Policy Output Best Practice
This is a completed example of two outputs generated by policy-generator agent.
Use it to check missing items by comparing it with your output/policy/ file.
Go to reference: Open Source Policy Establishment Chapter Guide
Open source policy
Document: oss-policy.md
- Company Name: Tech Unicorn
- Version: 1.0
- Written date: 2026-03-23
- Author: DevOps Team Open Source 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
1. Purpose and scope of application
Related Standards
- 5230 §3.1.1.1
- 18974 §4.1.1.1
This policy sets standards for Tech Unicorn (hereinafter referred to as “Company”) to properly use open source software, fulfill license obligations, and manage security vulnerabilities during software development and distribution.
applied area
Related Standards
- 5230 §3.1.4.1
- 18974 §4.1.4.1
This policy applies to the scope below:
- Target software: All software developed, distributed, and operated by Tech Unicorn
- Distribution method: SaaS, App Store (iOS/Android), embedded (device mounted), internal system
- Applicable Personnel: All members involved in the use of open source, including developers, managers, and purchasing/procurement personnel.
- Exclusions: None
Criteria by distribution channel
Related Standards
- 18974 §4.1.4.2
| Distribution Channel | Key risks | Core Standards |
|---|---|---|
| SaaS | AGPL Network Obligations | When introducing AGPL, prior review by open source personnel is required |
| App Store | App Store Policy and GPL Conflict | GPL series are excluded in principle, exceptions are allowed after review by the person in charge |
| Embedded | Obligation to disclose source code when distributing | Copyleft series strictly limited, Permissive used first |
| For internal use | No obligation to redistribute | Apply standard review procedures (allow for relaxed copyleft) |
2. Principles of using open source
Related Standards
- 5230 §3.1.5.1
- 18974 §4.1.1.1
Obligation to review before use
When introducing new open source or changing existing versions, be sure to review the following:
- License Check: Check against
output/policy/license-allowlist.md's list of permitted licenses. - License obligation implementation plan: In case of copyleft license, confirmation of implementation method, such as source code disclosure obligation, etc.
- Check known vulnerabilities: After creating SBOM, scan CVE to confirm that there are no Critical/High vulnerabilities.
- Approval by person in charge: Approved according to
output/process/usage-approval.mdprocedure
License classification criteria
| Category | Example | Obligations for distribution |
|---|---|---|
| Permissive | MIT, Apache-2.0, BSD | Copyright notice, license notice |
| Weak Copyleft | LGPL, MPL | Modified file source code released |
| Strong Copyleft | GPL-2.0, GPL-3.0 | Full source code disclosed (when distributed) |
| Network Copyleft | AGPL-3.0 | Source code disclosure including network use |
Package management principles for each development language
The company uses various package managers such as Java (Maven/Gradle), Python (pip), JavaScript (npm/yarn), and Go (mod), and dependency licenses must be automatically scanned in all package managers.
3. Program coverage and performance metrics
Related Standards
- 18974 §4.1.4.1·§4.1.4.2
Performance Metrics (KPI)
| indicators | Goal |
|---|---|
| SBOM Latest | Attach the latest SBOM to every release |
| License Compliance Rate | 100% preliminary review of newly introduced components |
| vulnerability Response Time | Critical: 1 week, High: within 4 weeks |
| Education Completion Rate | Completion of open source-related occupations at least once a year |
| Update cycle | Self-certification Revalidation every 18 months |
Note: The above deadlines are ISO/IEC 18974 and OpenChain KWG baselines. If organizational capabilities allow, more stringent deadlines, such as 24 hours for Critical and 1 week for High, can be applied as internal standards.
Measure and improve program effectiveness
- Regular evaluation cycle: Evaluate KPI achievement and process compliance status at least once a year.
- Evaluation Report: The evaluation results are reported to management, and the cause and improvement plan for unsatisfactory items are also listed.
- Continuous improvement: Update policies and processes based on evaluation results, internal best practices, and industry trends (see Section 9 for update cycle).
- Resource sufficiency review: Once a year, evaluate the sufficiency of open source management personnel and tool budget 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 (CVE) in distributed software:
- Perform SBOM based vulnerability scan before every release
- Critical/high vulnerabilities must be resolved or a mitigation plan established before deployment.
- If new vulnerabilities are discovered after deployment, respond according to
output/process/vulnerability-response.mdprocedures - Operation of external vulnerability reporting channel: security@sktelecom.com
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 possible after review and approval by the open source manager and legal team.
Rules to follow when contributing
- Pre-approval: Approved after review by DevOps team open source representative and legal team
- IP Verification: Check whether your contribution contains confidential company information or third-party IP.
- License Agreement: Check whether you need to sign a Contributor License Agreement (CLA)
- Record Keeping: Record your contributions in
output/organization/role-definition.md
Contribution Prohibitions
- Contributions including company internal algorithms, trade secrets, and customer data
- Contribute patent-related code without review by the legal team
- Contributions related to company work through personal accounts
6. Management of externally delivered software
The company complies with the following when providing software to external customers and suppliers:
- Provide SBOM with the delivery (or keep it available for immediate delivery upon request)
- Delivery after confirmation of prior fulfillment of copyleft license obligations
- Include open source-related notices in the delivery contract
- Operate notification procedures to customers when new vulnerabilities are discovered after delivery
7. Policy dissemination and education
Related Standards
- 5230 §3.1.1.2
- 18974 §4.1.1.2
This policy will be disseminated to all program participants in the following ways:
- Includes onboarding training for new employees
- Training (or notice) for all members once a year
- Post and share links on in-house wiki/shared drives
- Training completion record:
output/training/completion-tracker.md
8. Handling non-compliance
Related Standards
- 5230 §3.2.2.5
If you violate this policy:
- Immediately report to the open source representative
- Identify the violation and scope of impact
- Establish and implement corrective action plan
- Supplementing policies/processes to prevent recurrence
9. Policy review and update
Related Standards
- 18974 §4.1.1.1
This policy is reviewed and updated at the following intervals or when reasons arise:
- Regular review: Once a year (Next review date: 2027-03-23)
- Reason for regular review: Standard revision, regulation change, major accident, change in person in charge
- Review manager: DevOps team open source manager, legal team confirmation
Review history
| version | Review date | Major changes | Approver |
|---|---|---|---|
| 1.0 | 2026-03-23 | Originally written | DevOps Team Leader |
List of permitted licenses
Document: license-allowlist.md
- Company Name: Tech Unicorn
- Version: 1.0
- Written date: 2026-03-23
- Author: DevOps Team Open Source 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 Store (iOS/Android) + Embedded + Internal use Copyleft license is strictly restricted as it includes embedded and app store distribution.
1. Summary of acceptance principles for each 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 |
| For internal use | ✅ Allowed | ✅ Allowed | ✅ Allowed | ⚠️ Conditional |
⚠️ Conditional: Requires prior review and approval by open source staff ❌ Prohibited: Cannot be used without approval from the person in charge (If an exception is allowed, additional review by the legal team is required)
2. Permissive license — allows all channels
Mandatory: Include copyright notice and license text
| License | SPDX ID | Precautions |
|---|---|---|
| MIT | MIT | None |
| Apache License 2.0 | Apache-2.0 | There is a patent termination clause (regardless of general use) |
| BSD 2-Clause | BSD-2-Clause | None |
| BSD 3-Clause | BSD-3-Clause | Promotion/Advertising Use Restrictions |
| ISC | ISC | None |
| Unlicense | Unlicense | Public Domain Similar |
| CC0 1.0 | CC0-1.0 | Mainly used for documents and data other than software code |
| Boost Software License 1.0 | BSL-1.0 | None |
| zlib | Zlib | When modifying, it is necessary to clearly distinguish it from the original |
3. Weak Copyleft License — Channel-specific conditional permission
There may be an obligation to disclose the source code of modified files. Personnel review required.
| License | SPDX ID | SaaS | App Store | Embedded | For internal use | Precautions |
|---|---|---|---|---|---|---|
| LGPL-2.1 | LGPL-2.1-only | ✅ | ⚠️ | ⚠️ | ✅ | Relaxation of obligations when dynamic linking. Personnel review required for static linking |
| LGPL-3.0 | LGPL-3.0-only | ✅ | ⚠️ | ⚠️ | ✅ | Same as LGPL-2.1. Added obligation to provide installation information for embedded |
| MPL-2.0 | MPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | Only modified files are disclosed. Copyleft per file |
| CDDL-1.0 | CDDL-1.0 | ✅ | ⚠️ | ⚠️ | ✅ | Incompatible with GPL. Caution on mixing |
| EPL-2.0 | EPL-2.0 | ✅ | ⚠️ | ⚠️ | ✅ | Patent termination clause, duty to disclose source of modifications |
4. Strong Copyleft License — Embedded and App Store prohibited
Obligation to disclose entire source code arises. In principle, it is prohibited for embedded and app store distribution.
| License | SPDX ID | SaaS | App Store | Embedded | For internal use | Remarks |
|---|---|---|---|---|---|---|
| GPL-2.0 | GPL-2.0-only | ⚠️ | ❌ | ❌ | ✅ | Full source disclosure upon distribution. SaaS is conditionally allowed as not for distribution |
| GPL-3.0 | GPL-3.0-only | ⚠️ | ❌ | ❌ | ✅ | GPL-2.0 + Addition of patent/tivoization provisions |
Rationale for allowing GPL conditionality in SaaS: SaaS does not “distribute” software to customers, so GPL source disclosure obligations do not directly arise. However, if you modify the GPL code used in the service, you must comply with the GPL conditions internally.
5. Network Copyleft License — No SaaS
The obligation to disclose source code arises simply by providing services through the network.
| License | SPDX ID | SaaS | App Store | Embedded | For internal use | Remarks |
|---|---|---|---|---|---|---|
| AGPL-3.0 | AGPL-3.0-only | ❌ | ❌ | ❌ | ⚠️ | Obligation to disclose source when providing SaaS. If there is a possibility of external exposure for internal use, review by person in charge |
| EUPL-1.2 | EUPL-1.2 | ⚠️ | ❌ | ❌ | ✅ | Includes network usage terms. Personnel review required when using SaaS |
6. Prohibited Use License
The license below is prohibited for use on all channels due to legal uncertainty or incompatibility.
| License | Reason for ban |
|---|---|
| SSPL-1.0 (Server Side Public License) | Licensed by MongoDB, non-OSI certified, full service disclosure obligation |
| BUSL (Business Source License) | There are restrictions on conversion to open source or commercial use after a certain period of time |
| Commons Clause Additional License | Violation of open source definition, prohibition of commercial sales |
| Proprietary / Unknown | Be sure to check with the person in charge before using any license-identified components. |
7. License compatibility precautions
License scan tool by package manager
| package manager | scan tool | Remarks |
|---|---|---|
| Maven (Java) | License Maven Plugin, FOSSA | pom.xml dependency analysis |
| Gradle (Java) | License Gradle Plugin | build.gradle dependency analysis |
| pip (Python) | pip-licenses, FOSSA | Analyze requirements.txt |
| npm/yarn (JS) | license-checker, FOSSA | package.json dependency analysis |
| Go mod | go-licenses | go.mod dependency analysis |
Prohibited combinations
| combination | Reason |
|---|---|
| GPL-2.0 + Apache-2.0 | GPL-2.0 and Apache-2.0 patent terms incompatibility |
| GPL-2.0 + GPL-3.0 | Version incompatibility (cannot be mixed with GPL-3.0 only license) |
| CDDL + GPL | License incompatibility (Mozilla official confirmation) |
8. Exception handling procedure
If you need to use an unwhitelisted or prohibited license:
- Submit written reason and scope of use to the open source manager
- Legal team legal review
- Joint approval by the person in charge and the legal team
- Record the approval history and decide whether to reflect the list in the next policy review.
9. Review history
| version | Review date | Major changes | Reviewer |
|---|---|---|---|
| 1.0 | 2026-03-23 | Originally written | DevOps Team Open Source Manager |