Download the machine readable SPDX license list, pin the version you used, and validate every license ID in an SBOM against it. Check the isDeprecatedLicenseId flag, treat exceptions as a separate list used with WITH, and handle unknown IDs explicitly instead of dropping them. At the time of writing the list is version 3.29.0.
What the list is
The SPDX License List is a list of commonly found licenses and exceptions for open source, data, hardware and documentation. Each entry has a short identifier, a full name, license text and a permanent URL. Its purpose, per the project, is efficient and reliable identification of licenses in SPDX documents, source files and elsewhere.
The page I checked showed version 3.29.0, dated 2026-09-16. The project publishes machine readable files, and I fetched the licenses and exceptions JSON files directly.
What is in the JSON
The licenses file held a version string, a release date and an array of 740 licenses. Each license object had these fields.
| Field | Meaning |
|---|---|
| licenseId | The short identifier to use in documents |
| name | Full name |
| isDeprecatedLicenseId | True if the identifier should no longer be used |
| isOsiApproved | Whether the license is OSI approved |
| reference, detailsUrl | Pages for the license |
| seeAlso | Related links |
| referenceNumber | Position in the list |
The exceptions file listed 86 exceptions in the same release. Exception entries use licenseExceptionId in place of licenseId.
Why pin the version
The list changes with each release. New licenses are added and identifiers can be deprecated. If your validator downloads whatever is current, a document that passed last month can fail today with no change on your side. Record the licenseListVersion alongside every validation result, and update on a schedule you choose.
What deprecated means
The project explains that a deprecated identifier remains valid but should no longer be used, because an updated identifier exists, for example after changes to license expressions or when a duplicate was found. The URL for each deprecated license is kept.
So treat deprecated as a warning, not an error. Accept the document, flag the ID, and suggest the replacement where you know it.
A validation routine
- Load the licenses and exceptions JSON for your pinned version.
- Parse the license expression into IDs, operators and exceptions.
- Check each plain ID against licenseId values.
- Check each exception, written after WITH, against the exceptions list only.
- Accept IDs that start with LicenseRef as custom, and require the document to define them.
- Warn on deprecated IDs.
- Report anything else as unknown, with its location, and do not silently drop it.
See how SPDX records licenses not on the list and what OR, AND and WITH mean.
Mistakes to avoid
Mixing up OSI approved with allowed in your company is common. The flag describes OSI status, not your policy. Treating the full name as an identifier is another. Use the identifier.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the license shown on each component and ask whether it would pass a check like the one above.
Where this fits
Clean license data is what makes policy checks reliable. Safeguard offers SBOM and dependency scanning, and the free scan is a quick way to see component licenses on a real project.
Quick check
Is a deprecated license ID invalid?
No. The project says it remains valid but should no longer be used. Warn and suggest the updated ID.
Where do exceptions go in validation?
Check them against the separate exceptions list, after the WITH operator, not against the licenses list.
Sources
Last reviewed: 19 October 2026.
