ISO Standard-Based Enterprise Open Source Management Guide

• 1: 1. Organization
• 2: 2. Policy
• 3: 3. Process
• 4: 4. Tools
• 5: 5. Education
• 6: 6. Conformance

1 - 1. Organization

First, companies need to establish an organization responsible for managing open source.

The following should be considered when organizing:

• Roles and responsibilities of the organization
• Required competencies for each role
• The organization/person in charge of each role

1. Defining the roles and responsibilities of the organization

ISO standards commonly require a document describing the roles and responsibilities of various participants in the program.

Open Source Program Manager

To build an open source management system, you first need a person responsible for it. This person is called the Open Source Program Manager or Open Source Compliance Officer, and here we use the term Open Source Program Manager.

The Open Source Program Manager is in charge of the company’s Open Source Program Office. The Open Source Program Office refers to the organization responsible for managing the company’s open source, and is also referred to as the Open Source Office.

A person with the following competencies may be suitable for the role of open source program manager.

• Understanding of the open source ecosystem and development experience
• Broad understanding of the company’s business
• Passion and communication skills to propagate effective open source utilization to company members

It is best to ensure that the Open Source Program Manager can perform the role full-time if possible.

Global ICT companies are striving to hire excellent Open Source Program Managers. You can check various job postings on the following site: https://github.com/todogroup/job-descriptions

Documenting roles and responsibilities

Companies need to define the roles needed for the Open Source Program Office and determine what responsibilities to assign.

In the case of small companies, it is possible for the Open Source Program Manager to perform all roles alone. Depending on the size of the company, there may also be a need for an IT officer to operate open source tools, and the role of a legal officer may be required to provide professional legal advice.

Generally, the following roles are needed to build a company’s open source management system.

• Legal officer
• IT officer
• Security officer
• Development culture officer

For this, companies should document the roles and responsibilities of the Open Source Program Office as follows.

2. Definition of Required Competencies

Once you have defined each role and its responsibilities, you need to identify what essential competencies are required for the personnel to perform that role.

The ISO standard commonly requires a document that describes the competencies needed for each role.

This is to evaluate whether the person in charge of each role has the ability to perform that role, and to provide education if necessary.

For this, companies should document the competencies needed for each role as follows:

3. Appointment of Responsible Person

The Open Source Program Manager consults with the relevant departments to appoint a person in charge for each role and documents it. Of course, to do this, you need to report the goals and directions for establishing an open source compliance system to the CEO or other top decision-makers and receive the necessary support.

The organization and person in charge of open source do not necessarily have to participate in open source work full-time. It is also possible to form a virtual organization in the form of an OSRB (Open Source Review Board) to perform the necessary roles.

For this, the ISO standard commonly requires a document that lists the names of the persons, groups, or functions in the program roles.

For this, companies should document the names of the persons, groups, or functions in the program roles as follows:

You can refer to the sample that documented the roles, responsibilities, required competencies, and appointment of responsible persons in the next page. [Appendix 1] Open Source Policy template - Appendix 1. Status of Responsible Persons

SK Telecom has formed an OSRB to create open source policies and processes within the company, and collaborates to develop countermeasures when issues arise.

Summary

You can check the sample that documented the roles, responsibilities, required competencies, and appointment of responsible persons in the Open Source Policy template: Appendix 1. Status of Responsible Persons

Companies can refer to this to form an open source management organization suitable for their situation.

By designating and documenting the open source program office organization in this way, you will meet the requirements marked in red in the ISO standard specification.

In fact, it is more important to appoint a person who will faithfully perform the actual work and support the person in charge to secure the competency than to document it.

2 - 2. Policy

1. Open Source Policy Documentation

Enterprises should establish and document an open source policy, which consists of principles for organizations involved in software development, service, and distribution to properly utilize open source. This policy should be disseminated within the organization.

For this, the ISO standard commonly requires the following documented open source (security assurance) policies:

A typical open source policy includes the following. Enterprises should create and document an open source policy that includes these principles:

• Principles to minimize license and security vulnerability risks when distributing software products and services
• Principles for contributing to external open source communities
• Principles for releasing the company’s software as open source

2. Contents to be Covered in Open Source Policy

Let’s take a closer look at what an open source policy should include.

Open Source Risk Response

When developing products/services using open source, the policy should include the following principles to minimize license and security vulnerability risks:

1. Identification of open source and review of license obligations
2. Design considering open source licenses
3. Creation of open source compliance deliverables
4. Creation of SBOM (Software Bill of Materials)
5. Response to open source license compliance issues
6. Response to open source security vulnerabilities

You can refer to the principles documented in 6. Open Source Use of [Appendix 1] Open Source Policy template.

1. Open Source Use

When developing and distributing products and services using open source, you must comply with the obligations required by each open source license. This activity is called open source compliance.

For proper open source compliance activities, software development/distribution organizations comply with the following matters and record all processes in the Jira Tracker for preservation.

(1) Identification of open source and review of license obligations

When introducing open source to product/service development, first identify what the open source license is, and review and confirm the obligations required by the license.

The company's [Open Source License Guide] includes a list of major open source licenses, and distinguishes the obligations required by each license according to the following types of distribution:

- Binary form
- Source form
- Strong/weak Copyleft
- SaaS-based provision
- Whether modification is made
- Requirement to indicate the author's open source, etc.

Software development/distribution organizations can refer to this guide when reviewing open source license obligations. If a review of an open source license not mentioned in this guide is required, contact the open source program manager.

(2) Design considering open source licenses

Understand the combination relationship of open source and design the software architecture so that the company's code is not affected by the open source license.

The company's [Open Source License Guide] explains the range of source code disclosure for each open source license and the design method to prevent the disclosure of the company's code.

(3) Creation of open source compliance deliverables

