ISO/IEC 5230 Conformance Guide

• 1: §3.1 Program Foundation
• 1.1: §3.1.1 Policy
• 1.2: §3.1.2 Competence
• 1.3: §3.1.3 Awareness
• 1.4: §3.1.4 Program Scope
• 1.5: §3.1.5 License Obligations
• 2: §3.2 Relevant Tasks
• 2.1: §3.2.1 External Inquiry Response
• 2.2: §3.2.2 Effective Resources
• 3: §3.3 Content Review and Approval
• 3.1: §3.3.1 SBOM
• 3.2: §3.3.2 License Compliance
• 4: §3.4 Compliance Artifacts
• 4.1: §3.4.1 Artifacts
• 5: §3.5 Community Engagement
• 5.1: §3.5.1 Contributions
• 6: §3.6 Adherence to the Specification
• 6.1: §3.6.1 Conformance
• 6.2: §3.6.2 Duration

1 - §3.1 Program Foundation

1.1 - §3.1.1 Policy

1. Clause Overview

A company without an Open Source Policy risks distributing software while developers are unaware of their open source license obligations. This can lead to serious legal and business risks, such as copyright infringement lawsuits, mandatory source code disclosure, and termination of business contracts. §3.1.1 requires organizations to establish a documented policy governing open source license compliance for supplied software and to communicate it so that all Program Participants within the organization are aware of the policy’s existence. This clause forms the foundation of the entire ISO/IEC 5230 program; all subsequent clauses (competence, processes, artifacts, etc.) operate on top of this policy.

2. What to Do

• Write and formalize a policy document governing open source license compliance.
• Clearly define the scope of the policy (supplied software, contribution activities, internal releases, etc.).
• Include principles for open source use, contribution, distribution, SBOM management, and security vulnerability response in the policy.
• Establish and document a procedure for communicating the policy to Program Participants (developers, legal, IT, security, etc.).
• Retain records (training completion records, notification history, etc.) that demonstrate the communication took place.
• Include a procedure in the policy for periodically reviewing it and re-communicating it upon changes.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.1.1 Documented Open Source Policy

How to Comply

An Open Source Policy is an official document containing the principles and procedures for a company to use open source software safely and effectively. The policy document must include key items such as purpose, scope, roles and responsibilities, principles for open source use, contribution, and distribution, SBOM management, security vulnerability response, and training and review cycles. Since this document itself constitutes Verification Material 3.1.1.1, it must be managed as an official document with version and approval history recorded.

When establishing the policy, the company’s business environment and software supply chain characteristics must be reflected. For example, product companies and service companies that distribute software externally may differ in the scope of their obligation to generate Compliance Artifacts, so the scope must be clearly defined. The policy should go through a review by the legal team or OSRB (Open Source Review Board) and be approved by senior management or an authorized department head.

A policy is not a document that is established once and left alone. It should be reviewed at least once a year to reflect changes in ISO/IEC 5230 requirements, the emergence of new license types, and legal environment changes, with the change history recorded in the document.

Considerations

• Items to include: Include all of the following in the policy: open source use, external contributions, internal project releases, SBOM management, and security vulnerability response principles.
• Scope definition: Clearly distinguish the scope to which the policy applies, such as externally distributed software, internally used software, and contribution activities.
• Approval process: Final approval by OSRB or the head of the legal team or above, with the approval date and approver recorded in the document.
• Version control: Maintain document version numbers and change history so that previous versions can be compared during audits.
• Periodic review: Review the policy at least once a year, recording the completion date and reviewer.

Sample

The following is a sample of the Purpose and Scope section of an Open Source Policy document. This text itself becomes a key component of Verification Material 3.1.1.1 (documented open source policy).

## 1. Purpose and Scope

### 1.1 Purpose

This policy provides the principles and procedures for the company to use open source software
safely and effectively. The main purposes of the policy are as follows:

1. Open Source License Compliance:
   Comply with the license obligations of open source components included in supplied software
   and meet related legal requirements.
2. Open Source Security Assurance:
   Identify security vulnerabilities in open source components included in supplied software and
   minimize security risks through appropriate response measures.

These principles are designed to meet the requirements of ISO/IEC 5230 (Open Source License Compliance)
and ISO/IEC 18974 (Open Source Security Assurance).

### 1.4 Scope

This policy applies to all software projects developed, distributed, or used by the company.

- All supplied software provided or distributed externally.
- Activities contributing to external open source projects.
- Activities releasing internal projects as open source.

However, open source used solely for internal purposes may have the applicability of this policy
determined through a separate review procedure.

The scope of the policy is periodically reviewed and updated in accordance with changes in the
company's business environment.

3.1.1.2 Documented Procedure for Policy Awareness

How to Comply

Writing a policy document alone is not sufficient. A procedure for communicating the policy must be established and documented so that Program Participants (all employees involved in developing, distributing, or contributing to software) can actually become aware of the policy’s existence. The communication procedure document must specifically state through which channels, when, and to whom the policy is communicated. This communication procedure document itself is Verification Material 3.1.1.2.

It is effective to combine multiple channels for communication. For new employees, include an open source policy briefing in the onboarding process. For existing employees, use internal wiki posts and email announcements. The procedure should also include a step for immediately notifying changes when the policy is updated. To prove that communication took place, retain evidence such as notification sending history, training completion records, and policy acknowledgment signatures for at least 3 years.

Considerations

• Use multiple channels: Use two or more channels such as internal wiki, email announcements, and onboarding training to increase the effectiveness of communication.
• New hires: Include an open source policy briefing as a mandatory item in the onboarding process.
• Policy updates: Establish a separate procedure for immediately notifying Program Participants of changes when the policy is updated.
• Evidence retention: Retain notification history, training completion certificates, and policy acknowledgment signatures for at least 3 years.
• Accessibility: Post the policy document on the internal portal or wiki at all times so that participants can check it at any time.

Sample

The following is a sample policy communication notification email. Retaining the sending history can serve as evidence for Verification Material 3.1.1.2.

Subject: [Open Source] Open Source Policy Notice and Acknowledgment Request

To: All development/distribution-related employees
From: Open Source Program Manager

Hello,

The company's open source policy has been established (or revised).
All employees involved in using, contributing to, or distributing open source software are
requested to review and familiarize themselves with the policy document at the link below.

- Policy document: [Internal portal link]
- Key contents: Open source use principles, license compliance procedures,
               SBOM management, security vulnerability response principles
- Policy version: v1.0 (Effective date: YYYY-MM-DD)

For inquiries about the policy content, please contact the Open Source Program Manager
(oss@company.com).

Thank you.
Open Source Program Manager

5. References

• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template

1.2 - §3.1.2 Competence

1. Clause Overview

For an open source program to actually function, the people assigned to relevant roles must have the competence to perform those roles. If roles and responsibilities are only written in documents and the people responsible have no basic knowledge of open source license or security vulnerability management, the policies and processes will be nominal. §3.1.2 requires the organization to identify the roles involved in the program, define the competence required for each role, evaluate and record whether participants actually possess that competence. This clause advances the role structure defined in §3.1.1 Policy into a concrete competence framework.

2. What to Do

• Create a list of roles that affect the performance of the open source program and the responsibilities of each role.
• Specifically define and document the competence (knowledge, skills, experience) required to perform each role.
• Evaluate whether each Program Participant has the competence required for their role.
• Where competence is insufficient, take measures such as training, mentoring, etc. to acquire the necessary competence.
• Document and retain competence assessment results and subsequent action history.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.2.1 Documented List of Roles and Responsibilities

How to Comply

A document listing all roles involved in the program and clearly defining the responsibilities of each role must be created. Generally, the Open Source Program Manager, legal counsel, IT staff, security staff, developer culture staff, and business units are the key roles. Depending on the company size or organizational structure, it is also possible to have people hold multiple roles concurrently or operate as a virtual organization in the form of an OSRB (Open Source Review Board).

