1. Documenting an Open Source Policy

An enterprise must establish and document an open source policy consisting of principles that let the organizations involved in developing, servicing, and delivering supplied software use open source correctly, and must propagate this policy throughout the organization.

To this end, the ISO standards commonly require a documented open source policy and security assurance policy as follows.

A typical open source policy includes the following. An enterprise must create and document an open source policy that includes these principles:

1. Principles for minimizing open source license compliance and security vulnerability risk when delivering supplied software products and services
2. Principles for contributing to external open source projects
3. Principles for releasing the enterprise’s own software as open source
4. Principles for generating and managing the Software Bill of Materials (SBOM) of open source software components
5. Principles for responding to known vulnerabilities and newly discovered vulnerabilities

The open source policy must also be propagated to program participants and reviewed and updated regularly. This ensures the policy always stays current and reflects the organization’s requirements.

2. What the Open Source Policy Must Cover

An open source policy must include the following core content:

(1) Open Source License Compliance Principles

To achieve open source license compliance, the following principles must be established:

• Identify and document all open source included in supplied software
• Determine and comply with the license obligations of each open source
• Produce compliance artifacts that satisfy license obligations
• Fulfill license obligations such as open source notices and source code disclosure

(2) Open Source Security Assurance Principles

To achieve open source security assurance, the following principles must be established:

• Monitor known vulnerabilities and newly discovered vulnerabilities in the open source components of supplied software
• Perform a risk/impact assessment when a vulnerability is found
• Respond promptly and apply patches for severe vulnerabilities
• Notify customers of vulnerability information and provide updates

(3) Responding to Open Source Risk

To minimize the license and security risks that come with using open source, the following procedures must be established:

1. Identify open source and review its license obligations
2. Design the architecture with open source licenses in mind
3. Produce open source compliance artifacts
4. Generate and manage the Software Bill of Materials (SBOM)
5. Respond to open source license compliance issues
6. Respond to open source security vulnerabilities

You can see how these principles are documented in6. Use of Open Source of [Appendix 1] the open source policy template.

1. Use of Open Source
When developing and delivering supplied software, the obligations required by each open source license must be observed. The activities carried out for this purpose are called open source license compliance.
For proper open source license compliance activities and security assurance, the software development/delivery organization must comply with the following and record and retain the entire process in an issue tracking system.
(1) Identify open source and review license obligations
When introducing open source into supplied software development, first identify what the open source license is, and review and confirm the obligations the license requires.
The company's [Open Source License Guide] includes a list of major open source licenses, and for each license, it explains the obligations required by each of the following distribution forms.
- Binary form
- Source form
- Strong/weak Copyleft
- SaaS-based delivery
- Whether modified
- Inclusion of open source requiring attribution, etc.
Software development/delivery organizations can refer to this guide when reviewing open source license obligations. If a review of an open source license not covered by this guide is needed, contact the open source program manager.
(2) Design with open source licenses in mind
Identify the coupling relationships of open source and design the software architecture so that the company's own code is not affected by open source licenses.
The company's [Open Source License Guide] explains the source code disclosure scope for each open source license and design methods for preventing disclosure of the company's own code.
(3) Produce open source compliance artifacts
The most basic element of open source license compliance activity is understanding the state of open source included in supplied software. This is precisely to properly satisfy the open source license requirements that are the core of open source license compliance. In other words, a set of compliance artifacts must be produced for the open source included in supplied software.
Open source compliance artifacts fall into two broad categories.
1. Open source notice: a document providing the full text of open source licenses and copyright information
2. Source code package to be disclosed: a package that gathers the source code to be disclosed to fulfill the obligations of open source licenses such as GPL and LGPL that require source code disclosure
To compile, distribute, and archive these compliance artifacts, the following must be observed.
- Compile the open source notice or the source code package to be disclosed according to the conditions required by each license. For example, if a license requires that the full text of the license be enclosed, providing only a link is not sufficient.
- Store the compiled artifacts in a separate repository.
- If the source code to be disclosed is provided via a written offer, publish a download link so that the repository of compiled artifacts can be accessed externally.
The company's open source process can be used to issue the open source notice and compile the source code package to be disclosed.
(4) Generate the Software Bill of Materials (SBOM)
There must be a process to generate and maintain an SBOM (Software Bill of Materials) that includes the details of each open source software component making up the supplied software.
The company's open source process can use open source tools to generate and retain the SBOM.
(5) Compliance issue response procedure
When a compliance issue is raised, the open source program manager performs the following procedure to respond promptly.
1. Acknowledge receipt of the inquiry and specify a reasonable resolution time.
2. Confirm whether the issue content actually points to a real problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is a real problem, set a priority and decide on an appropriate response plan.
4. Carry out the response and, if necessary, appropriately supplement the open source process.
5. Preserve the above using the issue tracking system.
(6) Open source security assurance management
A documented procedure for detecting and resolving known vulnerabilities in the open source software components of supplied software must be established and maintained. This procedure must include the following.
- Apply methods for discovering the existence of known vulnerabilities
- Perform a risk/impact assessment for each discovered vulnerability
- Take appropriate action such as contacting customers or upgrading software components when necessary
The following processes must also be built.
- Identify structural and technical threats to supplied software
- Apply continuous and repeated security testing
- Confirm that identified risks have been resolved before the release of supplied software
- Secure monitoring and response capability after supplied software is released to the market
A record must be kept of the known vulnerabilities and newly discovered vulnerabilities identified for each open source software component, and of the actions taken.

(4) Internal Responsibility Assignment Procedure

The open source policy must address a procedure for internally assigning responsibility to resolve open source management issues.

The ISO standards commonly require a documented procedure for assigning internal responsibility as follows.

The open source program manager must identify license compliance issues and appropriately assign responsibility to the person in charge of each role to resolve them. Likewise, for open source security vulnerability issues, the person in charge of security identifies the issue and assigns responsibility to the appropriate personnel to resolve it.

To this end, a documented procedure for assigning internal responsibility can be reflected in the open source policy as in the example below.

4. Roles, Responsibilities, and Competencies
To ensure the policy is effective, the following defines the roles and responsibilities and the competencies the person in charge of each role must have.
(2) Open Source Program Manager
- Defines the roles necessary for open source license compliance and designates the responsible organization and person in charge of each role. Consults with the OSRB when necessary.
(6) Security Lead
- Assigns responsibility for each task so that open source security assurance can be carried out successfully.

Through this procedure, internal responsibility for open source license compliance and security assurance is clearly assigned, so that each person in charge can understand and perform their role. Consultation with theOSRB (Open Source Review Board) also helps maintain consistency with the organization’s overall open source strategy.

The internal responsibility assignment procedure must be reviewed and updated regularly, and must be able to be flexibly adjusted as the organization’s structure or projects change. This allows the efficiency and effectiveness of open source management to continuously improve.

(5) Responding to Non-Compliant Cases

