Hello, we are the Open Source Program Office TF. The Linux Foundation operates the OpenChain project, which sets the standard specifications for open source management. For about two years, we have been running a large-scale project to apply the standards set by the OpenChain project to LINE. As a result, we have received certification for compliance with ISO/IEC 5230, the international standard for open source management.

In this post, we'll first introduce what the OpenChain project is, and then discuss the efforts we've made to apply the OpenChain standards to LINE. We'll also look at the significance of applying the OpenChain standards from both the company's and developer's perspectives. We hope that by sharing LINE's experience, this post will serve as a reminder of the importance of open source management for developers, and as a useful reference for those who are engaged in open source management tasks.

What is the OpenChain project?

When companies develop software, they rarely develop it entirely on their own. They utilize open source projects, outsource services, and even purchase commercial software. In each case, the process is often not independent, so any amount of code can be introduced through various routes when developing a product. The same applies when the development is complete and the product is deployed. More often than not, products are delivered through other places, often via very complex routes, rather than directly supplying software to customers. This entire process of developing and delivering software is referred to as the "software supply chain".

The OpenChain project aims to "define the standard for open source management and enable companies to effectively manage open source within the complex software supply chain".

Now, let's first introduce the standards of the OpenChain project, and examine what benefits companies and their members can gain from applying them.

The standard

The OpenChain project defines core requirements and provides guidelines for open source compliance. The OpenChain standard is designed to be applicable to all businesses, regardless of size or industry, and is currently deployed up to version 3.0. At LINE, we applied the standard based on version 2.1, which was the latest version at the time of the project.

The version 2.1 standard defines six core requirements that businesses must fulfill as follows:

1. Program foundation
   1. Clearly define the policy, its scope of application, and the responsibilities and roles of participants
   2. Publish the policy, its objectives, and the impact of non-compliance so that all participants are aware
   3. Establish a decision-making program to review and identify license obligations
2. Relevant tasks defined and supported
   1. Establish a process to effectively respond to inquiries related to open source from outside
   2. Provide sufficient resources for the open source program to operate smoothly
   3. Establish processes needed for issue response, such as legal consultation
3. Open source content review and approval
   1. Establish a process to create and manage a bill of material (BOM) that includes each open source component that makes up the provided software and the identified licenses
   2. The open source manager will manage general open source usage cases and summarize the requirements and precautions of major licenses to share within the company
4. Compliance artifact creation and delivery
   1. Comply with the obligations required by identified open source licenses to generate, store, and deliver compliance artifacts (open source notices, source code packages to be made public)
5. Understanding open source community engagements
   1. Document the policy and process for contributing to open source projects
6. Adherence to the specification requirements
   
   1. Meet all the requirements demanded by the OpenChain standard, and declare that the company has a program that complies with OpenChain

Even companies that are just starting open source governance can build a high-level management process by following each requirement of the OpenChain standard.

Areas where LINE paid special attention

When applying the above standards, there were areas where we paid special attention to suit the characteristics of the organization called LINE. Let's take a look at each one.

Comparing the OpenChain standard with the existing LINE policies

At the stage of starting the OpenChain program, LINE was already operating based on an open source policy established through past experiences and learning from external communities. Therefore, before starting the OpenChain program, LINE worked to understand what standards the project required and to organize milestones. While organizing these milestones, we considered and organized the following specific items:

• What were we already doing well when compared to the standard?
• What were the areas of deficiency when compared to the standard?
• What do we need to prepare anew?
• Are there any parts that need consultation with other departments?

Establishing a method of internal communication

The OpenChain standard not only emphasizes creating good policies but also placing these well-crafted policies and processes where employees can easily access them and ensuring they are thoroughly explained through training. This is because even the most sophisticated policy cannot be effective if the developers are not aware of it. This was an area we had always been considering and working on while managing open source tasks, and we thought about it again while contemplating how to effectively communicate the revised policy.

We added the existence of the open source policy to the common development governance regulations so that developers can be aware of it at any time. As a result, the open source policy, which was only checked during the deployment process, became a mandatory procedure to check during the development process. To ensure that this change does not significantly impact existing development work, we provide a document that classifies and explains typical open source licenses that frequently appear, so developers can easily and quickly make judgments themselves. Of course, we are also continuously informing about the revision of the open source policy through various internal channels and delivering the content of the revision.

Establishing an open source review board (OSRB)

One of the most challenging tasks while running the OpenChain program was establishing the OSRB. The basis of open source management tasks is the open source compliance of our internally developed programs. At LINE, the Open Source Program Office was also responsible for various tasks such as open source disclosure, contributions, and events to further activate open source activities, so collaboration with related departments was absolutely necessary. Therefore, we established the OSRB as follows, referring to each team's original tasks and past collaboration records.