When defining roles, listing specific responsibility items rather than abstract descriptions is more advantageous for proving during audits. For example, instead of “open source management,” describe it clearly as “oversight of license review and SBOM generation for open source components used in supplied software.” This document can be included in the Open Source Policy document (§3.1.1.1) under the roles and responsibilities section, or managed as a separate appendix.

Considerations

• Role identification scope: Include roles from all organizations involved in the software supply chain, such as development, legal, IT, security, and procurement, and also review outsourced development and vendor management roles.
• Responsibility specificity: Describe responsibilities for each role in terms of specific activities, not abstract descriptions.
• Concurrent roles: When one person holds multiple roles concurrently, clearly note this in the document.
• Update cycle: Immediately update the document and version when organizational changes or personnel transfers occur.

Sample

The following is a sample roles and responsibilities list from an Open Source Policy Appendix. The full form can be found in Open Source Policy Template Appendix 1.

| Role | Responsibilities |
|------|-----------------|
| Open Source Program Manager | Overall management of the company's open source program / SBOM generation oversight /
                                External inquiry response / Internal best practice management |
| Legal Counsel | Interpretation and review of open source license obligations /
                 License compatibility review / Legal risk assessment and advisory |
| IT Staff | Operation of open source analysis tools and CI/CD pipeline integration /
             Support for SBOM generation automation |
| Security Staff | Response to known and newly discovered vulnerabilities /
                  DevSecOps environment integration and security measures |
| Developer Culture Staff | Encouraging open source community participation / Training program operation |
| Business Unit | Compliance with open source policy and processes / Open source identification and reporting |

3.1.2.2 Document Identifying Competencies for Each Role

How to Comply

The knowledge, skills, and experience required to perform each role must be specifically defined and documented. The competence definition should be written to a level where a person newly assigned to that role can clearly understand “what I need to know.” Instead of writing vaguely like “open source knowledge required,” describe it specifically, such as “understanding of the obligations and compatibility of major open source licenses (MIT, Apache-2.0, GPL-2.0, etc.).”

Breaking down competence levels into categories like “basic understanding,” “practical application,” and “expert” makes the evaluation criteria clearer and makes it easier to establish training plans. This document can be included in the Open Source Policy document or managed as a separate competence definition document, and should be reviewed periodically to reflect changes in the technical environment.

Considerations

• Specificity: Describe competence items at a measurable level so they can be used as evaluation criteria.
• Competence level distinction: Defining levels such as “Basic Understanding / Practical Application / Expert” facilitates evaluation and training design.
• Update cycle: Update competence items when new tools, licenses, or security technologies emerge.
• Training linkage: Design role-specific training curricula based on the defined competencies.

Sample

The following is a sample competence definition table by role.

| Role | Required Competence |
|------|---------------------|
| Open Source Program Manager | Understanding of major open source license obligations and compatibility /
                                Understanding of software development processes /
                                SBOM generation and management knowledge / Communication skills |
| Legal Counsel | Specialized knowledge of software copyright law /
                 Ability to interpret open source licenses / Legal risk assessment ability |
| IT Staff | Operation of open source analysis tools (FOSSology, ORT, Syft, etc.) /
             Understanding of CI/CD pipelines / IT infrastructure expertise |
| Security Staff | Understanding of DevSecOps / Operation of vulnerability analysis tools /
                  CVSS score interpretation and risk assessment ability |
| Developer Culture Staff | Understanding of open source policy / Training design ability /
                           Open source community participation experience |
| Business Unit | Basic knowledge of open source compliance /
                 Basic understanding of open source licenses / Understanding of open source policy |

3.1.2.3 Documented Evidence of Assessed Competence

How to Comply

Each Program Participant must be evaluated to confirm they actually possess the defined competencies, and the results must be documented and retained. Evaluation methods can combine a variety of approaches such as online training completion confirmation, verification of certification possession, written or practical exams, review of job performance records, and interviews. The important thing is that the evaluation results must remain as records. These records themselves are Verification Material 3.1.2.3.

If insufficient competence is found from evaluation results, take remedial measures such as training, external consulting, or mentoring, and retain completion records as well. Evaluations should be conducted regularly at least once a year, and new assignees should be immediately evaluated upon role assignment. Evaluation records should be stored in the internal Learning Management System (LMS) or document system and maintained in a state where they can be submitted immediately during audits.

Considerations

• Diverse evaluation methods: Comprehensively evaluate competence by combining multiple methods such as online training completion, exams, and on-the-job performance.
• Regular evaluation cycle: Conduct at least once a year, and immediately perform a new evaluation when an assignee changes.
• Remediation of insufficient competence: Establish a training plan for items found insufficient in evaluation results, and conduct re-evaluation after completion.
• Record retention period: Retain evaluation records at least for the duration of the assignee’s tenure, and maintain them for a certain period after departure for audit purposes.

Sample

The following is a sample competence evaluation record form. It is written by role and stored in the LMS or document system.

| Name | Role | Evaluation Item | Evaluation Method | Result | Evaluation Date | Notes |
|------|------|-----------------|-------------------|--------|-----------------|-------|
| Gil-dong Hong | Open Source Program Manager | Understanding of license obligations | Online training completion | Completed (95 points) | 2026-01-15 | - |
| Gil-dong Hong | Open Source Program Manager | SBOM management knowledge | Practical evaluation | Completed | 2026-01-15 | - |
| Chul-su Kim | Security Staff | Understanding of DevSecOps | External training completion | Completed | 2026-02-03 | Certificate retained |
| Young-hee Lee | Legal Counsel | Open source license interpretation | Interview evaluation | Completed | 2026-01-20 | - |

5. References

• Related guide: Enterprise Open Source Management Guide — 1. Organization
• Related template: Open Source Policy Template — Appendix 1. Personnel Status

1.3 - §3.1.3 Awareness

1. Clause Overview

Even participants with the right roles and competencies will only participate in a perfunctory manner if they do not understand the purpose of the open source program and the meaning of their own contribution to the overall compliance framework. §3.1.3 requires the organization to evaluate and record that Program Participants actually understand the program’s objectives, how they contribute, and the consequences of failing to follow the program’s requirements. This clause is the next step after §3.1.2 Competence (possessing knowledge and skills), forming the practical motivation by connecting the competence participants hold to the program’s purpose.

2. What to Do

• Verify that Program Participants understand the objectives of the open source program (license compliance, Security Assurance, etc.).
• Evaluate whether each participant is aware of how their role contributes to the overall program operation.
• Verify that participants are aware of the legal and business impacts that may arise from failing to comply with the program’s requirements.
• Conduct awareness assessments periodically and document and retain the results.
• For participants with insufficient awareness, provide additional training and retain re-evaluation results.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.3.1 Documented Evidence of Assessed Awareness

How to Comply

Program Participants must be evaluated on three key areas of awareness, and the results must be recorded. The three key areas are: (1) the program’s objectives (open source license compliance and Security Assurance), (2) how one’s role contributes to the program, and (3) the legal and business impacts of not following the program.

Evaluation methods can be combined in various ways such as online quizzes, offline surveys, training completion confirmation, and interviews. The important thing is that the evaluation results must remain as documents. These records are Verification Material 3.1.3.1. Evaluations should be conducted regularly at least once a year, and new participants should be immediately evaluated when they join the program. For participants with insufficient awareness, provide additional training and retain re-evaluation results together.

Considerations

• Evaluation scope: Design evaluation questions that cover all three key areas of awareness (objectives, contributions, implications).
• Evaluation cycle: Conduct a regular evaluation at least once a year, and new participants should be evaluated immediately upon joining.
• Evidence format: Retain in a format that can be submitted during audits, such as quiz results, signed policy acknowledgment forms, and training completion certificates.
• Measures for insufficient participants: Provide additional training for participants with insufficient evaluation results and retain re-evaluation records.
• Accessibility: Keep policy documents and training materials used for evaluation always accessible on the internal portal.

Sample

The following is a sample participant awareness assessment record form. It is written at the time of training completion and stored in the LMS or document system.

