markup change for cryptsetup-OpenSSL-exception

[xsuchy]

Fixes: #2674

[xsuchy]

Checking the CI failure. The alt-match "OpenSSL library|Objective Caml runtime" does not match "OpenSSL\nlibrary". Is this bug in matching code? cc @goneall
Because \n and " " should be treated identically. https://spdx.github.io/spdx-spec/v3.0.1/annexes/license-matching-guidelines-and-templates/#whitespace

[goneall]

The error is due to line breaks - using \s+ instead of spaces should fix it.

[goneall]

@xsuchy this was discussed in #2669

I did a very quick review of other alt texts and found spaces being used rather frequently, so this problem will likely come up more frequently.

There are 2 conflicting parts of the license matching spec - one stating that regexes follow a certain POSIX standard and the guidelines mentioned above.

One practical solution would be to replace the spaces in any alt match text with \s+. I'm a bit reluctant to take this approach since it does change the matching behavior without the author of the XML knowing it and it conflicts with the written definition of what the alt match is. That being said, I can't think of a scenario where someone would want the exact match to a single space. I would support this approach if we clearly documented this deviation from POSIX standard regexes.

There are 2 places we could do this hack:

1. In the license list XML repo when a new license XML is added - this could be done in the CI
2. In the license list publisher when we generate the license matching templates

I would recommend the first since the license list publisher may not be the only tool using the regexes from the alt tags.

@swinslow @zvr - Any thoughts or concerns on implementing one of the 2 hacks mentioned above?

[xsuchy]

Ah, that's that issue. Nod.

I updated this PR with \s+

[swinslow]

Thanks @goneall and @xsuchy.

@goneall I think I'm probably in favor of option 1 there. Primarily because I do think that most people would expect to be able to use the regexes as "standard" regexes as-is. So having them visible with the \s+ markers in the license-list-XML repo is probably a good idea.

We're likely going to be pushing the next release in the next week (may be next weekend), so perhaps this would be good to look at incorporating after we get past that -- rather than adding it in just prior to the release. Happy to chat about specifics for how we might implement this.

@xsuchy this PR looks fine, and I'll go ahead and merge -- thank you.