As the use of free and open source software (“FOSS”) has become more ubiquitous, legal issues relating to FOSS have become more common and important. This year has seen a mix of new and old issues.  Even more so than 2008, this year has seen an increase in the importance of the top ten legal issues  http://lawandlifesiliconvalley.com/blog/?s=top+10+2008&x=40&y=6.  My list of the top ten FOSS legal developments for 2009 follow: 

1. MySQL Delays Sun/Oracle Merger.  The European Commission (“EC”) delayed the closing of the Sun/Oracle merger because of concerns about the future of the MySQL database software. MySQL software is the most widely used open source database.  The use of FOSS in the European Union is much higher than in the United States and the EC is very concerned about a potential reduction in competition in the database market.  The EC concerns seem to fundamentally misunderstand the nature of FOSS and the ability of the community to continue the development of the software even without ownership of the copyright in the particular software. This approach has been widely criticized http://www.economist.com/businessfinance/displaystory.cfm?story_id=14861553.  In mid December, Oracle offered ten commitments with respect to MySQL software. http://www.marketwire.com/press-release/Oracle-Corporation-NASDAQ-ORCL-1090000.html. The EC will make its decision next year. 

2. First Lawsuit by a Commercial FOSS Vendor.  Artifex uses a “dual licensing” model (providing the software under both the General Public License (”GPL”) and a commercial license) for its MuPDF rendering engine: the company filed suit against Palm for alleged copyright infringement because Palm allegedly violated the GPL (in the interests of transparency, I have worked for Palm in the past, but I am not involved in this matter)   http://lawandlifesiliconvalley.com/blog/?p=376. This complaint may signal the beginning of a trend by commercial open source companies with “dual licensing” models because the success of that model depends on the difference in the scope of rights available under an open source license and a commercial license (as well as the value of the additional protections, performance warranties, support and indemnification available under the commercial license). 

3. Microsoft Discovers Violation of GPL and Contributes to Linux.  Microsoft Corporation continues its engagement with the FOSS community by its prompt acknowledgement and correction of its failure to comply with the GPL in its distribution of the Windows 7 USB/DVD Download Tool http://lawandlifesiliconvalley.com/blog/?p=306. In addition, Microsoft provided three drivers to Linux under GPLv2 http://lawandlifesiliconvalley.com/blog/?p=276.

4. Standard for Injunctive Relief for License Breach Is Set High. Last year,  the Court of Appeals for the Federal Circuit (”CAFC”) overturned the District Court decision in Jacobsen v. Katzner and strongly supported the right of FOSS licensors to obtain copyright remedies for breach of FOSS licenses. This result was critical for FOSS licensors because copyright remedies include injunctive relief (an order by the court to the licensee to obey the license) and statutory damages of up to $150,000 for each infringed work. http://lawandlifesiliconvalley.com/blog/?p=64.  The CAFC decision was so clearly in favor of Jacobsen that most lawyers thought the District Court would grant an injunction to Jacobsen upon remand. Instead, the District Court refused to grant an injunction on the basis that Jacobsen had made no showing that he had actually suffered any potential harms and that Jacobsen had “failed to proffer any evidence of any specific and actual harm suffered as a result of the alleged copyright infringement” http://lawandlifesiliconvalley.com/blog/?p=141.  This decision is disappointing for FOSS licensors and hopefully other courts will not impose such a high standard for injunctive relief.  

5.  SCO Attack on Linux Rises From the Dead. In August, the Ninth Circuit Court of Appeals reversed the summary judgment granted Novell in its litigation over the ownership of the copyright in Unix software. The ownership of the copyrights in the Unix software is essential for SCO  to prosecute cases for copyright infringement against Linux. Thus, if SCO does not own the copyright in Unix, it cannot sue third parties claiming that the distribution of Linux infringes its copyright of Unix. The original contract between SCO and Novell relating to Unix does not transfer the ownership of copyrights in Unix to SCO, but a Second Amendment provides for a “conditional” assignment. The District Court had found that the conditions of the assignment had not been met and the assignment had not become effective. The Ninth Circuit decided that the facts were not sufficiently clear to grant summary judgment and asked the District Court to try the case. This decision is likely to have little practical effect. First, the decision does not grant ownership of the copyrights to SCO, but simply provides SCO the ability to litigate the issue rather than losing on summary judgment. Given that the judge has expressed his opinion that the copyright was not transferred by Novell under the “high” standard imposed by a summary judgment (a “summary” procedure setting a high standard of proof on the moving party,  Novell), it seems unlikely that he will change his decision under the lower standard of proof which applies in a lawsuit. Second, the continued prosecution of the case will be very expensive and SCO is in bankruptcy.  SCO would need to find additional financing to continue the case.  

