A Guide to Building Enterprise Open Source Governance Based on the International Standard ISO/IEC 5230

• 1: 1. Understanding ISO/IEC 5230
• 2: 2. Essential Elements
• 3: 3. Organization (Personnel)
• 4: 4. Policy
• 5: 5. Process
• 6: 6. Tools
• 7: 7. Training/Assessment
• 8: 8. Declaration of Conformance
• 9: Appendix
• 9.1: 1. Open Source Policy (Sample)
• 9.2: 2. Open Source Compliance Process (Sample)
• 9.3: 3. Tools (FOSSology, SW360)
• 9.3.1: FOSSology
• 9.3.2: SW360

1 - 1. Understanding ISO/IEC 5230

What is ISO/IEC 5230?

ISO/IEC 5230 is a specification created by the Linux Foundation’s OpenChain Project that defines the minimum core requirements for ensuring trustworthy open source compliance across the software supply chain.

Today’s software keeps growing in scale and complexity. Building a single piece of software can involve not only software developed in-house but also a wide range of software from across the supply chain, including open source, third-party software, and vendor SDKs.

If even one organization in this complex software supply chain fails to comply with its open source license obligations or fails to provide accurate information about its open source usage, the company distributing the final software has no choice but to fail at open source license compliance as well. This can result in lawsuits that force the company to halt sales of its product.

In December 2009, there was a lawsuit involving the open source project Busybox. Busybox is a GPL-2.0-licensed open source project widely used in embedded systems, and 14 companies, including two Korean companies, were named as defendants. What stood out about this case is that even companies that had not developed the product themselves, but had merely distributed it, were sued.

In such a complex software supply chain environment, it is extremely difficult for any single company, no matter how excellent its processes are, to achieve complete open source compliance on its own. In the end, for a company to properly implement open source compliance, every participant in the software supply chain must comply with license obligations and provide accurate open source information. This kind of trust must be built across the entire supply chain.

The Linux Foundation’s OpenChain project was founded on the belief that if the core requirements a company must meet for open source compliance are defined concisely and consistently, and everyone complies with them, trust regarding open source licensing can be built across the entire software supply chain.

At an open source conference in Europe in 2016, Dave Marr, an open source attorney at Qualcomm, emphasized exactly this point. To raise a company’s level of open source compliance, the level of open source compliance of every participant in the software supply chain must be raised. He also suggested that, to achieve this, advanced companies that already understand open source well and have established policies and processes could open up their assets and know-how so that anyone could reference them. Conference attendees agreed with the idea that “open source compliance is not an area where companies can differentiate their competitive advantage. Companies want an adequate level of risk management while investing minimal resources. That is why the more companies share their assets with one another, the more everyone can achieve compliance with fewer resources.” That is how the OpenChain project (then a Work Group) began, with the participation of numerous global companies including Qualcomm, Siemens, Wind River, ARM, and Adobe.

The OpenChain project provides companies with three main things to make it easier to achieve open source compliance.

1. The OpenChain Specification¹
2. OpenChain Conformance Certification²
3. Reference materials³

Let’s look at how companies can use each of these.

The OpenChain Specification and ISO/IEC 5230

The OpenChain Specification is a 10-page document that defines the core requirements for open source compliance. OpenChain Specification version 1.0 was released in 2016. The OpenChain Specification is designed to be applicable to any company, regardless of its size or industry.

Version 2.1 of the specification was released in 2020, and it defines six core requirements that a company must fulfill to achieve open source compliance, along with a list of the evidence needed to demonstrate each.

1. Establishing the program
2. Defining and supporting relevant roles
3. Reviewing and approving open source content
4. Creating and delivering compliance artifacts
5. Understanding engagement with open source communities
6. Complying with the specification’s requirements

For a company just starting out with open source compliance, a good strategy is to raise its maturity level by fulfilling these OpenChain Specification requirements one by one.

In December 2020, this OpenChain Specification was formally registered as the international standard⁴ for open source compliance.

The OpenChain Specification, which had been a de facto standard for the previous four years, was converted into the formal international standard ISO/IEC 5230:2020, the first international standard to define open source compliance and process management. As a result, interest in ISO/IEC 5230 compliance is growing among global IT companies, and more companies are expected to require their suppliers in the software supply chain to comply with ISO/IEC 5230.

How to Get Certified for ISO/IEC 5230

If a company complies with all of the requirements in ISO/IEC 5230, it can be certified as having an open source program that conforms to ISO/IEC 5230. An open source program refers to the set of management systems, including policies, processes, and personnel, that a company puts in place to carry out open source compliance activities.

The image below lists the item numbers required by ISO/IEC 5230. A company that satisfies all of these items can be recognized as having built a transparent and trustworthy open source governance system across its software supply chain.

The OpenChain project proposes three certification methods.

• Self Certification
• Independent Assessment
• Third-Party Certification

Let’s look at each method.

1. Self Certification

Self certification is the method most recommended by the OpenChain project, and it has the advantage of being free of charge. The OpenChain Project provides an OpenChain self-certification website so that companies can check for themselves whether they comply with the OpenChain Specification². A company’s open source manager can sign up on the OpenChain self-certification website and begin the online self-certification process. Self certification proceeds by answering Yes/No questions as shown below.

If a company has built a solid open source compliance system and can answer Yes to every question in OpenChain self-certification, it can submit these results on the website as a Conforming Submission. After a simple Q&A-style confirmation process by the Linux Foundation, the company can then declare ISO/IEC 5230 certification.

Once this certification declaration is made, the company is recognized in the Global Software Supply Chain as having an open source program that conforms to ISO/IEC 5230.

The OpenChain project recommends the self-certification approach. For reference, most companies that have declared OpenChain conformance have also adopted self certification.

Furthermore, through the self-certification process, a company can determine what it lacks and what additional activities are needed. This guide explains how to comply with the ISO/IEC 5230 requirements, organized by key components such as organization, policy, and process.

If a company lacks the capability to fill these gaps on its own using the guide alone, it can consider the independent assessment method.

2. Independent Assessment

In independent assessment, an independent organization outside the company examines and evaluates the company’s open source compliance status from a fair, external perspective. What distinguishes independent assessment is that it does not stop at producing an assessment report, but also provides consulting to help address the gaps that are identified. (Note, however, that it does not issue an official certificate.)

Through fair assessment and consulting from an independent organization, a company can raise its compliance level, and by repeating independent assessments, it can refine its policies and build out its processes.

Eventually, the company reaches a level at which it can obtain ISO/IEC 5230 certification, at which point it can proceed to self certification or third-party certification. In this way, independent assessment provides the evaluation and consulting needed to raise a company’s open source compliance level, supporting the company as it works to build an ISO/IEC 5230 conforming program and obtain certification.

Companies that provide independent assessment include AlektoMetis⁵ and Source Code Control⁶.

In Korea, the Conformance Group⁷, a subgroup of the OpenChain Korea Work Group, is a community where companies discuss and share methods for achieving ISO/IEC 5230 compliance among themselves. Any member of the OpenChain Korea Work Group can join and get help.

3. Third-Party Certification

If a company wants to demonstrate a more reliable and transparent level of open source compliance to buyers in the software supply chain, it can obtain a certificate from a third-party certification body and use it for promotional purposes. It is also expected that some buyers who demand stronger assurance of open source compliance reliability may require their suppliers to obtain third-party certification.

As of October 2021, OpenChain’s authorized third-party certification bodies are ORCRO⁸, PWC⁹, TÜV SÜD¹⁰, Synopsys¹¹, and Bureau Veritas¹².

These bodies provide assessments to confirm ISO/IEC 5230 conforming programs and issue certificates to companies that pass.

As of October 2021, there still appear to be no buyers or institutions that mandatorily require third-party certification. However, some experts in the European automotive industry predict that it will not be long before ISO/IEC 5230 becomes mandatory for automotive software suppliers, much like ASPICE (Automotive SPICE)¹³, the international standard process model for automotive software development.

For more detail on the self-certification method, you can also refer to the following slides.

• https://openchain-project.github.io/OpenChain-KWG/meeting/9th/OpenChain_Korea_20210311_howto.pptx

OpenChain Resources

The OpenChain project provides a variety of reference materials that companies need to build a compliance program, including policy document templates and training materials. These materials are designed to help organizations comply with the OpenChain Specification and support common open source compliance activities, and they are provided under a CC-0 license so that anyone can use them freely.

