CycloneDX SBOM generated by ORT fails validation #11067
Description
When running the validate command of the cyclonedx-cli tool against a CycloneDX SBOM generated by ORT, a number of issues are reported, and the tool finally states that the "BOM is not valid."
The validation failures issued by the tool are a bit hard to interpret, since most issues are obviously follow-ups of other root causes. From my analysis of the messages, the relevant ones look like the following example:
Value should match one of the values specified by the enum
http://cyclonedx.org/schema/spdx.schema.json
On instance: /components/1059/licenses/66/license/id:
libpng-1.6.35
I think the actual cause is a discrepancy in the set of SPDX license identifiers that are considered valid between ORT and CycloneDX. The CycloneDX specification contains a list of license identifiers that are valid values for the id property of a license declaration. It claims that this list "is synchronized with the official SPDX license list". Declarations for licenses referenced by this list should have a corresponding id property; for other licenses, the name property should be used instead. ORT correctly implements this logic, but it seems to use a newer version of the SPDX license list than CycloneDX. For the licenses flagged as invalid, I could verify that they are listed in the official SPDX license list, but do not appear in list of the CycloneDX specification.
So, ORT is actually "more correct" or at least up-to-date than CycloneDX, but nevertheless the generated BOMs may fail the validation. In our case, this is problematic because other tools - especially Dependency Track - reject them.
What do you think would be the best way to handle this? Maybe have a negative list of license identifiers which should not be referenced by their ID? Or try to have an auto-generated positive list from the CycloneDX specification?