| Name | Role | Evaluation Item | Evaluation Method | Result | Evaluation Date | Notes |
|------|------|-----------------|-------------------|--------|-----------------|-------|
| Gil-dong Hong | Open Source Program Manager | Understanding of program objectives | Online quiz | Completed (90 points) | 2026-01-15 | - |
| Gil-dong Hong | Open Source Program Manager | Awareness of non-compliance implications | Online quiz | Completed (90 points) | 2026-01-15 | - |
| Chul-su Kim | Developer | Understanding of program objectives | Online quiz | Completed (85 points) | 2026-01-20 | - |
| Young-hee Lee | Security Staff | Awareness of contribution method | Interview | Completed | 2026-01-22 | Interview record retained |

The following is a sample policy acknowledgment form. Obtaining a signature after training completion can serve as Verification Material.

[Open Source Policy Acknowledgment Form]

I confirm that I have reviewed and understood the following:

1. The existence of the company's open source policy and the location of the document
2. The objectives of the open source license compliance and Security Assurance program
3. How my role contributes to the operation of the open source program
4. The legal and business risks that may arise from failing to comply with open source
   policies and processes

Name: ________________  Role: ________________
Signature: ____________  Date: ________________

5. References

• Related guide: Enterprise Open Source Management Guide — 5. Training
• Related template: Open Source Policy Template — §6 Training and Awareness

1.4 - §3.1.4 Program Scope

1. Clause Overview

If it is unclear whether the open source program applies to the entire organization or only to specific product lines or business units, the boundaries of compliance activities become vague and accountability becomes unclear. §3.1.4 requires a documented written statement that clearly defines which software, organizational units, and distribution channels the open source program applies to, and what is outside the scope. The scope may vary depending on the organization’s size and business model, and this clause requires that choice to be explicitly recorded.

2. What to Do

• Determine the types of software the open source program applies to (externally distributed products, services, internal systems, etc.).
• Define the organizational scope the program applies to (company-wide, specific business unit, specific product line, etc.).
• If there are items explicitly excluded from the scope, record them together with the rationale.
• Document the scope statement and officially manage it as an open source policy or separate document.
• Re-examine and update the scope when the business environment changes (entry into new businesses, mergers and acquisitions, etc.).

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.4.1 Written Statement of Program Scope

How to Comply

A document must be written that clearly describes where the program applies and where it does not. This statement can be included in the scope section of the Open Source Policy document (§3.1.1.1) or managed as a separate document. The key point is that the boundaries must be clear. For example, it can be stated clearly as “all software products distributed externally,” or the scope can be specifically limited such as “limited to embedded software developed by business unit A.”

When determining the scope, comprehensively consider the software distribution format (binary products, SaaS, internal tools), how open source is used (direct use, indirect dependencies), and external contribution activities. It is also advisable to clearly state the handling policy for software used only internally. The scope statement must be periodically reviewed and versioned in response to business environment changes.

Considerations

• Distribution format distinction: Specify the applicability for each software distribution type such as externally distributed products, SaaS services, and internal systems.
• Organizational scope: Clearly state whether it applies company-wide or only to specific business units or product lines.
• Exception recording: If there are items excluded from the scope, record them in the document together with the reason for exclusion.
• Update cycle: Immediately re-examine and update the version when entering new businesses, undergoing mergers and acquisitions, or changing the product portfolio.
• Policy alignment: The scope statement should be consistent with the open source policy §1.4 scope section.

Sample

The following is a sample scope statement within an open source policy. This text itself constitutes Verification Material 3.1.4.1.

## Program Scope

This open source program applies to the following scope:

**Applicable**
- All software products externally distributed or sold by the company (including embedded software)
- Activities contributing to external open source projects
- Activities releasing internal projects as open source

**Excluded**
- Software used internally only and not distributed externally (however, a separate review procedure
  may be applied)
- Commercial software procured from third parties (however, review for open source inclusion is required)

**Organizational Scope**
This program applies to all business units of [Company Name], and subsidiaries and affiliates
determine applicability through separate consultation.

This scope is reviewed at least once a year in accordance with business environment changes,
and the Open Source Program Manager publishes the revised version when changes occur.

5. References

• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template — §1.4 Scope

1.5 - §3.1.5 License Obligations

1. Clause Overview

The most critical task when including open source components in software is accurately understanding the obligations, restrictions, and rights imposed by the licenses applied to those components. Distributing without reviewing license obligations can result in serious legal risks such as mandatory source code disclosure, missing copyright notices, and patent clause violations. §3.1.5 requires the establishment of a procedure for reviewing all identified licenses to determine their obligations, restrictions, and rights, and for recording the results. This procedure forms the foundation of the §3.3.2 License Compliance process.

2. What to Do

• Identify and list the licenses of open source components used in the software.
• Review the obligations (notice obligations, source code disclosure obligations, etc.), restrictions (commercial use restrictions, patent use restrictions, etc.), and rights (use, modification, and redistribution rights, etc.) imposed by each license.
• Document review results by license and maintain records.
• Establish a procedure for requesting legal review when there is uncertainty in license interpretation.
• Update the procedure when new licenses emerge or existing license interpretations change.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.5.1 License Obligation Review Procedure

How to Comply

A procedure for reviewing and recording the obligations, restrictions, and rights of each open source license must be documented. The procedure must include the following steps: (1) license identification, (2) obligation, restriction, and rights analysis, (3) recording review results, (4) requesting legal review for uncertain items, and (5) record retention. This procedure document itself is Verification Material 3.1.5.1.

License obligations by license can be efficiently managed by utilizing pre-compiled license databases (SPDX License List, etc.). It is practically effective to prepare an obligation summary table in advance for major licenses (MIT, Apache-2.0, GPL-2.0, GPL-3.0, LGPL-2.1, AGPL-3.0, etc.) and to immediately conduct additional review when new licenses are discovered. The criteria for escalating to the legal team in the case of complex license combinations or situations requiring legal judgment should also be specified in the procedure.

Considerations

• SPDX utilization: Using the SPDX License List as a reference license list standardizes identification and classification.
• Obligation type distinction: Record obligations by type, such as notice obligations, source code disclosure obligations, patent clauses, and trademark restrictions.
• Review by distribution format: Review by distribution format, as license obligations may differ depending on the distribution format such as binary distribution, SaaS, and internal use.
• Escalation criteria: Specify in the procedure the situations requiring legal review (license conflicts, non-standard licenses, commercial restriction clauses, etc.).
• Update cycle: Immediately update the procedure and records when new licenses are adopted or existing license interpretations change.

Sample

The following is a sample obligation summary table for major open source licenses. Writing and retaining it as part of the license review procedure can serve as Verification Material.

| License | Notice Obligation | Source Code Disclosure | Same License for Modifications | Patent Clause | Commercial Use |
|---------|-------------------|----------------------|-------------------------------|---------------|----------------|
| MIT | Yes | No | No | No | Yes |
| Apache-2.0 | Yes | No | No | Yes (patent grant) | Yes |
| GPL-2.0 | Yes | Yes (upon distribution) | Yes | No | Yes |
| GPL-3.0 | Yes | Yes (upon distribution) | Yes | Yes (patent grant) | Yes |
| LGPL-2.1 | Yes | Yes (library) | Yes (library) | No | Yes |
| AGPL-3.0 | Yes | Yes (including network) | Yes | Yes (patent grant) | Yes |
| MPL-2.0 | Yes | Yes (file-level) | Yes (file-level) | Yes (patent grant) | Yes |
| BSD-2-Clause | Yes | No | No | No | Yes |
| BSD-3-Clause | Yes | No | No | No | Yes |

The following is a sample outline of a license obligation review procedure.

[License Obligation Review Procedure]

1. License Identification
   - Identify open source components and licenses through SBOM generation tools
     (FOSSology, ORT, etc.).

2. Obligation, Restriction, and Rights Analysis
   - Refer to the pre-compiled license obligation summary table to confirm the
     obligations, restrictions, and rights of the applicable license.
   - For licenses not in the summary table, review the SPDX License List and
     license text to add new entries.