6.  Enforcement of GPL for Busybox Continues. The Software Freedom Law Center has continued to enforce the GPLv2 on behalf of some of  the owners of the copyright in Busybox software. Most recently, the SFLC filed suit against fourteen major companies, including Samsung, Best Buy and Westinghouse  http://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/. The suits are based on violations of the GPLv2 in a variety of consumer electronic products, such as DVD players and televisions. However, Bruce Perens, one of the authors of the Busybox software, announced that he did not approve of the litigation  http://perens.com/blog/2009/12/15/23. He raised the question of the rights of one of the authors of FOSS in such litigation. This issue would depend on whether the software would be considered a “joint work” or “compilation” under copyright law  http://www.copyright.gov/title17/92chap1.html#101. As is the case frequently in software and copyright, these standard copyright categories are difficult to apply to software. A traditional example of a “joint work” would be a film because the work is the result of contributions by numerous authors to create a single work. A traditional example of a “compilation” would be a magazine which is the combination of independent copyrighted works from many authors.  This issue remains unresolved.   

7.  GPL Found to be Indirectly Enforceable in France. In case of first impression in France, the Court of Appeals in Paris has issued a holding, as part of a larger dispute over the delivery of software, that states that the terms of the General Public License were breached  (and thus the GPL is enforceable under French law). The basis for the decision was that the defendant, Edu4, had deleted two copyright notices in the VNC software and replaced them with its own copyright notice and had deleted the GNU GPL license language. The case is also unusual because it involved a suit by a licensee, AFPA, against a distributor, Edu4, claiming breach based on violation of the terms of the GPL by the distributor http://lawandlifesiliconvalley.com/blog/?p=285. 

8. ALI Adoption of Software Contract Principles.  The American Law Institute (“ALI”) approved the Principles of the Law of Software Contracts (the “Principles”) on May 19, 2009.  ALI is a very prestigious legal organization and the Principles have the potential to be very influential on courts. As I have discussed in this blog, the Principles continue to have significant flaws. The Principles were meant to clarify the ambiguity created by conflicting legal decisions and  the application of multiple laws to software licenses. Despite the stated goal of summarizing the case law and recommending best practices, the Reporters have included many new concepts which impose consumer type protections on both consumer and business software licenses. Although the Reporters have tried to exclude the applications of some of the Principles to FOSS, these modifications are not clearly successful in implementing this exclusion   http://lawandlifesiliconvalley.com/blog/?m=200906. 

9.  Microsoft Sues TomTom for Patent Infringement.  Microsoft Corporation sued TomTom for patent infringement for its GPS device which includes Linux. Although a number of commentators assumed that the suit was the first salvo in the long awaited patent assault on Linux by Microsoft, I was (and am) skeptical and thought that these concerns are premature. The claims relating to Linux, such as those covering FAT, are based on features common to many operating systems and would be likely to be subject to challenge under the new higher standards for patents set by the Supreme Court. Moreover, the case settled quickly, suggesting that it was not the beginning of a Microsoft assault against Linux   http://lawandlifesiliconvalley.com/blog/?p=214. 

10.  New GCC Runtime Exception.  The FSF announced new runtime exceptions (“GCC Exceptions”) for their popular GCC programs as part of its shift of the GCC programs from GPLv2 to GPLv3.  http://www.fsf.org/licensing/licenses/gcc-exception.html.  The exception is similar in purpose to the existing GCC exception for GPLv2 but is based on section 7 of the  GPLv3 which permits a limited (and carefully defined) number of “additional permissions.” The GCC Exceptions are necessary because the GCC program when it compiles another program may combine portions of certain GCC program header files and runtime libraries with the compiled program.  Without the GCC Exception, the compiled program would be required to be licensed under GPLv3 (just as without the prior exception, the use of GCC programs  licensed under GPLv2 for compilation would have required the compiled program to be distributed under GPLv2) . The GCC Exception permits the use of the GCC program to compile programs which are then licensed “under terms of your choice”, including proprietary licenses. However, the new GCC Exception has added a limitation to its scope which was not present in GPLv2 version of  the exception by limiting the use of non-GPL Compatible programs in the compilation process: “A Compilation Process is “Eligible” if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC. For example, using non-GPL-compatible Software to optimize any GCC intermediate representations would not qualify as an Eligible Compilation Process”.  This limitation was included because the GCC programs are moving to a “plug in” architecture and the FSF wanted to avoid permitting plug ins that “called out to proprietary software to transform the compiled code—effectively creating proprietary extensions to GCC and defeating the purpose of the GPL”.  