An enterprise must document a procedure for promptly reviewing and responding to non-compliant cases in open source license compliance and security assurance.

ISO/IEC 5230 and ISO/IEC 18974 commonly require a documented procedure for reviewing and remediating non-compliant cases as follows.

To this end, an enterprise can reflect a documented procedure for reviewing and remediating non-compliant cases in the open source policy as in the example below.

6. Use of Open Source
(5) Compliance and Security Assurance Issue Response Procedure
When a license compliance or security assurance issue is raised, the open source program manager performs the following procedure to respond promptly:
1. Acknowledge receipt of the inquiry and specify a reasonable resolution time.
2. Confirm whether the issue content actually points to a real problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is a real problem, set a priority and decide on an appropriate response plan.
- For license compliance issues, consult with the legal lead to establish a plan for meeting license obligations.
- For security assurance issues, consult with the security lead to establish a plan for resolving the vulnerability.
4. Carry out the response and, if necessary, appropriately supplement the open source process.
5. Record and preserve the above using the issue tracking system.
6. Analyze the root cause of the non-compliant case and establish an improvement plan to prevent recurrence.
7. Report the non-compliant case and the response outcome to the OSRB (Open Source Review Board) and, if necessary, discuss ways to improve the policy and process.

Through this procedure, an enterprise can systematically manage non-compliant cases related to open source license compliance and security assurance, and pursue continuous improvement. In addition, using a standardized format such asSPDX to manage license and security information makes it possible to identify and respond to non-compliant cases even more effectively.

(6) Staffing and Budget Support

An enterprise must provide sufficient resources for the open source program to function smoothly. Personnel for each role in the program must be appropriately staffed, and adequate budget and working time must be guaranteed. If not, a procedure to compensate for this must be put in place.

The ISO standards commonly require that the personnel for each role in the program be properly staffed and that adequate funding be provided, as follows.

To this end, an enterprise can reflect content on staffing and budget support in the open source policy as in the example below:

4. Roles, Responsibilities, and Competencies
The head of the organization responsible for each role designates a person in charge within the organization and allocates adequate time and budget for that person to fully perform the role.
- If the person in charge of each role is not adequately supported while performing the role, they must raise the issue with the open source program manager.
- The open source program manager discusses the resolution with the relevant organization head. If not resolved adequately, the open source program manager may request the OSRB to resolve the issue.
- The OSRB shares the issue with the head of the higher organization and requests resolution.

In addition, an enterprise can strengthen staffing and budget support by considering the following:

1. Assign dedicated personnel to the open source program manager
2. Secure a budget for purchasing specialized tools for open source license compliance and security assurance
3. Set a budget for training and building the competency of program participants
4. Allocate a budget for consulting with outside experts
5. Establish a regular process for reviewing personnel and budget

Through this support, an enterprise can raise the effectiveness of its open source license compliance and security assurance program and meet the requirements ofISO/IEC 5230 andISO/IEC 18974.

(7) Providing Expert Advice

When the person in charge of each role needs a professional review to resolve an open source issue, the enterprise must provide a way to request advice for this.

The ISO standards commonly require a way to use internal or external professional advice to resolve issues, as follows.

For open source license compliance issues, the company’s internal legal team is the primary owner, and if an issue is contentious, an outside law firm with attorneys specializing in open source can be used.

For open source security vulnerability issues, the company’s internal security team is the primary owner, and if an issue is complex and contentious, advice can be requested from an outside security specialist firm.

To this end, an enterprise can reflect content on providing advice in the open source policy as in the example below.

4. Roles, Responsibilities, and Competencies
(4) Legal Lead
The legal lead provides advice on legal risks and mitigation measures that may arise in the course of using open source, such as interpreting open source licenses and obligations.
- Provides a reasonable way for program participants to inquire about open source license compliance issues.
- Provides advice on license and intellectual property issues, including conflicts caused by incompatible open source licenses.
- Reviews necessary legal matters, such as open source licenses and the CLA (Contributor License Agreement), when contributing to external open source projects.
- If an issue is contentious, requests advice from an outside law firm with attorneys specializing in open source.
(6) Security Lead
The security lead operates open source security vulnerability analysis tools and builds a system so that security vulnerability analysis is smoothly performed for all supplied software.
- Provides a reasonable way for program participants to inquire about known vulnerabilities or newly discovered vulnerabilities, and uses outside professional technical advice when necessary to resolve vulnerabilities.

For reference, theOpenChain Project provides, through its partner program, a list of global law firms that offer open source-related advice:https://www.openchainproject.org/partners

Law firms registered as OpenChain partners meet the requirements set by the OpenChain Project, and in South Korea,Bae, Kim & Lee LLC is the sole registrant.

(8) Specifying Scope of Application

A single open source policy (program) does not necessarily have to apply to the entire organization. The scope of application can be set differently depending on the characteristics of each organization and product within the enterprise. For example, an organization that does not deliver any supplied software at all can be excluded from the scope of the open source program.

The ISO standards commonly require a written statement that clearly defines the scope and limits of the program, as follows.

An enterprise must clearly define the scope and limits of the open source program in view of the characteristics of the organization and products, and state this in the open source policy.

Also, as the organizational structure, products, and services change to match the business environment, situations may arise where the scope of the program needs to be determined or revised. An enterprise must establish metrics for assessing scope, and perform reviews and inspections for continuous improvement to fix shortcomings.

To this end, an enterprise must have a system for clearly defining the scope of application in the open source policy and documenting the history of activities, as follows.