3. Legal Review Request (if applicable)
   - When license conflicts, non-standard licenses, or commercial restriction
     clauses are present, request legal review from the legal team.

4. Recording Review Results
   - Record review results in the SBOM or license review record and store in
     the open source management system.

5. Obligation Fulfillment Confirmation
   - Before distribution, confirm that license obligations (notice inclusion,
     source code disclosure, etc.) have been completed.

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template

2 - §3.2 Relevant Tasks

2.1 - §3.2.1 External Inquiry Response

1. Clause Overview

Companies distributing software may receive inquiries from third parties (customers, open source copyright holders, researchers, etc.) regarding open source license compliance. Failure to respond to these inquiries in a timely manner risks escalation into copyright infringement disputes. §3.2.1 requires organizations to establish a publicly available means of contact for receiving external inquiries and to document a procedure internally for systematically responding to those inquiries. This clause requires both a public channel (Verification Material 3.2.1.1) and an internal response procedure (Verification Material 3.2.1.2).

2. What to Do

• Specify a publicly available contact (email address, web form, etc.) on the product or website where third parties can send open source license compliance inquiries.
• Document the internal response procedure from receiving an external inquiry through review, response, and closure.
• Include the person responsible for each type of inquiry (Open Source Program Manager, legal team, etc.) and the escalation path in the procedure.
• Record and retain the history of inquiries received and responses given.
• Periodically verify the validity of the public contact and the currency of the internal procedure.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.2.1.1 Publicly Available External Inquiry Channel

How to Comply

A means by which third parties can send open source license compliance inquiries must be publicly specified. The most common method is to publish a dedicated email address (e.g., oss@company.com) in product documentation, software open source notices, or the company website. This public contact itself is Verification Material 3.2.1.1.

It is better to use a role-based address rather than an individual’s personal email. This way the address is maintained even when the person in charge changes, and it is advisable to manage it as a team mailbox to prevent inquiries from being missed. Registering the contact on the OpenChain Conformance website is also an option.

Considerations

• Use role-based address: Use a role-based address such as oss@company.com instead of a personal email to prepare for changes in the person in charge.
• Publication location: Publish in locations that third parties can easily find, such as product manuals, open source notices (NOTICES file), and the company website.
• Verify responsiveness: Periodically check that the published contact is actually being received and monitored.
• Multilingual consideration: For global products, also provide English contact information.

Sample

The following is a sample public contact notice to be posted on the product open source notice or website.

Open Source License Compliance Inquiry

For inquiries regarding open source license compliance of the software components
included in this software, please contact us at the email below.

- Email: oss@company.com
- Response time: Within 14 business days

Open Source License Compliance Inquiry

For inquiries regarding open source license compliance of this software,
please contact: oss@company.com

3.2.1.2 Internal External Inquiry Response Procedure

How to Comply

An internal procedure defining how to handle an external inquiry when it is received must be documented. The procedure must include the following steps: (1) receiving and classifying the inquiry, (2) assigning a person responsible, (3) reviewing and drafting a response, (4) legal review (if necessary), (5) sending the response, and (6) record retention. This procedure document is Verification Material 3.2.1.2.

Response deadlines should be set within a reasonable range and specified in the procedure. In general, an initial response within 14 days and a final response within 60 days are common standards. The history of inquiry receipt, handling, and closure should be recorded in the internal system and retained for submission during audits.

Considerations

• Person responsible and escalation: Specify the primary person responsible (Open Source Program Manager) and the escalation path for legal review in the procedure.
• Response deadline: Specify the deadlines for initial and final responses in the procedure and adhere to them.
• Record retention: Record the inquiry content, review process, and final response, and retain for at least 3 years.
• Response by type: Include in the procedure methods for responding to different types of inquiries such as license notice requests, source code provision requests, and copyright infringement claims.

Sample

The following is a sample outline of an external inquiry response procedure.

[External Open Source Inquiry Response Procedure]

1. Receipt and Classification (within 1 business day)
   - Check the oss@company.com inbox daily.
   - Classify inquiries by type:
     A. Request for open source notice or source code provision
     B. Request for confirmation of license obligation compliance
     C. Copyright infringement claim or legal warning

2. Person Assignment and Initial Response (within 3 business days)
   - The Open Source Program Manager reviews the inquiry and sends a receipt confirmation.
   - Type C (legal warning) is immediately escalated to the legal team.

3. Review and Response Drafting (within 14 business days)
   - Review the relevant SBOM, license records, and Compliance Artifacts.
   - Type A: Confirm and provide the notice or source code.
   - Type B: Review compliance evidence and respond.
   - If necessary, request legal review of the draft response.

4. Response Sending and Closure
   - Send the final response and close the inquiry.

5. Record Retention
   - Document the inquiry content, review process, and final response and retain
     for at least 3 years.

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Policy Template — §9 External Inquiry Response

2.2 - §3.2.2 Effective Resources

1. Clause Overview

For an open source program to actually function, it is not enough to just define roles. Actual personnel must be assigned to each role, and sufficient time and budget must be provided to carry out the work. §3.2.2 requires organizations to document the persons responsible for each program role, confirm that staffing and budget are appropriately allocated, and to have a method for accessing legal expertise, a procedure for assigning internal responsibilities, and a procedure for handling non-compliance cases. This clause consists of five verification material items and is the stage that implements the role structure defined in §3.1 Program Foundation into an actual operational framework.

2. What to Do

• Record the names or job titles of the persons responsible for each role in the program (Open Source Program Manager, legal counsel, IT staff, etc.) in a document.
• Confirm and record that sufficient time and budget have been allocated for each role assignee to perform their duties.
• Identify and document internal or external legal expertise available when legal issues related to open source license compliance arise.
• Document a procedure for assigning internal open source compliance responsibilities to each role.
• Document a procedure for reviewing and remedying non-compliance cases when discovered.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.2.2.1 Document with Names of Persons in Program Roles

How to Comply

A document must be created listing the names, group names, or job titles of the actual persons responsible for each role in the program. This document can be managed by adding assignee information to the roles and responsibilities list document from §3.1.2.1, or can be included as an assignee status table in the Open Source Policy Appendix. It is acceptable to use job titles (Open Source Program Manager, Head of Legal, etc.) instead of specific individual names, and the document must be updated immediately when organizational changes occur.

Considerations

• Individual name or job title: Using job titles instead of names reduces the frequency of document updates when personnel changes occur.
• Concurrent roles: When one person handles multiple roles, note this fact for all relevant roles.
• Update management: Immediately update the document and record the version when organizational changes or personnel transfers occur.

Sample

The following is a sample assignee status table for program roles. The full form can be found in Open Source Policy Template Appendix 1.

| Role | Assignee | Contact |
|------|----------|---------|
| Open Source Program Manager | Gil-dong Hong (Dev Team Lead) | oss@company.com |
| Legal Counsel | Legal Kim (Head of Legal) | legal@company.com |
| IT Staff | Infra Lee (Infrastructure Team) | it-oss@company.com |
| Security Staff | Security Park (Security Team) | security@company.com |
| Developer Culture Staff | Culture Choi (HR Team) | culture@company.com |

3.2.2.2 Staffing and Funding Confirmation

How to Comply

It must be confirmed and the basis recorded that sufficient time and budget have been allocated for each role assignee to perform open source program duties. Even if there is no dedicated organization, there must be internal records confirming that the time available for concurrent assignees to invest in the work is secured, and that necessary budgets such as tool purchases or training costs have been allocated. Budget plans or work assignment documents that include management approval may constitute this Verification Material.

Considerations

• Specify dedicated vs. concurrent: Record whether it is a dedicated position or concurrent, and if concurrent, specify the input ratio (e.g., 20% of working hours).
• Retain budget evidence: Retain records proving budget support such as tool purchase contracts, training cost expenditure records, and external consulting contracts.
• Management confirmation: Maintain records of management approval or confirmation of staffing and budget support.

Sample

[Open Source Program Resource Allocation Confirmation]

Program year: 2026
Approver: [Executive name] / Approval date: 2026-01-10