The most basic of open source compliance activities is to understand the status of open source included in the distribution software. This is to properly meet the core of open source compliance, which is the requirements of the open source license. In other words, you need to create a set of compliance deliverables for the open source included in the distribution software.

Open source compliance deliverables are largely divided into two.

1. Open source notice: A document for providing open source license text and copyright information
2. Package of source code to be disclosed: A package that collects source code to be disclosed to fulfill the obligations of open source licenses that require source code disclosure

To collect, distribute, and store these compliance deliverables, comply with the following matters.

- The open source notice or package of source code to be disclosed is collected according to the conditions required by each license. For example, if the license requires the entire text of the license to be enclosed, you should not just provide a link.
- The collected deliverables are stored in a separate repository.
- If the source code to be disclosed is provided by a written agreement, the download link is disclosed so that the repository of the collected deliverables can be accessed from the outside.

You can issue an open source notice and collect a package of source code to be disclosed through the company's open source process.

(4) Creation of SBOM (Bill of Materials)

You need to create and manage the status of open source included in the distribution software (BOM: Bill of Materials).

You can create and preserve SBOM using open source tools through the company's open source process.

(5) Compliance issue response procedure

If a compliance issue is raised, the open source program manager performs the following procedures to respond quickly.

1. Confirm the receipt of the inquiry and specify the appropriate resolution time.
2. Confirm whether the content of the issue points out a real problem. (If not, notify the issue raiser that it is not a problem.)
3. If it is a real problem, prioritize and decide on an appropriate response.
4. Perform the response, and if necessary, appropriately supplement the open source process.
5. The above contents are preserved using the Jira Tracker.

(6) Response to open source security vulnerabilities

- Identify open source vulnerabilities and evaluate their severity.
- Modify vulnerabilities or apply security patches according to the results of open source vulnerability analysis. The decision to take action on vulnerabilities considers the severity of the vulnerability, the importance of the system, the availability of vulnerability modifications or security patches, etc.
- Monitor the announcement of new open source security vulnerabilities and respond quickly when vulnerabilities occur. Open source vulnerability monitoring can be performed through vulnerability databases such as CVE, websites of security professional organizations, etc.

Internal Responsibility Assignment Procedure

The open source policy should cover the procedure for assigning responsibility internally to resolve open source management issues.

The ISO standard commonly requires the following documented procedures that assign internal responsibilities:

Firstly, the open source program manager must identify compliance issues and appropriately assign responsibilities to the role holders to resolve them. Similarly, for open source security vulnerability issues, the security manager identifies the issues and assigns responsibilities to the appropriate personnel to resolve them.

To do this, you can reflect a documented procedure for assigning internal responsibilities in the open source policy, as shown in the example below:

1. Roles, Responsibilities, and Competencies

To ensure the effectiveness of the policy, we define the roles, responsibilities, and competencies that each role holder should possess.

(2) Open Source Program Manager

- Defines the roles necessary for open source compliance, and designates the responsible organization and person for each role. Consults with the OSRB as necessary. The security manager assigns internal responsibilities for open source security assurance.

(6) Security Manager

- Assigns responsibilities for each task to ensure the success of open source security assurance.

Response to Non-compliance Cases

Companies should document procedures to quickly review and respond when non-compliance cases occur.

ISO/IEC 5230 requires a documented procedure for reviewing and remedying non-compliant cases, as follows:

For this, companies can reflect a documented procedure for reviewing and remedying non-compliance cases in the open source policy, as shown in the example below:

6. Open Source Use

(5) Compliance Issue Response Procedure

When a compliance issue is raised, the open source program manager quickly responds by following the procedure below:

1. Confirm the inquiry and specify an appropriate resolution time.
2. Verify whether the issue content points to an actual problem. (If not, inform the issue raiser that it is not a problem.)
3. If it is an actual problem, prioritize and decide on an appropriate response.
4. Perform the response and, if necessary, appropriately supplement the open source process.
5. Preserve the above content using the Jira Tracker.

Support for Personnel and Budget

Companies should provide sufficient resources to ensure the smooth operation of the open source program. They should properly allocate personnel to handle each role within the program, and guarantee sufficient budget and working hours. If not, procedures should be in place to supplement this.

The ISO standard commonly requires that personnel handling each role within the program be properly allocated and that the budget be adequately supported, as follows:

For this, companies can reflect content on personnel and budget support in the open source policy, as shown 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 appropriate time and budget for the person in charge to faithfully perform the role.

- If the person in charge of each role finds that they are not receiving appropriate support while performing their role, they should raise the issue with the open source program manager.
- The open source program manager discusses problem-solving with the head of the organization. If it is not resolved appropriately, the open source program manager can request problem-solving from the OSRB.
- The OSRB shares the problem with the head of the upper organization and requests a solution.

Provision of Expert Advice

Companies should provide a way for role holders to request advice when professional review is needed to resolve open source issues.

The ISO standard commonly requires a method to use internal or external expert advice to solve problems, as follows:

For open source license compliance issues, the company’s legal team is primarily responsible, and if the issue is acute, an external law firm with an open source specialist lawyer can be used.

For open source security vulnerability issues, the company’s security team is primarily responsible, and if the issue is complex and acute, advice can be requested from an external security technology company.

For this, companies can reflect content on providing advice in the open source policy, as shown in the example below:

4. Roles, Responsibilities, and Competencies

(4) Legal Manager

The legal manager provides advice on legal risks and mitigation measures that may arise during the process of using open source, such as interpreting open source licenses and obligations.

- Provides a reasonable way for members to inquire about open source compliance issues.
- Provides advice on license and intellectual property issues, including conflicts due to incompatible open source licenses.
- Reviews necessary legal matters such as open source licenses, CLA (Contributor License Agreement), etc. when contributing to external open source projects.
- If the issue is acute, requests advice from an external law firm with an open source specialist lawyer.

