Subscribe
Software supply chain management requires license as well as security compliance
Effective open source management requires licensing as well as security compliance. Youāre using open source components and libraries to build software and know those components are governed by open source licenses, but do you know those licenses details? Perhaps more importantly, are your executives and legal counsel aware of those details in relation to your proprietary software?
Even one noncompliant license in your software could result in legal issues, loss of lucrative intellectual property, time-consuming remediation efforts, and even delays in getting a product to market. As detailed in the 2025 āOpen Source Security and Risk Analysisā (OSSRA) report, 56% of customer applications had license conflicts, opening them up to those potential scenarios.
Best practices for open source license management in software supply chain governance
The report outlines several best practices when it comes to managing your open source.
- 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.
- 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 2024 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 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 2025 OSSRA report, an annual compilation of audits of commercial software conducted by the Black Duck Audit 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 2024
| 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 | ISC License | Low | Yes |
| 6 | Public Domain* | Varies by use | No |
| 7 | GNU Lesser General Public License v2.1 or Later | High | Yes |
| 8 | The Unlicense | Low | Yes |
| 9 | Creative Commons Zero v1.0 Universal | Varies by use | No |
| 10 | Mozilla Public License 2.0 | Medium | Yes |
| 11 | SIL Open Font License 1.1 | Low | Yes |
| 12 | BSD Zero Clause License | Low | Yes |
| 13 | Creative Commons Attribution 4.0 | Varies by use | No |
| 14 | Python Software Foundation License 2.0 | Low | Yes |
| 15 | zlib License | Low | Yes |
| 16 | Creative Commons Attribution 3.0 | Varies by use | No |
| 17 | GNU Lesser General Public License v3.0 or Later | High | Yes |
| 18 | GNU General Public License v2.0 or Later | High | Yes |
| 19 | Do What The F*ck You Want To Public License | Low | No |
| 20 | Mozilla Public License 1.1 | Medium | Yes |
*Open source Component includes a statement that it is in the public domain but does not use a specific public domain license.
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 if 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: Weak Copyleft licenses
Weak copyleft 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 semi-permissive licenses as medium-risk licenses.
High risk: Reciprocal/Copyleft 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.
Unsurprisingly, given its #1 position, the MIT license was found in 92% of the open source audited for the 2025 OSSRA report. If your software contains open sourceāand according to the 2025 OSSRA report, 97% of commercial software doesāyouāll likely find the MIT license in your software. 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 license risk can vary depending on usageāone of the reasons the CC organization recommends using licenses specifically written for open source use rather than its licenses. While many developers do use CC licenses for documentation, some also inadvertently (usually by including a code snippet) or deliberately apply a CC license to their code, which can become a concern from a legal standpoint, especially during M&A transactions.
How to manage open source license risk in the software supply chain
If 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 7.8 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 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 concerning open source licenses, 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 M&A due diligence.
- 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
The bottom line is that 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.
What's in your code?
Explore insights into the current state of open source security and get recommendations for securing your open source supply chain
Download the report
Continue Reading
Six takeaways from the 2025 āOpen Source Security and Risk Analysisā report
Feb 25, 2025 / 5 min read
Forrester recognizes Black Duck as a Leader in software composition analysis
Nov 13, 2024 / 3 min read
