Policy Deliverables Best Practice
These are completed examples of the two deliverables generated by the policy-generator agent.
Compare them with your own output/policy/ files to spot missing items.
Go to reference: Open Source Policy Establishment Chapter Guide
Open Source Policy
Document: oss-policy.md
- Company name: Tech Unicorn
- Version: 1.0
- Date written: 2026-03-23
- Author: DevOps Team Open Source Program Manager
- Approved by: DevOps team leader
- Next review date: 2027-03-23
Related Standards
- 5230 §3.1.1.1·§3.1.4.1·§3.1.5.1·§3.5.1.1·§3.5.1.2
- 18974 §4.1.1.1·§4.1.4.1·§4.1.4.2
This policy document is based on the OpenChain KWG open source policy template (§1–11) and ISO/IEC 5230 and 18974. The KWG guide is licensed under CC BY 4.0.
1. Purpose and scope
Related Standards
- 5230 §3.1.1.1
- 18974 §4.1.1.1
This policy sets the standards for Tech Unicorn (the "Company") to use open source software correctly, fulfill license obligations, and manage security vulnerabilities throughout software development and distribution.
Scope of application
Related Standards
- 5230 §3.1.4.1
- 18974 §4.1.4.1
This policy applies to the following scope:
- Target software: All software developed, distributed, or operated by Tech Unicorn
- Distribution methods: SaaS, app stores (iOS/Android), embedded (installed on devices), and internal systems
- Applicable personnel: All members involved in open source use, including developers, managers, and purchasing/procurement staff
- Exclusions: None
Criteria by distribution channel
Related Standards
- 18974 §4.1.4.2
| Distribution channel | Key risk | Core criteria |
|---|---|---|
| SaaS | AGPL network obligations | Prior review by the Open Source Program Manager is required before adopting AGPL |
| App store | Conflict between App Store policies and the GPL | GPL-family licenses excluded in principle; exceptions allowed after Program Manager review |
| Embedded | Source code disclosure obligations upon distribution | Copyleft licenses strictly restricted; prefer permissive licenses |
| Internal use | No redistribution obligations | Standard review procedure applies (relaxed copyleft allowed) |
2. Open source usage principles
Related Standards
- 5230 §3.1.5.1
- 18974 §4.1.1.1
Mandatory review before use
When adopting a new open source component or changing an existing version, always review the following:
- License check: Compare against the approved license list in
output/policy/license-allowlist.md - License obligation fulfillment plan: For copyleft licenses, decide how obligations such as source code disclosure will be fulfilled
- Known vulnerability check: Generate an SBOM and run a CVE scan to confirm there are no Critical/High vulnerabilities
- Program Manager approval: Obtain approval according to the
output/process/usage-approval.mdprocedure
License classification criteria
| Category | Examples | Obligations upon distribution |
|---|---|---|
| Permissive | MIT, Apache-2.0, BSD | Copyright notice, license notice |
| Weak Copyleft | LGPL, MPL | Disclose source code of modified files |
| Strong Copyleft | GPL-2.0, GPL-3.0 | Disclose full source code (upon distribution) |
| Network Copyleft | AGPL-3.0 | Disclose source code, including for network use |
Package management principles per development language
The Company uses multiple package managers, including Java (Maven/Gradle), Python (pip), JavaScript (npm/yarn), and Go (mod). Dependency licenses must be scanned automatically across all package managers.
3. Program scope and performance metrics
Related Standards
- 18974 §4.1.4.1·§4.1.4.2
Performance metrics (KPI)
| Metric | Target |
|---|---|
| SBOM freshness | Attach an up-to-date SBOM to every release |
| License compliance rate | 100% prior review of newly adopted components |
| Vulnerability response time | Critical: within 1 week, High: within 4 weeks |
| Training completion rate | Open source-related roles complete training at least once a year |
| Renewal cycle | Reconfirm Self-Certification every 18 months |
The vulnerability response deadlines above are the OpenChain KWG guide baseline. Depending on your organization's risk profile and capabilities, stricter deadlines such as 24 hours for Critical and 1 week for High can be adopted as an internal SLA.
Measuring and improving program effectiveness
- Regular evaluation cycle: Evaluate KPI achievement and process compliance at least once a year.
- Evaluation reporting: Report evaluation results to management; for unmet items, include the cause and an improvement plan.
- Continuous improvement: Update the policy and processes based on evaluation results, internal best practices, and industry trends (see Section 9 for the update cycle).
- Resource sufficiency review: Once a year, assess whether open source management staffing and tool budgets are sufficient, and recommend adjustments if necessary.
4. Security assurance policy
Related Standards
- 18974 §4.1.1.1
The Company systematically identifies, tracks, and responds to known vulnerabilities (CVEs) in distributed software:
- Perform an SBOM-based vulnerability scan before every release
- Resolve Critical/High vulnerabilities or establish a mitigation plan before release
- When a new vulnerability is found after release, respond according to the
output/process/vulnerability-response.mdprocedure - Operate an external vulnerability reporting channel: security@techunicorn.example
5. Open source contribution policy
Related Standards
- 5230 §3.5.1.1·§3.5.1.2
Whether contributions are allowed
- Allowed after prior approval — Contributions are allowed after review and approval by the Open Source Program Manager and the legal team
Requirements when contributing
- Prior approval: Approval after review by the DevOps Team Open Source Program Manager and the legal team
- IP check: Confirm whether the contribution contains company confidential information or third-party IP
- License agreement: Confirm whether a CLA (Contributor License Agreement) signature is required
- Record keeping: Record contributions in
output/organization/role-definition.md
Prohibited contributions
- Contributions containing internal company algorithms, trade secrets, or customer data
- Contributing patent-related code without legal team review
- Company work-related contributions through personal accounts
6. Managing externally delivered software
When providing software to external customers and delivery destinations, the Company complies with the following:
- Provide the SBOM with the deliverable (or keep it available for immediate delivery upon request)
- Confirm fulfillment of copyleft license obligations before delivery
- Include open source attribution notices in delivery contracts
- Operate a procedure to notify customers when a new vulnerability is found after delivery
7. Policy dissemination and training
Related Standards
- 5230 §3.1.1.2
- 18974 §4.1.1.2
This policy is disseminated to all program participants through the following methods:
- Included in onboarding training for new hires
- Annual training (or announcement) for all members
- Posted on the internal wiki/shared drive with links shared
- Training completion records:
output/training/completion-tracker.md
8. Handling non-compliance
Related Standards
- 5230 §3.2.2.5
When this policy is violated:
- Report immediately to the Open Source Program Manager
- Identify the violation and its scope of impact
- Establish and implement a corrective action plan
- Update the policy/process to prevent recurrence
9. Policy review and update
Related Standards
- 18974 §4.1.1.1
This policy is reviewed and updated on the following cycle or when triggering events occur:
- Regular review: Once a year (next review date: 2027-03-23)
- Ad hoc review triggers: Standard revisions, regulatory changes, major incidents, change of the Program Manager
- Review owner: DevOps Team Open Source Program Manager, with legal team confirmation
Review history
| Version | Review date | Major changes | Approver |
|---|---|---|---|
| 1.0 | 2026-03-23 | Initial version | DevOps team leader |
10. Policy change requests and operation
Related Standards
- 18974 §4.1.1.1 (operation, G1.2)
- 5230 §3.1.5.1
While §9 defines when the policy is reviewed, this section defines the procedure by which anyone can request a change during day-to-day operation.
Change request flow
- Request: Any member who needs a change to the policy or the approved license list submits a request to the DevOps Team Open Source Program Manager (e.g., adding a new license, an exception for a prohibited license).
- Assessment: The Program Manager reviews license obligations, security, and business impact, obtaining legal team confirmation when necessary.
- Approval: The DevOps team leader approves. Exception approvals are recorded together with their validity period and conditions.
- Application: Upon approval, update the policy or
license-allowlist.mdand record the change in the §9 review history. - Notification: Announce the change through the internal wiki and development team channels.
Monitoring regulatory and standards changes
- Owner: The DevOps Team Open Source Program Manager checks relevant regulatory and standards trends (EU CRA, domestic SBOM mandates, ISO revisions, etc.) at least once a quarter.
- Application: If a change affects the policy, update it through the change request procedure above.
Appendix A. Definitions
Related Standards
- Maps to KWG policy template §2 (Definitions)
The key terms used in this policy are as follows.
| Term | Definition |
|---|---|
| SBOM | Software Bill of Materials. A list of the open source components, their versions, and licenses included in a product (SPDX or CycloneDX format). |
| License obligations | Conditions that must be fulfilled when using open source, such as attribution, copyright notices, and source code disclosure. |
| Copyleft | A license type that requires derivative works to be released under the same license (GPL, AGPL, etc.). |
| Permissive | A license type with few restrictions, centered on notice obligations (MIT, Apache-2.0, BSD, etc.). |
| Vulnerability (CVE) | A publicly identified security flaw. Severity is expressed as a CVSS score. |
| Distribution participant | A member involved in providing the Company's software to external parties. |
| Self-Certification | The procedure of declaring on one's own that the OpenChain (ISO/IEC 5230 and 18974) requirements are met. |
| OSPO | Open Source Program Office. The industry-standard name for a dedicated open source management organization. Corresponds to the "open source organization" in this policy. |
| OSPM | Open Source Program Manager. The industry-standard name for the manager of an open source program. Corresponds to the "Open Source Program Manager" in this policy. |
| OSRB | Open Source Review Board. The industry-standard name for a review board that deliberates on open source use and release. Small organizations may substitute a review by the Program Manager. |
For beginner readability, the body of this policy uses the single terms "Open Source Program Manager" and "open source organization". Refer to the mapping above when comparing this policy with external documents or the KWG template.
Appendix B. Releasing internal projects as open source
Related Standards
- Maps to KWG policy template §8 (Open-sourcing internal projects)
When software developed inside Tech Unicorn is released as open source, it goes through prior approval, intellectual property and security review, license selection, attribution notice preparation, and post-release management. The detailed procedure follows output/process/project-publication-process.md (a process deliverable). If that deliverable does not exist, generate it with the process-designer agent.
Approved License List
Document: license-allowlist.md
- Company name: Tech Unicorn
- Version: 1.0
- Date written: 2026-03-23
- Author: DevOps Team Open Source Program Manager
- Next review date: 2027-03-23
Related Standards
- 5230 §3.1.5.1·§3.3.1.1·§3.3.1.2
Summary of distribution methods: SaaS + app stores (iOS/Android) + embedded + internal use Since embedded and app store distribution are included, copyleft licenses are strictly restricted.
1. Summary of allowance principles per channel
| Distribution channel | Permissive | Weak Copyleft | Strong Copyleft (GPL) | Network Copyleft (AGPL) |
|---|---|---|---|---|
| SaaS | ✅ Allowed | ✅ Allowed | ⚠️ Conditional | ❌ Prohibited |
| App store | ✅ Allowed | ⚠️ Conditional | ❌ Prohibited | ❌ Prohibited |
| Embedded | ✅ Allowed | ⚠️ Conditional | ❌ Prohibited | ❌ Prohibited |
| Internal use | ✅ Allowed | ✅ Allowed | ✅ Allowed | ⚠️ Conditional |
⚠️ Conditional: Requires prior review and approval by the Open Source Program Manager ❌ Prohibited: Cannot be used without Program Manager approval (if an exception is granted, additional legal team review is required)
2. Permissive licenses — allowed on all channels
Obligations: include the copyright notice and license text
| License | SPDX ID | Notes |
|---|---|---|
| MIT | MIT | None |
| Apache License 2.0 | Apache-2.0 | Includes a patent termination clause (irrelevant to typical use) |
| BSD 2-Clause | BSD-2-Clause | None |
| BSD 3-Clause | BSD-3-Clause | Restrictions on promotional/advertising use |
| ISC | ISC | None |
| Unlicense | Unlicense | Similar to public domain |
| CC0 1.0 | CC0-1.0 | Mainly used for documents and data rather than software code |
| Boost Software License 1.0 | BSL-1.0 | None |
| zlib | Zlib | Modified versions must be clearly marked as different from the original |
3. Weak copyleft licenses — conditionally allowed per channel
Source code disclosure obligations may arise for modified files. Program Manager review required.
| License | SPDX ID | SaaS | App store | Embedded | Internal use | Notes |
|---|---|---|---|---|---|---|
| LGPL-2.1 | LGPL-2.1-only | ✅ | ⚠️ | ⚠️ | ✅ | Obligations relaxed with dynamic linking; Program Manager review required for static linking |
| LGPL-3.0 | LGPL-3.0-only | ✅ | ⚠️ | ⚠️ | ✅ | Same as LGPL-2.1; embedded adds the obligation to provide installation information |
| MPL-2.0 | MPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | Only modified files must be disclosed; file-level copyleft |
| CDDL-1.0 | CDDL-1.0 | ✅ | ⚠️ | ⚠️ | ✅ | Incompatible with the GPL; beware of mixing |
| EPL-2.0 | EPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | Patent termination clause; obligation to disclose modified source |
4. Strong copyleft licenses — prohibited for embedded and app store
Full source code disclosure obligations arise. Prohibited in principle for embedded and app store distribution.
| License | SPDX ID | SaaS | App store | Embedded | Internal use | Remarks |
|---|---|---|---|---|---|---|
| GPL-2.0 | GPL-2.0-only | ⚠️ | ❌ | ❌ | ✅ | Full source disclosure upon distribution; conditionally allowed for SaaS since no distribution occurs |
| GPL-3.0 | GPL-3.0-only | ⚠️ | ❌ | ❌ | ✅ | GPL-2.0 plus patent and anti-tivoization clauses |
Rationale for conditionally allowing GPL in SaaS: SaaS does not "distribute" software to customers, so GPL source disclosure obligations do not arise directly. However, if GPL code used in the service is modified, GPL conditions must still be complied with internally.
5. Network copyleft licenses — prohibited for SaaS
Source code disclosure obligations arise merely from providing a service over a network.
| License | SPDX ID | SaaS | App store | Embedded | Internal use | Remarks |
|---|---|---|---|---|---|---|
| AGPL-3.0 | AGPL-3.0-only | ❌ | ❌ | ❌ | ⚠️ | Source disclosure obligations arise when providing SaaS; even for internal use, Program Manager review is required if external exposure is possible |
| EUPL-1.2 | EUPL-1.2 | ⚠️ | ❌ | ❌ | ✅ | Includes network use clauses; Program Manager review required for SaaS use |
6. Prohibited licenses
The following licenses are prohibited on all channels due to legal uncertainty or incompatibility.
| License | Reason for prohibition |
|---|---|
| SSPL-1.0 (Server Side Public License) | Created by MongoDB; not OSI-approved; obligation to disclose the entire service |
| BUSL (Business Source License) | Converts to open source only after a set period, or restricts commercial use |
| Licenses with the Commons Clause | Violates the open source definition; prohibits commercial sale |
| Proprietary / Unknown | Components with unidentified licenses must be confirmed with the Program Manager before use |
7. License compatibility precautions
License scan tools per package manager
| Package manager | Scan tool | Remarks |
|---|---|---|
| Maven (Java) | License Maven Plugin, FOSSA | Analyzes pom.xml dependencies |
| Gradle (Java) | License Gradle Plugin | Analyzes build.gradle dependencies |
| pip (Python) | pip-licenses, FOSSA | Analyzes requirements.txt |
| npm/yarn (JS) | license-checker, FOSSA | Analyzes package.json dependencies |
| Go mod | go-licenses | Analyzes go.mod dependencies |
Prohibited combinations
| Combination | Reason |
|---|---|
| GPL-2.0 + Apache-2.0 | GPL-2.0 is incompatible with the Apache-2.0 patent clause |
| GPL-2.0 + GPL-3.0 | Version incompatibility (cannot be combined with GPL-3.0-only licenses) |
| CDDL + GPL | License incompatibility (officially confirmed by Mozilla) |
8. Exception handling procedure
When a license outside the approved list or a prohibited license must be used:
- Submit the reason and scope of use in writing to the Open Source Program Manager
- Legal review by the legal team
- Joint approval by the Program Manager and the legal team
- Record the approval and decide whether to add the license to the list at the next policy review
Approved exceptions
Approved exceptions are recorded below and re-reviewed on their expiration date. Expired exceptions are considered invalid until re-reviewed.
| Component / license | Approval reason | Conditions / scope | Approver | Approval date | Expiration / re-review date |
|---|---|---|---|---|---|
| (No approved exceptions at this time) | — | — | — | — | — |
9. Review history
| Version | Review date | Major changes | Reviewer |
|---|---|---|---|
| 1.0 | 2026-03-23 | Initial version | DevOps Team Open Source Program Manager |