Estimated Read Time: 4 minutes & 35 seconds

Open Source Software Legal Risks

I recently read a great blog post titled “Open-Source Security: How Digital Infrastructure Is Built on a House of Cards” by Fordham law professor Chinmayi Sharma. She argues that open source code is a public good just like our national physical infrastructure of highways, roads and bridges. And just like other public goods, there is a free loader issue in which many irresponsible consumers are not incentivized to contribute to it’s security & maintenance. Therefore she advocates for government support to maintain & secure the most critical open source libraries.

As I continued to educated myself on the history of open source, I was intrigued to learn more about their legal licenses and ramifications to companies.

This blog post is meant to capture my notes and clarify my own thinking around the topic, but hopefully it’s helpful to anyone else who is also curious.

I focus only on the licensing aspect of open source usage and will dive into the security vulnerabilities aspect in a separate blog post.

Table of Contents

• Open Source Software Legal Risks

  • What are Open Source Software Licenses?

  • Legal Risks:

  • Layers of Open Source Dependencies:

  • How to Manage This Risk?

  • Other Blog Posts & Articles:

  • Top 20 Open Source Licenses 2022-23

What are Open Source Software Licenses?

Open Source Licenses give the user the legal right to use, modify, and share the software code. This includes any components from open source code as well as snippets.

There are thousands of different types of licenses but the majority fall in to two categories:

• Permissive Licenses: The least restrictive type of license. Users only have to include attribution of the open source code to the authors. Examples of how companies can provide this attribution is Google Chrome, which lists all of the open source components that were used to build the browser software and their associated licenses for end users to easily access. See chrome://credits/

• Restrictive Copyleft Licenses: these open source legal licenses force any companies who use the open source code to also make their product open source in the same way. Some examples of these types of licenses include GNU General Public License (GPL), Affero GPL (AGPL) and Mozilla Public License (MPL).

Legal Risks:

If a company uses open source code with a more restrictive Copyleft type licenses, they need to be aware of the following risks:

• Liability Risk: Companies can be sued for financial liability by the creator of open source code that they used if it falls under certain restrictive licenses.

• Forced to Rewrite Portions of their Product: They may be forced to rewrite components of their product if they are found in breach of opens source licenses.

• IP Risk: if a company uses open source code with a restrictive Copyleft license (examples are the common GPL licenses), then they may not be able to protect their IP and can be forced to also provide their commercial code as open source.

• Copyright Infringement Issues

• Cease & Desist Orders

• Breach of Contract

• Financial Penalties & Restrictions: companies can face costly penalties and restrictions on selling their products if they are found in breach of licenses.

• Negative Press Coverage & Reputation Damage

Layers of Open Source Dependencies:

Many open source libraries use components from other open source libraries creating what is commonly described as a House of Cards similar to the layers of an onion.

For example, direct dependencies are the open source code that a commercial product directly uses. While transitive dependencies are open source code that is one layer deeper - open source code being used by open source code.

This makes it tricky for companies to get visibility into the full stack of licenses that are applicable to their product and their associated legal requirements.

For example, what if there are conflicting licenses - an open source library with a permissive license includes components that have a copyleft license. Which license prevails?

How to Manage This Risk?

Best practices to address this risk will require people, process & tools.

The first step is to establish a comprehensive open source policy. Companies should create a policy that covers all aspects of open source software usage. This includes defining a list of pre-approved open source licenses that are compatible with the company's business model. The policy should require approval for using licenses not on the pre-approved list, outlining the process for getting approval.

Using a Software Composition Analysis (SCA) Tool, (I’m biased as I currently work at Synopsys who sells Black Duck SCA) to teams can scan and identify all open source components within the codebase. The tool should catalog the associated licenses and compare them against the company’s approved license list. Ideally it would also be integrated into the CI CD pipeline for real time compliance checking (in addition to identifying security issues).

It’s also important to have Employee Awareness and Training. This should be tailored trainings for different team members such as developers, project managers, and legal folks. Focus on the risks associated with OSS, the nuances of various licenses, and the company’s specific OSS policies.

When acquiring a company, perform a thorough M&A OSS Assessment of the target’s open source usage. This includes evaluating the potential technical debt and legal risks associated with their OSS components and ensuring that any OSS licenses are compatible with the acquiring company’s policies.

Companies can also Implement Continuous Monitoring and Compliance Checks. These are automated alerts within your SCA tool to notify relevant teams when non-compliant licenses are detected. This allows for action to remediate or replace OSS components that violate company policy. It’s also helpful to schedule regular audits of OSS usage to ensure ongoing compliance with the company’s OSS policy.

Finally, it’s important to provide guidance to devs for contributing to open source. Establish clear guidelines for employees contributing to external OSS projects. This should cover intellectual property considerations, confidentiality obligations, and how to properly attribute work.

Hope this articles been helpful to anyone diving into the legal aspects of open source software!

Other Blog Posts & Articles:

• Top Open Source Licenses and Legal Risk for Developers

• The Legal Side of Open Source

• Open Source Licenses to Avoid: Exploring Legal Risks

• Open Source Software & Litigation Risks

Top 20 Open Source Licenses 2022-23

(From Synopsys Open Source Security Risk Analysis Report)