Much of the content in this guide was also written based on materials published by OpenChain. If a company’s open source manager needs policies, processes, or training materials, they should first check the OpenChain Resources. These materials are also translated into Korean and published. The OpenChain Korea Work Group¹⁴ leads this translation effort. Anyone interested can participate in the Korean translation work¹⁵.

The ISO/IEC 5230 Trend

In early 2021, news emerged that a German automaker had begun requiring its parts suppliers to plan for ISO/IEC 5230 compliance, and a European open source professor said, “It is clear that buyers in the software supply chain will increasingly require suppliers to comply with ISO/IEC 5230 going forward,” adding, “In the automotive industry, it will become like A-SPICE.”

Reflecting this trend, in May 2021, Scania, part of the Volkswagen Group, included a requirement for ISO/IEC 5230 compliance in its own corporate standard (STD 4589) that suppliers must follow.

Also, in July 2021, Bosch, an automotive and industrial technology company, declared that all of its group companies would have an ISO/IEC 5230 conforming program by the end of the year. Industry observers suggest it is only a matter of time before all automakers and companies in other industries begin requiring ISO/IEC 5230 within their software supply chains.

2 - 2. Essential Elements

Essential Elements of an Open Source Governance System

To build an efficient open source governance system, a company needs the following elements.

Among these elements, to build an open source governance system that fully meets all the requirements of ISO/IEC 5230, a company must basically have the following five elements in place. This section explains the details of each.

1. Organization (Personnel)
2. Policy
3. Process
4. Tools
5. Training/Assessment

3 - 3. Organization (Personnel)

Defining Roles and Responsibilities

To build a company’s open source governance system, a responsible person who takes charge of and carries out this task is needed first. This person may be called an Open Source Program Manager, Open Source Compliance Officer, or similar title, and is responsible for the company’s overall open source compliance.

A person with the following competencies is well suited for this role.

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

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

Global ICT companies are working to hire excellent Open Source Program Managers like this, and various job postings can be found at the following site: https://github.com/todogroup/job-descriptions

To build an open source governance system, a company must define the necessity of each role and determine what responsibilities should be assigned. In the case of a small company, it is possible for the Open Source Program Manager alone to perform all roles. Depending on the size of the company, an infrastructure officer to operate open source tools may also be needed, and a legal officer role to provide professional legal advice may be required.

In general, the following roles are needed to build a company’s open source governance system.

• Legal officer
• Infrastructure officer
• Development culture officer
• Security officer

By doing this, a company can prepare the following evidence materials required by ISO/IEC 5230.

Defining Required Competencies

Once each role and its responsibilities have been defined, the required competencies that personnel performing that role must have need to be identified. This is because the person in charge of each role must be assessed for whether they have the competency to perform that role, and training must be provided if needed.

By doing this, a company can prepare the following evidence materials required by ISO/IEC 5230.

Assigning Personnel

The Open Source Program Manager consults with the relevant departments to assign personnel for each role and documents this. Of course, to do this, the goals and direction for building the open source compliance system must be reported to top decision-makers such as the CEO in order to receive the necessary support.

The open source-related organization and personnel do not necessarily need to participate in open source work full-time. It is fine to form a virtual organization in the form of an OSRB (Open Source Review Board) to perform the necessary roles.

SK telecom has formed an OSRB to create open source policies and processes within the company and to prepare response measures when issues arise.

By doing this, a company can prepare the following evidence materials required by ISO/IEC 5230.

The table below is a sample personnel roster specifying the roles of the open source-related organization and personnel, along with the required competencies. A company can refer to this to organize and document its open source organization.

This content can also be found on the following page. : https://haksungjang.github.io/docs/openchain/#appendix-1-담당자-현황

Organizing in this way satisfies the following three requirements of ISO/IEC 5230.

4 - 4. Policy

Documenting the Open Source Policy

A company must establish and document an open source policy consisting of principles for the correct use of open source by every organization involved in software development, service delivery, and distribution, and must disseminate it throughout the organization.

A typical open source policy includes the following.

• Principles for building and distributing software products and services using open source
• Principles for contributing to external open source communities
• Principles for releasing the company’s software as open source

The following page provides a sample open source policy document that satisfies the ISO/IEC 5230 requirements: “Appendix 1. Sample Open Source Policy”

Each company can modify this sample policy to fit its own business strategy and environment.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Defining the Scope

A single open source policy (program) does not necessarily have to apply to the entire organization. The scope of application can vary depending on the characteristics of each organization and product within the company. Different open source programs can be applied by organization or by product. Likewise, an organization that does not distribute software at all can be excluded from the scope of the open source program. A company should clearly define the scope and limits of its open source program based on the characteristics of its organizations and products, and specify this in its open source policy.

As a company’s organizations, products, and services change to fit its business environment, situations may arise where the scope of the program needs to be determined or revised. A company should have a procedure in place to respond to this, such as the following example.

1. When starting a new project, the open source program manager determines whether the project falls within the scope of the program.
2. If it is determined not to fall within scope, a proposal to bring the project into the scope of the program is submitted to the OSRB.
3. If the OSRB accepts the proposal, the scope of the program is revised accordingly.
4. In addition, if the open source program manager determines that a review of the program’s scope is needed, they can initiate a review of the program’s scope through the same process.

The following example content can be included in an open source policy.

2. Scope
This policy applies to the following three areas.

1) It applies to all products the company provides or distributes externally.
   However, using open source solely for internal purposes is not
   within the scope of this policy.
2) It applies when a member contributes to an external open source project.
3) It applies when releasing internal code as open source.

The scope can be changed to fit the company's business environment,
and the procedure for doing so is as follows.

1) If the open source program manager determines that a change in the
   policy's scope is needed due to changes in the company's business
   environment, such as new business or organizational restructuring,
   they submit a proposal for this to the OSRB.
2) The OSRB approves an appropriate level of change to the scope.
3) The OSRB revises the open source policy to change the policy's scope.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Designating a Point of Contact for External Inquiries / Publishing Contact Information

Customers and open source copyright holders sometimes raise open source-related inquiries, requests, or claims to a company regarding products or services developed using open source. The main content of such external inquiries and requests includes the following.

• Inquiries about whether open source was used in a specific product or service
• Requests for the source code provided under a Written Offer for GPL or LGPL licensed code
• Requests for an explanation or the release of source code for open source found in a product that was not disclosed in the open source notice
• Requests for missing files or build instructions for source code released to satisfy GPL, LGPL, or similar obligations
• Requests for copyright attribution

A company must designate a person responsible for handling these external inquiries. This is typically the open source program manager.

Also, external open source developers sometimes want to contact a company’s point of contact to discuss an open source compliance issue but cannot find a way to reach them, and end up filing a legal claim directly. To prevent this, a company must always publicly disclose a way for third parties to make open source-related inquiries and requests to the company.

The ways in which external parties can make open source-related inquiries to a company are (1) publishing the email address of the company’s open source program manager, or (2) using the Linux Foundation’s Open Compliance Directory.

It is also good practice to publish the representative email address of the company’s open source program office in the open source notice that accompanies its products and services.

This content can be reflected in the open source policy as shown in the example below.

1. Responding 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 compliance from outside
the company.

The open source program manager can assign all or part of the
handling of an inquiry to an appropriate person within [Company].
If necessary, the legal team is consulted for handling.
Anyone who receives an external inquiry about open source
compliance should notify the open source program manager so that
a prompt response can be made.

(2) Publishing Contact Information
The open source program manager publicly provides the contact
information of the responsible person so that external parties
can make open source-related inquiries and requests.

* Provide contact email address information in the open source notice.
* Register contact information in the Linux Foundation's Open
  Compliance Directory.

(3) Procedure for Responding to External Inquiries
Responding quickly and accurately to external open source
compliance inquiries can greatly reduce the risk of escalation
to litigation. To this end, the company complies with the
external inquiry response procedure defined in the open source
compliance process to respond to external open source compliance
inquiries.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Providing Staffing, Budget, and Other Support

A company must provide sufficient resources so that its open source program can function smoothly. It must appropriately staff each role within the program and ensure adequate budget and working hours. If it cannot, it must have a procedure in place to compensate for this. The following example wording can be added to the open source policy document.

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 so that person can carry out the role
faithfully. If a person responsible for a role feels they are not
receiving adequate support in carrying it out, they must raise the
issue with the open source program manager. The open source
program manager discusses resolving the issue with the relevant
head of organization. If it is not resolved appropriately, the
open source program manager can ask the OSRB to help resolve the
issue. The OSRB shares the issue with the head of the higher-level
organization and requests a resolution.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Providing Legal Counsel

