Thursday, November 8, 2007

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.