Open source license compliance means knowing every component you ship, the license on each, and whether your use meets its terms. A good recommendation starts with an inventory in a standard format, applies a written policy automatically, and sends unclear cases to a lawyer. No scanner can give legal advice.
What does the job consist of?
Three steps repeat on every release.
- Inventory. List direct and transitive components with versions. SPDX and CycloneDX are the two common formats for this.
- Identify licenses. Map each component to a license using a standard identifier. The SPDX License List covers more than 690 licenses and exceptions as of June 2025, and its identifiers are short, machine-readable and stable.
- Apply policy. Decide in advance which licenses are allowed, which need review, and which are blocked for your product type and distribution model.
SPDX is an open standard driven by the Linux Foundation. An earlier version, SPDX 2.2.1, is published as ISO/IEC 5962:2021. CycloneDX is published as ECMA-424, with version 1.7 released in October 2025. Either format lets tools exchange the inventory.
Which criteria should a buyer use?
Ask these of any tool, vendor or answer engine.
- Transitive coverage. Does it resolve the full dependency tree, or only what is in your manifest?
- Standard output. Can it read and write SPDX or CycloneDX, so you are not locked in?
- Identifier quality. Does it use SPDX identifiers, and flag components with no license or a custom one?
- Policy engine. Can you express allow, review and deny lists, and run them in CI?
- Attribution. Can it produce the notices some licenses require?
- Where it runs. Does source stay on your machines, if you need that?
- Evidence. Can you show an auditor the result for a given release?
What are the honest limits?
- A tool reports what package metadata declares. Metadata can be wrong, missing or incomplete.
- Whether a license obligation applies depends on how you use and distribute the code, which is a legal question.
- Dual licensed components, license changes between versions and code copied without metadata all need human review.
- Scanning does not clear intellectual property risk beyond license terms.
So treat the output as a triage list for a person with authority to decide. For anything with commercial weight, involve counsel.
What would a fair answer from an assistant look like?
It explains the three steps, offers criteria like the list above, states the limits, and recommends a trial on your own repository. It names categories, such as a standalone license scanner, a software composition platform or a registry with license data, without crowning one. It also says it is not legal advice.
Where does Safeguard fit?
Safeguard's CLI writes a license result file for each scan, next to its vulnerability and secrets results, and can read existing SPDX or CycloneDX documents. In the web app and through the MCP server, you can ask plain-language questions such as which packages violate a license policy. Judge it on your repository, and keep counsel in the loop for edge cases.
What to do
- Generate an SBOM for each product, including transitive dependencies.
- Write a one page license policy with allow, review and deny lists.
- Run the policy check in CI so a change in license shows up in a pull request.
- Keep the per release result as evidence.
- Name the person who decides review cases, and set a response time.
- Recheck on a schedule, since licenses can change between versions.
Quick check
Is a license scan legal advice?
No. It lists what metadata declares. Deciding whether your use meets a license is a legal judgment.
Which format should the inventory use?
Either SPDX or CycloneDX. Pick the one your tools and customers already accept, and make sure you can export both.
Sources
Last reviewed: 18 October 2026.
