Why can license scanners miss copyleft obligations in open source dependencies?

How scanners infer license obligations from open source components

License scanners usually start from metadata because it is fast, scalable, and often good enough for straightforward dependencies. They map package name, version, lockfile entries, and registry records to a known license, then report obligations from that declaration rather than from the full contents of the delivered artifact. That works well when the package is cleanly published and the declaration is accurate, but it becomes brittle once source is vendored, copied, repackaged, or embedded.

The key limitation is that a scanner is not reading legal meaning from the software itself unless it actually inspects the artifact. If it depends too heavily on package registries or manifests, it can miss copied source files, nested third-party code, or bundled components that carry copyleft terms the registry entry never mentions. In practice, the legal risk sits in the delivered codebase, not just in the declaration trail around it.

That is why scanners can give a false sense of completeness. A dependency may be present in one form for build or distribution purposes, while the operative license obligations live in another layer of the artifact tree. The result is an apparently clean bill of materials that does not reflect the actual legal surface area.

Why copyleft is easier to miss than permissive licensing

Copyleft obligations are often embedded in places that declaration-based tools do not prioritise: copied source headers, subdirectories pulled in during vendoring, generated bundles, or vendor snapshots preserved inside a repository. A package manifest may describe the top-level module, but it will not reliably expose the license of a file copied from elsewhere or the obligations attached to a nested code subtree.

Permissive licenses are generally easier for scanners because the signal is usually concentrated in the registry metadata or a small number of standard files. Copyleft is more likely to require provenance-aware inspection, because the practical question is not only “what package is this?” but also “what code was actually redistributed, and under what terms?” That distinction matters when the dependency is transformed during packaging or release.

Tools such as PyPI secrets exposure 2023 and LiteLLM PyPI package breach show how much can hide behind a package boundary, while XZ Utils backdoor 2024 illustrates that the artifact you consume can contain materially different content from what a surface-level lookup suggests.

What good coverage looks like in a real review process

Good license coverage combines declaration data with artifact-level inspection. The scanner should reconcile manifests, lockfiles, embedded third-party notices, copied source trees, vendored directories, and any bundled release artifacts. If those views disagree, the safer assumption is that the declaration alone is incomplete and needs manual follow-up.

For copyleft specifically, teams should care about whether the dependency was redistributed, modified, statically linked, or incorporated into a larger work in a way that can trigger obligations. Those are legal and packaging questions, but they depend on accurate technical inventory. A scanner that stops at the registry can miss the very code path that creates the obligation.

OpenSSF is useful here because it reinforces the broader supply-chain principle: provenance and component visibility are part of security and compliance, not an optional enhancement after the fact.

Risk and Threat Considerations

When license scanners miss copyleft obligations, the immediate risk is compliance blind spots: a team may distribute software under assumptions that do not match the license terms of the code actually shipped. The same gap can also hide security-relevant third-party code, making it harder to know what has been imported, copied, or repackaged.

Failure mechanism: The scanner overweights package metadata, so nested files, vendored code, and copied source are never evaluated against their own license terms. That produces an incomplete inventory and can leave redistribution obligations undiscovered until release, audit, or dispute.

Impact: The organisation can ship non-compliant software, miss required attribution or source-offer obligations, and lose the ability to prove what was actually included in the deliverable. At scale, the same weakness can affect many products because one scanning assumption is repeated across pipelines.

Practitioner Guidance

What to verify: Treat a clean registry result as a starting point, not a conclusion. Verify the package against the actual artifact tree, including vendored directories, copied source, embedded archives, and generated bundles that may carry separate license terms.

Decision rule: If the package metadata and the shipped files disagree, trust the shipped files first and escalate for manual review before release. If the scanner cannot inspect the artifact contents, do not treat its output as sufficient evidence of copyleft compliance.

What practitioners underestimate: License risk is often introduced by packaging choices, not only by the upstream dependency itself. Repackaging, vendoring, and source copying can change the legal picture even when the dependency name and version look familiar.

Practitioner takeaway: The control objective is provenance-aware license coverage, not registry lookup accuracy, because copyleft obligations live in the actual distributed code.

Related resources from NHI Mgmt Group

• What happens when an organisation ignores copyleft obligations in open source dependencies?
• Why do transitive dependencies create unexpected open-source license risk in modern software?
• What breaks when teams rely only on package metadata to assess open-source license obligations?
• How should organisations manage open source license compliance across direct and transitive dependencies?