§3.1 Program Foundation

• 1: §3.1.1 Policy
• 2: §3.1.2 Competence
• 3: §3.1.3 Awareness
• 4: §3.1.4 Program Scope
• 5: §3.1.5 License Obligations

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

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

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

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

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