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.
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
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
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!
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.
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.
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.