Two license scans of one project differ because they looked at different things. The usual causes are what each scan included, which evidence it trusted, which version it matched and how it named the license. Compare those four factors before assuming one report is wrong.
Cause 1: Scope
One scan may read only your lockfile. Another may also read vendored code, container layers or a build output. Development dependencies may be in one report and not the other. Check whether each scan covered runtime, development and transitive packages.
Cause 2: Evidence source
A license can be declared in package metadata, written in a LICENSE file, or named in a source header. A tool that reads metadata only will report what the publisher typed. A tool that reads file text may report something else. The Python packaging specification even notes that older License fields hold free text, and that License-Expression holds a validated SPDX expression, so the same package can look different depending on which field a tool reads.
Cause 3: Version matching
Licenses can change between releases. If one scan resolved a version range to a newer release than the other, the results will differ for a real reason. Compare exact versions first.
Cause 4: Naming
One tool says Apache-2.0, another says Apache 2, another says Apache Software License. Without normalization they look like different findings. SPDX identifiers exist to make this comparable. Normalizing names is covered in normalizing messy license names to SPDX identifiers.
A comparison routine
- Export both reports as a list of package, version, license.
- Normalize license names to SPDX identifiers.
- Join on package and exact version.
- Review three groups: in one report only, in both with different licenses, and in both with the same license.
- For each difference, open the package and read the license file yourself.
The first group points to a scope issue. The second points to an evidence or naming issue. The third needs nothing.
What to record
Note which scan is your system of record, and why. Pick one and keep it stable, so month to month changes mean something. Switching tools without a baseline makes trend lines meaningless.
Quick check
Which report should I believe?
Neither by default. Read the license file of the disputed package and record the result.
Does a different count mean a tool is broken?
Not necessarily. Counts depend on scope and on how transitive packages are listed.
Safeguard's SBOM and dependency scanning gives one inventory you can use as that stable baseline.
Sources
Last reviewed: 19 October 2026.