A company must provide a way for the person responsible for each role to seek legal counsel when a legal review is needed to resolve an open source compliance issue. This should first be provided through the company’s in-house legal team, and for particularly sensitive issues, an outside law firm with open source-specialized attorneys can be used. An example of an open source policy for this is as follows.

4. Roles, Responsibilities, and Competencies

(2) Open Source Program Manager
* The open source program manager provides a way for members to
  obtain open source-related legal counsel.
* The open source program manager decides whether to engage an
  outside law firm. The effectiveness and appropriateness of
  outside legal counsel is evaluated and reviewed annually by the
  open source program manager.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

For reference, through its partner program, the OpenChain project provides a list of global law firms that offer open source-related legal counsel: https://www.openchainproject.org/partners

Law firms registered as OpenChain partners meet the requirements set by the OpenChain project, and Bae, Kim & Lee LLC is currently the only law firm registered from Korea.

Procedure for Assigning Internal Responsibility

There must be a procedure for assigning internal responsibility for open source compliance. This is the role of the open source program manager. The open source program manager must identify issues and appropriately assign them to the person responsible for each role. To this end, a company can describe this content in its open source policy document as follows.

4. Roles, Responsibilities, and Competencies

(2) Open Source Program Manager

The open source program manager is overall responsible for the
company's open source program. To ensure open source compliance
for products and services that use open source, they are
responsible for the following.

* Define the roles needed for open source compliance and
designate the responsible organization and person for each role.
Consult with the OSRB as needed.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Handling Non-Compliant Cases

A company must document a procedure for promptly reviewing and responding to non-compliant cases. The following example can be included in an open source policy for reference.

1. Open Source Use

(5) Compliance Issue Remediation Procedure
When a compliance issue is raised, the open source program manager
performs the following procedure to respond promptly.

1. Acknowledge receipt of the inquiry and specify an appropriate
   resolution time.
2. Confirm whether the issue content points to an actual problem.
   (If not, inform the person who raised the issue that it is not
   a problem.)
3. If it is an actual problem, determine priority and decide on an
   appropriate response.
4. Carry out the response, and if necessary, appropriately update
   the open source compliance process.
5. Retain the above content using the Jira Tracker.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Open Source Contribution Policy

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

For this open source contribution policy, you can refer to 7. Open Source Contribution in the NIPA OpenChain Guide’s Appendix 1. Sample Open Source Policy.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Once a company establishes an open source policy that includes the content above, it satisfies the following ISO/IEC 5230 requirements.

5 - 5. Process

Process is the actionable procedure that enables a company to comply with its open source policy during software development and deployment. Simply put, the open source compliance process consists of activities to comply with the conditions required by each license for the open source used while developing and distributing software, and it produces artifacts such as open source notices and source code to be disclosed.

Breaking down the open source compliance process into more detail gives the diagram below.

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

For more details, refer to the following page. : https://haksungjang.github.io/docs/openchain/#부록-2-샘플-오픈소스-컴플라이언스-프로세스

This chapter describes the components that the open source compliance process should include.

Open Source Identification and Auditing

To determine whether open source can be used, it is first necessary to identify the license of the open source to be used and check the obligations required by the license. Whether open source was used, what the license is, and what obligations each license imposes must be reviewed and recorded. An example procedure for this is as follows.

1. The development department performs a preliminary evaluation of the license according to the criteria defined in the open source policy.
2. Any questions are directed to the Open Source Program Manager, and if necessary, the Open Source Program Manager requests advice from an external legal expert.
3. All internal and external decision results and related grounds are retained.

The Identification, Auditing, Resolving Issues, Review, and Approval steps in “Appendix 2. Sample Open Source Compliance Process"’s 1. Identification of Open Source are an example of a documented procedure for reviewing and recording the obligations and restrictions imposed by each identified license.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Source code scanning tools can be used at the open source identification and auditing stage. This is explained in detail in “6. Tools”.

Open Source BOM Identification, Review, and Archiving

The most fundamental part of open source compliance activities is understanding the status of open source contained in Supplied Software. A process must be established for creating and managing a Bill of Materials (BOM) that identifies the open source and its licenses included in Supplied Software and contains that information. This is because knowing which open source is included in each version of Supplied Software is necessary to comply with the obligations required by each open source license when distributing the software.

All open source must be reviewed and approved before being integrated into Supplied Software. A prior review is needed not only for the function and quality of the open source but also for whether its origin and license requirements can be met. This requires a process of review request → review → approval.

Appendix 2. Sample Open Source Compliance Process describes the entire process for a company’s open source compliance. The BOM is created and managed through the steps from 1. Identification of Open Source to 6. Registration.

Tools for managing the open source BOM are explained in detail in “6. Tools”.

In addition, all processes and results of this open source compliance process must be documented. Using an issue tracking system such as Jira or Bugzilla, rather than email, can document this process more efficiently.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Generating Open Source Compliance Artifacts

As mentioned above, the most fundamental part of open source compliance activities is understanding the status of open source contained in Supplied Software. This is precisely to correctly fulfill the open source license requirements that are the core of open source compliance. In other words, a process must be established for generating a set of compliance artifacts for the open source contained in Supplied Software.

Compliance artifacts are broadly divided into two types.

1. Open source notice: A document providing the full text of the open source license and copyright information

   

   • How to generate an open source notice corresponding to the open source BOM collected using a tool is further explained in “6. Tools”.

2. Source code package to be disclosed: A package that collects the source code to be disclosed in order to fulfill the obligations of open source licenses, such as GPL and LGPL, that require source code disclosure

Compliance artifacts must be provided together when Supplied Software is distributed. Compliance artifacts are generated and distributed through the Notices and Distribution steps of “Appendix 2. Sample Open Source Compliance Process”.

If it is difficult to enclose the source code package to be disclosed when distributing Supplied Software, this can be replaced by providing a Written Offer to provide the source code for at least three years. A Written Offer is generally provided through the product’s user manual, and an 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 artifacts must be retained for at least three years, and a process must be established for this. To do this, a company should consider building an open source website, which is explained in detail in “6. Tools”.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Responding to External Inquiries

To avoid facing legal action due to external claims, it is important for a company to respond to external inquiries and requests as quickly and accurately as possible. To do this, a company must have a process in place to respond quickly and effectively to external open source inquiries.

The figure below is the process a company should have in place to respond to external inquiries.

https://haksungjang.github.io/docs/openchain/#2-외부-문의-대응-프로세스

Details can be found in “Appendix 2. Sample Open Source Compliance Process, 2. External Inquiry Response Process”.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Open Source Contribution Process

If a company has a policy that allows contributions to external open source projects, there must be a documented procedure governing the process by which internal developers can contribute to external projects.

The open source contribution process published by SK telecom is a good example.

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

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Building the process up to this point results in compliance with the ISO/IEC 5230 requirements as shown below.

6 - 6. Tools

Source Code Scanning Tools

Source code scanning tools can be used in the open source identification and auditing stage of the open source compliance process. Source code scanning tools range from free, open source-based tools to commercial tools, and each tool has its own strengths, but none provides complete functionality that can solve every problem. Therefore, a company must select the tool that best fits the characteristics and requirements of its product.

Many companies use these automated source code scanning tools alongside manual review. The Linux Foundation’s FOSSology project is a source code scanning tool released as open source, which companies can easily use for free.

For how to install and use FOSSology, refer to Appendix 3. Open Source Tools.

Dependency Analysis Tools

Modern software development uses build environments that support package managers such as Gradle and Maven. In these build environments, even without the source code present, the dependency libraries needed at build time are fetched from a remote location to compose Supplied Software. These dependency libraries are included in Supplied Software but are not detected by source code scanning tools. Therefore, it is also important to use tools for dependency analysis.

The open source OSS Review Toolkit provides a dependency analysis tool called Analyzer.

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

Open Source BOM Management Tools

Clause 3.3.1.2 of the ISO/IEC 5230 specification requires that the open source BOM list contained in Supplied Software be documented and retained. The open source BOM can be managed using a spreadsheet program such as Excel. However, when the number and versions of Supplied Software exceed several hundred, managing this manually is not easy. It is advisable to adopt an open source automation tool for this purpose.

SW360, an open source project sponsored by the Eclipse Foundation, provides functionality to track the list of open source included in each Supplied Software.

