Assign a category and policy to a license combination

[DennisClark]

Note: the scope and details of this issue have changed since this original posting. See new comments below for more details.

See related issue aboutcode-org/scancode-toolkit#2897

We should assign a category+usage-policy to a license-expression to clarify license WITH exception cases.

It could be that all exceptions to a Copyleft license turn a license expression into a Copyleft-limited

It's important to clarify that the scope of this improvement is limited to "license WITH exception" cases and not more complex license expressions that express multiple licenses connected by the "AND" operator; that is, the "(license WITH exception)", ideally surrounded by parentheses, can be thought of as its own unit (a molecule?) and we can apply a category to that. Since the most common cases exist with the general rule that the category of the exception prevails over the category of the target license, we can make that the default behavior, but ultimately this should be controlled by SCTK detection rules to handle odd cases where that is not what is actually happening, for example, "exceptions" that simply tell you what you are allowed to do but don't really modify the target license terms.

[mjherzog]

This raises the question of treating a license WITH an exception as a license so that we could set a Category of Copyleft Limited for "gpl-2.0 WITH class-path-exception-2.0". We cannot anticipate all license/exception combinations but it should be pretty easy to identify the most common ones and not too difficult to add a new one that is a combination of an existing license and exception.
This ties into using Categories rather than lists of licenses for setting policy.

[DennisClark]

Here is an alternative, relatively lightweight, approach to this issue:

Introduce a new boolean indicator on the license definition: is-policy-override default=no/false/unchecked.
This would only apply to licenses where is_exception has been set to true.

When enabled (true), and this license exception is specified after a WITH operator to apply to a license, the usage policy of the exception is applied to the entire license expression when it is assigned to a package, component, or product inventory item in DejaCode. Typical usage would be a Copyleft Limited exception applied to a Copyleft license. Note that the override applies to the DejaCode object where it has been assigned, not on the license itself. 

Comments welcome!

[mjherzog]

I think that the conceptual issue is that a license with an exception is itself a compound license. I do not see this as a policy override - gpl-2.0 and gpl-2.0 WITH classpath-exception-2.0 are different licenses.
Also we probably need to align sooner than later with the SPDX terminology for License vs License Exception.

[DennisClark]

@mjherzog I am coming around to your way of thinking about this and perhaps the idea of a policy override is too simplistic. For example, the following case does not quite follow the license-WITH-exception pattern but also needs to be handled:

The recently assigned license on Sbomify is not really “open source” but is actually Source-available
https://github.com/sbomify/sbomify?tab=License-1-ov-file#readme

It consists of (apache-2.0 AND commons-clause) and while Apache 2.0 is permissive, the “Commons Clause” License Condition v1.0 is Source-available and is the prevailing category for this license expression, and it is not in the SPDX list, nor is it in the OSI list, but can be found with various notes and links in the LicenseDB:
https://scancode-licensedb.aboutcode.org/commons-clause.html

We can expect various license combinations to emerge over time and providing a table of known and interesting license expressions with their effective categories would be a useful enhancement. Design details to follow.

[mjherzog]

We probably need to think about compound licenses broadly, but also follow the SPDX exception rules so the sbomify case would be apache-2.0 AND commons-clause in the Source-Available category as you suggest. I think this is an important way that we can streamline license detection and compliance within the AboutCode stack and it does not require any changes to SPDX or other relevant standards.

[DennisClark]

Proposed new table (DejaCode object): License combinations
Main help text
A license combination identifies a compound license expression, typically of the license-WITH-exception pattern or a conjunctive expression that includes licenses of different categories, that allows you to assign a Category and Usage Policy to that license expression.
Secondary help text
A license combination is not generally meant to identify disjunctive license expressions (see "License choices").

Elements:
combination
category
usage_policy
and the standard history fields

Anticipated design issues:

• Should a conjunctive license expression get multiple combination entries in the table to handle different orderings? Do we need a separate entry in the table for both "license-a AND license-b" and "license-b AND license-a" ?
• Should we restrict the combinations to conjunctive and WITH patterns; that is, should we disallow disjunctive expressions?
• Should we create an equivalent construction in the LicenseDB ?

More design detail suggestions to follow regarding application functionality and the user experience.