| Role | Assignee | Input Ratio | Annual Budget |
|------|----------|-------------|---------------|
| Open Source Program Manager | Gil-dong Hong | 50% | - |
| Legal Counsel | Legal Kim | 20% | - |
| IT Staff (tool operation) | Infra Lee | 10% | Including tool license costs |
| Training budget | - | - | Annual OOO amount |
| External legal advisory budget | - | - | Executed as needed |

3.2.2.3 Legal Expertise Access Method

How to Comply

The method for accessing professional legal advice when legal issues related to open source license compliance arise must be identified and documented. If there is an internal legal team, record the team’s contact information and escalation procedure. If there is no internal legal team or if expertise is insufficient, specify in the document the method for utilizing external law firms or open source consulting specialists.

Considerations

• Internal vs. external: Specify both the method for utilizing the internal legal team and the criteria for requesting external consultation.
• Escalation criteria: Include in the procedure the criteria for when legal advice is needed (copyright infringement claims, non-standard licenses, patent clauses, etc.).
• Maintain external advisory list: Keep information on open source specialist external law firms or consultants up to date.

Sample

[Legal Expertise Access Method]

Internal Legal Team:
- Contact: Legal Team (legal@company.com)
- Escalation criteria: When copyright infringement claims are received, when
  interpretation of GPL-family license obligations is uncertain, when review
  of non-standard licenses is required

External Legal Advisory:
- Utilization criteria: When complex legal disputes arise that are difficult for
  the internal legal team to adjudicate
- Contract status: [External law firm name] (annual advisory contract in place)
- Open source specialist consulting: Refer to the OpenChain partner list

3.2.2.4 Internal Responsibility Assignment Procedure

How to Comply

A procedure for clearly assigning internal responsibilities related to open source compliance to each role must be documented. This procedure defines who is responsible for what, and specifies the responsible person for each work stage such as open source use approval, SBOM generation, license review, and Compliance Artifacts distribution. This procedure document can be included in the open source policy or process document.

Considerations

• Responsibility by work stage: Designate a responsible person for each stage of open source introduction, review, approval, and distribution.
• RACI utilization: Defining responsibilities by role (Responsible, Accountable, Consulted, Informed) as a RACI matrix increases clarity.
• Update cycle: Immediately update the procedure when organizational or process changes occur.

Sample

| Task | Open Source PM | Legal | IT | Security | Developer |
|------|----------------|-------|----|----------|-----------|
| Open source use approval | A | C | - | C | R |
| License obligation review | R | A | - | - | I |
| SBOM generation | A | - | R | - | C |
| Vulnerability monitoring | I | - | C | A/R | I |
| Compliance Artifacts distribution | A | C | R | - | I |
| External inquiry response | A/R | C | - | - | - |

R: Responsible / A: Accountable / C: Consulted / I: Informed

3.2.2.5 Non-Compliance Case Review and Remediation Procedure

How to Comply

A procedure for reviewing and remediating non-compliance cases (license obligation failures, SBOM omissions, unauthorized open source use, etc.) when discovered must be documented. The procedure must include: (1) identification and reporting of non-compliance cases, (2) severity assessment, (3) root cause analysis, (4) corrective action, (5) preventive measures, and (6) record retention.

Non-compliance cases can be discovered through various channels such as internal audits, external inquiries, and automated tool alerts. It is effective to distinguish between urgent measures (distribution suspension, immediate source code disclosure, etc.) and general measures depending on severity, and to set different deadlines for processing.

Considerations

• Severity classification: Classify the severity (high/medium/low) of non-compliance cases based on legal risk and set different processing deadlines.
• Escalation: Make management reporting and legal review mandatory for high-severity cases.
• Recurrence prevention: After completing corrective action, derive and record process improvement measures to prevent recurrence of the same type of non-compliance.
• Record retention: Retain non-compliance case history and corrective completion records for at least 3 years.

Sample

[Non-Compliance Case Handling Procedure]

1. Identification and Reporting
   - Identify non-compliance cases through internal audits, external inquiries,
     CI/CD tool alerts, etc.
   - Report immediately to the Open Source Program Manager.

2. Severity Assessment
   - High: GPL source code not disclosed for distributed software, copyright infringement claim received
     → Emergency review initiated within 48 hours
   - Medium: SBOM omission, incomplete license notice
     → Corrective action completed within 7 business days
   - Low: Internal process non-compliance (approval procedure skipped, etc.)
     → Corrective action completed within 30 days

3. Root Cause Analysis and Corrective Action
   - Identify the cause of non-compliance and establish a corrective plan.
   - For high and medium cases, take action after consulting with the legal team.

4. Recurrence Prevention
   - Derive and implement process or training improvement measures.

5. Record Retention
   - Record the case content, action progress, and completion date, and retain for at
     least 3 years.

5. References

• Related guide: Enterprise Open Source Management Guide — 1. Organization
• Related template: Open Source Policy Template — Appendix 1. Personnel Status

3 - §3.3 Content Review and Approval

3.1 - §3.3.1 SBOM

1. Clause Overview

Without knowing what open source components are included in the supplied software, it is impossible to fulfill license obligations or respond to security vulnerabilities. §3.3.1 requires the establishment of a procedure for identifying, tracking, reviewing, approving, and archiving the open source components that make up supplied software, and maintaining component records (SBOM) that demonstrate the procedure has actually been followed. This clause forms the foundation for operating the SBOM, which is the core infrastructure of open source license compliance and Security Assurance.

2. What to Do

• Identify and list the open source components included in supplied software using automated tools (FOSSology, ORT, Syft, cdxgen, etc.).
• Document a procedure for tracking, reviewing, approving, and archiving open source component information (component name, version, license, source, etc.).
• Generate and manage an SBOM for each supplied software release.
• Write SBOM data in SPDX or CycloneDX standard formats to ensure interoperability.
• Immediately update the SBOM when software changes (new component addition, version upgrade, component removal) occur.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.3.1.1 Open Source Component Management Procedure

How to Comply

A series of procedures for identifying, tracking, reviewing, approving, and archiving open source components included in supplied software must be documented. The procedure covers how open source is managed throughout the software development lifecycle and must include the following steps: (1) component identification, (2) license confirmation, (3) obligation review, (4) use approval, (5) SBOM generation and registration, (6) providing SBOM upon distribution, (7) SBOM update upon changes, and (8) SBOM archiving. This procedure document itself is Verification Material 3.3.1.1.

It is recommended to adopt SPDX (ISO/IEC 5962) or CycloneDX format for standardizing the SBOM. Integrating automated tools into the CI/CD pipeline makes it easier to keep the SBOM up to date as it is automatically updated when components change.

Considerations

• Automated tool integration: Automate SBOM generation by integrating tools such as FOSSology, ORT, Syft, and cdxgen into CI/CD.
• Standard format adoption: Write SBOMs in SPDX or CycloneDX format to ensure interoperability with supply chain partners.
• Define update triggers: Mandate SBOM updates when new components are added, versions are upgraded, components are removed, or licenses change.
• Approval procedure specification: Include in the procedure the approval procedure by the Open Source Program Manager or OSRB when introducing new open source components.
• Retention period: Retain the SBOM for at least [N] years after the relevant software is distributed.

Sample

The following is a sample outline of an open source component management procedure. The full process form can be found in the Open Source Process Template.

[Open Source Component Management Procedure Outline]

(1) Identification
    - Developers report open source components to the open source management system
      when introducing them.
    - SCA tools in the CI/CD pipeline (Syft, ORT, etc.) automatically detect components.

(2) License Confirmation and Obligation Review
    - Confirm the license of identified components based on the SPDX License List.
    - Refer to the license obligation summary table to review obligations based on
      the distribution format.
    - Request legal review if uncertain.

(3) Use Approval
    - The Open Source Program Manager approves use based on review results.
    - Components that conflict with license policy are rejected after reviewing alternatives.

(4) SBOM Generation and Registration
    - Register approved components in the SBOM (format: SPDX or CycloneDX).
    - The SBOM includes component name, version, license, source (URL), and copyright notice.