2. Scope of Application
This policy applies to the following three parts.
1. It applies to all supplied software the company provides or distributes externally. However, using open source solely for internal use is not within the scope of this policy.
2. It applies when program participants contribute to external open source projects.
3. It applies when releasing internal code as open source.
The scope of application can change to match the company's business environment. In particular, to ensure continuous effectiveness, the open source program manager investigates at least once a month whether there is any supplied software distributed or serviced externally that is not covered by this policy. If even one such case is found, this is used as the basis for determining that the scope of application must be changed.
The procedure for changing the scope of application is as follows.
1. When the open source program manager determines that a change to the policy's scope of application is needed due to changes in the company's business environment, such as a new business or reorganization, a proposal for this is submitted to the OSRB.
2. The OSRB approves an appropriate level of change to the scope of application.
3. The OSRB revises the open source policy to change the scope of the policy.
The open source program manager continuously documents the history of reviews, updates, and inspections performed at least once a month to improve the scope of application, using the [Jira](https://www.atlassian.com/software/jira) Issue Tracker.

Therefore, an enterprise must have a system for clearly defining the scope of application in the open source policy and documenting the history of activities, as shown above.

(9) Responding to External Inquiries

Customers and open source copyright holders sometimes contact an enterprise regarding open source-related inquiries, requests, and claims about supplied software developed using open source. The main content of external inquiries and requests is as follows:

• Inquiries about whether open source was used in a specific piece of supplied software
• Requests to provide source code under the GPL or LGPL licenses referenced in a written offer
• Requests to explain and disclose source code for open source found in supplied software but not listed in the open source notice
• Requests to provide missing files and build instructions for source code disclosed under obligations such as GPL and LGPL
• Requests for attribution
• Inquiries and requests related to open source security vulnerabilities

An enterprise must designate a person in charge of handling these external inquiries. This is typically the open source program manager.

There have been cases where an outside open source developer, wanting to discuss an open source-related issue with a specific enterprise, could not find a way to contact the enterprise’s representative and ended up filing a legal claim directly. To prevent this, an enterprise must always publicly disclose a way for third parties to make open source-related inquiries and requests to the enterprise.

The ISO standards commonly require a publicly available way for third parties to make open source inquiries, as follows:

The following ways can be provided so that outside parties can make open source-related inquiries to the enterprise:

1. Publish a representative email address for the organization in charge of open source.
2. Use theLinux Foundation’s Open Compliance Directory.
3. If the enterprise has an open source website, publish the email address through it.

Including and publishing the representative email address of the organization in charge of open source in the open source notice enclosed with supplied software is also a good approach.

An enterprise can reflect content on responding to external inquiries in the open source policy as in the example below:

9. Responding to External Inquiries
(1) Responsibility for Responding to External Inquiries
Responding to inquiries and requests about open source from external parties is the responsibility of the open source program manager.
- The open source program manager may assign all or part of the handling of an inquiry to an appropriate program participant within the company. Legal is consulted for handling when necessary.
- Any program participant who receives an external inquiry about open source must notify the open source program manager so a prompt response can be made.
(2) Publishing Contact Information
The open source program manager publicly provides the contact information of the person in charge so that external parties can make open source-related inquiries and requests.
- Provides contact email information in the open source notice.
- Provides email information on the open source website.
- Registers contact information in the Linux Foundation's Open Compliance Directory.
(3) External Inquiry Response Procedure
Responding to external open source inquiries promptly and accurately can greatly reduce the risk of claims or legal action. To this end, the company follows the external inquiry response procedure defined in the company's open source process for responding to external open source inquiries.

SK telecom includes an open source notice in all of its supplied software. The open source notice provides the address of the SK telecom open source website together with an email address for contacting the open source program office.

TheSK telecom open source website also provides an email address for contacting the open source program office.

(10) Open Source Contribution

Global software companies value not only using open source to build products and provide services, but also the strategic value that can be created by contributing to open source projects. However, approaching this without a sufficient understanding of and strategy for the open source project ecosystem and how communities operate can unexpectedly damage the company’s reputation and create legal risk. It is therefore important for an enterprise to establish a strategy and policy for participating in and contributing to open source projects.

ISO/IEC 5230 requires a documented open source contribution policy, as follows.

This policy on open source contribution can be found in7. Open Source Contribution of the [Appendix 1] open source policy sample.

7. Open Source Contribution
The company encourages participation and contribution to external open source projects to create business value from open source. However, this process requires care to avoid unintended exposure of the company's intellectual property or infringement of third-party rights. To this end, when a program participant of the company contributes to an external open source project, the following must be observed.
(1) Review Request and Approval
From a copyright standpoint, an open source contribution grants the open source project the right to modify, use, and distribute the work. In some cases, copyright must even be assigned to the open source project. Generally, the copyright of a work created during employment is owned by the employer. In other words, a work created by a program participant is owned by the company. A program participant contributing a work to open source on their own judgment can cause unnecessary copyright infringement issues.
Therefore, if there is an open source project you wish to contribute to, follow the review request and approval procedure before the first contribution, in accordance with the open source contribution process.
However, in the following simple cases, since the risk of copyright infringement is not significant, a program participant may contribute based on their own judgment without going through the review procedure.
- A small code snippet of 10 lines or fewer
- Questions/answers on Stack Overflow
- Administrative activity on GitHub: creating issues, reviewing/approving pull requests, etc.
...

The open source contribution policy must include the contribution procedure, approval process, measures for protecting intellectual property rights, and guidance on signing aCLA (Contributor License Agreement). It must also provide guidelines for behavior when program participants engage with the open source community on behalf of the company.

(11) SBOM Generation and Management

A procedure for generating and managing theSBOM (Software Bill of Materials) must be established:

• Select the SBOM generation tool and methodology
• Ensure the accuracy and completeness of SBOM information
• Establish an SBOM update and version management process
• Define a method for sharing and distributing the SBOM

An enterprise can reflect content on SBOM generation and management in the open source policy as in the example below:

6. Use of Open Source
(4) Generate the Software Bill of Materials (SBOM)
There must be a process to generate and maintain an SBOM (Software Bill of Materials) that includes the details of each open source software component making up the supplied software.
The company's open source process can use open source tools to generate and retain the SBOM.
- The SBOM is generated using a standard format such as [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/).
- An SBOM is generated and managed for all supplied software.
- The SBOM is updated and version-controlled with each release of the supplied software.
- The accuracy of SBOM information is periodically verified.
- Preparations are made to share the SBOM with customers and regulators when necessary.

SBOM generation and management are core elements of open source license compliance and security assurance. Through this, an enterprise can accurately understand the open source components in use and respond promptly to known vulnerabilities or license issues.

An enterprise must include these SBOM-related principles in its open source policy to build a systematic SBOM management system.

3. Summary

Documenting an open source policy is the single most important process for effective open source management.

The next page provides a sample open source policy document that meets the requirements of ISO/IEC 5230 and ISO/IEC 18974 mentioned above:[Appendix 1] Open Source Policy (template)

Referring to the content above, it is necessary to establish appropriate principles for each requirement that fit the company’s situation. It is also important to go beyond documentation alone and consider actionable procedures. A policy that is words alone is of no use.

An open source policy must include the following core elements:

1. Open source license compliance principles
2. Open source security assurance principles
3. Response to open source risk
4. Internal responsibility assignment procedure
5. Response to non-compliant cases
6. Staffing and budget support plan
7. Method of providing expert advice
8. Specification of the policy’s scope of application
9. External inquiry response procedure
10. Open source contribution guidelines
11. Method for generating and managing the SBOM (Software Bill of Materials)

Establishing and documenting an open source policy that includes these elements makes it possible to meet the key requirements of the ISO/IEC 5230 and ISO/IEC 18974 standards.

A policy must not stop at documentation alone; it must actually be implemented within the organization. This requires regular review and updates, along with training for program participants. An effective open source policy will help systematically manage the organization’s use of and contribution to open source, and minimize potential legal and security risks.

1. Purpose and Scope

1.1 Purpose

This policy provides principles and procedures for the Company to safely and effectively utilize open source software. The main objectives 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 satisfy relevant legal requirements.
2. Open Source Security Assurance:
   • Identify security vulnerabilities in open source components included in supplied software, and minimize security risk through appropriate response measures.
3. Contribution to External Open Source Projects:
   • Promote collaboration with the open source community by contributing to external open source projects, and protect the Company’s intellectual property.
4. Open Sourcing of Internal Projects:
   • Release internal projects as open source to enhance collaboration with the open source community and promote the Company’s technical capabilities.

These principles are designed to satisfy the requirements of ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance).