(6) Security Manager

The security manager operates an open source vulnerability analysis tool to build a system that allows security vulnerability analysis to be performed smoothly for all distribution software.

- Provides a reasonable way for members to inquire about security vulnerabilities, and uses external technical advice as needed to resolve vulnerabilities.

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

Law firms registered as OpenChain partners have met the requirements of the OpenChain Project.

Specifying the Scope of Application

A single open source policy (program) does not necessarily have to be applied to the entire organization. Depending on the characteristics of each organization and product within the company, the scope of application can be specified differently. For example, an organization that does not distribute software at all can be excluded from the scope of the open source program.

The ISO standard commonly requires a documented statement that clearly defines the scope and limits of the program, as follows:

Companies should clearly define the scope and limits of the open source program considering the characteristics of the organization and products, and specify this in the open source policy.

Also, as changes occur in accordance with changes in the business environment, situations may arise where the organizational structure, products, and services determine or modify the scope of the program. Companies should establish metrics for evaluating the scope of application and improve deficiencies by performing reviews and inspections for continuous improvement.

For this, companies should have a system that clearly defines the scope of application in the open source policy and documents the activity history, as shown below:

1. Scope of Application

This policy applies to the following three parts:

1. It applies to all products provided or distributed externally by the company. However, the use of open source for internal use only is not included in the scope of this policy.
2. It applies when members contribute to external open source projects.
3. It applies when internal code is disclosed as open source.

The scope of application can be changed to suit the company's business environment. In particular, the open source program manager investigates at least once a month whether there are products that are not subject to this policy and are distributed or serviced externally to ensure continuous effectiveness. This is measured and used as a criterion for changing the scope of application when even one case is found.

The procedure for changing the scope of application is as follows:

1. If the open source program manager determines that it is necessary to change the scope of application of the policy due to changes in the company's business environment such as new business and organizational restructuring, it submits a proposal for this to the OSRB.
2. The OSRB approves an appropriate level of change in the scope of application.
3. The OSRB modifies the open source policy to change the scope of application.

The open source program manager continuously documents the review, update, and inspection history for improving the scope of application at least once a month using the Jira Issue Tracker.

Therefore, companies should have a system that clearly defines the scope of application in the open source policy and documents the activity history.

Responding to External Inquiries

There are cases where customers and open source copyright holders contact the company to make inquiries, requests, and claims about products or services developed using open source.

The main contents of external inquiries and requests are as follows:

• Inquiry about whether open source has been used in a specific product or service
• Request for source code provision under the GPL, LGPL license mentioned in the written agreement (Written Offer)
• Explanation and source code disclosure request for open source that was not specified in the open source notice but was found in the product
• Request for missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
• Request for copyright notice
• Inquiries and requests related to open source security vulnerabilities

Companies should designate a person in charge of handling these external inquiries. Typically, the open source program manager is in charge.

There are cases where an external open source developer wants to contact a company’s person in charge to discuss an open source related issue of a specific company, but cannot find a way to contact and eventually files a legal claim directly. To prevent this, companies should always publicly disclose a way for third parties to contact the company about open source.

The ISO standard commonly requires a publicly visible method that allows any third party to make an open source license compliance inquiry, as follows:

Companies can provide a way to contact the company about open source, as shown below:

Sure, here’s the translation of the guide in professional style:

1. The representative email address of the open source responsible organization is made public.
2. The Open Compliance Directory of the Linux Foundation is used.
3. If the company has an open source website, the email address is made public through it.

Including the representative email address of the open source responsible organization in the open source notice that comes with the product and service and making it public is also a good method.

Companies can reflect the following content on external inquiries in their open source policies:

9. Response to External Inquiries

(1) Responsibility for Responding to External Inquiries

The open source program manager is responsible for responding to inquiries and requests about open source from outside.

- The open source program manager can assign the handling of all or part of the inquiry to appropriate personnel within the company. If necessary, the legal representative is consulted for handling.
- Anyone who receives an inquiry about open source from outside informs the open source program manager so that a quick response can be made.

(2) Disclosure of Contact Information

The open source program manager provides the contact information of the person in charge publicly so that inquiries and requests related to open source can be made from outside.

- Provides email address information that can be contacted in the open source notice.
- Provides email address information on the open source website.
- Registers the contact information in the Open Compliance Directory of the Linux Foundation.

(3) Procedure for Responding to External Inquiries

If you respond quickly and accurately to open source inquiries from outside, you can greatly reduce the risk of claims or legal litigation. To this end, the company complies with the procedure for responding to external inquiries defined in the company's open source process.

SK Telecom includes an open source notice in all products. The open source notice provides the address of the SK Telecom open source website and the email address that can contact the open source program office.

Also, the SK Telecom Open Source Website provides an email address that can contact the open source program office.

Open Source Contribution

Global software companies not only use open source to create products and provide services, but also value the strategic value that can contribute to and create open source projects. However, if you approach without sufficient understanding of the open source project ecosystem and community operation methods and strategies, the company’s reputation may be unexpectedly damaged and legal risks may occur. Therefore, it is important for companies to establish strategies and policies for participating in and contributing to open source projects.

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

You can check the open source contribution policy in [Appendix 1] Open Source Policy template 7. Open Source Contribution.

7. Open Source Contribution

The company encourages participation and contribution to external open source projects to create business value from open source. However, care must be taken to avoid unintentional exposure of the company’s intellectual property or infringement of third-party rights during this process. To this end, members of the company must comply with the following when contributing to external open source projects:

(1) Request for Review and Approval

Contributing to open source is granting the open source project the right to modify, use, and distribute the work from a copyright perspective. Sometimes, you may need to transfer your copyright to the open source project. However, the copyright of works created during the employment period is generally owned by the employer. In other words, the works created by company members are owned by the company. The act of arbitrarily contributing works to open source can trigger unnecessary copyright infringement issues.