• Open Source Program Office: Takes on all open source-related tasks and plays a central role when collaborating with other OSRBs
• Legal Team: Supports legal review of open source licenses or related contracts
• Patent Team: Supports review related to patent licenses
• Security Team: Collaborates on tasks for managing open source security vulnerabilities
• CTO Office: Collaborates on tasks to ensure that the entire development organization faithfully implements open source-related processes
• Developer Relations Team: Collaborates on tasks for creating open source-related technical content for internal and external audience

We were already collaborating with each department, but formalizing this in policy documents and designating practical managers was another burden. Fortunately, all teams understood the project's purpose and willingly designated managers and defined the necessary responsibilities and capabilities.

In the OpenChain standard example, the CTO Office and Developer Relations team are not included in the OSRB. However, at LINE, we included the CTO Office to quickly communicate with various development organizations and promptly understand and respond to situations when issues arise. We included the Developer Relations team to check open source license issues when planning various contents or events on the topic of open source, and to maximize the effect by adding our unique perspective that can highlight the appeal of open source.

Establishing a training policy

Conducting open source policy training and preserving the evaluation results are also part of OpenChain's standards. The training was divided into two parts: training for in-house developers and training for OSRB members.

The developer training was conducted for all developers in the LINE group. This was the first time that mandatory open source training was carried out for all developers. Given the number of people who made time to complete the training, we put a lot of thought into how to effectively deliver the content. We carefully selected the content for the training materials, focusing only on what developers absolutely needed to know. The main goal of this training wasn't to memorize all the content, but rather to know where to look and which process to follow when they have questions about open source, and who to contact. We focused on this when structuring the training.

We were also quite concerned about the evaluation. Nobody likes exams. We made quizzes out of frequently asked questions from developers to encourage them to read the content again. For policies that we particularly wanted to emphasize, we set the difficulty level of the quiz a bit higher for the evaluation.

The significance of applying the OpenChain standard

Let's examine the significance of applying the OpenChain standard from both the company's and the developer's perspectives.

The company's perspective

Displaying the excellence of our open source governance system at an international level

From a corporate perspective, the area of open source compliance can easily turn into a major issue if a gap arises, but it's not always easy to verify whether open source is being well managed or whether it's trustworthy in terms of compliance. By obtaining OpenChain certification, a company can prove both internally and externally that it is adhering well to open source licenses, making continuous efforts in legal, technical, and organizational aspects, and has built a flawless open source compliance system. This can help the company gain trust by emphasizing its open source management capabilities and compliance aspects when building cooperation and partnerships with third parties.

Maintaining consistency in internal processes

The OpenChain standard emphasizes that there must be consistent criteria not only for compliance results, but also for the process of creating those results. This means that there has to be a clear basis for judging certain items, and the judgment process should also be defined as a process. For example:

• Existing guide: Write the open source license notice and deliver it to the development team
• Improved guide with the application of the OpenChain standard: The open source license notice is written in a certain format, and the writing process follows the following process

The OpenChain standard defines each operational process in documents to prevent practitioners from making different choices in the same situation. This allows the company to consistently operate internal processes such as open source management, license tracking, documentation, and training, regardless of who is in charge. It also significantly reduces the chance of risk arising from human errors.

Quick and efficient issue response

By forming an issue response council called OSRB according to the OpenChain standard, and defining what responsibilities each member has and how they will cooperate according to which process, a system is established that allows for quick and efficient responses when risks occur.

The developer's perspective

Creating an environment where developers can focus more on development

Following the OpenChain standard, developers can complete open source training to learn the basics about open source. Developers who have received the training can guess what the company's judgment will be for basic cases, or they can find and verify documents themselves. If they can't do that, they know they can get help with open source compliance through the Open Source Program Office. Therefore, they can trust the company's policy that follows the OpenChain standard, put aside their worries about open source, and focus more on development.

Acquiring basic knowledge and skills about open source

While going through the OpenChain project certification process, we found that many developers were directly or indirectly involved, learning about the company's open source policies and processes. This led to a lot of cases where they became aware of open source licenses from the development process itself and engaged in development with this awareness. If an open source compliance violation case is found after development is completed, the cost of correcting it can be very high. However, if developers approach development with a basic knowledge of open source, they can avoid open source compliance risks in advance, leading to more efficient development.

Conclusion

In summary, LINE has strengthened its open source governance system through the OpenChain project, gaining trust both internally and externally. It has also significantly reduced the likelihood of open source issues arising and has become more capable of responding efficiently and thoroughly when issues do occur.

The Open Source Program Office wanted LINE to be recognized as a company that thoroughly implements open source compliance through this OpenChain project, and also blends well into the developer ecosystem. The OpenChain standard has served as a guideline for LINE's open source governance, which had been somewhat unstructured, and provided an opportunity to further strengthen our internal systems.

When we first reviewed the standards to obtain OpenChain certification, it felt daunting as there were more requirements than we had expected. It took nearly two years as a small number of people had to proceed while carrying out their existing tasks, but it's very rewarding and gratifying to see that our open source policies and processes have improved significantly during the certification process, to the point where we can be proud of them anywhere.