Association of Corporate Counsel (ACC)

Welcome back Mr Badertscher

Practical strategies for developing open source compliance programs: why compliance (increasingly) matters

The legal risks of open source software need not be any greater than the legal risks of proprietary software — if you pay proper attention and take action.    

It has become increasingly unrealistic for any organization, regardless of industry, to avoid the use of open source software. Even organizations that have sought in the past to forbid the use of open source software have found that open source enters their organizations, whether via their own developers or through third party developers and vendors. At the same time, it has also become increasingly unwise for organizations not to consider the use of open source software on an equal plane with proprietary software. Most companies, particularly those in the computer software and information technology industries, need look no further than their nearest competitors to find that other companies are benefiting not only from the use of open source software but from the development and release of software under open source licenses as well.

As open source software continues to assume ever more prominent commercial roles, the legal scrutiny around open source software has likewise increased. In much the same way that the legal activity around proprietary software increased throughout the 1980s and 1990s as the software industry grew to prominence, so too is the open source legal landscape rapidly evolving as the commercial use of open source continues to expand.

This evolution has made many risks, once viewed as only hypothetical possibilities, into far more concrete realities. These realities have prompted many companies to shift from asking why they should be concerned with open source compliance and legal issues to why they should not be concerned, and to begin treating the legal issues surrounding open source software on par with the way they treat the legal issues surrounding proprietary software. These realities have also caused those companies not taking these steps on their own terms to face up to the increasingly real possibility of being required to take these steps on terms set by third parties in legal proceedings and other enforcement actions.

Open Source Licenses are Enforceable

  • In much the same way that the proprietary software industry operated for many years under a widely held assumption that “click-through” software license agreements were sufficient to form legally enforceable agreements until the now landmark decision in ProCD v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996) validated this assumption, open source software too has come into widespread commercial use without any formal legal decision validating the enforceability of open source licenses. That is, until the case of Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008).

Jacobsen involves two developers of model railroad software. The case arose when Katzer originally alleged that Jacobsen’s DecoderPro model railroad software infringed U.S. Patent No. 6,530,329 (for a “model train control system”) owned by Katzer. Jacobsen responded to Katzer’s allegations by seeking to invalidate the Katzer patent on the basis of fraud, asserting that significant portions of the software covered by Katzer’s patent were in fact copied line-for-line from Jacobsen’s own software. Jacobsen also brought a counterclaim for copyright infringement on the basis of Katzer’s unauthorized use of Jacobsen’s software.

Jacobsen offers his software under the Artistic License, a seldom-used open source license. In addition to terms regarding the copying, distribution and modification of software subject to the license, the Artistic License requires that all original copyright notices and disclaimers on the software be preserved by the licensee and that any changes made by the licensee be distinguished from the software originally received under the license. Jacobsen’s counterclaim asserted Katzer failed to observe these provisions and that this failure constituted copyright infringement. On this basis, Jacobsen moved for a preliminary injunction to enjoin Katzer from infringing the copyright in DecoderPro.

The District Court denied Jacobsen’s motion, surprising many who had assumed that a failure to comply with an open source license would give rise to a claim for copyright infringement and the right to seek an injunction against the infringement. See, Jacobsen v. Katzer, No. 06-CV-01905 JSW, 2007 WL 2358628 (N.D. Cal. 2007). In its denial, the District Court reasoned that the attribution provisions of the Artistic License constitute separate covenants on the license (thus leading to a conclusion that the attribution provisions are enforceable as a contract and give rise to monetary damages for breach), rather than conditions to the license itself (which would instead result in the attribution provisions being enforceable as a license and in a breach of those provisions giving rise to a claim for copyright infringement and the right to seek an injunction). As a result, while Katzer’s actions constituted violations of these covenants, the court held that the remedy available to Jacobsen included only monetary damages and not injunction.

The Court of Appeals for the Federal Circuit (CAFC), however, vacated the lower court’s decision and remanded the case for further consideration by the district court, finding that the attribution provisions of the Artistic License are clearly intended to create conditions, not covenants. In justifying its finding, the CAFC noted that the attribution provisions of the Artistic License serve to create significant and direct economic benefits to licensors under the Artistic License and thus must be enforced to accomplish the objectives of the licensor. Interpreting the attribution provisions as covenants would, according to the CAFC, render them “meaningless” by foreclosing the ability to enforce those provisions through injunctive relief.

