Support SPDX 3.0 as input to the Evaluator

[tsteenbe]

Supporting SPDX 3.0 as input file format to the Evaluator will enable the use case below:

• Review SPDX files provided by third parties (suppliers/vendors) to your organization
• Enables using ORT Evaluator and Reporter for code that is build using tools not supported by ORT such as Yocto

Note that this new feature only targets SPDX 3.0 and not any of the prior versions this is due to quirks in the SPDX spec that make it difficult to convert SPDX < 2.x to an ORT result file.

[sschuberth]

I'm confused why we should support SPDX 3.0 as input to the Evaluator instead of the Analyzer (which we already do support for SPDX 2.x in the form of SpdxDocumentFile). Because essentially, all we need to do with an SPDX BOM is to convert it to the ORT data model, which is essentially what the "fake" SpdxDocumentFile analyzer does. Can you elaborate @tsteenbe?

[tsteenbe]

Some ORT users only want to verify provided SPDX against their policy and don't want to run the analyzer or scanner. This makes sense for example in the case of:

• a supplier providing a SPDX file for a proprietary-licensed binary that includes private OSS forks/snippets for which the source code is not available and its package can not be found in public package repositories.
• build system like Yocto who have a lot of flags and my require custom scanning which is not supported by ORT and the user has their own analyzer/scanner tooling for this.

That said I can also see an use case where an organization wants to use the analyzer on provided SPDX file by a supplier to verify SPDX data correctness and/or use scanner/downloader to get a copy of the OSS code to create source code bundles/verify license conclusions in the SPDX file.

[vbasem]

An additional use case we have suggested and need:

We would like to enrich a SPDX generated through other tooling with correct download descriptors based on analyzer + downloader logic.

Assumption is that the source code links generated on the supplier side on the source code itself is the most accurate source. Thus: given a generated SPDX

1. analyzer can map components to findings and annotate missing components (both in SPDX and in its own output)
2. downloader takes the information from (1) and includes the most accurate download coordinate for the source code into the SPDX

_{Basem Vaseghi basem.vaseghi@daimler.com, Daimler TSS GmbH, legal info/Impressum}