Record a license that is not on the SPDX License List with a LicenseRef identifier: the prefix LicenseRef followed by a hyphen and a name made of letters, numbers, periods and hyphens. Keep the extracted license text with it, so anyone reading the SBOM can see exactly what terms apply.
What the SPDX specification says
The spec describes LicenseRef as a locally unique identifier for licenses not found on the SPDX License List. Each identifier must be unique within the SPDX document. Since version 1.2 descriptive names are allowed, so LicenseRef-Whiskeyware is acceptable instead of a sequential number. You can use the identifier in the package, file and snippet sections.
When you assign an identifier, extracted text becomes conditionally mandatory. It preserves the license wording as it appeared in the package, file or snippet, and can be a short reference or the full text.
The SPDX License List itself is at version 3.29.0, dated 16 September 2026, and its identifiers are meant to be stable. Deprecated identifiers remain valid but should no longer be used.
When to use it
| Situation | Use |
|---|---|
| License is on the list | The standard SPDX identifier |
| Custom text from a vendor | LicenseRef plus text |
| Modified standard license | LicenseRef, explain the change |
| License exception not on the list | Check the exceptions list first |
| Several unrelated custom licenses | One LicenseRef each, unique names |
Steps
- Check the SPDX list and exceptions list for a match. Do not invent a LicenseRef for something that already has an identifier.
- Save the exact license text from the package version.
- Choose a descriptive, unique identifier such as LicenseRef-VendorName-Terms-2026.
- Put the text in the extracted text field and reference the identifier in the package or file entry.
- Add the decision to your register. See how to handle a custom license.
CycloneDX equivalent
CycloneDX licenses use an id for SPDX identifiers or a name for others, and a license can carry its text and URL. See id, name or expression in CycloneDX.
Pitfalls
Reusing one LicenseRef for different texts destroys meaning. Leaving the text out makes the identifier a dead end. Using a LicenseRef where an SPDX identifier exists breaks automated policy matching.
Treat LicenseRef entries as a signal. A growing list of them means your dependencies or vendors use custom terms, and that deserves a conversation with legal. Review the list when you generate each release SBOM, and retire entries when you replace the component that needed them.
Safeguard generates SBOMs and scans dependencies. Try a free scan to see what your inventory looks like.
Quick check
Can two different licenses share one LicenseRef?
No. Each identifier must be unique within the document and refer to one text.
Is the text field optional?
Not when you assign an identifier. The spec makes extracted text conditionally mandatory.
Sources
- SPDX Specification 2.3.1, other licensing information detected: https://spdx.github.io/spdx-spec/v2.3.1/other-licensing-information-detected/
- SPDX License List: https://spdx.org/licenses/
- CycloneDX 1.6 JSON reference: https://cyclonedx.org/docs/1.6/json/#components_items_licenses
Last reviewed: 19 October 2026.