On remand the District Court again refused to grant Jacobsen’s motion, holding that Jacobsen had failed to make the necessary showing of irreparable harm. However, the broadly worded decision of the CAFC stands as a ringing validation of the enforceability not just of the Artistic License but of open source licenses in general and opens the door for open source licensors to seek remedies for copyright infringement for violations of open source licenses. These remedies include not only injunctive relief, but the potential to seek statutory damages and recovery of attorneys’ fees. By confirming that these potentially far more powerful remedies are available to open source licensors, the CAFC’s decision in Jacobsen has the potential to significantly increase the risk of noncompliance for those organizations that have elected not to comply with open source licenses, whether intentionally or, as is more common, though neglect by remaining unaware of the open source software licenses to which they are subject. For these companies, the decision in Jacobsen should stand as ample incentive to adopt and implement a sound open source compliance program. While for those already taking steps to comply with open source licenses, Jacobsen should serve as ample validation of their actions.

OPEN SOURCE LICENSES ARE BEING ENFORCE D

  • For most of the last 10 years, the increase in the commercial significance of open source software occurred without any court case filed to directly enforce the terms of an open source license. The Free Software Foundation and other open source licensors instead relied heavily on socalled “private” out-of-court enforcement actions to police violations of the GNU General Public License (GPL) and other open source licenses, by bringing hundreds of these actions. See, Free Software Foundation Compliance Lab at: http://www.fsf.org/licensing/. These actions existed largely in the shadows, with the parties bringing the actions preferring to reach resolution without filing of any formal legal action. However, from in September 2007 to July 2008, the developers of BusyBox, an open source software toolset commonly used in mobile applications of the Linux operating system and licensed under version 2 of the GPL, broke with this practice and filed complaints in the Southern District of New York against seven separate companies alleging violations of the GPL. While each of the cases was settled out of court before a response was filed, the complaints and the settlements shed new light on open source license compliance actions.

The complaints in the BusyBox cases are all relatively similar. Each alleges a claim for copyright infringement resulting from a failure to make the BusyBox source code available to customers to whom BusyBox had been distributed in violation of the GPL. Each in turn seeks unspecified damages, litigation costs, and an injunction against further distribution of BusyBox by the defendant. The settlements too are substantially similar. In each case, the defendant agreed to comply with the GPL by publishing the source code for the version of Busy- Box it distributed and informing its customers of the availability of the source code. The defendants also agreed to appoint an “Open Source Software Compliance Officer” to monitor open source license compliance, and paid an undisclosed amount to the plaintiffs. See, press releases regarding settlement at: http://www.softwarefreedom.org/news.  

In addition to being the first cases to ever directly enforce an open source license, on at least several levels the BusyBox cases are instructive for how easily they could have potentially been avoided had the defendants instituted relatively basic open source compliance measures. First, the defendants appear to have been relatively unknowing violators of the GPL. In several of the cases, the defendant is thought to have received BusyBox in software provided by a third-party vendor and redistributed it to customers without any actual knowledge of any violation. These defendants did not appear to have performed even basic diligence to expose the fact that they were receiving BusyBox from their vendor. Likewise, with the exception of Verizon Communications, Inc., none of the defendants appeared to have included indemnifications or other provisions in their vendor procurement contracts to insulate themselves from liability for violation of open source or other third party software licenses by the vendors. Second, the violations were very basic violations of the GPL. Each case involved a failure to comply with the GPL in connection with the redistribution of BusyBox in unmodified form (not, for example, a more complicated claim that modifications made to BusyBox were somehow subject to the GPL). Again, this would appear to signal that mere knowledge of the fact that BusyBox was being distributed would have been sufficient to enable any of the defendants to comply with the terms of the GPL. Third, the cases targeted companies of all size, from telecommunications giant Verizon down to High-Gain Antennas LLC, a very small reseller of antennas and other communications gear with a single location in Parker, Colorado, and in doing so demonstrated that open source license compliance is a concern for any company, not just those falling into a specific demographic.

In short, the facts giving rise to the claims in the BusyBox cases were not unique to the seven named BusyBox defendants and, to the contrary, are likely common to many other companies using BusyBox and other open source software. As a result, the BusyBox cases provide a unique view into open source license compliance and stand as a message to all companies of some of the genuine and potentially significant risks of ignoring open source license requirements.

OPEN SOURCE SOFTWARE IS SUBJECT TO CLAIMS OF PATENT INFRINGEMENT

  • The threat of patent infringement is nothing new to open source software. Indeed, in 2004 a study by Open Source Risk Management identified 283 patents “conceivably” posing a risk to Linux. See, http://www.osriskmanagement.com/press_releases/press_release_080204.pdf. However, as open source has achieved greater commercial success, the exposure to claims of patent infringement appears, not unexpectedly, to have increased as well.

