 Hello there, my name is Shane Coughlin and I am the General Manager of the Open Shane Project here at the Linux Foundation. I'm sorry I couldn't be there in person today. Unfortunately, the global pandemic continues to disrupt international travel. Being based in Japan, this makes it hard to get over there to Seattle. That said, I believe the travel situation is dramatically improving around the world, and I do hope to see a lot of you face to face in November at our Linux Foundation member summit. It's being held in Napa Valley, so we will have some interesting opportunities for all the wine lovers. But back to the topic at hand. Today we're going to talk about Open Shane, ISO standards and the future of compliance. Set context, Open Shane, ISO 5230 is the international standard for open source license compliance. It defines the key requirements of a quality open source license compliance program. It's the only standard of its type. And since its publication by ISO in December 2020, it has become increasingly important and popular around the world. But this standard didn't begin on December 2020. It actually began years earlier. The first idea for Open Shane was around 2015, when a handful of experts in this field got together and said, we really need a way to make the supply chain to open source compliance more effectively. It's a simple concept, but a very important one. And by October 2016, that idea had been polished into a standard. With the initial release of Open Shane back then in 2016. There was a de facto industry standard to help guide what the key requirements of a quality open source compliance program looked like for companies of various types in various markets. The transition between being a de facto standard into being a formal ISO standard is important. As much traction as Open Shane had, and it had significant traction between October 2016 and November 2020. And becoming a formal ISO standard made a new era of supply chain management possible. The reason is simple enough. Many companies ingest ISO standard materials today, many companies manage their processes with ISO standards. It's a simple clear signifier that what is being done meets the requirements and the understanding of parties across the globe. Open Shane's considerable success as a de facto standard contributed to its ability to become an ISO standard. Indeed, by the time we were in ISO standard, our community already numbered in the many hundreds of companies. We had local work groups in local languages in areas like China, Japan, Korea, and we had significant momentum across industries like automotive. But when it comes to a standard, what you're looking at is scaling from hundreds to thousands, tens of thousands of companies. Overall, what you want to do is to create a situation where every company benefits equally and easily from the efficiency and effectiveness of a refined standard simple thoughts. And in our case, I would be modestly say executed with precision and effectiveness. This is an uncontrovertical standard. It is the only standard for open source license compliance it defines processes that are no surprise to any party, but are equally important to the success of those parties. In other words, it solves a problem in a consistent manner where we didn't have a consistent solution before. Open Shane is the first ISO standard to come out of the next foundation in 14 years. Previously, the last standard was Linux standard base. And you can see the enormous gap between what was happening around the time of defining Linux standard base and what's happening today as we release standards like Open Shane. The whole gap is not a gap of peace and quiet or nothing happening quite the opposite. It's a gap of extreme innovation, iteration and massive growth of open source. Indeed, nowadays, everywhere you have software, you have open source. This is fast moving. This is fast evolving. And many aspects of this are not perfectly suited to standardization, because they change frequently. And when you have a standard, particularly a formal standard. One of the things you're doing is providing consistently in whatever that is. You don't want to iterate standards continue. You want the standards to be some of these scaffolding upon which people build. Open Shane is an ideal part of scaffolding. It is a foundational element to how you approach efficient software management. You need to manage licenses, you need to manage ingest and outbound, you need to manage internal processes, highlighting where we know things are most effectively done, saves time, and it saves a lot of money. It's controversial indeed. And also an indicator of what's to come. You see Open Shane fills a gap in the market based on maturity. We're at the stage where open source as an idea is well accepted open source code as deployed is everywhere. And now we're looking at how do we tighten things up to make them better. We always want to do things more effectively. And standards, of course, help with that. I'll give you an example with Open Shane and bear with me. This will involve a few different numbers and letters in a slightly soupy manner. The alphabet soup is because of the way standards work. But the overall point is simple and clear. Open Shane is ISO 5230. That's the identification number for Open Shane in ISO. And this means that any company can tell another company, please use Open Shane, or do you use Open Shane, or how do you use Open Shane. You phrase it by saying, how do you use ISO 5230 in the same way that they would phrase other questions, like in quality process management, ISO 9001 or 14001, or functional safety, ISO 26262. We often communicate these standard numbers to each other in sales and procurement and in other negotiations as a shorthand for double checking where people are aligned with the industry and where they're not. And it gets more nuanced to standards don't exist in a vacuum. They fit together like jigsaw puzzles and where there's a gap where we're missing something new standards emerge. The reason that Open Shane exists is because there was a gap in the market for open source license compliance process management. Open Shane has filled that gap. And now it's slotting in with lots of other standards around the place. I mentioned quality standards like ISO 9001 and ISO 14001. I mentioned functional safety ISO 26262. The reason I mentioned these standards isn't arbitrarily, it's because you're likely to find all of them in a package when people are negotiating their procurement, because they want to see what quality management is in place. They want to see what functional safety is in place. They want to see what open source compliance is in place. So they check if you're meeting the international standards or you're doing something unique. It's very easy to understand and accept international standards. But if someone's doing something unique you probably have to ask more questions to make sure it's adequate for your needs. And as it is that things interlock and connect. Open chain I mentioned earlier is popular in industries like automotive. We talk about open chain and automotive. Again, we're stacking standards. Open chain is building an area that was blank previously. And in doing so, it can be part of a list of standards as discussed, or it can be part of something else. For example, in automotive you've got third party certifiers like Goofsoot. These are organizations that go to your company. Check how you're doing things. And then issue a certificate saying that, yes, they certify that you're doing things in a manner appropriate for the market. Certifiers like that use open chain. And of course, open chain is an ISO standard 5230. But those certifiers are giving a general certification. Let's say Toofsoot, their particular certification is all open source process management, not just compliance, but other aspects like development process management and so on. So they slot the open chain ISO standard into an umbrella, which they mark as a Toofsoot standard. In fact, their standard including open chain is called PPS, PPP 150001A. It rolls off the tongue. The actual simple fact is that this certifier packages a bunch of known standards together, plus some additional material where they find gaps and create a new meta standard. In this case, TPS means Toyota production system. But Goofsoot have focused on a meta standard for open source that fits into the Toyota production system frequently used around the automotive industry. As you see, I warned you, we'd have some alphabet soup, but it is important to contextualize how all of this works. The same thing happens in a car company. Let's take Scania. Scania is based in Sweden. You probably know that they're very famous for trucks. Now, Scania has created a corporate standard, a Scania corporate standard, and the standard is STD 4589. And it includes ISO 5230 open chain as part of a sequence of standards that they're asking their suppliers to utilize wherever possible. The point of the Scania corporate standard is to provide one corporate standard to suppliers and then inside that corporate standard, a list of all the included or bundled standards from places like ISO. Right, take a breath. No more alphabet soup for a few minutes. The point there was that ISO standards and process management standards internal to various companies and process management standards external to various certifiers all fit together to interlock. And what's very useful in this space, of course, is that the formal standards out there are available. And rather than anything ambiguous happening, let's say, only using de facto standards, you can use stuff that's been true the crucible of ISO. And that matters. And like I said, open source increasingly having standards, which slot into all of this perfectly is an indication of maturity. And while it might sound like we're introducing complexity, we're actually introducing methodology to align more perfectly with how people doing procurement with how people doing standardization work today. And that is of course, one of the most important goals, you can have in the technology industry by not having to re educate people by not reinventing the wheel. By doing things working smoothly. And goodness knows, after the last 18 months of supply chain disruptions. We can see why we don't want to shake the boats on the supply chain. We want to fit in neatly and effectively. What does this mean for open source license compliance going forward. Well, open chain is there. It defines the key requirements of quality open source license compliance program. It defines the basis and the gold standard of how you approach this problem space. So that's problem solved with the proviso being over the next years, it's going to be all about adoption across the market. And that's fine. That's exactly what we expect to do. That's exactly what we've prepared for, and that's exactly what we're executing against. But open chain isn't going to be alone. The joint development foundation helped open chain become an ISO stand joint development foundation is a fascinating initiative. It's now part of the Linux foundation family in that it's a project in our ecosystem. The joint development foundation is what's called a past submitter and forgive me. I know this is beginning to introduce more acronyms. It is quote, a publicly available specification and quote submitter. It's an organization that can take a de facto standard in the industry and take it into formal standardization via ISO. In other words, that's exactly what open chain did. We explained our status as a popular de facto standard, and we worked with them to enter the ISO process and grow through a certain fast track to graduate within nine months. A de facto standard that's mature and de facto standard that's widely adopted. It's not something that needs reedited. It's something that needs conversion or transposition into a formal standard. And that's what it's there for. That's what the process is there for. That's what JDF is there for. Open chain led the charge, as you could say, the first test balloon in this space, where an ideal for a standard uncontroversial mature, lauded by a lot of companies and perfectly positioned to become an ISO standard to improve our positioning across procurement sales and negotiation, but we're not the only standard. You may be aware of SPDX software bill of materials. It's a project under Linux foundation that has been running for around 10 years. Now, SPDX has done a fantastic job of dealing with software identifiers in a consistent manner. For example, do you want to analyze the software see the name package version number license and so on, and be able to transmit it in a manner that other people can utilize manually or automated in XML, JSON or other formats? Well, then SPDX is useful for you. Now, SPDX entered the transposition process in ISO. It entered into the process of becoming a formal standard shortly after open chain, and it has just graduated. It is now ISO 5962. So, directly after open chain, which is open source license compliance process management and ISO standard for software bill of materials. These are sister standards. To use open chain, you don't have to use SPDX. To use SPDX, you don't have to use open chain. But if you're using process management and want a software bill of materials, they fit together perfectly. And that's where we're going in the future. We are going to do on a broad scale, what I mentioned earlier, where there are blank spaces, where there are the facto standards where there should be formal standards. We're going to gradually create those where there are simply gaps in guidance and interlinking topics. We're going to create those. And most of all, perhaps most importantly, inside Linux foundation inside JDF. No one is going to reinvent the wheel. Our goal is that beautiful interlocking industry with no surprises. The not invented here syndrome isn't even on the table. It's quite the opposite. What we want is no gaps in this market space. So we have open source license compliance process management. We have software bill of materials and currently a lot of our energy is being spent on really cool things like use case. Open chain rather surprisingly has been utilized in multiple areas outside of open source license compliance. It's being used for security, export control, merger and acquisitions, even venture capital. Now those usages are not a concern. Those usages do not change the standard. But those usages are exciting and they are different and in some cases they are unexpected. For example, utilizing open chain for security makes absolute sense. Open chain is all about the process inflection points where you identify software and you have a plan about what to do next. You identify inbound, internal and outbound software. You have covered most of the basis for most of the security issues you need to think about. And that's why we are used in that context. Now naturally we don't want to re-edit open chain, create a new version tomorrow that's called open chain security edition plus. That would confuse the market. But what we do instead is we create some security guidance documentation that says here's open chain, the open source license compliance standard, and here's how you can apply it if you wish in the security domain. By the same token, we're working on material for export control, merger and acquisitions and VC. These are really cool filling in the gaps exercises that are market responsive. In other words, where the market's doing something, we try to support it by providing knowledge that will allow new participants to do the same thing with the same fidelity as those who blaze the trail. And that probably indicates a lot of what's going to be happening in 2022 and 2023. Open source license compliance doesn't need a bunch of needs standards. At this juncture, we seem to have the primary basis covered. Open source license compliance does need a lot of additional guidance documentation. Not that we've been slacking on such documentation. Indeed, the open chain project has a library consisting of over 1000 documents, case studies, examples and other materials. But the market needs more because it's a huge market. In open source license compliance, you can expect around open chain and SPDX additional materials to help interlock with other standards and other domains more effectively. You can expect our knowledge and our experience to feed into other areas. What I personally don't expect a compliance related standard in the near future. I do suspect we may see the emergence of other standards related to process management around open source. For example, and this is not indicating that something's being cooked right now that I have special awareness of, but for example, process approaches to develop. There's a lot of stuff out there that's very interesting covered by case studies covered by guidance document and some of it may be mature enough to explore standardization as well. Maybe pausing here catching our breath. One of the things that we should do, the main thing we should do is consider that open source is mature. We have solved most of the problems. There's very little that's unknown in our space now. And where we have solved the problem consistently, reliably for a long period. There's something right for detailed case studies and or possible standardization. This applies in every part of open source from coding through to whatever. In the past, open source specifically didn't really produce so many standards, and where it did those standards were defective. Now that's very understandable on a rapidly moving code situation, but with open source in all types of domains and open source management being very mature. That's changing as well. So standardization formal standardization should not be something of concern, or something ignored by the open source community. It's something that should be embraced where appropriate. And that's why we are so fortunate to have had the experience of open chain to have the experience of SPDX and have the larger guidance of joint development foundation. I hesitate to say that open source license compliance is now a solved problem. I'll say it's a mostly solved problem, and our two ISO standards raised all the boats in the field places in a perfect position, and we're executing along that. The joint development foundation is well enabled to do the same to many other domains around open source. For example, what about the facto standards describing methodologies of doing stuff like 3D modeling. What about process management in completely different areas to compliance. This is where we have lots of thinking and lots of exciting stuff to do. And this is why, if you're in those domains if you have something that's the facto standard and look solid and is reliable and is essentially done. For me, with my team at the open chain project. Well, life is a lot of case studies, life is a lot of user groups, and life is a lot of spreading the growth of our ISO standard. Working with our sister standards, and of course working with people elsewhere with other standards other domains other organizations and so on. I think you're going to see anything dramatically exciting around open source license compliance and standardization in the next 12 months. And that's a good thing. You should be executing along the lines of open chain ISO 5230 as the gold standard. And if you're using software bill of materials, you should put serious time into looking at ISO 5962 as pdx. You should look at automation. You should look at how you can deal with interoperability between your internal activities your suppliers proprietary vendors and so on. And in doing so you should look at us open chain is running our largest ever case study rolling between September and December this year on automation and interoperability. Our community is running frequent meetings discussing these topics in local and global manners, and working together, you, me, everyone around us. We're doing that mission of raising all the boats and we're getting it done in a way I think that is pretty much optimally effective. Well everyone, there you have it. The open source license compliance has seen increased standardization. The standardization has focused on the areas where we most needed clarity and consistency process management and software bill of materials. This is work that will aid us for many years to come. Around this work case studies examples user groups to work directly with each other, all of that is happening, and all of that is available to you. So please come on by open source license compliance is not going to see a burst of standards. It doesn't need to. We probably have most of the basis covered and certainly for the next few years, as we expand outwards, what we're mainly doing is interlocking with other aspects of the market and other standards. That said, what we've done here, what we've pioneered will impact other areas of the open source ecosystem. We now have a clear mechanism for de facto standards to become formal standards. We have a clear friend and ally and joint development foundation to do the heavy lifting for us. And all of that is tremendously exciting. More broadly across the market. I mentioned before to have said, and their TPS PPP 15001 a standard utilizing open chain and other standards together. I mentioned Scania with their STD 4589 standard which utilizes open chain SPD accent other standards together. That type of bundling, not just in Linux foundation, but in the user companies in the certifiers will be happening around the world to, and instead of being overwhelmed by alphabet soup. Look at it this way. Your standardization people will understand this stuff in a moment, and that's their job. Your job is to do awesome work around open source, and to keep your mind open to the fact that there are aspects of our community which have been de facto, which now belong in the formal standardization space. And by the same token, there are aspects in our community best addressed in other matters like case studies and examples. We supported every step of the way with understanding and delineating this and executing according to that. Thank you very much for your time. I do hope that you can be part of the open chain community if you are not already and lend us some of your ideas for how we build the future together.