SCA license compliance tools read your dependency tree, identify each package's license, and flag those your policy does not allow. Some only summarize, some enforce an allow or deny list, and some scan source files for license text. Pick by how strict your policy is and what evidence you must produce.
Safeguard publishes this guide and sells a competing product, so we describe other tools only from their own documentation.
Key takeaways
- Package metadata gives a fast license list. Scanning source and license files is slower and finds more.
- Unknown licenses are the real work. Decide the default before the first scan.
- Enforcement needs an allow or deny list in SPDX identifiers.
- A license report is a technical input. Legal review decides what a license means for your product.
What does a license compliance tool do?
It answers three questions: which licenses are in my dependencies, which break my policy, and what do I owe, such as attribution notices. The first two can be automated. The third usually needs a person.
How do the tools compare?
The table uses each project's documentation as fetched on 19 October 2026.
| Tool | Type | How it finds licenses | Policy features | Output and notes |
|---|---|---|---|---|
| OSV-Scanner | Open source CLI | License data from the deps.dev API | Allowlist of SPDX identifiers reports violations; per package overrides in config | Without an allowlist you get a summary only |
| Trivy | Open source CLI | Package manager data by default; full mode also scans source, Markdown, text and LICENSE files | Google License Classification maps to severity; custom reclassification in config | Full mode is slow; unrecognized licenses are marked UNKNOWN |
| ScanCode Toolkit | Open source CLI and library | Detects licenses and copyrights in source and binary files | Not described on the page we read | JSON, YAML, HTML, CycloneDX, SPDX; Apache-2.0 |
| OSS Review Toolkit | Open source CLI suite | Analyzer and scanner gather license, copyright and snippet data | Scriptable evaluator rules, including a built-in set based on the OSADL matrix | Reports and CycloneDX or SPDX SBOMs |
| GitHub dependency review | Hosted, in pull requests | Provides license information on dependency changes | Action takes license allow or deny lists | Available for public repositories; private needs GitHub Code Security or Advanced Security |
| Semgrep Supply Chain | Hosted | Lists license compliance checking on Free, Teams and Enterprise | Checks against your organization's licensing requirements | Detail beyond that not on the page read |
Package metadata or full scan?
Use metadata scanning for continuous checks and full scanning for audits. Metadata is quick because it trusts what the package manager says. Source scanning, which Trivy calls full scanning, reads license files and text, so it catches a vendored file or a wrong declaration, at the cost of speed. Trivy's docs say full scanning is slow and that filesystem and repository targets depend on lock files.
How should I write a license policy?
Write it as a list your tool can enforce.
- Allowed: licenses approved for any use, in SPDX identifiers.
- Review: licenses that need a human decision, such as reciprocal ones.
- Denied: licenses you will not ship.
- Unknown: choose to block or to route to review. A common choice is review.
OSV-Scanner takes allowed licenses as a comma separated SPDX list. Trivy lets you reassign licenses between its categories in a config file. ORT's evaluator lets you script rules in Kotlin.
How do SBOMs fit in?
An SBOM is the portable record of components and, in CycloneDX and SPDX, their licenses. Buyers often ask for one. ScanCode and ORT export both formats. Safeguard offers SBOM generation and import, and you can check a CycloneDX or SPDX file in the free in-browser scan, which parses it locally and checks up to 100 dependencies for vulnerabilities.
How to choose
- Do you need a summary, or enforcement that fails a build?
- Do you need source level detection, or is package metadata enough?
- Can the tool use SPDX identifiers and override a wrong one?
- Does it produce an SBOM or a report an auditor accepts?
- Who reviews exceptions, and where is the decision recorded?
- Does it run where you need it, in a pull request, in CI or offline?
Frequently asked questions
What is the best free license compliance tool?
It depends on your depth. OSV-Scanner and Trivy are quick checks, while ScanCode and ORT go deeper and take more setup.
Can GitHub check dependency licenses?
Yes. The dependency review action can be configured with license allow or deny lists. It is available for public repositories, and private ones need GitHub Code Security or Advanced Security.
What happens with unknown licenses?
Trivy classifies licenses it cannot recognize as UNKNOWN and recommends reviewing them. Decide your default in advance.
Do license scanners replace legal review?
No. They find and classify licenses. A lawyer or open source program office decides what each license requires of you.
Do I need an SBOM for license compliance?
Not strictly, but an SBOM in CycloneDX or SPDX is a convenient way to record and share your component and license inventory.
Sources
- OSV-Scanner license scanning
- Trivy license scanning
- ScanCode Toolkit
- OSS Review Toolkit
- GitHub Docs: About dependency review
- Semgrep Supply Chain overview
- Semgrep pricing
- Safeguard free scan
Last reviewed: 19 October 2026.