Therefore, if there is an open source project you want to contribute to, you must comply with the review request and approval process before making the initial contribution according to the open source contribution process.

However, in the case of simple content such as the following, you can contribute according to the judgment of the member without the review process because the risk of copyright infringement is not high:

- Small code snippets of 10 lines or less
- Questions / Answers on Stack Overflow
- Management activities on GitHub: Creating Issues, Reviewing / Approving Pull Requests, etc.

...

Companies should refer to this and include principles for open source contributions that suit the company’s situation in the open source policy.

Summary

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

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

It is necessary to establish appropriate principles for each requirement according to the company’s situation and to consider executable procedures, not just documents. A policy that is only spoken is useless.

By establishing and documenting an open source policy like this, you can meet the requirements marked in orange in the ISO standard specifications.

3 - 3. Process

The open source process is an executable procedure that allows companies to comply with open source policies during the software development and distribution process.

From the perspective of open source license compliance, activities are carried out to comply with the conditions required by each license for the open source used in developing and distributing software, resulting in the creation of deliverables such as open source notices and source code to be disclosed.

For open source security assurance, activities must be carried out to detect the presence of security vulnerabilities in the software to be distributed, identify structural/technical threats, and resolve issues before release.

In order for a company to effectively achieve open source license compliance and security assurance, the following processes must be established:

• Open source process
• Open source vulnerability process
• External inquiry response process
• Open source contribution process

Let’s take a look at how each process should be structured.

1. Open Source Process

Companies should establish an open source process for open source license compliance and security vulnerability management according to the software development process.

The image below is a sample open source process that companies can generally adopt and use.

The procedures to be taken at each stage according to the open source process are as follows:

(1) Identification and Inspection of Open Source

In the identification and inspection stage of open source, it is necessary to identify what license the open source you want to use is, what obligations the license requires, and whether there are known vulnerabilities.

Review and record which open source you want to use, what its license is, what obligations each license imposes, and what known vulnerabilities are.

The ISO/IEC 5230 standard requires a documented procedure to handle common open source license use cases and to review and record the obligations, restrictions, and rights granted by each identified license.

An example of a procedure for this is as follows:

1. The open source program manager provides a guide on the obligations, restrictions, and rights of major open source licenses. This guide should include the following use cases to handle common open source license use cases:

   • Distribution in binary form
   • Distribution in source form
   • Integration with other open source that triggers additional license obligations
   • Inclusion of modified open source

2. The business unit checks the license and known vulnerabilities according to the criteria defined in the open source policy.

3. The business unit consults with the open source program manager and security officer on any questions. If necessary, advice is sought from external experts.

4. All decisions and related grounds are documented and kept.

For this, companies should establish a documented procedure to review and record the obligations, restrictions, and known vulnerabilities granted by each identified license before product release through the open source identification and inspection stage.

(1) Open Source Identification

The business unit complies with the following matters at the software design stage.

- Identify the anticipated open source usage status and check the license while designing the software.
- Check the obligations of each open source license. The obligations of each license can be checked in the company's open source license guide. : https://sktelecom.github.io/guide/use/obligation/
- Design the software considering the source code disclosure range of each open source license.

The open source program manager creates and publishes a guide on the obligations, restrictions, and rights of major open source licenses so that the business units of the company can refer to it. This guide should include the following use cases to handle common open source license use cases:

- Distribution in binary form
- Distribution in source form
- Integration with other open source that triggers additional license obligations
- Inclusion of modified open source

The business unit marks copyright and license in the source code according to the company rules. The company's source code copyright and license marking rules can be found on the following page. (insert_link)

When the business unit considers introducing new open source, it first identifies the license. According to the company's open source license guide, check the obligations, restrictions, and rights of the license. If the license is not explained in the company's open source license guide, ask the open source program manager about the possibility of introduction and precautions. Create a Jira Ticket for inquiries.

The open source program manager analyzes the obligations of the open source license and guides the software development organization.

- If there is any doubt, consult with the legal officer and provide clear guidance.
- The newly analyzed license information is reflected in the company-wide license guide.

The security officer provides a guide for the company's security assurance.

(2) Source Code Inspection

The business unit requests an open source check according to the guidance of the IT manager and provides the source code.

The IT manager uses the open source analysis tool to check the open source and create an SBOM (Software Bill of Materials).

The open source program manager reviews the possibility of complying with the open source license obligations, checks for conflicts between open source licenses, and if there are issues, requests the business unit to resolve them. Issues are created as Jira Tickets and assigned to the business unit.

The security officer reviews the detected known vulnerabilities and provides a response guide to the business unit according to the pre-defined Risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) Score, and Critical Risk is guided to establish a plan that can be addressed within 1 week.

In the open source identification and inspection stage, source code scanning tools can be used. More details on this can be found in “1. Source Code Scanning Tools”.

(2) Problem Solving

After identifying open source through open source identification and inspection, and confirming the risks of licenses and security vulnerabilities, a procedure is needed to solve the problem. All detected problems should be solved in the following ways:

• Remove the open source that is causing the issue.
• Replace with open source under a different license to resolve open source license issues.
• Replace with a version of open source where known vulnerabilities have been resolved.

An example of a documented process for this is as follows:

(3) Problem Solving

The business department solves all problems found in the source code inspection stage.

Remove the open source that is causing the issue, or replace it with open source under a different license. In the case of security vulnerability issues, measures such as replacing with a version where known vulnerabilities have been fixed are taken.

Once the business department has resolved all discovered issues, they resolve the Jira Ticket issue and request a re-review.

(3) SBOM Identification, Review, and Storage

