Notice

Just a reminder, these posts are not legal advice. This site is the personal blog of Mark Radcliffe and the opinions expressed are those of Mark Radcliffe and not those of his clients, DLA Piper or the clients of DLA Piper.

About Me:

Mark Radcliffe

I have been practicing law in Silicon Valley for over thirty years assisting startups and global companies develop and market innovative products and services. I have participated in multiple business cyles in Silicon Valley from hardware to software to internet to cloud. My projects have included developing the dual licensing business model for open source startup, developing the original domain dispute resolution policy for NSI and assisting Sun in open sourcing the Solaris operating system. Recently, I served on the US Japan Innovation and Entrepreneurship Council (one of ten members) to develop a plan to encourage the innovation in Japan and the United States. I have been working with the same attorneys since 1986 although we have merged with other law firms several times. I am now a partner at DLA Piper, a (relatively) new global law firm formed in 2005 from the merger of three law firms. The firm now has 4200 lawyers in 31 countries and 77 cities. My experience in corporate securities (particularly venture capital) and intellectual property enables me to assist companies structure the financing and intellectual property strategy for developing ane exploiting a new product or service. I and my team work with fifty startups at one time as well as Global Fortune 100. I have been fortunate enough to work with companies in software, cloud computing, semiconductor, health care IT and Web 2.0.

The recent Android Builder’s Summit in San Francisco demonstrated the breadth of products using Android and the dynamic nature of the operating system. In her keynote, Christy Wyatt of Motorola described the challenges of managing the launch of 700 products based on Android in countries around the world.  She was followed by Mark Charlebois (Director of Open Source Strategy at Qualcomm Innovation Center) and he predicted that their Android releases would grow from 241 in 2010 to more than 365 in 2011. 

Karim Yaghmour of Opersys provided a great overview of Android and its critical subsystems http://www.opersys.com/blog/abs-march2011. However, his presentation brought home the challenges of managing Android: he mentioned in passing that he was unhappy with the performance of the Android Toolbox, the component which Google substituted for BusyBox for Toolbox. He regularly substitutes BusyBox for Toolbox (one Android site had more than 25,000 downloads of BusyBox). BusyBox is described as follows;           

a software application that provides many standard Unix tools, much like the larger (but more capable) GNU Core Utilities. BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. It has been self-dubbed “The Swiss Army Knife of Embedded Linux”. 

According to Black Duck, Android Toolbox is a collection of 66 files, 52 are under the Apache 2.0 license and 14 are under BSD.  Both the Apache 2.0 and BSD licenses are very permissive. However, BusyBox is licensed under the GPLv2, a copyleft license,  which has very different and  much more significant obligations, particularly the obligation to make the source code available either with the object code or through a written promise. More importantly, the license to BusyBox is the most actively enforced license in open source. The Software Freedom Conservancy and the Software Freedom Law Center have filed at least seven lawsuits (with many other disputes settled with ligitation) to enforce the GPLv2 license on BusyBox. Last year, they won $90,000 in damages from Best Buy.  

Thus, a reasonable technical decision can dramatically change the obligations of the distributor. Since the GPLv2 is a “conditional” license, the failure to comply with these terms means that the license terminates automatically without a cure period. Thus, the distributor would be a copyright infringer.  Since products including Android are frequently mass market products, the consequences could be significant liability arising from millions of unlicensed units. This reality demonstrates once again the need for careful management of the use of Android and clear communication between the developers and the relevant counsel.

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.

Post tags:

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.

Post tags:

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.

Post tags: