SPDX WikiCopy Anchor Link

System Package Data Exchange — a Linux Foundation open standard for describing the components, licences, and provenance of software and the systems built from it. Version 3.0 rebuilt it from the ground up as a multi-domain graph model.

OverviewCopy Anchor Link

SPDX began around 2010 as an open-source license compliance exchange format — hence the original expansion, Software Package Data Exchange. Its most widely used artefact is still not an SBOM at all, but the SPDX License List: the short identifiers (MIT, Apache-2.0, GPL-2.0-or-later) that the entire industry uses to name licences.

In 2021 the SPDX workgroup merged with the OMG/CISQ Tool-to-Tool effort, and the combined group rebuilt the model. The result shipped as SPDX 3.0 in April 2024, with a deliberate rename to System Package Data Exchange: the scope moved beyond software to datasets, AI models, and build information in the same document.

StandardisationCopy Anchor Link

• ISO/IEC 5962:2021 — the international standard edition, which captures SPDX 2.2.1. This is the version procurement language usually cites.
• ISO/IEC DIS 5962 — a draft international standard for the newer model is progressing through ISO; SPDX 3.0.1 was explicitly prepared to support the OMG and ISO submissions.
• OMG has also published the SPDX 3.0 specification through its process, reflecting the Tool-to-Tool lineage.
• Governance: the SPDX workgroup under the Linux Foundation, with an open specification repository and public mailing lists.

Version historyCopy Anchor Link

Planning note: 2.x and 3.x are different standards that share a name. There is no lossless upgrade path from a 2.3 document to a 3.0 document. If your toolchain emits 2.3 and your customer asks for "SPDX", confirm which major version they actually validate against.

The 3.x data modelCopy Anchor Link

SPDX 3.0 dropped the flat document-in-a-tree design of 2.x in favour of a labelled graph. Almost everything you can talk about is an Element identified by an IRI, and the connections between elements are themselves elements.

The practical payoff: an SPDX 3 document can carry a security researcher's VEX statement about a package shipped by someone else, in a separate document, referencing that package by IRI, without either party editing the other's file.

ProfilesCopy Anchor Link

SPDX 3 is modular. A producer declares which profiles it conforms to, so a simple licence-only SBOM does not have to implement the whole model.

SPDX 3.1-RC1 (January 2026) widens the model further with profiles for hardware, service, functional safety, supply chain, and operations. As a release candidate it is explicitly for testing and validation — features may change before GA.

Serialization formatsCopy Anchor Link

Because 3.x is defined as an OWL ontology, the canonical form is RDF. The spec publishes an OWL ontology, a JSON-LD context, and a JSON Schema; serialisation is a rendering choice.

• JSON-LD — the canonical 3.x exchange form; the same bytes are valid JSON and valid RDF.
• RDF / Turtle — the native form for graph stores and SPARQL queries.
• SPDX JSON and XML — non-RDF renderings for consumers that just want JSON.
• YAML — commonly seen in ecosystem tooling.
• tag:value — the classic 2.x line-oriented format, still produced by many scanners; not part of the 3.x model.

Practical consequence: an SPDX 3 document is a serialisation of a graph, so element order is not meaningful and consumers should key off identifiers rather than list position. Many 2.x-era parsers assume otherwise, which is the main source of 3.x adoption friction.

SPDX License ListCopy Anchor Link

The License List is versioned independently of the specification — current release 3.29.0 (2026-09-16). It provides a short identifier, full name, canonical text, and flags for OSI approval and FSF freedom, plus a separate list of exceptions and a list of deprecated identifiers you should no longer emit.

License expressions combine identifiers with operators:

// two licences, choose either
"MIT OR Apache-2.0"

// both apply
"GPL-2.0-only AND BSD-3-Clause"

// with an exception, and "or later"
"GPL-3.0-or-later WITH Bison-exception-2.2"

These strings are the interoperability layer everyone agrees on: CycloneDX also accepts SPDX license IDs and expressions, which is why switching BOM formats rarely means rewriting your licensing data.

Security & VEXCopy Anchor Link

The Security profile carries vulnerability information in the same graph as the components. Rather than a single "severity number", each assessment is its own relationship object, so multiple scoring systems can coexist on one vulnerability:

• Vulnerability — the vulnerability itself (for example a CVE), with ExternalIdentifier links.
• VulnAssessmentRelationship — the base assessment, subclassed into CVSS v2/v3/v4, EPSS, SSVC, and exploit-catalog (for example KEV) assessments.
• VexVulnAssessmentRelationship — the VEX judgement, further subclassed as Affected, Fixed, NotAffected, or UnderInvestigation.

Example SPDX 3 documentCopy Anchor Link

{
  "@context": "https://spdx.org/rdf/3.0.1/spdx-context.jsonld",
  "@type": "SpdxDocument",
  "spdxId": "https://example.com/docs/app-1.2.0.spdx.json",
  "name": "acme-portal 1.2.0",
  "creationInfo": {
    "created": "2026-09-16T09:12:00Z",
    "createdBy": [{ "@type": "Organization", "name": "Acme Corp" }],
    "createdUsing": [{ "@type": "Tool", "name": "build-pipeline" }]
  },
  "dataLicense": "CC0-1.0",
  "profileConformance": ["core", "software", "security", "licensing"],
  "rootElement": [
    { "@type": "Package", "spdxId": "https://example.com/pkg/acme-portal@1.2.0" }
  ],
  "element": [
    {
      "@type": "Package",
      "spdxId": "https://example.com/pkg/acme-portal@1.2.0",
      "name": "acme-portal",
      "packageVersion": "1.2.0",
      "packageUrl": "pkg:generic/acme-portal@1.2.0",
      "suppliedBy": [{ "@type": "Organization", "name": "Acme Corp" }]
    },
    {
      "@type": "Relationship",
      "relationshipType": "DEPENDS_ON",
      "from": "https://example.com/pkg/acme-portal@1.2.0",
      "to": [{ "https://example.com/pkg/express@4.21.1" }]
    }
  ]
}

Strengths and trade-offsCopy Anchor Link

Strengths

• The universal licence vocabulary — SPDX IDs are the industry default, even inside CycloneDX documents.
• Genuinely multi-domain: software, AI, datasets, and build in one coherent model.
• Formal ontology with JSON-LD/RDF support enables graph queries and cross-document linking.
• International standard status via ISO/IEC 5962.
• Relationships are first-class, so third-party VEX and annotations attach cleanly.

Trade-offs

• The 2.x → 3.x break is real; tooling and validator support for 3.x is still maturing.
• Graph semantics plus IRIs are a steeper learning curve than a nested JSON document.
• Out-of-the-box "operational" features (services, hardware, attestations, crypto inventory) are thinner than CycloneDX's.
• Multiple serialisations mean "valid SPDX" still needs a version + format qualifier to be unambiguous.

Where to go nextCopy Anchor Link

Compare with CycloneDX → · Generators and converters → · Regulatory drivers →

Sources: spdx.dev, the SPDX 3.0.1 specification site, spdx.org/licenses, and the spdx-spec release history (retrieved September 2026).