For how to install and use SW360, refer to Appendix 3. Open Source Tools.

In addition, FOSSLight, the open source released by LG Electronics mentioned above, also provides functionality for open source BOM management.

LG Electronics developed FOSSLight in-house and has used it to manage the open source BOM for Supplied Software across its entire business divisions for several years, and in June 2021 announced that it had released it as open source for anyone to use.

Detailed installation and usage instructions are provided in a Korean-language guide, which is expected to be of great help to domestic Korean companies.

Adopting such a tool allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Generating Open Source Compliance Artifacts

Among the open source compliance artifacts, it is advisable to use a tool that automatically generates the open source notice rather than creating it manually.

Registering the open source BOM in FOSSLight automatically generates the open source notice. The open source notice generated by FOSSLight also includes a Written Offer for the source code to be disclosed.

In addition, SK telecom plans to release its internal open source notice auto-generation tool as open source, so using it in the future would also be a good option.

Archiving Open Source Artifacts

It is advisable for a company to build an open source website and register open source compliance artifacts there, so external customers can conveniently download the open source notice and source code package for Supplied Software at any time.

SK telecom’s open source website can be referred to as an example.

In particular, this website was developed as open source and its source code is publicly available, so other companies can easily build a similar website.

Building such a tool environment allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Building the tool environment up to this point results in compliance with the ISO/IEC 5230 requirements as shown below.

7 - 7. Training/Assessment

Training

No matter how excellent a policy and process a company has built, it will be useless if none of the company’s members pay attention to it. For the open source policy and open source compliance process to work effectively in a company, training its members is important.

A company must provide practical means, such as training and an internal wiki, so that all Program participants are aware that the organization has an open source policy and can carry out the necessary activities. Here, Program participants refers to all employees involved in the company’s software development, distribution, and contribution, including software developers, deployment engineers, and quality engineers.

Many companies publish their open source policy document on an internal wiki site so that any employee can check what is needed. In addition, they make training on the open source policy mandatory during new employee orientation and provide periodic training to Program participants annually or once every two years, so that all Program participants are aware of the existence of the open source policy. That is, a company should include such methods in its open source policy document, written as in the example below.

1. Training and Assessment

All Software Distribution participants must complete the mandatory open source
training provided on the [Learning Portal] every year.
This ensures familiarity with the open source policy, related training policy, and
how to look it up. Training records are retained on the [Learning Portal].

Building such a training environment allows a company to prepare the following evidence materials required by ISO/IEC 5230.

In addition, a company must make Program participants aware of the company’s open source policy, open source-related objectives, how participants can contribute to an effective open source program, and the implications of failing to comply with Program requirements. To do this, a company provides training and conducts an assessment to confirm that Program participants have understood correctly. The assessment results are documented and retained.

A company can include content such as the example below in its open source policy for this purpose.

1. Purpose
  (1) Purpose of the policy
    This policy provides the following principles so that the entire organization
    involved in the company's software development, service, and distribution can
    make proper use of open source.

    1) Principles for performing compliance in consideration of open source licenses
    2) Principles for contributing 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.

  (2) Impact of non-compliance
   Failure to comply with this policy may result in the following situations.
   * Receiving demands from external parties for open source license compliance.
   * Being forced to disclose company-developed source code against its wishes.
   * Facing legal action from open source copyright holders.
   * Being fined or receiving a product sales suspension order for copyright
     infringement and breach of contract.
   * Loss of company reputation.
   * Breach of contract with suppliers, resulting in claims for damages.
  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 action.

  (3) How members can contribute
    All members 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 carrying out the necessary
    activities.

Assessment is explained in more detail below.

Including such training content in the policy allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Open source training also includes content about the open source contribution policy. Even if an open source contribution policy has been created, if internal members are unaware of its existence, there is a risk that indiscriminate contribution activities could cause harm to individuals and the company. Open source training is provided so that all internal developers are aware of the existence of the open source contribution policy.

Providing training on the contribution policy in this way allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Creating new training materials from scratch can also be a difficult task for someone just starting this role. To help with this difficulty, NCSOFT published its internal open source training materials, including the lecture slides (PPT) and lecture script, on GitHub so anyone can use them.

In addition, Kakao, a leading domestic platform company, has also released its open source training materials for internal developers so that anyone can view them.

If training materials have not yet been created, using the open source training materials of these companies with excellent open source management practices is also a good option.

Assessment

Once a company has assigned personnel to each role, it must confirm that the assigned personnel are qualified to perform the role based on education, training, and experience. Training must also be provided to Program participants with insufficient competency so they can acquire sufficient competency. The company must also assess whether each participant has the necessary competency and retain the results.

1. The company provides training so that each participant can acquire the required competency.
2. An assessment is conducted based on the training content.
3. The assessment results are retained by the company’s training system or HR department.

When there are several hundred or more Program participants, making training difficult to provide, using the company’s online training and assessment system is also a good option.

Such content can be included in a company’s open source policy as follows.

4. Roles, Responsibilities, and Competencies
To ensure the effectiveness of this policy, the roles, responsibilities, and the
competencies required of the person in charge of each role are defined as follows.
The organization/person in charge of each role and the required competency level
are defined in "Appendix 1. Personnel Roster".

5. Training and Assessment
All members responsible for each role defined in Chapter 4 must complete the
open source training provided on the [Learning Portal].
Training records and assessment results are retained on the [Learning Portal]
for at least three years.

Having such a training and assessment system in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Open Source License Guide

To properly comply with open source licenses, one must accurately know the requirements of each open source license. However, since it is difficult for individual software developers to grasp all of this, it is advisable for the Open Source Program Manager to organize the requirements and precautions for common use cases of frequently used open source licenses and share them internally within the company.

The open source license guide should include the requirements for common open source license use cases, enabling the development department to correctly comply with license obligations while using open source.

For general guidance on open source licenses and summarized license obligation materials, the License Guide provided by the Korea Copyright Commission can be referenced.

The License Obligations document in SK telecom’s open source guide is also a good resource.

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

Providing such an open source license guide allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Building the environment for training, assessment, and guide provision up to this point results in compliance with the ISO/IEC 5230 requirements as shown below.

8 - 8. Declaration of Conformance

A company that has built an open source program (open source policy / process / tools / organization) that complies with all requirements of the ISO/IEC 5230 specification except Clause 6 may prepare and publish a document stating the following two items.

1. That the company’s open source program meets all requirements of OpenChain Specification 2.1
2. That the company’s open source program guarantees it has maintained compliance with all requirements of OpenChain Specification 2.1 for at least 18 months after obtaining conformance certification

A company can either include the above content in its open source policy or publish it on a publicly available website.

As shown in the image below, you can refer to how SK telecom published this content on its open source portal site. https://sktelecom.github.io/compliance/iso5230/

By documenting in this way that all requirements of ISO/IEC 5230 are guaranteed to be met, a company can prepare the following evidence materials required by ISO/IEC 5230.

Once this is completed, a company finally meets all the requirements of ISO/IEC 5230.

9 - Appendix

9.1 - 1. Open Source Policy (Sample)

1. Purpose

(1) Purpose of the Policy_(3.1.3.1)

This policy provides the following principles for the correct use of open source software (hereinafter “Open Source”) by every organization at [Company Name], Inc. (hereinafter “the Company”) that is involved in software development, service delivery, and distribution.

1. Principles for carrying out compliance with open source licenses
2. Principles for contributing to external open source projects
3. Principles for releasing internal projects as open source

These principles give every member of the Company a way to understand the value of open source, use open source correctly, and contribute to open source communities.

All members of the Company can find the open source policy at the following link on the internal wiki: [internal_link]_(3.1.1.1)

(2) Impact of Non-Compliance

Failure to comply with this policy can result in the following situations.

• The Company receives demands from outside parties to comply with open source licenses.
• The Company is forced to release source code it did not intend to release.
• The Company faces legal action from open source copyright holders.
• The Company is fined for copyright infringement or breach of contract, or is ordered to stop selling a product.
• The Company’s reputation suffers.
• The Company breaches a contract with a supplier and faces a claim for damages.

For these reasons, the Company treats violations of this open source policy as serious, and members or organizations that violate it may be subject to disciplinary action.

(3) How Members Can Contribute

All members of the Company can contribute to the effectiveness of this policy and to raising the Company’s compliance level by understanding the rationale and content of this policy and faithfully carrying out the required activities.

2. Scope_(3.1.4.1)

