Posted by Baljeet Malhotra on December 30, 2016
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 open source software may be governed by different types of 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 open source 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.
Permissive 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.
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 open source licenses. 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.
Some 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 open source 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||http://opensource.org/licenses/BSD-2-Clause|
|3-Clause BSD (“New” or “Revised”) License||LOW||http://opensource.org/licenses/BSD-3-Clause|
|Apache License 2.0 (Current)||LOW||https://www.apache.org/licenses/LICENSE-2.0|
|Apache License 1.1 (Historic)||LOW||https://www.apache.org/licenses/LICENSE-1.1|
|Apache License 1.0 (Historic)||LOW||https://www.apache.org/licenses/LICENSE-1.0|
|Boost Software License 1.0||LOW||http://www.boost.org/users/license.html|
|Code Project Open License (CPOL)||LOW||http://www.codeproject.com/info/cpol.aspx|
|Common Development and Distribution License 1.0 (CDDL-1.0)||MED||http://opensource.org/licenses/CDDL-1.0|
|Common Public Attribution License 1.0 (CPAL-1.0)||MED||http://opensource.org/licenses/CPAL-1.0|
|Common Public License||MED||http://opensource.org/licenses/cpl1.0.php|
|Eclipse Public License 1.0||MED||http://www.eclipse.org/legal/epl-v10.html|
|IBM Public License 1.0||MED||http://opensource.org/licenses/IPL-1.0|
|Mozilla Public License 1.0||MED||https://www.mozilla.org/MPL/1.0/|
|Mozilla Public License 1.1||MED||http://www.mozilla.org/MPL/1.1/|
|Mozilla Public License 2.0||MED||http://www.mozilla.org/MPL/2.0/|
|Netscape License 1.1||MED||http://www.mozilla.org/MPL/NPL/1.1/|
|Creative Commons Attribution Non-Commercial 3.0||HIGH||http://creativecommons.org/licenses/by-nc/3.0/legalcode|
|European Union Public License 1.1||HIGH||http://opensource.org/licenses/EUPL-1.1|
|GNU Affero General Public License 3 (AGPL-3.0)||HIGH||http://www.gnu.org/licenses/agpl-3.0.html|
|GNU General Public License 2.0||HIGH||http://www.gnu.org/licenses/gpl-2.0.html|
|GNU General Public License 3.0||HIGH||https://www.gnu.org/copyleft/gpl.html|
|GNU Library or “Lesser” General Public License 2.1||HIGH||https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html|
|GNU Library or “Lesser” General Public License 3.0||HIGH||http://www.gnu.org/copyleft/lesser.html|
|GNU General Public License 1.0||HIGH||http://www.gnu.org/licenses/gpl-1.0.html|
|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’s Hub 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.
Get the latest Software Integrity news, thought leadership, and more.