©2020. Published in Landslide, Vol. 12, No. 4, March/April 2020, by the American Bar Association. Reproduced with permission. All rights reserved. This information or any portion thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association or the copyright holder.
April 01, 2020 Webinar
Open Source Software and the Collaborative Culture
Donna P. Suchy, Susan E. McGahan, Adriana Suringa Luedke, and John Colligan
Open source software is software that is made available for other developers to use, edit, and build upon. This aspect is seen as “one of the key strengths of open source software, because not only does it invite close scrutiny from a wide range of parties with different interests and skill sets, it also invites wide ranging collaboration.”1 Due to this collaborative culture of open source software usage and development, open source projects tend to attract the formation of “communities” comprised of developers working together to further develop a piece of software.2 These communities may even branch out into groups working in different directions on a particular software. The Linux operating system is a famous example of this model, with the operating system coming in many forms and distributions.
Landslide Webinar Series
Practical Guidance for Managing Open Source Software Legal Risks
How Does Software Become “Open Source”?
Software is considered “open source” based on the conditions that the developer places upon the source code’s distribution and any further editing. According to the Open Source Initiative, open source software is defined as software that contains distribution terms which comply with the 10 basic criteria3 listed below. These criteria are all meant to preserve the ability of future developers to use, edit, and further develop the software:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
4. Integrity of The Author’s Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.4
Open Source Licenses
To meet the 10 criteria listed above requires that licenses contain terms governing the distribution and further editing of the source code that comply with the Open Source Definition. As of the drafting of this article, there are 96 Open Source Initiative–approved open source licenses.5
Open source licenses fall into two major categories: “copyleft” licenses and “permissive” licenses. Copyleft and permissive licenses are similar in that they both permit developers to modify, redistribute, and copy the code. The main difference is in the approach to copyright privileges.6 Specifically, permissive licenses allow developers to include their own copyright statements.7 Copyleft licenses, however, do not.8 “Instead, copyleft license rules require all derivative works [i.e., the follow-on works created based largely upon the original copyrighted work] to be subject to the original license. This means that developers cannot make patent or copyright claims on the original software.”9
According to a research study published in December 2018, the top three most popular permissive licenses utilized in 2018 were the MIT license, the Apache 2.0 license, and the BSD license (or the 3-Clause BSD License).10 The GNU GPLv3 license was identified as the most popular copyleft license and is aimed at making the source code freely available to anyone who would like to use it for any purpose.11
All top three permissive licenses permit the developer to modify or recalibrate the source code, produce derivative works from the original software, and even reap commercial benefits from sale of the secondary product.12 However, there are some important differences:
- MIT: includes a copyright disclaimer saying that copyright holders will not be held liable for claims or liabilities, and a disclaimer stating that the software is provided “as is.”
- Apache 2.0: defines “legal entities, derivative works, and contributions”; specifies terms surrounding the grant of patent rights;13 and establishes strict rules14 regarding redistribution rights.
- BSD or 3-Clause BSD: includes the same copyright and disclaimer clauses as the MIT license, and a nonattribution clause15 protecting the software’s original creator by requiring creators of derivative products to obtain express permission before using the creator’s original name to promote the derivative products.
Why Use Open Source Software?
There are a number of benefits to using open source software, including efficiency, cost savings, promoting security (to an extent), and reliability.
Efficiency and Cost Savings
Being freely available to use, edit, and further develop, open source software can be seen as a software developer’s friend. To be able to use already existing software, as opposed to writing it all in-house or otherwise from scratch, promotes efficiency from a software development and business standpoint. The open-architecture nature allows interoperability, collaboration, and quick turnarounds on tight deadlines. In addition, due to the number of collaborators and groups working in various directions on a particular software, many software functions can often be developed that are freely available. This in turn eliminates the need for a company to spend resources developing software that it can essentially get for free. Companies that participate in open source collaborations may also find it easier to deploy technology into the marketplace, which results in cost savings and overall efficiencies in their networks.
Security and Reliability
Open source software that has a large following of users and programmers can also be more secure because more people working with the software will be able to fix issues and debug problems as they arise. This is in contrast with typical proprietary software in which, depending on the resources the company has at its disposal, issues with the software and debugging may be slower to address.
What Are the Risks of Utilizing Open Source Software?
While there are many benefits to employing open source software, there are also associated risks, including cybersecurity risks and legal risks.
Cybersecurity Risks
As mentioned above, due to the potentially large number of collaborators on a particular open source software project, if an issue or vulnerability is detected in the code, the problem can be fairly quickly debugged. However, for organizations that are slow to incorporate fixes into the affected applications that are dependent on open source projects, they can become the target for hackers to exploit those vulnerabilities before the organization can act.
Legal Risks
Recall that open source software is defined according to the 10 criteria listed above. These criteria are mostly embodied in the license that accompanies the open source software’s usage and distribution. Breach of that license carries with it legal risks for the user, the developer, and the company. It is further important to note that open source issues can be global issues, especially for software that may be used or distributed globally.16 Moreover, copyright and joint ownership issues may vary by country, so it is important for the company’s legal counsel and software project managers to be aware of what software development is taking place, who the developers are, and which open source license terms are attached to a particular software.
Proper management of the license associated with open source software usage is therefore key for the in-house project managers and their counsel.
How Do We Mitigate the Risks?
Effective deployment of products utilizing open source software is linked to the effective management of the usage of open source software. It is critical to make sure the license terms associated with a particular piece of software are reviewed and have been carefully followed. Certain open source licenses could subject the purchasing party to additional costs or even the loss of previously proprietary software source code if the license terms were inappropriate for the intended use and/or not followed. For instance, if the license is a viral one (e.g., an open source license that requires grant-backs or delivery of certain source code packaged with it), then the use of that open source software in a proprietary product offering might render even the proprietary code publicly available for the asking. Such unintended results could greatly affect the value and proprietary nature of that product. In addition, infringement is always a concern. The fact that open source software does not cost anything does not mean it is not potentially infringing.
It is therefore essential to be aware of the different types of open source licenses, and in particular weigh the potential risks they pose to judge the appropriateness for your client’s or company’s purposes. This ideally requires a partnership between engineering and legal. Legal needs to educate the engineering and developer teams on risks associated with certain open source software, and the engineering and developer teams need to educate legal on products and end-user applications that will be developed with open source software.
Establish an Open Source Review Team
Among the toughest challenges an in-house counsel managing open source software faces is to make sure any licenses associated with software-containing products are complied with. To make sure the code is not used in a manner inconsistent with its license’s intent and that it does not attach virally to proprietary code is no easy task. Selecting the right open source projects within a correct open source community to complement a company’s open source software is crucial. In order to drive down costs and ramp up the speed of innovation, some companies even take an “open source–first approach” to virtualization and are involved in various open source groups before turning them over to an open source community.
In order to manage all these tasks, it is common for companies to establish review teams composed of colleagues in various capacities that may see or be exposed to products containing open source software within the company. For most companies, the “make-or-buy” decision regarding software is one that has legal and cybersecurity risks, so it must be carefully explained to the decision makers. At a minimum, therefore, a company’s open source review team should comprise representatives from legal and engineering/software development, and in some cases representatives from IT or other company functions. Although it varies by company, the larger risks relating to the use of open source software are often with the development and sale of company products, but there is potential for open source issues to arise with respect to internal IT systems or a company’s internal software functions. So the company’s open source review team should have representatives that reach across the entire business.
It is wise to also include embedded software experts who advise the engineering and business teams, coupled with robust processes and procedures. Involving teams that have software skills and knowledge is critical, along with attorneys who have a deep understanding of software and open source licenses. Remaining involved in the early stages of projects and development that may involve open source software is also important.
Don’t Forget about the Products or Software Your Company Purchases
In addition to tracking and controlling the use and inclusion of open source software developed in-house, it is also critical to track the inclusion of open source software or products that are purchased by your client or organization. In order to help run this due diligence, it is a good idea to require suppliers to furnish “open source software disclosures” and warrant that the use of the software complies with the legal requirements of any applicable license, or is otherwise suitable for the intent and purposes furnished to your company or client. It is also common to require suppliers to avert risks to your client or company or its third-party supplier’s proprietary software, and if not, your client or company can immediately terminate any applicable orders from that supplier. Depending on the situation, it may also be appropriate to independently determine whether software contains open source software by running a third-party scanning software to determine if there are any open source components.
Open Source Software Should Be Used with Caution
As this article demonstrates, there are indeed many benefits for open source software usage. But the usage also carries with it risks for the average company or software owner interested in simultaneously maintaining a competitive edge that necessitates exploiting the proprietary nature of the software.
Key takeaways for the legal counsel supporting the development, deployment, or purchase of products that include open source software include:
- Remain in the know: Remain in touch with the business and development teams, and others cognizant of the direction in which the business or client is heading, to ensure you are aware of the risk tolerance the business or client is willing to take. As mentioned above, the decision of whether and to what extent to include open source software in products is one that rests with the business. It is the legal counsel’s duty to, at a minimum, apprise the business of the legal and cybersecurity risks associated with a particular business decision.
- Establish open source review teams: In order to efficiently become apprised of and control the use of open source software that is developed or acquired by the business, establish a review team comprised of colleagues from the legal, technical, finance, and business sectors. This team will review the use of open source software and its associated licenses against the risk tolerance and intent of the business on a case-by-case basis.
- Train your clients and business: Conduct regular trainings to help ensure that your business and clients are aware of the risks associated with using open source software. At a minimum, letting the developers know when they need to come to legal (and the larger open source review team) with questions or to disclose the use of open source software will make the review more efficient and permit you the opportunity to flag risks and influence decision-making to mitigate risks early on.
- Indemnification: Request that suppliers using open source software in their deliverables indemnify the customer. If the customer is alleged to be in noncompliance with any open source license term, require the supplier to indemnify, defend, and hold harmless the customer against such allegations. This should be done in a manner that preserves any proprietary software of the customer or its third-party suppliers from public disclosure or any other open source license noncompliance allegations.
Endnotes
1. Cat Ellis & Brian Turner, Best Open Source Software of 2020: Free Software for Home or Business, TechRadar (Nov. 3, 2019), https://www.techradar.com/best/best-open-source-software (emphasis added).
2. Id.
3. It is noteworthy that these criteria are based off of the Debian Free Software Guidelines, which are part of the Debian Social Contract that accompanied the Linux distribution of software under what was known as the Debian Project. The Open Source Definition, Open Source Initiative, https://opensource.org/osd (last modified Mar. 22, 2007).
4. Id.
5. Licenses by Name, Open Source Initiative, https://opensource.org/licenses/alphabetical (last visited Feb. 14, 2020).
6. Open Source Licenses: A Comparison of the Most Popular Types, Kiuwan, https://www.kiuwan.com/blog/comparison-popular-open-source-licenses (last updated Oct. 16, 2019).
7. Id.
8. Id.
9. Id.
10. Id. (citing Ayala Goldstein, Top 10 Open Source Licenses in 2018: Trends and Predictions, WhiteSource (Dec. 13, 2018), https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions).
11. Id.
12. Id.
13. It is important to note that the terms surrounding the grant of patent rights are absent in the BSD, Apache version 1.1, and MIT licenses. Id.
14. For example, the Apache 2.0 license requires developers to perform specific tasks that follow the further developed and distributed software, including: provide a copy of the Apache 2.0 license to the recipient of any derivative work, provide clear statements verifying that files have been modified, and retain in the source form “all copyright, patent, and attribution notices from the source form of the original software.” Id.
15. This nonattribution clause was formerly known as the “non-endorsement clause.” Id.
16. See, for example, the case of Patrick McHardy, “an early contributor to Linux, [who had] been using the threat of litigation in Germany to obtain monetary settlements, essentially acting like a copyright troll” for violation of the GPLv2 license for Linux software. Although the case eventually settled, it exemplifies the cross-border nature of attempts to enforce open source licenses. Victoria Lee et al., Top 10 FOSS Legal Developments of 2018, Opensource.com (Feb. 5, 2019), https://opensource.com/article/19/2/top-foss-legal-developments.