Top open source licenses and legal risk for developers

Software supply chain management requires license as well as security compliance

If you’re a software developer, you’re probably using open source components and libraries to build software. You know those components are governed by different open source licenses, but do you know all the license details?

In particular, do you know the sometimes-convoluted licensing conditions that could pose compliance challenges for your organization? Even one noncompliant license in your software can result in legal action, time-consuming remediation efforts, and delays in getting your product to market—all reasons why ensuring open source license compliance is important.

Best practices for open source license management in software supply chain governance

• Identify all third-party components. Conduct a thorough inventory of all third-party software components in your software, including both open source and commercial software.
• Be wary of AI-assisted coding tools, which can produce code with the potential for license violations and intellectual property infringement. We are at the very begin­ning of prac­tical, wide­spread AI-assisted coding, and the legal and ethical ramifications of AI-produced code remains an open question—one that will likely have to be settled by the courts and government regulation.
• Assess license terms. Evaluate the license terms and conditions of each component and assess whether they are compatible with the intended use of the product.
• Check for compatibility between licenses of different components, as some licenses may not be compatible with each other.
• Use automated scanning tools to identify and track license obligations and restrictions for each component.
• Implement a process to ensure ongoing license compliance, including regular license scans and reviews of license compliance procedures.
• Establish a review process and workflow for new or unfamiliar licenses.
• Ensure effective communication between legal, technical, and business stakeholders to properly prioritize and execute license clearance efforts.
• Document all license clearance activities, including license assessments and compliance procedures, to provide a record of compliance efforts and facilitate future audits.
• The bottom line is that many open source licenses are open to interpretation based on the usage of the software. It can be very difficult to determine the legal risks of using open source software—especially for developers, who are not usually legal experts.

Open source licenses by risk

We’ve categorized the most popular open source licenses of 2023-24 into three broad groups based on their popularity, terms and conditions, and potential legal risks. This list of the 20 most popular open source licenses used by developers during 2022-23 also includes their risk classifications and whether the license has been approved by the Open Source Initiative (OSI). The OSI license review process ensures that software and licenses labeled as open source conform to community standards and helps minimize license duplication and proliferation.

Data for the list came from the 2024 “Open Source Security and Risk Analysis” (OSSRA) report, an annual compilation of audits of commercial software conducted by the Black Duck® Audit Services team. Black Duck audits over the years consistently show that the 20 most popular licenses are found in approximately 98% of the open source in use.

The risk classifications are only a guideline and should not be used to make decisions about using the open source software governed by each license. Developers should consult their corporate policies and/or legal teams for guidance regarding license compliance.

Top 20 Open Source Licenses 2022-23

*Component includes a statement that it is in the public domain but does not use a specific public domain license such as the Unlicense

What are low-, medium-, and high-risk open source licenses?

Low risk: Permissive licenses

Permissive licenses generally do not have many limiting conditions. Rather, they usually require that you keep the copyright notice in place when you distribute your own software. This means you can use and change the open source software as needed as long as you keep the copyright notices intact. MIT and Apache licenses, the two most popular licenses currently in use, are in this category. We rate permissive licenses as low-risk licenses.

Medium risk: Semipermissive licenses

Semipermissive licenses usually require you to make any modifications to the source code available under the same terms of the given license. Some of these licenses explicitly define what a modification is. For instance, a license might cite copying unmodified open source code into proprietary code as a modification. To comply with the license obligations, you would have to release the source code (original, modified, and newly added). Popular open source licenses in this category include the Mozilla public license. We rate semipermissive licenses as medium-risk licenses.

High risk: Restrictive licenses

Some popular open source licenses, such as the GNU General Public License v2.0 or later and GNU Lesser General Public License v3.0 or later, are quite restrictive. Depending on how you integrate open source software with your proprietary software, you may face significant risk. In the worst-case scenario, you may be required to release your proprietary software under the same license—royalty-free. We rate restrictive licenses as high-risk licenses.

What are the MIT and CC licenses?

Unsurprisingly, given its #1 position, the MIT license was found in 92% of the open source components/dependencies audited for the 2024 OSSRA report. You can be nearly certain that if your developers use open source or if you include third-party components in your software, you’ll likely find the MIT license. As a permissive license that permits reuse within proprietary software, the MIT license has high compatibility and low risk with other software licenses.

On the other hand, Creative Commons (CC) licenses, are specifically not recommended by their creators for software or hardware use. As the CC FAQ notes, “unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software.”

Many developers do use CC licenses for documentation, but some also inadvertently (usually through the use of a code snippet) or deliberately apply a CC license to their code. For example, the Creative Commons Attribution-ShareAlike (CC-SA) license can be interpreted in some situations as having a similar viral effect as the GNU Public License (that is, any work derived from a copyleft-licensed work must also be licensed under the same copyleft terms), so it can become a concern from a legal standpoint, especially during M&A transactions. As the data in the 2024 OSSRA report shows, CC-SA licenses were the top cause of license conflicts, with CC-SA 3.0 and 4.0 alone producing 33% of the license conflicts found.

How to manage open source license risk in the software supply chain

Whether you build packaged, embedded, or commercial SaaS software, open source license compliance should be a key concern for your organization. You need to determine the license types and terms for the open source components you use and ensure that they are compatible with the packaging and distribution of your software. Even companies whose software is not a commercial product and only used internally are still subject to the license terms of the open source components in their software.

The first step to managing risk is using an automated software composition analysis (SCA) tool to create an up-to-date, accurate Software Bill of Materials (SBOM) of all open source components in your software, the versions in use, and their associated licenses. Compile the license texts associated with those components so that you can flag any components not compatible with your software’s distribution and license requirements, or not compatible with licenses that may be used by other components in your software. It is important to ensure that the obligations of all licenses have been met, as even the most permissive open source licenses still contain an obligation for attribution.

Black Duck SCA enables development, security, and compliance teams to manage the risks that come from the use of open source. Black Duck’s multifactor open source detection and KnowledgeBase™ of over 6 million components can provide an accurate SBOM, including licensing information, for any application or container. And although the majority of open source components use one of the 20 most popular licenses, Black Duck provides an extra layer of information with data on over 2,500 other open source licenses that could potentially impose restrictions on the software your team writes. Tracking and managing open source with Black Duck helps you avoid license issues that can result in costly litigation or compromise your valuable intellectual property.