I recently did a webinar for Gathering 2.0 on open source legal issues with a particular emphasis on GPLv3. Gathering 2.0 is an interesting website which is building a community for people who manage intangible assets (like patents, copyrights and trademarks) for companies. I have known the founder, Suzanne Harrison, for over 15 years and she has great experience in this area. Since intangible assets have become such a large part of a company's assets it is critical that they be managed just like other assets. IBM has been doing a great job for many years, extracting over $1 billion per year by licensing its patent portfolio. In the interest of transparency, I should note that Gathering 2.0 is a client.
If you are interested in listening to the webinar (and seeing the slides), please follow these instructions:
1. Go to http://www.gathering2.com/
2. To access the slides, you must register and basic membership is free.
Note: The audible-only portion is available without registration ( on the homepage, just click the "Recording" link in the webinar block below and to the right of my picture).
3. Once you register and login, go back to the homepage, click the "Download Slides" link in the webinar block which is the block below and to the right of my picture.
Friday, August 24, 2007
Wednesday, August 22, 2007
New Open Source Legal Decision: Jacobsen & Katzer and How Model Train Software Will Have an Important Effect on Open Source Licensing
One of the frustrations of lawyers serving the open source industry is that they have few cases which interpret open source licenses. As Eben Moglen has pointed out, such cases are few because licensees need the license be in effect to avoid copyright infringement. However, with the increasing use of open source software, many lawyers believe that issues such as the scope of the license are likely to come before courts. The first example of these disputes arose in a decision published on August 17, 2007 in San Francisco regarding the Artistic License. Unfortunately, this case was wrongly decided and if allowed to stand may deprive open source licensors of the ability to get a court order (an injunction) to stop violation of the terms of their license, an important remedy for breach of such licenses.
Although you would expect that the first of these cases would focus on one of the wide range of commercial software being made available under open source licenses and probably deal with the most widely used license, the GPL. You would be wrong. The first case involves model railroad software and the rarely used Artistic License. The facts of the case are complicated, but can be gleaned from the pleadings at
http://jmri.sourceforge.net/k/docket/index.html (the decision is available there too). The plaintiff alleged a number of causes of action, but the most important was the alleged breach of the Artistic License (and copyright infringement for acting beyond the scope of the license) due to the removal of all of the original copyright notices to the original authors and the substitution of Katzen's company's name.
The decision makes two important points: (1) the Artistic License is a contract and (2) the failure to include the copyright notices was not a "restriction" on the scope of the license. The first point is important because the Free Software Foundation and some lawyers have taken the position that open source licenses are not contracts. They have good reasons for wishing to avoid some contract formalities, but this position has complicated discussions about the enforceability and remedies for open source licenses. This decision does not settle the issue for the GPL because it does not apply to the GPL and it is only a District Court decision, (lawyers really prefer to have an appellate decision, such as from the Ninth Circuit or the Supreme Court) but it does suggest how courts would approach the issue.
The second point is very important because it deals with remedies. Generally, the remedy for contract violations under US law is damages, not "injunctive relief" (which means that the court order a party to cease their violation). On the other hand, copyright infringement generally includes a presumption that injunctive relief is appropriate. Thus, the question of whether the violation of a license is a contract violiation or copyright infringement (it can be both) is very important, because licensors would prefer to obtain an injunction prohibiting the breach of the license. The question turns on a nuanced legal issue of whether the term in the license is a "restriction on the scope" of the license or a covenant. In the first case, the failure to comply with the provision means that the licensee is outside the scope of the license and thus is a copyright infringer (as well as liable for breach of the contract). On the other hand, if the term is merely a covenant, then the failure to comply with it is a breach of contract. The most celebrated case dealing with this issue involved the Java license between Sun and Microsoft in which the court found that the obligation on Microsoft to meet the Java compatability tests was a covenant, not a restriction on the scope of the license and the court denied Sun an injunction on those grounds (Sun got an injunction for unfair competition).
However, in this case, the court found that the condition to include a proper notice was not a restriction on the scope of the license and, thus, Katzen was not liable for copyright infringement. The court then denied the injunction. The court did not provide an analysis of why it reached this conclusion. I believe that this decision is simply wrong. The use of the term "condition" in the Artistic License should mean that the terms imposed are restrictions on the scope of the license. In fact, the judge in the Sun case even noted that restrictions are provisions which use language such as "subject to" or "conditional". This decision, if upheld, will remove an important (and expected) remedy from open source licensors. Just to be clear, the decision at present deals only with the Artistic License and the provisions dealing with this issue in other licenses may be interpreted differently. However, the decision is unfortunate and I recommend that the open source community support Jacobsen in having this decision reconsidered. Thanks to Roberta Cairney for bringing this decision to my attention; she has been in the forefront of many important copyright issues.
Although you would expect that the first of these cases would focus on one of the wide range of commercial software being made available under open source licenses and probably deal with the most widely used license, the GPL. You would be wrong. The first case involves model railroad software and the rarely used Artistic License. The facts of the case are complicated, but can be gleaned from the pleadings at
http://jmri.sourceforge.net/k/docket/index.html (the decision is available there too). The plaintiff alleged a number of causes of action, but the most important was the alleged breach of the Artistic License (and copyright infringement for acting beyond the scope of the license) due to the removal of all of the original copyright notices to the original authors and the substitution of Katzen's company's name.
The decision makes two important points: (1) the Artistic License is a contract and (2) the failure to include the copyright notices was not a "restriction" on the scope of the license. The first point is important because the Free Software Foundation and some lawyers have taken the position that open source licenses are not contracts. They have good reasons for wishing to avoid some contract formalities, but this position has complicated discussions about the enforceability and remedies for open source licenses. This decision does not settle the issue for the GPL because it does not apply to the GPL and it is only a District Court decision, (lawyers really prefer to have an appellate decision, such as from the Ninth Circuit or the Supreme Court) but it does suggest how courts would approach the issue.
The second point is very important because it deals with remedies. Generally, the remedy for contract violations under US law is damages, not "injunctive relief" (which means that the court order a party to cease their violation). On the other hand, copyright infringement generally includes a presumption that injunctive relief is appropriate. Thus, the question of whether the violation of a license is a contract violiation or copyright infringement (it can be both) is very important, because licensors would prefer to obtain an injunction prohibiting the breach of the license. The question turns on a nuanced legal issue of whether the term in the license is a "restriction on the scope" of the license or a covenant. In the first case, the failure to comply with the provision means that the licensee is outside the scope of the license and thus is a copyright infringer (as well as liable for breach of the contract). On the other hand, if the term is merely a covenant, then the failure to comply with it is a breach of contract. The most celebrated case dealing with this issue involved the Java license between Sun and Microsoft in which the court found that the obligation on Microsoft to meet the Java compatability tests was a covenant, not a restriction on the scope of the license and the court denied Sun an injunction on those grounds (Sun got an injunction for unfair competition).
However, in this case, the court found that the condition to include a proper notice was not a restriction on the scope of the license and, thus, Katzen was not liable for copyright infringement. The court then denied the injunction. The court did not provide an analysis of why it reached this conclusion. I believe that this decision is simply wrong. The use of the term "condition" in the Artistic License should mean that the terms imposed are restrictions on the scope of the license. In fact, the judge in the Sun case even noted that restrictions are provisions which use language such as "subject to" or "conditional". This decision, if upheld, will remove an important (and expected) remedy from open source licensors. Just to be clear, the decision at present deals only with the Artistic License and the provisions dealing with this issue in other licenses may be interpreted differently. However, the decision is unfortunate and I recommend that the open source community support Jacobsen in having this decision reconsidered. Thanks to Roberta Cairney for bringing this decision to my attention; she has been in the forefront of many important copyright issues.
Thursday, July 26, 2007
New Open Source License: Common Public Attribution License
I am proud to announce that the Socialtext Common Public Attribution License was approved by the OSI board on Wednesday morning. It will be the only OSI approved license that includes a provision enabling attribution and "filling" the ASP hole. The license is designed as a template for use by other companies and Socialtext and I believe that this license will fill an important need for open source companies.
The attribution provision was quite controversial and the license went through many drafts in order to satisfy those concerns. Many open source application companies have felt the need for an attribution notice: more than fifteen have adopted the MPL + attribution first used by SugarCRM, so the approval of this license is quite important to them. The participants on License Discuss at OSI were very opposed to the initial proposal on attribution. However, we and Socialtext worked with the members of License Discuss, the OSI Board as well as other members of the community to modify the provisions to meet these concerns. The real hero of the story is Ross Mayfield, CEO of Socialtext, whose patience and persistence during the eight month process were critical to its success. http://www.socialtext.com/node/267.
The license is based on the Mozilla Public License Version 1.1 but Sections 14 and 15 have been added to provide for limited attribution for the Original Developer and cover use of software over a computer network. The attribution provision in Section 14 permits an attribution notice with the following information: copyright notice, short phrase (10 words), graphic image and URL. The network use provision in Section 15 is based on the "external deployment" approach (rather than the Affero approach) and requires that a company that makes the software available over a network (such as providing service as an ASP) provide the source code to persons who use such application over the network.
I realize that I may be biased, but I encourage companies to consider using the CPAL.
The attribution provision was quite controversial and the license went through many drafts in order to satisfy those concerns. Many open source application companies have felt the need for an attribution notice: more than fifteen have adopted the MPL + attribution first used by SugarCRM, so the approval of this license is quite important to them. The participants on License Discuss at OSI were very opposed to the initial proposal on attribution. However, we and Socialtext worked with the members of License Discuss, the OSI Board as well as other members of the community to modify the provisions to meet these concerns. The real hero of the story is Ross Mayfield, CEO of Socialtext, whose patience and persistence during the eight month process were critical to its success. http://www.socialtext.com/node/267.
The license is based on the Mozilla Public License Version 1.1 but Sections 14 and 15 have been added to provide for limited attribution for the Original Developer and cover use of software over a computer network. The attribution provision in Section 14 permits an attribution notice with the following information: copyright notice, short phrase (10 words), graphic image and URL. The network use provision in Section 15 is based on the "external deployment" approach (rather than the Affero approach) and requires that a company that makes the software available over a network (such as providing service as an ASP) provide the source code to persons who use such application over the network.
I realize that I may be biased, but I encourage companies to consider using the CPAL.
Open Source: Japan
If I ever had any doubts about the international interest in Open Source, they were laid to rest last week. I was visiting clients in Tokyo (missed the typhoon, but was there for the earthquakes) and asked a friend if the Licensing Executive Society of Japan would be interested in a presentation on the new General Public License Version 3. Even though they only had a week's advance notice, they had 30 lawyers show up for the two hour presentation. Given lawyer's hectic schedules, such a turn out on such short notice indicates a strong interest. We had a wide variety of participants ranging from inhouse counsel at major companies to private lawyers to law professors. It was a very interesting and enlightening experience.
Sunday, July 8, 2007
Adoption of General Public License Version 3: Keeping Track
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.
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.
Monday, July 2, 2007
General Public License Version 3: A Legal View
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.
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.
Subscribe to:
Posts (Atom)