SPDX License Validator

What SPDX is and why it matters

SPDX stands for Software Package Data Exchange, an open standard maintained by the Linux Foundation and ratified as ISO/IEC 5962:2021. Inside SPDX lives the SPDX License List — a curated catalogue of over 600 approved license identifiers that lets developers, lawyers and automated tools refer to a license unambiguously with a short string like MIT, Apache-2.0 or GPL-3.0-or-later instead of pasting full license texts or vague labels like "BSD-style".

The standard goes far beyond a list. SPDX defines a complete data model for describing software components, their copyrights, their licenses, their cryptographic hashes and their relationships — the foundation of a modern SBOM (Software Bill of Materials). With the EU Cyber Resilience Act (CRA) taking effect in 2027 and the US Executive Order 14028 already in force for federal vendors, machine-readable SBOMs are no longer optional for serious software producers — and SPDX is one of the three formats officially recognised (alongside CycloneDX and SWID).

Anatomy of an SPDX license identifier

SPDX identifiers follow a deterministic, hyphenated naming scheme. The most common ones to recognise:

• Permissive: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Zlib, Unlicense, 0BSD, BSL-1.0.
• Weak copyleft: MPL-2.0, LGPL-2.1-only, LGPL-3.0-or-later, EPL-2.0, CDDL-1.0.
• Strong copyleft: GPL-2.0-only, GPL-3.0-or-later, AGPL-3.0-only.
• Creative Commons: CC-BY-4.0, CC-BY-SA-4.0, CC0-1.0.
• Source-available / fair-code: BUSL-1.1, SSPL-1.0, Elastic-2.0 — not OSI-approved but listed by SPDX.

Note the 2018 GPL naming change: legacy identifiers GPL-2.0 and GPL-3.0 were deprecated in favour of explicit -only versus -or-later variants, making the upgrade clause unambiguous. Linters such as spdx-correct will warn on the deprecated forms.

Compound expressions: AND, OR, WITH and parentheses

A single string is enough for a single license, but real projects often combine licenses. SPDX defines a small expression grammar to express dual-licensing, multi-licensing and exception handling:

MIT                                  // single license
MIT OR Apache-2.0                    // user picks one
(MIT AND BSD-3-Clause)               // both apply simultaneously
GPL-2.0-only WITH Classpath-exception-2.0  // GPL plus a stated exception
(LGPL-2.1-only OR BSD-3-Clause) AND MIT    // arbitrary nesting

• OR = the licensee may choose one of the alternatives. Cargo idiom MIT OR Apache-2.0 is the canonical Rust dual licence.
• AND = all listed licenses apply at once (the project bundles components under each).
• WITH = base license plus a named exception (Classpath, GCC, Bison, Autoconf, LLVM, etc.).
• Parentheses = mandatory whenever AND and OR are mixed to remove ambiguity.

Where SPDX identifiers appear day-to-day

• npm: "license": "MIT" in package.json; the registry rejects invalid identifiers since 2017.
• Cargo: license = "MIT OR Apache-2.0" in Cargo.toml — full SPDX expression syntax supported.
• Python: PEP 639 (accepted in 2024) standardises License-Expression in pyproject.toml using SPDX expressions.
• Go modules: go.mod does not carry license metadata, but pkg.go.dev reads SPDX from LICENSE files via license classifiers.
• Per-file header: // SPDX-License-Identifier: Apache-2.0 — REUSE-compliant, used in the Linux kernel and most modern projects.
• Containers and SBOMs: Syft, Trivy, Anchore and Microsoft SBOM Tool emit SPDX 2.3 documents that compliance teams ingest into FOSSA, Black Duck, Snyk Open Source, Tidelift and Mend.

License compatibility, CLAs and what the validator does NOT check

A passing SPDX validation only confirms the string is well-formed and matches an entry on the official list. It does not answer the harder legal questions:

• Compatibility: shipping GPL-3.0 code inside a proprietary closed-source binary is a license violation, even if both license strings are individually valid. Tools like FOSSology and FOSSA maintain a compatibility matrix.
• Patent grants: Apache-2.0 includes an explicit patent grant; MIT does not. Choosing between them affects defensive patent strategy.
• Copyleft scope: AGPL extends copyleft to network use, making it incompatible with most SaaS bundling strategies.
• CLA / DCO: the Contributor License Agreement or Developer Certificate of Origin governs contributions inbound, separate from the license under which the project ships outbound.

Treat this tool as the first guardrail in a layered compliance pipeline: format check here, then policy check in your SCA tool, then human review by counsel for the final licensing decision.

FAQ

Where is the canonical SPDX license list?

At spdx.org/licenses. The list is versioned, published on GitHub, and updated several times a year as new licenses are submitted and approved.

Are SBOMs really mandatory now?

For US federal suppliers under Executive Order 14028, yes. For products sold in the EU, the Cyber Resilience Act will phase in mandatory SBOMs starting 2027. Outside those jurisdictions SBOMs are still strongly recommended by procurement teams.

What is the difference between OR and AND in expressions?

OR lets the licensee pick one alternative (dual licensing). AND means all listed licenses apply simultaneously — typical when bundling multiple third-party components into a single package.

Why does the validator reject GPL-2.0?

Because the bare identifier was deprecated in 2018. Use GPL-2.0-only or GPL-2.0-or-later to make the upgrade clause explicit.

Does the tool detect commercial vs open source licenses?

No. It only verifies the identifier format and that the string is on the official SPDX list. OSI approval status, copyleft strength and commercial-use restrictions require a policy engine such as FOSSA, Snyk Open Source or Mend.