TL;DR: Knowledge base lookups are fast but can miss embedded copyleft obligations, while source code analysis is slower but produces audit-grade license evidence, according to FOSSA. For teams distributing software, the trade-off is not convenience versus perfection but whether compliance controls reflect the full reality of the codebase.
At a glance
What this is: This is FOSSA's analysis of two common OSS license detection methods, showing that metadata lookup is faster but can miss hidden obligations, while source analysis is more complete.
Why it matters: It matters because distributed software teams need license evidence that stands up in audits, and incomplete scanning can leave legal and compliance exposure in place.
Context
Open source license compliance is a governance problem, not just a tooling problem. Once software is distributed, the organisation must account for the actual license terms attached to every dependency, including transitive components and embedded source that package metadata may not reveal.
The article compares two detection models: knowledge base lookup and direct source analysis. That distinction matters for IAM and security teams because governance failures often begin with incomplete asset or obligation inventory, and here the same pattern appears in software compliance: if the scanner only sees declared metadata, it may miss the real obligation set.
Key questions
Q: How should teams choose between metadata-only and source-level license scanning?
A: Choose based on distribution risk. Metadata-only scanning can be acceptable for low-risk internal projects, but distributed software needs source-level analysis because obligations can live in embedded code, headers, or vendored components that package metadata never exposes. The more externally visible the product, the less defensible a lookup-only model becomes.
Q: Why can license scanners miss copyleft obligations in open source dependencies?
A: They miss them when the scanner trusts package registries or manifests more than the actual artifact. Copyleft terms may be buried in copied source, nested files, or vendored code, so a declaration-based lookup can return an incomplete legal picture even when the dependency is technically present.
Q: What are the signs that a license compliance program is too shallow?
A: Common signs include frequent surprises during release review, unexplained NOTICE file changes, repeated manual corrections, and license findings that appear only after source inspection. Those symptoms usually mean the organisation is scanning for declared licenses, not the full set of obligations attached to shipped code.
Q: How can organisations keep license scanning defensible without drowning in false positives?
A: Use a review workflow that records why a finding was accepted, dismissed, or escalated. The goal is not to eliminate every extra match, but to preserve traceability so a later audit can explain how each material license decision was made and by whom.
Technical breakdown
Knowledge base lookup and metadata-only license detection
A knowledge base scanner maps package names and versions to known licenses using registry metadata, package manifests, or repository information. It is fast because it does not need to fetch or inspect the code itself. The trade-off is that it only knows what the package claims, not what the package contains. If a dependency includes copied source, vendored code, or a hidden license header, the lookup model can return an incomplete answer even when the obligation is real. That makes the method useful for low-risk visibility, but weak where distribution and legal defensibility matter.
Practical implication: Use metadata-only scanning only where the compliance stakes are genuinely limited and the dependency inventory is tightly controlled.
Source code analysis and hidden copyleft obligations
Source analysis downloads the package or source artifact and searches actual files for license text, headers, and copied code. That lets the scanner detect obligations that never appear in registry metadata, including cases where one component contains code from another project under a different license. This is the more defensible model when products are distributed externally, because compliance depends on what ships, not what the package index says. The cost is higher friction, more compute, and more triage, but the result is closer to audit-grade evidence rather than a best-effort classification.
Practical implication: For distributed software, make source-level license detection the default and treat metadata-only results as incomplete until verified.
Triage false positives without losing audit evidence
Comprehensive scanning often returns multiple licenses for one component because the tool may find notices in source files, README content, examples, or vendored dependencies. That does not mean every hit is equally binding, but it does mean the organisation needs a review process that can confirm, dismiss, or document each finding. The important control is not suppressing noise blindly. It is preserving traceability so the compliance team can explain why a license was accepted, ignored, or escalated. Mature programs do this because the cost of uncertainty is higher than the cost of review.
Practical implication: Create a documented review workflow for multi-license findings so legal, engineering, and compliance can preserve traceability.
Threat narrative
Attacker objective: The practical outcome is not attacker-led compromise but ungoverned distribution of software that carries undisclosed license obligations.
- Entry occurs when a dependency is introduced through package metadata or registry lookup without examining the underlying code artifact.
- Credential access is not the issue here; the risk is obligation blind spots, where embedded GPL or other copyleft code remains undiscovered.
- Impact occurs when the organisation distributes software with incomplete notices or unaccounted copyleft terms and then fails an audit or faces forced remediation.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Metadata-only license detection creates a compliance blind spot when the obligation lives in the code, not the registry. License governance fails when organisations equate declared package metadata with the full legal state of the dependency. That assumption is attractive because it is fast and scalable, but it is wrong whenever vendored code, embedded text, or copied source changes the obligation set. The practitioner conclusion is simple: speed is useful, but it cannot be the only control where software is distributed.
Source-level analysis is the control that turns OSS compliance from a best effort into an auditable process. If the organisation needs to prove what shipped, it must inspect the actual artifact, not just the package record. That is the same governance principle that underpins identity and access controls: inventory is only defensible when it reflects reality. The practitioner conclusion is to treat direct analysis as the default for products that leave the building.
Copyleft exposure is a hidden dependency problem, not just a legal one. Copyleft risk emerges when a component carries obligations that are not visible in the dependency declaration path. This is why compliance teams need a detection model that can surface embedded source and not just known package names. The practitioner conclusion is to align scanner choice with distribution risk, not with convenience.
Audit readiness depends on traceability, not on the lowest alert count. Comprehensive scanners often create more triage work, but that work is what produces evidence a legal or audit reviewer can defend. The governance mistake is to optimise for fewer findings instead of better explanations. The practitioner conclusion is to build a review and documentation path for every material license finding.
Open source compliance now behaves like an identity governance problem for software obligations. Teams need to know what is present, what is inherited, and what is actually enforceable across the runtime and distribution path. That makes license detection a lifecycle control, not a point-in-time check. The practitioner conclusion is to govern dependencies with the same discipline used for other high-impact assets.
From our research library:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
What this signals
License detection is an obligation-discovery problem, not a package lookup problem. Teams that rely on registry metadata alone are optimising for speed before completeness, which is the wrong order when distributed software creates legal exposure. The practical signal for readers is to treat source analysis as the baseline for anything that ships outside the organisation.
Compliance evidence has to follow the artifact, not the declaration. When license terms are embedded in vendored code or nested source files, only artifact-level inspection can produce defensible records. That means release governance should be tied to what is actually built and distributed, not just to the dependency graph.
OSS governance works best when engineering and legal share the same review trail. The more complete the scanner, the more important the triage process becomes, because traceability is what turns a noisy finding into an auditable decision. For practitioners, the key shift is from simple detection toward documented disposition.
For practitioners
- Prefer source-level license detection for distributed products Use direct code analysis as the default for software that leaves the organisation, so hidden license text and vendored code are discovered before release.
- Treat metadata-only scans as incomplete evidence Reserve knowledge base lookup for low-risk internal projects or as a fallback when source is unavailable, and document the limitation in compliance records.
- Build triage workflows for multi-license findings Require legal or compliance review for components that surface more than one applicable license, and keep the decision trail with the build record.
- Track copyleft obligations across transitive dependencies Map whether GPL, AGPL, or other copyleft terms appear in embedded or downstream code, not only in top-level package metadata.
Key takeaways
- Open source license compliance fails when teams rely on declared package metadata instead of the actual shipped code.
- Source-level analysis is slower, but it is the only approach in this article that consistently exposes hidden copyleft obligations and supports audit-grade evidence.
- Mature compliance programmes should pair comprehensive scanning with a documented triage process so legal, engineering, and compliance can defend each license decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | License compliance depends on an accurate dependency inventory and artifact view. |
| Recommendation — Inventory dependencies at the artifact level so declared metadata does not become your only source of truth. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Released source and dependency artifacts need controlled handling and evidentiary integrity. |
| Recommendation — Protect build artifacts and dependency evidence so compliance records remain trustworthy and reviewable. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | OSS license scanning is part of securing the software supply chain and release process. |
| Recommendation — Embed license checks into the software release workflow and require review for risky dependency changes. | ||
| SLSA | L3 — Build and Provenance Integrity | Source analysis and traceability support stronger provenance for distributed software. |
| Recommendation — Preserve provenance from dependency intake through release so license decisions can be traced to shipped artifacts. | ||
Key terms
- License Compliance Review: License compliance review is the process of checking whether an organisation can meet the obligations attached to a software license. In practice, this means reading the terms, identifying restrictions on use, redistribution, or modification, and deciding whether internal policies and legal advice support adoption. It is broader than a simple approved-license checklist.
- Copyleft Licence: A copyleft licence is an open source licence that allows use and modification but requires derivative works or certain modifications to remain under the same licence terms. The practical effect is governance pressure on redistribution and packaging decisions, especially when open source code is combined with proprietary components.
- Source Code Analysis: Source code analysis for license compliance means downloading the real package or repository content and searching it for license files, headers, and embedded license text. It is slower than metadata lookup, but it provides a much stronger evidentiary basis for audits because it reflects what is actually in the artifact.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org