Templates

• 1: Open Source Policy
• 2: Open Source Process

1 - 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 the OOO company (hereinafter referred to as “the company”) to properly utilize open source software (hereinafter referred to as “open source”).

1. Principles of open source compliance / security assurance
2. Principles of contribution to external open source projects
3. Principles for releasing internal 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 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 breach of contract, or receive an order to stop selling products.
• The company’s reputation may be damaged.
• You may be claimed for damages due to breach of contract 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 it may be subject to disciplinary procedures.

(3) How Members Can Contribute

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.

2. Scope of Application

This policy applies to the following three parts:

1. It applies to all products provided or distributed 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 released 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 applied and are distributed or serviced externally to ensure continuous effectiveness. This is 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 changes to the scope of application of the policy are necessary due to changes in the company’s business environment such as new business and organizational restructuring, he/she submits a proposal 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 reviews, updates, and inspects the scope of application at least once a month to improve it, and documents the history using the Jira Issue Tracker.

3. Terminology

• SBOM (Software Bill of Materials): List of software components
• Software Distribution Participants: Refers to all employees involved in software development, distribution, and contribution in the company, including software developers, distribution engineers, quality engineers, etc.
• …

4. Roles, Responsibilities, and Competencies

The following roles, responsibilities, and competencies required for each role are defined to ensure the effectiveness of the policy.

The responsible organization/person and the level of required competencies for each role are defined in [Appendix 1. Status of Responsible Persons].

• The Open Source Program Manager regularly updates the list according to the company’s business situation.
• The head of the organization responsible for each role appoints a person in charge within the organization and allocates appropriate time and budget to ensure that the person in charge can faithfully perform the role.
  • If the person in charge of each role finds that they are not being properly supported in 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 issue with the head of the upper organization and requests a solution.

(1) OSRB

The OSRB (Open Source Review Board) is a consultative body composed of the Open Source Program Manager and responsible persons from related organizations such as the legal team, patent team, development team, infrastructure team, etc., for managing open source in the company.

• The OSRB establishes policies and processes for managing open source in the company and defines the roles and responsibilities within the company to implement them.
• The OSRB reviews and improves policies and processes annually. All improvement processes are documented and recorded.
  • The OSRB always updates the policies and processes for open source compliance and security assurance to reflect the business environment by analyzing the company’s process performance, shortcomings, and best practices.
  • The Open Source Program Manager is responsible for managing the policies and processes for open source compliance.
  • The security officer is responsible for managing the policies and processes for open source security assurance.
• The OSRB discusses solutions and prepares countermeasures when open source issues occur within the company.
• The OSRB reports issues to the executive management when necessary and receives feedback on risk mitigation measures.

(2) Open Source Program Manager

The Open Source Program Manager is responsible for the overall responsibility of the company’s open source program. It has the following responsibilities to ensure the management activities of open source used in products and services:

• Defines the roles necessary for open source compliance and assigns the responsible organization and person for each role. Consults with the OSRB if necessary. The internal responsibility for open source security assurance is assigned by the security officer.
• Organizes and evaluates open source education.
• Serves as the chairman of the OSRB and directs activities.
• Responds to inquiries and requests related to open source use and compliance from outside.
• Reviews and approves open source use requests.
• Maintains SBOM records.
• Provides a way for members to receive open source related advice.
• Maintains a repository for open source notices and source code disclosure.

(3) OSPO

The Open Source Program Office (OSPO) supports and nurtures open source activities both inside and outside the company.

• It provides guidelines for contributing code to external open source projects.
• It provides guidelines for releasing internal projects as open source.
• It develops and operates an open source portal.
• It develops and selects open source tools.
• It sponsors open source project events.
• It manages relationships with open source communities.

(4) Legal Officer

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

• It provides a reasonable method for members to inquire about open source compliance issues.
• It provides advice on license and intellectual property issues, including conflicts due to incompatible open source licenses.
• It reviews necessary legal matters such as open source licenses, CLA (Contributor License Agreement), etc. when contributing to external open source projects.
• In acute cases, it requests advice from external law firms with open source specialist lawyers.

