Top open source licenses and legal risk for developers

Learn about the top open source licenses used by developers in 2022-23, including the 20 most popular open source licenses, and their legal risk categories.

Software supply chain management needs 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 for 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 used in your software, including both open source and commercial software.
• Developers should be wary of using AI-assisted coding tools, which may 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. However, it’s an open question—one that will likely have to be settled by the courts and government regulation—on the legal and ethical ramifications of AI-produced code.
• 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 compliance process for ongoing license compliance, including regular license scans and periodic reviews of license compliance procedures.
• Implement 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 ensure a record of compliance efforts and to 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 2022-23 into three broad groups, based on their popularity, terms and conditions, and their 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 was taken from the “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 indicate that the 20 most popular licenses will be 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 or CC.

On low-, medium-, and high-risk open source licenses

Low risk: Permissive licenses

Permissive licenses generally do not have real 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 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 and the Eclipse public licenses. 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.

On the MIT and CC licenses

Unsurprisingly, given its #1 position, the MIT license was found in 70% (some 721,000) of the open source audited for the 2023 OSSRA. 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, while popular in the open source community, 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 or deliberately attempt to apply a CC license to their code, resulting in Creative Commons Attribution ShareAlike 3.0 being the top license with conflicts in 2023 OSSRA audit results.

Managing 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 used in their software.

Begin by using an automated software composition analysis tool to create an up-to-date, accurate software Bill of Materials (SBOM) of all open source components used 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 software composition analysis (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.

If your business is planning or Involved with an M&A

If your company plans to be involved with a merger and acquisition (M&A) transaction at some point, either as seller or buyer, you will want to involve your organization’s general counsel or seek outside legal advice, as understanding licensing terms and conditions and identifying conflicts among various licenses can be challenging. It’s vital to get this right the first time—especially if you build packaged or embedded software—because license terms are often more explicit for shipped software and harder to mitigate after the fact.

Knowing what open source code is in a company’s codebase is crucial for properly managing its use and reuse, ensuring compliance with software licenses, and staying on top of patching vulnerabilities—all essential steps in reducing business risk. From an M&A perspective, a code audit enables a buyer to understand risks in the software that could affect the value of the intellectual property and the remediation required to address those risks. Sellers may employ an audit proactively to avoid surprises in due diligence, particularly given the amount of unknown open source in a typical company’s code. An open source audit can be invaluable for companies wanting a better understanding of the code’s composition. Using Black Duck SCA, expert auditors comprehensively identify the open source components in a codebase and flag legal compliance issues related to those components, prioritizing issues based on their severity.

The audit discovers known security vulnerabilities that affect the open source components, as well as information such as versions, duplications, and the state of a component’s development activity. It also provides clues as to the sophistication of a target’s software development processes. Open source is so ubiquitous today that if a company isn’t managing that part of software development well, it raises questions as to how well it is managing other aspects.

If you’re on the buy side of a tech M&A transaction, an open source audit should be part of the software due diligence process. Acquirers need to identify problematic open source in the target’s code before the transaction terms are set, and a trusted third-party audit is the best way to get a deep, comprehensive view. Sellers should prepare for questions about the composition of their code and how well they have managed open source security and license risk. Proactive sellers can prepare for an acquisition by having their software audited in advance.

By identifying open source code and third-party components and licenses, an open source audit can alert your firm to potential legal and security issues in an M&A transaction. With an open source audit, you can

• Avoid surprises
• Mitigate legal exposure
• Understand risks that may affect software asset values
• Resolve potential issues before they affect the transaction
• Build appropriate protections into the deal terms
• Plan integration and remediation of seller/buyer code

Significant monetary and brand risk can be buried in the open source components of acquired code. Evaluating that risk as part of an acquirer’s due diligence must be a factor in the decision-making process of an M&A.

Learn more about Black Duck software composition analysis

This post was originally published Dec. 30, 2016, and refreshed My 19, 2023.