1.2 Impact of Non-Compliance

If the Company fails to comply with this policy, it may face the following risks:

• Legal Risk: The Company may receive external demands for open source license compliance, and may face litigation or fines.
• Reputational Damage: The Company’s reputation may be damaged due to source code disclosure obligations or security incidents.
• Business Loss: Relationships with customers or suppliers may deteriorate due to contract violations.
• Security Incidents: Serious security incidents may occur due to known vulnerabilities or newly discovered vulnerabilities.

1.3 How Program Participants Can Contribute

All program participants of the Company must understand and comply with this policy. Participants can contribute in the following ways:

• Perform the responsibilities and obligations defined in the policy according to their role.
• Complete education related to open source licenses and security, and apply it in practice.
• Report immediately if they discover an issue that impedes compliance with the policy.

1.4 Scope

This policy applies to all software projects that the Company develops, distributes, or uses. The main scope of application is as follows:

• 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 only for internal purposes may be subject to a separate review procedure to determine whether the policy applies.

The scope of the policy is reviewed and updated periodically according to changes in the Company’s business environment.

2. Definitions

This section defines the key terms used in the policy. These definitions are necessary to help clearly understand and apply the policy.

2.1 Key Terms

1. Open Source Software:
   • Software that satisfies the Open Source Definition defined by the Open Source Initiative or the Free Software Definition defined by the Free Software Foundation. This is software with a license that allows users to freely use, modify, and distribute the software.
2. SBOM (Software Bill of Materials):
   • A list of all components, libraries, and dependencies that make up a piece of software. This is like a software “bill of materials,” and is used to ensure transparency in the software supply chain and to identify potential security vulnerabilities and license-related issues.
3. Known Vulnerability:
   • A previously discovered, publicly available security vulnerability. This can be found in databases such as NVD and CVE.
4. Newly Discovered Vulnerability:
   • A new security vulnerability that had not previously been discovered. This may be discovered while software is in use, or reported by external researchers.
5. Security Assurance:
   • Confidence that a system satisfies the requirements for security best practices and is resilient against known vulnerabilities.
6. Verification Material:
   • Material demonstrating that a given requirement of a specification has been satisfied. This may be provided in various forms such as documents, records, and test results.
7. Supplied Software:
   • All software that an organization provides or distributes to a third party.
8. Program:
   • The set of policies, processes, and personnel that make up an organization’s open source license compliance and security assurance activities.
9. Program Participant:
   • Any member of the organization or contractor responsible for defining, contributing to, or preparing supplied software. This includes software developers, release engineers, quality engineers, product marketing, and product managers.
10. Compliance Artifact:
    • Represents the output of an open source license compliance program, and is the collection of deliverables that must be provided along with supplied software. This includes attribution notices, source code, copies of licenses, copyright notices, notices of modification, and Written Offers.
11. Identified License:
    • The set of open source licenses identified by an appropriate method for identifying the open source components included in supplied software.

3. Roles and Responsibilities

This section defines the key roles and responsibilities related to open source software management. Each role is essential to ensuring the organization’s open source license compliance and security assurance.

3.1 Role Descriptions

1. Open Source Program Manager (OSPM)
   • Responsibility: Overall responsibility for the Company’s open source program.
   • Key Duties:
     • Manage open source license compliance and security assurance activities.
     • Create and maintain the SBOM.
     • Respond to external inquiries related to open source.
     • Manage internal best practices.
   • Required Competencies: Understanding of software development processes, expertise in open source licenses, communication skills.
2. Legal
   • Responsibility: Assess legal risk related to open source licenses and provide advice.
   • Key Duties:
     • Interpret and review open source license obligations.
     • Review license compatibility and provide advice on intellectual property protection.
   • Required Competencies: Expertise in software copyright, expertise in open source licenses, ability to assess legal risk.
3. IT
   • Responsibility: Operate and automate open source analysis tools.
   • Key Duties:
     • Operate open source analysis tools and integrate them into the DevOps environment.
     • Create and maintain the SBOM.
   • Required Competencies: Expertise in IT infrastructure, understanding of open source analysis tools, understanding of CI/CD pipelines.
4. Security
   • Responsibility: Operate open source security vulnerability analysis tools.
   • Key Duties:
     • Respond to known vulnerabilities and newly discovered vulnerabilities.
     • Integrate into the DevSecOps environment and perform security measures.
   • Required Competencies: Understanding of DevSecOps, understanding of security vulnerability analysis tools, ability to assess and manage risk.
5. Developer Culture
   • Responsibility: Support in-house developers in actively utilizing open source.
   • Key Duties:
     • Encourage participation in the open source community and improve developer culture.
     • Support external contribution activities.
   • Required Competencies: Understanding of software development processes, ability to design education, experience with community engagement.
6. Quality
   • Responsibility: Verify open source license obligations when distributing supplied software.
   • Key Duties:
     • Verify the creation of compliance artifacts.
     • Review compliance with license obligations before distribution.
   • Required Competencies: Understanding of software development processes, basic knowledge of compliance.
7. OSRB (Open Source Review Board)
   • Responsibility: Establish and improve policies and processes for open source management.
   • Key Duties:
     • Periodically review and improve the policy.
     • Discuss key issues and develop resolutions.
   • Required Competencies: Expertise in policy development, experience operating a governance body.
8. OSPO (Open Source Program Office)
   • Responsibility: Support contributions to external open source projects and the release of internal projects.
   • Key Duties:
     • Provide guidance for external contributions.
     • Manage the release procedure for internal projects.
   • Required Competencies: Experience with community engagement, project management skills.

3.2 Staffing and Funding

1. Appropriate staffing:
   • Assign appropriate personnel with the necessary competencies and expertise for each role.
   • The head of each department must designate a suitable person to perform the role.
2. Sufficient funding:
   • The Company provides sufficient budget and resources necessary to perform each role.
   • Budget items include education, tool licensing fees, and external consulting costs.
3. Periodic review:
   • The OSRB reviews the staffing and funding status of each role at least once a year, and recommends adjustments as needed.
   • The review results are documented and reported to the OSPO (Open Source Program Office).
4. Issue resolution procedure:
   • If a department’s person in charge lacks the necessary support (personnel or funding), they must immediately report this to the OSPM.
   • The OSPM works with the relevant departments to resolve the issue, and requests the OSRB to resolve the issue if necessary.

3.3 Internal Responsibility Assignment Procedure

1. Responsibility assignment procedure:

   a. The OSPM convenes an annual responsibility assignment meeting.

   b. Consults with each department head (Legal, IT, Security, Development, Quality, etc.) to select a person responsible for each activity.

   c. Submits the list of selected persons responsible to the OSRB (Open Source Review Board) for final approval.