The most basic of open source license compliance activities is to understand the status of open source included in the distributed software. You need to build a process to create and manage an SBOM (Software Bill of Materials) that contains information identifying the open source and its licenses included in the distributed software. Knowing which open source is included in each version of the distributed software is essential for complying with the obligations required by each open source license when distributing software. This is also an essential process for discovering and responding to open source security vulnerabilities.

All open source must be reviewed and approved before being integrated into the distributed software. Not only the functionality and quality of the open source, but also whether the origin, license requirements can be met, and whether known vulnerabilities have been resolved, etc., must be reviewed in advance. A review request → review → approval process is required for this.

ISO standards commonly require a documented procedure that ensures that all open source software used in the supplied software is continuously recorded during the lifecycle of the supplied software.

For this, companies can reflect the following content about SBOM in the open source process:

(4) Review

The open source program manager reviews whether all issues have been properly supplemented. If necessary, the source code inspection is re-performed using the open source analysis tool.

The security officer reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, they review whether they can be approved considering the business form and service exposure status.

(5) Approval

The open source program manager finally approves or rejects whether the open source compliance procedure has been properly performed. If rejected, they propose a reason and a modification method to the business department.

(6) Registration

The open source program manager finalizes the BOM to track the list of open source used in each version of the software.

The IT officer registers the finalized BOM in the system. The BOM includes a list of open source included in the distributed software and the following information:

- Product (or service) name and version of the distributed software
- Open source list
  - Open source name / version
  - Open source license

The open source program manager finalizes the BOM to track the list of open source used in each version of the software.

For more details on tools for managing SBOM, see “SBOM Management Tools”.

Also, all processes and results of such open source processes must be documented. It is more efficient to use an issue tracking system such as Jira, Bugzilla than using email.

(4) Creation of License Compliance Artifacts

As mentioned above, the most basic of open source license compliance activities is to understand the status of open source included in the distributed software. This is precisely because it is the core of open source license compliance to properly meet the requirements of open source licenses. In other words, a process must be established to create a set of compliance artifacts for the open source included in the distributed software.

The ISO/IEC 5230 standard requires a documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.

Compliance artifacts are divided into two main categories:

1. Open Source Notice: A document for providing open source license text and copyright information

   

   • For how to create an open source notice that aggregates the SBOM using tools, see “Open Source Compliance Artifact Generation Tools”.

Sure, here is the English translation of the Korean guide you provided, written in a professional style suitable for user manuals, help documents, and technical documents:

2. Source Code Package to be Disclosed: A package that consolidates source code to be disclosed in order to comply with the obligations of open source licenses that require source code disclosure, such as GPL, LGPL.

Compliance deliverables must be provided along with the distribution of the software for distribution.

For this, companies can reflect the content on the creation of compliance deliverables from the notification stage to the distribution stage in the open source process as follows:

(7) Notification

The open source program manager creates an open source notice to comply with the notification obligation. The open source notice includes the following:

- Open source contact point where open source related inquiries can be made
- Notice content for each open source
  - Copyright
  - Open source license name
  - Copy of open source license
  - (If applicable) Written agreement to obtain a copy of the source code (Written Offer)

The open source program manager creates an open source notice and delivers it to the business department. At this time, if source code disclosure is necessary, the method of collecting the source code to be disclosed is guided to the business department.

The business department includes the open source notice when distributing the product. If the product has a screen, measures are taken so that the user can check it through the menu. (Example: App > Menu > Settings > Copyright Information > Open Source License)

The business department, when using open source under a license that requires source code disclosure such as GPL, LGPL, checks the scope of source code disclosure for this and collects the source code to be disclosed.

- The source code collected to comply with the obligations of licenses such as GPL, LGPL must match the source code that constitutes the binary loaded on the product. In other words, if you build the collected source code, it must be the same as the binary loaded on the product.

(8) Confirmation before distribution

The business department submits the following deliverables to prove that the open source compliance activities have been properly performed.

1. Final open source notice included in the product
2. Materials confirming that the open source notice is included in the product (Example: Screen capture image showing the open source notice)
3. (If applicable) Source code to be disclosed (Submit as a single file compressed)

The open source program manager reviews the materials submitted by the business department and checks for any abnormalities.

(9) Distribution

The open source program manager submits the compliance deliverables submitted by the business department to the IT manager.

The IT manager registers the compliance deliverables on the company's open source distribution site.

When distributing software for distribution, it may be difficult to include a package of source code to be disclosed. In this case, you can substitute it by providing a written agreement (Written Offer) that you will provide the source code for at least 3 years. Typically, the written agreement is provided through the product’s user manual, and the example is as follows:

The software included in this product contains copyrighted software 
that is licensed under the GPL. A copy of that license is included 
in this document on page X. You may obtain the complete Corresponding 
Source code from us for a period of three years after our last shipment 
of this product, which will be no earlier than 2011-08- 01, by sending 
a money order or check for $5 to:

GPL Compliance Division
Our Company
Any Town, US 99999

Please write“source for product Y” in the memo line of your payment.
You may also find a copy of the source at http://www.example.com/sources/Y/.
This offer is valid to anyone in receipt of this information.

<Source: SFLC Guide to GPL Compliance>

Therefore, compliance deliverables must be kept for more than 3 years, and a process for this must be established.

For this, companies can consider building an open source website. You can check the details in “Open Source Compliance Artifact Storage”.

2. Open Source Security Vulnerability Process

Companies must perform activities for security assurance, such as detecting and resolving open source security vulnerabilities, while developing products/services.

The ISO/IEC 18974 standard requires documented procedures and records of actions taken for security assurance methods as follows:

In order to address vulnerabilities in the deployed software, enterprises must detect the presence of known vulnerabilities in the distribution-ready software and resolve identified risks before release. Furthermore, they need to establish methods and procedures to respond to newly discovered vulnerabilities post-release.

