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.
Why the Two-License View Matters
When declared and discovered licenses do not match, the package should be treated as having two potentially relevant license signals, not one authoritative answer. The declared license is useful intent, but the discovered license may still govern embedded code or copied material inside the artifact. That means the compliance question is not just “what does the package say,” but “what rights apply to the code we actually received?”
This distinction matters because package metadata can lag behind the contents of the shipped artifact. Maintainers can declare one license at the repository or registry level while including third-party code, copied files, or bundled components that carry their own terms. If teams collapse those into a single declared license too early, they can miss obligations that are already present in the package they plan to use.
For open source intake, this is usually a legal and governance problem before it is a technical one, but the technical evidence still matters. A reliable review looks at the manifest, top-level notices, embedded license files, source headers, and any bundled dependencies that may introduce separate terms. That evidence set is what lets teams decide whether the discovered license is truly applicable or just a false positive from scanning.
How to Resolve the Conflict in Practice
Teams should document both the declared and discovered license findings, then compare scope, applicability, and restrictiveness before approving use. If the discovered license is valid and attached to code in the delivered artifact, it should be treated as an active obligation until counsel or the licensing team proves otherwise. If the artifact contains multiple licensing layers, the safer operational assumption is that the stricter relevant terms can shape redistribution, modification, attribution, or notice requirements.
That approach is especially important when the package is part of a software supply chain process. Open source metadata alone is not enough to establish compliance, because a package can be redistributed, repackaged, or vendored in ways that preserve code but obscure provenance. The practical question is not whether the package author intended one license, but whether the distributed artifact contains material governed by another license path. Supply-chain control guidance from OpenSSF is useful here because it reinforces verification of component provenance rather than blind trust in registry metadata.
When review is ambiguous, the decision should pause, not guess. Legal review is the right escalation point when the discovered license may impose different obligations, when the package bundles copied upstream material, or when the scanner output and the maintainer declaration conflict in a way that changes redistribution rights. In those cases, the package should remain gated until the team can explain which terms attach to which files.
What Good Compliance Review Looks Like
Good review separates license detection from license interpretation. Detection finds signals in the artifact, while interpretation decides whether those signals are legally operative, duplicated, relicensed, or limited to a subcomponent. Teams that do this well preserve file-level evidence, keep a record of the declared and discovered results, and tie the final decision to the exact version of the package they consumed rather than to a generic project page.
It also helps to track whether the discovered license is merely informational or actually binding on distributed code. Some scan results come from notices, examples, or test fixtures that do not change the package’s overall licensing posture. Others point to copied code or embedded third-party libraries that absolutely do. The difference is material, so the review process should force that distinction instead of assuming every mismatch is equally important.
A defensible workflow is to quarantine the package, compare the file set against the scan output, and resolve ownership of the conflicting material before approval. If the package is critical and the conflict cannot be quickly resolved, the team should substitute a cleaner dependency or get explicit approval for the risk rather than letting ambiguity propagate downstream.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Package provenance and artifact integrity are central when declared and discovered licenses conflict. |
| Recommendation — Verify artifact provenance and inspect the shipped package contents before accepting the declared license. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Policy | The question is about governance of third-party package risk and license due diligence. |
| Recommendation — Require license review and provenance checks for third-party packages before approval. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Conflicting licenses create legal and contractual obligations that must be assessed. |
| Recommendation — Track license obligations as contractual and legal requirements during software intake. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Artifact inspection and dependency scrutiny support secure software composition practices. |
| Recommendation — Inspect third-party components and embedded files before release. | ||
Practitioner Guidance
What to verify: Check whether the discovered license appears in shipped code, copied headers, bundled components, or notices that accompany redistribution. A registry label alone is not enough when the artifact itself contains separate license evidence.
Decision rule: If the discovered license is valid and materially attached to the delivered artifact, treat it as an active compliance input until legal review resolves the conflict. If it is only a scanner artifact or clearly non-operative text, document the finding but do not overstate its effect.
What practitioners underestimate: The hardest failures are not obvious “bad licenses,” but partial mismatches where teams approve the package based on the declared license and later discover that redistribution, attribution, or notice obligations were already embedded in the code they shipped.
Practitioner takeaway: The safe default is to review the artifact, not just the label, and to assume both license signals matter until the evidence proves one of them is not legally operative.