I am sure that this trend will continue in 2010, so stay tuned!

The American Law Institute (“ALI”) approved the Principles of the Law of Software Contracts (the “Principles”) on May 19, 2009. I have discussed these Principles in the past in this blog http://lawandlifesiliconvalley.com/blog/?p=134. Although the Reporters (the title given those managing the project) have made some changes to the earlier draft, the current draft continues to have significant flaws. The Principles were meant to clarify the ambiguity created by conflicting legal decisions and  the application of multiple laws to software licenses, such as intellectual property law (including, most importantly, copyright), Article 2 of the Uniform Commercial Code (“Article 2”) and various consumer laws (the federal Magnusson Moss Warranty Act and state laws such as the Song Beverly Warranty Act in California). Unfortunately, they have made the situation worse because many of their recommendations relating to ”best practices” are new and not consistent with existing law.

The Principles have the stated goal of summarizing the case law and recommending best practices, but the Reporters have included many new concepts which impose consumer type protections on both consumer and business software licenses. Yet consumer and business licenses are quite different because of the negotiation leverage of licensees who are businesses as well as the ability of businesses to enforce their rights. The result is a significant lack of flexibility in negotiating the terms of the license for businesses. Moreover, this dramatic change does not appear to be addressing any significant problem in the market.

The best example of this approach is the new “non disclaimable” warranty of no hidden material defects. This warranty provides that licensors are liable for “hidden” material defects if they are aware of them at the time of the transaction. Yet this warranty is not otherwise found in the case law and incorporates new and difficult concepts, such as “hidden” and “material”.  In addition, the concept of a “non disclaimable” warranty is fundamentally inconsistent with the approach of existing laws including Article 2  and both federal and state consumer warranty statutes. This warranty, if adopted, is likely to lead to significant litigation without any clear benefit to licensees.

The concern about the Principles in the software industry has led to unusual bedfellows: Microsoft Corporation and the Linux Foundation, who are fierce competitors with radically different approaches to licensing, sent a joint letter to the ALI to express their concern about  the provisions in the Principles and request a delay in their approval. The Principles were, nonetheless, approved.  

Despite these flaws, software licensors need to deal with the likelihood that the courts will be influenced by the Principles and need to review their agreements and processes. I will be providing a more detailed discussion of the major provisions in a series of blog posts. The Principles can be purchased at the ALI website at http://www.ali.org/.

In a major change in the law, the Court of Appeals for the Federal Circuit (”CAFC”) held in Transcore v. ETC found that covenants not to sue have the same effect on patent exhaustion as a patent license (i.e. a sale permitted under the covenant not to sue would “exhaust” the patent) http://www.cafc.uscourts.gov/opinions/08-1430.pdf.  

Consequently, a first sale that falls within the scope of a patentee’s covenant not to sue is considered “authorized” and exhausts the patent with respect to downstream customers and users. This holding is dramatically different from the assumptions of most lawyers.  In fact, lawyers frequently use a convenant not to sue rather than a patent license to avoid patent exhaustion. 

This issue is very important for software licensors, both commercial and open source,  because they must now rethink their approach to patent licensing.  For example,  Red Hat used covenants not to sue in its Firestar settlement to cover certain parts of its ecosystem http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf. This decision means that lawyers need to review their existing agreements to see how this change will effect the rights of their clients. They also need to be much more careful about drafting patent agreements. 

Another troubling aspect of the Transcore decision is its finding the covenant not to sue applied to a patent not yet issued at the time of the settlement on the basis of the theory of “legal estoppel.”

The Software Freedom Law Center (”SFLC”) has settled a second BusyBox sofware lawsuit. The settlement for Xterasys is confidential, but appears to be virtually identical to the settlement for Monsoon Media. Dan Ravicher, the SFLC attorney for BusyBox, stated:

As a result of the settlement, Xterasys has agreed to cease all binary distribution of BusyBox until SFLC confirms it has published complete corresponding source code on its Web site. Once SFLC verifies that the complete source code is available, Xterasys’ full rights to distribute BusyBox under the GPL will be reinstated.

Additionally, Xterasys has agreed to appoint an internal Open Source Compliance Officer to monitor and ensure GPL compliance, and to notify previous recipients of BusyBox from Xterasys of their rights to the software under the GPL. Xterasys will also pay an undisclosed amount of financial consideration to the plaintiffs.

