The Importance of Tracking and Managing the Use of Open Source Software

Once an exception, today open source software (OSS) is a critical tool that is used in or touches an ever-increasing number of software systems. OSS is in cars, smartphones, watches, appliances, websites and “SaaS” services – essentially all of the technology in our lives. Companies seek to benefit from using OSS as pre-existing building blocks for their digital transformations. Despite its advantages, OSS raises unique concerns that companies may not appreciate, such as the burden of complying with OSS licenses, potential liability for infringement of intellectual property (IP), potential introduction of security vulnerabilities into a company’s systems, and potential loss of commercial value of a company’s proprietary technology. Companies can mitigate or avoid these concerns and the financial loss and business disruption that may result from them by adopting best practices around OSS.

This article will provide a brief introduction to OSS, and describe the key risks inherent in the use of OSS. This article will also explore approaches for companies to successfully understand, track and manage their use of OSS.

What Is Open Source Software?

While there is no precise definition, OSS is generally understood to refer to both a software license model and a software development model. As a license model, OSS is software (1) made available to the public over the Internet in source code form,¹ and (2) under a license that permits users to modify and distribute the software without payment of any fee to the licensor. There are many different OSS licenses, but they all tend to share these attributes and fall into two general categories -- “permissive” or “copyleft” (copyleft is also sometimes referred to as “viral”).² By contrast, most commercial software licenses only permit use of software in executable (compiled) form, and prohibit users from reverse engineering, modifying or distributing the software. Such licenses are considered closed because the source code for the software remains the licensor’s closely guarded secret.³

As a development model, OSS refers to software created by crowd-sourcing the work to a group of unpaid, volunteer programmers organized into a “project”, with individual programmers contributing code to the overall project. Advocates tout this as an engine for innovation and collaboration among programmers that allows “many eyes on the code” to find bugs and add improvements.

Why Open Source Software Is So Important

The popularity of OSS is high and growing. According to Synopsis (f/k/a Black Duck), a leader in OSS code audits, OSS accounted for 78 percent of code in the 2,409 codebases it audited in 2021.⁴ OpenLogic, a leading global provider of OSS-related services, found that, of the 2,660 developers in various industries it surveyed in 2021, 31 percent of respondents contributed to OSS projects, and 36 percent of respondents reported a “significant” increase in their use of OSS in 2021 over previous years.⁵ These results are not surprising. OSS can provide up-front benefits to companies and shorten the time it takes to create working software by reducing the amount of custom code in a project through the use of proven technology building blocks. Some OSS packages are now industry standard tools, such as Linux, Apache Web Server and Hadoop. These widely used OSS tools have largely supplanted their commercial (fee-based) alternatives.

Key Risks of Using Open Source Software

Despite these benefits, there are concerns inherent in using OSS that arise from its unique license and development models, including the following:⁶

• OSS License Compliance May Be Complicated. There are significant differences among OSS licenses. Permissive OSS licenses, such as BSD and MIT, require a user to provide notice of the license terms and licensor attribution. Copyleft OSS licenses, such as the GPL, on the other hand, may, depending on how the OSS is used, impose on companies requirements that conflict with their business objectives. For example, if a company integrates its proprietary software into copyleft OSS, it may (1) be required to provide others access to the source code for its proprietary software; (2) be prohibited from charging a license fee, or imposing its own license terms, for such proprietary software, and/or (3) be forced to license its patent portfolio to others. These requirements typically get triggered when OSS is “distributed”. However, determining the meaning of this term or other requirements is not straightforward, especially for OSS licenses that do not define key terms or specify governing law. This means evaluating what is needed to comply with OSS licenses often calls for a detailed, fact-specific analysis by technical and legal specialists and ultimately a judgment call.
• OSS Is Provided As-Is, Without Customary Licensee Protections. OSS is licensed on an “as-is” basis without customary licensee protections found in commercial software license agreements. For instance, OSS licenses lack warranties, infringement indemnities and commitments around bug fixes, or the provision of support, updates and patches. Companies bear the entire risk of liability for IP infringement if unauthorized code is contributed to an OSS project.
• OSS Development Model May Create More Risk for Users. OSS is developed as a patchwork of contributions from individual programmers, and this gives rise to several concerns. First, there is an increased risk that a contributor will submit to the project infringing code, i.e., copied from someone else without authorization. Second, even when projects have a process for reviewing code contributions, contributors may intentionally insert malicious code into their contributions for political, vendetta or other reasons.⁷ Third, if projects permit contributors to retain ownership of their code contributions (in contrast to ownership being assigned to the organization running the project), users may be subject to claims by individual OSS contributors for breach of the OSS license.⁸
• Security Vulnerabilities May Be Discovered and Exploited by Hackers. The free availability of source code for OSS increases the risk that hackers will find security vulnerabilities in the code. Since some OSS is used by thousands of companies, hackers can exploit these vulnerabilities to engage in large scale cyberattacks.
• OSS Licenses May Conflict. When multiple OSS components are used in a software project, there is a risk that, while these components may be compatible in a technical sense, their governing license terms make them legally incompatible. If OSS packages governed by conflicting licenses are used together, it may not be possible for the company to comply with any of them. To evaluate this risk, companies must analyze OSS licenses both individually and in the context of their overall use together.

