Please consider going full case sensitive in the license expressions.
It will help users to read the expressions and simplify implementations of tools.
Arguments
- Humans read faster with the right cases, e.g.
aPachE-2.0 is bad to recognize quickly.
- When constructing URLs or filenames, the original case of a license identifier has to be used anyway.
This means tools have to do the checking first after a normalization (like using .upper() on list entries and string to check)
and then go into the list again for the original entry and use that.
- Once you move to case insensitivity, it is harder to go back.
Many tool implementations will already use the original case.
For others it will be a one-time translation.
Discussion
The decision in https://github.com/spdx/meetings/blob/d58ec031c89b83e6f6456946f01659177b374632/tech/2025/2025-08-19.md?plain=1#L38 does not give the reason why going to case insensitivity is considered a simplification and what alternatives were considered.
To me it is understandable that implementations profit from just having to do the normalization to upper or lower case instead of dealing with the mixed case sensitivity. However going full case sensitive also simplifies the situation.
Going case insensitive with 3.1 will trigger some changes in tools. So later going back to case sensitivity will be less acceptable for tool maintainers.
The small drawback of going full case sensitive is that some backwards compatibility is lost towards old expressions that make use of different cases where allowed.
In the past case sensitivity for protocol often paid tribute to old systems where only 7-bit transmissions or filenames were possible. This seems to have been resolved for good since a few years. Using upper and lower case are fine today.
The normalization step to a single case seems simple, but implementations could do it differently internally and this may lead to exposure of all lower case or all upper case expression in the wild.
From security aware implementations the trend is to have one method to express something to reduce complexity. Because even small additions can exponentially grow overall complexity and then lead to attacks on the code under bad circumstances.
Background
A release candidate is made to gather feedback. We (as in @tschmidtb51 and some others released to the CSAF standard technical committee) have been discussing the change from partly case sensitive to fully case sensitive in the https://github.com/spdx/spdx-spec/blob/develop/docs/annexes/spdx-license-expressions.md from 3.0.1 to 3.1-RC1.
When implementing validators, we ran into the change of the sensitivity.
See oasis-tcs/csaf#1468
Please consider going full case sensitive in the license expressions.
It will help users to read the expressions and simplify implementations of tools.
Arguments
aPachE-2.0is bad to recognize quickly.This means tools have to do the checking first after a normalization (like using .upper() on list entries and string to check)
and then go into the list again for the original entry and use that.
Many tool implementations will already use the original case.
For others it will be a one-time translation.
Discussion
The decision in https://github.com/spdx/meetings/blob/d58ec031c89b83e6f6456946f01659177b374632/tech/2025/2025-08-19.md?plain=1#L38 does not give the reason why going to case insensitivity is considered a simplification and what alternatives were considered.
To me it is understandable that implementations profit from just having to do the normalization to upper or lower case instead of dealing with the mixed case sensitivity. However going full case sensitive also simplifies the situation.
Going case insensitive with 3.1 will trigger some changes in tools. So later going back to case sensitivity will be less acceptable for tool maintainers.
The small drawback of going full case sensitive is that some backwards compatibility is lost towards old expressions that make use of different cases where allowed.
In the past case sensitivity for protocol often paid tribute to old systems where only 7-bit transmissions or filenames were possible. This seems to have been resolved for good since a few years. Using upper and lower case are fine today.
The normalization step to a single case seems simple, but implementations could do it differently internally and this may lead to exposure of all lower case or all upper case expression in the wild.
From security aware implementations the trend is to have one method to express something to reduce complexity. Because even small additions can exponentially grow overall complexity and then lead to attacks on the code under bad circumstances.
Background
A release candidate is made to gather feedback. We (as in @tschmidtb51 and some others released to the CSAF standard technical committee) have been discussing the change from partly case sensitive to fully case sensitive in the https://github.com/spdx/spdx-spec/blob/develop/docs/annexes/spdx-license-expressions.md from 3.0.1 to 3.1-RC1.
When implementing validators, we ran into the change of the sensitivity.
See oasis-tcs/csaf#1468