TL;DR: Declared licenses show what maintainers intend, but discovered licenses reveal what is actually embedded in the codebase, and both can create enforceable obligations according to FOSSA. That distinction matters because compliance failures often start with shallow scanning, not with missing policy language, so license governance must extend beyond manifests and registry metadata.
At a glance
What this is: This analysis explains why open source compliance must account for both declared and discovered licenses, because the latter can add enforceable obligations hidden inside the codebase.
Why it matters: For IAM, NHI, and software governance teams, the lesson is that inventory and policy decisions are only as reliable as the deepest scan of what is actually shipped.
Context
Declared licenses are the ones a maintainer states in a project’s metadata or license files, while discovered licenses are license texts or signatures that appear inside the code itself. The governance problem is that these two views can diverge, so a shallow review of registry fields or top-level files can miss obligations that still bind downstream users.
That matters to security and identity practitioners because software supply chain controls increasingly intersect with access governance, third-party risk, and code provenance. When a project carries embedded license material, the issue is not just legal hygiene but control scope: teams need to know what they are consuming, where it came from, and whether their review process is deep enough to catch it.
Key questions
Q: How should teams handle a package when declared and discovered licenses differ?
A: Treat the package as carrying both obligations until legal review proves otherwise. The declared license shows maintainer intent, but a discovered license can still apply if it is valid and embedded in the shipped code. Compliance teams should document both findings, assess restrictiveness in context, and avoid assuming the stated license cancels what was found deeper in the artifact.
Q: Why do shallow license scans create compliance risk?
A: Shallow scans miss files, copied snippets, vendored code, and nested license text that can carry additional obligations. If teams only inspect manifests or registry metadata, they may approve software that looks permissive at the top level but is subject to stricter terms in the code itself.
Q: What should compliance teams do first when a discovered license appears?
A: Verify whether the match is real and then check where the code came from, how it is linked, and whether the obligation changes with distribution. The first step is not escalation alone, but confirming scope so the team can decide whether the license is additive, duplicative, or a false positive.
Q: When does a discovered license override the declared license?
A: It does not override it in a simple either-or sense. If the discovered license is valid and the code is part of the delivered artifact, organisations may need to comply with both sets of obligations. The practical test is whether the discovered material creates an enforceable requirement that the declared metadata did not disclose.
Technical breakdown
Declared vs discovered licenses: why the two views diverge
Declared licenses are the maintainer’s stated terms, usually found in metadata, LICENSE files, or build manifests. Discovered licenses are identified by scanning source files, vendored code, or copied snippets that may carry different obligations. The key technical point is that software composition analysis has to look beyond a single declaration because a package can contain multiple licensing signals with different legal effects.
Practical implication: scan both manifests and source content before approving a component for use.
Why shallow license scans miss embedded obligations
A shallow scan checks the obvious files and assumes they represent the whole project. That approach fails when code is copied from another project, when a dependency includes nested source, or when license text appears in files that are not part of the standard metadata path. The article’s distinction is important because discoverability is a file-level problem, not just a package-level one.
Practical implication: configure tooling to inspect every file, not just top-level metadata.
How dual licensing differs from combined license obligations
Dual licensing gives the end user a choice between alternative licenses offered by the maintainer. Declared and discovered licenses are different: they are not an either-or choice, but an AND condition where both sets of obligations may apply if the discovered license is valid. That means compliance teams must evaluate restrictiveness, linking context, and notice obligations rather than assuming the declared license overrides what was found in code.
Practical implication: treat discovered licenses as additive obligations unless counsel confirms a valid exception.
NHI Mgmt Group analysis
Declared metadata is not a complete control surface: licence governance breaks when teams treat registry fields or a single file as the full truth. Open source packages often carry code that was imported, copied, or nested later in the lifecycle, so the enforceable obligation can sit outside the maintainer’s headline declaration. Practitioners should treat the declaration as one signal, not the final decision point.
Discovered licensing creates governance debt: the real problem is not hidden text alone, but the gap between what a team believes it approved and what actually ships. That gap becomes larger when policy, legal review, and engineering workflows are disconnected. For compliance teams, the operational question is whether the approval process can see the whole artifact, not just the package label.
Deep scanning is the named control concept here. The article’s core lesson is that compliance confidence comes from examining source content, nested dependencies, and license signatures together. That is a software supply chain discipline as much as a legal one, and it is directly relevant to SBOM-driven governance and third-party component review. The practitioner conclusion is simple: if scanning does not reach the full codebase, it cannot reliably prove licence compliance.
Declared and discovered licences should be governed as cumulative obligations: organisations should assume both matter unless a documented legal review says otherwise. That shifts licensing from a metadata check to a continuous control process with policy, tooling, and exception handling aligned. The practitioner takeaway is to design for the worst-case obligation, then narrow it with evidence.
What this signals
License governance fails when teams rely on package metadata alone: the control gap is not the absence of a stated license, but the failure to verify what is actually embedded in the delivered artifact. That means compliance, legal, and engineering teams need a shared view of the scanned codebase, not a single registry field.
Declared and discovered licenses create a provenance question, not just a legal one: once code has been copied, nested, or vendored into a project, the team must know whether the approval process covered the full artifact. In practice, that pushes software supply chain governance closer to evidence-based review than checkbox compliance.
For practitioners
- Deep-scan every dependency Inspect source files, vendored code, and embedded text, not just LICENSE files or registry metadata, before approving a component.
- Classify license obligations by context Evaluate whether copyleft, permissive, or proprietary obligations change based on linking mode, redistribution, or source disclosure requirements.
- Document declared and discovered findings separately Track the maintainer-stated license and any discovered license evidence as distinct review records so legal teams can compare them.
- Add exception handling for mixed-license components Require documented sign-off when a discovered license introduces obligations that differ from the declared terms, especially for copied or nested code.
Key takeaways
- Declared licenses show intent, but discovered licenses can add obligations that only deeper scanning will expose.
- The main failure mode is not missing policy language, but relying on shallow metadata checks that do not inspect shipped code.
- Compliance teams should treat license review as a full-artifact control, with separate evidence for declared terms and discovered material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Provenance | License discovery depends on knowing exactly what code was incorporated into the artifact. |
| Recommendation — Track component provenance so discovered license material is visible before release approval. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Open source packages are third-party software inputs that require controlled review and oversight. |
| Recommendation — Review third-party software inputs under CIS-15 before approving them for production use. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | License compliance depends on protecting and validating the integrity of delivered software content. |
| Recommendation — Apply PR.DS-01 discipline to preserve artifact integrity during software intake and review. | ||
| MITRE ATT&CK | TA0005 — Defense Evasion | Hidden or nested code paths can obscure what is actually present in a component. |
| Recommendation — Map hidden license findings to TA0005 and investigate whether source paths were intentionally obscured. | ||
Key terms
- Declared License: The license a project maintainer explicitly states for a codebase or component. It usually appears in repository metadata, a LICENSE file, or manifest documents, and reflects intended usage terms. It is not enough on its own to determine full compliance obligations when embedded code or dependencies carry other terms.
- Discovered License: A license found by scanning code, dependencies, or embedded text rather than by reading maintainer-provided metadata. Discovered licenses can introduce extra obligations if they are valid and applicable to the component. They matter because the artifact may contain terms that the maintainer did not explicitly declare.
- Dual Licensing: A licensing model where the licensor offers the same software under two or more alternative license choices. The recipient typically selects one path. This is different from a codebase that contains both declared and discovered licenses, where obligations may accumulate rather than present a choice.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for teams that need to connect access control with broader assurance work. It gives security and compliance practitioners a shared foundation for governing identities across modern software environments.
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