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.
