Skip to content
Latchkey

cargo-deny "rejected: not in allow list" license failure in CI

cargo-deny ran the licenses check and rejected a crate because its SPDX license is not in the allow list of deny.toml. With an allow-list policy, anything not listed is rejected and the check exits non-zero.

What this error means

cargo deny check licenses prints an error pointing at the crate and its license with "rejected: license is not explicitly allowed" (or not in the allow list), and returns a non-zero exit.

Terminal
error[license-not-encountered]: rejected
   crate = some-crate 1.2.0
   license = GPL-3.0
   = license "GPL-3.0" is not explicitly allowed

Common causes

The crate license is outside the allow list

Your [licenses] allow = [...] set does not include this crate's SPDX license, so the allow-list policy rejects it.

A new dependency changed the license set

A dependency bump introduced a crate with a license you have not vetted, so it is not in allow and fails the check.

How to fix it

Add the license after vetting it

  1. Run cargo deny check licenses to see the exact SPDX id rejected.
  2. If legal approves it, add the SPDX id to allow in deny.toml.
  3. Re-run the check to confirm it passes.
deny.toml
# deny.toml
[licenses]
allow = ["MIT", "Apache-2.0", "BSD-3-Clause", "ISC", "Unicode-DFS-2016"]

Grant a per-crate exception

To allow a single crate without opening the license globally, add a clarify/exception entry for that crate only.

deny.toml
# deny.toml
[[licenses.exceptions]]
name = "some-crate"
allow = ["GPL-3.0"]

How to prevent it

  • Keep the allow list explicit and reviewed by legal.
  • Run cargo-deny on every PR so a new license fails before merge.
  • Prefer per-crate exceptions over widening the global allow list.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →