The Pitfalls of Using Open-Source Code
Friday, November 25, 2011

Free or open-source software emerged in the early 1980s as a reaction against the perceived threat posed by proprietary software relying on trade secrets, copyrights and contract law to limit access to source code. The Free Software Foundation (FSF), a pioneer of the open-source code movement, was responsible for developing and releasing several free and open-source software programs, including the Linux operating system kernel. The FSF currently focuses on developing and maintaining various open-source licenses such as the GNU General Public License (GNU GPL), the GNU Lesser General Public License (GNU LGPL) and the GNU Affero General Public License (GNU AGPL). Although each of these licenses has different terms, the central idea is that software released under a GNU license should not ultimately end up locked away as part of proprietary software. In essence, open-source code must always remain “open” or “free” (i.e., accessible and modifiable, even when used as part of subsequent programs that were independently created).

As acknowledged by the founder of the FSF, the terms of the GNU licenses are rather complex and largely specific to relatively low-level system languages such as “C,” the typical language of early GNU software and libraries.1 Nonetheless, GNU licenses have been and continue to be applied to a variety of different software languages. Unfortunately, GNU licenses have rarely been challenged in court.2 Consequently, there is little judicial precedent to help understand the meaning of the provisions of these license agreements above and beyond the four corners of the agreements themselves and the various documents and FAQs published by the FSF.

Notwithstanding the lack of judicial comment or blessing with respect to the enforceability of the GNU licenses, it is clear that the GNU GPL is the most “copyleft” of the GNU licenses and provides users four freedoms that are generally reserved by copyright law to the copyright holder: the freedom to use the software for any purpose, the freedom to change the software to suit the user’s needs, the freedom to share the software with others and the freedom to share the changes made to the software. As such, software licensed under the GNU GPL is said to be “free software.” Importantly, “free software” does not mean that developers may not charge a price for the distribution of the software. Instead, the term “free” is in reference to the end user’s right to modify and distribute the source code associated with the software.

Today, most open-source code or free software is provided under the GNU GPL. Under the terms of this license, certain uses of open-source code “infect” the final product such that it also becomes open-source and distributed under the GNU GPL.3 For example, if a programmer improves the Linux kernel and distributes it to others, the programmer is free to “sell” the new kernel on the market so long as the modified kernel is distributed under the GNU GPL (i.e., so long as the source code is available to end users to modify and subsequently redistribute).

Although the open-source movement was designed to combat the development of proprietary software, the restrictive GNU GPL forced several corporate software developers (e.g., Microsoft) away from using open-source code. In response and recognizing that a number of open-source software constitutes software libraries (i.e., collections of resources used to develop software and to provide services to independent programs),4 the FSF created the weaker GNU LGPL, a license specifically directed to the use of such libraries with fewer copyleft restrictions than the GNU GPL.

The latest version of the GNU LGPL (version 3, dated June 29, 2007), incorporates the entirety of the GNU GPL and adds certain detailed exceptions for “Applications” (e.g., programs that “make use” of an open-source library) and “Combined Works” (e.g., “works produced by combining or linking an application with an open-source library”). Importantly, Applications themselves are not controlled by the GNU LGPL because they do not include and/or are not otherwise combined or linked with open-source code. In other words, programs that are designed to be used with an open-source code library but that are not actually linked with such libraries are not themselves subject to the open-source code GNU LGPL.

In contrast, Section 4 of the GNU LGPL makes clear that use of open-source libraries to create Combined Works is governed by the license. Unlike the GNU GPL, the Combined Work (including the proprietary application portion thereof) need not be licensed as free software under the terms of the “weaker” GNU LGPL. Instead, Section 4 of the GNU LGPL mandates that end users have access to the source code of the open-source code library and permission to modify the library and recombine it with the application.

In particular, the GNU LGPL (a) requires the provision of notice that an open-source code library was used pursuant to the GNU LGPL alongside other copyright notices, if any; (b) requires the provision of a digital copy of the GNU LGPL; (c) requires the conveyance of the source code of the library and the corresponding source code or object code of the application in a form that allows a user to modify the library and recombine or relink it with the application to create a modified Combined Work; and (d) prohibits terms that restrict access and modification to the source code of the open-source library or that otherwise restrict the end users’ ability to engage in reverse engineering to debug such modifications. For example, if a programmer uses an open-source code library in a word processing application for the Linux operating system and sells the product to customers, the GNU LGPL requires that the programmer provide customers the opportunity to access, modify and recombine the open-source library with the word processing application. If the library is dynamically linked, the programmer might use a suitable shared library mechanism for linking the object code of the application with the modified library at run time or, if the library is a statically linked library, the programmer would be required to provide either the source code for the application or a linkable object code version of the application.

Legal Issues Associated with Using Open-Source Code

1. Infection of Proprietary Software by Modification of Open-Source Code

Programmers may be tempted to adapt and modify a routine from an open-source code application. Use of such modified open-source code in a distributed product may result in infection of the corresponding source code of the proprietary application used with it, transforming it into open-source code that must be “freely” provided to end users.

2. Lack of Warranty

Generally, open-source code suppliers do not provide legal indemnification against claims for patent infringement or breach of warranties. Instead, open-source code is generally obtained “as is.” In the event a third party alleges patent infringement based on the use of open-source code, accused infringers will not likely be able to rely on any indemnification or warranty.

3. Prohibition on use of other Incompatible Open-Source Software

As a condition of use of the open-source library under the GNU GPL, programmers may not impose any further restrictions on the exercise of the rights granted under the GNU GPL. Thus, to the extent a programmer incorporates other open-source software governed by a different open-source software license, the programmer must first ensure that the two open-source software components are “compatible” or subject to certain exceptions. For example, open-source software governed by the 4-Clause Original BSD open-source license, which requires the display of an acknowledgement on all advertising materials, is incompatible with the GNU GPL. Therefore, programmers may not convey programs that include such BSD open-source code with modified open-source software governed by the GNU GPL. In contrast, the Apache License 2.0 is compatible with the GNU GPL, and programmers are free to modify and combine source code governed by the Apache License 2.0 and the GNU GPL.

Accordingly, while use of open-source software may be tempting, it is prudent to consider what trip wires and land mines one must successfully traverse before blindly using “free” software.

1 Richard E. Fontana, Open Source License Enforcement and Compliance, The Computer & Internet Lawyer, Apr. 2010 at *5.

2 Kelly v. Sky Angel, 2010 U.S. Dist. LEXIS 70624 (E.D. Tenn. 2010); Progress Software Corp. v. MySQL AB, 195 F. Supp. 2d 328 (D. Mass. 2002); Computer Assocs. Int'l v. Quest Software, Inc., 333 F. Supp. 2d 688 (N.D. Ill. 2004); Wallace v. Int'l Bus. Machines Corp., 467 F.3d 1104 (7th Cir. 2006).

3 In general, users of software licensed under the GNU GPL may use such software internally without any consequence. Similarly, users of such software may generally convey unmodified open-source software licensed under the GNU GPL to third parties without being forced to release the source code of other proprietary software used in connection with the open-source code.

4 In computer science, programs statically or dynamically link to libraries using a linker or compiler. Common dynamic libraries are DLL files (i.e., .dll files) in Microsoft Windows or DSO files (i.e., .so files) in Unix-like systems.

 

NLR Logo

We collaborate with the world's leading lawyers to deliver news tailored for you. Sign Up to receive our free e-Newsbulletins

 

Sign Up for e-NewsBulletins