Initially, enterprises should detect known vulnerabilities in the distribution-ready software and resolve identified risks before release. The procedure for detecting and addressing these known vulnerabilities can be carried out through the open-source identification phase, source code inspection phase, and issue resolution phase of the open-source process, as outlined in Open Source Process.

Additionally, when newly identified vulnerabilities are disclosed after the release of the deployed software, it is imperative to establish a process for confirming their existence in the already distributed software and taking necessary measures to address them.

Below is a sample process for responding to the discovery of new security vulnerabilities:

1. New Security Vulnerability Process

After a product/service is launched in the market, we adhere to the following process to take appropriate measures according to the risk level when a new security vulnerability is reported.

(1) Monitoring

The IT department operates a system that monitors new security vulnerabilities. This system performs the following functions:

- Regularly collects information about newly disclosed security vulnerabilities.
- If an open source with a new known vulnerability is used in a product/service that has already been released, it sends a notification to the business department in charge of the product/service. From notification to review, action, and resolution, everything is documented and recorded using the Jira Issue Tracker.

(2) Initial Response

The security officer provides a response guide to the business department according to the pre-defined risk classification criteria. Risks are classified by CVSS (Common Vulnerability Scoring System) scores, and Critical Risk is guided to establish a plan that can be implemented within 1 week.

If a new security vulnerability is found in a product/service that has already been released, the business department establishes a response plan according to the response guide provided by the security officer.

If there are customers who need assurance, the business department notifies the confirmed known vulnerabilities by email or other means as needed, depending on the risk level.

(3) Problem Solving

The business department solves the security vulnerability problem by deleting the problematic open source or replacing it with a patched version, etc., according to the established response plan. Once all issues are resolved, a re-review is requested.

(4) Review

The IT department uses an open source analysis tool to check whether the problem has been properly resolved.

(5) Approval

The security officer reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, the approval is reviewed considering the business form and service exposure status.

(6) Registration

The IT department registers the SBOM, which has resolved the open source security vulnerability, in the system.

(7) Notification

The open source program manager creates an open source notice based on the SBOM that has resolved the open source security vulnerability and delivers it to the business department.

The business department replaces the open source notice included in the product distribution.

The IT department registers the modified open source notice on the company's open source distribution site.

(8) Distribution

The business department redistributes the software version that has resolved the open source security vulnerability.

The security officer identifies whether there is risk information that needs to be disclosed to third parties, and if so, delivers it to the IT department.

The IT department registers the identified risk information on the open source website so that third parties can check it.

3. External Inquiry Response Process

In order for a company not to lead to legal litigation due to external claims, it is important to respond as quickly and accurately as possible to external inquiries and requests. To this end, companies should establish a process that can respond quickly and effectively to external open source inquiries.

ISO standards commonly require the following internal documented procedures to respond to third-party inquiries.

The following figure is a sample process that a company should have in order to respond to external inquiries.

If you respond quickly and accurately to open source compliance inquiries from outside, you can greatly reduce the risk of proceeding to litigation. To this end, the company adheres to the following process to respond to external open source compliance inquiries.

(1) Receipt Notification

As soon as the open source program manager receives an inquiry, they notify the requester that the inquiry has been received. At this time, they also notify the expected date of action. If the inquiry is unclear, they request additional explanation.

The main contents of the inquiries and requests that require response are as follows:

- Inquiry whether open source has been used in a specific product or service
- Request for source code provision under GPL, LGPL license mentioned in written agreement (Written Offer)
- Explanation and source code disclosure request for open source found in the product but not specified in the open source notice
- Request for missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
- Copyright notice request

The open source program manager creates a Jira Issue for the received request and records all the response situations in detail.

(2) Investigation Notification

The open source program manager notifies the requester that they are investigating the open source compliance. It is good to notify whenever the internal investigation progress is updated.

(3) Internal Investigation

The open source program manager conducts an internal investigation on the request. They check whether the compliance process has been properly performed for the version of the product in question through the BOM and documented review history. If necessary, they request advice from the legal department.

If it is a matter that needs to be confirmed by a specific business department, the open source program manager requests an investigation from the business department. The business department immediately checks whether there is a problem with the compliance deliverables upon receiving the investigation request and reports the results to the open source program manager.

(4) Report to Requester

The open source compliance officer completes the internal investigation within the expected date of action and notifies the requester of the result.

- If the requester's inquiry was a misdirected point due to misunderstanding, they notify the requester and end the process without any additional action.
- If there is a problem, they notify the requester of the exact method and timing to fulfill the obligations of the open source license in question.

(5) Problem Supplement / Notification

If a compliance problem is actually found in the internal investigation, the relevant business department performs all procedures necessary to solve the compliance problem.

(6) Problem Resolution Notification

After solving the problem, they immediately notify the requester and provide the best way to confirm that the problem has been resolved.

(7) Process Improvement

If there was a compliance problem, the OSRB meeting reviews the case, identifies the circumstances of the problem, and improves the process so that the problem does not recur.

Sure, here is the translation of the text you provided:

4. Open Source Contribution Process

If a company has a policy that allows contributions to external open source projects, there should be a documented procedure for how in-house developers can contribute to external projects.

The ISO/IEC 5230 standard requires a documented procedure for managing open source contributions.

The Open Source Contribution Process published by SK Telecom is a good example.

https://sktelecom.github.io/guide/contribute/process/

5. Process Modernization

It is not desirable for the process to be documented but not actually operated. Also, it is a problem if it does not fit the business situation or organizational composition. Companies should always keep the process up-to-date to match the internal organization and situation of the company.

The ISO/IEC 18974 standard requires periodic review and improvement of the process.

Companies can define in the open source policy document that they improve the open source policy and open source process every year and document and record all processes.

1. Roles, Responsibilities, and Competencies