2. Balance of responsibility and authority:

   • Each person responsible is granted appropriate authority necessary to perform the relevant duties.
   • They have the authority to request the resources (e.g., budget, personnel) necessary to fulfill their responsibilities.

3. Periodic review and updates:

   • The OSRB reviews the status of responsibility assignments at least once a year and makes adjustments as needed.
   • Responsibility assignments are updated immediately whenever there is a major change, such as an organizational restructuring or personnel change.

4. Documentation:

   • The results of responsibility assignment are recorded as an official document and registered in the Company’s document management system.
   • The document specifies each activity, the person responsible, their role, and the required competencies.

5. Education and awareness:

   • Provide necessary education to newly assigned persons responsible.
   • Share the results of responsibility assignment with the entire organization to raise awareness.

3.4 Current Assignees

The organization and person responsible for each role can be found in [Appendix A: Current Assignees]. The list is updated as needed.

4. Open Source License Compliance

This section describes the procedures for complying with the license obligations of open source components included in supplied software. Through this, the Company can ensure open source license compliance and minimize legal risk.

4.1 Open Source Identification and License Obligation Review

1. Open Source Identification:
   • Identify all open source components used when developing supplied software.
   • Use SCA (Software Composition Analysis) tools to automatically detect and record open source components.
2. License Obligation Review:
   • Review the licenses of identified open source components and confirm the obligations required by each license.
   • Refer to the Company’s [Open Source License Guide] to understand licenses, and work with the Legal team to resolve compatibility issues.

4.2 Design Considering Open Source Licenses

1. Software Architecture Design:
   • Design the software architecture to minimize the impact of open source licenses.
   • Identify the coupling relationship between open source components and the Company’s own code to comply with license obligations.
2. License Compatibility Review:
   • Review whether the licenses of multiple open source components are compatible with each other.
   • If incompatible licenses are used, propose alternative components or take appropriate action.

4.3 Creating and Managing Compliance Artifacts

1. Creating Open Source Notices:
   • Prepare a notice containing the copyright information and licenses of the open source components included in supplied software.
   • The notice is prepared according to the conditions required by each license, and is included in the distribution package.
2. Creating Source Code Packages for Disclosure:
   • Create the source code packages necessary to comply with licenses that require source code disclosure, such as GPL and LGPL.
   • Source code packages are securely stored in a separate repository and provided upon external request.
3. Distribution and Storage of Compliance Artifacts:
   • All compliance artifacts are distributed together with supplied software and systematically managed in an internal repository.
   • Operate a system that can provide artifacts upon external request.

4.4 Creating and Managing the SBOM

1. Creating the SBOM:
   • Create the SBOM (Software Bill of Materials) for all open source components that make up supplied software.
   • The SBOM includes the name, version, license information, and download location of each component.
2. Maintaining and Updating the SBOM:
   • The SBOM is updated with each software release and kept up to date.
   • The SBOM is securely managed in an internal repository and prepared to be provided upon external request.
3. Managing Open Source Component Records:

   • Maintain detailed records for each open source component. These records include the following information:

     a. Component identification information (name, version, source)

     b. License information and obligations

     c. Purpose and manner of use

     d. Whether modified and details of modifications

     e. Vulnerability analysis results and response measures

   • These records are periodically reviewed and updated, and managed according to documented procedures.

4. Record Verification Procedure:
   • Verify the accuracy and completeness of open source component records quarterly.
   • Verification results are documented and stored, and improvement measures are taken as needed.

4.5 Compliance Issue Response Procedure

1. Issue Identification and Response:
   • When a compliance issue occurs, the OSPM immediately identifies the issue and develops a response plan.
   • Works with the Legal team to assess the severity of the issue and determine the necessary action.
2. Maintaining Response Records:
   • All response processes are recorded and preserved through Jira or another issue tracking system.
   • Response records are periodically reviewed and used as reference material in the event of a similar problem in the future.

5. Open Source Security Assurance

This section describes the procedures for ensuring the security of open source components included in supplied software. Through this, the Company can effectively manage known vulnerabilities and newly discovered vulnerabilities, and raise the security level of its software.

5.1 Known Vulnerability Detection and Response Procedure

1. Vulnerability Detection:
   • Use SCA (Software Composition Analysis) tools to detect known vulnerabilities in each open source component included in the SBOM.
   • Regularly update vulnerability databases such as the NVD (National Vulnerability Database) and CVE (Common Vulnerabilities and Exposures) to check the latest information.
2. Vulnerability Severity Assessment:
   • Assess the severity of a vulnerability using its CVSS (Common Vulnerability Scoring System) score.
   • Determine response priority considering the exploitability of the vulnerability, its scope of impact, and its potential impact on the system.
3. Response Measures:
   • Immediately apply a patch or take mitigation measures for high-risk vulnerabilities.
   • If customers may be affected, notify customers and present a resolution plan.
4. Maintaining Response Records:
   • All vulnerabilities and response measures are recorded in a database, and reports are generated periodically.
   • Response records are used as reference material in the event of a similar problem in the future.

5.2 Newly Discovered Vulnerability Response Procedure

1. Detecting Newly Discovered Vulnerabilities:
   • Identify and assess new security vulnerabilities that had not previously been discovered.
   • Newly discovered vulnerabilities may be reported by external researchers or through internal testing.
2. Severity Assessment and Response:
   • Assess the severity of a newly discovered vulnerability using its CVSS score.
   • Determine response priority based on the assessment results and take necessary action.
   • If customers may be affected, notify customers and present a resolution plan.
3. Maintaining Response Records:
   • Newly discovered vulnerabilities and response measures are recorded in a database, and reports are generated periodically.

5.3 Continuous Monitoring and Response

1. Vulnerability Monitoring:
   • Continuously monitor software even after release to identify known vulnerabilities or newly discovered vulnerabilities.
   • Use automated tools to detect anomalies based on the latest data.
2. Response Preparation:
   • Security experts prepare the response, and receive assistance from external experts as needed.
   • The response plan is periodically reviewed and updated.
3. Reporting and Improvement:
   • All monitoring and response activities are reported periodically and shared with program participants.
   • Improve processes based on monitoring results to continuously enhance the security level.

5.4 Alignment with Internal Best Practices

1. Investigating Internal Best Practices:
   • Investigate security-related activities and processes that are successfully operated by other teams or departments within the Company.
   • Example: the information security team’s vulnerability management process, the development team’s secure coding guidelines, etc.
2. Comparing and Analyzing Processes:
   • Compare and analyze how the investigated best practices operate relative to the open source security assurance program.
   • Identify differences, weaknesses, and opportunities for improvement.
3. Integrating and Improving Processes:
   • Adjust or integrate the open source security assurance program to align with the Company’s internal best practices.
   • Example: applying the company-wide vulnerability management system to open source vulnerability management as well.