Not paying attention to these issues can have devastating consequences. In the 2000s, Cisco embedded copyleft OSS in its Linksys routers without complying with an applicable OSS license. As a result, Cisco was sued and ultimately agreed to make freely available to the public the source code for one of its flagship products, in addition to paying an undisclosed amount to settle the dispute.⁹

Despite these outcomes, many companies still lack established policies for approving OSS use, do not enforce their OSS policies, and/or lack processes for tracking OSS usage.

How to Craft an Effective OSS Use Policy

Developing and adhering to a clearly written OSS policy can help companies realize the benefits, and mitigate the risks, of OSS. The particulars of a policy can and should vary company by company.

For example, a company that distributes software likely requires a more detailed OSS policy than one that only uses OSS for its internal systems. While there is no “one size fits all” approach, the following tips should help companies establish an OSS policy that fits their particular requirements.

Identify Key Objectives and Stakeholders

An effective OSS policy should be based on clearly defined objectives and buy-in from senior stakeholders within a company’s business, legal, engineering, and IT departments. Legal objectives might include OSS license compliance and avoiding conflicting license terms, while business objectives might include ensuring the company can charge fees for the right to use its proprietary software, avoiding a requirement to disclose its proprietary source code, and avoiding a requirement to license its IP to others. It is also critical to involve a range of stakeholders in this process to help ensure the resulting policy is practical and more likely to be followed.

Risk-Based Categorization of OSS Licenses

Strictly prohibiting, or requiring rigorous review of, all OSS is often impractical and may prove counterproductive by alienating a company’s technology personnel. Realizing this, companies may seek to streamline their approval process by designating OSS licenses as GREEN (acceptable for use), YELLOW (potentially acceptable for use) and RED (normally not acceptable for use). While OSS license categories depend on a company’s particular circumstances, the following are typical:

• GREEN: limited to OSS licenses with minimal requirements, such as the MIT, BSD, and Apache licenses.
• YELLOW: limited to “weak” copyleft OSS licenses such as the Mozilla MPL license, with license requirements that may be acceptable depending on the proposed use of the OSS in question.
• RED: includes “strong” copyleft OSS licenses such as GPL, LGPL, and Affero GPL and any other license not designated GREEN or YELLOW. By default, RED licenses are strictly prohibited without specific approval from the legal team for special circumstances.

Establish an Approval Process

While a company may choose to pre-approve certain OSS licenses (e.g., GREEN licenses or others used only internally),¹⁰ other OSS should be subject to a clearly defined approval process.

Requests to approve YELLOW- or RED-licensed OSS should be submitted to a review committee comprised of relevant personnel (e.g., legal, engineering, IT, and security). Well-designed OSS request templates should be used to gather relevant details based on the proposed OSS and license, such as the license type, impacted systems/products, proposed integration or usage with the company’s proprietary code, whether (and how) the OSS will be modified or distributed or made available to others. The review committee should seek clarifications and additional information as needed. Since OSS license compliance may depend on how software is engineered, the OSS policy should require a new approval request if there is a change in how OSS is to be used or engineered (i.e., blanket approvals should be limited).

Implement Regular Code Scans and Checklists

Regular code scans should be conducted throughout the software development process to ensure OSS components are tracked and accounted for and OSS licenses complied with. If a code scan identifies an OSS issue or an undisclosed use of OSS, company stakeholders can identify potential resolutions in real time. In addition, OSS license compliance checklists should be developed and completed before the release of new software products, or updates to existing products. This is critical even for non-restrictive, permissive OSS licenses, since the license granted is generally contingent upon compliance with applicable notice and attribution requirements.

Manage Third-Party Vulnerabilities

Many companies rely on third parties to develop or maintain their software or to supply key hardware components of their products. Accordingly, care must be taken to ensure that collaboration, vendor, consulting, and development agreements require suppliers to inform the company of all OSS proposed to be used in the applicable project and to obtain the company’s approval of the type and nature of such desired use. Companies should consider making “clean” OSS code scans part of their deliverable acceptance criteria. These steps are essential for companies to avoid unwittingly becoming subject to copyleft and other OSS license requirements that could be inconsistent with its business objectives.

Conduct Trainings and Educate Personnel

An OSS policy is unlikely to be effective if it is not known to and understood by the individuals subject to it. Accordingly, an OSS policy should be designed for ease of use, and, when finalized, communicated to all relevant personnel. Just as companies conduct regular trainings related to cybersecurity and harassment in the workplace, OSS training for programmers and others involved in software development is critical. This training should be repeated and updated periodically to address new developments related to OSS (e.g., the release of a new version of a popular OSS license, a decision interpreting the terms of an OSS license).

Best Practices and Pitfalls to Avoid

Below are key OSS usage pitfalls and suggested practices to help mitigate or avoid them.

Unplanned Inclusion of Copyleft OSS into Proprietary Code

