Declared and discovered open source licenses change compliance risk

At a glance

What this is: This is an analysis of how declared and discovered open source licenses differ, and why both can shape compliance obligations.

Why it matters: It matters to IAM and security practitioners because software supply chain governance increasingly depends on knowing what is really present in code, dependencies, and artifacts, not just what is declared.

👉 Read FOSSA's analysis of declared and discovered open source licenses

Context

Open source compliance fails when teams treat metadata as the full picture. Declared licenses describe intended terms, but embedded code can carry additional obligations that only file-level analysis reveals, which is why license governance has to look beyond package manifests and LICENSE.txt files. The same pattern shows up across broader identity and supply chain governance: what is declared is not always what is operative.

For security and compliance teams, the practical issue is control scope. If scanning stops at the repository edge, teams can miss nested license text, copied snippets, or transitive obligations that change how software may be distributed or modified. That gap is especially relevant in programmes that already depend on continuous asset visibility, because hidden terms function like hidden exposure elsewhere in the stack.

Key questions

Q: How should organisations handle declared and discovered licenses in the same codebase?

A: They should treat them as cumulative unless legal review says otherwise. Declared licenses show intent, but discovered licenses may add enforceable terms that affect distribution, modification, or notice requirements. The safest approach is deep scanning, explicit policy mapping, and escalation for ambiguous cases before release.

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 do compliance teams get wrong about dual licensing?

A: They often assume any mix of licenses creates a choice. In reality, a declared license and a discovered license usually create an AND relationship, meaning both sets of obligations may apply unless the licensing terms explicitly state otherwise.

Q: How can teams reduce false positives in discovered license reviews?

A: Use file-level scanning combined with policy rules and human review for edge cases. False positives often arise from README files, tests, or copied text that is not actually governing the component, so reviewers need evidence-based thresholds before escalating or rejecting a package.

Technical breakdown

Declared licenses vs discovered licenses in code

Declared licenses are the terms the maintainer explicitly publishes, usually in repository metadata, LICENSE files, or manifests. Discovered licenses are identified by scanning source files and dependencies for embedded license text or signatures that were not formally declared. The distinction matters because code can contain both the stated license and additional inherited obligations, especially when snippets, copied files, or vendored dependencies are present. A shallow scan can therefore produce a false sense of compliance coverage.

Practical implication: scan at file and dependency level, not just at package metadata level.

Why discovered licenses create dual obligations

When a discovered license is valid, it can attach obligations alongside the declared license rather than replacing it. That means the end user may need to comply with both sets of terms, including notice preservation, source disclosure, or linking conditions depending on the license family. This is not the same as a dual-license offer, where the recipient chooses one licence path. Compliance teams need to separate choice-of-license scenarios from stacked obligations in the same codebase.

Practical implication: classify each license finding by obligation type before deciding how the component can be used.

Why shallow scanning misses compliance risk

Many compliance tools and processes stop at top-level manifests or registry metadata, which only tells you what a maintainer intended, not what a dependency tree actually contains. Deep scanning is needed to inspect every file, identify copied fragments, and distinguish true license text from false positives in docs or tests. Policy rules also matter because the restrictiveness of a license can change with context, such as static versus dynamic linking under LGPL-style terms.

Practical implication: use deep scanning plus policy-based review to catch license terms hidden below the manifest layer.

NHI Mgmt Group analysis

Declared license governance is necessary but insufficient. The maintainer's stated license tells only part of the compliance story because embedded code can introduce additional terms that alter distribution and modification rights. This is a control-gap problem, not a terminology problem: governance programs that stop at registry metadata are blind to real obligation exposure. Practitioners should treat declared licenses as the starting point, not the compliance conclusion.

Discovered licenses create a hidden obligations layer that many teams still under-model. When a project contains copied or nested license text, the compliance burden can expand even if the top-level license looks permissive. That means policy needs to resolve what is present in the artifact, not just what the repository owner claims. Teams should build review workflows that can handle mixed obligation sets without assuming a single declared license settles the matter.

License compliance is becoming a file-level governance problem. The more software is assembled from dependencies, generated code, and copied snippets, the more important it becomes to inspect the code itself. This is where software supply chain controls intersect with identity-style governance thinking: the authoritative record is the artifact, not the label attached to it. Practitioners should align scanning depth with the distribution risk of each package.

Nested-license ambiguity is a policy design issue, not just a tooling issue. Even good scanners cannot replace a clear rule set for how the organisation handles conflict, ambiguity, or false positives. Teams need documented decision paths for when discovered terms override expectations, when legal review is required, and when a component must be excluded. The maturity signal is whether the programme can explain its decisions consistently.

Continuous monitoring matters because the obligation surface can change over time. New dependencies, vendored code, and upstream file changes can introduce discovered licenses long after the first review. That makes license compliance an ongoing control rather than a one-time approval step. Practitioners should connect source control monitoring, dependency review, and legal escalation into a single workflow.

What this signals

License governance is converging with broader software supply chain assurance. Teams that already manage secrets, dependencies, and code provenance as control problems will recognise the same failure pattern here: the authoritative record is the artifact, not the declaration.

Artifact truth gap: compliance programs fail when they trust the label more than the file. That same governance pattern appears in identity and NHI programmes, where declared ownership or intended scope is not enough without continuous verification. Practitioners should expect more scrutiny of file-level evidence in audits and vendor assessments.

As software estates get more fragmented, the operational burden shifts from point-in-time review to continuous evidence collection. Teams that align license review with change detection and dependency monitoring will be better placed to absorb upstream changes without slowing delivery.

For practitioners

• Deep-scan every component before approval Inspect source files, vendored code, and dependency trees rather than relying on registry metadata or a top-level LICENSE.txt check.
• Separate declared and discovered obligations in policy Record which obligations come from maintainer-declared terms and which come from embedded or nested license text so reviewers can see the full compliance set.
• Escalate ambiguous findings for legal review Route false positives, mixed-license components, and static-linking edge cases into a defined review path before the software reaches release.
• Monitor upstream changes continuously Re-scan dependencies and source artifacts when upstream packages change, because newly introduced files can change the compliance profile after initial approval.

Key takeaways

• Declared licenses are only the starting point because discovered licenses can add real obligations hidden inside code.
• Shallow scans and manifest-only checks miss nested terms, copied files, and other compliance risks that alter release decisions.
• Strong compliance programmes combine deep scanning, policy-based evaluation, and legal escalation for ambiguous license findings.

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.
• Nested License: License text or licensing signals embedded inside a larger project, usually through copied code, vendored files, or included components. Nested licenses may sit alongside the declared license and create additional compliance duties. They are often the reason a permissive-looking project still needs careful legal review.
• 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.

What's in the full article

FOSSA's full article covers the practical detail this post intentionally leaves for the source:

• Examples of how discovered licenses appear inside source files and dependency trees
• Nuanced discussion of when LGPL obligations change with static versus dynamic linking
• The distinction between true dual licensing and mixed declared-plus-discovered obligations
• Practical guidance for policy rules that evaluate license restrictiveness in context

👉 FOSSA's full article covers the compliance nuances, scanning depth, and obligation handling in more detail.

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. It is designed for practitioners who need a clear control model for identity-related risk across modern environments.