There are a number of potential pitfalls when using open-source software, however, a large group of developers is more likely to create a better working product than a single developer or a small group of developers. Both managers and developers need to be aware of these issues since a careless mistake can have disastrous consequences as they relate to proprietary, commercial software.
Most open-source licenses are rooted in U.S. copyright law. U.S. copyright law allows the creator of a copyrighted work (e.g., software) to have fairly strong control over what is done with that copyrighted work. You need look no further than the RIAA and what happens when the RIAA goes after someone who illegally posts or downloads copyrighted music files. It can be downright brutal.
The Powers of Copyright Holders
Article 1, Section 8 of the United States Constitution grants Congress the power to “promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.” This clause provides the basis for both U.S. copyright law and U.S. patent law.
Congress has codified U.S. copyright law in title 17 of the United States Code. Rules related to U.S. copyright law are published in title 37 of the Code of Federal Regulations.
A copyright holder has broad discretion in deciding how his or her copyrighted material will be used. Most of us know that there are many types of open sources licenses out there. Perhaps the most popular are the GNU General Public License (GPL), the GNU Lesser General Public License (LGPL), BSD, MIT, and Apache licenses. These licenses tend to place restrictions on how developers can use licensed software or libraries in so-called derivative works.
U.S. Copyright Law defines a derivative work as a “work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a ‘derivative work.'”
A software copyright holder can use pretty much any license grant he or she wants. Here’s an interesting license one of my colleagues recently came across.
DO WHAT THE [EXPLETIVE] YOU WANT TO PUBLIC LICENSE
Version 2, December 2004
Copyright (C) 2011 Tejaswi
Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed.
DO WHAT THE [EXPLETIVE] YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHAT THE [EXPLETIVE] YOU WANT TO.
/* This program is free software. It comes without any warranty, to
* the extent permitted by applicable law. You can redistribute it
* and/or modify it under the terms of the Do What The [EXPLETIVE] You Want
* To Public License, Version 2, as published by Sam Hocevar. See
* http://sam.zoy.org/wtfpl/COPYING for more details. */
We got a good laugh over this. Colorful language aside, this license grant is perfectly valid; you can basically do what you want with code provided under this license.
Most roboticists will encounter one or more of the GPL, LGPL, BSD, MIT, and Apache licenses. Some of these licenses are more restrictive, while some are more permissive. For example, the GPL is one of the most restrictive open source licenses. LGPL relaxes some of the requirements of GPL, making it suitable for use in some commercial applications, if the requirements of the license are followed. The BSD, MIT, and Apache licenses are considered more permissive.
For a good short overview of some of the most popular OSS licenses, take a look at “A Short Guide To Open-Source And Similar Licenses” by Cameron Chapman of Smashing Magazine. If you have concerns about these licenses, particularly combining different license types, it’s best to consult an attorney licensed in your jurisdiction who can assess your specific situation and provide tailored legal advice.
There have been very few court decisions where the central issue was whether or not the terms of an open-source license have been violated and the plaintiff was asking that source code be released. Many cases have settled. There is no reason to believe that the terms and conditions of the most popular OSS licenses would not be upheld. Google “BusyBox litigation” for examples of GPL-related litigation.
Propagation and Conveyance as Triggers
One of the first things to consider regarding the use of GPL 3 code in a proprietary application is whether the application will be propagated to those outside of your company/organization or those under your control (e.g., subcontractors, consultants).
GPL 3 defines propagation of a covered work as “do[ing] anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.”
GPL 3 defines a conveyance of a covered work as “any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.” See, GNU General Public License, Version 3, 29 June 2007.
Section 2 of GPL 3, which relates to basic permissions, provides the trigger for GPL 3. It states, in part, that “[t]hose [] making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated [in the remaining sections of the license].”
Because of this, if you are selling an unmanned system, delivering an unmanned system to a customer under an R&D contract, delivering OCU software to a customer, etc., and you have proprietary software that incorporates or links to GPL 3-licensed code, you’ll be required to comply with the source code distribution requirements of GPL 3. LGPL 3 incorporates GPL 3 by reference but relaxes many of GPL 3’s requirements in certain situations.
There has been some controversy related to companies that use GPL 3 code in software-as-a-service (SaaS) and other approaches where GPL’d software is used in proprietary, commercial applications where that software is not conveyed but is instead accessed over the Internet (e.g., via the “cloud”). To address these concerns, the Affero General Public License (AGPL), now the GNU Affero General Public License, was created.
This 2016 State of the Plate Church Giving Research is very similar to GPL, with additional requirements if users interact with derivatives of AGPL’d software remotely via a computer network. In such cases, the remote user must be given access to the derivative software via a network server. The full terms of AGPL 3.0 can be found here.
Effect on Proprietary Code
If you plan to use GPL 3 code in a proprietary project that you plan to commercialize, you’re likely making a very bad decision. Again, consult your legal counsel. In many cases, LGPL 3 might be a better option, assuming you can find an LGPL’d version of the library to which you plan to link. However, know that the type of linking you use with LGPL 3 does matter.
Many developers will find an LGPL’d library that meets their needs and assume that as long as they are linking to it, there are no issues. That is not 100% correct. LGPL 3 provides two options for using an LGPL’d library without having to release source code (or object code): (a) conveying “Minimal Corresponding Source” that relates to the areas of overlap between the LGPL’d library and your proprietary code or (b) use dynamic linking.
Unfortunately, GNU considers a proprietary application that statically links to a library to be a derivative work of that library. Therefore, in those situations, the terms of GPL will likely apply. So, if you are linking to an LGPL’d library, you should consider whether you are statically or dynamically linking.
0) Convey the Minimal Corresponding Source under the terms of this license, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) Use a suitable shared library mechanism for linking with the library. A suitable mechanism is one that (a) uses at run time a copy of the library already present on the user’s computer system, and (b) will operate properly with a modified version of the library that is interface-compatible with the Linked Version.
A big point to remember here is that LGPL is basically GPL with a few exceptions added. If your use of an LGPL library does not fall within those exceptions, the terms of GPL may apply and you may be required to release your proprietary source code. In addition, the patent-related provisions of GPL 3 may apply.
Effect on Patents
If patent protection is important to your organization, it’s important that both management and developers understand the patent-related section of GPL 3.
11. Patents.
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.
A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this license, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this license.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this license, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this license, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this license. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
There are many potential issues and discussion topics in this section of GPL 3. A full analysis is outside the scope of this article. However, an important consideration is that as someone who is making a derivative work (i.e., you’re modifying GPL 3’d code or are directly integrating or statically linking to GPL 3’d code), any recipient of that modification or derivative work would be granted a “non-exclusive, worldwide, royalty-free patent license” to any “essential patent claims” as defined in the license. This grant is for any of your current or future patent claims that would be infringed by someone using the code you convey.
If your organization’s strategy includes licensing your patents, this could be particularly problematic. Keep this in mind and, again, be sure to consult your legal counsel. Either way, you might want to establish an open-source software policy for your organization.
Establishing an Open Source Software Policy
If you are or likely will be selling commercial software, you should consider establishing an open-source software policy for your developers. Included in this policy might be a quick reference chart showing developers the open-source licenses your organization will allow them to use and which open-source licenses they are not allowed to use. The quick reference chart could also include important notes related to each license. For example, next to LGPL 3, an appropriate note might be “Do not statically link!”
You might also want to consider adding to each project in your source code management system a file that lists the open-source software used and the licenses attached to that software. This will help with OSS audits you may conduct before distributing your software outside your organization. In addition to this approach, there are also open-source license auditing tools that might be helpful.
Conclusion
Before developers grab software libraries or code snippets for use in proprietary software, they should be aware of which software licenses are attached to those libraries or code snippets. Furthermore, you should understand how those licenses impact the proprietary software once it’s distributed. An open line of communications with your legal counsel should help you avoid many of the pitfalls associated with using open-source software.
Legal Disclaimer: The information in this post is for educational and informational purposes only and is not and should not be considered legal advice or a substitute for legal advice from an attorney licensed in your jurisdiction.