This pitfall may occur during development when developers combine copyleft OSS with a company’s proprietary code. As noted above, this may lead to it becoming “infected” by copyleft requirements. This not merely a theoretical legal risk -- as the Cisco example discussed above illustrates, the unintended consequences of an oversight can be devastating.

Periodic code scans coupled with an effective OSS policy can help minimize this risk so that prohibited OSS is identified earlier in the development process. Conducting regular training programs will also help ensure that engineers are mindful of the types of OSS licenses and the pitfalls of each.

Failure to Comply with Attribution or Notice Requirements

This pitfall most often occurs at product launch and results from developers not being aware of (or paying attention to) OSS license requirements. Requiring completion of a compliance checklist during the product release cycle can mitigate this risk by verifying necessary attribution and notice requirements are satisfied.

Failure to Update Company’s OSS Use Policy

An OSS policy should be treated as a living, breathing document that must be updated as needed to account for changes in the company, security risks and the like. This can be achieved by calendaring review of the company’s policy to coincide with review of other key company policies that should be regularly updated, such as those governing disaster recovery and business continuity.

Failure to Follow Company’s OSS Policy

To be effective, an OSS policy must be followed. Making regular code scans a part of the company’s software processes, and making programmer attendance at trainings and compliance with OSS approval requirements a metric to be discussed during performance reviews, can be useful ways to ensure greater OSS policy adoption and accountability for OSS use.

Taking a Reactive Rather Than a Proactive Approach to OSS Management

Adopting and following an OSS policy allows companies to be proactive about their OSS use management. Companies can avoid OSS problems and address them promptly when they arise by educating employees about OSS issues, requiring approvals to be secured for riskier types of OSS use, ensuring license requirements are met before a product is released, and tracking OSS use and vulnerabilities through regular scans and audits. Yet until a crisis arises, company stakeholders may be unaware of how their companies are using OSS and the risk or implications of such use.

For example, a potential acquirer of a business may back out of the deal or demand a significant sale price reduction if it discovers that software presumed to be proprietary is likely subject to copyleft requirements or the company has severe OSS compliance issues. A reactive approach leaves little time to remediate issues and can undermine investor and customer confidence in the company or its products.

Conclusion

The bulk of today’s software incorporates or uses OSS. In the current technological environment, it is essential that in-house counsel and management be attuned to the risks associated with OSS use. Companies should prioritize cultivating both a greater sense of accountability among developers as well as robust institutional safeguards to foster responsible OSS use and compliance. OSS can be a valuable tool; tracking and managing its use does not mean it must be avoided at all costs. Rather, by having an effective OSS policy and following the practices outlined above, companies can reap the benefits of OSS while protecting the value of their own assets and mitigating security and legal risks.

 

¹“Source code” refers to software code that is in human readable form. Source code specifies concrete actions to be performed by a computer to achieve a desired purpose, which is converted into executable code that can be run by a computer.
²The Open Source Initiative (OSI) defines as “copyleft” any licenses “that allow derivative works but require them to use the same license as the original work”. This type of license is sometimes also called “viral” since it may cause proprietary code to become “infected” by the copyleft effects of an OSS license. By contrast, a “permissive” license “guarantees the freedoms to use, modify, and redistribute, but [ ] permits proprietary derivative works.” See Open Source Initiative FAQs available at https://opensource.org/faq#.
³Restricting access to source code is important to commercial software vendors, in part, so that they maintain control over their software and the secrecy of the algorithms, designs, and trade secrets embodied therein.
⁴Synopsis 2022 Open Source Security and Risk Analysis Report.
⁵OpenLogic 2022 State of Open Source Report.
⁶A full description of OSS licenses is beyond the scope of this article. For more information, see Derek Schaffner, “The Risks of Open Source Software in Outsourcing Transactions,” Business and Technology Sourcing Review, https://m.mayerbrown.com/Files/Publication/891b2c9a-ceff-4ae9-be20-d5f879bc3927/Presentation/PublicationAttachment/f9a67ec3-5786-4c9c-8d46-9cf97b5efe5f/ART_RISKSOFOPENSOURCE_0308.PDF.
⁷For example, following Russia’s invasion of Ukraine in 2022, activist programmers vandalized a frequently used piece of OSS code. Users’ IP addresses were scanned when they downloaded an update to the software and if the IP address came from Russia or Belarus, the code would then deploy a malicious data wiper to delete all system files and replace them with a heart emoji. This type of malware is sometimes referred to as “protestware” and the perpetrators as “hacktivists.” See “Russia’s Largest Bank Tells Its Clients to Delay Downloading Software Updates After ‘Protestware’ Attacks Target Russian Users” available at https://fortune.com/2022/03/22/what-is-protestware-russia-ukraine-sberbank-software-open-source/.
⁸See, e.g., “Patrick McHardy and Copyright Profiteering” available at https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering.
⁹See “FSF Settles Suit Against Cisco” available at https://www.fsf.org/news/2009-05-cisco-settlement.html.
¹⁰Even if a given OSS license is considered pre-approved in an OSS policy, the use of the OSS should be documented and tracked by the company. This should include verifying how license requirements will be met, and developing a database of OSS to facilitate security patching.