Establishment of open source policy:The first step to legal protection
1. What we do in this chapter
In this chapter, you will create a custom open source policy document for your company. An open source policy is not just an internal rulebook — it serves as a means of legal protection in the event of a licensing dispute or vulnerability incident, demonstrating that the company has systematically managed compliance. It becomes an official document that can be submitted immediately even when a supplier or partner company requests proof of an open source management system.
If you run agents/03-policy-generator, you will see your company's distribution method.,development language,Based on the answers to five questions, including delivery status, two outputs, output/policy/oss-policy.md and output/policy/license-allowlist.md, are automatically created.
2. Background knowledge
Why we need an open source policy
There are cases where open source license violations have led to actual legal disputes.
Artifex vs Hancom (2017) Hancom Office uses Ghostscript distributed under the GPL license.(PDF rendering engine)was used in the product without permission. Artifex Software filed a lawsuit in a California court in the United States.,In the first trial, the court ruled that the GPL license was legally binding as a contract. This case shows that open source license violations go beyond simple copyright issues and can result in liability for breach of contract.
Problems that arise in practice in the absence of policy
- License conflict:If GPL code is mixed into the Apache-2.0 project, full distribution may become impossible.
- Missing Notice: Apache-2.0,Permissive licenses such as MIT also require a NOTICE file or copyright notice.
- Neglecting vulnerabilities:Failure to track known CVEs in open source components leaves your products vulnerable to security vulnerabilities.
Having a written policy serves as a basis for proving “unintentional” in the event of a violation.,It is used as evidence that systematic procedures have been operated.
Policy prerequisites required by the standard
Acceptable ranges for both standards,Procedures for fulfilling license obligations,manager,Violation Processing Procedure,A common review cycle is required. ISO/IEC 18974 adds vulnerability response procedures,Security vulnerability Disclosure Policy,Program Performance Indicators(KPI)Additional requests are made. Additionally, for both standards, the mere existence of a policy document is not enough;,In fact, it requires employees to be accessible and aware of it.
Detailed descriptions of items to be included in the policy and example policy documents are available in KWG Open Source Guide — PolicySee .
ISO/IEC 18974 §4.1.4.2 — Program performance indicators
ISO/IEC 18974 requires that open source security assurance programs have **measurable performance indicators.(KPI)Requires that ** be included. You can meet this requirement by specifying the types of KPIs below in your policy document:
| KPI example | Measurement method |
|---|---|
| Critical vulnerability patch period after CVE detection | Discovery date ~ Patch distribution date(target:Within 1 week) |
| SBOM Renewal cycle compliance rate | SBOM Number of updates per release / Total number of releases |
| CVE regular scan cycle | Regular scans per release + once a month |
| vulnerability response rate | Over 90% resolved within deadline(Documentation of reasons and mitigation plan in case of non-resolution) |
| Education Completion Rate | 100% annual completion of open source-related occupations |
| Open source use approval processing period | Processing time for approval request(target:Within 3 business days) |
reference:The above deadline is the OpenChain KWG guide baseline. Depending on your organization's risk profile, more stringent deadlines, such as 24 hours for Critical or 1 week for High, can be applied as internal SLAs.
The oss-policy.md generated by the agent will contain the same KPI section as above.
AI Generated Code Policy
GitHub Copilot,When code generated by an AI coding tool such as ChatGPT is included in the product,Licensing obligations for open sources used as training data may apply. KWG The open source guide recommends explicitly reflecting this in the policy.
- The same review process as general open source applies to AI-generated code.
- source code scan tool(SCANOSS etc.)Snippet detection using is recommended.
- Terms and conditions for the AI tools you use(Copyright Attribution,License Terms)Confirmation required
The oss-policy.md generated by the agent contains the AI generated code policy section. If your organization does not use AI coding tools, it is also a good idea to specify “Not Applicable.”
policy dissemination(Policy Communication)
Both ISO/IEC 5230 and 18974 require that policies are communicated and understood by relevant personnel. Simply writing a document is not enough.
How to propagate policy:
- in-house wiki(Confluence,Notion, etc.)Post policy on
- 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.(Utilizing appointment-template.md)
This step is ISO/IEC 5230 3.1.1(Establishing and documenting open source policies)Meets your requirements.
Understand license classifications
Open source licenses are broadly classified into three categories depending on the strength of the obligations. The application criteria for each classification vary depending on the company's distribution method, so be sure to understand them before creating a policy.
| Category | Representative License | Features | Precautions for each distribution |
|---|---|---|---|
| Permissive | MIT, Apache-2.0,BSD | Few obligations,Free for commercial use | Safe in almost any deployment method |
| Weak Copyleft | LGPL,MPL | Obligation to disclose only the modified part | Dynamic linking is mostly safe |
| Strong Copyleft | GPL,AGPL | Possibility of full source disclosure obligation | SaaS is GPL safe,AGPL cautions |
Impact by distribution method
Distribution method is a key factor in determining whether licensing obligations arise.
- SaaS (Server provided):Running GPL code on a server does not constitute “distribution” and therefore does not give rise to GPL obligations. step,AGPL-3.0 imposes an obligation to disclose sources even when providing services through a network, so caution is required.
- App Store distribution(Mobile/Desktop):Since it is distributed to users in binary form, copyleft licensing obligations arise. Inclusion of GPL components may result in full source disclosure obligations.
- Embedded(Firmware/Hardware):This is the strictest case. Distribution of binaries gives rise to GPL obligations and,GPL compliance is more stringent for software included in hardware because it is difficult to reinstall after modification.
This step is ISO/IEC 5230 3.1.4(Program scope definition)Meets your requirements.
This exercise is done in the trustedoss project root. It assumes an environment in which Claude Code runs.
- Did you clone the trustedoss repository?
git clone https://github.com/trustedoss/trustedoss.github.io.git - Are you in the project root in the terminal?
cd trustedoss.github.io - Is Claude Code running?
claude
If everything is not checked → 1. Prepare the environmentGo through the chapters first.
3. Self-study
It interacts with the agent and creates policy documents. If you prepare answers to the five questions below in advance, the process will proceed quickly.
Advance preparation:Summary of answers to 5 questions
The process will proceed quickly if you briefly note the company's situation regarding the questions below before running the agent.
- Software Distribution Method:SaaS / App Store(Mobile/Desktop)/ embedded(Firmware/Hardware)/ Internal tools only / Complex(Duplicate selection possible)
- Major development languages and package managers:yes) Python + pip, JavaScript + npm,Java + Maven, etc.
- Open source project contribution plan:Do you plan to contribute code to external open source projects such as GitHub?
- Delivery to external customer/supplier:Do you deliver or sell products or software to external customers?
- Is there a current license review process:Is there currently a procedure for reviewing licenses when introducing open source?
Step-by-step practice
Step 1. Summary of company situation Write down the answers to the five questions above in advance.
Step 2. Run policy-generator agent
Terminate the current Claude session first(/exit or Ctrl+C)After doing it,Run the command below in a new terminal.
cd agents/03-policy-generator
claude
Step 3. When the Claude prompt opens, enter 시작.
Agent conversation example(Click to expand)
Below is an example of a conversation flow with an actual agent. When the user enters 시작, the process goes like this.
Agent guidance message:
hello! This is an agent that creates open source policy output. If you answer 5 questions, 2 policy documents will be automatically generated.
Question 1/5 — How will the software be distributed?(SaaS / App Store Distribution / Embedded / Internal Use / Complex)
Sample answer: SaaS
Question 2/5 — What development language and package manager do you mainly use?
Sample answer: Python + pip, JavaScript + npm
Question 3/5 — Do you plan to contribute to open source projects?
Sample answer:doesn't exist(Focus on internal service development)
Question 4/5 — Do you deliver software to external customers/suppliers?
Sample answer:doesn't exist(Operates only our own SaaS services)
Question 5/5 — Do you currently have a license review process in place?(Yes / No / Informally present)
`Sample answer:It exists unofficially.
Example of output upon completion of creation:
| file | Content |
|---|---|
output/policy/oss-policy.md | Open source policy document(purpose,applied area,Obligations) |
output/policy/license-allowlist.md | List of permitted licenses by distribution method |
Items that require manual entry:
- Contact person's actual name and email
- Policy enforcement date
- Confirm policy review cycle
Step 4. Answer agent questions in order The agent asks five questions one by one. We talk based on the answers we have prepared. If you are unsure about anything, you can ask your agent for guidance.
Step 5. Review oss-policy.md
open output/policy/oss-policy.md
- Check whether the company name and actual person in charge are reflected.
- Ensure that procedures for enforcing licensing obligations are included for your deployment method.
- Policy Review Cycle(yes:Once a year)Check if it is specified
Step 6. Review and edit license-allowlist.md
open output/policy/license-allowlist.md
- Ensure that the appropriate classification is applied for our deployment method
- Verify that the license you are actually using is included in the list
- Add items or modify conditions as needed
Step 7. Check completion confirmation checklist Check the checklist item by item in section 5 below.
This step is ISO/IEC 5230 3.5.1(Establishing an open source contribution policy)Meets your requirements.
When the practice is completed successfully The files below are created.
Created file:
output/policy/oss-policy.mdoutput/policy/license-allowlist.md
Items that must be included in the file:
- Acceptable scope and restrictions on open source use
- Procedures for fulfilling license obligations
- Person in charge and contact information
- Procedures for handling policy violations
- Policy Review Cycle
- Known vulnerability Response Procedures(18974 Requirements)
Open the created file and check if it contains the above items. Check it yourself and supplement if necessary.
Completing this lab will meet the requirements below:
ISO/IEC 5230
| Item ID | Requirements | 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 | Requirements | Self-certification checklist |
|---|---|---|
| 4.1.1 | Documenting 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 Confirmation Checklist
These are items that must be checked directly by a person after running the agent. You must pass all checklists 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 actual person in charge are reflected in the policy.
- License classification and obligations appropriate for our distribution method are applied.
- Open source contribution policy is included(If you have a contribution plan)
- Includes vulnerability response procedures(ISO/IEC 18974 requirements)
- Policy review cycle is specified(yes:Once a year)
Example table of contents of 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 example
Compare the generated allowed license list to the sample below to ensure it is correctly categorized by deployment 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 of output: Policy Output Best PracticeYou can check the actual format of the generated file at .
5. Next steps
Once you have completed this chapter, move on to the process design phase. The open source process is the step of materializing the procedures defined in the policy into actual work flow.
Terminate the current Claude session first(/exit or Ctrl+C)After doing it,Run the command below in a new terminal.
cd agents/04-process-designer
claude
or open source process:From use to distributionGo to and read the chapter document to proceed.
This step is ISO/IEC 5230 3.1.1, 3.1.4,Meets 3.5.1 and ISO/IEC 18974 4.1.1 requirements.