Canonical form of composite license expressions

[bact]

From https://spdx.github.io/spdx-spec/v3.0.1/annexes/spdx-license-expressions/:

The license expression

LGPL-2.1-only OR MIT

is identical to

MIT OR LGPL-2.1-only

but it does not say what is canonical form of the expression.

LGPL-2.1-only OR MIT or MIT OR LGPL-2.1-only ?

Should we need to specify that?

The use cases are

1. license matching by naive string matching, without license expression normalization (normalized by a smart producer, consumers can be relatively dumb)
2. deterministic hash of an SBOM with a license information that contain composite license expressions

Or should we explicitly say that, don't reorder it since the order of licenses may indicate the author's preference (which the license expression is not captured), and leave the order as-is?

--

Follow up question if we think license expression canonicalization is useful:

How to order it?

1. By straightforward alphabetical order (using codepoint values of ALPHA, DIGIT, etc in the ABNF).
2. By presence in the SPDX License List then by alphabetical order.

Given a license expression:

MIT AND LicenseRef-My-License AND Apache-2.0

(1) will give:

Apache-2.0 AND LicenseRef-My-License AND MIT

(L comes before M)

while (2) will give:

Apache-2.0 AND MIT AND LicenseRef-My-License

(any LicenseRef-* will come after the listed licenses)

Which ordering is preferred?

[bact]

Another case of license expression normalization, regarding parenthesis from aquasecurity/trivy#10139:

(GPL-3.0-or-later WITH GCC-exception-3.1) (with parentheses)

vs

GPL-3.0-or-later WITH GCC-exception-3.1 (without parentheses)

[zvr]

The SPDX specification does not define any "canonical" representation of License Expressions.

If an application wants to check for equality of two values, it would have to do any transformation to a unique representation itself, and it is free to define how this would be defined.
As you note, simple string match does not work: "MIT OR 0BSD" is not the same string as "MIT OR 0BSD".

I should point out that this is consistent with how a number of different types are handled. The spec does not provide a canonical way of writing URLs, email addresses, etc. So, if one wants to test whether two value like "user@example.com" and "user@EXAMPLE.COM" are the same, one has to have a type-specific checker.

[bact]

May related, from Microsoft review on 3.1-RC1: “Case-insensitivity lacks canonicalization/failure guidance” #1420 (comment)

@henrylyons

[swinslow]

Echoing @zvr, there is no defined "canonical" or preferred structuring of license expressions.

I don't think there should be. My gut instinct is that any perceived benefit from instituting a "canonical" representation of license expressions is likely to be outweighed by the friction caused by invalidating lots of existing valid license expressions.