This policy applies to the following three areas.

1. It applies to [all products the Company provides or distributes externally]. However, using open source solely for internal purposes is not within the scope of this policy.
2. It applies when a member contributes to an external open source project.
3. It applies when releasing internal code as open source.

The scope can be changed to fit the Company’s business environment, and the procedure for doing so is as follows.

1. If the open source program manager determines that a change in the policy’s scope is needed due to changes in the Company’s business environment, such as new business or organizational restructuring, they submit a proposal for this to the OSRB.
2. The OSRB approves an appropriate level of change to the scope.
3. The OSRB revises the open source policy to change the policy’s scope.

3. Terminology

• BOM (Bill of Materials)
• Software distribution participant: refers to any employee involved in the Company’s development, distribution, or contribution of software, including software developers, release engineers, and quality engineers.
• …

4. Roles, Responsibilities, and Competencies_(3.1.2.1)

To ensure the effectiveness of this policy, the following roles, responsibilities, and the competencies required of each role’s assignee are defined.

The organization/person responsible for each role and the required competency level are defined in [Appendix 1. Roster of Responsible Parties]._(3.1.2.2)

• The open source program manager periodically updates the roster to fit the Company’s business situation._(3.2.2.1)
• The head of the organization responsible for each role designates a person in charge within the organization and allocates appropriate time and budget so that person can carry out the role faithfully._(3.2.2.2)
  • If a person responsible for a role feels they are not receiving adequate support in carrying it out, they must raise the issue with the open source program manager.
  • The open source program manager discusses resolving the issue with the relevant head of organization. If it is not resolved appropriately, the open source program manager can ask the OSRB to help resolve the issue.
  • The OSRB shares the issue with the head of the higher-level organization and requests a resolution.

(1) OSRB

The OSRB (Open Source Review Board) is a body composed of the open source program manager and the heads of relevant organizations, including Legal, Patents, Development, and Infrastructure, formed for the Company’s open source compliance.

• It creates the policies and processes for open source compliance and defines the roles and responsibilities within the Company for carrying them out.
• When an open source compliance issue arises within the Company, it discusses solutions and prepares a response.
• When necessary, it reports issues to executive leadership and obtains feedback on risk mitigation measures.

(2) Open Source Program Manager

The open source program manager is overall responsible for the Company’s open source program. To ensure open source compliance for products and services that use open source, they are responsible for the following._(3.2.2.4)

• Define the roles needed for open source compliance and designate the responsible organization and person for each role. Consult with the OSRB as needed.
• Organize and evaluate open source compliance training.
• Chair the OSRB and direct its activities.
• Respond to inquiries and requests from outside parties about open source use and compliance.
• Review and approve requests to use open source.
• Maintain records of the open source BOM.
• Provide members with a way to obtain open source-related legal counsel._(3.2.2.3)
• Maintain a repository for open source notices and source code releases.

(3) OSPO

The OSPO (Open Source Program Office) supports and fosters the growth of open source activity both inside and outside the Company.

• Establishes, improves, and disseminates the open source policy.
• Provides guidance for contributing code to external open source projects.
• Provides guidance for releasing internal projects as open source.
• Develops and operates the open source portal.
• Develops and selects open source tooling.
• Sponsors open source project events.
• Manages relationships with open source communities.

(4) Legal

Legal provides counsel on the legal risks that can arise in the course of using open source, and on mitigation measures, including interpreting open source licenses and obligations.

• Provides counsel on license and intellectual property issues, including conflicts arising from incompatible open source licenses.
• Reviews the legal matters required for contributing to external open source projects, including the open source license and the CLA (Contributor License Agreement).

(5) IT Infrastructure

IT Infrastructure operates and automates open source analysis tooling, and builds the systems needed to ensure license analysis is carried out smoothly for all distributed software.

• Operates open source license analysis tooling.
• Integrates with the DevOps environment to automate license analysis.
• Builds the systems and processes needed to ensure license analysis is performed on all distributed software.
• Obtains and maintains the open source BOM for all distributed software.

(6) Security

Security operates open source security vulnerability analysis tooling and builds the systems needed to ensure security vulnerability analysis is carried out smoothly for all distributed software.

• Operates open source security vulnerability analysis tooling.
• Integrates with the DevSecOps environment to automate open source security vulnerability analysis.
• Builds the systems and processes needed to ensure open source security vulnerability analysis is performed on all distributed software.

(7) Developer Relations

Developer Relations supports in-house developers so they can actively use open source, participate in internal and external communities, and adopt leading development practices.

• Encourages participation in open source communities.
• Fosters a culture that recognizes active external open source project activity as an internal accomplishment.
• Builds a development culture that makes the Company attractive to open source developers.

(8) Quality

The organization responsible for quality, such as QA, confirms that open source license obligations were properly carried out when software is distributed.

• Confirms that open source compliance activities were carried out at each stage of the development process.
• Confirms that the artifacts required by the open source licenses were produced.
• Confirms that the open source notice and any source code to be released are provided together with the distributed software.
• Notifies the software development/distribution organization of any issues found so they can be corrected immediately.

5. Training and Assessment

Every software distribution participant must complete the mandatory open source training provided on the [Learning Portal] each year. This ensures they are familiar with the open source policy, the related training policy, and how to look it up. Training records are retained on the [Learning Portal]._(3.1.1.2)

Every member responsible for a role defined in Section 4 must complete the advanced open source training course provided on the [Learning Portal]. Training records and assessment results are retained on the [Learning Portal] for at least three years._(3.1.2.3)

6. Open Source Use

To develop and distribute products and services using open source, the obligations required by each open source license must be complied with. This activity is called open source compliance.

To carry out open source compliance correctly, the software development/distribution organization must comply with the following._(3.3.1.1)

• Every step of the open source compliance process is recorded and retained in the Jira Tracker.

(1) Identifying Open Source and Reviewing License Obligations

When introducing open source into product/service development, first identify what open source license applies, and review and confirm the obligations the license requires.

The Company’s [Open Source License Guide] includes a list of major open source licenses, and for each license, it separately explains the obligations required for each of the following distribution forms._(3.3.2.1)

• Binary form
• Source form
• Strong/weak copyleft
• SaaS-based delivery
• Whether modified
• Inclusion of open source requiring attribution, and so on.

The software development/distribution organization can refer to this guide when reviewing open source license obligations. If a review is needed for an open source license not covered in this guide, contact the open source program manager.

(2) Designing with Open Source Licenses in Mind

Identify the combination relationships of open source components and design the software architecture so that the Company’s own code is not affected by open source license terms.

The Company’s [Open Source License Guide] explains, for each open source license, the scope of source code disclosure it requires and design methods for preventing disclosure of the Company’s own code.

(3) Producing Open Source Compliance Artifacts

The most basic part of open source compliance activity is understanding the open source contained in distributed software. This is precisely so that the open source license requirements at the core of open source compliance can be correctly satisfied. In other words, a set of compliance artifacts must be produced for the open source contained in distributed software._(3.4.1.1)

Open source compliance artifacts fall into two broad categories.

1. Open source notice: a document providing the full text of each open source license and copyright information
2. Source code package to be released: a package assembling the source code to be released to fulfill the obligations of open source licenses that require source code disclosure, such as GPL and LGPL

To assemble, distribute, and store these compliance artifacts, the following must be complied with._(3.4.1.2)

• Assemble the open source notice and the source code package to be released according to the conditions each license requires. For example, if a license requires that the full text of the license be included, providing only a link is not sufficient.
• Store the assembled artifacts in a separate repository.
• When providing source code to be released through a Written Offer, publish a download link so that external parties can access the repository of assembled artifacts.

The Company’s open source compliance process can be used to issue the open source notice and assemble the source code package to be released.

(4) Producing the Open Source BOM (Bill of Materials)

The open source contained in distributed software (BOM: Bill of Materials) must be produced and maintained._(3.3.1.2)

The Company’s open source compliance process can be used to produce and retain the open source BOM using open source tooling.

(5) Compliance Issue Remediation Procedure

When a compliance issue is raised, the open source program manager performs the following procedure to respond promptly._(3.2.2.5)

1. Acknowledge receipt of the inquiry and specify an appropriate resolution time.
2. Confirm whether the issue content points to an actual problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is an actual problem, determine priority and decide on an appropriate response.
4. Carry out the response, and if necessary, appropriately update the open source compliance process.
5. Retain the above content using the Jira Tracker.