The settlement suggests that SFLC has adopted a template for settlement. The lessons for FOSS management are the same as I suggested in my post about Monsoon Media. http://lawandlifesiliconvalley.blogspot.com/2007/11/monsoon-media-lessons-for-foss.html

1. You need to respond quickly and appropriately to any complaints about non compliance with open source licenses.

2. You should have a FOSS Use Policy to avoid these problems.

3. Your FOSS Use Policy should include a procedure for responding to these types of complaints.

4. Non-compliance, even “innocent” non-compliance, is getting more expensive.

If you don’t take these steps voluntarily, they may be imposed on you and you will have your own Open Source Compliance Officer.

One of the major questions in the open source community is whether projects will adopt the General Public License Version 3. Although I have stated in my previous post that the GPLv3 has significant advantages over GPLv2, inertia is tough to overcome. We have no prior history on this question because, in the past, projects did not have a choice between different versions of the General Public License. One challenge in answering this question is tracking these conversions because the information is very dispersed. Fortunately, Palamida, the software management firm, is now tracking these conversions on their website: http://gpl3.palamida.com/.

They count 116 conversions in the first week after the release of GPLv3. However, because this first week included July 4th, it may not be representative. Thanks to Palamida for making it easier to track these changes.

The final version of the General Public License Version 3 (“GPLv3) published on June 29th is a significant improvement over General Public License Version 2 (“GPLv2”) and deserves to have broad acceptance. In fairness to GPLv2, the GPLv2 was drafted in 1991: both the law relating to software and the manner in which software is developed and distributed has changed significantly since 1991. I was actively involved in the process as the Chair of Committee C, the committee representing users, and it is very satisfying that the hard work of the Free Software Foundation, Committee C and the other committees has reached such a successful conclusion (even though not all of our suggestions were accepted).

The process of drafting the GPLv3 has been a remarkably open one: the Free Software Foundation used four committees representing different constituencies from vendors to users to developers to focus comments while at the same time permitting anyone to comment on the drafts through their website. I have been practicing for over 25 years and in my experience this approach is unique. The result has been a significant improvement from the initial drafts and the FSF deserves credit for listening to constituencies beyond the free software community.

My perspective is formed by my legal practice: as noted in my biography, I work primarily with corporate clients from global corporations to Silicon Valley startups. I believe that the option of using the GPLv3 will be valuable to both corporations and developers. Because corporations are the largest users of software, their understanding and comfort with the terms of free and open source software (“FOSS”) licenses is important to the continuing success of FOSS.

The final version includes clarifications of existing issues in the GPLv2 as well as provisions dealing with new issues. The major differences between GPLv2 and GPLv3 are as follows:

1. Clarifying the Scope of GPLv3. The scope of the GPL license is one of the most critical issues for both vendor and users. The GPLv2 relied on United States copyright law for many of its critical definitions. Although the GPLv3 continues to use copyright as the basis for defining the scope of the license it is no longer based solely on United States copyright law. The GPLv3 has also clarified several important issues: for example, does “making the software available” (such as through an ASP) trigger the “copyleft” obligations of the GPLv3 (which include making source code available to licensees)? The GPLv3 clearly states no. Similarly, running the program and making modifications that licensee does not share do not trigger these obligations. Another important change is the deletion of the use of “collective work” in GPLv2: this term is defined in US copyright law as “a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.” This definition is difficult to apply to software and this ambiguity was a major source of concern about the interpretation of GPLv2.

2. Patents. The GPLv2 did not deal directly with patent licenses because software patents were very rare when it was drafted in 1991. However, software patents have become very common in the software industry in the United States and, thus, the lack of a patent license in GPLv2 created serious ambiguities about its scope. Although the FSF had taken a position that the GPLv2 provided an “implied” patent license, the position was controversial. The GPLv3 grants a direct patent license by companies who contribute (rather than merely distribute) the work. The GPLv3 also includes other provisions relating to patents to prevent another transaction similar to the Microsoft/Novell deal.

3. Expanded Compatibility. The inability to use FOSS programs together which are licensed under different FOSS licenses remains one of the major challenges to the success of FOSS. One of the major disadvantages of GPLv2 is that the software licensed under GPLv2 cannot be used with software licensed under most other major FOSS licenses. GPLv3 is specifically designed to broaden the number of licenses with which it is compatible. Most importantly, works licensed under the Apache Public License (“APL”) can be licensed under GPLv3 (although GPLv3 licensed software may not be licensed under the APL). GPLv3 licensed software can also be used with software licensed under the Affero General Public License which closes the “ASP hole” (see Section 9).