(5) IT Officer

The IT Officer operates open source analysis tools and automates them to build a system that allows open source analysis to be smoothly performed for all distributed software.

• It operates open source analysis tools.
• It integrates with the DevOps environment to automate open source analysis.
• It builds systems and processes to perform open source analysis for all distributed software.
• It secures and maintains SBOM for all distributed software.

(6) Security Officer

The Security Officer operates open source security vulnerability analysis tools to build a system that allows security vulnerability analysis to be smoothly performed for all distributed software.

• It assigns responsibilities for each task to ensure successful open source security assurance.
• It operates open source security vulnerability analysis tools.
• It integrates with the DevSecOps environment to automate open source security vulnerability analysis.
• It builds systems and processes to perform open source security vulnerability analysis for all distributed software.
• It provides a reasonable method for members to inquire about security vulnerabilities, and uses external expert technical advice if necessary to resolve vulnerabilities.

(7) Development Culture Officer

The Development Culture Officer supports in-house developers to actively use open source and participate in in-house and external communities to acquire advanced development culture.

• It encourages participation in open source communities.
• It creates a culture that recognizes active external open source project activities as in-house performance.
• It creates a development culture that can be recognized as an attractive company by open source developers.

(8) Quality Assurance Officer

The Quality Assurance Officer, such as QA, checks whether the open source license obligations have been properly performed when distributing software.

• It checks whether open source management activities are performed according to the development process stage.
• It checks whether the deliverables are created as required by the open source license.
• It checks whether the open source notice and the source code to be disclosed are provided together when distributing software.
• If there is an issue, it notifies the software development/distribution organization and guides them to correct the issue immediately.

5. Education and Evaluation

All members who are responsible for the roles defined in Chapter 4 must take the advanced open source education course provided by the [Learning Portal]. Through this, they will familiarize themselves with the open source policy, related education policy, and how to look it up.

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

6. 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, the software development/distribution organization complies with the following matters and all processes are recorded and preserved in the Jira Tracker.

(1) Open Source Identification and License Obligation Review

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 explains the obligations required by each license according to the following types of distribution:

• Binary form
• Source form
• Strong/Weak Copyleft
• SaaS-based provision
• Whether modified
• Including open source that requires author indication, etc.

The software development/distribution organization can refer to this guide when reviewing open source license obligations. If you need to review an open source license not mentioned in this guide, contact the open source program manager.

(2) Open Source License Consideration Design

Understand the combination relationship of open source and design the software architecture so that our 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 how to design to prevent the disclosure of our 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 distributed 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 distributed software.

Open source compliance deliverables are divided into two main categories.

1. Open Source Notice: A document for providing the full text of the open source license and copyright information
2. Source Code Package to be Disclosed: A package that collects the source code to be disclosed to fulfill the obligations of open source licenses that require source code disclosure, such as GPL, LGPL

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

• The open source notice or source code package 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 cannot 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 made public so that the repository of the collected deliverables can be accessed from the outside.

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

(4) Creation of SBOM (Bill of Materials)

You must create and manage the status of open source included in distributed 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 inquiry receipt and specify a reasonable resolution time.
2. Check whether the issue content is pointing out a real problem. (If not, inform 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) Open Source Vulnerability Response

• We identify open source vulnerabilities and evaluate their severity.
• Based on the analysis of open source vulnerabilities, we either fix the vulnerability or apply a security patch. The decision to address vulnerabilities takes into account the severity of the vulnerability, the importance of the system, and the availability of vulnerability fixes or security patches.
• We 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 and websites of security specialist organizations.

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.

(2) Only Contribute Code You Have the Right to Contribute

You should only contribute code that you have the right to contribute. In other words, you contribute code that you have written yourself. You should not arbitrarily contribute third-party code.

(3) Be Careful About Intellectual Property Exposure

Do not contribute code or documents that may expose sensitive information or company intellectual property, such as patents.

If the code you want to contribute contains a company patent, you need to check whether this patent can be contributed to the project under an open source license. If there is any ambiguity, contact the OSPO.

