BUG: LicenseRef should not be used with License Exceptions

[DennisClark]

The SPDX team has specified that a non-SPDX-license-list text which is an exception should be identified with a name that starts with AdditionRef rather than LicenseRef.

So, from the SPDX perspective, this is wrong:
some-license-key WITH LicenseRef-something-exception
but this is right:
some-license-key WITH AdditionRef-something-exception

There are multiple Active license exceptions in DejaCode with SPDX key starting with "LicenseRef".
Updating them would of course have an impact on the LicenseDB and various ScanCode tools, so such an update is a big deal and would require a fair amount of work and communication/documentation.

I have created a new Query and Report in DejaCode (nexB dataspace) called License Exceptions with "LicenseRef". I am also attaching the .xlsx output from the report to this issue.

The resolution of this conflict requires some discussion.

Note that our current workaround to this problem, which is simply to construct an expression like this using the AND operator

some-license-key AND LicenseRef-something-exception

rather than using the operator WITH , gets us through the SPDX validator, but is not really a good long-term sustainable solution, since it avoids compliance with the latest SPDX standard.

[DennisClark]

The DejaCode/LicenseDB list currently contains 112 non-SPDX-license-list exceptions with this problem.

license-exceptions-with-licenseref-2025-06-03.xlsx

[DennisClark]

@AyanSinhaMahapatra Do you know what the impact would be if I were to change the SPDX identifier of these 112 exceptions to start with AdditionRef rather than LicenseRef in DejaCode and we were to synchronize that change with SCTK? Would it break stuff or would it give us some strange results?

[AyanSinhaMahapatra]

@DennisClark IMHO this might not have a lot of impact to convert these non-spdx license exceptions from LicenseRef-something-exception to AdditionRef-something-exception, but it's best to check for that by implementing this change in scancode-toolkit and license-expression first. It is also possibly easier to write and script and do this at once in scancode, rather than dejacode.

And then if the tests pass and everything looks good, we can push these changes from there to sync with dejacode.

There are also some pending scancode issues related to SPDX exceptions such as aboutcode-org/scancode-toolkit#3248

Would it break stuff or would it give us some strange results?

@pombredanne do you think this would give us any strange results anywhere?

[DennisClark]

@AyanSinhaMahapatra it's best to check for that by implementing this change in scancode-toolkit and license-expression first. It is also possibly easier to write and script and do this at once in scancode, rather than dejacode. Thanks, I agree completely.

[tsteenbe]

@AyanSinhaMahapatra Keep in mind that AdditionRef are SPDX 3.0+ but ScanCode is used to produce SPDX 2.0 files in SPDX so a solution should support both SPDX 2.x and 3.x license expressions.