By: Jaideep Reddy
“These days a developer will do a Google search, find five open-source products that fit his[/her] need and the next thing you know one of them is in a product.” – Phil Robb.
Because open source code presents such a valuable resource for programmers, for-profit companies regularly incorporate it into their products. A developer need not expend resources into writing common mathematical functions, for example, afresh. She can incorporate an open source library already having such functionality into her program. Frequently used mathematical functions are just one example of millions of tasks that can be incorporated from open source software. According to a recent estimate, “[t]here are over 25 million repositories on GitHub, over 430,000 projects on SourceForge and over 21 billion lines of indexed and searchable open source code on the Black Duck Open Hub.”
Many for-profit companies, especially those in the early-stages, do not realize that they “can’t just use [open source software] any way they want.” This could be because they misconstrue the import of the term “open source” and/or because they are not aware of open source licenses being enforced.
This post explores the instances in which open source licenses have been enforced, with the aim of gauging the practical importance of complying with open source license conditions.
Jacobsen: Breach of an open source license can lead to a copyright remedy
The first vindication of open source license enforcement came in Jacobsen v. Katzer (Fed. Cir. 2008). The Federal Circuit held that a licensee’s violation of the Artistic License, an open source license imposing disclosure requirements on the licensee, amounted to copyright infringement. The court dealt with the question of whether the Artistic License imposed a mere covenant (which would only provide a contractual remedy to the licensor) or a “condition” limiting the scope of the licensed rights (which would allow for a claim of copyright infringement). The licensee argued that the terms of the license were not “conditions,” since the code was made available for free and could not provide the copyright holder economic rights. The court rejected this argument, concluding that the requirement of “disclosure and explanation of changes, rather than [] a dollar-denominated fee, is entitled to no less legal recognition.”
The holding of the case could not necessarily be extrapolated to other more popular open source licenses such as the General Public License (GPL). But it did establish that if an open source license contained provisions limiting the licensee’s rights of reproduction and distribution, it could be enforced under copyright law. It thereby “cemented the legal footing” of open source licenses.
The Versata Case – Testing the GPL; Carelessness can be costly
The Versata Case consists of five independent litigation proceedings involving the incorporation of XimpleWare’s open source software by Versata Software into its proprietary Distribution Channel Management (DCM) software. XimpleWare’s software was made available to Versata under a GPLV2 license. The DCM software was in turn licensed by Versata to various enterprise customers. Versata had used the XimpleWare software in its product, but failed to comply with the terms of the GPLV2 license. The GPLV2 license required Versata, when providing its software to its licensees, to display the text of the license, attribute ownership, and provide a copy of the source code of the XimpleWare software. Versata failed to carry out any of these actions.
Ironically, the proceedings began with Versata suing one of its customers for copyright infringement, leading to the discovery of Versata’s skeletons in the closet. XimpleWare promptly filed suit. All of the proceedings are before the trial courts, except one which has settled. The four issues arising out these cases are regarding:
- What the remedies are for breach of the GPLv2;
- What a “distribution” is under the GPLv2 (a “distribution” triggers the license obligations);
- Whether the GPLv2 includes a patent license; and,
- What type of integration between proprietary software and GPLv2-licensed software results in the creation of a “derivative work”, subjecting the proprietary software to the terms of the GPLv2.
The courts have not yet had occasion to rule on these issues. Answers to these questions will . However, the mere fact that such a complicated legal saga (involving 3 courts and 12 different actors) has resulted from one company’s careless appropriation of open source software deserves noting.
Oracle – Application Programming Interfaces (APIs) are copyrightable
In June of this year, the U.S. Supreme Court declined to overturn a Federal Circuit ruling that held that certain widely used APIs of Oracle were copyrightable. APIs are, in layman’s terms, programming instructions that developers can use in their own software as building blocks. For example, many popular ride sharing services use the Google Maps API in their apps because it would be costly to independently develop a similar interface of equivalent quality. Why is this relevant to open source licensing? Developers regularly use open source APIs.
In the case, Google (the developer of the “Android” platform, which used the APIs at issue) argued among other things that the code of the APIs was so central to their functionality that they did not qualify for copyright protection. The Federal Circuit rejected this argument, noting that other developers like Microsoft had written APIs with similar functionality but using different expression. Proceedings are currently pending before a jury in the Northern District of California District Court on the question of whether the use of the APIs by Google constituted “fair use” under copyright law.
Other than the simplest of APIs, Oracle means that developers are bound by copyright law when using open source APIs, and that they face actions for infringement if they violate the underlying licenses. Licensees can of course raise the fair use defense, but that is a highly fact-specific question, and will depend on the outcome of the jury’s decision in the Oracle proceedings in the District Court.
Open Source in Other Countries
Of course, the United States is not the only jurisdiction in which companies need to be concerned about the enforcement of open source licenses. Some past violations (and related litigation) of open source licenses in Europe have been chronicled here. In March this year, a new case alleging violation of the GPLV2 was filed in a German district court.