7. Open Source Contribution

The Company encourages participation in and contribution to external open source projects to create business value from open source. However, approaching this without sufficient understanding of and strategy for the open source project ecosystem and how communities operate can lead to unintended exposure of the Company’s intellectual property or infringement of third-party rights. For this reason, when a member of the Company contributes to an external open source project, the following must be complied with._(3.5.1.1)

(1) Requesting Review and Approval

From a copyright standpoint, an open source contribution grants the open source project the right to modify, use, and distribute the contributed work. In some cases, it may even require assigning your copyright to the open source project. However, the copyright to a work created during a period of employment generally belongs to the employer. In other words, a work created by a Company member belongs to the Company. If a member contributes a work to open source on their own judgment, it can create unnecessary copyright infringement issues.

Therefore, if there is an open source project you wish to contribute to, follow the review request and approval procedure defined by the open source contribution process before making your first contribution.

However, for the following kinds of simple content, the copyright infringement risk is low, so members may contribute based on their own judgment without going through the review procedure.

• Small code snippets of 10 lines or fewer
• Questions and answers on Stack Overflow
• Administrative activity on GitHub, such as creating issues or reviewing/approving pull requests

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

Contribute only code you have the right to contribute. That is, contribute code you wrote yourself. Do not contribute third-party code on your own judgment.

(3) Beware of Intellectual Property Exposure

Do not contribute code or documents that raise concerns about exposing the Company’s intellectual property, such as sensitive information or patents.

• If the code you wish to contribute includes a Company patent, you must confirm whether it is acceptable to contribute that patent to the project under an open source license. If anything is unclear, contact the OSPO.

(4) Caution with CLA Signatures

Some open source projects require every contributor to sign a CLA (Contributor License Agreement). This is an agreement used to obtain contributors’ consent in order to reduce copyright disputes that can arise as a project manages the works of many contributors. Projects led by large corporations commonly require a CLA signature.

CLAs vary by project, but they generally include agreement to the following.

• I (or my employer) have the right to contribute the contribution I intend to contribute to the project. (That is, I am the author of this contribution.)
• I (or my employer) grant the project the right to modify, distribute, and manage my contribution.
• I (or my employer) will not revoke the granted rights.
• I (or my employer) grant the project the right to change its license in the future as needed.

In addition, though rare, some CLAs also require agreement to the following condition.

• I (or my employer), upon contributing my contribution, simultaneously assign my copyright in it to the project or the organization managing the project.

To protect its own intellectual property, the Company does not permit contributions to open source projects that require copyright assignment. To make this determination, a Company member must request a review from the OSPO before signing, if the open source project they wish to contribute to requires a CLA signature.

(5) Copyright Notice

The intellectual property of a work created by a member during their employment generally belongs to the Company. Accordingly, when a member contributes 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 relevant open source project.

However, if you are only modifying existing code, such as for a bug fix, there is no need to add a copyright notice for that code change.

(6) Use of Company Email

Do not use a personal email address when contributing to open source projects; use your Company email address. This (1) gives members a sense of responsibility as they communicate with the community on the Company’s behalf, and (2) helps improve the Company’s recognition as one that actively contributes to open source communities.

8. Open Source Release

The Company respects the value of collaboration with open source communities and encourages releasing internal software as open source projects. However, there are some rules that must be followed to protect the Company’s intellectual property and prevent unintended copyright infringement.

(1) Approval

From a copyright standpoint, an open source release grants anyone the right to modify, use, and distribute the work through an open source license. The copyright to a work created during a period of employment generally belongs to the employer. In other words, a work created by a Company member belongs to the Company. If a member releases a work as open source on their own judgment, it can create unnecessary copyright infringement issues.

Therefore, if you wish to release software as open source, follow the review request and approval procedure under the Company’s open source release policy.

If anything about the release process seems questionable, do not hesitate to contact the OSPO.

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

One of the worst situations that can arise in an open source project is the inclusion of legally problematic code in the project. Code the Company does not have the right to distribute, or code that infringes another company’s IP such as a patent, can create legal problems. Therefore, when preparing code for release, verify the origin of all code and remove any code that raises concerns.

(3) Beware of Intellectual Property Exposure

Do not release code or documents that raise concerns about exposing the company’s intellectual property, such as sensitive information or patents.

If the code you wish to release includes a Company patent, confirm whether it is acceptable to release that patent under an open source license. If anything is unclear, contact the OSPO.

(4) Release Useful Code

For a project to succeed, 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 plan to release should be expected to (1) provide differentiated value to the open source community, (2) solve a problem the community has not yet solved, and (3) draw positive attention by showcasing our technical capability.

• Do not release code as open source if it has not been used in an actual product or service.
• Do not release code that addresses a problem the open source community has already solved. In such cases, contribute to the existing open source project instead.

(5) Securing Resources

Secure the resources, including developers, that need to be committed to the project.

• Initially, a level of developer effort similar to a typical internal project is needed.
• Developers are needed who can quickly review external contributions.
• Roles from Legal and Marketing are also needed.
• Secure budget for the infrastructure required to maintain and manage the project. This includes tools for project hosting, such as GitHub.

If an environment with sufficient resource support cannot be created, do not release the software as open source.

(6) Use of Company Email

Do not use a personal email address for open source release activity; use your Company email address. This (1) gives members a sense of responsibility as they communicate with the community on the Company’s behalf, and (2) helps improve the Company’s recognition as a company that actively releases open source.

9. Responding 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 compliance from outside the Company._(3.2.1.2)

• The open source program manager can assign all or part of the handling of an inquiry to an appropriate person within the Company. If necessary, the legal team is consulted for handling.
• Anyone who receives an external inquiry about open source compliance should notify the open source program manager so that a prompt response can be made.

(2) Publishing Contact Information

The open source program manager publicly provides the contact information of the responsible person so that external parties can make open source-related inquiries and requests._(3.2.1.1)

• Provide contact email address information in the open source notice.
• Register contact information in the Linux Foundation’s Open Compliance Directory.

(3) Procedure for Responding to External Inquiries

Responding quickly and accurately to external open source compliance inquiries can greatly reduce the risk of escalation to litigation. To this end, the Company complies with the external inquiry response procedure defined in the Company’s open source compliance process to respond to external open source compliance inquiries._(3.2.1.2)

10. OpenChain

The Company supports the spirit of the Linux Foundation’s OpenChain project and actively participates in it to raise the level of open source compliance across the software supply chain.

• By applying this open source policy, the Company ensures compliance with ISO/IEC 5230:2020 as of October 1, 2021._(3.6.1.1)
• The Company ensures that, for at least 18 months after obtaining conformance certification, it satisfies all requirements of OpenChain Specification version 2.1 and ISO/IEC 5230:2020._(3.6.2.1)
• The Company reviews conformance at intervals of at least 18 months and revises and updates the policy as needed.

Appendix 1. Roster of Responsible Parties

9.2 - 2. Open Source Compliance Process (Sample)

OOO Corporation (hereinafter “the Company”) actively utilizes open source software (hereinafter “open source”) while developing products and services that include software. The Company must carry out activities to comply with the obligations imposed by open source licenses when distributing software, and this is called open source compliance.

1. Process for Software Product Development/Distribution

The open source compliance process defines the procedures that must be performed to comply with open source license obligations at each development stage as the Company develops and distributes software products and services. All members involved in software product development/distribution comply with the following 10 steps of the open source compliance process.

1. Identification of Open Source_{Identification of Open Source}

The development department complies with the following during the software design stage.

• While designing the software, identify the anticipated open source usage status and check the licenses.
• Check the obligations for each open source license. License-specific obligations can be found in the Company’s open source license guide.
• Design the software considering the source code disclosure scope of each open source license.

The Open Source Program Manager writes and publishes a guide on the obligations, restrictions, and rights of major open source licenses so that development departments across the company can reference it.

The development department marks copyright and license notices in the source code in accordance with company rules. The Company’s rules for copyright and license notation within source code can be found on the following page. : (insert_link)

When reviewing the adoption of new open source, the development department first identifies the license. It checks the license obligations, restrictions, and rights according to the Company’s open source license guide. If the license is not covered by the Company’s open source license guide, the department inquires with the Open Source Program Manager about whether adoption is possible and any precautions. The inquiry is made by creating a Jira Ticket.

The Open Source Program Manager analyzes the open source license obligations and guides the software development organization accordingly.

