License Policy Governance
This document provides information to represent open-source license governance concerns implemented through the IQ Server Reference Policy. The initial sections contain license terminology used throughout the Product. The additional questions are intended to be answered by an organization’s legal representation to establish the guidelines for policy creation and license review resolution.
License Terminology
Product | Sonatype IQ Server |
|---|---|
OSS | Open Source Software |
Application Composition Report | A report generated by the Product that organizes OSS components into License Threat Groups to conduct a license-related risk analysis of those components. |
License Threat Group (LTG) | A group of OSS licenses is categorized based on the severity of risk associated with those licenses when analyzing OSS components. |
Banned License - LTG | A license determined to be not allowed for use within the application. |
Copyleft License - LTG | A license that makes an OSS component free to use but requires all modified and extended versions of the program to be provided for free as well and requires that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. The most well-known free software license that uses strong copyleft is the GNU General Public License |
Non-Standard License - LTG | An OSS license that includes non-standard licensing terms, often unique to the OSS component. An example of a Non-Standard License is the “Beerware” license, which strongly encourages users of the software to buy the author a beer should they happen to meet in person. |
Weak Copyleft License - LTG | A license that allows the software to link to the OSS components governed by it while permitting redistribution without the legal requirement that the linking software is distributed under the license; provided that any changes to the OSS components governed by the license become subject to the copyleft provisions thereof. Weak Copyleft Licenses allow programs of any license to be compiled and linked against the OSS components governed by a Weak Copyleft License and then redistributed without any re-licensing required. |
Liberal (Permissive) License - LTG | A class of licenses with minimal requirements about how the software can be redistributed, therefore making no guarantee that future generations of the software will remain free. Like Copyleft Licenses, Liberal Licenses offer freedom in terms of how the software can be used, studied, and privately modified but, unlike Copyleft Licenses, Liberal Licenses permit someone to distribute the software to restrict access to the modified source code. |
POM File (Maven) | Project manifest information is stored in a pom.xml file used for configuring and building Maven projects using OSS. POM stands for Project Object Model. |
Declared License | The license that the developer of the component has identified within the source code or on the OSS project website. |
Observed License | The licenses that have been observed during Sonatype’s research. |
Effective License | The effective license displays license information based on one of two scenarios. In cases where multiple licenses are found, including any that are observed, these will all be included as effective. If a license is selected, or overridden, then that license will be considered effective. |
Multiple Licenses | Licenses derived from different license definitions across multiple files within the component packaging. |
Dual Licenses | A situation where the component can be obtained under two different software licenses. Usually one of these licenses is an OSI-approved open-source license and the other is a proprietary license. |
No Source | A license value signifies that a particular OSS component has no source code available for analysis, meaning that no license information can be derived from the source code. |
No Source License | A license value signifying that there is no Observed License information available in the source code license headers. |
Non-Standard License | A license that does not conform to common OSS licenses as cataloged by Sonatype’s data services will require further investigation to identify. |
Not Declared | A license value signifying that a Declared License value was neither present in the POM file nor identified from the OSS project website. |
Not Provided License | A temporary state during which license information is still contained in the Sonatype data pipeline but has not yet been made available. |
Not Supported | Indicates Sonatype or the target ecosystem does not currently support automated license collection for this component format. |
License Analysis
The Application Composition Reports provide a point-in-time analysis of the licenses governing open-source software components. Sonatype extracts licenses from files contained within the components' distribution packaging and source code.
License Obligations
OSS licenses are organized into License Threat Groups that identify potential risks based on the license obligations shown below.
License Obligations | Liberal | Weak Copyleft | Copyleft | Commercial | Non- standard | Banned |
|---|---|---|---|---|---|---|
Permitted Commercial Use | x | x | x | |||
Commercial Use Forbidden | x | |||||
Permitted Distribution | x | x | x | |||
Permitted Modification | x | x | x | |||
Modification Forbidden | x | |||||
Inclusion of Copyright | x | x | x | |||
Inclusion of License | x | x | x | |||
Inclusion of Notice | x | |||||
Existing Liability | x | x | x | |||
Trademark Use | x | x | x | |||
Required Disclosure of Source Code of Modified Components | x | x | ||||
Required Disclosure of all Source Code with Distribution | x | |||||
Source Code Must be Distributed Along with Web Publication | x |
Banned, Commercial, Non-Standard, and Special licenses are not included due to the unique nature of their terms.
Sonatype Special Licenses
The License Threat Group, Sonatype Special Licenses, identifies OSS components that, based on Sonatype data, have license values of No Source, No Source License, Not Declared, and/or Not Provided License. These are components that may need additional remediation when evaluating the Application Composition Reports for the unknown risks they present.
License Risk Matrix
Application Types and Threats | Internal | Distributed | Hosted Internal Employee Access | Hosted External Consumer Access |
|---|---|---|---|---|
Liberal | --- | --- | --- | --- |
Modified Weak Copyleft | --- | Low | --- | --- |
Non-Standard | Low | Review | Low | Low |
Copyleft | Low | High | Low | Low |
No License | Low | High | Low | High |
Similar Match | Low | Medium | Low | Medium |
Unknown Component | --- | High | --- | High |
Privileged | --- | High | --- | --- |
Declared Only | --- | --- | --- | --- |
Observed Only | --- | --- | --- | --- |
No License | --- | High | --- | High |
Dual License | --- | Review | --- | --- |
License Policy Questions
When reviewing your license governance policy, we recommend documenting and sharing the answers to the following questions. This will set clear expectations for your development teams and preempt having to answer them every time they come up during the remediation process.
List applications or proprietary components in your organization’s environment that will require special approval for access and/or use or separate tracking practices.
Define what “distribution” means for applications that would trigger copyleft license provisions from open source.
Is it acceptable to rely on the Declared License if there is no Observed License data?
Is it acceptable to rely on the Observed License if there is no Declared License data?
Define the process for when the Declared and Observed licenses DO NOT match.
Is additional review/approval required?
Does one license take precedence over the other?
Should the most restrictive license be chosen regardless of location?
Define the process for when multiple Declared and/or Observed licenses DO NOT match.
Is additional review/approval required?
Does one license take precedence over the other?
Should the most restrictive license be chosen regardless of location?
Define the process for when multiple Declared and/or Observed Licenses DO match.
Is additional review/approval required?
Should the most restrictive license be chosen?
Process for consideration of dual-licensed components (e.g., either CDDL-1.0 or GPL-2.0 with class-path exception).
Is additional review/approval required?
Should the most restrictive license be chosen?
May components without license information be used?
If yes, may the component be distributed without additional review/approval?
May components identified as Similar Match be used?
Additional code that is not known.
Recompiled authentic code.
Code fixes originate from within your organization.
Define any additional license obligations that should be prohibited.
Define current LTG licenses that should be redefined.