Subscribe
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 beginning of practical, widespread 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
| Rank | License | Risk | OSI Approved |
| 1 | MIT License | Low | Yes |
| 2 | Apache License 2.0 | Low | Yes |
| 3 | BSD 3-Clause "New" or "Revised" License | Low | Yes |
| 4 | BSD 2-Clause "Simplified" License | Low | Yes |
| 5 | Generic Public Domain* | Varies by usage | Yes |
| 6 | ISC License | Low | No |
| 7 | Creative Commons Zero v1.0 Universal | Varies by usage | No |
| 8 | GNU Lesser General Public License v2.1 or Later | High | Yes |
| 9 | Mozilla Public License 2.0 | Medium | Yes |
| 10 | The Unlicense | Low | Yes |
| 11 | Zlib/libpng License | Low | Yes |
| 12 | SIL Open Font License 1.1 | Low | Yes |
| 13 | BSD Zero Clause License | Low | Yes |
| 14 | Creative Commons Attribution-ShareAlike 3.0 | Varies by usage | No |
| 15 | Creative Commons Attribution ShareAlike 4.0 | Varies by usage | No |
| 16 | GNU General Public License v2.0 or Later | High | Yes |
| 17 | GNU Lesser General Public License v3.0 or Later | High | Yes |
| 18 | Do What The F*ck You Want To Public License | Low | No |
| 19 | Python Software Foundation License 2.0 | Low | Yes |
| 20 | GNU General Public License v3.0 or Later | High | Yes |
*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[NB1] -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.
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.
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. 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. An open source audit can also 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 uncovers known security vulnerabilities that affect 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 about how well it is managing other aspects.
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 may employ an audit in advance to avoid surprises in due diligence, particularly given the amount of unknown open source in a typical company’s code.
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.
-This blog was fact checked by Mike McGuire.
Report
2024 OSSRA Report
Learn more about popular and risky open source licenses in the latest OSSRA report.
Continue Reading
Introducing fAST Dynamic: Streamlining dynamic application security testing
Mar 19, 2024 / 3 min read
