SBOM: opt-in SPDX 3.0 output

[mstykow]

Summary

Offer SPDX 3.0 as an opt-in output format alongside the current SPDX 2.x, with 2.2 remaining the default. Build only when there is real pull — do not implement speculatively.

Why not now

• No capability gap. SPDX 2.2 already expresses everything Provenant needs — LicenseConcluded/LicenseDeclared (declared vs. concluded), PackageVersion, and purl ExternalRef. 3.0 unlocks nothing Provenant currently can't say (unlike the CycloneDX 1.3→1.7 bump, which closed a real gap — see SBOM: emit CycloneDX 1.7 with license acknowledgement (declared/concluded) + evidence #1328).
• 2.2 is the standard. SPDX 2.2.1 is ISO/IEC 5962:2021; mandates, most tooling, and consumers still center on 2.x (and CycloneDX). 3.0 adoption is early.
• Large, from-scratch build. 3.0 is a new element/relationship data model with JSON-LD serialization — effectively a second SPDX writer, not an extension of the 2.2 tag-value/RDF writer — plus new validation infra (confirm spdx-tools/pyspdxtools validates 3.0). High cost for speculative benefit.

Design (when built)

• New output flag (e.g. --spdx-json / --spdx-3), following the existing multi-format model (--spdx-tv, --spdx-rdf, --cyclonedx, …). 2.x stays the default.
• Add 3.0 documents to the official-validator gate in scripts/validate_output_format_fixtures.py.
• Map the Software + Licensing profiles; skip Build/AI/Dataset/Crypto profiles (not Provenant's use case).

Build trigger

Implement when one of these is true: a user/customer/mandate requires SPDX 3.0 output, or major consumers default to 3.0. Until then this stays parked.