How do you cut license compliance false positives?

Cut license compliance false positives by fixing how licenses are read, not by muting alerts. Normalize identifiers to SPDX, honor exceptions and OR choices, separate code you ship from build only tools, and record one reviewed decision per package. Most noise comes from four predictable mistakes.

Why are there so many false positives?

License scanners infer a license from metadata, headers and license files. That inference is imperfect, and policy rules then act on the result. A wrong reading becomes a policy violation, and a team that sees five bogus violations stops trusting the sixth, real one.

The SPDX License List helps by giving each license a standardized short identifier, such as Apache-2.0 or GPL-2.0-only. As of our check on 18 October 2026, the list was at version 3.29.0, dated 16 September 2026.

The four common causes

1. Old or ambiguous identifiers. The SPDX list says some identifiers are deprecated, and the GNU ones were replaced in version 3.0 with explicit "only" and "or later" forms. A scanner reading an old GPL-2.0 tag has to guess which one is meant. A policy that treats the guess as the worst case produces false alarms.

2. Exceptions ignored. SPDX expressions can use WITH to attach an exception to a license, for example GPL-2.0-or-later WITH Bison-exception-2.2. A tool that drops the exception sees a plain GPL license and flags it. The exception may remove the obligation that worried you.

3. OR read as AND. In SPDX expressions, AND means you must comply with all listed licenses, and OR means you may choose. LGPL-2.1-only OR MIT lets you take the MIT terms. A tool that treats it as both reports the stricter one.

4. Wrong scope. A test framework or build tool that never ships in your product has different obligations than code you distribute. A scan that lumps them together flags licenses that do not apply to your delivered software.

What are the fixes?

1. Normalize to SPDX identifiers. Map deprecated and free text license names to current identifiers, and keep the mapping in one place.
2. Parse the whole expression. Make sure your tool understands AND, OR and WITH, parentheses, and the plus sign meaning "or any later version." Operator precedence matters: the default order applies WITH first, then AND, then OR, and parentheses override it.
3. Handle custom licenses explicitly. SPDX uses LicenseRef- identifiers for licenses not on the list. Review each one by hand once and record the outcome.
4. Tag dependencies by use. Mark direct runtime, transitive runtime, dev only and build only. Apply your strictest rules to what ships.
5. Review once, remember forever. Store a decision per package and version, with reviewer, date and reason. Re-open only when the license changes.
6. Prefer declared over guessed. If a package declares a license expression in its metadata and the license file agrees, trust it more than a fuzzy match on a header.
7. Review the top ten noisiest rules. If one rule produces most of your alerts, the rule or the data feeding it is probably wrong.
8. Keep a human in the loop for copyleft. Automation clears the obvious cases, and a person reads the uncertain ones.

How do you measure progress?

Track the share of license findings that survive review. If you start at 20 percent and reach 70 percent, the tool is now earning attention. Also track time to decision for a new package. Both numbers matter more than the raw count of alerts.

What are the limits?

No tool replaces legal advice. License terms can interact with how you link, distribute or modify code, and that is a judgment for counsel. Automation should reduce the obvious errors and make the real questions visible.

Safeguard's CLI generates SBOMs across many package managers. We do not make a claim about license accuracy rates, and you should test any tool, ours included, against a set of packages you have already reviewed.

Quick check

Sources

• SPDX License List
• SPDX specification 2.3.1: license expressions

Last reviewed: 18 October 2026.