4. Assigning and Managing Responsibility:
   • The OSPM is responsible for compliance with internal best practices, and periodically reviews the operating approach and proposes improvements.

6. Education and Awareness

This section describes the education and awareness activities necessary to ensure the competency and awareness of program participants. Through this, participants can fully understand the open source policy, the goals of the related program, and their own roles and responsibilities, and raise their awareness of open source license compliance and security assurance.

6.1 Open Source Education

1. Education Objectives:
   • Help program participants use open source correctly, and understand and apply license compliance and security assurance procedures in practice.
   • Key education content:
     • The purpose and principles of the open source policy.
     • License obligations and compliance procedures.
     • How to create and use the SBOM.
     • Procedures for managing known vulnerabilities and newly discovered vulnerabilities.
2. Education Methods:
   • Completed through online courses provided on the [Learning Portal].
   • Additional education is provided in workshop or seminar format as needed.
   • Case-based learning is used to strengthen the ability to solve real-world problems.

6.2 Competency Assessment

1. Assessment Criteria:
   • Assess the competencies required for each role.
   • Assessment items:
     • Understanding of the open source policy.
     • Ability to perform compliance procedures.
     • Ability to manage security vulnerabilities.
2. Assessment Methods:
   • Measure participants’ competency through periodic tests and practical evaluations.
   • Assessment results are reflected in individual performance records, and additional education is provided as needed.

6.3 Awareness-Raising Activities

1. Periodic Newsletters and Workshops:
   • Share the latest open source trends and policy changes through a periodic newsletter.
   • Raise program participants’ understanding and promote collaboration through workshops and seminars.
2. Use of Communication Channels:
   • Share open source-related information through internal communication channels (e.g., email, internal portal).
   • Encourage collaboration and information exchange among program participants.

6.4 Record Retention

1. Education and Assessment Records:
   • All education completion records and assessment results are retained for at least 3 years.
   • This allows the Company to demonstrate that program participants have a sufficient understanding of the policy and processes.
2. Periodic Review and Updates:
   • The OSPM reviews the education content and assessment methods at least once a year and updates them as needed to reflect the latest open source trends and the organization’s requirements.

6.5 Identifying and Utilizing Expertise

1. Identifying Required Areas of Expertise:
   • Periodically identify the technical and legal areas of expertise necessary to operate the program.
   • Example: web security, cryptography, network security, systems administration, open source license interpretation, etc.
2. Preparing and Updating a List of Internal Experts:
   • Prepare a list of personnel with expertise in the relevant field within the Company, and update it periodically.
   • Record each expert’s career history, certifications, and contact information.
3. Establishing a Plan to Secure External Resources:
   • Establish a plan to utilize external experts or consulting firms for problems that are difficult to resolve internally.
   • Secure reliable external resources and clearly define contract terms.
4. Establishing a Procedure for Accessing Expertise:
   • Establish a procedure so that program participants can easily access the expertise they need.
   • Example: how to consult an internal expert, how to utilize an external consulting firm, etc.

7. Contribution to External Open Source Projects

This section describes the procedures and principles that the Company’s program participants must follow when contributing to external open source projects. Through this, the Company can actively participate in external open source projects while preventing intellectual property and copyright issues.

7.1 Contribution Procedure

1. Review Request and Approval:
   • To contribute to an external open source project, a program participant must obtain review and approval from the OSPO (Open Source Program Office).
   • The OSPO confirms that the code to be contributed does not infringe on the Company’s intellectual property, and requests review by the Legal team as needed.
2. Contribute Only Code You Have the Right to Contribute:
   • Program participants may only contribute code they have written themselves or code owned by the Company.
   • Third-party code must not be contributed without authorization.
3. Caution Regarding Exposure of Intellectual Property:
   • Take care not to include sensitive information, patents, or other Company intellectual property.
   • If the code to be contributed includes a Company patent, it must be reviewed by the OSPO and the Legal team.

7.2 Caution Regarding CLA Signing

1. CLA Review:
   • Some open source projects require contributors to sign a CLA (Contributor License Agreement).
   • Before signing a CLA, request a review from the OSPO to ensure protection of the Company’s intellectual property.
2. Prohibition on Copyright Assignment:
   • To protect its own intellectual property, the Company does not permit contributions to open source projects whose CLA terms require copyright assignment.

7.3 Copyright Notice

1. Copyright Notation:

   • When a program participant contributes code to an external open source project, the Company’s copyright must be clearly stated.

   • State the copyright and license at the top of the file as follows:

     textCopyright (c) [Year] [Company Name] SPDX-License-Identifier: [SPDX_license_name]

2. Use of Company Email:

   • When contributing to an open source project, use the Company email rather than a personal email.
   • This instills a sense of responsibility for communicating with the community on behalf of the Company.

7.4 Maintaining Contribution Records

1. Managing Contribution History:
   • Manage the entire history of contributions to external open source projects, and report it to the OSPO.
   • Contribution history is retained in an internal system (e.g., the Learning Portal) for at least 3 years.
2. Assessing Contribution Activities:
   • Contribution activities to external open source projects are reflected in program participants’ performance evaluations.
   • The OSPO periodically assesses the effectiveness of contribution activities and proposes improvement measures as needed.

8. Releasing Internal Projects as Open Source

This section describes the procedures and principles for releasing internal projects as open source. Through this, the Company can promote collaboration with the open source community, protect its intellectual property, and minimize legal risk.

8.1 Approval Procedure

1. Review and Approval:
   • To release an internal project as open source, review and approval must be obtained from the OSPO (Open Source Program Office).
   • The OSPO confirms that the code to be released does not infringe on the Company’s intellectual property, and requests review by the Legal team as needed.
2. Intellectual Property Protection:
   • Take care not to include sensitive information, patents, or other Company intellectual property.
   • For code that includes a patent, work with the Legal team to confirm whether it can be released.
3. Copyright Notice:
   • State the Company’s copyright in the code being released.
   • Example: “Copyright (c) [Year] [Company Name]”

8.2 Release Preparation

1. Code Preparation:
   • Organize and document the code to be released so it can be used externally.
   • Verify the origin of the code, and delete or modify any code that poses a potential problem.
2. Choosing an Open Source License:
   • Select an appropriate open source license under which to release the code.
   • When choosing a license, consider protection of the Company’s intellectual property and the needs of the community.
3. Securing Resources:
   • Secure the infrastructure and budget necessary to maintain and manage the project.
   • Use a project hosting platform such as GitHub to maintain transparency.

8.3 Post-Release Management

1. Community Management:
   • Collect community feedback on the released project and respond appropriately.
   • The OSPO manages the relationship with the community and actively accepts external contributions.
2. Ongoing Maintenance:
   • The released project is continuously maintained, with bug fixes and feature improvements.
   • Quality is ensured through code review, and the project collaborates with external contributors.
