Thank you for sharing!

Your article was successfully shared with the contacts you provided.
According to the Open Source Initiative, a nonprofit corporation dedicated to managing and promoting open-source software, there are four “classic” open-source licenses. These are the GNU (Gnu’s Not Unix) Public License, the Limited GNU Public License, the Berkeley System Distribution and the Massachusetts Institute of Technology license. Since the open-source release of the Netscape Web browser in 1998, the Mozilla Public License has also become widely used. Many other open-source licenses have been created. Currently, there are 58 open-source licenses approved by OSI, and new open-source licenses can be approved by the OSI by submitting the text of the proposed license along with comments by an attorney making reference to OSI’s 10-part definition of open source. Of all the open-source licenses currently being used, the classic GPL license is the most prevalent. Most components of the popular GNU/Linux system, including the Linux kernel itself and most system utilities and applications, are licensed under the GPL. In addition, leaders in the open-source community have urged developers to use the GPL or GPL-compatible licenses whenever possible. According to a 2002 estimate, about 90 percent of all open-source software was licensed under the GPL. This article will address the legal and practical risks that users of open-source software might face. Clearly identifying the risks involved with open-source software is a step toward overcoming the fear, uncertainty and doubt that might otherwise discourage its widespread adoption. Due to its prevalence, the focus here will be on the GPL. Many companies find that open-source software components provide high quality at low cost compared to commercial alternatives. This provides the natural incentive to use open-source software as a building block for proprietary products. For example, a company may wish to create a special-purpose operating system based on the Linux kernel. However, under the terms of the GPL, a licensee may be required to release its own source code if it distributes or publishes a derivative work based on the GPL-licensed program. Setting aside the obvious questions of when a work is considered “distributed” and “derived” under the terms of the GPL, companies may find themselves in the difficult position of having to either release their proprietary source code to the public or lose the permission to distribute, copy or modify the modified software. Licensees can choose to release their source code and thereby comply with the terms of the GPL. However, licensees that choose this route should be cautioned that the GPL requires derivative works to be licensed “as a whole.” This may include not only the main source code routines, but interface definition files and related scripts as well. Thus, it is often not possible simply to carve out or redact selected proprietary portions of the source code. SEPARATING OUT PROGRAMS One way around the requirement to release source code is to put proprietary code into identifiable sections of a work that are not derived from the open-source program, as contemplated by � 2 of the GPL. These separate sections must reasonably be considered independent and separate works in themselves. However, separate programs must be truly distinct from other GPL-licensed works, and not “part of a whole which is a work based on the Program.” What this means, though, is not entirely clear and has yet to be interpreted by a court. On one extreme, merely aggregating programs on a volume of storage or distribution medium is expressly permitted under the GPL. On the other extreme, a proprietary program that is separate but nonetheless relies entirely on a GPL-licensed program to function would likely be considered “part of a whole work” based on the GPL-licensed program, requiring the source code to be released. In between these two extremes lie many shades of gray, where two separate programs may communicate, interoperate or function in parallel, but where the GPL offers little guidance on the duty to release code. Thus, one risk associated with using GPL or other open-source licenses as building blocks in creating proprietary products is the uncertainty regarding precisely when the duty to release source code is imposed. Many companies would rather not release their source code for fear of divulging proprietary information and giving up trade secret protection, which may be the best means of safeguarding software. Making matters worse, the GPL prohibits distribution of a derivative work in the event that patent or other royalties are exacted. And while copyright protection remains available, it is generally limited to nonfunctional aspects of a developer’s work. Needless to say, distributing source code is seldom an attractive option for developers of proprietary software. This leaves many developers between a rock and a hard place. Releasing source code could mean giving away proprietary information, but on the other hand, licensees that choose not to release their source code but need to continue distributing their software could be liable for copyright infringement. Normally, the author has standing to sue in such actions. In many instances, however, the author will have transferred the copyright to another more sophisticated body. For example, the GNU project urges donors of any substantial amount of code to assign rights to the Free Software Foundation, in part to facilitate enforcement actions. To this end, the FSF operates a “compliance lab” to monitor GPL violations and take enforcement action where necessary. While it does not appear that such actions have reached U.S. courts, the FSF has not been hesitant to enter negotiations with such heavyweights as Cisco Systems Inc. and Broadcom Corp. over suspected GPL violations. In Germany, a group unrelated to the FSF, but having the same goal of tracking GPL violations, has received at least two injunctions against companies that have failed to release source code. These activities show that the duty to release source code should not be taken lightly. DUTY TO RELEASE SOURCE CODE Given the repercussions of releasing source code, it is important for licensees of open-source software to know when this duty is imposed. There are two aspects to this duty: distribution and derivative works. But unfortunately, the GPL does not use consistent or well-defined language in connection with either aspect. In �2(b), the GPL requires releasing source code when licensees “distribute or publish” any work that in whole or in part contains or is derived from the program or any part thereof. In connection with the “distribution” aspect of the duty to release source code, �2(b) uses the additional language “third parties” to qualify when a work might be considered distributed. Another term, “redistribute,” is used in the context of how a license is automatically granted to successive licensees. In connection with the “derivative work” aspect, �0 of the GPL imports the definition of a “derivative work” from copyright law, but then uses the phrase “work based on the Program” in a more expansive context (stating that it includes “a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language”), suggesting that the two terms are not coextensive in scope. Exacerbating the problem, the term of art “collective work” is also used in �2, but its definition under 17 U.S.C. 101 as a “work … constituting separate and independent works in themselves” was not imported into the GPL. This suggests a somewhat broader duty to release code, not confined simply to the creation of derivative works. Nor has the term “distribution,” which is defined in 17 U.S.C. 106(3) as “sale or other transfer of ownership by rental, lease, or lending,” been explicitly imported into the GPL. This raises the issue of whether a “distribution” under the GPL is coextensive with a “distribution” in copyright law. The lack of clear definitions and consistent terms can make it difficult for licensees to discern their precise responsibilities to release code. For example, a licensee may make minor but proprietary modifications to a GPL-licensed program, and then pass it on in executable form to independent contractors, without the accompanying source code, for testing purposes. Does the modified program constitute a “derivative work” and, if so, does it also qualify as a “work based on the Program”? And should the proper inquiry focus on whether the licensee’s act qualifies as a “distribution,” or on the status of the recipient as a “third party”? The GPL Frequently Asked Questions section weighs in on this and other issues, but its interpretation of the GPL is primarily aimed at resolving practical rather than legal issues, and, in any case, is not binding on courts. RISK OF INFRINGING COPYRIGHTS Another risk of using open-source software is that it will be found to infringe existing copyrights. This risk does not result from the terms of the GPL itself, but from the possibility of unpoliced submission of proprietary code into open-source projects. Although this is a risk when using any software product, it may be even more of a risk in open-source projects, where the code is open to public inspection. However, some have argued that this creates strong incentives for honesty and provides far greater protection for copyright holders than in proprietary systems, where source code can be misappropriated and hidden without being discovered, short of a lawsuit. This risk can be addressed in part by educating developers about the legal standard of substantial similarity in the context of copyright law, which focuses on the abstraction-filtration-comparison test set forth in Computer Associates International Inc. v. Altai Inc., 982 F.2d 693 (2d Cir. 1992). According to this test, the process of determining substantial similarity involves three steps: abstraction of the plaintiff’s program; filtration out of any nonprotectible elements; and comparison between the remaining core of protectible expression and the defendant’s work. Currently, however, the GNU Developer Guidelines urge programmers who have vague recollections of the internals of a Unix program that they wish to imitate, to organize their work internally along different lines because “this is likely to make the details of the Unix version irrelevant and dissimilar to your results.” But merely using a different internal organization is problematic in view of Whelan Assocs. Inc. v. Jaslow Dental Lab. Inc., 797 F.2d 1222, 1240 (3d Cir. 1986), which holds that copyright law may protect the “structure, sequence and organization” of the source code. Another issue that arises in the context of imitating or porting familiar code to open-source platforms is that the programmer’s familiarity with Unix or other proprietary code could result in a finding of subconscious copying. The well-known case Bright Tunes Music v. Harrisongs Music, 420 F. Supp. 177 (S.D.N.Y. 1976) held that George Harrison had subconsciously, though not deliberately, copied the melodic kernels of “He’s So Fine” when composing “My Sweet Lord.” The court found it relevant that Harrison was aware of “He’s So Fine” (it was on the Billboard charts with a Beatles song in 1963). Likewise, an open-source developer could infringe the copyright of a familiar proprietary product by inadvertently imitating its code, as contemplated by the GNU Developer Guidelines, even if she is not deliberately copying its structure, sequence or organization. Donors of code into GNU and other formal open-source projects are normally required to represent that they have the necessary ownership rights and to obtain the necessary disclaimers from employers. However, such representations are merely assertions of legal ownership by the donor of the code, and do not operate as a warranty, indemnification against claims of infringement, or other legally binding protection against future claims by any party, other than the donor’s employer. Thus, despite the freedom to distribute, copy and modify code, licensees of open-source software should be aware their own use is only permissible to the extent that the original licensor holds a valid copyright. OTHER RISKS There are other legal risks in using open-source software. For example, there are certain legal issues in combining nonfree libraries with GPL-covered software. There is also the issue of how to reconcile incompatible open-source license provisions, which is of particular concern in complex releases that may contain dozens of different open-source components. In addition to indemnification provisions, proprietary software licenses frequently provide warranties against defects in media, the existence of viruses, worms, Trojan Horses and backdoors. In contrast, GPL-licensed software is typically offered “as is,” without any warranties. In addition, maintenance and support provisions, also common in proprietary licenses, are often lacking in the GPL though available from third-party vendors for a fee. While there are many risks associated with the use of open-source software, being aware of these risks allows licensees to make informed choices. In many cases, the extra cost of proprietary software is justified. However, often the high quality and low (or no) cost of open-source software more than outweighs the risks involved. Ryan Hatch is an associate who practices intellectual property law in the Los Angeles office of Pillsbury Winthrop Shaw Pittman.

This content has been archived. It is available through our partners, LexisNexis® and Bloomberg Law.

To view this content, please continue to their sites.

Not a Lexis Advance® Subscriber?
Subscribe Now

Not a Bloomberg Law Subscriber?
Subscribe Now

Why am I seeing this?

LexisNexis® and Bloomberg Law are third party online distributors of the broad collection of current and archived versions of ALM's legal news publications. LexisNexis® and Bloomberg Law customers are able to access and use ALM's content, including content from the National Law Journal, The American Lawyer, Legaltech News, The New York Law Journal, and Corporate Counsel, as well as other sources of legal information.

For questions call 1-877-256-2472 or contact us at [email protected]

Reprints & Licensing
Mentioned in a Law.com story?

License our industry-leading legal content to extend your thought leadership and build your brand.


ALM Legal Publication Newsletters

Sign Up Today and Never Miss Another Story.

As part of your digital membership, you can sign up for an unlimited number of a wide range of complimentary newsletters. Visit your My Account page to make your selections. Get the timely legal news and critical analysis you cannot afford to miss. Tailored just for you. In your inbox. Every day.

Copyright © 2021 ALM Media Properties, LLC. All Rights Reserved.