日本のオープンソースサミッドの オープンソースプログラムオフィスにお聞かせします 今日はオープンソースプログラムオフィスのエンジニアリングロールを紹介しますまずは私たちにご紹介します私の名前はかずみさと私はソニーグループコープレーションのディスティングシュエンジニア私はソニーウインクラスの オープンソフトペアを行います私はソニープログラムオフィスに 新しいプログラムオフィスを行います私はオープンソフトペアで ソニーでは大きなコンプライアンをしています2002年からソニーに使った オープンソフトペアのデ developmentalソフトペアを使った オープンソフトペアのディスティングをand introducing it to the products complying with the OSS licenses.I am a member of the software strategy committee at Sony.Hello, my name is Hirofukuchi.I'm a senior alliance manager in Sony.I'm a chair of open source board in Sonyand work on open source license compliancerelationship with open source community.I'm the leader of planning subgroup of OpenChain Japanwork group.I'm also a volunteer translatorfor community-related documents such as OpenChain and SBDX.This is today's agenda.This talk consists of three sections.Firstly, we will explain open source programming office.Secondly, we will explain our challenges of OSPO.Those are creating open source policy, bridging policy and development,and scaling OSPO initiative.Finally, we will conclude this talk with the things we learned from OSPO activity.Let's move on to open source program office, OSPO.From the perspective of corporate development,open source software has many aspects.Those are license, technology, community and culture.Regarding license, open source has an open source license.Using open source software requires license compliance.Regarding technology, in open source,technologies are implemented.We should keep watching that trend in technology.Open source is software so that the software should be managed regarding security.Regarding community, open source is developed by a community.We need to observe activity of a community from the viewpoint of sustainability.Regarding culture, open source culture and traditional development culture are far different.The feature of open source development is collaboration with others.We need to know open source way and grow open source culture inside a company.Open source software has many aspects so that we need a frameworkfor comprehensively managing the use and creation of open source in a company.One of the framework is open source program.The framework should be created considering the various aspects of open sourceso that open source program consists of policy, process, training and human resources.Open source program office, OSPO,can take the initiative to create and promote the open source program.OSPO is the center of open source program in a company.Here is an example of open source program.There could be policy, OSPO, training, internal community, external community relationships.Among those, policy and OSPO's initiatives are the most important.Policy governs all open source activity.OSPO takes the initiative of open source program.In this talk, we will focus on policy and OSPO.OSPO's another role is to align internally and externally.There are several alignments.Firstly, open source development is far different from traditional development.OSPO aligns between open source and traditional development in a company.Open source is developed by a community.A company needs to know the community way of development.Secondly,OSPO aligns between a company and a community.Thirdly,OSPO aligns between a company and the industry.A company needs the alignment with the software supply chain regarding open source use.In this talk, we will talk about the alignment betweenopen source and traditional development in a company.Let's move on our challenges we faced.This is the big picture of the cycle of open source policy.Around open source policy, there is the cycle of creation, promotion and scaling.In the next cycle, we update the policy again.The first challenges we faced while creating the open source policy.The open source policy has engineering aspects.OSPO requires engineering laws.The first challenge is to create an open source policy.OSPO should consider strategy, business objectives and technology objectives in creating the open source policy.OSPO needs for knowledge of business situations and technology trend.The second challenge is to disseminate the open source policy.The second challenge is divided into two parts.The first one is to bring between policy and product development in business unit.The second one is to scale the open source initiative over the company.Let's move on, creating open source policy.This page shows embedded Linux products history of Sony.At first, we developed TV and video product with embedded Linux.This is the starting point of OSS activity.After that, we expanded the embedded Linux into other consumer embedded categories such as video cameras and digital cameras.Then, we expanded embedded Linux into professional equipment such as broadcasting equipment and medical equipment.Finally, we expanded embedded Linux into new categories such as robots and others.And OSS activities have expanded into other business categories.Fencever, we expanded into other categories we needed to improve the open source program.This figure shows the brief history of Sony's open source program.In this presentation, we divided the period into three phases.Introduction phase, early growth phase, growth phase.These phases were strongly related to the changes in the business environment.In the introduction phase, only several mass production categories use Linux and OSS.In the early growth phase, a lot of embedded products use Linux and OSS.In the growth phase, not only embedded products but also many business categories use OSS.In the introduction phase, Linux development team had OSPO role.OSPO created a technical guideline to collect the best practice in using Linux kernel in product development.This guideline plays the role of open source policy in the first phase.The guideline was only shared among internal engineers of business unit.In the early growth phase, to strengthen OSPO, OSPO's role was allocated in the open source license committee.The committee consists of legal staff, intellectual property staff, R&D staff, and representative of business units.The committee has the responsibility to create and maintain the open source policy.Under the committee, OSPO publish the official open source policy.In the growth phase, OSPO has become a dedicated team while open source is still the center of the open source license committee.To expand activity for contribution and publishing as open source.OSPO has updated the open source policy.This is our open source policy.Our basic policy is to promote open source usage and contribution.In this document, the process of usage and contribution are described.For contribution, we defined processes for contribution to communities, publishing software as open source, and presentation at open source events.Let's move on, breaching policy and development.The next challenge is to breach between policy and development.Open source policy is simple, general, and static.On the other hand, product development is complex, specific, and dynamic.Open source is also complex and dynamic.Sometimes, engineers require OSPO support to perform the license compliance.OSPO supports engineers for software development regarding technology selection, license compliance, security, and contribution.In these activities, license compliance is the most typical activity.To show OSPO's engineering role, we will focus on the activity of license compliance.License compliance is divided into these processes, creating SBOM, reviewing SBOM, and preparing compliance artifacts.Creating SBOM is the foundation of license compliance, but creating SBOM is very hard, so OSPO's engineering support is needed.We will explain the reason why is creating SBOM so hard.There are the reasons.Taking open source has various ways.Open source is downloaded from internet.Open source is received from supplier, but staff may not be an engineer and they do not know to create SBOM.Open source is reused from another project, but the origin may occasionally be lost.Open source is located in various repositories and comes from various sources.There are external repositories, internal repositories, and media from suppliers.Open source is often reused from previous products so that the repository is sometimes internal.Open source has many dependencies and that makes SBOM create more difficult.We will show the process of SBOM creation.Listing open source software requires identifying repository and checking dependencies.OSS is located in external repositories such as GitHub, GitLab.We should find out the location.Checking dependency is hard.Open source software uses a lot of other open source software.Development tool adds other OSS.Compilers add libraries such as GCC runtime.OSS depends on distribution and container such as Debian Docker container.We need to find out these dependencies.After that, we should identify name and version, origin, download URL, license, modification.This is an example of a simple SBOM.Let's move on reviewing SBOM.We need to review SBOM from several points.At first, base points are here.Those points are deliverables, licenses, obligations, patents, and open source policy.And we need to review SBOM from business point.To review SBOM, we need to grasp the full picture of open source distribution by the company.To know the whole picture, we need to know several factors.Fan is a release schedule for the deliverables.Who are the direct recipients from us?Who are the final recipients?The recipients are internal user and user enterprise.These factors affect obligation to comply with licenses.Then we need to review SBOM from engineering point.Implementation style is essential.There are embedded products, long on semiconductors, server application, PC application, mobile application, and SDK.These factors affect obligations to comply with licenses.Deliverables are next point.First is the scope of the deliverables.The scope should include developed software, dependent software, software out by SDK, compiler runtime library,software in Linux distribution, software stack in container environment.SBOM OSS license may require patent grant.We should review the scope of OSS function.Software licensed under the copy left license affects other software.So that we should review relationship between software components.We should care about relationship such as linkage, API, and communication.Then conflict between policy and license occurs.OSPO try to propose alternative to resolve the conflict.OSPO propose the possibility to use a different open source software or commercial license for the software.At last to prepare compliance artifacts, we need to do the following.Creating a list, collecting license notice, collecting copyright notice.Preparing the source code.This includes the build script and verification of building between offer.OSPO advices delivery method such as a website disclosure media delivery.Finally, compliance artifacts are archived.Let's move on scaring of OSPO initiative.The last challenge in this talk is to scare the OSPO initiative.Sony has many business categories.There are various projects and services such as electronics, semiconductor, game, picture, and financial services.While OSPO is the center of the activity, our global OSPO has only 10 members.OSPO cannot give consultation to every internal development.To scare the OSPO initiative, we prepared training and best practices and grow internal communities.Training and best practice have engineers to get basic knowledge about open source.They can resolve issues by themselves.Their internal communities, we could grow open source culture inside the company.We have several training courses on open source.The training courses are designed to give engineers basic knowledge on usage and the contribution of open source as well as open source communities.One of the training is key technology training course.Once the open source software course was one-day-round training, but to adapt to a remote work style, we remade the course and now the training is the correction of 200 video clips.Engineers can take training when they need their knowledge.This course is full of learnings from open source community to open source license to strategy basics.The text book has been prepared both in Japanese and in English language.Other two key technology courses are taught in English language by community experts.These courses focus on open source community and get tools because these are designed for open source contribution.We have re-learning which teach basics of open source license compliance.We have also training course for new employees.This course teaches basics of open source and introduces the overview of Sony's open source program.The course also covers community basics.Best practices have been collected as technical guideline and OSPR website.The technical guideline is called GPR guideline.The GPR guideline is the correction of best practices from experience of Linux kernel development.The knowledge covers linking of software libraries, license tickets, disclosure of the source code, and contribution to OS open source communities.The GPR guideline is technology guideline that tells us the spirit of open source communities.We should respect for open source communities.Other best practices is OSPR website.OSPEO collects basic license information and important points of each license.And also show the software showcase.The best practices give engineers basic knowledge and help them to resolve issues by themselves.We have various types of internal communities.First one is OSPO Global Network.OSPO Global Network is the center of open source initiative in Sony.The second one is study group.We have a study group for the next generation of OSPO.The third one is the open source license committee.Regarding internal community of open source license compliance, we have open source license committee.The committee is an internal committee to promote license compliance and share best practices.The committee is officially recognized by the company.The center of the committee is OSPO.And OSPO, the committee consists of legal and intellectual property staff, R&D staff, representative of business units.The number of the committee is over 100.The committee has the responsibility to maintain the open source policy.We have open source events for global engineers.We prepared internal SNS and website to share knowledge among engineers.This figure shows OSPO Global Network.We have three OSPO teams in Japan, US, and EU.The numbers of staff in each region are 6, 2, and 2 respectively.Global OSPO are collaborating each other.Sony has many technology development sites in Asia, US, and EU.Each OSPO covers their respective area.OSPO collaborates internal Linux development team in terms of engineering, such as analyzing software architecture.We have internal open source events to grow open source culture inside Sony.These pictures are from events of Open Source Day and Sony Technology Exchange Fair.Many engineers from around the world joined and shared their experience about the open source.We are connecting internal communities and building an internal network through OSPO Global Network.Now the conclusion.We would like to conclude our session with the things we learned from our experience.Firstly, OSPO is essential for establishment intended, promoting open source program in a company.Open source has many aspects.OSPO is required to promote open source especially for a large company.Secondly,OSPO's engineering role is critical in creating a policy, bridging policy and development, and scaling OSPO initiative.Thank you for your listening and attention.Thank you for listening.