Before (or, more likely, while) diving headfirst into the deep end of a new year, it's good to take a moment to consider what significant events occurred in the closing year. With the benefit of 20/20 hindsight, one can gain new perspectives on the recent past and, perhaps, gather valuable insight and foresight to plan for this coming year. That being said, here are my top three significant open source events from 2012:
1) Copyright protection of software not as broad as some might like
Two cases, one in the United States and one in the European Union, provide valuable clarification regarding the limits of copyright protection applicable to software.
Oracle v. Google5, it bred early and often conjecture that Oracle was going to take Google to the cleaners, that this could be the death (or at least a major setback) of Android, or other such doomsday scenarios. The world of open source software kept a vigilant watch as this case combined dubious software patents and critical, precedential copyright questions concerning the world's most popular open source mobile operating systems. The copyright portion of the case involved Java API packages. Oracle's central claim was that Google had replicated the structure, sequence, and organization of the overall code for 37 Java API packages. The parties agreed that Google had not literally copied the software, but had instead developed its own implementations of the 37 APIs. Interestingly, Oracle's trial brief also asserted that the Java language itself was protected by copyright, but the court opinion states that "[a]ll agree everyone was and remains free to program in the Java language itself." 6
When Oracle sued Google on August 12, 2010 for copyright and patent infringement (on seven patents) relating to its Java platform
The court held that "so long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API." 7 The court reasoned that although the Android method and class names were the same, copyright law does not protect names, titles, short phrases, or expressions. Additionally, these names represent a symbol in a command structure; a command structure that is used as a utilitarian and functional set of symbols to carry out pre-assigned functions is a "system or method of operation," as per Section 102(b) of the Copyright Act and cannot be protected. Furthermore, when there is only one (or only a few) ways to express something–as is the case here, where the method specification as set forth in the declaration must be identical under the Java rules to carry out a specific function–then no one can claim ownership of such expression by copyright. 8
SAS Institute Inc. v. World Programming Limited 1 The European Court of Justice (ECJ) held that "neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program for the purposes of Article 1(2) of Directive 91/250." 2 Such ideas and principles are not protected by copyright; only the expression of those ideas and principles is protected. To hold otherwise would result in a monopoly on ideas, which is not the goal of copyright protection.
SAS Institute developed the SAS programming language, a set of programs, and associated documentation. SAS brought suit against World Programming, Ltd (WPL) for copyright infringement involving, among other issues, the extent to which copyright protection applies to a programming language.
This concept is not unique to European Union law; under United States law, copyright protection also covers only the expression of an idea, not the idea itself. For example, copyright protects the book that explains a system of bookkeeping, but does not protect the system the book describes. 3 Likewise, recipes are not protectable because they describe a procedure or process. 4 It is reassuring to have the highest court in the EU return a verdict that is consistent with US law, as well as the general assumption in the software industry regardless of location. From a pragmatic view, can you imagine any other result? What if the authors of any of the most popular computer languages could assert copyright, and thereby require a license fee for any implementation or derivation of the language?
For many software programmers, the net result of these court decisions is probably not earth-shattering, as the holdings reflect assumptions long held by many. However, to have such established jurisprudence reduces potential fear, uncertainty, and doubt for business and legal risk managers.
2) Last of BusyBox suits settle
Back in December 2009, open source license enforcement made major headlines when the Software Freedom Law Center sued fourteen defendants, including Best Buy, Samsung, Bosch, and Westinghouse, over non-compliance with the GNU General Public License v2 (GPL v2). Most of the defendants settled with minimal public mention. One defendant entered state bankruptcy proceedings and stopped participating in the lawsuit, which led to a default judgment against them including injunctive relief, statutory damages, forfeiture of the remaining infringing items, and attorney’s fees and costs. The remaining defendant finally settled in 2012, almost three years after the filing.
There is no doubt that this suit, with household-name defendants, caught the attention of many open source software users. No longer could license compliance be ignored. Legal departments and compliance officers scrambled to get a handle on this "free" software issue. Since then, enforcement actions have not made headlines. This does not mean, however, that license compliance enforcement has ceased 9; rather, it has returned to private discussions that lead to compliance via agreement instead of litigation, which is a far more efficient and preferable resolution for all involved.
Unfortunately, many organizations operate primarily out of urgency, and the lack of public visibility can lull back to laziness those companies only concerned about the risk of litigation vis-à-vis license compliance. To do so is severely short-sighted, as it represents a failure to see the many other reasons to properly govern the use of open source software. By way of analogy, do you only drive the speed limit to avoid getting a ticket? Of course not. You also drive the speed limit because it is safer, smarter, more fuel efficient, makes your passengers more comfortable and likely to ride with you, and so forth.
3) Open source software knowledge: a little does not go a long waya similar post, I called 2011 the year when open source adoption left the age of denial, and wondered if 2012 might be the year of responsibility and action. I may have been prematurely optimistic. By "responsibility and action," I imagined that the gap between the vast number of companies using OSS and the relatively small percentage that have an open source policy and governance framework implemented would shrink. But I forgot that in order for this to occur, there is a crucial and easily underestimated step.
Last year when I wrote
Without consistent and relevant knowledge of open source software by all users within an organization, an open source policy or governance framework cannot be effective. Although awareness of open source software and the surrounding issues has certainly increased (as I noted last year), a little knowledge does not necessarily go a long way. In the various interactions we have with a wide range of customers, one recurring theme is the need for education. Often there may be one or a few open source "champions" in an organization who realize the need to get their ducks in a row in regards to tracking use, achieving license compliance, etc. The champion may have a high level of understanding, but that does not mean the rest of the affected personnel (developers, legal, business) will be able to comprehend the rationale for various open source policy rules, or which risks associated with the open source software apply to their organization. All the best intentions, policies, and procedures are practically useless if some or most of your organization does not possess the knowledge to grasp, value, and implement them.
Where does your organization fall on the open source software understanding continuum? Knowing you need to do something is not enough. Perhaps 2013 is the year to transition from simple awareness to cognitive understanding and decisive action.