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, the technical and somewhat convoluted licensing conditions that could pose compliance challenges?
The main problem in this context is that open source licenses are subjective. Their interpretation depends on the technical usage of the licensed software. Therefore, it’s difficult to determine the legal risks of using open source software, especially for developers, who are not usually legal experts. What developers need is a broad classification of licenses based on the risks they pose in terms of legal compliance.
Here, we’ve categorized the most popular open source licenses into three broad groups depending on their terms and conditions and their potential legal risks.
Following is a list of the most popular open source licenses used by developers and their risk classification as described above. This classification is only a guideline and should not be used to make decisions about using open source software governed by each license. Developers should consult their legal/technical teams for further guidance regarding license compliance.
|2||GNU General Public License (GPL) 2.0||18%||High|
|3||Apache License 2.0||14%||Low|
|4||GNU General Public License (GPL) 3.0||7%||High|
|5||BSD License 2.0 (3-clause, New or Revised)||6%||Low|
|7||Artistic License (Perl)||4%||Medium|
|8||GNU Lesser General Public License (LGPL) 2.1||4%||High|
|9||GNU Lesser General Public License (LGPL) 3.0||2%||High|
|10||Eclipse Public License (EPL)||1%||Medium|
|11||Microsoft Public License||1%||Medium|
|12||Simplified BSD License (BSD)||1%||Low|
|13||Code Project Open License 1.02||1%||Low|
|14||Mozilla Public License (MPL) 1.1||<1%||Medium|
|15||GNU Affero General Public License 3.0 or later||<1%||High|
|16||Common Development and Distribution License||<1%||Medium|
|17||Do What the F**k You Want To Public License||<1%||Low|
|18||Microsoft Reciprocal License||<1%||High|
|19||Sun GPL with Classpath Exception 2.0||<1%||High|
These licenses don’t make the top list, but they’re still in wide use.
|Apache License 1.1 (Historic)||Low|
|Apache License 1.0 (Historic)||Low|
|Boost Software License 1.0||Low|
|Common Public Attribution License 1.0 (CPAL-1.0)||Medium|
|Common Public License||Medium|
|IBM Public License 1.0||Medium|
|Mozilla Public License 1.0||Medium|
|Mozilla Public License 2.0||Medium|
|Netscape License 1.1||Medium|
|Creative Commons Attribution Non-Commercial 3.0||High|
|European Union Public License 1.1||High|
|GNU General Public License 1.0||High|
|Creative Commons Licenses||Varies|
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 basically means that you can use and change the open source software as needed as long as you keep the copyright notices intact. Some top open source licenses in this category are the Apache and MIT licenses. We rate permissive licenses as LOW risk licenses.
Semi-permissive licenses usually require that if you modify the open source code, you make these modifications 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). The most popular open source licenses in this category include the Mozilla and the Eclipse Public Licenses. We rate semi-permissive licenses as MEDIUM risk licenses.
Some top open source licenses, such as GPL 3.0 and AGPL, are quite restrictive. Depending on how you integrate the 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.
Black Duck software composition analysis enables you to discover open source components in your proprietary software and their corresponding open source licenses and vulnerabilities to help mitigate the legal and security risks. Black Duck applies state-of-the-art scanning mechanisms to find the most comprehensive list of open source software (both source and binary) used in your software. Furthermore, Black Duck provides capabilities to contextualize operational risks originating from various licenses and security vulnerabilities through a rule-based engine.
This post was originally published Dec. 30, 2016, and was refreshed Oct. 21, 2019.