This year, 2011, was one of the most active years in legal developments in FOSS. This activity reflects the increase in FOSS use: Laura Wurster of Gartner, noted in the Harvard Business Review blog that open source has hit a “strategic tipping point” this year with companies increasingly focused on using “open source” software for competitive rather than cost reasons.

Continuing the tradition of looking back over top ten legal developments in FOSS,  my selection of the top ten issues for 2011 are as follows:

1.  Android Patent Litigation.   One of the most widely reported legal developments in FOSS has been the patent wars surrounding the Android operating system.  Over 40 patent cases are pending between a wide variety of parties, including Motorola Mobility, Inc., HTC, Samsung Electronics, Inc. and Apple Computer, Inc.  This year saw several decisions in these suits.  In Australia, Apple won a trial court decision which enjoined the distribution of Samsung’s Android tablets based on a claim that the Samsung tablet violated Apple’s design patents. However, after a series of appeals, Australia’s High Court overturned the injunction and Samsung can now distribute its tablets. Apple was more successful in Germany where it was successful in obtaining an injunction based on Apple’s design patents which prevents the distribution of Samsung’s Galaxy Tab 10.1 (however, Samsung has released a revised version named the Galaxy Tab 10.1N).  Apple was not successful in obtaining an injunction against distribution of Samsung’s Galaxy Tab in the United States, although the judge stated that Apple’s design patents might be infringed. More recently, on December 19, the ITC ruled that HTC’s Android phones violated two claims of an Apple utility patent and issued an “exclusion order” for HTC Android phones which would take effect on April 19, 2012. HTC has announced that it will provide a workaround.  Google has been handicapped by its lack of patents to assert in defense of Android (it started with only 600 patents, but is aggressively buying new patents and has agreed to purchase Motorola Mobility, Inc., primarily for its patent portfolio).

2.  Oracle v. Google.   A separate but related case is Oracle’s suit against Google for the alleged infringement of Oracle’s copyrights in the Java software (which it acquired from Sun Microsystems, Inc.) and certain Oracle patents by Android.  Oracle is asserting that the Android operating system infringes the copyrights in “twelve code files and 37 specifications for application programming interface packages”.  The decision on this claim could have a significant impact well beyond this case: most software lawyers have viewed APIs (and their specifications) as either having no copyright protection or very limited copyright protection. These views govern the interpretation of both FOSS and proprietary licenses.  The court described APIs as follows:

Conceptually, an API is what allows software programs to communicate with one another. It is a set of definitions governing how the services of a particular program can be called upon, including what types of input the program must be given and what kind of output will be returned. APIs make it possible for programs (and programmers) to use the services of a given program without knowing how the service is performed. APIs also insulate programs from one another, making it possible to change the way a given program performs a service without disrupting other programs that use the service.

If Oracle prevails and the court finds that APIs are copyrightable, lawyers will need to rethink how they interpret both FOSS and proprietary licenses. The issue could be particularly important in determining whether interactions between software programs licensed under GPLv2 or GPLv3 create, respectively, “derivative works” or a “modified version” and, thus, impose the license terms of GPLv2 or GPLv3 on the software modules with which they interact. The first significant decision in the case rejected Google’s attempt to eliminate the claims through summary judgment (Google won only on a single minor point).  However, this decision is not surprising because summary judgment is generally used for settled issues of law; the copyright issues in this case are on the cutting edge of the law.

3.  Perfect 10 v. Google.   Although this case was not strictly about open source software, it established a critical principle for remedies for copyright infringement. These remedies also apply to enforcement of copyright licenses in certain situations. For decades prior to this decision, the presumption was that the remedy for copyright infringement was always “injunctive relief”.   Injunctive relief means that a court orders an “infringer” to comply with the terms of the license. The Perfect 10decision in the Ninth Circuit Court of Appeals made clear that “injunctive relief” is no longer a remedy which is always available for copyright infringement.  Instead, the court stated that:

