The licence a tool determines most strongly governs a dependency after weighing declared and discovered licence evidence. It is a compliance decision, not a replacement for raw scan data, and it should remain traceable to the evidence and policy that produced it.
Expanded Definition
Licence Concluded is the policy-backed licence outcome an organisation assigns to a dependency after evaluating declared metadata, embedded licence text, package manifests, and other discovered evidence. It is distinct from raw scan results because it represents the decision reached, not every candidate licence signal observed during analysis. In software supply chain and open source governance, that distinction matters because a package can contain inconsistent or incomplete licensing clues, especially when upstream maintainers omit notices or distributors republish components with additional terms. NHI Management Group treats the concept as a compliance control point: the concluded licence should be explainable, reproducible, and mapped to the evidence set that supports it. That makes it useful for legal review, SBOM interpretation, and policy enforcement across build pipelines and release gates. Where evidence conflicts, organisations commonly document the rationale for the final conclusion rather than treating the most visible notice as automatically authoritative. The most common misapplication is to equate the licence concluded with the licence detected by a scanner, which occurs when teams ignore policy precedence and evidence hierarchy.
Examples and Use Cases
Implementing licence conclusion rigorously often introduces review overhead, requiring organisations to balance automation speed against legal defensibility and audit traceability.
- A build system detects both MIT and Apache-2.0 references in a dependency, then records Apache-2.0 as the licence concluded because the package manifest and repository notice align with that outcome.
- A security team reviews a vendored library with a missing SPDX identifier and concludes the licence from the repository notice plus maintainer file history, while preserving the raw scan artefacts for later audit.
- A platform team blocks release of a container image when the concluded licence is marked as copyleft and the product policy disallows distribution under that condition.
- An SBOM workflow uses the concluded licence as the compliance field, while retaining the evidence trail needed to show how the decision was reached during due diligence.
- A procurement review compares the concluded licence of a third-party SDK against internal policy before the component is approved for production use, using guidance from the NIST Cybersecurity Framework 2.0 as a governance reference for managing software risk.
Why It Matters for Security Teams
For security, legal, and engineering teams, the value of a licence concluded lies in making software consumption decisions consistent and defensible. If the term is misunderstood, organisations may overblock safe dependencies, miss restrictive terms that affect redistribution, or lose the evidence trail needed to answer auditors and customers. The issue is especially important in modern CI/CD and SBOM-driven workflows, where machine-generated findings can be numerous but still require a human- or policy-driven conclusion. That is why licence conclusion should be treated as part of governance, not just dependency scanning. It also intersects with broader cyber risk management because software supply chain controls increasingly depend on documented decision points, exception handling, and repeatable evidence collection. Teams managing AI applications and NHI-heavy pipelines should pay particular attention when models, agents, or automation tools pull in transitive code, since licence obligations can attach to components embedded deep in the stack. Organisations typically encounter the cost of an incorrect licence conclusion only after a release, acquisition review, or customer audit, at which point the decision becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | Supply chain governance covers software component risk decisions like licence conclusions. |
| NIST SP 800-53 Rev 5 | SA-10 | Developer and integrator controls address software composition and external component terms. |
| ISO/IEC 27001:2022 | A.5.31 | Legal, statutory, regulatory and contractual requirements include software licence obligations. |
Document licence decisions in supply chain governance and require traceable evidence for every dependency.
