OpenHarmony, an operating sytem with OpenChain in mind
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Piana, Carlo
Ricci, Davide
OpenHarmony is a new operating system stewarded by Huawei's Open Source Technology Center, with Array as advisor. Having prioritized compliance, governance and transparency, OpenChain was the natural backdrop for it. Rather than embracing open source only to exploit it, having transparency and compliance as a last minute afterthought, OSTC has made them central pillars from the very beginning. We seek the opportunity to present you how the goal of OpenChain conformance helped. Born as an internal project, since its conception OpenHarmony's future has been to live in an independent, respected foundation that will receive all the tool for keeping it a truly community-driven operating system. The tools that Will be donated do include a compliance toolchain with source code scanning, compliance policy documents and roles, a Bill of Material for the initial release and many other artifacts to make it sure compliance is not a one-off exercise, but an ongoing commitment for the entire life of the project. Full conformance with Openchain is projected in a short-term future and it is surely a motivation to start with the right steps and making the right choice off the very beginning of the project.
 Good afternoon. My name is Carlo Piana. I'm an Italian lawyer dedicated to free and open source software mainly. And today we are presenting with my good friend and client, David Ricci, on Open Chain in Open Harmony and how the two play together and what we are doing for achieving, finally, eventually conformance to Open Chain. So in a short time, I will be handing over to David to present himself. Of course, as this is a pre-recorded statement, we are ready to answer any of your questions. I will be joined by my good friend and colleague, Alberto Piano, who is also available for taking questions. And any curiosity, any questions, please don't hesitate. David, over to you now. Thanks, Carlo. Carlo, can you see the screen? I can see your screen. Perfect. So thanks for handing it over to me. So my name is David and I'm joining you guys from Milano. It's a pleasure to be here. And Carlo has invited me to present Open Harmony. So we'll start from there. And then he's going to take over and explain better Open Chain and how the two work together. So David, I'm the director of the open source technology center at Wildwood. I have a master of science in computer engineering, degrees, artificial intelligence and robotics, and I spent 15 and plus years in open source at Moondrower. And Moondrower was part of Intel, worked very closely with the tele-open source technology center at that time. Throughout my career, I've been a bit of everything from Linux kernel developer to field application engineer, product manager, director of product management, and general manager of open source platform teams. And in this capacity, I run the open source technology center at Wildway. I've contributed to many open source projects, including the after projects, separate project, Open Chain, Open Virtualization Alliance, work with the Clis and use the Clips IDE for my open source product in the past and plan to use it in the future. So what is Open Harmony? So Open Harmony is meant to be an operating system, a software stack across all consumer devices. The idea is that to build an edge to cloud operating system. It's been initially developed by Wildway under the brand name of Harmony OS, and then it's going to be progressively contributed to the open source community under the brand name of Open Harmony. The goal is that to leverage the broadest spectrum possible of open source components. And as you guys know, each component in open source can't really turn license and copyright and license dictated obligations. The idea is that to deliver on the promise of autonomous cooperative devices. So the goal is that once we integrate existing kernels and open source components together, and each device, consumer device, say in the household, share the same operating system. Now you can start developing and enabling interesting things such as devices knowing that they exist, one with each other, devices understanding what applications they need to fulfill together, and devices collaborating one with each other to fulfill an application. The example that I use typically at this point is supposed to you're doing a multimedia zoom call, like the one that we're registering recording this talk onto. And you started from your phone. And your phone detects that there are open Harmony devices running in the house, namely TV with a 4k display and the microphone for your telephone and suddenly Dolby speaker surround. And then the phone and the application will ask you if you want to run in an optimized way, which means that you're going to be leveraging the display from the 4k TV for the best experience possible. You're going to be leveraging the microphone from your phone because it's close to your mouth and the voice. You're going to be leveraging the surround speaker from your Dolby surround system because that's where the audio is best processed from. So the idea is to integrate as many open source components as possible to build the ultimate vision of intelligent, complicating consumer devices. The initial code is being donated in China. You can find it on gt.com, open Harmony. Effectively in Europe, we are developing the European version of it that has slightly different requirements initially when it comes, for instance, to the way that we cooperate with partners by leveraging existing foundation-open governance. And certainly we're making IP compliance and false compliance as one of the top priorities. The idea is that by March, I have a bit of a roadmap later, we're going to be donating the first code base to the European set of customer and the first official release of the project will be released in November later in 2021. So why false compliance must come first and why open source, why myself, and why after many years in the open source community, and why is open source strategic to why? Well, it is strategic to why with multiple reasons. Number one, it does break vendor lock-in. So effectively, no companies is locked into the technology provided by another company or wherever those companies are located. It means that all of our products are built upon technology that is shared by most of our customers and partners as well. If it's done right, and I underlined the fact if it's done right, it does increase the brand value for Huawei. It also means that all eyes are on us to do it right. So if done right, you know, it's expected, but if it's not done right with all eyes on us, then that's going to be a problem. And doing it right means putting false compliance and IP compliance at first. And it was one of the initiator of the Open Chain project when I was back in the States. I think it was 2015, if I'm not mistaken. And so coming from the software as a product mindset, and I know that, you know, having a policy that captures roles, responsibility and processes for dealing with components of open source nature is paramount to assess the risk of releasing a product and doing something with that risk. At the end of the day, it's about business decisions. And the business is best done if the risks are calculated, right, and managed. So Open Chain, false compliance, IP compliance policies allow somebody who is supposed to release an open source product to know exactly where the risks are and take the right decisions. I lead the Open Source Technology Center, ESSEP, which is an open source group that has been built by Huawei in Europe, leveraging talents across the side of R&D centers that Huawei has in Europe. Right now at the moment, we have people in Milan like myself, Munich, Warsaw, Helsinki, London, court, Lyon, as well as R&D personnel in India. The Open Source Technology Center has been run as a BU, so software becomes core and strategic since open source is strategic to Huawei. So we're running it with an R&D group, but we have engineering, functions, marketing, product management, field engineering, evangelism, and yes, IP compliance, so an audit group, etc. And of course, the first big project, as I mentioned, is Open Harmony, right, to take you to Europe. A bit of timing, and a bit of a team that is working on false compliance before I hand it back over to Carlo. So as I said, OSDC was funded at the beginning of 2020, so we're spending time staffing the key functions and building up the team that you've seen some faces from in the slide before. Building processes and infrastructure, one of those processes is IP compliance and infrastructure are for instance, compliance scanning toolchain based on saver use and facology. Carlo would talk more about that. Then before you launch an Open Source Project in any location, you do a market analysis, you understand your partners and the market needs. In September, the first technology became available from Harmony to Open Harmony from China. Since then, we've been onboarding partners and we've been assessing the technology, understanding the readiness for the launch in the European market, building a DevOps infrastructure, preparing the code. And then in September, at the same time, we started the activity around license compliance. And a bit more in for that, you know, just go back to September, we started by looking at the policy. Once the policy was somehow sketched, we started training personnel, because one of the important points of the Open Chain compliance is training for personnel. At the same time, we started setting up DevOps toolchain for IP compliance, any component that we bring in, you know, scan, and then it's, you know, it's the license is determined, and then if there's a risk, it's flagged. So that would do this continuously as early as possible, release early release often. We don't keep, you know, IP compliance and fast compliance as an afterthought. But as you can see, it's done since the very beginning. This led us to the generation of the first bill of materials. So the analysis of and creation of the manifest of all the components that we have integrated with your license. And, and then once it's done, it's about tweaking, right? It's about this is never done, you start early, but that is never done, because you have to tweak the policy, new open chain specifications comes available, you update the policy, you train new personnel, you make the bomb better, you update the toolchain DevOps pipeline. So it's about continuous improvement over time. So it's something that if you start early, you minimize the risk where you cannot stop. So you have to keep training and improving, right? There's no getting, you know, there's no staying the same. It's about either getting worse or better. So we definitely want to get better at this. With this, introducing the IP compliance project for open harmony. Carlo, I'll stop presenting and I'm going to hand it over back to you. Oh, thank you, Davide. That was really interesting. I've seen this already, but anytime it's it's all the more fun. So we decided to prevent this introduction because you know what the scope of the project is. And so also the magnitude of the project and therefore the task that's at hand with us. And, and also the stage of development. So as David has said, this is something that comes from the very beginning, thinking about open source compliance and open chain conformance. So this presentation is not to just to praise us how good we are and what we have achieved, but it's rather to expose ourselves to the to criticism possibly or to and for by all means to be sort of forced to be delivering what we are probably. So this is not a one off thing is something that we plan to redo maybe next year, maybe the year after. So in a bit of more formal context, this is to my reckoning, the first time that we are seeing a new operating system or all the more a new open source operating system being developed in the full open since day one. When strategic decision are still liquid, everything is possible. Therefore, I cannot but praise the decision to get us on board since the beginning. The fact that we are interacting with the development team not just to ensure compliance as an exposed, but helping devising the whole process in the beginning. It's something that we believe is a prime for a project, at least of this magnitude and so ambitious. So in my understanding, and from my experience as well, conformance and compliance are usually done later in the process by retrofitting an environment where compliance were delayed to a later stage of maturity. I myself, when myself and my colleague Alberto have been summoned to a compliant process, we perceived that our intervention was kind of seen as a necessary perhaps, but an annoyance or a source of delay. This is different. This is a long preamble to just say this is not the grand finale of a success story, is not an epic journey, is not the depiction of the battle over the Pelinore fields. It is rather maybe a number of zero of a series that we trust will be, if not entertaining, at least interesting and somewhat instructive. So out of metaphor, as I said, we plan to be back and reporting you, but for the time being, we have the secret ambitions to be setting an example for other projects as to what it is possible to do even for a corporate sponsor, like large projects, which is directed at satisfying an entire wide industry from IoT to entertainment devices to smartphone. But that now some juice. First, what? What we are making possible, we're making public. And as David said, pretty much everything. And by pretty much everything, as I said, things that normally get done are not exposed, like the guts of the process, the entire project will be exposed. And all the more, Huawei is even going to donate the entire project to a newly formed working group within a well-respected and independent foundation. So the project in this new incarnation will inherit what we're doing now. And it's important to stress that since Huawei is going to be also a client of this new form, newly formed working group, no effort will be spared by it to make sure that also the project upstream is conformant to Open Chain as Huawei OSDC wants to be. So it's well playing both sides of the net. The when is also important. As I said, from the beginning, we are making available everything as they become available to us. So for the first bit has been the policy and in future, we have many things in the world. Some of that are house bake, off-credits. Some of them are more advanced. So bear with me. Policy first. This is not finalized too, but it's quite advanced. We have decided to, and you can find it, there is a link in the slides, we have decided to separate the public part with something more company specific, but we shifted pretty much the everything to the public side. Also the implementation base. So you will find there, of course, the overarching rules, the principles and the roles. And as they become available also, the many, many of the things that the roles, the interplay between the very various actors and so on and so forth. Other things on privacy concerns mainly will not be made public, like the actual names who has gone through compulsory education and so on. But the rest will be, and is already somewhat public. Now the forward looking, something that you are not yet able to see, but you will be seeing in a near future. So the tool chain is built on two main building blocks, which are scan code and phasology. One might wonder why we are using something that is often perceived as covering more or less the same. We have an extensive experience in using phasology. We have even, I am and mainly my colleague, Alberto Pianon, have developed a tool set to complement phasology for compliance works. And we have been pointed out to scan code, which is also very good. And when deciding which one to use, we decided to use both. Because one complements the other, in some cases, scan code has better results. Sometimes phasology has better results. But combining that together, we are feeding more quality information and we cross-check what we find from the actual automated scans. We have worked with Neutech Park of Bolzano to make this available directly into a CI pipeline in GitLab. So everything should be, is already working and is working by making everything. And I am showing you in a second how this is being implemented. So this is quite difficult to read because it is made with plant UML. But I am trying to explain to you what you are seeing here. We have basically five different actors. One is developers, of course. There is a GitLab CI pipeline. This is the most interesting bit. It is a phasology wrapper, something that does things that are fed into phasology, which is the fourth. And of course, as Open Chain mandates, there is a noted team that follows and takes the decision. So first, we have some triggering events, like committing on a massive branch or using a new tag, whatever. This is yet to be decided. It will be decided. And this triggers the CI pipeline. The CI pipeline just provides package sources and metadata. And this is the place where the most interesting bits happen. Of course, the sources are uploaded to phasology made available for scanning. The developer triggers running built-in scanners in phasology. And at the same time, in scan code, scan code will pass the results to a phasology through an SPDX, which is slightly changed. And this is also very important. We have a database of past decisions. So we are reusing decisions that we have made in the past. And possibly, we have imported from other sources. We will come to that in a few minutes. All of this is, of course, fully automated. But that doesn't end with that. Of course, phasology outputs its own report as a raw report. And the wrapper adds information and consolidates that phasology establishes licensing to the single file level. And we are condensing it and making information as to the project, the package. So we are presenting information to the package. Additionally, this is not the pipeline that has a pass-non-pass. Ideally, the pipeline doesn't stop further adding new comments. But at the same time, it outputs information for the developers that make evident what the status of the package analysis is. So we use status badges. These are yellow because there hasn't been no final decision, no assertion, because this is just the result of automated scans. And it's not yet ready for shipping. So the developer knows what the status is. But this package, this project is not really to ship in this form. What misses? The missing part is the human decision. No package will be out without human interaction and human decision. So the audit team is notified and prompted to look into the raw report and to make decisions which will depend. The next part, if there are no new commits in the intervening time occurs, the audit team just launches the pipeline after having provided the necessary information and decisions. So the pipeline is run again. And of course, if there is nothing new, no new versions. And by new versions, I mean no new major versions, because we're not just making a one comparison to say if the hash is identical. We assume that if the no major version of the package has been added and no big variations in the language occur, the package is the same. So we can reuse the decision where they've been made and a new SPDX generator. And this time, it runs again, this time you see a lot of green and blue, meaning that all the files in the package have been processed, the SPDX is available. And we have concluded this package is Apache 2.0. This is not enough yet, because this is a package level. But package can either have many or several license applicable depending on the decisions you make at the compile time. Plus, these does not tell everything about the interaction of this package with other package, possibly with copy left publications. So you need to do another step, which is generating a graph of dependencies. In our experience, from our point of view, you can do it only at build time, because only when you have a completely built version of the package, you know what counts. And the best way we have found so far is to do a binary analysis. Also, because SPDX cannot store abstract dependencies of the package in a native way, and so there's a machine readable way. And this is a job that we have devised that tree for storing and reusing this information. And this leads me to another bit, which is quite important and bear with me, because this is something for which we need advice, perhaps, or we need a contribution. So I said that we reuse the result of our scans and decisions, but since OpenHarmony uses Yocto and Yocto is built for making an entire distribution, many other packages are just called in. They are inserted, and they need also to be scrutinized. And there is a lack of information on this decision from the outside. And it's difficult to find this. Clearly, the find is there for that, but they are at a very different focus. So we are planning to use already reliable, very reliable information from, for instance, the Debian to present a curated database that comes from reliable sources, is processed by us, and will be made available either by CC, Creative Commons, or ourselves, and maybe contribute, also contributed upstream to a project, maybe clearly define what we are, the things. And this is going to be a full SPDS compliance and really with a few transformations to be fed into physiology. And if you know of other efforts, and if you know of other initiatives comparable or have suggestions, please by opening Fly Them Up. Very quickly, because we're running out of time, we also are committing to reuse. Reuse is a project of the Software Foundation Europe, and is a standard for declaring copyright statements in a standard wise way, so that for your own software, you are telling out with a clear voice with a one single language, what is the what is the license applicable to your own software. And we are, on the one hand, we're trying to convince and to lead by example to our downstream implementers to also use these for their own projects. And the second bit, since we are convinced that this is one of the ways to go for easing up compliance, to do the same and proposing as a pull request to our upstream to also use this as their foundation. So this is something we are still have to decide, but it's just an idea, but we are happy to hear your comments. This has been, I think, a quite comprehensive view of what we have so far and we project to do. And of course, we are, as I said, ready to take your questions, your comments, perhaps some of them have already been answered. And I hand over to David for the final bye bye. Thank you. Thank you, Carlo, and thank you, everybody. It was a pleasure to speak and fuzz them again. Any questions, you guys know where to find us. And with this, I think, you know, that's it. Adios, bye bye. Thanks very much. Bye.
 Good afternoon. My name is Carlo Piana. I'm an Italian lawyer dedicated to free and open  source software mainly. And today we are presenting with my good friend and client,  David Ricci, on Open Chain in Open Harmony and how the two play together and what we are doing  for achieving, finally, eventually conformance to Open Chain. So in a short time, I will be  handing over to David to present himself. Of course, as this is a pre-recorded statement,  we are ready to answer any of your questions. I will be joined by my good friend and colleague,  Alberto Piano, who is also available for taking questions. And any curiosity,  any questions, please don't hesitate. David, over to you now.  Thanks, Carlo. Carlo, can you see the screen? I can see your screen.  Perfect. So thanks for handing it over to me. So my name is David and I'm joining you guys from  Milano. It's a pleasure to be here. And Carlo has invited me to present Open Harmony. So we'll  start from there. And then he's going to take over and explain better Open Chain and how the two  work together. So David, I'm the director of the open source technology center at Wildwood. I have a  master of science in computer engineering, degrees, artificial intelligence and robotics,  and I spent 15 and plus years in open source at Moondrower. And Moondrower was part of  Intel, worked very closely with the tele-open source technology center at that time. Throughout  my career, I've been a bit of everything from Linux kernel developer to field application  engineer, product manager, director of product management, and general manager of open source  platform teams. And in this capacity, I run the open source technology center at Wildway. I've  contributed to many open source projects, including the after projects, separate project,  Open Chain, Open Virtualization Alliance, work with the Clis and use the Clips IDE for my open  source product in the past and plan to use it in the future. So what is Open Harmony? So Open  Harmony is meant to be an operating system, a software stack across all consumer devices. The  idea is that to build an edge to cloud operating system. It's been initially developed by Wildway  under the brand name of Harmony OS, and then it's going to be progressively contributed to the  open source community under the brand name of Open Harmony. The goal is that to leverage the  broadest spectrum possible of open source components. And as you guys know, each component in  open source can't really turn license and copyright and license dictated obligations. The idea is  that to deliver on the promise of autonomous cooperative devices. So the goal is that once we  integrate existing kernels and open source components together, and each device, consumer  device, say in the household, share the same operating system. Now you can start developing and  enabling interesting things such as devices knowing that they exist, one with each other,  devices understanding what applications they need to fulfill together, and devices collaborating  one with each other to fulfill an application. The example that I use typically at this point is  supposed to you're doing a multimedia zoom call, like the one that we're registering recording  this talk onto. And you started from your phone. And your phone detects that there are open  Harmony devices running in the house, namely TV with a 4k display and the microphone for your  telephone and suddenly Dolby speaker surround. And then the phone and the application will ask  you if you want to run in an optimized way, which means that you're going to be leveraging the  display from the 4k TV for the best experience possible. You're going to be leveraging the  microphone from your phone because it's close to your mouth and the voice. You're going to be  leveraging the surround speaker from your Dolby surround system because that's where the audio  is best processed from. So the idea is to integrate as many open source components as possible to  build the ultimate vision of intelligent, complicating consumer devices. The initial code is  being donated in China. You can find it on gt.com, open Harmony. Effectively in Europe, we are  developing the European version of it that has slightly different requirements initially when  it comes, for instance, to the way that we cooperate with partners by leveraging existing  foundation-open governance. And certainly we're making IP compliance and false compliance as one  of the top priorities. The idea is that by March, I have a bit of a roadmap later, we're going to be  donating the first code base to the European set of customer and the first official release of the  project will be released in November later in 2021. So why false compliance must come first and why  open source, why myself, and why after many years in the open source community, and why is open  source strategic to why? Well, it is strategic to why with multiple reasons. Number one, it does  break vendor lock-in. So effectively, no companies is locked into the technology provided by another  company or wherever those companies are located. It means that all of our products are built upon  technology that is shared by most of our customers and partners as well. If it's done right, and I  underlined the fact if it's done right, it does increase the brand value for Huawei. It also means  that all eyes are on us to do it right. So if done right, you know, it's expected, but if it's not  done right with all eyes on us, then that's going to be a problem. And doing it right means  putting false compliance and IP compliance at first. And it was one of the initiator of the  Open Chain project when I was back in the States. I think it was 2015, if I'm not mistaken. And so  coming from the software as a product mindset, and I know that, you know, having a policy that  captures roles, responsibility and processes for dealing with components of open source nature  is paramount to assess the risk of releasing a product and doing something with that risk. At  the end of the day, it's about business decisions. And the business is best done if the risks are  calculated, right, and managed. So Open Chain, false compliance, IP compliance policies allow  somebody who is supposed to release an open source product to know exactly where the risks are and  take the right decisions. I lead the Open Source Technology Center, ESSEP, which is an open source  group that has been built by Huawei in Europe, leveraging talents across the side of R&D centers  that Huawei has in Europe. Right now at the moment, we have people in Milan like myself, Munich,  Warsaw, Helsinki, London, court, Lyon, as well as R&D personnel in India. The Open Source Technology  Center has been run as a BU, so software becomes core and strategic since open source is strategic  to Huawei. So we're running it with an R&D group, but we have engineering, functions, marketing,  product management, field engineering, evangelism, and yes, IP compliance, so an audit group, etc.  And of course, the first big project, as I mentioned, is Open Harmony, right, to take you to Europe.  A bit of timing, and a bit of a team that is working on false compliance before I hand it back  over to Carlo. So as I said, OSDC was funded at the beginning of 2020, so we're spending time  staffing the key functions and building up the team that you've seen some faces from in the slide  before. Building processes and infrastructure, one of those processes is IP compliance and  infrastructure are for instance, compliance scanning toolchain based on saver use and facology.  Carlo would talk more about that. Then before you launch an Open Source Project in any location,  you do a market analysis, you understand your partners and the market needs.  In September, the first technology became available from Harmony to Open Harmony from China.  Since then, we've been onboarding partners and we've been assessing the technology,  understanding the readiness for the launch in the European market, building a DevOps infrastructure,  preparing the code. And then in September, at the same time, we started the activity around  license compliance. And a bit more in for that, you know, just go back to September, we started  by looking at the policy. Once the policy was somehow sketched, we started training personnel,  because one of the important points of the Open Chain compliance is training for personnel.  At the same time, we started setting up DevOps toolchain for IP compliance, any component that  we bring in, you know, scan, and then it's, you know, it's the license is determined, and then  if there's a risk, it's flagged. So that would do this continuously as early as possible, release  early release often. We don't keep, you know, IP compliance and fast compliance as an afterthought.  But as you can see, it's done since the very beginning. This led us to the generation of the  first bill of materials. So the analysis of and creation of the manifest of all the components  that we have integrated with your license. And, and then once it's done, it's about tweaking,  right? It's about this is never done, you start early, but that is never done, because you have  to tweak the policy, new open chain specifications comes available, you update the policy, you train  new personnel, you make the bomb better, you update the toolchain DevOps pipeline. So it's  about continuous improvement over time. So it's something that if you start early, you minimize  the risk where you cannot stop. So you have to keep training and improving, right? There's no  getting, you know, there's no staying the same. It's about either getting worse or better. So  we definitely want to get better at this. With this, introducing the IP compliance project for  open harmony. Carlo, I'll stop presenting and I'm going to hand it over back to you.  Oh, thank you, Davide. That was really interesting. I've seen this already, but anytime it's  it's all the more fun. So we decided to prevent this introduction because you know what the scope  of the project is. And so also the magnitude of the project and therefore the task that's  at hand with us. And, and also the stage of development. So as David has said,  this is something that comes from the very beginning, thinking about open source compliance  and open chain conformance. So this presentation is not to just to praise us how good we are and  what we have achieved, but it's rather to expose ourselves to the to criticism possibly or to  and for by all means to be sort of forced to be delivering what we are probably. So this is not  a one off thing is something that we plan to redo maybe next year, maybe the year after. So in a  bit of more formal context, this is to my reckoning, the first time that we are seeing a new operating  system or all the more a new open source operating system being developed in the full open since  day one. When strategic decision are still liquid, everything is possible. Therefore, I cannot but  praise the decision to get us on board since the beginning. The fact that we are interacting  with the development team not just to ensure compliance as an exposed, but helping devising  the whole process in the beginning. It's something that we believe is a prime for a project,  at least of this magnitude and so ambitious. So in my understanding, and from my experience as well,  conformance and compliance are usually done later in the process by retrofitting an  environment where compliance were delayed to a later stage of maturity. I myself, when  myself and my colleague Alberto have been summoned to a compliant process, we perceived  that our intervention was kind of seen as a necessary perhaps, but an annoyance or a source  of delay. This is different. This is a long preamble to just say this is not the grand finale of a  success story, is not an epic journey, is not the depiction of the battle over the Pelinore fields.  It is rather maybe a number of zero of a series that we trust will be, if not entertaining, at  least interesting and somewhat instructive. So out of metaphor, as I said, we plan to be back  and reporting you, but for the time being, we have the secret ambitions to be setting an example  for other projects as to what it is possible to do even for a corporate sponsor, like large projects,  which is directed at satisfying an entire wide industry from IoT to entertainment devices to  smartphone. But that now some juice. First, what? What we are making possible, we're making public.  And as David said, pretty much everything. And by pretty much everything, as I said,  things that normally get done are not exposed, like the guts of the process, the entire project  will be exposed. And all the more, Huawei is even going to donate the entire project to a newly  formed working group within a well-respected and independent foundation. So the project in this  new incarnation will inherit what we're doing now. And it's important to stress that since Huawei  is going to be also a client of this new form, newly formed working group, no effort will be  spared by it to make sure that also the project upstream is conformant to Open Chain as Huawei  OSDC wants to be. So it's well playing both sides of the net.  The when is also important. As I said, from the beginning, we are making available everything  as they become available to us. So for the first bit has been the policy and in future,  we have many things in the world. Some of that are house bake, off-credits. Some of them are  more advanced. So bear with me. Policy first. This is not finalized too, but it's quite advanced.  We have decided to, and you can find it, there is a link in the slides, we have decided to  separate the public part with something more company specific, but we shifted pretty much  the everything to the public side. Also the implementation base. So you will find there,  of course, the overarching rules, the principles and the roles. And as they become  available also, the many, many of the things that the roles, the interplay between the very  various actors and so on and so forth. Other things on privacy concerns mainly will not be made  public, like the actual names who has gone through compulsory education and so on. But  the rest will be, and is already somewhat public. Now the forward looking, something that you are not  yet able to see, but you will be seeing in a near future. So the tool chain is built on two main  building blocks, which are scan code and phasology. One might wonder why we are using something that  is often perceived as covering more or less the same. We have an extensive experience in using  phasology. We have even, I am and mainly my colleague, Alberto Pianon, have developed a tool  set to complement phasology for compliance works. And we have been pointed out to scan code, which  is also very good. And when deciding which one to use, we decided to use both. Because one  complements the other, in some cases, scan code has better results. Sometimes phasology has better  results. But combining that together, we are feeding more quality information and we cross-check  what we find from the actual automated scans. We have worked with Neutech Park of Bolzano  to make this available directly into a CI pipeline in GitLab. So everything should be,  is already working and is working by making everything. And I am showing you in a second  how this is being implemented. So this is quite difficult to read because it is made with  plant UML. But I am trying to explain to you what you are seeing here. We have basically  five different actors. One is developers, of course. There is a GitLab CI pipeline. This is  the most interesting bit. It is a phasology wrapper, something that does things that are fed  into phasology, which is the fourth. And of course, as Open Chain mandates, there is a noted team  that follows and takes the decision. So first, we have some triggering events, like  committing on a massive branch or using a new tag, whatever. This is yet to be decided.  It will be decided. And this triggers the CI pipeline. The CI pipeline just provides  package sources and metadata. And this is the place where the most interesting bits happen.  Of course, the sources are uploaded to phasology made available for scanning.  The developer triggers running built-in scanners in phasology. And at the same time,  in scan code, scan code will pass the results to a phasology through an SPDX, which is slightly  changed. And this is also very important. We have a database of past decisions. So we are  reusing decisions that we have made in the past. And possibly, we have imported from other sources.  We will come to that in a few minutes. All of this is, of course, fully automated. But that  doesn't end with that. Of course, phasology outputs its own report as a raw report. And the  wrapper adds information and consolidates that phasology establishes licensing to the single  file level. And we are condensing it and making information as to the project, the package.  So we are presenting information to the package. Additionally, this is not the pipeline that  has a pass-non-pass. Ideally, the pipeline doesn't stop further adding new comments.  But at the same time, it outputs information for the developers that make evident what the  status of the package analysis is. So we use status badges. These are yellow because there  hasn't been no final decision, no assertion, because this is just the result of automated scans.  And it's not yet ready for shipping. So the developer knows what the status is. But  this package, this project is not really to ship in this form. What misses? The missing part is the  human decision. No package will be out without human interaction and human decision. So the  audit team is notified and prompted to look into the raw report and to make decisions which will  depend. The next part, if there are no new commits in the intervening time occurs, the audit team  just launches the pipeline after having provided the necessary information and decisions. So  the pipeline is run again. And of course, if there is nothing new, no new versions. And by new  versions, I mean no new major versions, because we're not just making a one comparison to say if  the hash is identical. We assume that if the no major version of the package has been added and  no big variations in the language occur, the package is the same. So we can reuse the decision  where they've been made and a new SPDX generator. And this time, it runs again, this time you see  a lot of green and blue, meaning that all the files in the package have been processed, the SPDX  is available. And we have concluded this package is Apache 2.0. This is not enough yet, because  this is a package level. But package can either have many or several license  applicable depending on the decisions you make at the compile time. Plus, these does not tell  everything about the interaction of this package with other package, possibly with  copy left publications. So you need to do another step, which is generating a graph of  dependencies. In our experience, from our point of view, you can do it only at build time, because  only when you have a completely built version of the package, you know what counts. And the best  way we have found so far is to do a binary analysis. Also, because SPDX cannot store  abstract dependencies of the package in a native way, and so there's a machine readable  way. And this is a job that we have devised that tree for storing and reusing this information.  And this leads me to another bit, which is quite important and bear with me, because this is  something for which we need advice, perhaps, or we need a contribution. So I said that we reuse  the result of our scans and decisions, but since OpenHarmony uses Yocto and Yocto is built for  making an entire distribution, many other packages are just called in. They are inserted, and they  need also to be scrutinized. And there is a lack of information on this decision from the outside.  And it's difficult to find this. Clearly, the find is there for that, but they are  at a very different focus. So we are planning to use already reliable, very reliable information from,  for instance, the Debian to present a curated database that comes from reliable sources,  is processed by us, and will be made available either by CC, Creative Commons, or ourselves,  and maybe contribute, also contributed upstream to a project, maybe clearly define what we are,  the things. And this is going to be a full SPDS compliance and really with a few transformations  to be fed into physiology. And if you know of other efforts, and if you know of other initiatives  comparable or have suggestions, please by opening Fly Them Up. Very quickly, because we're running out  of time, we also are committing to reuse. Reuse is a project of the Software Foundation Europe,  and is a standard for declaring copyright statements in a standard wise way, so that for your  own software, you are telling out with a clear voice with a one single language, what is the  what is the license applicable to your own software. And we are, on the one hand, we're trying to  convince and to lead by example to our downstream implementers to also use these for their own  projects. And the second bit, since we are convinced that this is one of the ways to go for easing up  compliance, to do the same and proposing as a pull request to our upstream to also use this as their  foundation. So this is something we are still have to decide, but it's just an idea, but we are  happy to hear your comments. This has been, I think, a quite comprehensive view of what we have  so far and we project to do. And of course, we are, as I said, ready to take your questions,  your comments, perhaps some of them have already been answered. And I hand over to David for the  final bye bye. Thank you. Thank you, Carlo, and thank you, everybody. It was a pleasure to speak  and fuzz them again. Any questions, you guys know where to find us. And with this, I think,  you know, that's it. Adios, bye bye. Thanks very much. Bye.
