Notifications
Clear all
Topic starter
18/08/2026 2:49 pm
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.
NHIMG editorial — based on content published by FOSSA: declared and discovered open source licenses
Questions worth separating out
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.
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.
Q: What do compliance teams get wrong about dual licensing?
A: They often assume any mix of licenses creates a choice.
Practitioner guidance
- 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.
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
👉 Read FOSSA's analysis of declared and discovered open source licenses →
Declared vs discovered licenses: where compliance teams get caught?
Explore further
18/08/2026 3:31 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Declared and discovered open source licenses change compliance risk
