Openchain overview: ISO/IEC 5230 Open Source License Compliance
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.
Thielscher, Jan
A short overview of the OpenChain project, its purpose, goals and the current state We will introduce the project, its current state, especially the ISO adoption, give a short overview of the requirements and link to the different certification schemes. Finally we will expose the working procedures and link the international working groups.
 Hello and welcome to the Open Chain session. In this session we want to give you an introduction into what Open Chain is about, what Open Source license compliance project is doing. My name is Jan Tieter. I am from EACG. EACG is a consultancy coming from the architecture part and is focusing on supporting organisations and getting a good deal out of Open Source. We came to the Open Source chain project in 2018 and it very much fits to our thoughts how Open Source compliance should be achieved. This is why we are pretty much happy to support the project and also happy and very enlightened about the latest achievements where this specification became recognised as an ISO standard, international standard. I only have a few minutes to make this complex topic or talk about this complex topic so I don't want to spend too much on talking around. The core idea of Open Chain project has always been to define the requirements that are relevant or an organisation should comply with to ensure that they are producing Open Source in a compliant way, meaning legally compliant in the first place. The idea is we have an inbound side of a company that is taking software as for example Open Source as inbound into its own procedures and processes to produce some artefacts that it then puts outbound into a downstream consumer. The idea is if this happens along a value chain, it is absolutely beneficial if you have a core set of training, policies and processes that allow you to manage all your Open Source in a very reliable manner so that you are able to produce an outbound product that is definitely compliant. If you think this away from the particular company into the value chain, then it comes clear that the overall benefit of a value chain that can trust or the inbounds it is receiving, because it is receiving it from a certified organisation that is doing or reliably delivering a compliant product that reduces the analysis efforts you have when you want to reuse the stuff or want to build upon it. This idea is quite a while ago achieved by particular companies and since then they have created this specification that is called the Open Chain specification and this recently in December 2020 has been recognised as an international standard under ISO 5230 and it is an open standard, it is available for everybody, it is something that you can really look into, materials are available and you can start implementing these things. So what is this all about? I want to give a quick overview, it is just a nutshell view so it is more complex behind but let us talk about the basic things. So there is the specification, it separates requirements into different domains, there is for example the foundational part that is requesting to have an open source policy available to make resources skilled that are capable of understanding what they have to do, that there is an awareness in your organisation that open source compliance is something relevant to take care of, you have to scope it in the sense of who is actually taking care of or involved in this topic and it should be clarified who is actually where, which part of the organisation is actually participating in this programme and also you should make sure that licence obligations are clearly understood and certain use cases can be managed. In the second domain it is about the capability to deliver, to assign the responsibilities to have people there on the outbound side that can take inquiries to search for, you have a process on how to search, that you are efficiently resourcing the people so that it is possible that the task can be fulfilled and it is not just a ticket that is hanging somewhere in a ticket system, it is about the review and approval within the project so when projects are using software, that they are producing bill of materials, that there is a clear process on how to document what is inside the software and that there is someone who is kindling the different cases when software is modified or understands what to do in case there is a certain business case to be fulfilled. Then it also should be ensured that the artefacts are provisioned, that everything that leaves the company is containing the responsible early requirements, fulfilling the specification and that there is an understanding of what happens, what I need to do, what are the policies when I want to contribute something back, seeing I have a fix or something, how do I handle this, how can this be treated. And last but not least, it is absolutely something that I did not understand in the beginning but it makes sense from the point of view in the value chain, if you declare your conformity, it is something that you on the one hand side have to maintain throughout the whole time because it is not a point in time thing, it is something that is very lasting, must be sure because and also it must be declared to build distrust. So these are the core domains of the requirements that you have to fulfill with this specification and there is a lot of material out there that is all freely available, look out at GitHub for the open chain project reference materials, they are there simple to access, they have been produced by international groups, working groups that are actively supporting further development and also building training materials and so on. The groups have been working on self-certification questionnaire that is available over the internet, you can go there, you can look into the question, see the status of your organization and will be able to either derive the need, what to do, where to close the gaps or with the help of some supporters you may use this to improve the organization that you are in. There is a globally physical distribution of partners, you find a lot of law firms that are in the partner program, there are two vendors that support open source compliance in the program, there is a lot of consulting companies that have specific knowledge how to drive your organization towards a compliant approach and there is third party certifications available. So there is a huge amount of knowledge out there that you can take and make your own compliance working. Be part of this, join us, there is a website, you can find a get started document and there is also a lot of material available, so whenever you have questions feel free to reach out to Shane Koffmann, he is the project lead from the Linux Foundation or direct your questions to one of the partners, for example you can reach me on OSC at EAC GDE and we will be happy to help to answer your questions and also I will be available in the Q&A session that is following this. Thank you for your attention and I am looking forward to your questions.
 Hello and welcome to the Open Chain session.  In this session we want to give you an introduction into what Open Chain is about, what Open Source  license compliance project is doing.  My name is Jan Tieter.  I am from EACG.  EACG is a consultancy coming from the architecture part and is focusing on supporting organisations  and getting a good deal out of Open Source.  We came to the Open Source chain project in 2018 and it very much fits to our thoughts  how Open Source compliance should be achieved.  This is why we are pretty much happy to support the project and also happy and very enlightened  about the latest achievements where this specification became recognised as an ISO standard, international  standard.  I only have a few minutes to make this complex topic or talk about this complex topic so  I don't want to spend too much on talking around.  The core idea of Open Chain project has always been to define the requirements that are relevant  or an organisation should comply with to ensure that they are producing Open Source  in a compliant way, meaning legally compliant in the first place.  The idea is we have an inbound side of a company that is taking software as for example Open  Source as inbound into its own procedures and processes to produce some artefacts that  it then puts outbound into a downstream consumer.  The idea is if this happens along a value chain, it is absolutely beneficial if you  have a core set of training, policies and processes that allow you to manage all your  Open Source in a very reliable manner so that you are able to produce an outbound product  that is definitely compliant.  If you think this away from the particular company into the value chain, then it comes  clear that the overall benefit of a value chain that can trust or the inbounds it is  receiving, because it is receiving it from a certified organisation that is doing or  reliably delivering a compliant product that reduces the analysis efforts you have when  you want to reuse the stuff or want to build upon it.  This idea is quite a while ago achieved by particular companies and since then they  have created this specification that is called the Open Chain specification and this recently  in December 2020 has been recognised as an international standard under ISO 5230 and  it is an open standard, it is available for everybody, it is something that you can really  look into, materials are available and you can start implementing these things.  So what is this all about?  I want to give a quick overview, it is just a nutshell view so it is more complex behind  but let us talk about the basic things.  So there is the specification, it separates requirements into different domains, there  is for example the foundational part that is requesting to have an open source policy  available to make resources skilled that are capable of understanding what they have to  do, that there is an awareness in your organisation that open source compliance is something relevant  to take care of, you have to scope it in the sense of who is actually taking care of or  involved in this topic and it should be clarified who is actually where, which part of the organisation  is actually participating in this programme and also you should make sure that licence  obligations are clearly understood and certain use cases can be managed.  In the second domain it is about the capability to deliver, to assign the responsibilities  to have people there on the outbound side that can take inquiries to search for, you  have a process on how to search, that you are efficiently resourcing the people so that  it is possible that the task can be fulfilled and it is not just a ticket that is hanging  somewhere in a ticket system, it is about the review and approval within the project  so when projects are using software, that they are producing bill of materials, that  there is a clear process on how to document what is inside the software and that there  is someone who is kindling the different cases when software is modified or understands what  to do in case there is a certain business case to be fulfilled.  Then it also should be ensured that the artefacts are provisioned, that everything that leaves  the company is containing the responsible early requirements, fulfilling the specification  and that there is an understanding of what happens, what I need to do, what are the policies  when I want to contribute something back, seeing I have a fix or something, how do I handle  this, how can this be treated.  And last but not least, it is absolutely something that I did not understand in the  beginning but it makes sense from the point of view in the value chain, if you declare  your conformity, it is something that you on the one hand side have to maintain throughout  the whole time because it is not a point in time thing, it is something that is very lasting,  must be sure because and also it must be declared to build distrust.  So these are the core domains of the requirements that you have to fulfill with this specification  and there is a lot of material out there that is all freely available, look out at GitHub  for the open chain project reference materials, they are there simple to access, they have  been produced by international groups, working groups that are actively supporting further  development and also building training materials and so on.  The groups have been working on self-certification questionnaire that is available over the internet,  you can go there, you can look into the question, see the status of your organization and will  be able to either derive the need, what to do, where to close the gaps or with the help  of some supporters you may use this to improve the organization that you are in.  There is a globally physical distribution of partners, you find a lot of law firms that  are in the partner program, there are two vendors that support open source compliance  in the program, there is a lot of consulting companies that have specific knowledge how  to drive your organization towards a compliant approach and there is third party certifications  available.  So there is a huge amount of knowledge out there that you can take and make your own  compliance working.  Be part of this, join us, there is a website, you can find a get started document and there  is also a lot of material available, so whenever you have questions feel free to reach out  to Shane Koffmann, he is the project lead from the Linux Foundation or direct your questions  to one of the partners, for example you can reach me on OSC at EAC GDE and we will be  happy to help to answer your questions and also I will be available in the Q&A session  that is following this.  Thank you for your attention and I am looking forward to your questions.
openchain_overview_0_155.png openchain_overview_156_2123.png openchain_overview_2124_2783.png openchain_overview_2784_4031.png openchain_overview_4032_6011.png openchain_overview_6012_7907.png openchain_overview_7908_9671.png openchain_overview_9672_10139.png openchain_overview_10140_11051.png openchain_overview_11052_11159.png openchain_overview_11160_11339.png openchain_overview_11340_11615.png openchain_overview_11616_12335.png openchain_overview_12336_12491.png openchain_overview_12492_13307.png openchain_overview_13308_13703.png openchain_overview_13704_14555.png openchain_overview_14556_14682.png