The Common Public License 1.0 is an open source software licence that permits use, modification and distribution of covered code. It includes reciprocal terms for distributed changes and defines how contributors grant rights to downstream users, so licence compatibility and source disclosure matter when the code is reused in larger software projects.
What the licence means for reuse and distribution
The Common Public License 1.0 is a reciprocal open source licence, so its core issue is not just whether code can be used, but how modified code must be shared when distributed. That makes it a legal and operational control point for software teams, especially when code is embedded into larger products or combined with other licences.
Unlike a permissive licence, a reciprocal licence can affect the way a larger project is packaged, distributed, and documented. Teams need to understand the licence terms early, because the compliance burden often appears only when code is reused, redistributed, or incorporated into a product with its own licensing model.
Why compatibility matters in mixed codebases
Licence compatibility becomes important when a project combines code under different legal terms. If a component is reused without checking the obligations attached to it, the result can be an incompatible distribution model, a delayed release, or a forced change in how source code and notices are provided.
This is especially relevant in software supply chains where one dependency can carry obligations into downstream builds. The practical question is not whether the code is valuable, but whether the licence terms can coexist with the rest of the project’s legal and distribution structure.
In large projects, the risk is often less about the licence text itself and more about poor inventory and attribution discipline. If teams do not track where covered code appears, they may miss disclosure, notice, or redistribution obligations until late in the release cycle.
How organisations assess exposure to licence obligations
Organisations normally start by identifying every repository, package, and third-party component that includes the licence. They then check how the code is used, whether it is modified, and whether the distribution model triggers the reciprocal terms that matter under the licence.
For teams that manage many dependencies, a licence review is most reliable when tied to software inventory, build artefacts, and release governance. That is why open source governance should sit alongside secure development and third-party dependency management, not as a separate afterthought.
When a project mixes licences, the assessment should also confirm whether notices, source disclosures, and redistribution requirements can be met without conflicting with commercial distribution plans. If the answer is unclear, legal and engineering review should happen before release rather than after.
Practitioner guidance for using licenced open source safely
Governance implication: Treat licence review as part of software intake and release approval, not just legal review at the end. The licence terms should be documented alongside dependency provenance, modification status, and distribution intent so downstream obligations are visible before code is shipped.
What to watch for: Pay close attention when covered code is modified, merged into a broader product, or redistributed outside the organisation. Those are the moments when reciprocal terms and source disclosure requirements are most likely to become operationally important.
Practitioner takeaway: The safest approach is to know the licence status of every reused component before it becomes part of a release path, because compliance problems usually emerge from integration, not from the original import.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM, SLSA and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | Software Security Strategy | Licence governance belongs in secure software development and third-party intake practices. |
| Recommendation — Embed open source licence review into software governance and release decisions. | ||
| SLSA | Supply Chain Integrity | The term affects how reused code is tracked and released through software supply chains. |
| Recommendation — Track component provenance and release obligations across the build and distribution pipeline. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Open source licence terms create contractual obligations that must be identified and met. |
| A.5.9 — Inventory of information and other associated assets | Licence compliance depends on knowing which code and components are in use. | |
| Recommendation — Identify licence obligations and include them in compliance and release controls. Maintain an inventory of licensed components and their obligations. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Software composition and release governance are central to safe reuse of open source code. |
| Recommendation — Review third-party components and licensing before integrating them into releases. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org