Skip to main content

License Policies

The license policy threat level (risk) rankings are based on the generalized information below, and the Sonatype categorization of license obligations.

Note

References to open source software (“OSS”) license agreements included in license threat groups or IQ policy configurations do not constitute legal advice or guidance. You are responsible for seeking appropriate legal advice regarding your rights and obligations set forth in any such OSS license agreement.

Policy

Threat

Categories

Detection

License-None

9

Distributed

Hosted

  • The component does not have a license or an error in the data

License-Threat Not Assigned

7

Distributed

Hosted

  • The license was not assigned to a threat group

  • License Threat Group is [unassigned]

License-Banned

10

All

  • License Threat Group is Banned

  • Commonly determined by organizations as not allowed in any situation

License-Copyleft

8

Distributed

  • License Threat Group is Copyleft

License-Commercial

7

Distributed

Hosted

  • License Threat Group is Commercial

License-Non-Standard

5

Distributed

  • License Threat Group is Non-Standard

License-Modified Weak Copyleft

5

Distributed

Modified

  • License Threat Group is Modified Weak Copyleft

License Exceptions

When multiple licenses are present, it may not be clear which licenses are effective for your use case. In some cases, the reported effective licenses may differ from the findings of your legal team. Tracing where the license was discovered/reported for the component and research on the component's development website may be required. When a discrepancy is discovered, you may need to override the reported license with the recommendation from your legal team.

  • Choosing the least restrictive license when the component is dual licensed.

  • Overriding inaccurate license data.

  • The organization is willing to accept the risk.

Banned Licenses

Licenses in this category are often determined to present too great of a risk to be used in any context. This may be due to commercial obligations (you must purchase a license) or present obligations which are too restrictive for organizational use. Always consult with your legal team regarding the effective license to use.

  • A justification should always be provided in all exception requests attached to any internal legal policy.

Unknown License

Some OSS software includes a URL where the reported license is posted. This practice presents its own type of risk, as changes on their website could be interpreted to retroactively replace the license for previously published components. Sonatype data does capture the license data internally, but the component will be reported as License-None because a dynamic URL is not a valid license. You will need to consult with your legal team on their policy for selecting the applicable license for these components. Exceptions are made by selecting the appropriate license for usage going forward.

  • Select the appropriate reported license from the developer's website.

No License

The license on open source grants or restricts the right to use the project within your applications. OSS components without a license present a significant risk as it falls under copyrighted works by default. Consult with your legal team before making any exceptions or avoid using it altogether. Alternatively, consider making a request to the project owners to add an acceptable license.

  • May be common in legacy components.

  • Be careful that the selected or overridden license information is correct for the version used.