 So my name is Shane Coughlin and I'm the general manager of the OpenChain project. Today I'm going to talk to you about how OpenChain, as a specification, became the international standard for open source compliance. This talk will be a little bit different to some of the other talks in this event. I'm not going to use slides, instead I'm going to talk to you directly about how we started, what we did, and what is coming next. First of all, the idea of having an industry standard for open source compliance came about through a discussion at an event just like this, but of course a physical event. Some people working in the field of open source who deal with matters in legal areas talked about how compliance activity was done company by company, yet all of the companies were probably using essentially the same type of approach, perhaps even exactly the same type of process and training material. The obvious question was, what if we standardized our approach? What if we could find a way to describe the processes that encapsulated all of the important points and allowed not just us in this room having this conversation, but everyone to approach compliance in a systemic effective way? A simple idea, and an idea that gained traction quite quickly. By October 2016, a conversation had turned into a specification describing the key requirements of a quality open source compliance program. This remarkable accomplishment was not done in a trivial or easy manner, nor was it done in a theoretical manner. It was wholly focused on the very practical matter of what do we need to do to bring products and services to market in an effective way that ensures in the best possible manner we adhere to the requirements of each and every license we're using. Open source licenses fall into various categories and of course they have different requirements, but there are common approaches to process management that allow us to adhere to the requirements of any open source license. The key is to have the structure in place to allow identification and adherence to the requirement of various licenses located in open source software. Being too prescriptive about any one point, let's say about any one license, would perhaps hinder the ability of an organization to deal with other licenses. Likewise, being too prescriptive in the precise nature of each process would naturally only fit the market segment and company size of those who determine it. The key was to find the common overarching processes, the inflection points, the points for a process should exist to help ensure effective open source compliance. Made very simple. Everyone should have inbound, internal and outbound processes to identify, understand and adhere to the licenses applicable to the open source software being used. By putting processes at these appropriate points, you can identify the terms that apply, what your suppliers are giving you, what your developers are doing and what you are passing on to your customers. An overarching gulf of making this definition of identifying those processes and describing them clearly in a manner that is suitable for companies of all sizes in all markets. The overarching goal was to build trust so that companies in complex supply chains could have increased trust in each other regarding open source compliance and this trust would be entirely practical. The likelihood of a supplier providing code that was in compliant with the appropriate open source licenses dramatically reduced. The likelihood of deploying to your customers while failing to adhere to the appropriate open source licenses dramatically decreased. And most importantly in some ways, the ability at any stage to stop, look at code and feel confident that you are doing the right thing in the right way. So we went to market in October 2016, a standard which was both simple and comprehensive. It is easy to read and easy to understand and adaptable, a truly open standard. Open Chain was created by hundreds of voices. It went to market and got feedback and evolved. Six months later, the first evolution, version 1.1, tidying up language to make it easier to understand and adjusting slightly terms based on feedback from new markets and new participants. Six months after that, exactly the same, another update incorporating real world feedback to make this standard easier to use and more effective for more companies in more markets. In April 2019, version 2 of the standard came to market. Version 2 was an interesting development. International communities had grown around the Open Chain project and the Open Chain standard and they provided a wealth of feedback on many topics, perhaps most importantly the topic of translatability based, of course, on ease of understanding. That informed many adjustments to the language to ensure that non-native English speakers could understand the specification and, of course, could translate it as a reference for their peers in their geography. Also important, Open Chain 2 included so much more feedback from companies in very different markets that it was, how shall I put it, more suitable for a truly global audience than anything that had come before. Now Open Chain 2.0 in market April 2019 increased in popularity quite quickly. Local communities in areas such as Japan, Korea, China grew at a rapid pace as peers invited peers to join the mailing lists, the calls, the face-to-face meetings when we still had them. The growing community showed us something very important. Our real-world standard for real-world compliance was working. People were able to use it effectively across multiple markets with a great deal of confidence. As this understanding was internalized, we began to consider an important point for the long-term future and mass adoption of the standard. Open Chain was a de facto standard, something that was created by companies for use by companies and adopted in a practical manner across the world. But of course, as well as de facto standards, there are what are termed formal standards. Organizations such as ISO create formal standards or approve formal standards in a manner that, well, gives an understanding that goes beyond a series of peers. An ISO standard can be understood as a standard and as something to use to understand, to even contribute to, by companies from any sector whatsoever, whether they are a company making food or jet planes or a company drilling oil. If they're thinking about open-source software management, it's so much easier to engage with a formal standard, an ISO standard, than with a de facto standard. The reason is really mental modeling. Companies in sectors who are not familiar with software per se and not familiar with open source per se, have greater confidence in formal standards and of course already have workflows for addressing and applying formal standards. For us, as a project, it was a simple decision to move towards formal standardization to ensure that the maximum number of companies around the world could benefit from our work and, just as importantly, could provide information, reference material and ideas to make open-source compliance even better. So, as we worked on this, as we collaborated with our own community, we came to work with the Joint Development Foundation. The Joint Development Foundation is designed to help projects which work on specifications, such as Open Chain, become more involved in formal standardization. They provide support and they provide a methodology of submitting de facto standards into an approval process. If you can think of standardization as being an area where people draft and then approve standards, it's also worth considering that there are mechanisms for existing standards to become formal standards and that's exactly what we wanted, what we needed and what Joint Development Foundation could help us do. As an existing standard, a de facto standard used widely in the industry, there's a mechanism called the ISO, IEC, JTC1, pass transposition process. I know that's quite a mouthful, but of course in standardization, as with law, the wording is important and we have to be accurate. Put simply, there was a methodology through JTC1, Joint Technical Committee 1, for existing de facto standards to be approved as formal standards. We entered that approval process in April 2020, one year after the launch of Open Chain 2.0. The document we sent into the ISO, IEC, JTC1, pass transposition process was essentially Open Chain 2.0, but of course with some of the formatting adjusted to fit in with the formal ISO style. We were very thankful to work both with a great editor who has experienced in the ISO process and also would pass mentors from JTC1. They provided the feedback and the support through Joint Development Foundation that we needed. Our submission went into the transposition process, which included several stages. The first stage was translation, so that various country committees around the world could review our standard and vote whether to approve it or not. Then we moved on to the ballot process, the actual voting process. This voting process provided a mechanism to approve or decline the existing standard. And it also provided a mechanism for providing comments, both for our education and for their education, a mechanism for two-way feedback, not connected to the approval vote, but adjacent to it. Standardization, above anything else, is about communication, to ensure clarity and to build collaboration. Those comments were part of that and provide a great foundation for future work, but I digress. The ballot process for our submission was successful. The voting concluded very recently and the vote was approved. Open Chain is now an international standard, a formal international standard. Indeed, as I record this, we are simply pending the publication of our standard. There is a six-week period after the vote, upon which ISO must publish a standard. And we're now two weeks into that. So within less than a month, we will be formally published as an ISO, IEC, JTC1 standard. At that point, we will have our ISO number. Prior to that, of course, you can check in the database, we are DIS5230 in the database. That was the draft international standard number used during the translation and ballot process. Long story short, our work started with a conversation. It built out from there. It built out through about 18 months of work among peers of exactly the people who use the standards to get things done. And that resulted in October 2016 in the release of the first standard for open source compliance. This standard quickly gained traction. It quickly built out across the world. And in April of this year, we were at the position, the understanding that our community had grown large enough. Many hundreds of companies, thousands of people. Battle proven, market ready, something that really did work and we knew for sure. And we could move with confidence into the formal standardization process. Now, if you're a project with a specification and thinking about international standardization, becoming a formal standard, some of the things I just told you could seem daunting. How do you work with an ISO committee? How do you actually prepare a submission? If you want to turn a draft standard into a standard, do you use the past transposition process? If you want to turn an existing de facto industry standard into a formal standard, how do you get help? Let me explain. If you were just drafting a standard, then that is an interesting moment where you have the choice to either complete drafting the standard and build it up as an industry standard or to enter into things like national standardization committees and receive their help and support in drafting. If you have a pre-existing industry standard, such as Open Chain, what you probably want to do is to explore converting that into a formal standard, in which case you want something like the ISO, IEC, JTC-1 past transposition process. Whatever you need to do, whatever option, don't worry, you're far from alone. The organization that can and will help you is Joint Development Foundation. You can find it at jointdevelopmentfoundation.org. They help a great deal in contextualizing what you're doing and what is appropriate in the standardization world. The people there know standards inside out. Seth Newberry, who's leading the effort, is a remarkable collaborator, endlessly patient, endlessly helpful, and perfectly positioned to guide you through the paperwork, the process, and of course, the politics of standardization. In fact, and if I was to give you one major message from this talk, it's that standardization, if you're working on a genuine, useful standard, and you collaborate with something like Joint Development Foundation, standardization is utterly painless. It's actually something you can do effectively without interrupting your ability to manage your community, without interrupting your ability to evolve the standard on your own. In essence, for quite a low cost in time resources, you can take an enormous step forward to broaden your audience. For Open Chain, I like to say that we are at the cusp of broadening our audience from hundreds of companies around the world to thousands. As an ISO, IEC, JTC1 standard, we are going to be super easy for people to use. For example, sales people can utilize it in their market to explain to customer companies that they do have the key requirements of a quality open source compliance program, and they adhere to the international standard for that. For customer companies, the ISO, IEC, JTC1 standard for open source compliance provides tremendous utility in purchasing discussions and actual procurement. When you're doing that, of course, you already ask for various standards to be used, quality standards, functional safety, export control, security. Our standard for open source compliance simply slots neatly into the pre-existing methodology used by these companies in sales and procurement. It enhances their work, it improves their clarity, it reduces the chance of errors, and of course, it reduces the amount of resource cost of dealing with open source compliance. Open source compliance is no longer something you have to do on your own. It's no longer something you have to contextualize on your own. It is something that is clearly understood, clearly defined, and entirely available to all parties. Now, the next thing I want to talk about is how does this work for a project with a specification like OpenChain? What happens after you get published as an ISO, IEC, JTC1 standard? Well, this is an interesting answer. Pretty much nothing changes. OpenChain will continue to develop our standard through the existing mechanisms and committees that we have in place. Our community will continue their work based on the practical methods we know have been effective. We are going to continue our meetings, our webinars, the publication of our reference material just as before. And indeed, you can access all of the material necessary to understand and use the standard for free on our website. Now, if you're familiar with ISO, IEC, JTC1 standards, you'll know that if you go to their website, you have to pay to download the standard. And, of course, our standard on the website will be exactly the same as anyone else, but we will host a document functionally identical on our website that will be freely accessible just as before. Anyone can self-certify. They can get independent compliance assessment or full third-party certification just as before. Our existing infrastructure, such as our self-certification web app, which is tremendously popular, our self-certification downloadable checklist also popular, our enormous library of reference material, exactly as it was. Though, to be honest, the reference material is always changing, we update it constantly and the corpus is growing dramatically. Our reference library has over 400 documents today. With the increased interest after our formal standardization effort, I expect that to bloom. Let me pause there. Reference library for a standard, what does that mean? Now, I mentioned at the very beginning, OpenChain defines process inflection points and it's flexible enough for companies of all sizes in all markets. That means that it says put a process here and it doesn't actually tell you in detail what that process should be per se. For instance, it says identify the software that is coming into your company. And you may ask, how do I do that? How do I do it manually? How do I do it automated? How do I do it for a small company? How do I do it for a big company? That's where the reference library comes in. We're not prescriptive about how you fill the processes out, but our vibrant community of user companies has provided a wealth of material to explain how to do precisely that. You can get reference material provided by companies of dramatically different sizes in dramatically different markets that tells you what to do if you want to. For example, a policy template that allows small or large companies to build out of blocks a policy appropriate for their youths. Training slides that contextualize some of the key points in open source training and allow people the flexibility to go where they want with that. And of course, any documents that might be guides for suppliers, for example, for sales of procurement, checklists for utilizing specific licenses all the way through to case studies and other material. Like I said, over 400 documents and growing rapidly. Let's sum it up. Let's come to the end here. Open Chain, the project created a specification. This specification grew to be the industry standard for open source compliance. Let's be very, very specific. The open chain specification grew to be the industry standard for open source license compliance. It identifies the key requirements of a quality open source compliance program. In doing so, it allows companies to trust each other more in the supply chain while reducing the amount of resources, reducing the amount of risk, reducing the amount of error that might occur otherwise. This standard is freely available. The material and mechanisms necessary to self-certify are freely available. There is a vibrant user community with local groups all over the world. Again, freely available. We have centralized activity and global work groups. We have bi-weekly webinars, bi-weekly tooling meetings, bi-weekly specification meetings, all types of avenues to engage, ask questions and contribute. We also have a partner network where various types of vendor organization like law firms or service providers or servifiers or tooling companies who happen to know Open Chain well and have taken the time to engage with and contribute to our community act as official partners to provide their various services. This vast user community has the solution for effective open source compliance. It was codified and battle tested and now it is graduating as a formal ISO, IUC, JTC1 standard. The process would have been daunting on our own, quite frankly, but it was not daunting. It was made possible by Joint Development Foundation because they helped us transition from de facto to formal standard. It is a tremendous leap to move from an industry standard to an international standard. We now have the ability to talk to every company in the world, to become part of every process that involves transactions of software from one legal entity to another in a manner that is perfectly compatible with what people expect. That is something new. Open source compliance is defined and standardized for the first time. Working with Joint Development Foundation allowed us to become a formal standard and the process in practice, painless, remarkable. If you have a project which has a specification, if you are a de facto standard, I highly recommend reaching out to Joint Development Foundation. If you're thinking about making a standard, if you're drafting, likewise, reach out to this organization dedicated to helping us with precisely these things and learn from them. And of course, you're welcome to learn from us. Open Chain is delighted to share its story. It's delighted to share the practicalities of what we did. Just bounce over to openchainproject.org. Join a meeting, join a call, send an email, and we'll be right there for you. Thank you for listening to the story of how Open Chain became a formal international standard. I hope it was educational, and I'm looking forward to working with you, maybe on conformance to the standard and maybe helping you with your standard. Find out more, openchainproject.org. Thank you for your time.