A scanner's license report is only as good as the declared string

The workload

A dependency-scanning tool cannot read prose; it reads a declared string. Verified: the SPDX License List, maintained by the Linux Foundation's SPDX project, is the standardized catalog those strings come from, version 3.29.0 as retrieved 16 September 2026, running from '0BSD' through 'ZPL-2.1.' The workload this creates for a founder is upstream of any scanner: making sure the project's own package manifest declares an SPDX identifier at all, and that the identifier matches the license text actually shipped, since a scanner reports the declared string, not the license the maintainer meant.

What the documents show

Verified: an SPDX identifier is defined as a 'standardized short identifier' meant to 'enable efficient and reliable identification of such licenses and exceptions in an SPDX document, in source files or elsewhere,' with the project's own guidance recommending developers 'use short identifiers in your source code,' typically as a comment such as 'SPDX-License-Identifier: MIT.' The handling-license-info guidance adds license expressions built from identifiers: 'AND' for licenses that must all be satisfied, 'OR' for a licensee's choice among them, and 'WITH' for a named exception. The guidance states the reason standardization matters directly: 'Saying a BSD-style license can mean a wide range of different licenses...Saying BSD-3-Clause means one specific license.' A scanner matching text to identifiers is only as good as that matching step and the identifier the package author actually declared.

The operating cost

The list itself carries no fee; it is a public specification. Estimated: the cost a founder actually bears is the gap between what a scanner reports and what is true, which shows up only when it is checked, not on any invoice. Any specific automated scanner's accuracy rate is a claim about that tool, documented in that tool's own materials, not something the SPDX list itself states or that this entry asserts.

The stop condition

There is no expiration to reading a manifest correctly once; the check recurs every time a dependency is added, upgraded, or vendored, since a new version can carry a different declared identifier than the one previously recorded. Editorially, the practical stop condition is not a date but an event: a scanner alert or a version bump, either of which should reopen the question of what identifier is actually declared now.

• Does every direct dependency declare an SPDX identifier, or is the license inferred from a registry page instead?
• When a scanner reports a license, has anyone checked that string against the dependency's own LICENSE file?
• Does an upgrade change the declared identifier, and would that change go unnoticed without a recheck?

SPDX identifiers make license claims checkable, not automatically true. The list standardizes the vocabulary; verifying that a given package actually matches its declared entry is still a task for the founder, not the specification.