• If there are questions, advice is requested from the legal officer to provide clear guidance.
• Newly analyzed license information is reflected in the company-wide license guide.

2. Auditing Source Code_{Auditing Source Code}

The development department provides the source code according to the infrastructure officer’s guidance and requests an open source check.

The infrastructure officer performs the open source check using an open source analysis tool and generates the open source BOM.

The Open Source Program Manager reviews whether the open source license obligations can be met and whether there are open source license conflicts, and if there are issues, requests the development department to resolve them. Issues are created as Jira Tickets and assigned to the development department.

3. Resolving Issues_{Resolving Issues}

The development department resolves all issues found during the source code auditing stage. It takes actions such as removing the problematic open source or replacing it with open source under a different license.

Once the development department resolves all identified issues, it resolves the Jira Ticket issue and requests a re-review.

4. Reviews_Reviews

The Open Source Program Manager reviews whether all issues have been properly addressed. If necessary, the source code audit is performed again using the open source analysis tool.

5. Approval_Approval

The Open Source Program Manager gives final approval or rejection of whether the open source compliance procedure was properly performed. In case of rejection, an explanation of the reason and a suggested method of correction are proposed to the development department.

6. Registration_Registration

The Open Source Program Manager finalizes the BOM for tracking the list of open source used in each version of the software.

The infrastructure officer registers the finalized BOM in the system. The BOM includes the list of open source contained in the Supplied Software and the following information.

• The name and version of the product (or service) of the Supplied Software
• List of open source
  • Open source name / version
  • Open source license

7. Notices_Notices

The Open Source Program Manager generates an open source notice to comply with the notice obligation. The open source notice includes the following items.

• Open source contact for open source-related inquiries
• Notice content for each open source
  • Copyright
  • Open source license name
  • Copy of the open source license
  • (if applicable) a Written Offer to obtain a copy of the source code

The Open Source Program Manager generates the open source notice and delivers it to the development department. If source code disclosure is required at this time, the department guides the development department on how to collect the source code to be disclosed.

The development department encloses the open source notice when distributing the product. For products with a screen, measures are taken so users can check it through a menu. (e.g., App > Menu > Settings > Copyright Information > Open Source Licenses)

If the development department has used open source under a license that requires source code disclosure, such as GPL or LGPL, it checks the scope of source code disclosure and collects the source code to be disclosed.

• The source code collected to comply with license obligations such as GPL and LGPL must match the source code that composes the binary installed on the product. That is, building the collected source code must produce the same binary as the one installed on the product.

8. Pre-Distribution Verifications_{Pre-Distribution Verifications}

The development department submits the following artifacts to demonstrate that open source compliance activities were properly performed.

1. The final open source notice included in the product
2. Materials confirming that the open source notice is included in the product (e.g., a screen capture image showing the open source notice)
3. (if applicable) the source code to be disclosed (submitted compressed into a single file)

The Open Source Program Manager reviews the materials submitted by the development department to confirm there are no issues.

9. Distribution_Distribution

The Open Source Program Manager submits the compliance artifacts submitted by the development department to the infrastructure officer.

The infrastructure officer registers the compliance artifacts on the Company’s open source distribution site.

10. Final Verifications_{Final Verifications}

The Open Source Program Manager conducts a comprehensive check, including whether the compliance artifacts were properly registered on the Company’s open source portal without issues and whether they can be downloaded externally without problems.

2. External Inquiry Response Process

Responding quickly and accurately to external open source compliance inquiries can greatly reduce the risk of escalation to litigation. To this end, the Company complies with the following process to respond to external open source compliance inquiries.

1. Acknowledge_Acknowledge

Upon receiving an inquiry, 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 communicated. Since it is important to accurately understand the requester’s intent, additional clarification is requested if the inquiry is unclear.

The main types of inquiries and requests that require a response are as follows.

• Inquiries about whether open source is used in a specific product or service
• Requests for source code under a GPL or LGPL license mentioned in a Written Offer
• Requests for explanation and source code disclosure for open source found in a product but not specified in the open source notice
• Requests to provide files missing from source code disclosed under GPL, LGPL, and similar obligations, and how to build it
• Requests for copyright attribution

The Open Source Program Manager creates a Jira Issue for the received request and records all response activities in detail.

2. Inform_Inform

The Open Source Program Manager informs the requester that the Company is faithfully performing open source compliance and is investigating the requester’s inquiry. It is advisable to notify the requester whenever there is an update to the progress of the internal investigation.

3. Investigate_Investigate

The Open Source Program Manager conducts an internal investigation of the request. Whether the compliance process was properly performed for the version of the product in question is confirmed through the BOM and documented review history. Advice is requested from the legal officer if needed.

If confirmation is needed from a specific development department, the Open Source Program Manager requests the development department to investigate. The development department that receives the investigation request immediately checks whether there is a problem with the compliance artifacts and reports the results to the Open Source Program Manager.

4. Report_Report

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

• If the requester’s inquiry was a mistaken claim due to a misunderstanding, the requester is notified of this without further action, and the case is closed.
• If the issue is confirmed, the requester is informed of the exact method and timing for fulfilling the obligations of the relevant open source license.

5. Rectify_Rectify

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

6. Report_Report

After the problem is resolved, the requester is notified immediately, and the best available method to confirm the resolution is provided.

7. Improve_Improve

When a compliance problem occurred, the case is reviewed at an OSRB meeting, the circumstances leading to the problem are identified, and the process is improved to prevent recurrence.

9.3 - 3. Tools (FOSSology, SW360)

Open source compliance activities require not only policies, processes, and training materials, but also a variety of tools and systems for source code scanning, dependency analysis, and open source Bill of Materials management. As a result, many companies are investing significant resources in adopting and operating these tools and systems. Companies that are just starting open source compliance face difficulties not only with process but also with cost.

To address these difficulties, in June 2019, the OpenChain Tooling Work Group was launched, led by open source compliance tool experts from companies participating in the OpenChain project, including Siemens, Bosch, Toshiba, Fujitsu, and Hitachi.

The OpenChain Tooling Work Group was formed so that open source experts from various companies could work together to solve issues and share results, reducing open source compliance costs and producing high-quality compliance outcomes.

