List the SPDX license identifiers your company accepts in the allow key of the [licenses] table in deny.toml. Anything not listed is denied. Use exceptions for one crate that needs a different license, and clarify when a crate has no machine readable license data.
Start from legal, not from the tool
The tool enforces a list. Someone has to decide the list. Ask legal or the person who owns open source policy which licenses are acceptable for your distribution model, because the answer differs for a SaaS service, a shipped binary and an internal tool. Then translate it into identifiers.
The keys
| Key | What it does |
|---|---|
allow | SPDX identifiers you permit, including forms such as Apache-2.0 WITH LLVM-exception |
confidence-threshold | Minimum score to trust detection from a license file, default 0.8 |
exceptions | Extra licenses allowed for a named crate only |
clarify | Hand assigned license expression, tied to the hash of a license file |
private | Controls whether unpublished workspace crates are checked |
unused-allowed-license | Warn, allow or deny when an allowed license never appears |
Defaults worth knowing: dev dependencies are not included, build dependencies are, and unlisted licenses are denied. A WITH exception is treated as different from the bare license, so list both if you accept both.
Example
[licenses]
confidence-threshold = 0.95
allow = ["MIT", "Apache-2.0", "BSD-3-Clause"]
[[licenses.exceptions]]
allow = ["Zlib"]
name = "some-crate"
[licenses.private]
ignore = true
The crate name here is a placeholder. Real exceptions should name a real crate and carry a comment saying who approved it.
Why clarify is safer than ignoring
When a crate ships an unusual license file, you can state the expression yourself and bind it to the file hash. If the file changes in a later release, the hash no longer matches and the clarification stops applying, so the check fails and a human looks again. That is the behavior you want.
Steps
- Get the approved license list from legal.
- Run
cargo deny check licensesand read the failures. - Add accepted identifiers to
allow. - For each remaining failure, decide: replace the crate, add an exception, or clarify.
- Mark unpublished workspace crates as private so they do not fail.
- Gate pull requests on the check.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control maps to several compliance frameworks.
Quick check
Is a license check legal advice?
No. It enforces the list your counsel approves. Detection can be wrong, so keep the confidence threshold high and review exceptions.
Should dev dependencies be checked?
By default they are not. Include them if your tests or tools are distributed with your product.
Safeguard compliance and evidence automation can collect dependency inventory and policy results for audits, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