(5) Distribution and SBOM Provision
    - Provide the SBOM with the software upon distribution or upon request.

(6) Update Upon Changes
    - Immediately update the SBOM when components are added, upgraded, removed, or when
      licenses change.

(7) Archiving
    - Retain the SBOM by version for at least [N] years after software distribution.

3.3.1.2 Open Source Component Records (SBOM)

How to Comply

Component records that demonstrate the procedure defined in 3.3.1.1 has actually been followed must be maintained for each supplied software. These records are the SBOM (Software Bill of Materials) and constitute Verification Material 3.3.1.2. The SBOM must include at minimum the name, version, license, and source of each open source component. Writing it in SPDX or CycloneDX format makes it immediately submittable during audits.

The SBOM should be managed by software release version, and past version SBOMs should also be retained so that the component configuration at a specific point in time can always be verified. The output from SBOM generation tools can be used directly, or it can be stored and managed in an open source management system (SW360, Dependency-Track, etc.).

Considerations

• Required items: Include component name, version, license identifier (SPDX ID), source (package registry URL or source repository), and copyright notice.
• Version-by-version management: Manage SBOMs separately for each software release version and retain past versions.
• Utilize management tools: Using open source management systems such as SW360 and Dependency-Track allows for systematic management of SBOM generation, tracking, and distribution.
• Customer provision: Retain in an accessible format so that the SBOM can be provided immediately when requested by customers or supply chain partners.

Sample

The following is a sample of key items in an SPDX format SBOM.

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: MyProduct-v1.2.0-sbom
DocumentNamespace: https://company.com/sbom/myproduct-1.2.0

PackageName: openssl
SPDXID: SPDXRef-openssl
PackageVersion: 3.0.8
PackageDownloadLocation: https://www.openssl.org/source/openssl-3.0.8.tar.gz
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: Copyright (c) 1998-2023 The OpenSSL Project

PackageName: zlib
SPDXID: SPDXRef-zlib
PackageVersion: 1.2.13
PackageDownloadLocation: https://zlib.net/zlib-1.2.13.tar.gz
PackageLicenseConcluded: Zlib
PackageLicenseDeclared: Zlib
PackageCopyrightText: Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template
• Related tools: FOSSology, ORT, Syft, cdxgen, Dependency-Track

3.2 - §3.3.2 License Compliance

1. Clause Overview

License obligations for open source components vary depending on the distribution format (binary, source code), whether modifications were made, and how they are combined with other components. §3.3.2 requires the program to have the capability to handle the common open source license use cases for open source components in the supplied software. This clause goes beyond simply identifying licenses to establishing procedures that define how to fulfill obligations for various distribution scenarios.

2. What to Do

• Identify major license use cases such as binary distribution, source code distribution, and distribution of modified open source, and establish handling procedures for each case.
• Include in the procedure how to handle license conflicts (combination of incompatible license components).
• Define the handling method for licenses requiring notice obligations (including copyright notices and full license text).
• Establish a distribution procedure for software containing licenses with source code disclosure obligations such as GPL.
• Document the procedure and periodically review it to address new license types.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.3.2.1 Procedure for Handling License Use Cases

How to Comply

A procedure defining how to fulfill license obligations for the various scenarios in which open source is included in supplied software must be documented. This procedure document is Verification Material 3.3.2.1. ISO/IEC 5230 presents the following 6 major use cases as examples, and the organization selects the applicable cases based on its business environment to establish handling procedures.

Each use case procedure must include: (1) criteria for determining whether the case applies, (2) license obligation items, (3) method for fulfilling the obligation, (4) person responsible, and (5) artifacts (notices, source code packages, etc.). The path for escalating to the legal team in the case of license conflicts must also be specified.

Considerations

• Determine use case scope: Select the use cases matching the organization’s software distribution method to establish procedures (not all cases may apply to every organization).
• License conflict response: Pre-define the handling method for incompatible license combinations such as GPL and Apache-2.0.
• Notice management: Establish a procedure for writing notices in a NOTICES file or product documentation for licenses with copyright notice obligations.
• Source code disclosure procedure: Separately define the procedure for responding to source code disclosure requests under GPL-family licenses.
• Update cycle: Update the procedure when new license types are adopted or distribution formats change.

Sample

The following is a sample summary table of procedures for handling license use cases.

| Use Case | License Examples | Key Obligations | Handling Method |
|----------|-----------------|-----------------|-----------------|
| Binary distribution | MIT, Apache-2.0 | Include copyright notice | Include notice in NOTICES file or in-app notice screen |
| Binary distribution | GPL-2.0, GPL-3.0 | Disclose source code or include written offer | Distribute source code package or enclose written offer |
| Source code distribution | All licenses | Preserve original license file and copyright notice | Keep license file and copyright notice as is |
| Contains modified open source | GPL-2.0, LGPL-2.1 | Note modifications, apply same license to modifications | Record modification details, disclose modified source code |
| Incompatible license combination | GPL-2.0 + Apache-2.0 | Resolve license conflict | Replace component or change structure after legal review |
| Attribution requirement | BSD-3-Clause, Apache-2.0 | Include copyright notice in product documentation or UI | Add notice to product manual or About screen |

The following is a sample outline of a license obligation handling procedure by distribution format.

[License Obligation Handling Procedure for Binary Distribution]

1. SBOM Review
   - Review the list of included open source based on the latest SBOM of the
     distributed software.

2. License Obligation Classification
   - Notice obligation: MIT, Apache-2.0, BSD, etc. → Create NOTICES file
   - Source code disclosure obligation: GPL-2.0, GPL-3.0 → Prepare source code package
   - LGPL: Determine scope of obligation based on dynamic linking status
     (legal review if necessary)

3. Compliance Artifacts Preparation
   - NOTICES file: Include copyright notices and full license text for all open source
   - Source code package: Include modified source code and build scripts for GPL components

4. Review and Approval
   - The Open Source Program Manager conducts a final review of the completeness of
     the artifacts.
   - License conflicts or uncertain items are escalated to the legal team.

5. Distribution
   - Provide Compliance Artifacts together with the software.
   - Retain a copy of the artifacts (see §3.4.1).

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template

4 - §3.4 Compliance Artifacts

4.1 - §3.4.1 Artifacts

1. Clause Overview

To fulfill license obligations, Compliance Artifacts such as notices and source code packages must actually be prepared and provided with the software. §3.4.1 requires the establishment of a procedure for preparing the Compliance Artifacts required by the identified licenses and distributing them with the supplied software, as well as a procedure for retaining copies of the artifacts for a certain period. This clause connects the results of the §3.3 review and approval stage to actual distribution and archiving.

2. What to Do

• Define the types of Compliance Artifacts (NOTICES file, source code package, written offer, etc.) required for each license.
• Document a procedure for preparing artifacts and providing them with the supplied software.
• Establish and document a procedure for retaining copies of distributed artifacts for a certain period.
• Specify the artifact retention period in the policy (industry practice: at least 3 years after the last distribution).
• Maintain records that prove the archiving procedure was carried out correctly.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.4.1.1 Compliance Artifacts Preparation and Distribution Procedure

How to Comply

A procedure for preparing Compliance Artifacts required by license obligations and providing them with the supplied software must be documented. This procedure document is Verification Material 3.4.1.1. The procedure must include the following steps: (1) determining artifact types, (2) creating artifacts, (3) reviewing and approving, (4) providing with the software, and (5) record retention.

The types of Compliance Artifacts vary depending on the licenses being distributed. Generally, licenses with notice obligations (MIT, Apache-2.0, etc.) require a NOTICES file, and GPL-family licenses require a source code package or written offer. Artifacts can be provided in various ways such as enclosed in the product, included in the package, posted on a website, or provided upon request.

Considerations

• Define artifact types: Define in advance what artifacts are required for each license so that distribution preparation can proceed quickly.
• NOTICES file quality: Review that copyright notices and full license text for all open source components are included without omission.
• Source code package: For GPL components, prepare a complete source code package that includes modified source code and build scripts.
• Provision method: Determine whether to enclose artifacts with the software, post them on a website, or provide them upon request based on license requirements.
• Final review: The Open Source Program Manager conducts a final check of the completeness of artifacts before distribution.