Specifically, it aims to build a turn-key open source tool chain by leveraging existing open source projects such as FOSSology, SW360, Software Heritage, ClearlyDefined, and SPDX, and to make this freely available to all companies. (https://groups.io/g/oss-based-compliance-tooling)

This section introduces FOSSology and SW360 and provides a brief guide on how to use them.

9.3.1 - FOSSology

For open source compliance, a source code scanning tool can be used to detect the open source and license information contained within software.

The Linux Foundation’s FOSSology project is a tool that develops this kind of scanning tool and has released it as open source so that anyone can use it freely.

Key Features

FOSSology is a web-based program that allows users to log in to the website and upload individual files or software packages. FOSSology detects license text and copyright information within the uploaded files. It is a good idea for developers to use FOSSology when they want to check the license and copyright information of the open source they intend to use. FOSSology scans all files within the open source package uploaded by the developer, automatically detects license-related text and copyright information in each file, and generates this as a report. For more details on FOSSology’s key features, refer to the following page: https://www.fossology.org/features/

Installation

To use FOSSology within a company, a FOSSology server must be built in-house. To do this, FOSSology must be installed on a Linux-based server system. FOSSology can be installed using the following three methods.

1. Using Docker
2. Using Vagrant and VirtualBox
3. Installing via a source build

Here, the simplest method, using Docker, is explained.

FOSSology publishes a containerized Docker image through Docker Hub (https://hub.docker.com/). : https://hub.docker.com/r/fossology/fossology

The pre-built Docker image can be run using the following command.

$ docker run -p 8081:80 fossology/fossology

The Docker image can be accessed using the following URL and account information. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

For more details on installation, refer to the following page. : https://github.com/fossology/fossology/blob/master/README.md

Test Server

If it is difficult to build a system to install FOSSology, the test server provided by the FOSSology Project can be used. The FOSSology project provides an environment for testing. (The test server may be discontinued without notice.)

Users can access the FOSSology test server with the following account to try out FOSSology’s features.

Basic Workflow

The basic usage procedure for FOSSology is as follows.

• To check the license and copyright information of the open source you want to use, compress the open source’s source code into a single file and upload it to FOSSology.
• To do this, select menu > Upload > From File.

• Select the file to upload and click the Upload button.
• Once the upload is complete, the analysis is automatically performed by the Job Agent.
• The status of the analysis in progress can be checked at menu > Jobs > My Recent Jobs.

• Once the analysis is complete, the results can be checked at menu > Browse.

• Selecting an individual file allows you to check the license-related text detected by FOSSology.

• menu > Browser > select a file or directory > Copyright/Email/Url/Author shows the Copyright/Email/Url/Author information detected by FOSSology.

After checking whether the results analyzed in this way by FOSSology are valid, users can exclude incorrectly detected items from the analysis results. FOSSology describes this as the Clearing process, and for more details, refer to the following page: https://www.fossology.org/get-started/basic-workflow/

In this way, you can easily check what the license of the open source you want to use is and what the copyright information looks like.

9.3.2 - SW360

A company that develops and distributes products containing open source must collect and track information such as the version and license of the open source used in each product and each release version. This allows the company to carry out proper open source compliance activities.

In particular, when a security vulnerability is reported in the NVD (https://nvd.nist.gov/vuln) for a specific open source version, if a company cannot trace which products use that version, it has no way of knowing which products need the security patch, leaving those products exposed to the security vulnerability.

For this reason, tracking open source information is essential. Companies build their own systems for this or purchase commercial services. SW360 is an open source project sponsored by the Eclipse Foundation that provides a web application and repository for collecting and tracking software BOM information.

Key Features

SW360 provides a web-based UI, and its key features are as follows.

• Tracking components used in a product
• Security vulnerability assessment
• License obligation management
• Generating legal documents such as notices

Installation

SW360 is composed of the following.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

For details on the project structure and the software required for installation, see the Required software section of the README: https://github.com/eclipse/sw360/blob/master/README.md

SW360 offers the following three installation methods. Users can choose whichever one suits them.

1. Vagrant (https://www.vagrantup.com/)-based installation: Vagrant is a tool for managing virtualized instances, and sw360vagrant provides an environment for deploying SW360 all at once. : https://github.com/sw360/sw360vagrant
2. The components of SW360 can be installed individually. : https://github.com/eclipse/sw360
3. It can be deployed via Docker. : https://github.com/sw360/sw360chores

Here, we introduce how to install and deploy SW360 on a CentOS 7.6 system using the Vagrant-based method. For more detail, refer to the README. : https://github.com/sw360/sw360vagrant/blob/master/README.md

1) Prerequisites

To install SW360 on a Vagrant box, you must first install openjdk, VirtualBox, and Vagrant. First, install openjdk 1.8.0.

$ yum install java-1.8.0-openjdk
$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)"
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Install VirtualBox.

$ sudo wget https://download.virtualbox.org/virtualbox/rpm/el/virtualbox.repo -P /etc/yum.repos.d
$ sudo yum install VirtualBox-5.2

If, when installing VirtualBox on CentOS 7, you get a “kernel module is not loaded” error, resolve it by installing kernel-devel and then reinstalling VirtualBox.

$ sudo yum install https://centos7.iuscommunity.org/ius-release.rpm
$ sudo yum install dkms
$ sudo yum install kernel-devel
# reboot
$ sudo /sbin/vboxconfig
$ systemctl status vboxdrv
● vboxdrv.service - VirtualBox Linux kernel module
   Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-02-19 09:06:02 KST; 20min ago

Install Vagrant and the vagrant-aws plugin.

$ sudo yum install https://releases.hashicorp.com/vagrant/2.2.6/vagrant_2.2.6_x86_64.rpm 
# install the vagrant-aws plugin
$ vagrant plugin install vagrant-aws

Then, clone the sw360vagrant code.

$ git clone https://github.com/sw360/sw360vagrant.git

2) Downloading Dependencies

To reduce the time it takes to build the Vagrant box, download the dependency packages in advance.

$ cd sw360vagrant
$ ./download-packages.sh

The following packages are then downloaded into the ./shared/package folder.

• Liferay 7.2.1 CE GA2 with Tomcat (9.0.17)
• Postgresql-42.2.9 ODBC client for Java as *.jar file
• 11 *.jar files required by SW360
• Thrift 0.11
• A box images from the Ubuntu 16.04 LTS (xenial-server-cloudimg-amd64-vagrant.box)

3) Creating the Base Box

Now, create the base box with the following commands.

$ cd generate-box
$ ./generate_box.sh

This step can take several tens of minutes.

4) Running the Box

Run the box with the following commands.

# If you have built a vagrant box from this directory earlier, you will have to destroy it first via
$ vagrant destroy
$ cd ../sw360-single
$ vagrant up

Running the box configures Liferay, PostgreSQL, and CouchDB. If it runs without issue, you can access the Liferay screen at https://localhost:8443/.

5) Deploying the SW360 Layout

The final step is deploying the SW360 layout on Liferay. This step is not yet automated, so an administrator must perform it manually. Access https://localhost:8443/ and log in with the following account.

• id : setup@sw360.org
• pw : sw360fossy

After that, follow the instructions on the following site to deploy the layout. https://github.com/eclipse/sw360/wiki/Deploy-Liferay7

Once the deployment is complete, you will see a screen like the following.

Basic Workflow

1) Registering Licenses

The first time you install SW360, you must register the open source licenses you commonly use. A license includes the following information.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (e.g. yes, no)
• License Text

Selecting Menu > Licenses > Add License takes you to the Create License screen, shown below.

Registering licenses one by one this way can be quite tedious, but fortunately SW360 provides a feature to import the entire SPDX License List at once. Click Menu > Admin < Import SPDX Information.

The SPDX License List is then registered automatically. You can confirm that 338 licenses have been registered under Menu > Licenses.

2) Registering Components and Releases

In SW360, a Component is a single unit of software. It can correspond to various kinds of software, including the following.

• Open source software
• Libraries
• Third-party software

A Component includes the following information.

• Component Name
• Main Licenses
• Categories (e.g. Library, Cloud, Mobile, …)
• Component Type (e.g. OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

A Release is a unit that points to a single version of a Component. A single Component can therefore have multiple Releases. A Release is created and managed under a Component.

A Release includes the following information.

• Component Name
• Version
• License
• Download URL
• CPE ID (e.g. cpe:2.3:a:apache:maven:3.0.4)

For example, to register zlib-1.2.8, you would first register zlib as a Component, and then register zlib 1.2.8 as a Release. Selecting Menu > Components > Add Component takes you to the Create Component screen, where you can register information about zlib.

Once you have created the Component, you can register information for the zlib-1.2.8 version at Components > Releases > Add Release.

After registering versions 1.2.8 and 1.2.11 as separate Releases under the single Component zlib, the Release Overview screen shows the following two Releases.

SW360 also provides a feature for importing information for multiple Components at once. You can enter the Component information you want to register into the CSV template under Menu > Admin > Import / Export and import it.

Note that, as of February 2020, this feature may not yet work reliably.

3) Creating a Project

A Project refers to a single product. Depending on the type of business, it could be a product, a service, or software. A Project registers and manages the Components/Releases used in the product.

When creating a Project, you register the following information.

• Project Name
• Version
• Project type (e.g. Product, Customer Project, Service, Internal Project, InnerSource)

You can create a Project via Menu > Projects > Add Project.

After creating a Project, register the Releases or sub-Projects it includes. Selecting the Project under Menu > Projects lets you register Linked Projects and Linked Releases under “Linked Releases and Projects.”

The following is the screen after registering OpenSSL 1.0.1 and zlib 1.2.8 as Linked Releases under a Project called SuperCalc.

4. Security Vulnerability Management

SW360 can automatically check whether a registered Release has a security vulnerability. To do this, SW360 provides a feature for scheduling periodic collection of CVE information. Under Menu > Admin > Schedule, you can set up a schedule to collect CVE SEARCH information every 24 hours.

With this schedule set, SW360 collects CVE information at the scheduled time from the CVE Search site (https://cve.circl.lu/). The collected CVE information can be viewed under Menu > Vulnerabilities.

Once Vulnerabilities information has been collected, you can check whether a created Project has any security vulnerabilities. In the SuperCalc Project created above, you can see that 85 security vulnerabilities have been reported.

By registering and managing the software a company develops and distributes in SW360 this way, it becomes possible to manage not only open source compliance but also security vulnerability risk in a way that minimizes it.

SW360 also exposes most of its features as a REST API in addition to the web interface above, making it possible to integrate with other tools such as FOSSology. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

In other words, by importing the analysis results of a source code scanning tool into SW360 and integrating it into DevOps to automate the registration of Projects and Releases, efficiency can be increased significantly.