3. Use of Company Email:
   • Use the Company email rather than a personal email during open source activities, to maintain the Company’s representation.

8.4 Record Retention

1. Retaining Release Records:
   • All records related to a released project are retained for at least 3 years.
   • Records include the approval procedure, code versions, and community feedback.
2. Periodic Review and Updates:
   • Released projects are periodically reviewed and updated as needed.
   • Continuously improved to reflect the latest open source trends and organizational requirements.

9. Responding to External Inquiries

This section describes the procedure by which the Company responds quickly and effectively when there is an external open source-related inquiry or request, particularly one related to open source license compliance and open source security vulnerabilities. Through this, the Company can appropriately respond to external demands, minimize legal risk, and promote collaboration with the open source community.

9.1 Responsibility for Responding to External Inquiries

1. Designating the Person Responsible:
   • Responding to external open source-related inquiries and requests is handled by theOSPM.
   • As needed, works with the Legal team (for license compliance matters) or the Security team (for security vulnerability matters) to resolve the issue.
2. Inquiry Escalation Procedure:
   • Any program participant who receives an external open source-related inquiry must immediately forward it to theOSPM.
   • Depending on the nature of the inquiry, it is promptly assigned to the department responsible for license compliance or security vulnerabilities.

9.2 Publishing Contact Information

1. Public Contact Information:
   • The official contact information for theOSPM is made publicly available.
   • The contact information is registered on the following channels:
     • The open source notice
     • The Company website
     • The Linux Foundation’s Open Compliance Directory
2. Guidance on How to Make Inquiries:
   • Clearly explain how external parties can make open source-related inquiries.
   • Operate a system that can accept inquiries by email address, website inquiry form, and other means.

9.3 External Inquiry Response Procedure

1. Receiving and Confirming the Inquiry:
   • When an external inquiry is received, theOSPM immediately confirms it and specifies an appropriate resolution time.
   • Reviews the nature of the inquiry and classifies it as a license compliance or security vulnerability matter.
     • License compliance: reviewed and addressed in cooperation with the Legal team.
     • Security vulnerability: assessed for severity and addressed in cooperation with the Security team.
2. Carrying Out the Response:
   • Take appropriate response measures according to the content of the inquiry, and receive assistance from external experts as needed.
   • All response processes are recorded through an internal system (e.g., Jira Tracker).
3. Providing Feedback and Improving:
   • After responding, provide feedback to the external inquirer, and propose improvement measures as needed.
   • Analyze response records and improve processes to prevent recurring problems.

10. Measuring and Improving Program Effectiveness

This section describes the procedure for measuring and continuously improving the effectiveness of the open source program. Through this, the Company can evaluate and improve the performance of its open source license compliance and security assurance program.

10.1 Defining Performance Indicators

1. List of Performance Indicators:
   • Number of supplied software analyzed.
   • Number of known vulnerabilities and newly discovered vulnerabilities resolved.
   • Number of compliance artifacts created and distributed.
   • Response time for external inquiries.
   • Education completion rate of program participants.
   • Number of external open source contributions and released projects.
2. Setting Indicator Targets:
   • Set target values for each indicator so that the program’s performance can be evaluated.
   • Target values are set in line with the organization’s business goals and the program’s objectives.

10.2 Periodic Program Assessment

1. Assessment Cycle:
   • Conduct a program assessment at least once a year.
   • Conduct additional assessments as needed when there is a change in the business environment or a major issue occurs.
2. Assessment Procedure:
   • Document the assessment results and report them to the OSRB (Open Source Review Board).
   • Collect and reflect feedback from program participants during the assessment process.
   • Assessment results are recorded and preserved through an internal system (e.g., Jira Issue Tracker).
3. Periodic Policy Review and Renewal:
   • The policy is periodically reviewed and, if necessary, renewed to reflect the latest open source trends and the organization’s requirements.
   • This continuously improves the effectiveness of the program.

10.3 Continuous Improvement Plan

1. Identifying Areas for Improvement:
   • Identify areas that need improvement based on assessment results, and set priorities.
   • Areas needing improvement may include process efficiency, education content, response time, and more.
2. Setting Improvement Targets:
   • Set specific improvement targets and schedules.
   • The progress of improvement activities is monitored and documented.
3. Reflecting Improvement Results:
   • Reflect improvement results in the next assessment cycle to continuously enhance the program’s effectiveness.
   • Improvement results are shared with program participants to encourage continued commitment to improvement.

10.4 Integrating and Improving Internal Best Practices

1. Planning Integration Activities:
   • Identify the gaps between internal best practices and the open source security assurance program, and establish an integration plan based on this.
   • Example: integrating vulnerability management systems, standardizing code review procedures.
2. Periodic Review and Updates:
   • Review the alignment between internal best practices and the open source program at least once a year, and reflect improvements as needed.
   • The review results are reported to the OSRB (Open Source Review Board).

10.5 Assessing Personnel and Resources

1. Assessment cycle:
   • The Company assesses the staffing and funding status for each role at least once a year.
   • Assessment results are reported to the OSRB, and improvements are implemented as needed.
2. Assessment items:
   • Whether appropriate personnel have been assigned for each role.
   • Whether sufficient budget has been provided to perform each role.
   • Cases of problems caused by insufficient support, and their resolutions.
3. Establishing an improvement plan:
   • Establish a specific plan to supplement insufficient personnel or resources based on the assessment results.
   • The improvement plan is implemented upon approval by the OSRB.

11. ISO Standard Compliance Declaration and Maintenance

This section describes the procedure by which the Company complies with and maintains the requirements of ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance). Through this, the Company can ensure the continuous improvement of its open source program and compliance with the standards.

11.1 ISO Standard Compliance Declaration

1. Compliance Declaration:
   • Through this policy, the Company declares that it satisfies all the requirements of ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance).
   • The date of declaration and validity period (18 months) are clearly stated.
   • The compliance declaration may be made through Self Certification under the Linux Foundation’s OpenChain project.
2. Documenting Evidence:
   • The OSPM documents and maintains evidence of satisfaction for each requirement.
   • Evidence documents include policy documents, process descriptions, education records, compliance artifacts, and security vulnerability management records.
   • All evidence documents are stored in a central repository and retained for at least 3 years.
   • This document must be prepared within 18 months after undergoing conformance verification, and is renewed at least once a year.
3. Periodic Review and Renewal:
   • The OSRB reviews whether the requirements are satisfied at least once a year, and improves the policy and processes as needed.
   • The review results and improvements are documented and stored.
4. Preparing for External Verification:
   • Prepare to provide evidence documents to external auditors or certification bodies upon request.

11.2 Maintaining Compliance Status

1. Periodic Review:
   • The OSRB conducts an internal review of all the requirements of ISO/IEC 5230 and ISO/IEC 18974 at least once a year.
   • The review results are documented and stored, and an improvement plan is established for any items not satisfied.
