Popular open source software license
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.
*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.
Learn more about Black Duck software composition analysis
This post was originally published Dec. 30, 2016, and refreshed July 13, 2022.
About Open Source Licenses
Open source licenses are licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared. To be approved by the Open Source Initiative (also known as the OSI), a license must go through the Open Source Initiative’s license review process.
The following OSI-approved licenses are popular, widely used, or have strong communities:
All Approved Licenses
Many other licenses are also OSI-approved, but fall into other categories, such as special-purpose licenses, superseded licenses, or retired licenses. Complete lists that include all approved licenses are available:
The OSI maintains a FAQ, which includes a lot of useful background on open source licensing, including:
For more information about open source licenses and in particular about the Open Source Initiative’s approval process, see:
Reuse is not a matter for debate with proprietary software. When developers produce software in-house, they create a piece of intellectual property that is guarded through the restrictions of a commercial license. But as the industry evolves and adopts open source software, including as small components within a larger development product, open source software licenses take on great importance.
Enterprises and individuals have released a burgeoning volume of open source code subject to far less restrictive licensing, which often grants users rights to examine, alter, use, redistribute and even resell the code to anyone for any purpose. Open source software has had a remarkable effect on software development, as it enables contributions from a global developer community, sometimes accelerating the creation of powerful new products without a prohibitive cost or time burden.
But licenses sometimes pose challenges with open source software. There are myriad open source software licenses, and each one imposes some level of binding terms and conditions. Thus, the challenge with open source software is not only how to access or modify such code, but rather how to do so while observing the terms of these licenses, and how licenses interact with each other.
It’s easy to forget that there is a difference between open source and free or public domain software. Licenses govern open source software. There are dozens of established open source software licenses, each with its own unique, sometimes dramatically different, terms and conditions. It’s crucial that developers understand some of the most vital terms that accompany various open source licenses to avoid potential legal ramifications.
Here’s what developers need to know about five common open source software licenses.
Apache License 2.0
The Apache License 2.0 provides a broad set of guidelines that apply to both copyrights and patents. It’s unusual for open source licenses to cover both.
Apache License 2.0 conveys a perpetual, worldwide, non-exclusive, no-charge, royalty-free and irrevocable license. Users can reproduce the licensed work, prepare derivative works, publicly display or perform work, sub-license and distribute the work or changes as either source code or object code.
When open source software is released under the Apache License 2.0, developers can use the licensed software forever, anywhere, without purchase costs or royalties; and they can redistribute variations on the code under different licenses. These rights cannot be withdrawn, though there are exceptions in patent infringement cases — see section three of the license. Also, there are some requirements when redistributing the code under Apache with or without modifications, but those requirements generally relate to how the license information is displayed and how credit is provided.
There are two permutations of the BSD license, which typically applies to software with virtually no restrictions on distribution and use. BSD licenses, named after the Berkeley Software Distribution OS, are fairly prevalent, particularly for free software.
The 3-Clause BSD License, also known as the New BSD License or Modified BSD License, follows a straightforward copyright arrangement. Developers can use and redistribute software under this open source license in either source or binary forms, with or without modifications. There are only three points, or clauses, to which developers must adhere:
- users must include the copyright notice, along with the list of conditions and a standard disclaimer;
- redistributions in binary form must reproduce the copyright notice, conditions and standard disclaimer; and
- neither the copyright holder nor contributors may be used to endorse or promote products created from the code without separate consent. Therefore, a developer cannot fork the code
The 2-Clause BSD License, also called the Simplified BSD License or the FreeBSD License, simply removes the third clause regarding author/contributor promotion.
There are two versions of the GNU General Public License (GPL). The terms of the latest iteration, GPL version 3, are clear and readable overall; it allows open copy, redistribution and modification. Developers who use open source code covered by GPL version 3 can choose to charge a fee for their open source software.
However, the GPL imposes several important restrictions on developers and users. The GPL emphasizes copyleft behaviors for activities such as including linking, distribution, modification and re- or sub-licensing. Generally, copyleft clauses require that uses of the work observe the same terms and conditions to which the original code adheres. Thus, open source software obtained under GPL version 3 retains those rights indefinitely. In addition, developers must include a copy of the GNU GPL with the software as it’s redistributed and within the software itself. Other restrictions exist for source and binary software distributions under the GPL.
The GNU Lesser General Public License (LGPL) provides a slightly more permissive option than version 3. The agreement, for instance, allows linking the LGPL code with code under non-GPL licenses — a practice prohibited under GPL version 3. Consequently, developers often use LGPL when they want to allow for the use of non-GPL open source libraries, but preserve other copyleft restrictions.
The MIT license is one of the most brief and straightforward of any open source software license. This license grants broad permission for anyone to use the software without restriction; the developer can use, copy, modify, distribute, re-license and even sell the software.
The only restriction with the MIT License is that the copyright notice, permission notice and disclaimer must accompany all copies or partial copies of the software.
Mozilla Public License 2.0
The Mozilla Public License (MPL), version 2.0, is generally deemed a weak copyleft license. This open source license is somewhat more permissive than GPL in terms of linking MPL code with code under other licenses, yet it still enforces some key copyleft terms. For example, developers must release any source code that results from the project under MPL, but they can combine MPL and proprietary code, as long as the former is kept distinct. The development team can release binary files under a different license, but source code must adhere to MPL. MPL is generally regarded as compatible with GNU LPGL and GPL.
Developers can use, modify and distribute the software and protect it with a warranty, and they can even use the software in a patent. However, they must include a copyright notice, license copy and source disclosure — where the source code came from.