(4) Be Careful About Signing the CLA

Some open source projects require all contributors to sign the CLA (Contributor License Agreement). This is an agreement that seeks consent from contributors to reduce copyright disputes that can arise while the project manages the works of multiple contributors. Typically, projects led by large corporations require you to sign the CLA.

The CLA varies from project to project, but it usually contains the following:

• I (or my affiliated company) have the right to contribute the contribution I want to contribute to the project. (In other words, I am the author of this contribution.)
• I (or my affiliated company) grant the project the right to modify, distribute, and manage my contribution.
• I (or my affiliated company) will not revoke the granted rights.
• I (or my affiliated company) grant the project the right to change the license as needed in the future.

Also, although rare, some CLAs require agreement on the following conditions:

• I (or my affiliated company) transfer my copyright to the project or project management organization at the same time as I contribute my contribution.

The company does not allow contributions to open source projects that require copyright transfer to protect its intellectual property. To make this judgment, company members must request a review from the OSPO before signing if the open source project they want to contribute to requires signing the CLA.

(5) Copyright Notice

The intellectual property of the works created by members during their employment is basically owned by the company. Therefore, when members contribute code to an external open source project, they must indicate the company’s copyright.

When contributing one or more files, indicate the copyright and license at the top of the file as follows:

Copyright (c) {$year} {$Company}
SPDX-License-Identifier: {$SPDX_license_name}

Here, $SPDX_license_name is written according to the license policy of the open source project in question.

However, if you are modifying existing code for purposes such as bug fixes, you do not need to indicate copyright for the code modification.

(6) Use of Company Email

When contributing to an open source project, do not use personal email, use company email. Through this, (1) members have a sense of responsibility to communicate with the community on behalf of the company, and (2) the company can improve its recognition as a company that actively contributes to the open source community.

8. Open Source Release

The company respects the value of collaboration with the open source community and encourages the release of internal software to open source projects. However, there are a few rules to follow to protect the company’s intellectual property and prevent unintended copyright infringement.

(1) Approval

Open source release is granting anyone the right to modify, use, and distribute the work through an open source license from a copyright perspective. Generally, the copyright of works created during the employment period is owned by the employer. In other words, the works created by company members are owned by the company. The act of arbitrarily disclosing works to open source can trigger unnecessary copyright infringement issues.

Therefore, if you want to disclose software as open source, you must follow the review request and approval process according to the company’s open source release policy.

If there is anything that seems undesirable in the process of release, do not hesitate to contact the OSPO.

(2) Only Disclose Code You Have the Right to Disclose

One of the worst situations that can occur in an open source project is the inclusion of legally problematic code in the project. Code that the company does not have the right to distribute, or code that infringes on the IP of another company, such as a patent, can cause legal problems. Therefore, while preparing to disclose the code, check the source of all code and remove any code that may be problematic.

(3) Be Careful About Intellectual Property Exposure

Do not disclose code or documents that may expose sensitive information or company intellectual property, such as patents.

If the code you want to disclose contains a company patent, you need to check whether this patent can be disclosed under an open source license. If there is any ambiguity, contact the OSPO.

(4) Disclose Useful Code

In order to be a successful project, it must also be useful to others. If a similar project already exists, participate in the existing project rather than creating a new one.

The open source you want to disclose should (1) provide differentiated value to the open source community, (2) solve problems that the community has not been able to solve, and (3) be expected to attract positive attention by disclosing our technology.

• Do not disclose code that could not be used in actual products or services as open source.
• Do not disclose code that deals with problems already solved in the open source community. In this case, contribute to the existing open source project.

(5) Resource Allocation

• Secure the resources that need to be invested in the project.
• Initially, you need developers at a level similar to general internal projects.
• You need developers who can quickly review contributions from outside.
• The roles of the legal and marketing teams are also needed.

Secure a budget for the infrastructure needed to maintain and manage the project. This includes project hosting tools like GitHub. If you cannot create an environment that supports sufficient resources, do not disclose it as open source.