We therefore conclude that the propriety of injunctive relief in cases arising under the Copyright Act must be evaluated on a case-by-case basis in accord with traditional equitable principles and without the aid of presumptions or a “thumb on the scale” in favor of issuing such relief.

Injunctive relief is an unusual remedy for breach of license agreements, because under Anglo Saxon law, the standard remedy for breach of contract is monetary payment. However, a remedy of monetary damages has little value for breach of open source licenses because the open source software is generally distributed at no cost. The Perfect 10 decision undercuts the value of the Jacobsen decision to the open source community.  In Jacobsen, the Court of Appeals of the Federal Circuit decision found that injunctive relief was available for open source licenses if the relevant obligations were drafted to make them a “restriction” on the scope of the license rather than just a contractual obligation (a “covenant”).  However, the other standard copyright law remedies such as attorneys fees, actual damages and, potentially, statutory damages remain available. Yet, injunctive relief, the most valuable of remedies, may be more difficult to obtain to enforce open source licenses.

4.  Publication of Software Package Data Exchange (“SPDX”) Specification.  The management of open source software in the supply chain has been a continuing problem. However, the open source community has been working to find a solution to this problem.  The work has been guided by the SPDX Group (the SPDX Group is a working group of the Linux Foundation and is associated with FOSSBazaar) which has developed the SPDX specification as a standard format for describing the components, licenses and copyrights associated with a software package. For example, SPDX Group has identified seven versions of the General Public License version 2, the most commonly used open source license. If widely adopted, SPDX will be critical to effectively manage open source software as it becomes more widely used in the supply chain. As noted in the Harvard Business Review blog by Gartner Group, the ubiquity of the use of open source software has not been matched by effective management of its use.

5.  Revision of Mozilla Public License.   The Mozilla Public License is one of the most popular open source licenses.  After eighteen months of work, Mozilla has announced a new version. The Mozilla Public License version 2 (“MPLv2”) is a much simpler, shorter and more usable license. The new license has adopted approaches (and sometimes the terms themselves) from other open source licenses: the patent license provision was adopted from the Apache license and the termination provision from the General Public License version 3. In addition, Mozilla has made the MPLv2 compatible with the Apache license. And MPLv2 has also included a provision to make the license “compatible” with other licenses. For example, MPLv2 permits distribution of code under the MPLv2 with other modules licensed under GPL variants (GPLv2, GPLv3, APGL and LPGL) if such modules are part of a “Larger Work” (unless the notice in the software states that the software is “Incompatible with Secondary Licenses”).  However, these differences mean that the transition to the MPLv2 for existing projects will require careful thought.

6.  Cybits Decision in Germany.  This decision makes clear that companies cannot alter the terms of software licensed under GPLv2.  AVM is a manufacturer of FRITZ!Box router, a digital subscriber line DSL terminal, which uses the Linux Kernel as a part of their production firmware (which is licensed under GPLv2). Cybits, a software producer, distributes the Internet filtering software “Surf-Sitter DSL”, which is intended to protect children. The Surf-Sitter application downloads FRITZ!Box software to the user’s computer, modifies it and then reinstalls it back on the FRITZ!Box.

AVM claimed that Cybits did not have the right to modify the part of the FRITZ!Box firmware which was licensed under GPLv2. The court rejected AVM´s claims that Cybits should not be permitted to alter the firmware of AVM and denied that Cybits had infringed AVM´s copyright by distributing Surf-Sitter. The court found that the firmware is a collective work, which contains modules licensed under GPLv2. Cybits or any third party may modify the GPLv2 licensed software. Thus, AVM is not able to control any modifications to the GPL licensed components of the FRITZ!Box firmware.

