Component License Information
In some cases, the licenses of a component is the last thing a development team will think about. This could simply be due to a misunderstanding of open source, or a situation where it’s nearly impossible to do the exhaustive research needed to determine the license for a given component, especially dependencies.
The IQ Server's can identify license issues, and indeed the default policy set includes policies for alerting on common license issues. That said, even if you haven’t built policies around licenses the Raw Data page provides license information about every component found during a scan of your application.
This license information is provided via data collected from the Central Repository, as well as research conducted by Sonatype. In addition to the license information for each component, we’ll also assess a threat of each license, based on a set of default License Threat Groups.
As with security issues, the best place to start is on the Policy-Centric page, using a Policy Type filter to narrow down to only license-related policy violations. From there, individual components can be selected and their licensing information reviewed and, when appropriate, adjusted. Alternatively, the raw license information for all components identified by Sonatype's Hosted Data Services can be viewed on the Raw Data page.
License Threat Group
License threat groups are based on the configuration for each organization or application. Additional information can be found in License Threat Groups.
How you manage your license threat groups directly impacts how threat is translated in the reports.
The Component Information Panel (CIP)
To access the CIP for a component, simply click on the component row in the Policy Violation table on the Policy-Centric page. For this section, we want to focus on the license-related information in the Component Info section, as well as the entire Licenses section.
The Component Info tab displays license information for the component in a few different places.
License Identification Types
On the left side of the Component Info section, you should pay attention to three fields, which are described below.
- Declared License: these are the licenses that the developer of the component has identified.
- Observed License: these are 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, and listed here.
License Identification Values
It's not uncommon for a single component to be subject to multiple licenses. For example, the license information might read "EPL-1.0 or LGPL-2.0+, BSD-3-Clause". In this condensed expression, the word "or" denotes a choice the code author grants, meaning a consumer of the code can choose to either abide by the terms of EPL-1.0 or LGPL-2.0+. The "+" (plus) character at the end of a license name is short for "or newer/later versions", so for the example of "LGPL-2.0+" one is again given the choice of LGPL-2.0 or LGPL-2.1 or LGPL-3.0 or whatever newer versions of LGPL the future provides. Lastly, the "," (comma) in the license information denotes a logical conjunction/AND, meaning these license terms apply additionally. Summing up, the example component license "EPL-1.0 or LGPL-2.0+, BSD-3-Clause" conveys that some parts of the component are subject to EPL-1.0 or LGPL-2.0 or newer versions thereof and some parts of the component are subject to BSD-3-Clause.
In cases where there is no declared and/or observed licenses, a message will be displayed. There are several options, each with specific meaning:
- No Source License: sources were provided, but there was no license data found.
- No Sources: indicates we have no sources for the component.
- Not Declared: indicates nothing was declared by the author/developer.
- Not Provided: will appear when the license is actually null, and is unique to claimed components, but might also happen while new components are being processed by Sonatype.
- Not Supported: indicates Sonatype or the target ecosystem does not currently support automated license collection for this component format.
The graph itself is laid out like a grid, with each vertical piece representing a particular version. The selected version being identified by a vertical line.
While the information displayed in the graph includes information about popularity and violations of all types of policy, right now, just take a look at the policy threats for licensing (Click on the Details link to show policy threats for each policy type). The heatmap provides a quick way of identifying a component version with a suitable license.
Editing License Status and Information
Editing a license can be used for different purposes. One addresses the workflow of your research into a license related issue, while the other allows you to completely override a license all together. We’ll cover all this below, but first let’s take a look at the information displayed.
After clicking on a component in the list, and then the Licenses tab of the CIP, the left side of the CIP displays the license(s) declared by the developer of the component, those that have been observed, and what is considered effective (a combination of the previous two). That is, unless they have been manually overridden or a specific license has been selected.
Next to each of these licenses is a box, displaying the severity of this license's Threat Group. This list can get long, so you may have to scroll to see all the licenses. Then, to the right of the license list, there are four drop down lists.
Scope allows you to apply the license status to this component within one of several scopes:
- only this application by choosing the application name
- any application in the current application’s organization by choosing that organization's name
- system-wide by choosing "Root Organization"
As we mentioned previously, Status provides a way to track your research, override a license, or select from an option. The available options are included below.
- Open: This is default status, and will be included in the count of license issues.
- Acknowledged: Acknowledged indicates the issue is being researched, and will still be included in the count of license issues.
- Overridden: This status will allow you to select one or more licenses from the License(s) dropdown (located just below the Status dropdown). This will override any licenses that have been declared or observed.
- Selected: In cases where there are multiple licenses, this option will populate the License(s) dropdown with any licenses found in the component, declared or observed. Multiple licenses can be selected.
- Confirmed: Confirmed simply indicates that the license(s) found are indeed correct, and will be included in any count of license issues.
The License(s) drop down only displays given that a status of selected or overridden has been chosen. Given that it will present either a list of all licenses (if Overridden is chosen) or only the declared and observed licenses (if Selected is chosen). The license that is chosen will be displayed in the Effective License field in the Component Info section of the CIP. In addition, any overridden/selected license will be indicated with a label of same name, next to the license in this field.
A comment is not required, but is a good element to include whenever you are making changes to the License Status. This is because it provides a way to understand, as well as audit, the decisions made to change a license status. This comment will be included with the record in the Audit Log section of the CIP.
Once you have made all your selections, and entered any necessary comments, click the Update button to save the License Status change.
Any changes to licenses are visible only when the application is re-analyzed (via the re-evaluation button or a new evaluation being triggered from CI, CLI, policy monitoring, etc).