 So today, we are going to talk about the open source compliance challenges in our semiconductor company and how we overcome those difficulties. So we hope you will gain some ideas for complying with the open source license of your products. So let's get started. So here is the rundown for today's discussion. So we have mainly four parts. First, we will discuss common issues in the license clearance workflow. And in the next two parts, we will explore the challenges and implemented solutions in our semiconductor company. So lastly, we will showcase our contribution activities. So before moving further, let me introduce ourselves quickly. So I'm Shimomura. So I've been an embedded engineer for extensive periods contributing to the development of various products such as camera, TVs, and video devices. So over the years, I have also been actively involved in development using open source. And now I have initiated and managed the companies of Ospo. So OK, hello. My name is Yuji Honda. I work for Sony semiconductor solutions. And I have a various software engineering experience like software embedded into TV or camera or some kind of farmwares or SDK, your UX, machine learning, and so on. And last year, I created an Ospo in SSS. So today, I will talk about the experience. Thank you. So next, let me talk to you about our company. The Sony Group consists of several segments, including game, music, picture, and entertainment technology, and services, and imaging and solutions, and financial services. So we are Sony Semiconductor Solutions Corporation. So it's wholly owned subsidiary of Sony Group Corporation. And that's where we come in. And Sony Semiconductor Solutions has many subsidiaries as shown in this slide. Our primary focus is on image sensor development. But we also have a lot of software development. Naturally, we frequently utilize and control it to a diverse range of open source software. Sometime managing and figure out all OSS activities in our company can be challenging. So now we move on to the license clearance issue. As you are aware, achieving open source license compliance can be challenging. In addressing those challenges, we have established an internal open source compliance management process. And we are proud to be open change certified. So, oh, sorry, I'm essentially grateful to the open source change community for guiding us in improving our processes. So, however, it's important to note that our compliance process is stringent, detailed, time consuming, and not always easy to grasp. And also, it's difficult to execute because it requires software engineering expertise. So this slide shows that dependency analysis is difficult. We need to know all dependencies, not only direct dependencies, but also indirect dependencies. And to investigate all dependencies, we should check like package metadata. But metadata may, sometimes may be wrong. To solve this issue, we need detailed knowledge of building system, building system, and build configuration for each product. Sorry. So we have also another difficulty. So another difficulty is license investigation. After we identify software components, we investigate license of each component. There are great scanning tools like Phosology, and so on. In fact, we use both of them. But to identify appropriate licenses, we need to be familiar with those tools. Scan result containing may false detections. We need some know-how to deal with them effectively. And of course, open source license knowledge is needed. So, okay, so I pass to you. Okay. And previous slides show that common issues in open source license compliance. And next, I'll show you unique challenges for us. Okay, this slide roughly describes product domain of our business in SSS. And as you can see, it's very wide. And we have great sensor devices, of course. And we want to make the world better by great solutions utilizing our sensor devices. But it is not easy to bring out the potential of sensor devices. It requires expertise of sensor devices. So there's a big gap between sensor devices and solutions. To provide great solutions by leveraging our sensor expertise, we do all, from edge to cloud, to fill the gap. And we consume a lot of open source software to make our products. Open source software constitutes more than 90% of our product. This makes our open source compliance very difficult. Here's some example of our software product. The left one, one of our main products, image sensors. And firmware built into them. And we distribute device drivers to control the sensors. And we also have development board. And it's a kind of small computer. And it works with firmware, device drivers, and OS, middleware, SDKs, package managers, apps, and so on. And of course, we make camera devices. And as described in the previous slide, we have platform as a service business. And it involves server software, managed services, and so on. So our various software products make our open source compliance very complicated. For example, dependency analysis. How to identify open source components. When we make camera devices, we define build dependencies and customize build options. And compile source code to generate binaries. We need to read source code and build logs, like configure script or make file, see make list, dot text, or running LED commands, and so on to analyze dependencies. And on the other hand, when we make web service, we use package managers. And refer to package metadata. And use pre-built binaries. We should use dependency analysis tools, like app cache depends, or pip depth tree, or npm list, or sift, or something like that. So different product needs different techniques. Another example, open source license policies. It depends on how open source components will be used. When we make camera device, open source software will be embedded into product. It's distributed in the market, and software update will be done sometimes. But when we make web service, open source software will be run on server, accessed through web browsers, and software will be updated frequently. So when we define policies, we need to define different policies for the same open source license, considering how we use components. Some license cannot be used in camera devices, but it's OK to use in web services. So different products needs different policies. Here come some problems. When building software, build options are defined. Build options differ depending on products. Changing the build options may change licenses. What should we do? Then many binaries are generated from one repository. Each binary may have different licenses. Which license should we comply with? Or container image consists of a lot of many, many, many open source components. And sometimes, some products use container as built environment internally. And some web services use container on server to run programs. Should we do the same for both cases? Maybe some of you don't know how should we do, but some developers doesn't know. So as I explained, we deal with various software products. To comply with the open source license, both product-specific knowledge and open source expertise are needed. This was a big challenge. So how we navigated on open source compliance. This is our solution. We assign dedicated developers in charge of open source compliance for their products. Only product developers know the detail of their product. And we created Ospo consists of open source experts to support developers. There were few experts in our division. We need to train our Ospo members. But fortunately, there are some open source experts in Sony Group, so we learn a lot from them. This is our Ospo created last year. Ospo and product developers work together to comply with open source license. Our Ospo consists of various experts. One manager is him, and one leader is me, and eight collaborators, including legal members or IP members, and seven dedicated support members in India. We engage with about 30 projects. And we have some types of activities. We define internal rules. We provide engineering support and strategy planning. And license clearance support team have very important role in our Ospo. Our license clearance support team are in India. They are open source experts. Last year, they built an environment to proceed license clearance. And in every process, they work together with product developers. Today, some members here in this session from here in India. So please talk to them after this session. And here is a real example of license clearance. Sorry, it's very complicated. But this was the real log of our process. And this was for open CV 4.5. And in this case, 57 binaries are generated from one source package. And product developers and Ospo communicates on GitHub issues. First, product developer create a request and share some detailed information for building binaries. And then Ospo member confirm the inputs, then give some advice about patents. This one is not the license issues, but we advise them about the patents. Then, run some tools for scanning source file like Phosology. After checking scanned results, use shared information from developers to investigate the result in detail. In this case, very long log is here. And then identify license for each binary. In this example, it takes a long time to identify because there were 57 binaries. So it takes a lot of time. Then Ospo review the results. And after some modification, we prepare complex artifacts like S-forms, or license text, or copyrights, source files. Then we release them to product developers finally. And it takes about one to two weeks per package. The point is Ospo experts ask product developers for hints to identify license for each binaries. This approach is good for both Ospo and product developers. Ospo experts can acquire wide and practical knowledge of open source. Ospo can also optimize support workflow for products in this feedback. And product developer can concentrate on their development to make their product better. And they also can learn what they need to do for license compliance. So this could be another feedback. And finally, I'll show you some of our contribution activities. Partnership with open community is very important for us. This picture is very famous for Ospo members, I think. And thank you so much to use this in this slide. And for the first step, we strictly comply with open source license because we have respect for all developers in open community. So we do all for open source compliance in Ospo members and developers. And the second step, our SDKs are released as an open source project. And we want to improve them with open community. And finally, to support open community, aligning with our business strategy is also important. But we sponsor community events, like such as this year's Open Source Summit Japan. We sponsor this event. And Ospo encourages developers and business division for contribution in many ways. So these are today's key takeaways. First one, to comply with open source license for barrier software, dividing the work between Ospo experts and product developers is realistic way for us. Through this activity, Ospo experts can acquire wide and practical knowledge of open source and product developers can make their product better. And finally, Ospo experts also discuss open source strategies and encourage product developers for contribution. So that's all for today's session. Thank you very much. Okay, any questions, comments? Thank you very much for the great talk. And I think that the activity is very nice. So my question is that your Ospo structure is very good, I think. So how did you find out such a structure or such a way? Did you have some experience or some know-hows before start up the Ospo? Or did you refer to some reference? Or did you think by yourself? How did you find out the structure? Okay, thank you for the question. What we done first was to investigate what is the issue for us because we have many project involved and they have unique issues each other. So we gather all of the issues and analyze them and we define some requirements for Ospo for us. And then we, of course, we refer to some existing example like to the group provided and we decided which one is best for us. And the conclusion was this structure for us. So not only internal discussion, but also we refer to open discussions. Is that, that was the way we did. Thank you very much, I understand. Thank you. Thank you very much for your very, very impressive talk. May I see some slides after, again, yes, sorry, more, no, more, yes, yes, yes, yes. In this case, so one thing I'd like to ask you is the, how to say the right side and the down side, the prepare compliance artifact. That means the license clear supporting and the tooling teams will make the, how to say, the license notices for the product or services and just give the product team. So it means the development team doesn't need to make any kind of notices by their selves. Mike, understand it's correct? Yes, because we Ospo and product developers works together. So we communicate very deep in detail. So Ospo member prepare compliance artifacts for release products and they just receive the result from Ospo and they release to their customer. So in this case, may I ask this, but if I can, I'm very happy to ask you. So in this case, in your company, the whole kind of nice artifact, sorry, kind of the document of the notices is managed by Ospo. I mean, whole kind of product, sorry, the notice of all kind of product and the services will be managed in Ospo. Responsibility to release the artifact is belong to development team. So finally we give them to manage the compliance artifacts. But the Ospo member have the responsibility to prepare the compliance artifacts. Thank you so much. And this is my last question. May I? Would you please show me again your structure of the Ospo? I guess it's in this illustration. So I couldn't find the security teams. So do you have any collaboration with the security or security assurance team? Yes, of course. We have another security team out of this figure, but we communicate very much every day. And how should we handle with the vulnerability of OSS components? So I think we should add another box here. Thank you very much. But the security guys doesn't include the Ospo. Just the security as it is? Both. Because we are in the same section, security team and Ospo team are in the same section. So we do the same for open source security. Again, thank you very much. Hello, thanks for your sharing. I come from Taiwan and I come from the organization, OCF, that really wants to establish open-chain culture in Taiwan, but now we've tried to let company know how important the open-chain is and help them to build the Ospo. But we really don't know how to make them understand the importance. Usually they will ask us about we might have some risk of the litigation, the suit of the open source license. But if you want to provide them some assistance, they will just ask the license mentor, consultants. But they don't really want to establish the ISO 5230 and build the Ospo. So I want to ask, how did you build the Ospo from the beginning and what were the challenges you face inside your company? Thank you. Okay, thank you very much. Fortunately, Sony has a long history about open source relationship, like CELinux contribution or something like that. And we have both idea about the good side of the open source contribution and risk of open source consuming. And what was good for us was that most of the managers know about the risks of open source consuming. So we started with open source compliance first. So that was the first step for our Ospo. And then we talked with managers about the open source activities for the next step and not only for risk reducing activities, but also how can we utilize open source as a strategy, strategically. And they agree with us so we could build this kind of full functional Ospo. So, yes, I think this was very specific for Sony's case, but you can refer to our example. Thank you. So in terms of like, well, there's open source compliance, but in terms of the supply chain, did you receive any pressure or influence from like your customers to provide them with compliance artifacts? Yes, it begins to feel like that. And our another team started discussion for how should we comply with the laws about this one more supply chain solution. So we also work with another team about thinking those kind of things. So the answer should be yes. So I'd like to ask again, that's a very trivial sense, but in my experience for almost all of Japanese company mainly they are using Japanese language for the documentation and some kind of trading materials or so, and so on. So, but in this case, in your case, so you're working with a team in India. So I assume the English is the main language for your operation, why not? Yes, you're left side persons. Yes, the developers and support team communicate in English, that's right. But how about the Japanese developers in your Japan country side? They try to speak English. Really? Of course, and of course I support them in English and Japanese to communicate fluently with India team. So it works for us. Thank you so much, thank you. Thank you for your presentation. And my question is similar to him. So I'd like to know the background behind the improvement of the members or branches. Because I imagine at first, if I start to make an Ospo, maybe initially to gather members, just Japanese. So my question is, what's the background to gathering the overseas members? It's difficult to answer, but I think it was another lucky things for us that we have a big group company. So we have a lot of subsidiaries in the world. And we already worked together in another projects like product development with the India team. So we could easily to start communication about building Ospo for us in India. So I think this one is also specific for Sony, but. Yeah, I think it's generally speaking, I think it's very difficult to delegate functionalities to other countries. Yes, I think so. Thank you for the presentation. Can you go back to the slide with the Ospo maturity level? I see that on stage four, you have the open source summit sponsorship. Do you also encourage internal developers to contribute back to community or you just give money to the different events? Yes, we really encourage developers to contribute back to each OSS community. And we are thinking about some kind of contribution back to OSS community. And we especially have interests in AI domain. So internally we have some kind of discussion about contribution for the OSS community with developers. Thank you. Excellent, five minutes we have. Five minutes we have. I also have a question about the contribution. How do you decide which project to contribute? Is it bottom up or top down? That's really difficult question, but currently we mainly bottom up approach because the open source technologies are very immersive and the top manager doesn't know that those kind of new technologies generally. So we bring up some kind of new news of the open source activities and they are doing this kind of things and we should do this also. We bottom up the proposal to managers and they also have the idea that open source contribution is very important for business strategy. So we can talk for both kind of view business and open source development. So in some project we are starting the discussion for contribution regarding the business strategies. Thank you. Thank you for the presentation. So I have a question about the, how do you organize the relationship between the developers and the OSPO members? How can you gather the engineers in this activity? Okay, this one involving developers to... Maybe previous slide, or this one, not this one. Sorry, oh, sorry, but my question is how do you gather the engineers, get the interest from the engineers to do this kind of activity? As we showed earlier, we have a certification for open chain and we already had a very strict process internally. So every product developer had a problem in proceeding the process. So they needed some help. And that time we created OSPO and we asked them for any help they need. Then they agreed to work with us. And also we provide, as you see in the left side of this, we provide them some kind of open source training for them. So we are working together good. Thank you. So which group is actually running your open source scanning tools like Fossology and FOSSID? Is that the group in India or is that the product developers? India team. So that means the India team has access to the source code for the different products? Yes. Regarding the source code, gathering all the source code to scan is a kind of big problem. So in that case, also this India team and product developers work together to gather all the source code to scan. Three minutes left. Can we close this session? Okay, thank you very much.