(6) Use of Company Email

When conducting open source release activities, use company email instead of personal email. This has the following benefits:

• Members have a sense of responsibility to communicate with the community on behalf of the company.
• The company can improve its recognition as a company that actively discloses to the open source community.

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 all or part of the processing of inquiries to appropriate personnel within the company. If necessary, consult with a legal officer to handle it.
• Anyone who receives an open source inquiry from outside informs the Open Source Program Manager so that a quick response can be made.

(2) Public Contact Information

The Open Source Program Manager provides contact information publicly so that outsiders can make inquiries and requests related to open source.

• Provide an email address where you can be contacted in the open source notice.
• Provide email address information on the open source website.
• Register your contact information in the Open Compliance Directory of the Linux Foundation.

(3) External Inquiry Response Procedure

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 external inquiry response procedure defined in the company’s open source process to respond to external open source inquiries.

10. Declaration and Maintenance of Compliance with ISO Standards

The company supports the spirit of the OpenChain project of the Linux Foundation for improving the level of open source compliance in the software supply chain and actively participates.

• The company guarantees compliance with ISO/IEC 5230:2020 as of October 1, 2021, by applying this open source policy.
• The company guarantees that it meets all the requirements of OpenChain Specification Version 2.1, ISO/IEC 5230:2020 for more than 18 months after obtaining conformity certification.
• The company reviews conformity at least every 18 months and changes and updates policies as needed.

Appendix 1. Status of Responsible Persons

2 - Open Source Process

The OO Company (hereinafter referred to as the “Company”) actively utilizes open source software in the development of products and services that include software. The Company must perform appropriate activities to detect open source security vulnerabilities and follow-up measures, and to comply with the obligations imposed by open source licenses when distributing software, in order to minimize open source risks. We follow the open source process to ensure these activities.

1. Open Source Process

The open source process defines the procedures that the Company must perform to comply with open source license obligations and resolve open source security vulnerabilities according to each development stage for developing and distributing software products and services. All members involved in the development/distribution of software products comply with the following 11 steps of the open source process.

The Company strives to provide safe and stable software products and services to customers by minimizing open source risks through the open source process.

The open source program manager should review the process at least once a year to spread internal best practices and improve areas that are lacking.

(1) Identification of Open Source

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

• Identify the foreseeable open source usage status and check the license when 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 departments of the entire company can refer to it. This guide should include the following use cases so that general open source license use cases can be managed.

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

The business department marks copyright and licenses in the source code according to the company’s rules. The company’s rules for marking copyright and licenses in the source code can be checked on the following page. (insert_link)

When the business department reviews the introduction of new open source, it first identifies the license. Check the license obligations, restrictions, and rights according to the company’s open source license guide. If it is a license 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, request advice from the legal manager and provide clear guidance.
• The newly analyzed license information is reflected in the company-wide license guide.

The security manager provides a guide for the company’s security assurance.

(2) Auditing Source Code

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

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

The open source program manager reviews whether the open source license obligations can be complied with and whether there is a conflict between the open source licenses, and if there is an issue, requests the business department to resolve it. Issue matters are created as Jira Tickets and assigned to the business department.

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

(3) Resolving Issues

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

Remove the open source that has become an 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 in which known vulnerabilities have been fixed are taken.

When the business department resolves all discovered issues, it resolves the Jira Ticket issue and requests a re-review.

(4) Reviews

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

The security manager reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, the possibility of approval is reviewed 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, it proposes a reason and a correction method to the business department.

(6) Registration

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

The IT manager registers the finalized BOM in the system. The BOM includes a list of open sources included in the software for distribution and the following information.

• Product (or service) name and version of the software for distribution
• Open source list
  • Open source name / version
  • Open source license

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

(7) Notices

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

• Open source contact that can be contacted for open source related inquiries
• 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

The open source program manager creates an open source notice and delivers it to the business department. At this time, if the source code needs to be disclosed, it guides the business department on how to collect the source code to be disclosed.

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

