Top open source licenses and legal risk for developers
Learn about the top open source licenses used by developers, including the 20 most popular open source licenses, and their legal risk categories.
If you’re a software developer, you probably use 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?
Open source licenses are subjective. Their interpretation depends on the usage of the licensed software. It’s difficult to determine the legal risks of using open source software—especially for developers, who are not usually legal experts. Developers need a broad classification of licenses based on the risks they pose in terms of legal compliance.
We’ve categorized the most popular open source licenses into three broad groups, based on their terms and conditions and their potential legal risks.
Top open source licenses by risk
The following is a list of the most popular open source licenses used by developers, their risk classifications, and whether the license has been approved by the Open Source Initiative (OSI). 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 have consistently indicated that the 20 most popular licenses cover 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 open source software governed by each license. Developers should consult their corporate policies and/or legal teams for guidance regarding license compliance.
| Rank | License | Risk | OSI Approved |
| 1 | MIT License | Low | Yes |
| 2 | Apache License 2.0 | Low | Yes |
| 3 | ISC License | Low | Yes |
| 4 | BSD 3-Clause “New” or “Revised” License | Low | Yes |
| 5 | BSD 2-Clause “Simplified” License | Low | Yes |
| 6 | Creative Commons Zero v1.0 Universal | Varies by usage | No |
| 7 | Generic Public Domain* | Varies by usage | N/A |
| 8 | GNU Lesser General Public License v2.1 or later | High | Yes |
| 9 | Common Development and Distribution License 1.1 | Medium | Only 1.0 |
| 10 | Eclipse Public License 1.0 | Medium | Superseded by version 2.0 |
| 11 | GNU General Public License v2.0 or later | High | Yes |
| 12 | The Unlicense | Low | Yes |
| 13 | SIL Open Font License 1.1 | Low | Yes |
| 14 | Zlib/libpng License | Low | Yes |
| 15 | Mozilla Public License 2.0 | Medium | Yes |
| 16 | Do What The F*ck You Want To Public License | Low | No |
| 17 | GNU Lesser General Public License v3.0 or later | High | Yes |
| 18 | Eclipse Public License 2.0 | Medium | Yes |
| 19 | Microsoft Public License | Medium | Yes |
| 20 | Mozilla Public License 1.1 | Medium | Superseded by version 2.0 |
*License includes a statement that the open source component is in the public domain but is not a specific public domain license such as the Unlicense or CC0.
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: Semi-permissive 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, they might consider copying unmodified open source code into proprietary code to be a modification. To comply with the license obligations, the developer 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 top 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.
How to manage open source license risk
Whether you build packaged, embedded, or commercial SaaS software, open source license compliance should be a key concern. You need to determine the license types and terms for the open source components you use and ensure that they’re 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 creating 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’s 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.
If your company plans to be involved with a merger and acquisition (M&) transaction at some point, either as seller or buyer, you’ll 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.
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 4 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.
This post was originally published Dec. 30, 2016, and refreshed July 13, 2022.
