Software Integrity Blog


Classification of open source licenses: A developer’s perspective

Classification of open source licenses: A developer’s perspective

Throughout my career, I have used various open source libraries (software or freeware) to build software systems primarily for data management and analytics applications. I knew the software may be governed by different types of open source licenses, but I did not necessarily know the details, in particular about those technical and somewhat convoluted licensing conditions that could pose compliance challenges.

The main problem in this context is that licenses are subjective and their interpretation depends on the technical usage of the corresponding open source software. Therefore, it’s difficult to determine the level of legal risks (even before knowing the precise compliance issues) involved in using open source software. In general, what helps developers (who are usually not legal experts) regardless of how they are using or integrating open source software, is a broad classification of licenses based on the risks they pose in terms of legal compliance.

Any classification (legal or technical due diligence aside) is going to be subjective at some level. However, depending on the licensing terms and conditions and the risks they pose in the context of technical legal compliance, many licenses can be broadly categorized into three basic groups. Many thanks to my former colleague Stefan Gustafsson for initial work on the license classification problem.

Low risk permissive open source licenses

Permissive open source licenses generally do not have real limiting conditions. Rather they usually include a not so trivial requirement of keeping a copyright notice in the distribution of the corresponding open source software. This basically means that you can use the open source software as needed (while making any changes) as long as you keep the copyright notices intact. Some of the licenses that can be grouped into this category are the Apache and MIT licenses. We can rate permissive licenses as LOW risk licenses.

Medium risk semi-permissive licenses

Semi-permissive licenses usually require that if you make modifications to the underlying computer programs (i.e., software codes) these modifications shall be made available under the terms of the given license. This means that if you modify an open source software under such a license, then you may be required to provide access to the source code of the modifications and make the relevant source code available under the license. Some of these licenses explicitly define what exactly a modification means, for instance, copying unmodified open source code into proprietary code can be treated as modification. In order to comply with the obligations in this scenario, the developer has to release the source code (original, modified and newly added). Some of the licenses that can be grouped into this category are the Mozilla and the Eclipse Public Licenses. We can rate semi-permissive licenses as MEDIUM risk licenses.

High risk restrictive licenses

Some open source licenses such GNU GPL and GNU LGPL are quite restrictive in terms of viral, copyleft and hereditary characteristics. Depending on the technical integration of the open source software with a proprietary software, there is a significant risk in using such open source software. In a worst case scenario, the developer may be required to release the proprietary software under the license — royalty free. We can rate restrictive licenses as HIGH risk licenses.

Following is the list of most frequently used open source licenses (but it’s not an exhaustive list) used by various developers and their classification based on the three categories of risk described above. This classification is only a guideline, and should not be used for the purpose of making decisions while using open source software (governed by the corresponding license). Developers should consult their legal/technical teams for further guidance regarding license compliance.

License Name Risk Level License Source
2-Clause BSD (“Simplified” or “FreeBSD”) License LOW
3-Clause BSD (“New” or “Revised”) License LOW
Apache License 2.0 (Current) LOW
Apache License 1.1 (Historic) LOW
Apache License 1.0 (Historic) LOW
Boost Software License 1.0 LOW
Code Project Open License (CPOL) LOW
ICU License LOW
Jaxen License LOW
MIT License LOW
Zlib/Libpng License LOW
Common Development and Distribution License 1.0 (CDDL-1.0) MED
Common Public Attribution License 1.0 (CPAL-1.0) MED
Common Public License MED
Eclipse Public License 1.0 MED
IBM Public License 1.0 MED
Mozilla Public License 1.0 MED
Mozilla Public License 1.1 MED
Mozilla Public License 2.0 MED
Netscape License 1.1 MED
Creative Commons Attribution Non-Commercial 3.0 HIGH
European Union Public License 1.1 HIGH
GNU Affero General Public License 3 (AGPL-3.0) HIGH
GNU General Public License 2.0 HIGH
GNU General Public License 3.0 HIGH
GNU Library or “Lesser” General Public License 2.1 HIGH
GNU Library or “Lesser” General Public License 3.0 HIGH
GNU General Public License 1.0 HIGH
Creative Commons Licenses VAR* *Different versions of the Creative Commons Licenses have different risk factors, you should consult IP/legal about specific versions.

Black Duck enables you to discover open source (embedded in your proprietary software) and their corresponding open source licenses and vulnerabilities to help mitigate the legal and security risks. Hub applies state of the art scanning mechanisms to find the most comprehensive list of open source software (source and binary codes) used in your software. Furthermore, Hub provides capabilities to contextualize operational risks originating from various licenses and security vulnerabilities through a rule based engine.

Learn more about Black Duck Hub


More by this author