7.  Project Harmony Publishes Standardized Contributor Agreements.   Many commentators have complained about the problems raised by the number of licenses approved as “open source”, a problem frequently referred to as “license proliferation”.  Yet a similar problem is lurking in the development of open source software: the contribution agreements which govern the rights provided by contributors to a project. Project Harmony was a community effort to resolve this problem in advance by developing a set of standard agreements which can be adopted by open source projects.

Many open source projects use the “license” for the project as a contribution agreement, but a variety of separate open source contribution agreements have developed over time, from the Apache Contributor Agreement to the Joomla Contributor Agreement. Although many open source projects can use their standard open source license (i.e. GPLv2 for Linux or Mozilla Public License for the Mozilla browser) as the “contribution agreement”, this approach “locks in” the open source project to that license.  If the open source project wishes to change the license (such as the change of OpenOffice project from GPLv2 to Apache), this approach would require that each contributor agree to the change. A good example of the potential for problems with this approach is the Open Street Map Project (“OSM Project”). The OSM Project has been struggling with shifting from a Creative Commons license to a more appropriate Open Database License. After three years, the transition is still not complete. Finally, the OSM Foundation has given up on obtaining agreement from the remaining contributors and will probably delete contributions from  contributors that have not agreed to shift to the new license. In addition, open source licenses do not deal with a number of other issues which should be addressed by contribution agreements, such as contributions by minors and changes of license. Project Harmony also makes it easier for corporations to contribute to open source projects by avoiding the complexities of managing the differing terms of these new contribution agreements. The Project Harmony standard contribution agreements permit projects to make a choice between a license or assignment approach and, then, select among several options to change licenses in the future (without obtaining permission from each contributor.

8.  Dispute over Koha Trademark.   The importance of the protection of trademarks to open source projects was illustrated by the recent dispute over the Koha trademark between Horowhenua Library Trust (“HLT”) and a commercial company,  PTFS.  HLT manages the Koha open source project. PTFS filed for trademark protection for Koha in New Zealand after it had acquired a company which used the trademark and the trademark was, then, registered by the New Zealand government. Upon registration of the Koha trademark, HLT complained and appealed for help. Subsequently, PTFS agreed not to enforce the trademark and even to transfer the trademark to HLT.

9.  The Meaning of Open Source.  The power of the community to police the misuse of “open” was demonstrated by Nokia’s attempt to claim that the Symbian mobile operating system was “open” for business.  However, the Symbian license is not consistent with the Open Source Definition. The copyright license in the Symbian license is as follows:

Subject to the terms and conditions of this Agreement, Nokia hereby grants to You a personal, non-exclusive, non-transferable, irrevocable (except as set forth in Clause 7.1 and 7.2 below), royalty-free and worldwide license under Copyrights licensable by Nokia to: i) reproduce and modify Source Code Components; ii) reproduce Binary Components and Documentation; iii) use and reproduce Utility Software, and iv) publicly display, distribute and make available (a) the Source Code Components to third parties that have acquired a valid source code license from Nokia; and (b) Utility Software, Binary Components and Source Code Components in binary form to third parties, (c) Documentation in unmodified form in all cases i)-iv) solely as part of the Symbian Platform or for use with the Symbian Platform, under the terms and conditions of this Agreement.

The agreement requires a separate license for source code from Nokia and limits the use to the “Symbian Platform.” Nokia was forced to “correct” their original statement to “open for business” rather open source.

10.  Open Hardware License.   The open hardware movement received a boost when CERN published an Open Hardware License (“CERN OHL”). The CERN OHL is drafted as a documentation license which is careful to distinguish between documentation and software (which is not licensed under the CERN OHL). The license is “copyleft” and, thus, similar to GPLv2 because it requires that all modifications be made available under the terms of the CERN OHL. However, the license to patents, particularly important for hardware products, is ambiguous. This license is likely to the first of a number of open hardware licenses, but, hopefully, the open hardware movement will keep the number low and avoid “license proliferation” which has been such a problem for open source software.

This blog was originally posted to Law & Life: Silicon Valley.