SPDX validation should consider LicenseRef-* that are not in the database

[Joerki]

The current validation of SPDX expressions includes the lookup of SPDX and LicenseRef-scancode-* items in the database.

It would be useful to also assume custom LicenseRef-* items as valid that are not starting with LicenseRef-scancode-*.

This changed behavior could be achieved by having a new bool parameter like "allow_custom_licenserefs" with False as default to mark existing behavior.

[jkowalleck]

docs say:

An SPDX user defined license reference: ["DocumentRef-"1*(idstring)":"]"LicenseRef-"1*(idstring)

here are some examples for valid values

LicenseRef-23
LicenseRef-MIT-Style-1
DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2

as found in the official docs:

• https://spdx.github.io/spdx-spec/v3.0.1/annexes/spdx-license-expressions/#simple-license-expressions
• https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/#d3-simple-license-expressions

tested with license-expression==30.4.1

>>> from license_expression import get_spdx_licensing
>>> lic = get_spdx_licensing()

>>> lic.validate('LicenseRef-23')
ExpressionInfo(
    original_expression='LicenseRef-23',
    normalized_expression=None,
    errors=['Unknown license key(s): LicenseRef-23'],
    invalid_symbols=['LicenseRef-23']
)

>>> lic.validate('LicenseRef-MIT-Style-1')
ExpressionInfo(
    original_expression='LicenseRef-MIT-Style-1',
    normalized_expression=None,
    errors=['Unknown license key(s): LicenseRef-MIT-Style-1'],
    invalid_symbols=['LicenseRef-MIT-Style-1']
)

>>> lic.validate('DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2')
ExpressionInfo(
    original_expression='DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2',
    normalized_expression=None,
    errors=['Unknown license key(s): DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2'],
    invalid_symbols=['DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2']
)

[mjherzog]

These license expressions are only useful in the context of an SPDX document where you can trace them to actual license text. Unless there is some public source for the actual license that is provided there is no point in treating these as license notice. The current reporting as unknown licenses is accurate.

[pombredanne]

@mjherzog agreed, but we should not fail validation with an error when these are present, and only report something like a warning

[mjherzog]

Why not just report them as unknown license? That is what they are.

[jkowalleck]

For CycloneDX we use this very library to validate SPDX expressions. This includes LicenseRef ones.
We are working on CycloneDX having capability to hold the (custom) license text for these ref'ed licenses eventuality, so at this point it would be great to have the library not report these errors. Warnings would be fine.

So while we don't have a water-proof case yet, we probably will in the future.

[Joerki]

First, I do not see that the current implementation has any defect, my proposal is an enhancement. This enhancement may result into the introduction of more functions to not make the original ones too complex considering parametrization.

license-expression is a valuable library, but I see one more usage scenarios than it currently. I also have the impression that the context of "validation" can be misunderstood if the reader does not study the full comments of parse and validate functions.

Please let me describe the use cases I see when I deal with SPDX license expressions

1. (existing) use case - Syntax check only
   In case no "validation" is used the library checks the boolean syntax,
   Useful especially for compound/composite expressions to split them and analyse items manually. This is the use case I implement, because there are so many faulty license declaration errors in the world. I rely on an own business logic - but considering license-expression as part of it - plus a JSON file based on the Scancode structure to map faulty items to correct ones. The ScanCode index is the one I use as the basis.

2. (existing) use case - syntax check and license identification
   The library shall help me to not only check for the syntax, but also whether given license ID (from official list + custom ScanCode licenses. This requires "validation".

3. (existing) use case - use of most recent SPDX license IDs
   The library helps me to identify most recent versions of official SPDX license IDs, e.g. "AGPL-1.0", which now gets "AGPL-1.0-only".

4. (not existing) use case - parse and check SPDX license expression conformity only
   One or more functions should check that boolean syntax and license items are compliant with the SPDX expression definition (see SPDX annex). This means that current and outdated license IDs from SPDX list are assumed as valid, other LicenseRef-* or DocumentRef-* items are valid if they are compliant with the SPDX ABNF.
   Special possible exception: If you claim the scancode namespace (LicenseRef-scancode-*) as valid if the expression is listed in the JSON file this is totally fine for me.
   For me, I created functions named is_spdx_simple_expression, is_spdx_license_identifier and is_spdx_compound_expression to check for conformity with the SPDX expression spec and without the optimization the existing library applies.
   Proper handling of license texts is for me out of scope here and implemented in the application elsewhere (or maybe by another JSON DB that can be initialized with the library)

I hope that my long explanation is helpful and makes clear that "validation" means something different depending on a desired expectation: the check of an expression that comes with known IDs or the check (just) for conformity to the SPDX standard, both with check of correct syntax.

It would be great if the libraries targets both things, maybe with different API functions (but internally shared code) to show a clear distinction between expectations.

If any assumption of me is wrong, not clear or not complete, please let me know.