The year 2007 has been the most active year for legal developments in the history of free and open source (“FOSS”). In fact, you would have been hard pressed in past years to enumerate even five important legal developments. However 2007 permits the creation of a traditional “top ten” list. My list of the top ten FOSS legal developments in 2007 follows:
1. Publication of GPLv3. The GPLv2 continues to be the most widely used FOSS license, yet the law relating to software has developed significantly since the publication of the original publication of the GPLv2 in 1991. The first revision of the GPLv2 had a number of drafts over an 18 month period. However the new GPLv3 license is much more comprehensive than GPLv2 and addresses the new issues which have arisen in software law in the last 15 years.
2. SCO’s Attack on Linux Collapses. SCO filed lawsuits claiming that Linux infringed SCO’s copyrights in UNIX. These suits suffered a fatal blow when the court in the Novell litigation found that SCO did not own the copyrights in UNIX. The ownership of the copyrights is essential to prosecute cases for copyright infringement. The melt down of SCO’s strategy was complete when it filed for bankruptcy soon after this loss.
3. First Legal Opinion on Enforcing a FOSS License. In August, the district court in San Francisco surprised many lawyers by ruling that the remedies for breach of the Artistic License were in contract, not copyright. Most lawyers believe that the failure to comply with the major terms of an open source license means that the licensee is a copyright infringer and, thus, can obtain “injunctive relief" (which means that the court orders a party to cease their violation). On the other hand, if the remedy is limited to contract remedies, then the standard remedy would be limited to monetary damages. Such damages are of limited value to open source licensors. The district court decision has been appealed.
4. First US Lawsuit to Enforce GPLv2. The Software Freedom Law Center filed the first lawsuit to enforce the GPL for the BusyBox software in August. Subsequently, it filed three other lawsuits. Although the first three lawsuits were against small companies, the most recent lawsuit was against Verizon. These lawsuits represent a new approach for the SFLC which, in the past, has preferred negotiation to litigation. SFLC has settled two of the lawsuits. Each of the settlements has required that the defendants pay damages, another new development. These suits may be the first of many.
5. First Patent Infringement Lawsuit by Patent Trolls against FOSS Vendors. IP Innovation LLC (and Technology Licensing Corporation) filed suit against Red Hat and Novell in what may be the first volley in a patent war against a FOSS vendor. Acacia is a well known patent troll which has been buying patents for some time and works through multiple subsidiaries. The FOSS industry provides a tempting target because of its rapid growth. These suits could slow the expansion of FOSS because many potential licensees express concern about potential liability for infringement of third party rights by FOSS.
6. First Patent Lawsuit by a Commercial Competitor against a FOSS Vendor. Network Appliances, Inc. (“NetApps”) sued Sun Microsystems, Inc. (“Sun”) for patent infringement by Sun’s ZFS file system in its Solaris operating system. The ZFS file system posed a challenge to NetApps products because it permits the connection of less expensive storage devices to the operating system.
7. Microsoft Obtains Approval of Two Licenses by OSI. Microsoft Corporation continues its schizophrenic approach to FOSS by simultaneously asserting that the Linux operating system violates Microsoft’s patents and submitting two licenses for approval by OSI. In October, the OSI Board approved the Microsoft Public License (Ms-PL) and the Microsoft Reciprocal License (Ms-RL) as consistent with the Open Source Definition.
8. German Court Finds that Skype Violates GPLv2 The enforcement of the GPLv2 in Germany continues with a Munich court finding that Skype had violated GPLv2 by not including the source code with the binary version of the software (instead, Skype had included a “flyer” with a URL describing where to find the source code version). The suit was brought by Harald Welte, who has been the plaintiff in virtually all of the German enforcement actions for GPLv2. Harald runs gpl-violations.org, an organization which he founded to track down and prosecute violators of the GPL.
9. New License Options. Two of the most controversial issues in FOSS licensing, network use and attribution, were addressed in new licenses adopted this year. A “network use” provision imposes a requirement that when a program makes functions available through a computer network, the user may obtain the source code of the program. Essentially, it extends the trigger requiring providing a copy of the source code from “distribution” of the object code (as required under the GPLv2) to include making the functions available over a computer network. An “attribution” provision requires that certain phrases or images referring to the developing company be included in the program. This provision was very controversial on the License Discuss email list for OSI. The Free Software Foundation published the Affero General Public License in the fall which expanded the scope of the GPLv3 to include a “network use” provision. A limited form of attribution was included in the GPLv3. And OSI approved the Common Public Attribution License which included both the “network use” and “attribution” provisions.
10. Creation of Linux Foundation. The Open Source Development Labs and the Free Standards Group merged to form the Linux Foundation. The FOSS industry is unusual because of the extent to which it depends on non profit entities for guidance. These entities include the OSI, Free Software Foundation, Mozilla Foundation, Apache Foundation and Eclipse Foundation. This merger provides a much stronger platform to promote Linux and open standards.
Wednesday, December 19, 2007
Monday, December 17, 2007
BusyBox Settles Second GPL Suit
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.
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.
Labels:
busybox,
general public license,
software licensing,
xt
Monday, December 10, 2007
Paying Developers: A New Way to Develop Community
In Bangalore at FOSS.IN, Simon Phipps, Sun Microsystem's open source guru, announced on Friday that Sun will be establishing an "award program" to support innnovation and advance open source development relating to its products. He describes the program as providing a "substantial prize purse". The fund will be divided into six chunks of about $175,000 each — war chests to ignite original ideas in six streams or communities working on Sun-created open environments: OpenSolaris, GlassFish, NetBeans, OpenJDK, OpenOffice and OpenSparc. http://www.hindu.com/2007/12/08/stories/2007120854141800.htm
This announcement deals with one of the most fundamental questions in the FOSS industry: will the future of FOSS be constrained by the limited number of programmers who are willing to work for free? This issue translates into the more immediate question for FOSS companies of how to motivate FOSS developers to become part of their community given the proliferation of FOSS companies and projects. Many industry commentators have emphasized that developing a robust community is critical to the success of a company depending on an open source business model. This announcement may mark the rise of a new approach to community development.
This announcement deals with one of the most fundamental questions in the FOSS industry: will the future of FOSS be constrained by the limited number of programmers who are willing to work for free? This issue translates into the more immediate question for FOSS companies of how to motivate FOSS developers to become part of their community given the proliferation of FOSS companies and projects. Many industry commentators have emphasized that developing a robust community is critical to the success of a company depending on an open source business model. This announcement may mark the rise of a new approach to community development.
Sunday, December 9, 2007
BusyBox Files Lawsuit against Verizon to Enforce the General Public License
On Thursday, BusyBox, through the Software Freedom Law Center ("SFLC") filed a new lawsuit to enforce the General Public License ("GPL"). The lawsuit claims that Verizon used BusyBox software in one of its routers without complying with the GPL. This lawsuit is the fourth filed by the SFLC in the last two months and confirms that the trend that I mentioned in my earlier post http://lawandlifesiliconvalley.blogspot.com/2007/11/software-freedom-law-center-files.html. SFLC appears to be taking a much more aggressive approach by filing lawsuits within weeks of the original demand letter. In this case, SFLC states that they gave notice to Verizon on November 16 and filed suit on December 5. The allegations in this suit are similar to the earlier complaints. However, this lawsuit is the first against a company of substantial size.
Companies should review their use of BusyBox software which is the basis for these claims and should be prepared to respond quickly to demand letters from the SFLC.
Companies should review their use of BusyBox software which is the basis for these claims and should be prepared to respond quickly to demand letters from the SFLC.
Sunday, November 25, 2007
Software Freedom Law Center Files Second Round of Enforcement Actions for BusyBox Software
The Software Freedom Law Center ("SFLC") has filed a second round of lawsuits to enforce the General Public License ("GPL") for BusyBox software last week. The suits were filed against two different companies: High Gain Antennas, LLC ("High Gain") and Xterasys Corporation ("Xterasys"). As in the Monsoon Media case, the suits are based on the failure to make the source code of the BusyBox software available as required under the GPL.
As I mentioned in my earlier post, the SFLC is much more willing to bring a lawsuit than in the past http://lawandlifesiliconvalley.blogspot.com/2007/11/monsoon-media-lessons-for-foss.html. In past years, SFLC stated that they were involved in up to 50 enforcement actions a year, but never filed a lawsuit. In some cases, they also appear to be moving very rapidly to file such lawsuits: the suit against High Gain was filed on November 20 after an unsatisfactory response from High Gain on November 19 (however, according to the complaint, High Gain had received notice of the requirement to provide source code in August 2006 from a third party, but the source of this notice is not made clear). On the other hand, the initial notice by the SFLC to Xterasys was on May 23, 2007 and Xterasys responded on the same day. The last contact was on May 24, 2007 when SFLC reminded Xterasys to keep them informed of the results of the investigation. However, Xterasys did not further communicate with SFLC.
SLFC consistently takes the position that the failure to comply with all of the terms of the GPL "terminates" the permission in the license and the licensee becomes a copyright infringer. However as in Jacobsen, a court might decide that the failure to provide the source code is a breach of contract (which has a different set of remedies, generally limited to monetary damages) rather than copyright infringement http://lawandlifesiliconvalley.blogspot.com/2007/08/new-open-source-legal-decision-jacobsen.html. Please note that the SFLC and the Free Software Foundation have consistently taken the position that the GPL is not a contract, but I believe that this position is difficult to defend. In any case, I believe that the Jacobsen decision is wrong and the GPL is a very different license from the Artistic License. Yet this question of remedies remains open and depends on the exact terms of the license.
The clear lesson from these suits is to respond quickly if SLFC contacts your company and try to resolve the issue promptly.
As I mentioned in my earlier post, the SFLC is much more willing to bring a lawsuit than in the past http://lawandlifesiliconvalley.blogspot.com/2007/11/monsoon-media-lessons-for-foss.html. In past years, SFLC stated that they were involved in up to 50 enforcement actions a year, but never filed a lawsuit. In some cases, they also appear to be moving very rapidly to file such lawsuits: the suit against High Gain was filed on November 20 after an unsatisfactory response from High Gain on November 19 (however, according to the complaint, High Gain had received notice of the requirement to provide source code in August 2006 from a third party, but the source of this notice is not made clear). On the other hand, the initial notice by the SFLC to Xterasys was on May 23, 2007 and Xterasys responded on the same day. The last contact was on May 24, 2007 when SFLC reminded Xterasys to keep them informed of the results of the investigation. However, Xterasys did not further communicate with SFLC.
SLFC consistently takes the position that the failure to comply with all of the terms of the GPL "terminates" the permission in the license and the licensee becomes a copyright infringer. However as in Jacobsen, a court might decide that the failure to provide the source code is a breach of contract (which has a different set of remedies, generally limited to monetary damages) rather than copyright infringement http://lawandlifesiliconvalley.blogspot.com/2007/08/new-open-source-legal-decision-jacobsen.html. Please note that the SFLC and the Free Software Foundation have consistently taken the position that the GPL is not a contract, but I believe that this position is difficult to defend. In any case, I believe that the Jacobsen decision is wrong and the GPL is a very different license from the Artistic License. Yet this question of remedies remains open and depends on the exact terms of the license.
The clear lesson from these suits is to respond quickly if SLFC contacts your company and try to resolve the issue promptly.
Tuesday, November 20, 2007
Free Software Foundation Announces Final Affero General Public License
One of the most contentious issues during the drafting of the General Public License Version 3 was whether to add an obligation to make source code available for software licensed under GPLv3 if it was provided over a network. The GPLv2 only required source code to be provided upon the "distribution" of the program (although the Affero project, with the permission of the Free Software Foundation, developed a version of GPLv2 which included a requirement to make the source code available to any user of a network, rather than just upon distribution). With the rise of service providers such as Google, open source software was being modified and used, but the modifications were not being made available to the community.
Ultimately, the FSF decided not to include such a requirement in GPLv3 but provide this option through an alternative license, the Affero GPL. It also made the GPLv3 "compatible" with the Affero GPL in Section 13 of the GPLv3. This compatability is "hardwired" rather than a natural result of changes to the GPLv3 which permitted compatability with Apache. And the compatability is "one way": GPLv3 licensed code can be linked with or combined with works licensed under the Affero GPL, but works licensed under the Affero GPL cannot be licensed under the GPLv3.
The final version of the Affero GPL is not surprising. It includes the "network use" language which requires that the Corresponding Source of the Affero GPL licensed code (as well as any GPLv3 licensed code which is incorporated into it) be made available to any network user. The critical provision is as follows:
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Notwithstanding any other provision of this License, you have permission
to link or combine any covered work with a work licensed under version 3
of the GNU General Public License into a single combined work, and to
convey the resulting work. The terms of this License will continue to
apply to the part which is the covered work, but the work with which it is
combined will remain governed by version 3 of the GNU General Public
License.
The Affero GPL is an important option for companies or projects that are concerned that they will be used to provide services, but the service providers will not provide their modifications to the community. This issue can be important for a company: I worked with Socialtext to develop the Common Public Attribution License which included a network use provision and a very explicit attribution provision. This option may become more popular as more software is provided as a service. I still believe that the GPLv3 will continue to be much more widely used than the Affero GPL. In fact, I have a small bet with Fabrizio Capobianco, CEO of Funambol, that GPLv3 will continue to beat out Affero GPL over the next five years, so keep adopting GPLv3!
Ultimately, the FSF decided not to include such a requirement in GPLv3 but provide this option through an alternative license, the Affero GPL. It also made the GPLv3 "compatible" with the Affero GPL in Section 13 of the GPLv3. This compatability is "hardwired" rather than a natural result of changes to the GPLv3 which permitted compatability with Apache. And the compatability is "one way": GPLv3 licensed code can be linked with or combined with works licensed under the Affero GPL, but works licensed under the Affero GPL cannot be licensed under the GPLv3.
The final version of the Affero GPL is not surprising. It includes the "network use" language which requires that the Corresponding Source of the Affero GPL licensed code (as well as any GPLv3 licensed code which is incorporated into it) be made available to any network user. The critical provision is as follows:
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Notwithstanding any other provision of this License, you have permission
to link or combine any covered work with a work licensed under version 3
of the GNU General Public License into a single combined work, and to
convey the resulting work. The terms of this License will continue to
apply to the part which is the covered work, but the work with which it is
combined will remain governed by version 3 of the GNU General Public
License.
The Affero GPL is an important option for companies or projects that are concerned that they will be used to provide services, but the service providers will not provide their modifications to the community. This issue can be important for a company: I worked with Socialtext to develop the Common Public Attribution License which included a network use provision and a very explicit attribution provision. This option may become more popular as more software is provided as a service. I still believe that the GPLv3 will continue to be much more widely used than the Affero GPL. In fact, I have a small bet with Fabrizio Capobianco, CEO of Funambol, that GPLv3 will continue to beat out Affero GPL over the next five years, so keep adopting GPLv3!
Thursday, November 15, 2007
Oracle Announces 1,500 Customers for Its Unbreakable Linux
One of the concerns about the open source business model has been the risk that third parties provide support for a company's product and deprive the company of a significant revenue stream. This concern was crystallized by the Oracle announcement last year that they would support the Red Hat version of Linux at half of Red Hat's price. However, after six months, Oracle had announced only 26 customers. Many companies sighed with relief. However, Oracle recently announced that they had 1500 customers. For more information, see the story: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9046978. Oracle has acquired some significant clients such as Yahoo, Activision and IHOP. Yet some of these clients are clearly "testing" the service and working with both companies. It will be very interesting to see the numbers after two years (particularly renewals). Yet the Oracle/Red Hat competition may be less relevant for products other than Linux because Linux has a large community of developers which can be hired by Oracle or others who want to provide support services. No such community exists for many open source products. Consequently, this announcement is interesting for the Linux community but may have little relevance outside of the Linux market.
Thursday, November 8, 2007
New Guide to GPLv3
The Free Software Foundation's Compliance Lab has published a new guide to the GPLv3
http://www.fsf.org/licensing/licenses/quick-guide-gplv3.html. This Guide is designed for developers who are not familiar with GPLv3. If you have read the GPLv3 or the FAQs, you will not need this summary. However, if you are new to the GPLv3 and need a narrative summary of major terms and the purpose behind them, this guide will be quite useful.
I have four suggestions:
1. The discussion of Tivoization should clarify that this provision is limited to "User Products." The summary appears to make the requirement apply to all products.
2. A discussion of the limits of permitted modifications under Section 7 would be useful;
3. The application of attribution through the Appropriate Legal Notices section is complicated and an explanation would be useful; and
4. A cross reference to the relevant provisions in the GPLv3 would be helpful.
http://www.fsf.org/licensing/licenses/quick-guide-gplv3.html. This Guide is designed for developers who are not familiar with GPLv3. If you have read the GPLv3 or the FAQs, you will not need this summary. However, if you are new to the GPLv3 and need a narrative summary of major terms and the purpose behind them, this guide will be quite useful.
I have four suggestions:
1. The discussion of Tivoization should clarify that this provision is limited to "User Products." The summary appears to make the requirement apply to all products.
2. A discussion of the limits of permitted modifications under Section 7 would be useful;
3. The application of attribution through the Appropriate Legal Notices section is complicated and an explanation would be useful; and
4. A cross reference to the relevant provisions in the GPLv3 would be helpful.
Monsoon Media: Lessons for FOSS Management
I have been traveling so I have not been able to comment on the recent Monsoon Media settlement (if you are in London and like Indian food, I highly recommend Quilon at 41 Buckingham Gate, SW1). The recent settlement in the Monsoon Media case has several important lessons for managing FOSS software. Everyone, including Monsoon Media, appears to agree that they violated the GPLv2 by not making the source code of the BusyBox software available as required under the GPLv2. It is less clear why Monsoon Media did not respond to the requests of the BusyBox authors and the SFLC to come into compliance. According to the complaint, they simply admitted that they were not distributing source code of BusyBox as required by the GPLv2. Although the settlement of the case means that we will not have a court’s view on the enforceability of the GPLv2 and the appropriate remedy for breach, it is not surprising.
The settlement was described as follows: As a result of the plaintiffs agreeing to dismiss the lawsuit and reinstate Monsoon Multimedia's rights to distribute BusyBox under the GPL, Monsoon Multimedia has agreed to appoint an Open Source Compliance Officer within its organization to monitor and ensure GPL compliance, to publish the source code for the version of BusyBox it previously distributed on its Web site, and to undertake substantial efforts to notify previous recipients of BusyBox from Monsoon Multimedia of their rights to the software under the GPL. The settlement also includes an undisclosed amount of financial consideration paid by Monsoon Multimedia to the plaintiffs.
As I mentioned in an earlier post, this complaint was the first suit filed about the enforceability of the GPLv2 in the United States. In the past, the SFLC has sought compliance rather than damages http://emoglen.law.columbia.edu/publications/lu-13.html. However, in this case, Dan Ravicher of the SFLC noted (despite Monsoon Media’s public statements about coming into compliance): "Simply coming into compliance now is not sufficient to settle the matter, because that would mean anyone can violate the license until caught, because the only punishment would be to come into compliance." This statement suggests a new more aggressive approach on financially penalizing violators of the GPLv2.
The case also recognizes an often overlooked problem for GPLv2 licensees: if you are out of compliance with the GPLv2, you do not have a license and, thus, are likely to be liable for both copyright infringement and breach of license. This “termination” can be particularly problematic if you have significant amounts of product already distributed and, thus, “unlicensed”.
The dispute moved very swiftly: according to the complaint, Monsoon Media was first informed of their violation on August 28, 2007 (and admitted to their failure to supply source code on September 5, 2007), contacted again by the SFLC on September 11, 2007 and the suit was filed on September 20, 2007.
The lessons from this suit are as follows:
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.
The settlement was described as follows: As a result of the plaintiffs agreeing to dismiss the lawsuit and reinstate Monsoon Multimedia's rights to distribute BusyBox under the GPL, Monsoon Multimedia has agreed to appoint an Open Source Compliance Officer within its organization to monitor and ensure GPL compliance, to publish the source code for the version of BusyBox it previously distributed on its Web site, and to undertake substantial efforts to notify previous recipients of BusyBox from Monsoon Multimedia of their rights to the software under the GPL. The settlement also includes an undisclosed amount of financial consideration paid by Monsoon Multimedia to the plaintiffs.
As I mentioned in an earlier post, this complaint was the first suit filed about the enforceability of the GPLv2 in the United States. In the past, the SFLC has sought compliance rather than damages http://emoglen.law.columbia.edu/publications/lu-13.html. However, in this case, Dan Ravicher of the SFLC noted (despite Monsoon Media’s public statements about coming into compliance): "Simply coming into compliance now is not sufficient to settle the matter, because that would mean anyone can violate the license until caught, because the only punishment would be to come into compliance." This statement suggests a new more aggressive approach on financially penalizing violators of the GPLv2.
The case also recognizes an often overlooked problem for GPLv2 licensees: if you are out of compliance with the GPLv2, you do not have a license and, thus, are likely to be liable for both copyright infringement and breach of license. This “termination” can be particularly problematic if you have significant amounts of product already distributed and, thus, “unlicensed”.
The dispute moved very swiftly: according to the complaint, Monsoon Media was first informed of their violation on August 28, 2007 (and admitted to their failure to supply source code on September 5, 2007), contacted again by the SFLC on September 11, 2007 and the suit was filed on September 20, 2007.
The lessons from this suit are as follows:
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.
Friday, October 19, 2007
Ballmer Announced that Microsoft Could Acquire Companies based on Open Source Products: Don't Break Out the Champagne
Yesterday, during an onstage interview at the San Francisco Web 2.0 Summit, Ballmer stated: "Microsoft will continue to invest in buying technology, products and market share. We'll buy 20 companies a year consistently for the next five years for anywhere between 50 million and 1 billion bucks. We will buy smaller companies. We will buy smaller companies that make some use of open source software. We don't want to discourage people who would talk with us just because they do some open source." This statement is change from Ballmer's long held hostility and dismissive attitude towards FOSS companies. Based on my experience in selling companies to Microsoft, it is a big change. The last time I sold a company to Microsoft (several years ago now), they initially wanted to remove all open source components in the product although they eventually settled for leaving in some open source components because of the difficulty of rewriting them. However, the FOSS community should not break out the champagne: Ballmer is simply acknowledging the reality that virtually all companies, certainly Web 2.0 companies, are built on FOSS. The statement is the business equivalent of stating that Microsoft will buy companies that are subject to the law of gravity.
Yet in an odd way it is consistant with Ballmer's recent demands that Linux users pay Microsoft royalties. I was discussing these statements with Karen Copenhaver, counsel for the Linux Foundation and one of the most thoughtful lawyers in the open source market, at the SFLC seminar last week and she made the point that Ballmer's statements about Linux are an acknowledgement that Linux is a real competitor to Microsoft. This acknowledgement is also consistant with Microsoft's other moves to engage more broadly with the FOSS community such as their recent successful application to the OSI to approve some of their licenses.
However, the FOSS community should celebrate Microsoft's acknowledgement, however indirect, that FOSS is a real competitor.
Yet in an odd way it is consistant with Ballmer's recent demands that Linux users pay Microsoft royalties. I was discussing these statements with Karen Copenhaver, counsel for the Linux Foundation and one of the most thoughtful lawyers in the open source market, at the SFLC seminar last week and she made the point that Ballmer's statements about Linux are an acknowledgement that Linux is a real competitor to Microsoft. This acknowledgement is also consistant with Microsoft's other moves to engage more broadly with the FOSS community such as their recent successful application to the OSI to approve some of their licenses.
However, the FOSS community should celebrate Microsoft's acknowledgement, however indirect, that FOSS is a real competitor.
Friday, October 12, 2007
Patent Troll Fires First Volley at Open Source
The recent lawsuit in the Eastern District of Texas by IP Innovation LLC (and Technology Licensing Corporation) against Red Hat and Novell may be the first volley in a patent war against open source software. Acacia is a well known patent troll which has been buying patents for some time and works through multiple subsidiaries. http://trolltracker.blogspot.com/2007/10/acacia-targets-linux-in-new-lawsuit.html. Acacia describes itself as follows: The Acacia Technologies group develops, acquires, and licenses patented technologies. Acacia controls 81 patent portfolios covering technologies used in a wide variety of industries including audio/video enhancement & synchronization, broadcast data retrieval, computer memory cache coherency, credit card fraud protection, database management, data encryption & product activation, digital media transmission (DMT®), digital video production, dynamic manufacturing modeling, enhanced Internet navigation, image resolution enhancement, interactive data sharing, interactive television, laptop docking station connectivity, microprocessor enhancement, multi-dimensional bar codes, resource scheduling, spreadsheet automation, and user activated Internet advertising.
Although I and many attorneys in the open source industry have long been concerned about patent challenges to open source companies, this case appears to be the first by patent trolls against an open source licensor. The open source industry provides a tempting target because of its rapid growth. This morning, Eben Moglen at the Software Freedow Law Center Seminar on FOSS issues noted that Brad Bunnell of Microsoft joined Acacia on October 1 . According to news reports, Brad spent sixteen years at Microsoft at a number of positions which included General Manager, Intellectual Property Licensing. http://biz.yahoo.com/bw/071001/20071001005590.html?.v=1
Eben raises the intriguing question about whether these incidents are related. Given the time that it takes to prepare a patent lawsuit, Brad's hiring probably did not effect the filing of this lawsuit. However the hiring may indicate the addition of a new business line for Acacia: suits against open source companies. Steve Ballmer's recent comments about Red Hat's obligation to pay Microsoft for alleged use of its patents makes this lawsuit and the timing of the move interesting.
The seminar was a very helpful overview of the FOSS industry and the next set of legal challenges now that GPLv3 has been published and SCO has been defeated. In the afternoon, the Software Freedom Law Center provided an overview of the legal issues facing FOSS development from establishing contribution policies to entities for projects to patent issues for FOSS projects. The Software Freedom Law Center will be making some final edits and be posting it on their website in the next ten days. You should check their website: http://www.softwarefreedom.org/.
Although I and many attorneys in the open source industry have long been concerned about patent challenges to open source companies, this case appears to be the first by patent trolls against an open source licensor. The open source industry provides a tempting target because of its rapid growth. This morning, Eben Moglen at the Software Freedow Law Center Seminar on FOSS issues noted that Brad Bunnell of Microsoft joined Acacia on October 1 . According to news reports, Brad spent sixteen years at Microsoft at a number of positions which included General Manager, Intellectual Property Licensing. http://biz.yahoo.com/bw/071001/20071001005590.html?.v=1
Eben raises the intriguing question about whether these incidents are related. Given the time that it takes to prepare a patent lawsuit, Brad's hiring probably did not effect the filing of this lawsuit. However the hiring may indicate the addition of a new business line for Acacia: suits against open source companies. Steve Ballmer's recent comments about Red Hat's obligation to pay Microsoft for alleged use of its patents makes this lawsuit and the timing of the move interesting.
The seminar was a very helpful overview of the FOSS industry and the next set of legal challenges now that GPLv3 has been published and SCO has been defeated. In the afternoon, the Software Freedom Law Center provided an overview of the legal issues facing FOSS development from establishing contribution policies to entities for projects to patent issues for FOSS projects. The Software Freedom Law Center will be making some final edits and be posting it on their website in the next ten days. You should check their website: http://www.softwarefreedom.org/.
Thursday, September 27, 2007
Open Source: Paradigm Shift
For some time, I have been referring to the open source business model as a "paradigm shift" in the way software is developed and distributed. I use the term "paradigm shift" reluctantly because it has been so overused. However, I think that it is the best term for this change and I use paradigm shift in its original sense of a fundamental change in the industry. I am delighted to report that I now have confirmation of this view from Gartner's recent report: Gartner declared open-source software "the biggest disruptor the software industry [Gartner] has ever seen and [Gartner] postulated it will eventually result in cheaper software and new business models." They stated that open-source products accounted for a 13 percent share of the $92.7 billion software market in 2006, but should account for 27 percent of the market in 2011 when revenue is expected to be $169.2 billion, according to Gartner research. http://www.eweek.com/article2/0,1895,2186932,00.asp
Thursday, September 20, 2007
The Software Freedom Law Center Files First Enforcement Action for General Public License
On September 20, the Software Freedom Law Center has filed the first lawsuit to enforce the General Public License version 2 in the United States ("GPLv2"). The GPLv2 continues to be the most widely used open source license: more than 65% of the projects on SourceForge use it.
The plaintiffs, Erik Andersen and Rob Landley, sued Monsoon Multimedia, Inc. for copyright infringement of the BusyBox software in the Southern District of New York. The complaint can be found at http://www.softwarefreedom.org/news/2007/sep/20/busybox/complaint.pdf. The plaintiffs allege that Monsoon Multimedia distributed their program as part of their firmware, but did not make the source code available.
This case is very important because it will establish what type of remedies (either contract or copyright) are available to licensors for breach of the GPLv2. The Free Software Foundation has consistantly taken the position that the GPLv2 is a copyright license rather than a contract and that the failure to comply with its terms results in copyright infringement.
I don't agree with the view that the GPLv2 is not a contract (see below for the significance of this distinction), because the GPLv2 includes many provisions such as a disclaimer of warranty which are characteristic of "contracts" for the sale of goods under Article 2 of the Uniform Commercial Code. This distinction could be important as illustrated in the recent decision in Jacobsen (see above) which provided that the remedy for the breach of the Artistic License was in contract (i.e. monetary damages) and not copyright infringement. The major difference in remedies is that contract remedies are generally monetary damages, but copyright remedies are generally injunctive relief (the court orders a party to do something) as well as monetary damages. Clearly, open source licensors would prefer to obtain injunctive relief to require the licensee to comply with the terms of the license.
However, the court's decision on remedies will not turn solely on whether the GPLv2 is a copyright license or a contract: even if the court finds that the GPLv2 is a "contract", it could also find that the breach of the GPLv2 results in copyright infringement (see the Jacobsen case blog for an explanation of this issue). The GPLv2 is very different from the Artistic License so the reasoning in the Jacobsen case may not apply. However, courts are very influenced by the decisions of other courts in new areas which is why the wrong decision in the Jacobsen case is so important.
Stay tuned, this case will be very important for the future of open source software.
The plaintiffs, Erik Andersen and Rob Landley, sued Monsoon Multimedia, Inc. for copyright infringement of the BusyBox software in the Southern District of New York. The complaint can be found at http://www.softwarefreedom.org/news/2007/sep/20/busybox/complaint.pdf. The plaintiffs allege that Monsoon Multimedia distributed their program as part of their firmware, but did not make the source code available.
This case is very important because it will establish what type of remedies (either contract or copyright) are available to licensors for breach of the GPLv2. The Free Software Foundation has consistantly taken the position that the GPLv2 is a copyright license rather than a contract and that the failure to comply with its terms results in copyright infringement.
I don't agree with the view that the GPLv2 is not a contract (see below for the significance of this distinction), because the GPLv2 includes many provisions such as a disclaimer of warranty which are characteristic of "contracts" for the sale of goods under Article 2 of the Uniform Commercial Code. This distinction could be important as illustrated in the recent decision in Jacobsen (see above) which provided that the remedy for the breach of the Artistic License was in contract (i.e. monetary damages) and not copyright infringement. The major difference in remedies is that contract remedies are generally monetary damages, but copyright remedies are generally injunctive relief (the court orders a party to do something) as well as monetary damages. Clearly, open source licensors would prefer to obtain injunctive relief to require the licensee to comply with the terms of the license.
However, the court's decision on remedies will not turn solely on whether the GPLv2 is a copyright license or a contract: even if the court finds that the GPLv2 is a "contract", it could also find that the breach of the GPLv2 results in copyright infringement (see the Jacobsen case blog for an explanation of this issue). The GPLv2 is very different from the Artistic License so the reasoning in the Jacobsen case may not apply. However, courts are very influenced by the decisions of other courts in new areas which is why the wrong decision in the Jacobsen case is so important.
Stay tuned, this case will be very important for the future of open source software.
Friday, August 24, 2007
Open Source Legal Webinar: An Open Source Overview after the Release of General Public License Version 3
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.
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.
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)