To ensure the effectiveness of the policy, we define the roles and responsibilities and the competencies that each role holder should have as follows.

(1) OSRB

The OSRB (Open Source Review Board) is a consultative body composed of the open source program manager and the heads of related organizations such as the legal team, patent team, development team, and infrastructure team for the company's open source management.

The OSRB improves policies and processes on a regular basis every year. All improvement processes are documented and recorded.
  - The OSRB always modernizes the company's process performance results, shortcomings, best practices, and reflects the business environment.
  - The policy and process for open source compliance are managed by the open source program manager.
  - The policy and process for open source security assurance are managed by the security officer.

6. Summary

By building the process up to this point, you can meet the requirements marked in yellow in the ISO standard specifications.

4 - 4. Tools

1. Source Code Scanning Tools

In the open source identification and inspection stages of the open source process, you can use source code scanning tools. These tools range from open source-based tools that can be used for free to commercial tools. Each tool has its strengths, but no tool provides a perfect solution to all problems. Therefore, companies should select the appropriate tool that fits the characteristics and requirements of their products.

Many companies use these automated source code scanning tools in conjunction with manual reviews. The Linux Foundation’s FOSSology project is an open source source code scanning tool that companies can easily use for free.

For information on how to install and use FOSSology, please refer to Get Started with FOSSology.

2. Dependency Analysis Tools

In recent software development, build environments that support package managers such as Gradle and Maven are used. In these build environments, even without source code, the necessary Dependency libraries are fetched from a remote space at build time to compose the distribution software. However, these Dependency libraries are included in the distribution software but are not detected by the source code scanning tools. Therefore, it is also important to use tools for Dependency analysis.

The OSS Review Toolkit, which is open source, provides a Dependency analysis tool called Analyzer.

In addition, LG Electronics has released the FOSSLight Dependency Scanner as open source. The FOSSLight Dependency Scanner supports various package managers such as Gradle, Maven, NPM, PIP, Pub, and Cocoapods.

3. SBOM Management Tools

ISO/IEC 5230 standard 3.3.1.2 requires that the SBOM list included in the distribution software be documented and stored.

SBOM can be managed with spreadsheet programs like Excel, but it is not easy to manage manually when the number and version of distribution software exceed hundreds. Therefore, it is recommended to introduce open source automation tools for this purpose.

The SW360 project, sponsored by the Eclipse Foundation, provides the ability to track the list of open sources included in each distribution software.

The installation and usage of SW360 can be referred to in the SW360 Docker.

And the aforementioned FOSSLight also provides features for SBOM management.

LG Electronics has been managing the SBOM for all business units’ distribution software for the past several years using FOSSLight, which it developed in-house. In June 2021, it announced that it had released it as open source so that anyone can use it.

4. Open Source Vulnerability Management Tools

Companies need to track products/services that contain known vulnerabilities and resolve them. To do this, companies need to build a tool environment that automates this.

