 Good morning, and welcome to join my session. I am really, really afraid this session might be the most boring session within this, you know, all, you know, presentation within this event, because I'd like to talk about something about the legal and something about the compliance of those kind of issues. I'd like to give you another, one of quite unique, maybe, aspect of what we are thinking about. So my name is Ueda. I am working for Sony as an Chief Open Alliance Manager. But my history of the open source is something long. I have been working for the, not only for Sony, but for the open world that is an establishment of the CE work group, or used to be a CE Linux forum, since about 15 years ago. Until then, then, I am working for, you know, something like a promotion of the Linux or many of the open source software to be used embedded system. Especially, maybe, you know, that many of Sony's products are another, you know, consumer electronics vendors' products are now using a bunch of open source software, including, of course, Linux and many. And within Sony Corporation, I have something of the mission to make some of the training for the open source software appropriately to use some of the advisory of the open source software strategy. And I'm getting to be so busy because of the bunch of products, a bunch of people are aware of the importance of the open source software as a quite strategic, you know, stuff. So this time, I'd like to talk about something about the use of the open source software. But I'm quite frankly speaking, it's a bit, you know, boring story still. Many people ask me about the appropriate use only the open source software. But only using open source software will not be so much, you know, interesting thing. Maybe it's missing some important thing, which I'd like to mention. Of course, I know the open source software license compliance about appropriate use is a really important thing, but I know many people do not understand appropriately. And also, somebody is making a big misunderstanding that the use of the open source software may cause litigation, which will be totally forced. And I'm performing the internal technical training course for the open source software appropriate use, and I have prepared about 180 pages of the text. And also, along with the 350 pages of the slides, it takes about eight hours to go through. And somebody gave me that nickname of this training course as an open source software boot camp. Well, I will never say that, you know, push up for the 20 times, at least you thought you were wrong in this question or something, but I will never let those kind of audience to sleep. Maybe I think everybody will have a great, you know, understanding of why it is so important. And this presentation is mainly quoted from those kind of, you know, training course. But unfortunately, it is not decided to publicize a whole bunch of the training course at this moment. But we are gradually thinking to disclose those kind of, you know, presentation material. And within the training material I have start this kind of question, what is the license? And I sometimes give this, you know, question to the attorney or legal staff. And everybody start thinking something, but I am thinking the right of the software authors are protected by copyright law. It's quite essential thing. And it is saying that therefore the author of the software have some right to make a grant of the use of those kind of copyrighted material. And how to express those kind of, you know, conditions to grant, that is written in license. So that I think the license, this is my understanding about the license is something of the document of describing the intention of the copyright holder, the condition of the use, and what will be intended to letting them use of those kind of copyrighted material. So that reading through the open source software license or some software license is really important to get to know the intention of the licenses. So without, you know, reading precisely about the open source software license, it is not allowed to use that kind of copyrighted material, which may be quite Majesty. And for the many cases, the license as copy, license serves intention will be described within the license three size three. So that only to do for the license see, license see to understand the license as intention is read carefully about a license, software license. It's quite simple. And many of the legal or some of the attorney can do it because they are quite accustomed to, you know, get rid of those kind of license text or some of the legal text. But the case of the open source software license is a little bit different because the person who write the license term and license is a different person. For example, the GPL. GPL is, you know, prepared by, of course, you know, the free software foundation. And of course, free software foundation itself is some of the, some softwares, you know, licensor. But for the many cases, the license of the, you know, GPL license software will not always the free software foundation think about Lennox. Lennox is not copyrighted by the free software foundation, but many of the people. So here might be existing some sort of the paradigms. The licensor is always borrowing the license text from some certain person like a free software foundation to use. And also, those kind of licensee always, you know, try to read the, you know, license text precisely. But you know that I'm afraid there's some gap because not always the licensor itself is fully, you know, are conveying from the license text holder's intention like a free software foundation. So that just reading the open source software license will not suffice to understand the licensor's, you know, condition. That is underlying within the open source software license itself. So that some of the open source, some of the legal person or attorney will become puzzled because just reading, you know, open source software license may not suffice to get to know the licensor's intention. That is some of the quite fundamental problem. So it means that just simply reading or not suffice, it means that we have to find a way to know another way to know the licensor's intention. That is maybe to get close relationship with licensor or I mean community. So it is quite essential to read the open source software license carefully. It's of course quite essential thing. But it will not suffice to understand the open source software licensor's intention. We need to understand the OSS development community's intention with another way that will be how to participate into the community maybe. So some of the legal or IP department person will get to be something of their concern that should we participate in community. I am really good at reading the license term or some of the copyrighted law or something like that. But I'm not software engineer. I have no chance to get into the community. Then I have no way to understand the community's intention. They may say, of course, they are quite accustomed to read the, you know, those kind of text, but their expertise will not set up on some of the software engineering or to know the software open source software community. Of course, there are several exempted people who are quite well-acquired of the technical background and the community background with the legal or attorney license or that kind of thing. But that's quite exceptional. So maybe we can trust those kind of people to read the term precisely and make some of the, you know, good suggestions, but we need something to follow them up. Many of the software engineers or the engineers regarding the legal and IP department person like that, if we ask something to legal or IP department, well, this is something of the open source software license under this term, please analyze some of the risks or some of the things we should consider, then they will say, guess what? Not only this, they will say some fear included. So we cannot criticize those kind of people because it is some of the mission of those kind of people. But software engineers themselves knows the way to communicate with the open source software development community. Why it is a community releasing the software under open source software license? Or what are the anticipation to the users or something like intention or some dreams or something like that, we can know. Maybe most of the audience here will be software engineers or those kind of technological background people. So we are always making this kind of appeal to the Sony employee that these think about the people developing the open source software when we use the open source software. Try to appropriately understand them. Not just, of course it is quite essential and important to read the open source software license term but we mustn't forget about these kind of things and also we'd like to try to become some of the appropriate and good citizen within this community. Apparently, it's fact. That is some of the top sentences, top charts of the chapter of the open source software training in the course within Sony and saying never stray from the right path or do something debilitating. So that this kind of relationship of the trust in between open source community and company will make us, both of us, happy, I think. And the worst thing is like this. Somebody tried to use open source software but neighbor and teacher tried to hide the fact of their use of an open source software. It will cause really bad situation. And we have to use the open source software quite open and quite, you know, with some of the owner or something like that. We should probably use the open source software in an open way. We should not attempt to hide the use of open source software. So that forming the, you know, legal or IP staff and software engineers, especially who knows the community, who have a talent of the community relationship will be quite essential to use the open source software appropriately. So that the first, you know, step we should do within each company is how to make some of internal community in between the legal, IP staff and software engineers, especially who knows the open source community. And we, those kind of collaboration will be able to make a sum of reporting to the person who can, who can judge the use of the open source software and they will be able to make appropriate business judgment. Then we will be able to use the open source software quite a complicated way. So that quite essential thing is if we can make up this kind of internal community or not. For Sony's case, we have established two types of open source community. One is the open source software license, you know, committee. That is a committee in between the legal person and software engineers from all the business units. And another committee is named Sony Open Source Board. Sony Open Source Board is a board to make a promotion to letting them, letting Sony's engineers to participate into the open source software community or making a donation of the open source software code, which is developed within Sony as an open source software. And maybe you will be able to see the Sony's official GitHub site, that is github.com slash Sony. And of course, that is not still a starting phase, but actually the project within the Sony official GitHub site is increasing. And I know that many of another company, advanced company like Microsoft or Samsung, Intel or those kind of company have a bunch of projects disclosed from that kind of GitHub site. But we are going to make some catching up to those kind of advanced companies. Anyway, that kind of internal community will be quite essential, I believe. So this kind of discussion will make a good result. And quite essential thing is how to make mutual trust each other. And this kind of phenomena, you know, environment will have a quite, you know, appropriate situation to use open source software. So then, risk will be removed. Well, we'd like to try to focus, try to aim at this kind of situation. Three important things is one. One is encourage software engineers to participate into the community and create in-house community. And tell what the open source software development community is intending. Like sometimes, Lena Stupos is making some of the comments in the mailing list or something. Like Lena's community is intending something blah blah blah or something like that. That kind of expressed, you know, information is quite useful to understand, to let those kind of understand who are not participating into the community. And also, those kind of information is not something like not touch it, but something like implicit so that we have to encourage as much engineers or as much people to participate into the EU community. And we have to say a great thanks to the Lena Foundation or those kind of persons who are organizing this kind of opportunity to make a, you know, a very, very intensive, you know, communication and collaboration looking at a point like the Lena conference or Lena scone and open source summit or those kind of events. And also, we are making a proposal to the software engineers showing something like quite shocking slides. Isn't that quite shocking? This slide is more shocking, you know, than I think. Of course, it is intentional. Do not think the bio computer or this kind of Sony-related computer is like this, you know, a stable computer, but it is intentional slides. What we should do? Well, this must be a worst case that I'm lost. What kind of software are we embedded into this product so that I have no way? That kind of thing will become quite an awful situation. If it happens upon some of the vulnerability or some of the quality issues, Sony will lose our reputation from the customer. And of course, if it is related to the some of the, you know, suggestion from the outsiders of the concern of the open source software license compliance, that, well, this kind of situation will make a quite, you know, terrible situation. So that we must, you know, this is a quite, you know, base fundamental, you know, requirement for the daily life of software engineering to record what you did, the record of the structure. Structural management is one of the quite important things. This is not only for the sake of the open source software license compliance, but of course it is quite essential for the quality or some of the vulnerability issue, which is quite essential and important. Do not make any, you know, black box within each product or each software, you know, software application software or some software package. And if you'd like to take some of the new open source software, well, somebody will always saying that, oh, here's a good open source, a good open source software. I checked the Google or something. I would see it as a good copy and paste immediately. That kind of behavior will make another mess. So that this is a picture which we are always saying, hey, I found cool software on the website, on the street side. Do not drink it. It may be poison. It may be something quite, you know, malicious or something. So that assess first whether we can use those kinds of software or not. Of course, one aspect is quality aspect. Another aspect is, you know, maintenance. If the, you know, software is not supported by some of the intensive, activated community, maybe we have to worry for some of the maintenance issue. Of course, in some cases, we take something of the open source software, which supporting, you know, open source community is not activated. To that's case, maybe Sony will try to activate those kind of software, or its open source software community. And maybe we are starting several, you know, projects to activate those kind of community. And also, open source software license compliance is another aspect. If we take some of the software, which Sony cannot make the, you know, open source software license compliance, maybe we mustn't take that kind of software. So that if you take, intake those kind of software from the outside, we have to be reminded like this, you know, picture. So software configuration management is really important and never hide the fact of using the open source software. And evaluate the open source software. When you intake, that's quite important and essential thing. We are emphasizing to the software engineers as well. And also, we are thinking about how to deal with the external communities. I mean that the supply chain is another, you know, important issue for us. If the supply chain people have, you know, appropriate knowledge and behavior, and Sony have appropriate knowledge and behavior, and Sony have also have the appropriate knowledge and behavior. It may be okay, but both are not so well becoming a really miserable situation and well know way. And even if the Sony have a well, you know, trained and well understanding the open source software, people dealing with those kind of, you know, supply chain issue, but without collaboration with the open-source OEM partners, we cannot do appropriate behavior to it. In some case, it's something embarrassing for Sony, but we have good, you know, suggestions. We got good suggestions from the OEM OEM partners, and we are paying great thanks to those kind of people. And of course, we should aim at this situation. Both Sony and both OEM OEM partners have good in understandings. And of course, one of the quite essential thing is that how to share the idea of the principles of the using open-source software. And maybe I think the principle of using open-source software is which I have already described, that think OSS community first, and follow the quite essential thing of the open source of the other software engineers. So now, we'd like to, you know, try to make this kind of sharing the idea of the quite essential thing with the Sony's partner companies. It's the starting phase, and we'd like to make another, you know, progress. Of course, we are thinking that the SPDX or OpenChains result is quite useful, and we'd like to use those kind of results as well. And we'd like to add Sony's original way of thinking, as I have already mentioned. So that I hope every, you know, partner companies also establish internal community of the legal IT staff together with the software engineers who know the open-source community well. And this kind of networking of the ideas will make both OEM OEM manufacturers, supply chain people and Sony ourselves happy. And of course, in order to make, you know, convey the, you know, actual information about the use of the open-source software, SPDX is quite, you know, remarkable and useful. And I hope the Linux Foundation to help both legal IT staff and also some of the provided opportunity to make a community relationship advisory to be vitalized. And of course, this kind of event is a really good event to make this kind of, you know, fostering those kind of people who to know the open-source software community reality. So this is another thing we are thinking as a sum of division, like making the OEM OEM supplier, a legal and IP expert and client ourselves together to think and together to make some of the trust of use of the open-source software and relate with the community. So this is a quote from the Ibrahim Haddad said, the Samsung People Center. Approximately the use of the open-source software, it is the engineering issue which is required legal health and it is quite, you know, good word and I'd like to say thanks to Ibrahim. Well, I wonder I'm forgetting something more important. That is, I'd like to introduce what we have experienced within Sony. This actually happened. Several years ago, we made, we start using one open-source software with some of the bug fixing. But unfortunately, we hold it, those kind of bug fix within Sony. And quite recently it happened. Another bug was reported. And also that was, of course, causing some of the vulnerability problem. We are obliged to make a version lab to the latest version. And when we evaluate that kind of latest version, we found it that the bug which Sony already, you know, found it out and fixed is still there. But the situation gets to become worse than we have expected in the older version. Every engineer said, I did not make the contribution of those kind of bugs previously. We made that kind of bug fix, you know, donation to the expert, you know, those kind to the good community people. Community people may make some sort of the maintenance together with those kind of bug fix. But they have lost the way to do it because Sony didn't make the, you know, contribution of those kind of bug fix. So we have learned one more with this, you know, situation. And now we set up one of the corporate inside, you know, that is making this kind of bug fixes to the open community. We can make a really, really simple, you know, approval to be taken. And we can make it quite, you know, instant. And of course, that is subject of the judgment of each manager or each, you know, engineers themselves. So that we'd like to make another, you know, promotion of those kind of things. We are on the way to make it anyway. This kind of thing, I'd like to recommend you, every of you, to do it. And this kind of situation may happen, not only within Sony but also within your company. So that donating the simple, you know, bug fix will make future of ours happy. But without doing that kind of thing, we will lose this kind of happy situation. But anyway, just using the open source software will not surface and will not cover 100% of the advantage of the open source software. Well, just wait someone to do something. That will not quite, you know, in an active way. Well, for example, you know that Sony is now going to use intensively the NATX. Two years ago, we have started evaluation of NATX, but I found that NATX, the community of NATX is not so much activated. But performed by some of the quite limited people supporting the NATX themselves. So that if we are the company which we look for someone to do something, just waiting someone to do something, maybe we have no way to judge the use of the NATX. But we have decided we should make another way of saying that make a contribution, not just waiting somebody to do some of the, you know, evolution of that kind of open source software. Then Sony got another, you know, freedom of the use of that kind of software because we decided ourselves to become the one of the person of the community, of the NATX. And of course, unfortunately, because of the limited human resources, that kind of activity is not yet sufficient. But that is laying behind within us, you know, judgment of the NATX to be used for our products. Of course, community people will not be so cruel and just waiting or just, you know, asking something to do for some kind of community. That will also be allowed. But sometimes maybe community people will say that I'm not a free of charge servant of you to create software. So go together with the community. That will be quite an important thing. Not just wait somebody to make the, you know, evolution of the certain open source software but involve it. That's right, together with the NATX, soaring to the sky together. That will make software engineers happy. OSS community is a place to make collaborative, you know, collaborative creation and innovation. And it is a place to learn how to make the innovation or how to foster the next generation of software engineer who are required to have the, you know, idea or skill to go together with, you know, partners, not solely by themselves. It is so complicated, you know, world. So that only single, you know, genius people have limited chance to make innovation. But a teamwork will make another, you know, resolution. So I'd like to come in with some of the early stages of the open source software for embedded system. We have decided to set three, you know, stages of the open source software for the embedded system people. One is, of course, the mainline community. Another is that we have encouraged every people to jump into the mainline community initially. But every people, especially Japanese people, are too shy to jump into the mainline community. It's really embarrassing. My disguise, I cannot speak English. What? I cannot speak English. What language are you speaking? I'm speaking English. Well, that's kind of funny thing. It's always happened, but no one, you know, tried to make a, you know, contribution to the community. But so that we have started to, you know, have the place of the international place to get together the person who are interested in the embedded system. That is embedded Linux conference. You know that ELC is now performed by the, you know, Linux Foundation. And every springtime and autumntime, we can get together globally in America and in Europe. And we also holding another event, that is Japan Technical Jamboree. Japan Technical Jamboree is allowing them to speak in Japanese. And we have not given the name of the, you know, technical conference to that kind of event. We named the event Jamboree. Think about the voice call people surrounding the campfire and speaking out quite freely about their dreams or their, you know, fault, their mistake or those kind of things. You made such kind of mistake or the teacher may say something quite, you know, tough thing for you. Next time, we'd like to do this kind of thing. That kind of thing will be talked around the, you know, campfire. That kind of, you know, atmosphere, I'd like to try to, you know, produce. And it's quite happy. But many people understood this kind of situation. So that it's something like a half step jump strategy. Hop into the Japan Jamboree. That is quite, you know, free space to speak Japanese. It's free space to speak. They are, even with the, you know, competitors companies because it's, you know, open source field. And next step is, you know, ELC in the United States and, you know, Europe. And then jump into the community. This is one of the strategies we set up. Hop, step, jump, you know, strategy into the community. And it's quite happy that that kind of, you know, strategy seems to be working well. And we are counting 60 times of the upcoming next Japan Jamboree. The schedule is March 17. And I hope to make a summary review of this kind of, you know, history of 60 times of the Japan Jamboree at next opportunity. Maybe I hope it happens in the, you know, in the ELC Europe if the, you know, organizer approved my session proposal. Anyway, this is all for my presentation and hope it to be useful and hope it, you know, informative for you to think something about it. Especially, I am proposing one of the way that the open source software license is something quite unique one, which is not always saying the same as the ordinary, you know, software license. That is because the person who prepared the license term is not the person who are making the, you know, open source software as an public, to the public says, I mean the licensor. Licensor's intention is not always, you know, covered within the licensor itself, but we have to make some of the additional way of thinking to consider together with the community itself. It's all. Thank you very much. If you have some suggestions or some of the comments or any discussion, please go ahead. Thank you very much.