Get the highlights in your inbox every week.
A review of legal, free and open source software issues in 2012
Top 10 FOSS issues of 2012
The year 2012 had many important FOSS legal developments which reflects the continued increase in FOSS use. FOSS projects have increased from 600,000 in 2010 to 900,000 by December 2012. In addition, a Dr. Dobbs' survey in the third quarter of 2012 stated that more than 90% of developers are using FOSS in two of the most rapidly growing areas, cloud computing and mobile computing.
Continuing the tradition of looking back over the top ten legal developments in FOSS, my selection of the top ten issues for 2012 are as follows.
Android patent litigation
The litigation surrounding the Android operating system has continued around the world. Although some of the cases have settled, the litigation has continued to result in multiple decisions in different countries. One of the most important decisions occurred in Silicon Valley on August 24, 2012: the jury awarded Apple Computer, Inc. ("Apple") $1.05 billion in damages for Samsung’s violation of its patents. The decision is particularly interesting because the lawsuit involved four design patents and three utility patents.
Note: DLA Piper represents some of the parties in other matters, I offer no opinion on the correctness of the decision.
Many intellectual property lawyers have been skeptical about the value of design patents, particularly in comparison to utility patents. This decision will undoubtedly cause a reassessment of the value of design patents. However, more recently, in the same case, the judge refused to grant Apple a permanent injunction against the distribution of the Samsung products found to be infringing. This decision will be appealed and we will not know the final answer for some time. The multiple cases will undoubtedly continue this year.
Protection of APIs: Oracle v. Google
A separate but related case also involved the Android operating system. Oracle sued Google for the alleged infringement of Oracle’s copyrights in the Java software (which it had acquired from Sun Microsystems, Inc.) and certain Oracle patents. Oracle alleged that Google’s Android operating system infringes the copyrights in "twelve code files and 37 specifications for application programming interface packages." The results of the dispute were complicated because the judge first had the jury make a decision about copyright infringement but reserved for himself the decision about whether the application programming interfaces ("APIs") were copyrightable. Thus, in early May last year, the jury found that Google had infringed the copyrights in Oracle’s APIs (although they deadlocked on whether the copying was "fair use"). However, at the end of May, Judge Alsup issued a decision finding that the Java APIs were not protectable under copyright law. The decision is one of the first on this issue. The critical part of the decision stated:
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. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality—even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.
Although the decision is carefully limited to the facts of the Oracle case, it strongly suggests that judges will provide more limited protection to computer software under copyright law:
This order does not hold that Java API packages are free for all to use without license. It does not hold that the structure, sequence, and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.
Note: DLA Piper represents some of the parties in other matters, I offer no opinion on the correctness of the decision.
If it is upheld, the decision has important implications for the scope of FOSS licenses: the GPL family of licenses is generally viewed as imposing obligations on "derivative works" as defined by copyright law. The combination of more limited scope of copyright protection for computer software and the rise of "loosely coupled" programming techniques using APIs may limit the scope of these licenses.
EU copyright law does not protect computer language and functions
The SAS Institute, Inc. ("SAS") v. World Programming, Limited ("WPL") decision in the European Court of Justice involved the scope of copyright protection for computer programs and has important implications for FOSS and the scope of "derivative works" under copyright law. The case addresses issues similar to the Oracle v. Google case described above (in fact, Judge Alsup asked for a briefing from the parties in the Google case after the SAS decision was announced).
The case involved the copying of the scripts and certain functions of the SAS analytical software. The SAS software enables users to write and run their own application programs in order to adapt the SAS software to work with their data. These "application programs" are called "scripts" and are written in a language which is peculiar to the SAS software. WPL recognized that a market existed for alternative software capable of executing application programs written in the SAS language. WPL produced the 'World Programming System,' designed to emulate the SAS components as closely as possible in that, with a few minor exceptions, it attempted to ensure that the same inputs would produce the same outputs. This approach would enable users of the SAS software to run the "scripts" which they have developed for use with the SAS software on the 'World Programming System.' The court found that such functions and programming language were not protected under the EU Directive on Protection of Computer Programs:
Article 1(2) of Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs must be interpreted as meaning 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 and, as such, are not protected by copyright in computer programs for the purposes of that directive.
Similar to the Google decision, this decision has important implications for the scope of FOSS licenses. As I noted above, the GPL family of licenses is generally viewed as imposing obligations on "derivative works" as defined by copyright law. The combination of a more limited scope of copyright protection for computer software and the rise of "loosely coupled" programming techniques may limit the scope of these licenses.
Expansion of the Open Source Initiative
The Open Source Initiative ("OSI") has decided to broaden its base by expanding its role as an advocacy organization. The OSI has started membership programs for individuals and affiliated organizations. (Note: As a matter of transparency, I am outside general counsel to the OSI on a pro bono basis.)
OSI describes this change as follows: "The OSI is moving its governance from a model of volunteer and self-appointed directors to one driven by members. Our high-level objectives in doing so are to provide a broad meeting place for everyone who shares an interest in open source software, with the continuing aim of strengthening the OSI so that it can more effectively fulfill its goals over the long term." The Affiliate Program has successfully signed up over 20 open source organizations, which include, among others, the Linux Foundation, Mozilla Foundation, Debian, and OW2.
One disturbing trend is the posting of FOSS modules without licenses. Simon Phipps focused on this problem in his recent blog, particularly on the problems raised by the terms of service at Github. James Governor, the founder of analyst Red Monk, is quoted by Simon as stating (on Twitter): "younger devs today are about POSS—Post open source software. f*** the license and governance, just commit to github."
As I mentioned in another post, this approach will undercut the major desire of most FOSS developers: the broad use of their code. The lack of a license ensures that the software will be removed from any product meant to be used by corporations. Corporations are very sensitive about ensuring that all software that they use or which is incorporated in their products is properly licensed. I have worked on the analysis of hundreds of software programs and the response to software without a clear license is almost always "rip it out." In addition, as I discuss in more detail in the post, this approach could also subject the developer to liability under the Uniform Commercial Code (an admittedly low probability).
Qualification of FOSS under the Trade Agreement Act
Talend, a licensor of open source enterprise software, has recently received a ruling from the U.S. Customs Service corroborating that its software complies with the Trade Agreements Act of 1979 (19 USC 2511 et seq.) ("TAA"). FOSS adoption by the U.S. Federal government must comply with many regulations, some of which can be difficult given the nature of modern software development.
Contributor agreements redux
Recently, the issues of contribution agreements arose in the departure of Nikos Mavrogiannopoulos from the GnuTLS project. As the primary drafter of the Harmony Project contribution agreements, I have had an opportunity to consider these issues in detail. GnuTLS is "a secure communications library implementing the SSL,TLS and DTLS protocols." The project was commenced in 2000 under the GNU project. As is true of all GNU projects, the copyrights in the contributions are assigned to the Free Software Foundation ("FSF"). When Nikos left, Richard Stallman reminded him that he could fork the project, but that the FSF would retain ownership of copyright in the project code. The LWN article concludes that the basis for copyright assignment "seems to be weak." I disagree with this conclusion and Bradley Kuhn makes some very cogent arguments in the comment sections.
Copyright assignment does provide the manager of the FOSS project (in this case, the FSF) with significant advantages in enforcement as well as changing the license of a project. Without an assignment, a licensee can raise several potential defenses (such as a license from an alleged joint copyright owner) whose strength is uncertain. In addition, any change in the project license would require the approval of each contributor to the project. However, copyright assignments also mean that the community needs to be comfortable that the project strategy of the project manager is aligned with the community. However, as FOSS projects continue for a longer period, this alignment may be more difficult to determine in advance. And this approach also poses practical problems for the FOSS project manager: the project manager needs to be very disciplined about getting the written assignments from all contributors. Such assignments may be difficult to obtain from developers employed by a corporation because corporations are reluctant to assign intellectual property rights.
This dispute emphasizes the importance of FOSS projects and their contributors carefully considering the needs of the project when deciding on how to obtain the necessary rights in contributions. Project Harmony provides information and proposed agreements to assist FOSS projects to make these decisions. Once determined, the method of implementation of a contribution agreement is important: the Eclipse Foundation also provides an excellent summary of their approach to due diligence issues relating to accepting contributions.
Rise of open source collaborations
Open source collaborations have become an increasingly important strategy for companies to address major software development problems. This trend was best illustrated last year by the creation of the OpenStack Foundation ("Foundation"). The Foundation takes over the OpenStack project from Rackspace who had managed the project for several years. (Note: As a matter of transparency, I represent the Foundation).
OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a data center. The Foundation is run by a board of 24 members, with eight members representing individuals, eight members representing Gold Members, and eight members representing Platinum Members. The Foundation has over 150 corporate members and more than 6,000 individual members. In a second example, Deutsche Bank announced in September the formation of the Lodestone Foundation to coordinate the development of IT solutions for capital market companies. The OpenStack Foundation and the Lodestone Foundation join the many foundations who manage open source collaborations for combinations of corporations which include, among others, the Linux Foundation, Genivi Alliance, and Eclipse Foundation.
UK Government adopts Open Standards Principles
The UK government adopted Open Standards Principles in government IT procurement through a Cabinet Report. The report adopted open standards to encourage "software interoperability, data and document formats in government IT specifications." One of the goals of the adoption of the Open Standards Principles was to ensure that FOSS and proprietary software could compete on an equal level. One important requirement of UK Open Standard Principles is that the patent rights for the standards must be available on a royalty free basis: "rights essential to implementation of the standard, and for interfacing with other implementations which have adopted that same standard, are licensed on a royalty free basis that is compatible with both open source and proprietary licensed solutions. These rights should be irrevocable unless there is a breach of licence conditions." Government remains a significant potential market for FOSS companies but their procurement procedures continue to hinder such adoption (see discussion of Talend’s success with the Trade Agreement Act above).
More standardized process on FOSS compliance by large companies
In my practice, I have seen an acceleration of an existing trend: many large companies are much more focused on FOSS compliance and are developing standardized procedures to ensure compliance. I work with many small companies entering into commercial relationships with large companies as well as large companies entering into commercial relationships and purchasing smaller companies. Although some technology companies have developed and implemented such procedures for commercial relationships for several years, such processes have recently become much more widespread and sophisticated. They range from elaborate contractual provisions relating to remedies to special procedures for "remediation" through removal of certain modules and developing functionally compatible software.
Although a limited number of technology companies have also implemented a separate due diligence process for FOSS compliance in acquisitions for several years, these practices are also spreading more widely to both technology companies and non-technology companies. Acquiring companies are even willing to change the form of a transaction to avoid potential FOSS compliance problems: recently, I worked with a company that shifted an acquisition from a merger to a sale of assets primarily based on FOSS compliance concerns. This development emphasizes the need for small companies to have a structured approach to the management of the use of FOSS and to be able to demonstrate such management to both potential commercial partners and potential acquirers.