Sample

The following is a sample outline of a Compliance Artifacts preparation and distribution procedure.

[Compliance Artifacts Preparation and Distribution Procedure]

1. Determine Artifact Types
   - Review the list of included licenses based on the SBOM.
   - Determine the necessary artifacts based on license obligations:
     · Notice obligation licenses → NOTICES file
     · GPL-2.0/3.0 → Source code package or written offer
     · LGPL → Dynamic link structure proof document or source code

2. Create Artifacts
   - NOTICES file: Generate using automated tools (FOSSology, ORT, etc.) or create manually.
     Include component name, version, full license text, and copyright notice.
   - Source code package: Include modified source code and build scripts for GPL components.

3. Review and Approval
   - The Open Source Program Manager reviews the completeness and accuracy of the artifacts.
   - Incomplete items are corrected and re-reviewed.

4. Provide with Software
   - Enclose in the product package or include in the screen displayed during installation.
   - If posting on a website or providing upon request, specify the relevant URL or procedure.
   - If using a written offer, include a written commitment valid for 3 years.

3.4.1.2 Compliance Artifacts Archiving Procedure

How to Comply

A procedure for retaining copies of Compliance Artifacts for distributed supplied software for a certain period must be documented, and records must be maintained that prove the procedure was actually followed. This procedure document and archiving records are Verification Material 3.4.1.2.

The retention period must be a reasonable period from the last distribution of the software, and at least 3 years is recommended as industry practice. The items to be retained include all artifacts provided upon distribution such as NOTICES files, source code packages, written offer copies, and SBOMs. Artifacts should be systematically managed by software version so that artifacts for a specific version can be immediately retrieved and submitted.

Considerations

• Specify retention period: Specify the retention period (at least 3 years) in the policy or procedure document.
• Version-by-version management: Link software release versions to artifacts and retain by version.
• Storage location: Store in an accessible and secure location such as an internal file server, document management system, or source code repository.
• Maintain archiving records: Record the history of when artifacts for which version were archived.
• Accessibility: Store in a searchable format so that artifacts can be immediately submitted when audits or external inquiries occur.

Sample

The following is a sample Compliance Artifacts archiving record form.

| Software Name | Version | Distribution Date | Artifact Type | Storage Location | Retention Deadline | Responsible |
|---------------|---------|-------------------|---------------|-----------------|-------------------|-------------|
| MyProduct | v1.0.0 | 2024-03-01 | NOTICES file, GPL source code package | /archive/myproduct/v1.0.0/ | 2027-03-01 | Gil-dong Hong |
| MyProduct | v1.1.0 | 2024-09-15 | NOTICES file | /archive/myproduct/v1.1.0/ | 2027-09-15 | Gil-dong Hong |
| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES file, LGPL source code package, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | Infra Lee |

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template

5 - §3.5 Community Engagement

5.1 - §3.5.1 Contributions

1. Clause Overview

Many companies contribute code, documentation, bug reports, and more to external open source projects. Contribution activities build community trust and expand technical influence, but they also carry the risk of unintentionally disclosing company code or patents. §3.5.1 requires organizations that allow external open source contributions to establish a documented policy and procedure governing contributions, and to ensure that Program Participants are aware of their existence. This clause does not apply to organizations that do not allow contributions, but if they do, all three verification materials must be in place.

2. What to Do

• Decide whether the organization allows external open source contributions and specify this in the policy.
• If contributions are allowed, document a contribution policy including the types of contributions (code, documentation, bug reports, etc.), approval process, and copyright and patent handling policy.
• Establish and document a procedure for managing actual contributions from proposal through approval, submission, and recording.
• Establish a procedure for communicating the existence of the contribution policy to Program Participants.
• Record and retain the contribution history.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.5.1.1 Open Source Contribution Policy

How to Comply

A policy governing the act of contributing to external open source projects must be documented. This policy document is Verification Material 3.5.1.1. The contribution policy must include: (1) scope of allowed contributions (code, documentation, bug reports, etc.), (2) contribution approval process, (3) copyright handling (company-owned vs. individually-owned), (4) patent handling policy, (5) criteria for signing a CLA (Contributor License Agreement), and (6) prohibited contribution items (trade secrets, unpublished patents, etc.).

The policy can be included as a separate section in the Open Source Policy document or managed as an independent contribution policy document. Even organizations that completely prohibit contributions should explicitly document that “contributions are not permitted.”

Considerations

• Define contribution scope: Specifically list the types of contributions allowed (bug fixes, feature additions, documentation writing, etc.).
• Copyright attribution: Specify in the policy whether copyright of contributions belongs to the company or to the individual.
• Patent risk management: When contributions may include company patents, make legal review mandatory.
• CLA handling: When an external project requires CLA signing, specify the signing authority and procedure in the policy.
• Prohibited items: Prohibit contributions containing trade secrets, unregistered patents, or third-party intellectual property.

Sample

The following is a sample of key items in an open source contribution policy.

## Open Source Contribution Policy

### Scope of Allowed Contributions
The company allows employees to contribute to external open source projects for business purposes.
The types of contributions allowed are as follows:
- Bug fixes and patch submissions
- Documentation improvements
- Feature additions (prior approval required)
- Bug reports and issue submissions

### Copyright and Patents
- Copyright of contributions created during working hours using company resources belongs to the company.
- If there is a possibility that company patents are included in the contribution, prior review by
  the legal team is required.

### Prohibited Items
Code containing the following items cannot be contributed:
- Trade secrets or confidential information
- Third-party intellectual property
- The company's unpublished patent technology

### CLA (Contributor License Agreement)
If an external project requires CLA signing, prior reporting to and approval from the Open Source
Program Manager is required.

3.5.1.2 Open Source Contribution Management Procedure

How to Comply

A procedure defining step-by-step how to handle actual contribution activities must be documented. This procedure document is Verification Material 3.5.1.2. The procedure must include the following steps: (1) contribution proposal and approval request, (2) legal and patent review (if necessary), (3) approval, (4) contribution submission, and (5) contribution history recording. Depending on the scale or type of contribution, it is possible to operate a simplified procedure (small bug fixes) and a formal procedure (large-scale feature additions) separately.

Considerations

• Procedure distinction by contribution scale: Set scale-based criteria so that small bug fixes use simplified approval and large-scale feature additions go through formal legal review.
• Retain contribution records: Record and retain the contribution proposal, approval record, and submission link (PR/commit URL).
• Escalation: Include in the procedure an escalation path to the legal team when patent or copyright issues arise.

Sample

The following is a sample outline of an open source contribution management procedure.

[Open Source Contribution Management Procedure]

1. Contribution Proposal
   - The employee reports the contribution details (project name, contribution type, content
     summary) to the Open Source Program Manager.

2. Review and Approval
   - Small contributions (bug fixes, documentation improvements):
     The Open Source Program Manager confirms policy compliance and approves.
   - Large contributions (feature additions, core module contributions):
     The Open Source Program Manager gives final approval after the legal team's
     patent and copyright review.

3. CLA Handling (if applicable)
   - If the external project requires a CLA, process according to the approved CLA
     signing form.

4. Contribution Submission
   - Submit only the approved content.
   - Contribute using a company email or company-approved account.

5. Contribution Recording
   - Record and retain the contribution content, approver, submission date, and
     contribution URL (PR/commit link).

3.5.1.3 Contribution Policy Awareness Procedure

How to Comply

A procedure for communicating the open source contribution policy to all Program Participants so they are aware of its existence must be documented. This procedure document is Verification Material 3.5.1.3. It can be integrated with the §3.1.1.2 open source policy communication procedure by including the contribution policy in it.

It is effective to combine new hire onboarding briefings on the contribution policy, internal wiki posts, and email announcements for communication. Retain notification history and training completion records to prove that communication took place.

Considerations