2. Periodic Internal Audit:
   • Internal audits assess whether program participants are performing their roles, whether compliance artifacts are adequate, and the effectiveness of security assurance activities.
   • Based on the audit results, areas for improvement are identified and necessary action is taken.
3. Providing Education and Training:
   • Provide periodic education and training to continuously improve the competency and awareness of program participants.
   • Education content reflects the latest open source trends and the organization’s requirements, and emphasizes compliance with ISO standards.
4. Preparing to Respond to External Inquiries:
   • Maintain a system that can respond quickly and effectively to external inquiries related to ISO standard compliance.
   • Inquiry response is handled by the OSPM, who works with the Legal team as needed.
5. Periodic Policy Renewal:
   • The policy is reviewed at least once a year, and renewed to reflect the latest open source trends and the organization’s requirements.
   • The renewed policy is shared with all program participants.

Appendix 1. Personnel Assignments

1. Clause Overview

Without an AI SBOM policy, an organization ends up deploying AI systems while developers remain unaware of the licensing obligations attached to models and datasets. In AI, what needs to be tracked goes beyond code. Model weights, training datasets, and the model tree derived from other models each carry their own license, and non-standard licenses that restrict the purpose of use — such as the Llama Community License or the RAIL family — are common. Missing these obligations leads to copyright disputes, violations of usage restrictions, and terminated business contracts.

To prevent this risk, 3.1 requires establishing a documented policy that governs AI SBOM compliance and communicating it so that program participants are aware of its existence. This policy must reflect business strategy, the legal requirements of relevant jurisdictions, and the level of risk appropriate to the use case. All subsequent clauses (competence, license obligations, AI SBOM, governance, and so on) operate on top of this policy.

2. Activities to Perform

• Draft and formalize a policy document that governs AI SBOM compliance.
• Define the scope of application in the policy (AI systems deployed externally, external models/datasets brought in, internal models released publicly, etc.).
• Reflect business strategy, the legal requirements of relevant jurisdictions, and the risk level for each use case in the policy.
• Include in the policy a list of licenses allowed or prohibited for models and datasets.([Guide Recommendation] Because compliance with non-standard licenses is hard to track automatically after the fact, decide it through policy at intake time.)
• Establish and document a procedure for communicating the policy to program participants (development, legal, security, data staff, etc.).
• Retain records that prove the policy was communicated (training completion, notice history, etc.).
• Include in the policy a procedure for periodically reviewing it and re-communicating it when it changes.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.1.1 Documented AI SBOM Policy

How to Comply

The AI SBOM policy is a formal document that captures the principles and procedures by which the organization manages the licensing and transparency obligations of its AI systems. The policy should include its purpose, scope, roles and responsibilities, principles for reviewing model and dataset licenses, AI SBOM management, how transparency obligations are addressed, and the review cycle. Because this document itself is verification material 3.1.1, manage it as a formal document with recorded version and approval history.

For an organization that already has an ISO/IEC 5230 open source policy, it is more efficient to add an AI-related section to the existing policy than to create a separate new one. Add that models and datasets fall within the scope of license review, how non-standard licenses are handled, and what format is used to manage the AI SBOM.

A policy is not a document to be written once and left alone. Because the AI regulatory landscape changes quickly, conduct a periodic review at least once a year and record the change history.

Considerations

• State the AI-specific scope explicitly: Clearly state in the policy that license review covers not only code but also model weights, training/testing/validation datasets, and the derivation relationships in the model tree.
• Allowed/prohibited license lists: Divide model and dataset licenses into allowed and prohibited lists, based on whether commercial use is permitted and whether there are behavioral use restrictions, and set this in the policy in advance.([Guide Recommendation])
• Approval procedure: Have the legal team or the AI governance lead give final approval, and record the approval date and approver.
• Version control: Maintain the document version and change history so that previous versions can be compared during an audit.
• Periodic review: Review at least once a year, and record the review completion date and reviewer.

Sample

Below is a sample of the scope of application and the allowed/prohibited license lists for an AI SBOM policy. This text becomes a core component of verification material 3.1.1. Check the actual terms of each license against its original text, then classify it to fit the organization’s use case.

## 1. Purpose and Scope
This policy defines the compliance principles and procedures for the company to
develop and deploy AI systems safely and responsibly. It is designed to satisfy
the requirements of ISO/IEC 5230 (open source license compliance) and the
OpenChain AI SBOM Compliance Guide.
Scope:
- All AI systems, models, and services distributed externally.
- Pre-trained models and datasets brought in from outside.
- Activities that release internal models to the outside.
## 2. Model/Dataset License Classification
Licenses for models and datasets being brought in are reviewed against the
classification below. A license not in this classification goes through review
by the AI governance lead before being brought in.
- Allowed (commercial use permitted, no behavioral restrictions): Apache-2.0, MIT, BSD, CC-BY-4.0, etc.
- Conditionally allowed (use after review): licenses with restrictions on purpose or
scale of use, such as the Llama Community License, the Gemma Terms of Use,
and the OpenRAIL family
- Prohibited (non-commercial only, etc.): using a CC-BY-NC dataset in a commercial product, etc.

3.1.2 Policy Awareness Procedure

How to Comply

Writing the policy document alone is not enough. A communication procedure must be established and documented so that program participants actually become aware the policy exists. This communication procedure document itself is verification material 3.1.2. Because AI systems involve not just developers but also data staff, legal, and security, design the channel so the policy reaches all of them.

Include AI SBOM policy guidance in onboarding for new hires, and use internal wiki postings and email notices for existing employees. To prove that the policy was communicated, retain evidence such as notice history and training completion records for at least three years.

Considerations

• Use multiple channels: Use two or more channels, such as an internal wiki, email notices, and onboarding training.
• Include AI-related roles: Include dataset owners and model operators as recipients as well.
• When the policy changes: Have a separate procedure to notify participants of changes immediately.
• Retain evidence: Keep notice history and training completion certificates for at least three years.

Sample

Below is a sample policy communication notice email. Retaining the send history serves as evidence for verification material 3.1.2.

Subject: [AI Compliance] AI SBOM Policy Notice and Acknowledgment Request
To: Employees involved in AI system development, operations, and data
From: AI Compliance Officer
Hello,
Our AI SBOM compliance policy has been established (or revised).
All employees involved in using, bringing in, or deploying AI models and
datasets are asked to review and familiarize themselves with the policy
document below.
- Policy document: [internal portal link]
- Key contents: model/dataset license classification, license obligation
review procedure, AI SBOM management, transparency obligation response
- Policy version: v1.0 (effective date: YYYY-MM-DD)
Contact: AI Compliance Officer (ai-compliance@company.com)

5. References

• License obligation review procedure:3.5 License Obligations
• Basic structure of an open source policy:ISO/IEC 5230 Compliance Guide — 3.1.1 Policy
• AI license management strategy:Enterprise Open Source Management Guide — AI Compliance