SPDX 2.2 conformance (invalid `licenseListVersion` produced)

[kikofernandez]

Describe the bug

After generating a SPDX SBOM in an unmanaged project, the licenseListVersion is set to "3.25.0", but SPDX 2.2 only allows two digits, e.g., "3.25"

To Reproduce

Run in an unmanaged project

1. Generate an analysis
2. Then do a scan
3. Finally create a report

   ./gradlew cli:run --args="report -i scan-result.json -o . -f SpdxDocument"
   

4. See error

The generated SPDX has a licenseListVersion with 3 numeric versions

Expected behavior

I expected the licenseListVersion to conform to the SPDX 2.2 standard.

Additional context

This happens in Unmanaged projects, as far as I know.

[kikofernandez]

Thanks!

[sschuberth]

BTW, how did you notice? Was some validation tool complaining about it?

Other than that I believe the spec to be overly restrictive here, esp. as the official tagging of the license list versions has itself changed from two to three digits after 3.23.

[kikofernandez]

Yes, a python tool called ntia-checker [here] which fails when generating the SPDX for Erlang.

The scanner PR (#9487) I submitted is enough for me to track all files (even if not ready for merging), and I have another based on the changes proposed on #8485 to produce the SBOM. This is all we need to generate an SBOM :)

After I removed the final 0, and added the supplier field (which I think you already added to ort, but unmanaged projects cannot set it), I got that the Erlang SPDX is compliant with ntia minimum requirements :)

[kikofernandez]

Essentially, with minor changes to the produce SPDX from ort, I get NTIA compliance.
Kudos to everyone for this tool!
I know my changes are not there yet to be merged, but they prove that they can be useful in a large context.

Sure enough, I need to edit other fields in the SPDX to look more complete, but I can create my own script for this particular purpose. More concretely, that would be:

• to set the licenseConcluded to the actual license that we know it is true, but that ort leaves for manual revision (AFAIK),
• set the name of the project, and
• set the downloadLocation to the location of our releases/repo

I believe that in unmanaged projects, these are not set and there is not yet a way to set them. But as I said, it is a minor thing that I can script :)