The business department collects the source code to be disclosed by checking the source code disclosure range when using open source under a license that requires source code disclosure such as GPL, LGPL, etc.

• The source code collected to comply with the obligations of licenses such as GPL, LGPL, etc. must match the source code that constitutes the binary loaded on the product. In other words, the collected source code should be the same as the binary loaded on the product when built.

(8) Pre-Distribution Verifications

The business department submits the following deliverables to demonstrate that open source compliance activities have been appropriately performed:

1. The final open source notice included in the product
2. Materials confirming the inclusion of the open source notice in the product (e.g., a screenshot showing the open source notice)
3. (If applicable) Source code to be disclosed (submitted as a single compressed file)

The open source program manager reviews the materials submitted by the business department to check for any issues.

(9) Distribution

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

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

(10) Final Verifications

The open source program manager comprehensively verifies whether the compliance deliverables have been properly registered on the company’s open source portal and whether they can be downloaded without issues from outside.

(11) Monitoring

The open source program manager periodically checks for products with inadequate generation of open source compliance deliverables. They also operate a process to respond quickly to external inquiries. The detailed procedure for responding to external inquiries follows [2. External Inquiry Response Process].

The security manager operates a process to monitor and respond to newly known vulnerabilities. The detailed procedure for responding to new security vulnerabilities follows [3. New Security Vulnerability Management Process].

2. New Security Vulnerability Management Process

We adhere to the following process to take appropriate action according to the risk when a new security vulnerability is reported after a product/service has been launched in the market.

(1) Monitoring

The IT manager operates a system to monitor new security vulnerabilities. This system performs the following functions:

• It periodically collects information about newly disclosed security vulnerabilities.
• If an open source with a newly known vulnerability is used in a product/service that has already been released, it sends a notification to the business department manager responsible for that product/service. From the notification to the review, action, and resolution, everything is documented using the Jira Issue Tracker.

(2) Initial Response

The security manager provides a response guide to the business department according to the predefined risk classification criteria. The risk is classified by the CVSS (Common Vulnerability Scoring System) score, and a plan that can be implemented within one week is recommended for Critical Risk.

If a product/service that has already been released has a new security vulnerability, the business department establishes an action plan according to the response guide provided by the security manager.

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

(3) Problem Resolution

The business department resolves the security vulnerability issue by deleting the problematic open source or replacing it with a patched version, according to the established action plan. Once all issues are resolved, a review is requested.

(4) Review

The IT manager uses open source analysis tools to confirm whether the problem has been appropriately resolved.

(5) Approval

The security manager 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 manager registers the SBOM, which has resolved the open source security vulnerability, in the system.

(7) Notification

The open source program manager generates 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 manager 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 issue.

The security manager identifies whether there is risk information that needs to be disclosed to third parties, and if there is, it is delivered to the IT manager.

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

3. External Inquiry Response Process

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, companies comply with the following process to respond to external open source compliance inquiries.

(1) Acknowledge

The open source program manager immediately notifies the requester that the inquiry has been received. At this time, the expected date of action is also notified. If the inquiry is unclear, additional explanation is requested to accurately understand the requester’s intention.

The main contents of the inquiries and requests that require a response 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
• Explanation and source code disclosure request for open source found in the product but not specified in the open source notice
• Request for provision of missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
• Request for copyright notice

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

(2) Inform

The open source program manager informs the requester that they are conducting open source compliance faithfully and that they are investigating the requester’s inquiry. It is good to notify whenever the internal investigation progress is updated.

(3) Investigate

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

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 that received the investigation request immediately checks whether there is a problem with the compliance deliverables and reports the results to the open source program manager.

(4) Report

The open source compliance manager completes the internal investigation within the scheduled 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 relevant open source license.

(5) Rectify / Notify

If an actual compliance issue is found in the internal investigation, the relevant business department performs all procedures necessary to resolve the compliance issue.

(6) Report

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

(7) Improve

In case of a compliance issue, the case is reviewed through the OSRB meeting, the circumstances of the occurrence of the problem are identified, and the process is improved so that the problem does not recur.