open_harmony52782_0_179.png open_harmony52782_180_1847.png open_harmony52782_1848_1943.png open_harmony52782_1944_3851.png open_harmony52782_3852_8147.png open_harmony52782_8148_8471.png open_harmony52782_8472_11231.png open_harmony52782_11232_11831.png open_harmony52782_11832_12059.png open_harmony52782_12060_12467.png open_harmony52782_12468_14147.png open_harmony52782_14148_16535.png open_harmony52782_16536_16835.png open_harmony52782_16836_22115.png open_harmony52782_22116_23855.png open_harmony52782_23856_24455.png open_harmony52782_24456_26447.png open_harmony52782_26448_28967.png open_harmony52782_28968_29027.png open_harmony52782_29028_29495.png open_harmony52782_29496_29783.png open_harmony52782_29784_31631.png open_harmony52782_31632_31931.png open_harmony52782_31932_32423.png open_harmony52782_32424_33827.png open_harmony52782_33828_34103.png open_harmony52782_34104_34307.png open_harmony52782_34308_34811.png open_harmony52782_34812_34943.png open_harmony52782_34944_35855.png open_harmony52782_35856_36659.png open_harmony52782_36660_36707.png open_harmony52782_36708_40427.png open_harmony52782_40428_42419.png open_harmony52782_42420_42911.png open_harmony52782_42912_43259.png open_harmony52782_43260_43836.png