• Include in onboarding: Include the contribution policy briefing as a mandatory item in the new hire onboarding process.
• Re-communication when policy is updated: Immediately notify Program Participants when the contribution policy is changed.
• Evidence retention: Retain notification sending history and training completion certificates for at least 3 years.
• Policy accessibility: Post the contribution policy on the internal portal or wiki at all times so it can be checked at any time.

Sample

The following is a sample contribution policy communication email.

Subject: [Open Source] Open Source Contribution Policy Notice

To: All development-related employees
From: Open Source Program Manager

Hello,

We would like to inform you about the company's open source contribution policy.
All employees involved in contributing to external open source projects are requested
to review and familiarize themselves with the policy document at the link below.

- Policy document: [Internal portal link]
- Key contents: Scope of allowed contributions, approval procedure, copyright and
               patent handling policy
- Policy version: v1.0 (Effective date: YYYY-MM-DD)

If you wish to make a contribution, you must go through the prior approval procedure.
Inquiries: Open Source Program Manager (oss@company.com)

Thank you.
Open Source Program Manager

5. References

• Related guide: Enterprise Open Source Management Guide — 6. Contributions
• Related template: Open Source Policy Template — §3 Open Source Contributions

6 - §3.6 Adherence to the Specification

6.1 - §3.6.1 Conformance

1. Clause Overview

To receive official recognition of ISO/IEC 5230 conformance, the program defined in §3.1.4 must be confirmed in a document as satisfying all requirements of this specification. §3.6.1 is the stage for officially affirming that all clauses from §3.1 through §3.5 have been satisfied. This clause is the final confirmation procedure that completes adherence to the specification, requiring the organization’s official confirmation that the program satisfies all requirements of ISO/IEC 5230:2020 version 2.1.

2. What to Do

• Conduct a self-assessment to verify that all verification material items (24 items) for all clauses from §3.1 to §3.5 are in place.
• Write a document confirming that the program satisfies all requirements of ISO/IEC 5230 within the scope of application defined in §3.1.4.
• Record the reviewer, approver, and confirmation date in the confirmation document.
• Choose an appropriate certification method — self-certification, independent assessment, or third-party certification — and proceed.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.6.1.1 Specification Conformance Confirmation Document

How to Comply

A document must be written confirming that all requirements of ISO/IEC 5230:2020 are satisfied within the scope of application defined in §3.1.4. This document is Verification Material 3.6.1.1. It can be written in the form of a checklist confirming compliance for each of the 24 verification material items, or as a general conformance statement.

Before writing, use this guide’s Full Clause Checklist to verify that all verification materials are in place. The document must include the scope of the program being confirmed, the specification version confirmed (ISO/IEC 5230:2020 version 2.1), the confirmation date, and the reviewer and approver.

Considerations

• Self-assessment first: Before writing the document, conduct a self-assessment of all 24 verification material items to confirm there are no missing items.
• Specify specification version: Specify the specification version confirmed in the document (ISO/IEC 5230:2020 version 2.1).
• Approval process: Formalize the document through the Open Source Program Manager’s review and management or OSRB approval.
• Update cycle: After a new version of the specification is published, re-confirm based on the latest version within 18 months (see §3.6.2).

Sample

The following is a sample ISO/IEC 5230 specification conformance confirmation document.

[ISO/IEC 5230 Specification Conformance Confirmation]

Program name: [Company name] Open Source Compliance Program
Scope of application: [Enter scope defined in §3.1.4]
Specification confirmed: ISO/IEC 5230:2020 (version 2.1)
Confirmation date: YYYY-MM-DD

This document confirms that the above program satisfies all requirements of
ISO/IEC 5230:2020 from §3.1 to §3.6.

Summary of conformance items:
- §3.1 Program Foundation (5 clauses, 8 verification materials): Satisfied ✓
- §3.2 Relevant Tasks (2 clauses, 7 verification materials): Satisfied ✓
- §3.3 Content Review and Approval (2 clauses, 3 verification materials): Satisfied ✓
- §3.4 Compliance Artifacts (1 clause, 2 verification materials): Satisfied ✓
- §3.5 Community Engagement (1 clause, 3 verification materials): Satisfied ✓
- §3.6 Adherence to the Specification (2 clauses, 2 verification materials): Satisfied ✓

Reviewer: [Open Source Program Manager name]
Approver: [Management or OSRB head name]
Approval date: YYYY-MM-DD

5. References

• ISO/IEC 5230 self-certification: https://certification.openchainproject.org/
• Full clause checklist: ISO/IEC 5230 Conformance Guide

6.2 - §3.6.2 Duration

1. Clause Overview

ISO/IEC 5230 conformance does not remain valid indefinitely once obtained. When a new version of the specification is published, a program that was conformant against the previous version retains its conformance for only 18 months after the new version is published. §3.6.2 requires organizations to maintain a document confirming that the program meets all requirements of the specification within the past 18 months of obtaining conformance. This clause serves as a mechanism to ensure that open source compliance programs remain continuously operational rather than stopping at formal certification.

2. What to Do

• Record and manage the date on which conformance was obtained.
• Within the past 18 months of obtaining conformance, re-confirm and document that the program still meets all requirements of the specification.
• If a new version of the specification is published, update the program to meet the latest version and re-confirm within 18 months.
• Conduct periodic internal audits to verify that the program maintains continuous compliance.

3. Requirements and Verification Materials

4. How to Comply with Each Verification Material

3.6.2.1 Document Confirming All Requirements Met Within 18 Months

How to Comply

A document confirming that the program still meets all requirements of the specification must be maintained within 18 months of obtaining conformance. This document constitutes Verification Material 3.6.2.1. The simplest approach is to periodically review and update the specification conformance document from §3.6.1.1 at least once a year. Each time it is updated, record the review date and reviewer to demonstrate that a review was conducted within the past 18 months.

When a new version of ISO/IEC 5230 is published, update the program to meet the latest version within the 18-month grace period and create a re-confirmation document. Since conformance expires if the grace period is exceeded, it is important to monitor specification revision trends and respond in a timely manner.

Considerations

• Establish a periodic re-confirmation schedule: Conduct a minimum of one annual internal audit to re-confirm and document the validity of all verification material items.
• Monitor specification revisions: Regularly check OpenChain Project announcements for specification revisions and establish a response plan within 18 months when a new version is published.
• Manage conformance expiration: Register the conformance acquisition date and validity period (18 months) in a calendar or management system to receive renewal reminders before expiration.
• Reflect changes: When organizational structure, product portfolio, or process changes occur, immediately reflect them in the program and update the re-confirmation document.

Sample

Below is a sample periodic re-confirmation record for ISO/IEC 5230 specification compliance.

[ISO/IEC 5230 Specification Conformance Periodic Re-confirmation Record]

Program Name: [Company Name] Open Source Compliance Program
Initial Conformance Date: YYYY-MM-DD
Specification Version Confirmed: ISO/IEC 5230:2020 (Version 2.1)

| Re-confirmation Date | Result | Changes | Reviewer | Notes |
|----------------------|--------|---------|----------|-------|
| 2025-01-10 | Fully Met | Reflected personnel change (§3.2.2.1 updated) | John Doe | - |
| 2026-01-08 | Fully Met | None | John Doe | Next re-confirmation: 2027-01-08 |

Next re-confirmation scheduled: YYYY-MM-DD (within 12 months of last re-confirmation)
18-month validity deadline: YYYY-MM-DD (18 months from last re-confirmation)

Below is a sample response checklist for when a new version of the specification is published.

[ISO/IEC 5230 New Version Response Checklist]

New Version Publication Date: YYYY-MM-DD
Response Deadline (18 months): YYYY-MM-DD

□ Identify changes in requirements between new version and current version
□ Establish program update plan based on changed requirements
□ Complete updates and organize verification materials under new version
□ Create and approve specification conformance document under new version
□ Proceed with self-certification or certification renewal process

5. References

• Check latest OpenChain specification version: https://www.openchainproject.org/license-compliance
• Self-certification renewal: https://certification.openchainproject.org/
• §3.6.1 Conformance: Previous Clause