 Hello, everyone. Thank you for your interest. This session is from Compliance for Creation, open source program as an engine for creation. As you may know, this presentation is pretty recorded, and so I'm looking forward to talking with you in the Q&A session that we'll follow this. Toshiba had a research and department on Linux in the late 1990s and has been an active member of the open source community since 2000, and now is a member of the Linux Foundation. Of course, there is also the accumulated initiatives relating to open source programs internally. However, the situation is moving. Like open source licenses, the concepts of the community, and the software technologies subject to open source compliance is constantly changing. Also, the circumstances of a company organization or group companies are changing. The kind of change can affect how an open source program is implemented in an organization. So, even though the situation is still moving, we'd like to share our efforts and lessons in our journey. We are two speakers. Both of us are involved in managing open source programs, but we have different backgrounds. Hello again. I am Takashi Ninjouji, chief specialist and a member of the Web Office R&D team. One of my mission is to support open source compliance activities in product and service development. Open source compliance is not a close initiative within a company, but it is also important to collaborate with the open source community and the community of companies working on open source properties. I may participate in open source complex communities such as Open Chain and SPDX. However, I cannot always join in real time due to the time differences, so I'm very happy to have this opportunity. Also, I'm working on relating with the Open Invention Network. Hi, everyone. This is Yasaka Shirai. I'm also a chief specialist and the team leader for software development process management and promotion. Software systems are used in various infrastructure and consumer devices, and stakeholders are very different. I am engaged in making process standards for software development and also in education and consulting for the entire group. As an expert in development processes such as CMMI and SCLAM, I assist in the implementations. In that context, I am involved in the construction and operation of the open source program and working to promote inner source to apply such a program to create a body. Here is the agenda of this session. First, we will briefly review our approach to open source programs. Next, is what we have done to utilize open source programs for inner source. Then, we will talk about the progress of the open source program and inner source and the lessons learned from it. Again, this is the quality contents, it will be very happy to discuss with you in the Q&A session after this presentation. Okay. First, the open source program. In the beginning, let me give you some background. Toshiba is composed of corporate entity and group companies that conduct businesses. At this time, each group company is legally independent, so governance is basically done individually and independently. It can be that open source license compliance is part of the software development process. In terms of software development process, corporate development process standards, published policies and guidelines for them, and support implementation in each company. Each group company must define and implement its own process standards. This should be referring to those standards of the corporate and customizing them to fit its own circumstances as necessary. If there is no particular need for change, the same standards and guidelines will be used. One of the very important related initiatives is software process improvement called SPI. SPI is a group-wide effort to establish process standards by referring to external standard processes and educating and disseminating. Some of the processes we refer to are CMMI, ITUFO, and ISO-IC standards. The open chain specification has become ISO-IC 5230 2020. We are looking into this as well. The development methodology itself is a target to this activity as well. For example, we promote agile, devos, and Microsoft architecture. In order to formulate and disseminate such corporate standards, we have established subcommittee in which group companies participate. For example, there is a high-level subcommittee that discusses software in general, and we have specific subcommittees for particular case, for example, open-source software utilization. Toshiba is an active user of Linux and other open-source software and participates in their communities. These tools are related to the Linux Foundation. The first one is the Civil Infrastructure Platform, CIP. The CIP develops civil infrastructure systems that require long-term reliability. We participate in it at the member of the Technical Stealing Committee. As a relevant effort, we are also participating in Debian LTS. And next, the Open Chain. Open Chain project is also important for open-source companies in the software-separate chain. We participate in it as a pressure member. Currently, we are introducing and operating open-source programs from the perspective of how we can utilize the existing framework. To be honest, we'd like to make the best use of the software-different processes and technologies known to the world today. We consider the impact of changes on the part without any problems so far, so following the existing framework is one of the possible approaches. We haven't made any particular changes to the existing rules and guidelines, however, along with the clarification of the processes, we examine them, there are some points still under discussion. For usage, we already have one on open-source properties. As for contribution, it will be treated as one of the types of external disclosure and we will follow the provisions on information management and export control. These routes have been formulated since the early 2000s and although they have been revised and updated to after now, and their perspective is somewhat defensive from the view of the interpretation property. So therefore, a document to motivate co-creation and contribution is needed. That is manifesto. This is an attempt to clarify the open-source policy while basing it on the corporate philosophy. The original is in Japanese. I've translated in the English for your preference. I'm sure that the English version will be more refined in the future, but I'm happy to share our thoughts with you. These are three periods. Make what doesn't exist and respect community and collaborate and co-create together. First one means if you have it, use it. If you don't have it, make it. Sure, you know how it's highly encouraged and this also means following the rules when you use it. The second intends to grow together in the spirit of get and given. Feel free to exchange your ideas and the suggesting rather than criticizing is a way to should be. The third one me intends, publish your ideas and nurture them in the community. Accelerate quality improvement by collaborating with many people, believe the power of the community and communicate yourself openly. Here community doesn't only mean the open source community but also the group companies as well. We had expected this form from the beginning. This manifest is designed to work for both inner source and open source. Well, the next topic is inner source. Introducing inner source aims to introduce the open source development style and to improve propriety code development in both its style and quality and also aim to promote both usable component design and DevOps as well. As we saw earlier, the manifest is applicable for both open source and inner source. To be honest, now we are discussing rules and guidelines for inner source. It should be noted that inner source is an exchange between specific independent companies. The open source is free to the public for an indefinite number of people but this is not the case with inner source. Therefore, to share inner source, it is necessary to clarify its license conditions. We needed to examine what kind of conditions would be required for collaboration and co-creation with the group companies. It was clear, it was important to share information about the software and the other hand, from a corporate complex perspective, it is necessary to take care in handling intangible assets. So the inner source should be confidential within the group. Furthermore, the software was defined as source form or non-source form and the distribution in source form only is allowed but the non-source form has to be discredited with source form. What was interesting in the discussion of this document was the companies participating in the subcommittee showed interest. Although the full scale deployment of inner source scheme is yet to come, I believe that we can work together to solve problems and create value. Well, let us talk about our progress. We are in the process of creating a template that can be customized for compliance with ISO, IC, 5.2, 3.0, including policies, processes, and competencies. As for training materials, we are preparing e-learning materials for elementary, basic, and advanced-award open source. We have also conducted an inner source training program. Indeed, we will briefly introduce later. Deforming on governance is still in discussion. I hope I can talk to you soon. Automated compliance workflow. Working with CI, compliance workflow is still under discussion. There are two approaches such as method one, fit to existing workflows. Method two, fit to the development environment. I'd like to briefly introduce the second one later. Well, let me talk about the e-learning on open source for beginners. The content covers licenses, proper usages, litigation cases, and others even at the elementary level. Although some of the group companies provide training on intellectual property rights related to software, the content on open source varies. It was created to align elementary contents. So far, the course participants have a variety of patients, not limited to engineering. The following are some findings. It seems awareness of open source software in work and daily life affect the level of interest and satisfaction. We ask a wide range of engineers to take the course. The questionnaires seem to be at the point whether they were engaged in software development work and whether they used open source software. And also there were people who tried to search information on the internet by themselves. The reasons for doing so varied, but for example, they couldn't understand the contents or wanted to know more deeply. Therefore, it became clear to us again that we should use the terms and expression used in the domain and avoid using our own expressions. It can be said that particular care should be taken when translating English-driven wording, English-drived wording into another language such as Japanese. We also developed the in-house training program to experience collaboration and co-creation. This five days training program includes the hands-on, ideas-on, hack-a-son, and product presentation. More than 50 employees will participate in this training program by December 2022. We introduced some of the findings through this training program. One of the findings is that participants enjoyed new connections, especially between engineers and non-engineers. Toshiba had a little connection between engineers and non-engineers, and it seemed to have stimulated the participants. We also find future challenges, for example, need for the department of results in the need for participation. We would like to continue to support the result of this training program to be in the source. Okay, the last slide is just an idea. In terms of comprehensive workflows, I think one way to do this is work with the IP and the legal department and try to be as close as possible to their workflows. The approach we are taking. Country, we use the combination of tools in existing workflows. The other is open source compasses, such as SW 360, pathology, scan code, block deck, and so on. We also use the SharePoint to manage the reviews and the approvals. However, I'm just wondering how the front end could be simpler to implement, and what is a more engineer-friendly approach? When I think about automation, sometimes I think that Git and CI could be integrated from creating complex artifacts to their management. Roughly speaking, the idea is to use Git to manage the source code repository, the complex artifacts generated from the repository, and the review and the approval of those artifacts in Git process. If the developers at the organization's core want to be easier to execute complex workflows this way, I'd like to discuss this with you at another time. Now finally, I'd like to end with the lessons we have learned. The importance of documentation and endorsement has been reaffirmed. In other words, people from diverse backgrounds were encouraged to actively participate in discussion, which led to new opportunity for mutual understanding beyond boundaries. This discussion also seemed to have influenced the way we think about behaving with an explicit state or documentation. But I dare say that we should be careful not to leave such toxic knowledge untouched. The next one is modularities. Many of you might know that less is more is one of the making policies of the open chain specification. This is a very important view even from the prospect of an organization within the company. This is because just every company is different, and organization within the company and not always organized under the homogeneous conditions. So we found it important to set up templates to show the basics and provide the insights shows and how tos to customize it. And well, let me emphasize the following words, and with together. Rather than staying with the minimalities of less is more, we need to look at the diversity of the extents from there. But to create a new value, I think we need to look at these three words. And it's important to expand to more, next, and so on. And with, in other words, there are many codes beyond the boundaries of single person or a homogeneous range. And together, let's to be together and find something common in oil inclusion. We realize once again, that this process is collaboration and co-creation. Okay, thank you for joining our session. We are looking forward to your comments and comments are really welcome and feel free to contact us. Thank you.