This trend started in 2006 with the first ever patent infringement lawsuit involving an open source project. The case was brought by Firestar Software, Inc. against Linux distributor Red Hat, Inc. in the Eastern District of Texas and alleged that the Hibernate 3.0 technology (having been recently acquired by Red Hat from JBoss Inc.) infringed U.S. Patent No. 6,101,502 then-owned by Firestar. See, Firestar Software, Inc v. Red Hat, Inc et al, Case No.: 2:06cv258. While the case against Red Hat was settled before any substantive action had taken place, the settlement agreement has been published and has become required reading for any company concerned with its exposure to claims of patent infringement based on their use of open source software. See, http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf. Notably, the settlement is quite broad, covering all software licensed under the Red Hat brand (whether developed by Red Hat or third parties), derivative works of Red Hat-branded products, and combinations of software including Red Hatbranded products. The settlement covers upstream developers as well as predecessor products of Red Hat-branded products. The settlement also covers not only the patents involved in the lawsuit itself, but all other patents owned by the plaintiffs in the case.

This suit was followed by others, including lawsuits directed at Linux itself. The first such patent infringement lawsuit involving Linux was filed on October 12, 2007 in the Eastern District of Texas by subsidiaries of Acacia Research Corp. against Red Hat and Novell, Inc., directed against the desktop and server versions of Linux distributed by Red Hat and Novell. See, IP Innovation, LLC et al v. Red Hat Inc. et al, Case No.: 2:2007cv00447. At the time of this article, this case is still ongoing but has not yielded any substantive results.

More recently, however, in February of 2009, Microsoft brought patent infringement allegations against GPS device maker TomTom N.V. in the Western District of Washington involving eight Microsoft patents, among them at least three that allegedly cover TomTom’s implementation of the Linux kernel. While Microsoft claimed that the suit was not an attack on Linux or open source, the suit did come on the heels of several years of patent saber rattling by Microsoft against open source. See, e.g., http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/. Tom- Tom did not take Microsoft’s claims lightly and responded with a countersuit for infringement involving four TomTom patents. TomTom also joined the Open Innovation Network (OIN), a patentsharing coalition including IBM, Sony, Philips, Novell, Red Hat, Google, Oracle, and others in which the members agree to not assert their own patents against Linux and related software in return for receiving a royalty-free license to the patents contributed to the OIN by the other members. See, http:// www.openinventionnetwork.com/. Together, these efforts were successful in helping TomTom settle the claims brought by Microsoft on March 30, 2009. See, http://www.microsoft.com/Presspass/press/2009/mar09/03-30MSTomTomPR.mspx. In contrast to the sweeping terms of the settlement in Firestar v. Red Hat, the settlement in TomTom is quite limited. While the settlement is reported to cover past and future sales of the accused products, the scope is limited to the U.S. and the term is limited to five years. Likewise, the agreement requires that TomTom remove the technology covered by the Microsoft patents included in the suit from its products within two years. TomTom also agreed to pay Microsoft an undisclosed amount. While patent infringement activity involving open source software will likely continue, the suits involving open source are not yet nearly as prolific or problematic as those involving proprietary software. As with other legal issues involving open source, they have, however, shown an increase as the commercial use of open source has itself increased. As a result, now more than in the past, companies should take steps to understand the patent implications of open source and the steps they can take to address and minimize their liability for patent infringement. The cases covered above, and their public records, form a solid starting point for gaining this understanding.

CONCLUSION

  • While there are many risks associated with using and deploying open source software, these risks need not be any greater than the risks posed by proprietary software. Most all companies have taken steps to ensure their compliance with third-party proprietary software licenses and to assess and address the legal risks of using third party proprietary software. Yet, despite many of the same risks being presented by the use of open source software, far fewer companies are even aware of what open source software they are using, much less have taken steps to comply with applicable open source licenses (or mitigate the consequences of non-compliance). Increasingly, the rapidly evolving open source software legal landscape has placed these companies at an increased risk of open source license violations and other potential legal liabilities. These risks are, however, largely unnecessary if companies devote similar attention to open source software compliance and legal issues as they have to the legal issues involving proprietary software.

Popular related articles

Most popular articles on Lexology

If you are interested in submitting an article to Lexology, please contact Andrew Teague at ateague@lexology.com.

© Copyright 2006-2010 Globe Business Publishing Ltd