An open source licence is a legal agreement that defines how software may be used, changed, and shared. It preserves the open nature of the code while setting conditions such as attribution, notice retention, or share-alike obligations. Licence choice directly affects compliance, distribution rights, and commercial use.
Expanded Definition
An open source licence is the legal layer that governs redistribution, modification, and downstream use of software. In NHI and agentic AI environments, licence terms matter because code is often embedded into tooling, automation pipelines, SDKs, and internal platforms that also handle secrets, service accounts, and API-driven execution.
Definitions are stable at a high level, but practical interpretation varies across vendors and legal teams when software is embedded in distributed systems, container images, or managed AI services. The Open Source Initiative’s licence principles remain the usual reference point, while governance teams often map obligations against internal release, attribution, and notice-retention workflows. For operational controls, open source licence review should sit alongside supply chain review in the NIST Cybersecurity Framework 2.0, especially where third-party components influence deployment trust.
Licence choice can determine whether a team may modify code, statically link components, or distribute a derivative product without exposing source changes. The most common misapplication is treating every open source licence as interchangeable, which occurs when teams approve a dependency based only on popularity or package manager metadata.
Examples and Use Cases
Implementing licence compliance rigorously often introduces release friction, requiring organisations to balance fast dependency adoption against legal review, attribution handling, and distribution constraints.
- A security platform embeds an open source parser into an internal agent workflow, then verifies whether redistribution terms require notice retention before shipping the binary.
- An engineering team packages a container image that includes multiple libraries with different obligations, so the release checklist checks whether any copyleft terms could affect downstream distribution.
- A vendor imports a permissively licensed library into a SaaS control plane, then confirms whether customer-facing documentation needs attribution or licence text retention.
- A supply chain review flags code similar to patterns discussed in the PyPI Breach, where package trust and dependency governance matter as much as functionality.
- A product team assesses an upstream change after incidents like the Nx Package Attack, using licence review as part of broader dependency provenance controls.
For engineering and legal teams, licence review is usually paired with dependency vetting, SBOM analysis, and release approval gates. That is especially important when open source components are pulled into CI/CD paths that also manage credentials and signing keys.
Why It Matters in NHI Security
Open source licence issues are not just legal housekeeping. In NHI security, the same pipeline that builds, signs, and deploys software also handles secrets, tokens, and service account access, so weak component governance can expose both compliance and operational risk. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means dependency and licence oversight often intersects with insecure software handling. That is why open source governance belongs in the same control conversation as supply chain integrity and access control.
Misunderstood licence terms can delay remediation, force emergency code replacement, or create unplanned redistribution exposure after a product release. They also complicate incident response when a compromised package must be removed quickly but its legal status was never reviewed. Teams should treat licence review as part of software trust validation, not as a post-release paperwork task. Where package integrity and access abuse converge, the risks become visible in cases such as the LiteLLM PyPI package breach and the SpotBugs Token GitHub Supply Chain Attack, where trust in the software supply chain and the surrounding identity controls both matter.
Organisations typically encounter licence obligations only after a release has shipped, at which point distribution limits and notice requirements become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-5 | Covers supply chain risk management, including third-party software and licence governance. |
| OWASP Agentic AI Top 10 | A07 | Agentic systems inherit risk from third-party tools and libraries with unclear usage rights. |
| OWASP Non-Human Identity Top 10 | NHI-07 | NHI supply chain controls depend on trusted components and managed distribution paths. |
| NIST AI RMF | GOVERN 1.3 | Governance processes should account for third-party AI and software component obligations. |
Review open source dependencies as part of supply chain risk controls before release approval.
