Establishing an open source policy: The first step to legal protection
1. What we do in this chapter
In this chapter, you will create an open source policy document tailored to your company. An open source policy is not just an internal rulebook — it serves as a means of legal protection in a licensing dispute or vulnerability incident, demonstrating that the company has managed compliance systematically. It becomes an official document you can submit immediately when a customer or partner requests proof of an open source management system.
When you run agents/03-policy-generator, it asks five questions — including your distribution method, development languages, and delivery situation — and based on your answers automatically generates two outputs: output/policy/oss-policy.md and output/policy/license-allowlist.md.
2. Background knowledge
Why you need an open source policy
There are cases where open source license violations have led to real legal disputes.
Artifex vs. Hancom (2017) Hancom Office used Ghostscript (a PDF rendering engine) distributed under the GPL license in its product without permission. Artifex Software filed suit in a California court, and in the first trial the court ruled that the GPL license was legally binding as a contract. This case shows that an open source license violation goes beyond a simple copyright issue and can result in liability for breach of contract.
Problems that arise in practice without a policy
- License conflict: If GPL code is mixed into an Apache-2.0 project, full distribution may become impossible.
- Missing notice: Permissive licenses such as Apache-2.0 and MIT also require a NOTICE file or a copyright notice.
- Neglected vulnerabilities: Failing to track known CVEs in open source components leaves your products exposed to security vulnerabilities.
Having a written policy provides a basis for proving that a violation was "unintentional," and it serves as evidence that you have operated systematic procedures.
Policy prerequisites required by the standard
Both standards require a common set of items: the acceptable scope of use, procedures for fulfilling license obligations, the person in charge, a violation-handling procedure, and a review cycle. ISO/IEC 18974 additionally requires vulnerability response procedures, a security vulnerability disclosure policy, and program performance indicators (KPIs). For both standards, the mere existence of a policy document is not enough; employees must actually be able to access it and be aware of it.
Detailed descriptions of the items a policy should include, along with an example policy document, are available in the KWG Open Source Guide — Policy.
ISO/IEC 18974 §4.1.4.2 — Program performance indicators
ISO/IEC 18974 requires that an open source security assurance program include measurable performance indicators (KPIs). You can meet this requirement by specifying the KPI types below in your policy document:
| KPI example | Measurement method |
|---|---|
| Critical vulnerability patch time after CVE detection | Detection date to patch release date (target: within 1 week) |
| SBOM update cycle compliance rate | Number of SBOM updates per release / total number of releases |
| CVE periodic scan cycle | Per-release scan plus once a month |
| Vulnerability response rate | Over 90% resolved within the deadline (document the reason and a mitigation plan if unresolved) |
| Training completion rate | 100% annual completion for open-source-related roles |
| Open source usage approval turnaround time | Processing time for an approval request (target: within 3 business days) |
Note: The deadlines above are the OpenChain KWG guide baseline. Depending on your organization's risk profile, you can apply stricter deadlines as internal SLAs — for example, 24 hours for Critical or 1 week for High.
The oss-policy.md generated by the agent will contain the same KPI section as above.
AI-generated code policy
When code generated by an AI coding tool such as GitHub Copilot or ChatGPT is included in a product, license obligations for the open source used as training data may apply. The KWG Open Source Guide recommends reflecting this explicitly in your policy.
- The same review process used for general open source applies to AI-generated code.
- Snippet detection using a source code scanning tool (SCANOSS, etc.) is recommended.
- Confirm the terms and conditions of the AI tools you use (copyright attribution, license terms).
The oss-policy.md generated by the agent contains an AI-generated code policy section. If your organization does not use AI coding tools, it is fine to mark this "Not Applicable."
Policy communication
Both ISO/IEC 5230 and 18974 require that policies are communicated to and understood by the relevant personnel. Simply writing a document is not enough.
How to communicate the policy:
- Post the policy on an internal wiki (Confluence, Notion, etc.).
- Include policy links in onboarding training materials.
- Share policy changes with all developers once a year.
- Include a policy acknowledgment signature line on the appointment letter (using appointment-template.md).
This step meets the ISO/IEC 5230 3.1.1 (establishing and documenting an open source policy) requirement.
Understand license classifications
Open source licenses are classified by the strength of their obligations into Permissive, Weak Copyleft, Strong Copyleft, and Network Copyleft. For the same code, whether an obligation arises depends on the company's distribution method (SaaS / App Store / Embedded), so be sure to understand this before writing your policy.
Representative licenses per category, core obligations, impact by distribution method, and the distribution-channel allow matrix are consolidated in License classification. The policy-generator agent turns this into an allow list tailored to your distribution method.
This step satisfies ISO/IEC 5230 3.1.4 (program scope definition).
This exercise is done in the trustedoss project root. It assumes an environment where Claude Code is running.
- Did you clone the trustedoss repository?
git clone https://github.com/trustedoss/trustedoss.github.io.git - Are you in the project root in your terminal?
cd trustedoss.github.io - Is Claude Code running?
claude
If any of these are not checked, → go through the 1. Environment setup chapter first.
3. Self-study
You interact with the agent and create the policy documents. If you prepare answers to the five questions below in advance, the process will move quickly.
Preparation: answers to the 5 questions
The process moves quickly if you jot down your company's situation for the questions below before running the agent.
- Software distribution method: SaaS / App Store (mobile/desktop) / Embedded (firmware/hardware) / Internal tools only / Mixed (multiple choices allowed)
- Main development languages and package managers: e.g., Python + pip, JavaScript + npm, Java + Maven, etc.
- Open source contribution plans: Do you plan to contribute code to external open source projects such as those on GitHub?
- Delivery to external customers/suppliers: Do you deliver or sell products or software to external customers?
- Existing license review process: Do you currently have a procedure for reviewing licenses when adopting open source?
Step-by-step exercise
Step 1. Summarize your company's situation Write down your answers to the five questions above in advance.
Step 2. Run the policy-generator agent
First terminate the current Claude session (/exit or Ctrl+C), then run the command below in a new terminal.
cd agents/03-policy-generator
claude
Step 3. When the Claude prompt opens, enter 시작 ("start").
Agent conversation example (click to expand)
Below is an example of a conversation flow with the actual agent. When the user enters 시작, it proceeds like this.
Agent guidance message:
Hello! This is the agent that creates the open source policy deliverables. Answer 5 questions and 2 policy documents will be generated automatically.
Question 1/5 — How will the software be distributed? (SaaS / App Store distribution / Embedded / Internal use / Mixed)
Sample answer: SaaS
Question 2/5 — What development languages and package managers do you mainly use?
Sample answer: Python + pip, JavaScript + npm
Question 3/5 — Do you plan to contribute to open source projects?
Sample answer: No (focused on internal service development)
Question 4/5 — Do you deliver software to external customers/suppliers?
Sample answer: No (we operate only our own SaaS service)
Question 5/5 — Do you currently have a license review process in place? (Yes / No / Informally)
Sample answer: Informally
Example output on completion:
| File | Content |
|---|---|
output/policy/oss-policy.md | Open source policy document (purpose, scope, obligations) |
output/policy/license-allowlist.md | List of permitted licenses by distribution method |
Items you must fill in manually:
- The contact person's actual name and email
- The policy's effective date
- Confirm the policy review cycle
Step 4. Answer the agent's questions in order The agent asks the five questions one at a time. Respond based on the answers you prepared. If you are unsure about anything, you can ask the agent for guidance.
Step 5. Review oss-policy.md
open output/policy/oss-policy.md
- Check that the company name and the actual person in charge are reflected.
- Ensure that procedures for fulfilling license obligations are included for your distribution method.
- Check that the policy review cycle (e.g., once a year) is specified.
Step 6. Review and edit license-allowlist.md
open output/policy/license-allowlist.md
- Ensure the appropriate classification is applied for your distribution method.
- Verify that the licenses you actually use are included in the list.
- Add items or adjust conditions as needed.
Step 7. Go through the completion checklist Check the checklist item by item in section 5 below.
This step meets the ISO/IEC 5230 3.5.1 (establishing an open source contribution policy) requirement.
When the exercise completes successfully, the files below are created.
Created files:
output/policy/oss-policy.mdoutput/policy/license-allowlist.md
Items the files must include:
- The acceptable scope of, and restrictions on, open source use
- Procedures for fulfilling license obligations
- The person in charge and contact details
- Procedures for handling policy violations
- The policy review cycle
- Known-vulnerability response procedures (18974 requirement)
Open the created files and check that they contain the items above. Verify them yourself and supplement as needed.
Completing this exercise meets the requirements below:
ISO/IEC 5230
| Item ID | Requirement | Self-certification checklist |
|---|---|---|
| 3.1.1 | Open source policy documentation | Do you have a documented open source policy? |
| 3.1.4 | Program scope definition | Is the scope of your open source program documented? |
| 3.5.1 | Open source community participation policy | Do you have a policy for open source community participation? |
| 3.5.1 | Open source contribution process | Do you have a process for contributing to open source projects? |
ISO/IEC 18974
| Item ID | Requirement | Self-certification checklist |
|---|---|---|
| 4.1.1 | Documenting a security assurance policy | Do you have a documented open source security assurance policy? |
| 4.1.4 | Security program scope definition | Is the scope of your open source security assurance program documented? |
4. Completion checklist
These are items a person must check directly after running the agent. You must pass the entire checklist to complete this chapter.
Confirm file creation
-
output/policy/oss-policy.mdfile exists -
output/policy/license-allowlist.mdfile exists
Check policy details
- The company name and the actual person in charge are reflected in the policy.
- The license classifications and obligations appropriate for your distribution method are applied.
- The open source contribution policy is included (if you have a contribution plan).
- Vulnerability response procedures are included (ISO/IEC 18974 requirement).
- The policy review cycle is specified (e.g., once a year).
Example table of contents for the main sections of oss-policy.md
Ensure that the generated policy document contains the sections below.
1. Purpose and scope
2. Policy owner and responsibilities
3. Open source usage approval criteria
4. License obligation compliance procedure
5. Open source contribution policy
6. Security vulnerability response procedure
7. Policy violation handling
8. Policy review and revision
license-allowlist.md sample table
Compare the generated allowed-license list against the sample below to confirm it is correctly categorized by distribution method.
| License | Category | Internal Use | SaaS Distribution | App distribution | Embedded |
| ---------- | --------------- | ------------ | ----------------- | ----------------- | ----------------- |
| MIT | Permissive | ✓ Allowed | ✓ Allowed | ✓ Allowed | ✓ Allowed |
| Apache-2.0 | Permissive | ✓ Allowed | ✓ Allowed | ✓ Allowed | ✓ Allowed |
| LGPL-2.1 | Weak Copyleft | ✓ Allowed | ✓ Allowed | △ Conditional | △ Conditional |
| GPL-2.0 | Strong Copyleft | ✓ Allowed | ✓ Allowed | ✗ Review required | ✗ Review required |
| AGPL-3.0 | Strong Copyleft | ✓ Allowed | ✗ Review required | ✗ Review required | ✗ Review required |
📋 Example output: See the actual format of the generated files in Policy output best practices.
5. Next steps
Once you have completed this chapter, move on to the process design phase. The open source process is the step where you turn the procedures defined in the policy into an actual workflow.
First terminate the current Claude session (/exit or Ctrl+C), then run the command below in a new terminal.
cd agents/04-process-designer
claude
Or go to Open source process: From use to distribution and read the chapter to proceed.
This step meets the ISO/IEC 5230 3.1.1, 3.1.4, and 3.5.1, and ISO/IEC 18974 4.1.1 requirements.