 Hello there everyone, this is Shane Coughlin, General Manager of the OpenChain Project. We've got about 25 minutes in total for this virtual talk. I'd like to make sure that everyone feels comfortable with sending in comments and questions throughout the talk and I'll also be a little bit of time afterwards. Big shout out to Steve, Wally for telling me to break a leg. That's great, kind of you. Alrighty, let's type right in. So OpenChain is something that we've been cooking in the Linux Foundation for about three years and right now it's in the final stages of an ISO standardization process. In this way, it's a little bit interesting for the open source community. We're really used to building technology, we're really used to building new solutions and we very frequently create de facto industry standards. Sometimes it's code, sometimes it's something like a document format, sometimes it's something else. What we don't do super often is create ISO standards. The last time that the Linux Foundation created an ISO standard was when we did the Linux standard phase and that was first submitted 14 years ago. So it's been quite a long time that we haven't had formal standardization, we instead have focused on de facto standardization and the Linux Foundation is not alone in this. In general, that's what most of the open source community did. Of course, times change and with Linux at the heart of everything, with open source at the heart of everything. We now have to look at how we can work inside traditional standardization and how that's effective. OpenChain is the first Linux Foundation ISO standard in 14 years and I'm going to explain why that is and then I'll explain how other things like your projects can also do the same and of course, how difficult that will be in practice. Some context in general, as you probably know, given that you're in my audience at a Linux Foundation event, the Linux Foundation covers a huge amount of companies, an enormous amount of code and a tremendous amount of value. So we really are at the center of where software is in the technology supply chain and of course, if you're in the center for software areas, you're in the center for all technology. The OpenChain standard, the OpenChain project was created to help address the question of how do we ensure with open source effectively third party IP? How do we ensure that the compliance programs work effectively? How do we ensure everyone is following the appropriate licenses? Everyone gets a fair and equal degree of access to the code stack. So we have to think about how thousands of companies can access many hundreds of projects with billions of dollars of value in code. It's a very interesting challenge and there are numerous ways to approach it. The OpenChain standard is about how we do it in the simplest manner possible to accomplish the required mission. So key requirements for quality open source compliance program. Rather than doing something like enormous checklists when it comes to compliance, which of course would be both tedious and entirely impossible to implement in practice, we decided to define the inflection points, the process points where you need to have something in place. This is based on learned knowledge. It's based on what we know doesn't work in the community. Where we've seen failures inside ingest, internal development and deployment. So what we're looking at here is taking the learned experiences of when things go wrong and identifying that these things are solved by putting something at this inflection point or that inflection point and codifying that in a simple standard. OpenChain succeeds in about 12 pages and identifying the key inflection points where if you have something in place you will have the key requirements of a quality open source compliance program. It will reduce the chance of error dramatically based not on supposition, not on guessing, based on the fact of market reality, what we've observed. The idea of OpenChain is that company by company as people adopt this compliance standard, there'll be a chain of companies which have the key requirements of a quality open source compliance program. And therefore inside that chain of companies the level of trust is much higher. We know that each company is doing what's effective and what's needed to make sure that the open source licenses are correctly applied and to make sure that if something goes wrong remediation is quick and effective. Nice simple concept and the idea is ultimately that if companies are OpenChain conformant to a version of the standard, they can quickly display what version they're conformant to and their suppliers or customers can understand exactly how that company is contextualizing and filling out process points for open source compliance. This streamlines a lot of stuff. It means you can ask your supplier very quickly, okay, so you're OpenChain conformant. That means that you have internal training on OpenSource for the people who make decisions around OpenSource. Show me the training slides. Or you can ask something along the lines of you're OpenChain conformant. That means you have a company-wide OpenSource policy. Let me see the policy. This allows companies to kick the tires on each other, make sure everything is where they want it to be and where it isn't. They can say, okay, so I saw your training slides. They're okay, but they're not exactly what we'd like to see. So here's an example from our training slides. We'd like to see you adopting something like this. And those conversations lead to very productive solutions around OpenSource compliance. We're not gonna dig too long into this, but we are just gonna pass through some of the key points about how big OpenChain is. So the OpenChain mailing list, we've been active about three years. We've got over 3,700 participants on the mailing list from hundreds of companies. We have over 100 active contributors on GitHub. We've got automotive workgroups on a global scale, reference tooling on a global scale. Both of those are north of 100 participants somewhere in the region of 8,900 companies in each workgroup. We have regional activities in China, Japan, Korea, Taiwan, India, and Germany. These workgroups meet to talk through how OpenSource applies to them. In some areas, it's heavy in one industry. For example, in Germany, it's heavy on automotive. In some industries, it's very diverse. In Japan, it's just a real hodgepodge of companies, which is obvious, but 190 participants from over 100 companies. Long story short, a lot of people are working on OpenChain because a consolidated approach to OpenSource compliance is precisely what we need. There are numerous ways to address OpenChain conformance. You can meet the standard basically by self-certification, reading the standard or reading checklists that explain the standard and making sure you've got those processes in place. You can do independent compliance assessment where you think you've met the standard, but you ask someone else, like a consultancy or a law firm, if they think you've all met the standard or full third-party certification where you go all the way in to have a large company certify you. For example, with OpenChain, Pricewater has Cooper or Tootset offer global third-party certification. The idea here is that companies in every sector can do whatever they need to make sure that their OpenChain conformance works for them. Quite frankly, the heart of OpenChain and one of the reasons it's a really cool OpenSource standard is that we have a lot of emphasis on self-certification. We have an online self-certification, a print version of the self-certification where people just get yes-no questions. If they can answer yes to every question, they are OpenChain conformant. Nice, simple, elegant. In practice, we found that works really well. One thing that came up early was people said, hey, if people can self-certify, well, everyone lie. And that has not been the case. The case in the market is actually that when people go through self-certification, they often shoot higher than base requirements quite frequently by a considerable degree. People are very serious about getting this right and doing this best. The type of organizations that are OpenChain conformant, it's eclectic. Here's some example of conformed organizations. There's everything here from British National Health Service organizations to networking companies like Cisco to consumer electronics like Sony through to ethical banks like Yoma Bank and Myanmar. It's a very diverse crowd because OpenSource is everywhere. Everyone has to address OpenSource compliance and everyone finds it easier to do so through a predictable unified global standard. All right. So we got a de facto standard. How do we take it to the next level? Obviously, formal standard. De facto standards work fantastic in practical market deployment and certainly around OpenSource, around software, definitely. But of course, when you're looking at massive global adoption, when you're looking at how do we talk to people who aren't part of the OpenSource community but use OpenSource, how do we help them get compliant? And the answer is you use the mechanisms that these organizations are already familiar with. People who utilize OpenSource but aren't part of the community aren't really part of software community are probably going to be dealing with standards in whatever they are focused on, whether it's banking or defense or whatever. They're used to standards. And absolutely everyone is used to ISO standards. So we said, let's really amp this up from an audience of thousands of companies to tens of thousands of companies to become an ISO standard. This has some advantages. For instance, when you talk with procurement or salespeople, when you talk with process workflow people who are just not technical, not familiar with any of this, they'll all understand an ISO standard number and they'll understand, oh, this fits into our portfolio. It's alongside functional safety, export control, whatever. It's just another ISO standard for when we talk with our suppliers or if we're a sales department and we talk with our customers. Nice, simple, elegant. How do you do that? I mean, how do you go from a de facto standard into a formal standard? How do you actually create an ISO standard? And there's a lot of different answers to that. Of course, there are, it's an old complex field. One way is you can go country by country drafting. You can go through the national bodies and spend about 15 plus months. That takes a lot of resources, a lot of time. And you know that in open source, the idea of spending 50 months standardizing something is daunting because you're looking back and it's like, wow, that's more than four years. A lot has changed. So one of the other ways you can do standardization is to go through various pass tracks to say, hey, this is a de facto standard, it's deployed, it's useful. It should be a formal standard. How do we convert? And again, numerous answers. What we did, what we did is we went through something called a pass process in JTC One. So JTC One is Joint Technical Committee One. It's an important part of the ISO standardization regime. And we decided to go through their process for saying, this is an existing de facto standard, let's convert it into an ISO standard. And that allows you to do it in a much shorter time scale, less than a year. In fact, we submitted in the earlier part of this year and we expect to be an ISO standard in Q3. The balloting around open chain, the voting around open chain will conclude on the 22nd of September. So we found a way to work inside the existing ISO standardization process that provided the time scales and the flexibility to convert de facto standards into ISO standards quickly and effectively. How? Yeah, surprisingly easy and surprisingly cheap. As it turned out, we didn't need specialized knowledge or tens of thousands or hundreds of thousands of dollars to do this. We worked with a preexisting organization, Joint Development Foundation, which entered the Linux Foundation community last year and formally announced their active services with LF and standards about four weeks ago. The Joint Development Foundation is essentially a project which helps open source projects and standardization come together. So they provide the umbrella that deals with all of the corporate legal infrastructure to do standardization. And that means a project like open chain can go to JDF and say, hey, we've got this pre-baked standard. It's been in market three years. We're on revision 2.0. That's been announced since April, 2019. We haven't had drafting comments, large scale suggestions for change. We're just seeing increased market adoption. So this standard is baked. It's ready. How do we go through ISO? And they've provided a tremendously useful path to do that. I'm gonna dig into this briefly now. The overview is simple and the secret sauce, the sausage making, mostly you don't need to worry about the details. They do the heavy lifting. But in a nutshell, when you're standardizing, you do this. You've got your idea. In the case of open chain, we had the idea, let's define the key requirements of a quality open source compliance program. And then initially our idea was, let's make that checklist. And then we thought that's useless. We throw that out. And let's define the process inflection points. So we did that. We drafted the process inflection points. And we said, that works well. We deployed the draft to market in our case. And we saw a really good reaction. We saw some great feedback from 1.0. We iterated quickly 1.1, 1.2 based on market feedback. Then it went stable. People were using a lot. We just refined the language a little for translation purposes 2.0. And the standard was ready. And at that point, we took the standard JDF and they said, okay, you've got your standard. It's drafted. It's complete. It's in market. Now we need an ISO draft. So in open chain, we hired an ISO editor. His name is Rex. He was awesome. I can send your connection points to him. Give him details. And Rex took our standard 12 pages long. And he reformatted it slightly to make sure it fit the ISO format and ISO norms. He didn't change a single requirement. He didn't change any of the nuances on the standard. He just made sure that it was suitable for the ISO process. And then of course, we submitted it. Technically, we submitted it through the ISO IEC, JTC1 transposition process. But for us, what we did is we gave it to Joint Development Foundation and they did the magic in the background. What this means is when you have an open standard based on an open project, it could define code. It could define something like us for talk about processes. It just doesn't matter. You can take that preexisting standard, get an ISO draft of that standard in collaboration with JDF and put that through the process of ISO. And nine months later or so, you end up with an ISO standard. That process in itself, you know, I say, oh, it's easy, you just do that. Open chain was the learning curve on this, okay? So it wasn't as easy for us as it will be for you because since we did it, since we created the setup of open chain, we drafted our defecto standard by setting up our committees, making our records, making our submissions and all of that. Since we've done that over the last three years, other smart people have been busy working on the idea of a spec in a box. How do you create a spec using, let's say, GitHub? And they build it. There's a thing called Community Specification 1.0. It had a soft launch 25 days ago. And basically you fork this GitHub repo and it contains all the documents and approaches and whatnot you need to create a spec that can easily go into something like ISO. So it describes how you set up the regulation, how you set up the committees. Nothing on it here. I mean, it's not even that difficult. But it's a structure. It provides a structure for you to do that. And you can literally just fork this GitHub repo, work through the documents, adjust the documents in your fork to fit what you're doing and hand over to JDF. That's really cool. Now, when it comes to open standards like ours, there's a few important points. So Open Chain is run by user companies or user companies. Our mission is crystal clear. We are the companies with the challenges in compliance, fixing the challenges in compliance. There's no deviation, no confusion, no ambiguity. So you should do the same. I mean, you should clearly know what your project goals are before you make an international standard. Fact is Open Chain, once it's an ISO standard in September, of course we'll draft future versions of Open Chain, but the thing that goes live in September will be the thing that is in market for who knows how long, five years, 10 years, more. So you need to know exactly what you're trying to accomplish and what we did. You need to make sure that people coming into your community can address what you're up to. So we created tons of reference material, multi-languages, case studies, reference processes, reference workflows, reference training slides to make sure that when people arrived, understood our mission and then said, that's great, but how do I do it? They could find a lot of reference material. Actually, our library of reference material is over 400 documents thanks to our global community. I would encourage you, if you're interested in standardization through JDF, Linux Foundation, to jump over to the Open Chain community, see how we're cooking it, especially to see how encouragingly open and not scary it is. So I mean, we're building the international standard, the ISO standard for open source compliance, but we're doing it in a way that people are essentially sharing knowledge, coming as close to having fun as you can when you're dealing with license compliance. And it's a very supportive community where new companies are embraced, supported and lifted into positions where they're confident to become contributors too. You can also mess around with, how does things like self-certification on a standard work? There's our web app to do it, you can have a look, you can take the questions, you can play with it. A lot of people play with it. 50% of companies using it are doing conformance, 50% are doing health checks, but there's another chunk of companies and individuals out there simply messing with it to see how it works. You're super welcome to do that. And as the first ISO standard by a Linux Foundation in 14 years, you can be sure that part of our adjacent mission is to make sure that if you're making a standard, we help you. Now, we're not gonna be alone for long. At the opening keynote of this event, Jim just announced that SPDX, our software bill of materials standard, will be the second ISO standard going through JDF for Linux Foundation. So, yeah, we'll have a couple of months where we're the golden child and then SPDX will be the second one through, their community will be perfectly poised to help you as well. And over time, more Linux Foundation projects will have ISO standards. If you wanna make an ISO standard, contact JDF. The guy running the sanitization side, Seth Mupri is just awesome. He'll be very glad to help you. You can get support there. You can talk about things like the community specification where you can use GitHub to make a standard to convert your existing workflow into something for an ISO standard, the whole deal. It's all there. That's what they do. They just help you. And in a nutshell, that's it. Linux Foundation open source, in general, the whole global set of foundations and communities, we can now take our defective standards and really easily convert them into ISO standards. Of course, we don't want to rethread areas where people already have really cool international standards. No one needs that. But when we have new stuff, when we're filling in the gaps, we have an excellent mechanism to do it effectively, quickly, and without much specialized knowledge or investment. In fact, just to put a dollar sign on it, I paid Rex, I think about $4,000 for the conversion, the support, the back and forth. And that was it. That's how much it cost us to make an international standard apart from some time resources on our end. It's really doable. And I highly recommend that if you have a useful de facto standard, you consider making it an ISO standard to share the benefit from the thousands of companies who are kind of in our open source ecosystem to the tens of thousands of companies out there who could take an improved workflow and really make something of it. That's it. Thank you very much for your time. I am available right now for questions. We've got three minutes, I think. And also you can contact me at this email address and you can catch the OpenChain project with this URL. If you have a question, I think you type it in somewhere on the bottom. And while we're just pending there in case there's a question or two, at this event, this virtual event, we have an OpenChain mini summit tomorrow. It happens at around this time tomorrow. Everyone's welcome to dial in. We'll be talking through the OpenChain standard. We'll be talking through some regional things like what's happening in Europe? What's happening in Asia? Why is it happening? And we will also be, oh, cool. Todd is asking for the URL of the presentation and the URL of the slides. Todd, I will be making these available on the OpenChain project website. So in about 30 minutes, if you go to openchainproject.org, you will find these slides, all right? So you are super welcome to go to the OpenChain website and in 30 minutes, you'll be able to pick up these slides. You'll find it under the news section. Oh, David Wheeler, man, you're a legend to me. Good to have you here. Okay, I love this question. David asks, how do we make sure the standard is available instead of behind a paywall? And that's relevant because for instance, if you download an ISO standard off ISO, you have to pay, I think it's like $120. Okay, short answer. Thanks to companies like Microsoft who've done this before, we are knowledgeable in how to do this and it's super simple. So Microsoft case study. OpenXML format. They put that through ECMA, European Standardization Organization, and from ECMA, it went to ISO. ECMA revision four of OpenXML is functionally identical to the ISO standard. You can download the ECMA revision four for free on the ECMA site or you can download the ISO official publication on the ISO site. One is free, the other's not. It's the same for us. So OpenXML, I'll have our ISO standard on our website available for everyone to download. We're gonna call it OpenXML 2.1. It's functionally identical to the existing 2.0. It's just reformatted and that'll be there for everyone to download and go. They can also obtain it through the official ISO library at a cost which some companies might elect to do because that's how they get their standards. But yeah, you host it on your project website. It's a really cool question and it's super simple. It's really nice that we can just host it on our website and ISO have it in their database. So yeah, it's free, always will be free. Stephen asked, how do we handle the maintenance of ISO standards versus ongoing work in OpenChain? Great question, simple answer. The maintenance is still through OpenChain. What happens is that we will draft future versions of the OpenChain standard and update the ISO standard via JDF. So we just edit as normal and when we call time and say this is a new version of OpenChain, we put that through JDF and they update our ISO standard. Here's what happens with an ISO standard. You have the ISO number. Let's say, I'll just steal functional safety. ISO 26262 colon year. So let's say that we are ISO 1234, when we first release this ISO 1234, it'll be ISO 1234 colon 2020. We do a revision of the standard. It's ISO 1234 colon 2023. And that's how we do the updates and that's how you always know which one is current. We'll make sure to have a map on the website so it's super, super clear. Alrighty. Yeah, so you control the standard, you keep it on your website, you update it at your pace and essentially ISO is the repository, the canonical place where people can check the ISO standard data. Steven asks, does it require a GTC one pass vote each time? My understanding is that we have to go through an update process instead of the full transposition process. So my current understanding is, no it's not a ballot to see if it can be a standard again. It's more of an update process, so it's easier. Alrighty. I think that's all of our questions. So long story short on the questions, you still on the standard, you can put it for free on your website. You still on the standard, you can edit it and update it. Updating the standard is easier than initially submitting it and initially submitting it is pretty easy because Jade, you have to do the heavy lifting. So it's actually a really smooth process for a cheat from easy. Surprisingly, surprisingly easy. I say that because I was on a standardization body for two years in Switzerland and traditional standardization is heavy. All right, thank you so much everyone. Todd, website 30 minutes, you'll have the slides. David, thank you for the excellent question about availability. Steven, thank you for the question about maintenance and for everyone else, thank you for being here. I think we're wrapping up now and we have to hand over to the magic staff, I guess, for turning this off. Okay, so Jennifer sent me a Linux foundation site. There is a slack workspace for this track. So you can kind of jump into the community tech community leadership track on our Slack for this event and that's for the conversation and also keep going if you so wish. All right, thank you very much indeed. Take care everyone and talk to you soon.