4. Broadened Scope of Works. The GPLv2 was limited to only programs. Although Sun Microsystems, Inc. was able to use the GPLv2 to license the RTL code for its SPARC chip, the GPLv2 was not designed for use with other types of works. The GPLv3 is much broader: it applies to any “copyrightable work” which ranges from software to documentation to music. It also expressly applies to “mask works” (which are the legal protection for the three dimensional design of semiconductors).

5. Termination. The GPLv2 terminated automatically upon failure to comply with its terms and continued use of the program was copyright infringement. GPLv2 did not address how to reinstate the rights under the license after coming back into compliance. This provision was particularly troubling as GPLv2 licensed software was used in consumer products such as television sets and computers which are sold in millions of units: even an inadvertent breach could result in massive liability for copyright infringement. The GPLv3 directly addresses this issue in Section 8. Although it continues to provide for automatic termination, it now includes a procedure for reinstatement.

6. Modification of Software for Consumer Products. This provision has received little comment, but could have an enormous impact. It requires that any consumer product which uses software licensed under the GPLv3 must “open up” the software. Frequently referred to as the “anti-Tivo” provision, it applies to products which are normally used for personal, family or household purposes as well as anything designed or sold for incorporation into a dwelling. Such consumer products range from the expected, such as televisions and stereos, to the surprising such as automobiles and home security systems. Section 6 requires that the vendor provide the source code as well as “Installation Information” for such software. Installation Information includes methods, procedures, authorization keys and other information required to install and execute modified versions of the software. The only exception is for software for which neither the vendor nor a third party can install modified software. This exception is likely to be very limited. The provision also provides the vendor with options relating to warranties and connection to a network in dealing with such modified software.

7. Limitations on Digital Rights Management. The GPLv3 reflects the FSF’s hostility to DRM. Section 5 prohibits the use of software licensed under the GPLv3 to implement DRM (referred to as “effective technological measures” to conform to the provisions of the relevant WIPO treaty). In addition, it requires a user of GPLv3 licensed software to waive his rights under the Digital Millennium Copyright Act and similar laws arising from the WIPO treaty to protect such works by using “anti-circumvention” technology.

8. Use of Contractors. One of the major changes in the software business since 1991 has been the increase in outsourcing of software development, either by independent contractors or outsourcing firms. Under the GPLv2 the transfer of a copy of the software to the independent consultant or outsourcing firm was a “distribution” and, thus, theoretically could permit the independent contractor or outsourcing firm to further distribute the software in both source code and object code form. GPLv3 resolves this issue in Section 2 by permitting a company to provide copies of the work to a third party to make modifications solely for the company.

9. Application Service Provider (“ASP). One of the significant issues in drafting the GPLv3 was the treatment of a new method of making software functions available: companies that do not “distribute” software, but rather make it available as a service (called an Application Service Provider). Since no distribution occurs, these companies do not have to comply with the “copyleft” provisions of the GPL such as making their source code available to their licensees. This problem was referred to as the “ASP hole.” This issue was not addressed in GPLv2 because this method of distribution did not exist in 1991. After considering several approaches, the FSF chose to provide an alternative license for those who wished to address this issue: the Affero General Public License (“AGPL”). The AGPL includes a provision requiring that companies providing services over a network make the source code available to users of the services (just as if the companies had distributed a copy of the software under the GPLv3) based on the well known “Affero” modification to the GPLv2. The GPLv3 also permits AGPL licensed software to “link” to GPLv3 licensed software, but does not permit the AGPL licensed software to be distributed under the GPLv3.

10. Additional Terms. The GPLv2 did not permit any modification of its terms which led to incompatibility with other FOSS licenses and potential problems in countries other than the United States where the wording of disclaimers and limitation of liability required to eliminate warranties and limit liability may differ from the United States. In Section 7, the GPLv3 permits limited modifications in these terms which will help solve these problems. In addition to making the GPLv3 compatible with the APL and permitting modified disclaimers of warranties and limitations, the provision permits adding limited attribution information (an approach which is being used by about twenty companies but using the Mozilla Public License as the basis) and various provisions to protect the use of trademarks and personal names.

I believe that the GPLv3 is a very valuable addition to FOSS licenses and solves many of the challenges faced by GPLv2. Companies distributing FOSS should consider it and companies using FOSS should be prepared, in most cases, to accept it.