SW360 can automatically check if there are any security vulnerabilities in the registered Release. For this, SW360 provides a feature to schedule the collection of CVE information every 24 hours. If you set up this scheduling, SW360 will collect CVE information from the CVE Search site (https://cve.circl.lu/) at the set time. After the Vulnerabilities information is collected, you can check if there are any security vulnerabilities in the created Project, so you can also track whether newly disclosed vulnerabilities exist in products that have already been released.

The method of managing security vulnerabilities with SW360 can be referred to in the SW360 guide.

FOSSLight also automatically acquires security vulnerability information and automatically checks project information where security vulnerabilities have been detected, providing notifications such as emails as needed.

5. Open Source Compliance Artifact Generation Tool

The main open source compliance artifact, the open source notice, is a document that provides copyright and license information for the open source included in the distributed software. Open source notices can be created using a document editor tool, but it is recommended to use a tool that generates them automatically.

SK Telecom has released an open source notice automatic generation tool (onot: https://github.com/sktelecom/onot) used internally as open source, and Kakao has participated in joint development by contributing major features.

onot is a tool that automatically converts SBOMs written in SPDX document format into open source notice format. It is a Python program that is lightweight and easy to use.

FOSSLight also provides a feature to automatically generate open source notices based on the acquired SBOM.

6. Open Source Compliance Artifact Storage

It is recommended that companies build an open source website and register open source compliance artifacts so that external customers can conveniently download open source notices and source code packages to be disclosed for distributed software at any time.

For this, the ISO/IEC 5230 standard requires a documented procedure for archiving copies of the compliance artifacts of the supplied software.

You can refer to this tool environment on SK Telecom’s open source website.

This website was developed as open source, and the source code is open, so other companies can easily build a similar environment.

7. Summary

If you build up to the tool environment, you can meet the requirements marked in green in the ISO standard specification.

5 - 5. Education

1. Education

No matter how excellent the policies and processes are, they will be useless if no one in the organization pays attention to them. For open source policies and processes to work effectively in a company, member education is crucial.

Companies should provide practical means such as education and internal wikis so that all program participants are aware of the existence of open source policies within the organization and can perform necessary activities. Program participants here refer to all employees involved in the development, distribution, and contribution of software, including software developers, distribution engineers, and quality engineers.

For this, the ISO standard commonly requires the following documented procedures to inform about the open source policy:

Many companies make their open source policy documents available through internal wiki sites so that any employee can check the necessary items. In addition, they mandate education on open source policies during the orientation of new hires and provide regular education once a year or every two years to all program participants, ensuring that all program participants are aware of the existence of the open source policy.

Companies should include these methods in the open source policy document as follows:

5. Education and Evaluation

All members in charge of each role defined in Chapter 4 must take the advanced open source education course provided by [Learning Portal]. Through this, they will familiarize themselves with the open source policy, related education policy, and inquiry methods. The education history and evaluation results are kept in [Learning Portal] for at least 3 years.

Companies should ensure that program participants are aware of the company’s open source policy, open source-related goals, participant’s contribution methods for an effective open source program, and the impact of non-compliance with program requirements. To do this, companies should provide education, perform evaluations to confirm correct understanding by program participants, and document and keep the evaluation results.

The ISO standard commonly requires the following documented evidence indicating the assessed awareness of program participants:

Therefore, companies can include the following content in the company’s open source policy:

1. Purpose

(1) Purpose of the policy

This policy provides the following principles for the entire organization involved in software development, service, and distribution at OOO Co., Ltd. (hereinafter referred to as "the company") to properly utilize open source software (hereinafter referred to as "open source").

1. Open source compliance / security assurance principles
2. Principles for contributing to external open source projects
3. Principles for disclosing in-house projects as open source

These principles provide a way for all members of the company to understand the value of open source, use open source correctly, and contribute to the open source community.

All members of the company can check the open source policy at the following link on the internal wiki: [internal_link]

(2) Impact of non-compliance

If this policy is not complied with, the following situations may occur:

- You may receive a request for open source license compliance from the outside.
- You may have to disclose the source code developed by the company against your will.
- You may be sued by the open source copyright holder.
- You may be fined for copyright infringement and contract violation, or receive a product sales suspension order.
- The company's reputation may be damaged.
- You may be claimed for damages due to a contract violation with the supplier.
- You may be exposed to serious security incidents, causing significant damage to the company.

For these reasons, the company takes violations of the open source policy seriously, and members or organizations that violate this may be subject to disciplinary procedures.

(3) Contribution method of members

All members of the company can contribute to the effectiveness of the policy and the improvement of the company's compliance level by understanding the basis and content of this policy and faithfully performing the necessary activities.

The evaluation will be explained in more detail below.

The open source education includes content on the open source contribution policy. Even if an open source contribution policy is created, if no one in the company is aware of its existence, there is a risk of damage to individuals and companies due to indiscriminate contribution activities.

For this, the ISO/IEC 5230 standard requires the following documented procedure to make all program participants aware of the existence of the open source contribution policy.

Therefore, companies should provide open source education so that all in-house developers are aware of the existence of an open source contribution policy.

Creating new educational materials may not be easy for those who are just starting out. To help with these difficulties, NCSoft has made its in-house open source educational materials available to everyone by publishing the lecture (PPT) and lecture script on GitHub.

In addition, Kakao, a leading platform company in Korea, has also made its open source educational materials available for anyone to view.

If you haven’t created educational materials yet, it’s a good idea to use the open source educational materials from these excellent open source management companies.

2. Evaluation

Once a company has assigned roles, it must ensure that the assigned individuals are qualified to perform their roles based on education, training, and experience. Adequate education should be provided to program participants who lack competence. And the company must evaluate whether each participant is competent and keep the results.

For this, the ISO standard commonly requires documented evidence of assessed competence for each program participant.

Therefore, companies should perform education and evaluation as follows:

1. The company provides education so that each participant can have the necessary competence.
2. Perform an evaluation based on the content of the education.
3. The evaluation results are kept in the company’s education system or HR department.

If there are hundreds of program participants and it is not easy to provide education, it is a good idea to use the company’s online education and evaluation system.

This content can be included in the company’s open source policy as follows:

4. Roles, Responsibilities, and Competencies

To ensure the effectiveness of the policy, we define the roles and responsibilities and the competencies that each role's manager should have.

The organization/manager in charge of each role and the required competency level are defined in [Appendix 1. Manager Status].

5. Education and Evaluation

All members who are in charge of each role defined in Chapter 4 must take the advanced open source education course provided by [Learning Portal]. Through this, you will be familiar with the open source policy, related education policy, and how to inquire.

The education history and evaluation results are kept in [Learning Portal] for at least 3 years.

3. Open Source License Guide

To properly comply with open source licenses, you need to know exactly what each open source license requires. However, it is difficult for individual software developers to identify this on a daily basis, so the open source program manager should summarize the requirements/precautions for common use cases for frequently used open source licenses and share them internally.

The open source license guide should enable development departments to perform correct license compliance activities when using open source, including general requirements for common open source license use cases.

For this, the ISO/IEC 5230 standard requires a documented procedure for handling common open source license use cases for the open source components of the supplied software.

To handle open source license use cases, you need a license guide classified by open source license. General guides and license obligation summary materials for open source licenses can be referred to the License Guide provided by the Korea Copyright Commission.

The License Obligation document in the open source guide of SK Telecom is also a good resource.

https://sktelecom.github.io/guide/use/obligation/gpl-2.0/

Companies should provide an open source license guide in a space where members can easily access and refer to.

4. Summary

If you have built up to the education, evaluation, and guide provision environment, you can meet the requirements of the ISO standard specifications indicated in sky blue.

6 - 6. Conformance

Companies that have built an open source program (open source policy / process / tools / organization) that complies with all requirements except ISO/IEC 5230 3.6, ISO/IEC 18974 3.4 can document and specify the following two things.

For this, ISO standards commonly require the following documented procedures to announce open source policies.

Therefore, you can document the following:

1. The company’s open source program complies with all the requirements of ISO/IEC 5230, ISO/IEC 18974
2. Guarantee to maintain a state that meets all the requirements of ISO/IEC 5230, ISO/IEC 18974 for more than 18 months after obtaining conformance validation

The company can include the above in its open source policy, or it can be posted through a publicly available website.

You can refer to the content posted on the open source portal site of SK Telecom as shown in the image below. https://sktelecom.github.io/compliance/iso5230/

By doing so, you can meet the requirements marked in blue in the ISO standard specifications.

Once you have completed this, your company will finally meet all the requirements of ISO/IEC 5230, ISO/IEC 18974.