Implementing OpenChain across endjin's InnerSource and Open Source estate
Linux Foundation Webinar
Charlotte Gayton was invited by the OpenChain Project, an initiative of the Linux Foundation, to present a webinar about her 2 year journey with OpenChain.
The webinar has two parts; the first is an overview of her industrial placement at endjin implementing the OpenChain ISO/IEC 5230 specification - the international standard for open source license compliance programs - across endjin's InnerSource and Open Source estate.
The second focuses on her final year project on the OpenChain ISO/IEC 18974 specification - the industry standard for open source security assurance programs, building on the extensions to endjin's DevOps processes and tooling used to implement ISO/IEC 5230.
The slides from the presentation are available below:
You can also read Charlotte's final year dissertation:
You can read more about Charlotte's journey with OpenChain in her blog series - What is OpenChain (ISO 5230)?
Transcript
Shane Coughlan: Here we are at another OpenChain webinar. Today's webinar is a little bit special for a couple of reasons. The first one is that we are going to be covering two topics. One is a case study around ISO 5230, the International Standard for Open Source License Compliance. The second part of this webinar is going to be talking about research around ISO 18974, the International Standard for Open Source Security Assurance. It's unusual for us to cover two topics like this. But we do have a rather unique reason, which brings me to overall the other very exciting part of this webinar.
Our presenter today, Charlotte Gayton, is someone who has worked in the industry as part of an industrial placement at endjin, but has also been doing research at university. So this is the first time we're going to have a recent graduate present to us about research and practical business matters. Charlotte. This is motivated by a couple of different things. One is to cover the area of academic research. That's something that we have only looked at in, I think, two out of our 90 plus webinars. The other is to hear the voice of rising next generation. It's time to give the floor to people who are looking at open source and open source business and open source standard with a fresh eye.
Before we start, as always, I'm showing the antitrust policy notice. The full antitrust policy can be found on the Linux Foundation website. If you're from a Linux Foundation member company, you can ask questions of our counsel, Andrew Updegrove. The purpose is to ensure that everyone feels comfortable sharing, talking, and collaborating.
Now, without further ado, then, and to ensure that my background noise. Is reduced. I will stop here and hand over to Charlotte for her presentation. As always, this is an open chain webinar. So you should feel free to jump in with questions if you have any, and we will have some space at the end of this call to collect questions if you want to wait until the end. Charlotte, thank you for coming here today. I'll stop my share and over to you and look forward to your topics.
Background
Charlotte Gayton: Okay, thank you. I thought I'd start with an introduction about me. I'm a recent Computer Science graduate from the University of York. I hadn't done Computer Science before starting University, so it was definitely a big learning curve, and I was very much thrown into the deep end, learning lots of different concepts. So I first joined endjin for my internship in 2021, and we were set with a project to generate synthetic data that could, represent the normal population for testing scenarios. It was a really great data project to get thrown into for my first real application of programming, and seeing what you can actually do with it. And then that led me to come back for a year in industry with endjin a year later as part of my university degree. And that was a year-long project where I worked on OpenChain ISO 5230 license compliance. And that was Brilliant project. It looked at all the different aspects that start right from the beginning of the project from discovering what it is to actually implement it, and seeing the results first hand.
Which then led me on to my final year dissertation when I reached my final year of University, who allowed me to continue my work with endjin as an industry partner. I worked on the second strain of OpenChain, the the security assurance side. There was a lot of research about what that meant, and best ways to approach this problem in context to endjin. Which I will this talk will cover. A little bit of background about me; I've just moved to Cambridge and I'm starting at Darktrace in September. I'll be joining the Research and Development team for Software as a Service security. So I'm really excited to get into that and start applying my knowledge. So also a little background about endjin they're a boutique consultancy with expertise in Data, Analytics, AI & Cloud Native App Dev, with expertise in Azure, Microsoft Fabric, Azure Synapse Analytics and .NET as well.
Understanding Open Source Software and OpenChain
And I've already mentioned this, but I joined in 2021 and then returned in 2022. Endjin maintain over 60 open source projects, which is pretty key for this talk. Starting off with the license compliance; initially when I started this project, I didn't even know what Open Source Software was. So it was definitely a learning curve of understanding what is OpenChain? Why is this a standard? And to get to that, I had to learn about everything about the Open Source ecosystem. So having not really used open source software before or written it or had much experience with it it was getting to understand why these this compliance is important and why, yeah, why is this standard important? Why is it important for endjin? I took a couple of courses to get good background knowledge of the subject.
I took Source Code Control's course Get It Right With Open Source Software. Thank you to Martin Callinan and Holly Wyld for giving me access to that. And that was a really good course which gave me an overall background understanding open source software and licensing. I also took the Introduction to Open Source License Compliance Management course by the Linux Foundation, which was also very good. This allowed me to gain an overall understanding of open source software, licensing, compliance, and best practices.
So starting out and just, understanding what this was all about. The next step was to understand endjin's DevOps & CodeOps architecture as this is going to be different from company to company. No company is going to be the same in the way that they implement these processes, because endjin have a very specific architecture. The next step was to look at that and decide what would be best for them. In the end, we decided to focus on GitHub and use GitHub Actions, Azure to integrate into their existing CI/CD processes. You'll see more about this in a second.
Implementing OpenChain ISO/IEC 5230
So this is endjin's open chain operating model, and thank you James Dawson for creating this for me. So it outlines the different Processes that are designed for throughout this project. So you can see the vulnerability analysis in here as well, which. I will talk about further on, but you can see the, which parts are in certain boxes CI/CD, that's where we generate the SBOMs (Software Bill Of Materials) and look at the license compliance and the vulnerability analysis. And then at the end here, these are outputs, like what we're going to do with this information which I'll look into this a bit later. A bit later. So talk about our SBOMs because they're a pretty important part of compliance because they represent your system as a whole. It was very important for us to get these obviously, because you can see all the licenses that you're using for each component. Endjin generate their SBOMs with a tool called Covenant by Patrik Svensson. It's beneficial for them because Covenant supports .NET and NPM, and they can also add a custom format with additional metadata at the top, so it will also have the GitHub organization, repo name, git branch, and then git commit. So these were generated as part of endjin's DevOps / CI/CD processes and every night they will be generated again and stored into The Cloud. That's SBOMs, so after these SBOMs are generated, there's two different ways that we use them.
It's to make this a fully automated process and to ensure that licenses that aren't meant to be used, are caught in time or discovered. We're thinking, if someone makes a change to the code and they add a add a component that has a license or dependency, and that has a license that we don't want to use, we want that to be caught before it's actually merged into the main code and the changes are actually made to the software. This is the CI/CD section, part of the implementation. And it's part of the GitHub Actions process. So whenever there's a change or PR that's created an SBOM will be generated and will be checked. And then it can block the PRs if there are changes that would result in a rejected license being used. It tries to catch them before they actually become a problem. And then there's also another strain where it's the bulk run. You couldn't get all of the SBOMs for the whole estate in a single repository. You need to analyze every single component at the same time to see the whole. Because this is quite a lot of data processing and data analysis this is all done in "The Cloud" in Microsoft Azure, making use of the parallelization in Azure Synapse Analytics.
So, you can have then an overall view of the system. You can gain an overall understanding of the licenses being used and what are not being used. It's more of an overview, whereas the first one it's specific to each repository. And for this, I wrote a general script called "SBOM Analyzer", which can be used in both the CI/CD and the bulk run processes. It's designed to be used both in pure Python and PySpark, so you can still make use of the parallelization. The SBOM Analyzer is designed to extract the information from each SBOM and then produce meaningful results from it. It will extract the licenses and copyright notices alongside the components and then check it against business logic, and scores are generated, which are a representation of how many accepted licenses there are, how many licenses are there that were not accepted, and then there's another column for "unknown" because There were some components that didn't have a license registered, or the copyright notice wasn't clear. In terms of the business logic, there were lots of discussions around what makes a license accepted or rejected. Which licenses are endjin happy to use and which ones would they like to avoid. Creating this policy was quite a key part of the process because we're really deciding what is going to be okay and what is not going to be okay.
Examples of accepted licenses we have allowed are MIT and Apache 2. 0, because they're generally permissive licenses and ones that should be fine to use, and some rejected licenses, like the GPL license, because they're copyleft. So any licenses that aren't recognized or have a copyright notice would be flagged as unknown, which would require someone to manually check what's going on. And there are also some special cases because obviously endjin produce their own open source software, and will use it as well, so some of their licenses are ones that they generally wouldn't accept from a different company or a different developer, but for themselves it's alright for them to use. There's an additional check to check for the the SBOMs that they were coming from, the repository names to check. If it was made by them or not, and if it was, then they could still use that license, even though generally it's not one that they would accept. So there was certain special cases like these that we needed to consider because we didn't want to just flag up everything that endjin have developed and then end up with lots of problems further down the line.
These scores are produced after the SBOM Analyzer has been applied to the repositories, or just the singular repository. And after this, the rejected licenses can be reviewed and removed from the system. At the beginning there could be quite a lot to remove, but as more get caught in the CI/CD processes before they merge into the code, it will become more autonomous and there won't be as many that will need to be removed in the bulk review.
The scores include the number of accepted or rejected licenses. Now we're at the final stage of the process of using this information. So We've generated all of these SBOMs and we've analysed the information within them, but now what are we going to do to actually make sure that this information is used in an appropriate way, and a way that will be beneficial for endjin, and a way that they will actually catch these errors? At the moment there are currently two places where they're being used. In Slack and Backstage, which I will talk more about. For Slack there's a daily message that gets generated, which is produced after the SBOM Analyzer is run. It's just a simple script that can do that, and it will give a summary depending on the amount of licenses that are rejected or accepted. So you can see here that there's some ticks, which is great because there's no rejected components. However, In the chance that there are rejected components, it's very obviously different. If someone were to check it and it was red, then they would know that there's something wrong and there's something to check. So we make sure to design this very clear so that you know If it's going right or wrong, you don't have to specifically look at the individual numbers to work it out. And this is just one way that you could be alerted. It's the first port of call.
If you see this and there's errors, then you might want to go onto Backstage, which is Spotify's open source framework for building developer portals. You can build your own development site, and it has all the information that you need on it. This site, we designed it to access the scores from the Azure Data Lake where, after they're bulk run and generated, they get stored. It's always easily updated, and Ready to go, and it displays the information so it's easy to see the results. So you have, if you look at this particular repository here, you can see how many are accepted, licenses there are, any unknown, and any rejected, and then below it will actually list the specific information for if there are rejected ones or the unknown ones.
So you can see here it hasn't registered a license or a copyright notice for this component. That will be listed as unknown. And then there's another tab, which is just an overall view of all of the repositories. So you can have a general guide as to what's happening across the whole system. Endjin also have developed a framework called The IP Maturity Matrix and it it measures the Engineering Practices quality of a repository. For example, how much is documented or how much code is covered by testing. So we decided to add our SBOM score so that it can increase the confidence in the code, knowing that repository is being checked. So in this instance here we designed it so that 100 percent means that the repository is generating an SBOM and is being checked, and then 0 percent means that an SBOM isn't being generated. I think we're also going to add another one as well, that could show. What percentage of the licenses were all right or not? I'm not sure if we ever got around to that. But yeah, that's, it's also great because you can see this on each individual repository. So this is just a screenshot from GitHub and you can see the state of the repository.
So from endjin's perspective why is all of this beneficial? They maintain over 60 open source repositories, so having an up to date view of the software supply chain has been reassuring. You know exactly what's in it, and exactly what you're using. So implementing these processes, it doesn't have to be big or scary. I started and I knew nothing about Open Source Software, but it's just important to figure out what the requirements for the your company are. And then you can understand what's important from that. So endjin use DevOp practices everywhere. So for them, it's important to integrate it into those low level processes, so it runs by default and people don't need to worry about whether they have to make sure this license, or have to manually check this before merging. It will all be automated and people won't need to worry about checking things. So yeah, in DevOps terms, it's all about the "pit of quality". So it's set up just to happen rather than needing to be switched on. So then, it's also important to start small, and it's really to build on what you have from feedback that you start to get.
I think at first we just started generating SBOMs and saw what information we got, and decided how that could be useful, and what information we'd actually want to extract from that. It's important as a consultancy because now they can see supply chain considerations forming part of commercial terms. It's positive to see these effects feeding back into these sorts of conversations. That's just from endjin's perspective why this is good and yeah, the overall benefits of it.
Implementing OpenChain ISO/IEC 18974
I'll move on to the second strand of OpenChain, which was focusing on my dissertation. I returned back to uni after my year in industry and I, started my final year project. So this one, I was looking at the this, the newest strain of OpenChain, the security assurance one. It's A year long project and contributes to a third of my final year grade. I was supported by both my supervisor Dr Konstantinos Barmpis and endjin. I had lots of input and lots of support throughout this process. My dissertation I came in with the focus of threading together the processes that endjin can easily use in their existing system. The aim was to simply just track the components that endjin are using and detect any vulnerabilities. Now, it doesn't seem like a lot of work at the moment, because they're already tracking their components. So the next step is just to detect any vulnerabilities. And due to the nature of the projects, because it had to be self-contained, I couldn't cover all the components of the specification. But I focused mainly on vulnerability detection.
That leads me on to this diagram, which is a representation of how my system was formed and how it works so starting the process here with the input data, from the data lake storage the SBOMs will be fetched, and these will need to be flattened and then cleansed.
I'll talk about the the vulnerability scanner first, because as part of my dissertation, I wanted to create this myself. I thought it'd be a really cool project to go off and extract data from these vulnerability databases and compare against components. However, there are so many tools out there that already do this and my supervisor said, "No, that would be a waste of time. Don't recreate something that already exists". And it makes sense. It would have been a cool project, but it makes sense. So I did quite a bit of research on all of the different tools out there. I'm sure some of you know there's quite a lot of ones you have to pay for, but then there's also some open source ones out there that are free to use. And I'll discuss which one I chose a bit later on and why. But these vulnerability scanners need a specific format of SBOM, which as I discussed earlier, endjin have a custom format. Luckily Covenant, the tool that we use, has a built in converter that you could just easily convert them to well known format, I used SPDX for this project. I flattened the data and then cleansed it. That's part of the cleansing is transforming them from their custom format and then becoming the SPDX. And then they can be scanned and then vulnerability reports are generated. And then we get into analyzing the vulnerability data.
This is where the information is extracted, and then reports are generated, so we get a summary report, and then a refined vulnerability report as well. I will show you this later on, I've got some screenshots as to what each of these are. And then the results get published to Data lake, it would be in the same place that endjin stores. The other strain of OpenChain's results as well. For my actual implementation, it wasn't because mine was self contained, but I designed it in a way that it would be easy to, lift up and then drop into endjin system. And then this information would therefore then be added to the backstage site as well. And then I was going to add a screenshot of this, but I couldn't find one, but I will find one. So the vulnerability detector I chose was Trivy. It can scan repositories, container images, communities, and virtual machine images. However, we already had SBOMs, and endjin were already using SBOMs, so it made sense just to give it an SBOM.
And it it consumes security advisories from multiple different data sources. Which is key. It's what I was looking for as part of my research. I determined that, you can't just have one source. You have to have multiple sources. I looked more into depth about CVEs and all the different processes that come along with vulnerabilities now, the first tool that I chose for this process, I think called Bomber it was a good tool, however, it didn't give the version fix. It identified the vulnerabilities, but it didn't tell you which versions the next version that would fix this issue was, which is a pretty key point of this. Specification is to make sure that you are actually making these changes. And because we were designing this system to be almost fully autonomous, we want these fixed versions to be generated.
Some more research, I came across Trivy and, that's what we're using at the moment. And it's also a lot quicker. I think it pulls all the information first and then compares the components rather than having to Continuously fetched information, which makes it a lot quicker. So more on the implementation side I think I've already talked about quite a lot of this already, actually. This is my my GitHub actions workflow. This is where I strung all these processes together, demonstrated getting the SBOMs and cleansing them, scanning them, producing these results, all through a GitHub Actions workflow. So this is a diagram explaining the different steps along that and how the information feeds from one part to another. And then there are also quite a few functional and non functional requirements for this project, which is something that's very key in software engineering is, defining these requirements, especially because I treated endjin as if they were like a customer or someone I was creating their software for.
So you need to understand what do they want and what are they looking for? If I just produce this in a way that I thought was cool, that's not exactly what they want. So it's really important to have these functional and non functional requirements. And I actually found that over the stretch of the project these changed dramatically as I discovered new things, and as I did more research and in the end I came out with a robust list, but there were even more even after I finished that I discovered and run out of time to do. But it's an ever changing list of requirements. I took three just as a example to show you. Generate a report with Patch number recommendations, and then whether I fulfilled it or not. So I think I did manage to fill most of the requirements of this project. Which is very good. And these are just some screenshots from my GitHub Actions workflow that I was just talking about. It shows each step of the process.
So you've got the vulnerability scanner and then you analyze the data and you publish results to the data lake. And I wanted to have these separate from one another because they use very different tools. So it's easier for debugging and overall easier to understand and track, and then the results outputted here as an asset. So as a release, which contains assets, I release them both in CSV and JSON format, depending, so it can be used in different ways. But I will show you, so this is the vulnerability report, just not refined or filtered at all. You can see there's a ton of information on here. it's probably not that useful when you really want to know, what's the vulnerability? What's the severity of this? And how can we fix it? A lot of this isn't going to be useful. So then I'll come back to that one actually. Then I had this summary report. I think this is like a refined vulnerability report. Maybe I've got the wrong name there. But it has a lot of simple information. It's just got the name of the SBOM, the severity of The vulnerability the installed version and then which version it needs to be fixed. The name of the component that has this vulnerability, and then how much of a change is it going to be to update? So this was quite a big thing as to automating if it's. A patch is fine, update it, but if it's a major change like this one, then that's going to need some manual intervention to check that it works with the current system, it won't break anything but patches should be fine, for example, so this is all logic that can Be used later on when endjin implement this into their own processes.
And then for ease of checking things I also separated the org name and the repo name out from one another. Going back, there's this one as well, which is just a very simple summarized version of the report. And this can be used for the backstage site and for Slack messages as well. So it just, it contains hardly any information, but it gives an overall view of the system as a whole. So it's very easy to understand what's going on. So then I thought I'd just, I'll just Pop this back on just to show you the different things that I just talked about and how these are the reports that I've just shown and then these will get added to the data they can then subsequently into the Backstage site. And then, I've just got some relevant links that might be useful if you wanted to go have a look more in detail at anything else.
But that's it from me. Any questions?
Questions & Answers
Shane Coughlan: Thank you very much indeed, Charlotte. Before questions might come in, just an observation That was a really great case study.
It was really interesting to hear how endjin implemented these things. And I think it might be the most detail we've gone into on the practical how to, which is both impressive in terms of endjin and your work, of course, but also impressive in the information that we'll provide people as part of our reference library here in the webinars.
Now, the floor is open questions and I'll get it started with one. Your research continuing into ISO 18974 seems like a natural continuity and it's of course very useful for us to have that adjacent to your original work. My question is that Did you find the commonalities between the standards meant that the research into how they work, how they could be implemented indicated that if someone uses one, it's relatively easy to use the other, which was an assumption we had, but it's a question to you to see how that played out based on your experience.
Charlotte Gayton: Yeah absolutely. I think so. Like I spoke about earlier endjin were already generating SBOMs and they were already it was a very similar process as in, there wasn't a lot to do around the setup of all of it. It was very much, okay, this is just an extra piece of information that we want to use and, More insight that we want to gain from the SBOMs. And I think actually the language of the specification as well for the security assurance one was very similar to the license compliance one. So it was easy to understand that the motivation was the same and the reason for doing it was the same, but it's just slightly different information that you want to, gain insight into.
Shane Coughlan: Now we have a question in from Steve and it is, it sounds like you're using SBOM as the canonical representation of the information and as the medium of exchange in different parts of the system rather than, for example, ingesting the SBOM contents into a local database. Is that correct? Is SBOM the source of truth here, as opposed to a local database? And he has a follow up about choosing Slack and Backstage. Is that because they're already deployed in the organization?
Charlotte Gayton: So the SBOM is the representation of the system. So within a certain time-frame, I think, a new one's generated every night. And that information is after all of these SBOMs are generated, which each represent the current state of the repository in the cloud, they are processed and then saved as a database in a way so that you can see every single repository against the information that's generated from it. And this is All in the cloud. So everything's updated and saved. I think we also saved the history of the SBOMs as well. So if there's anything we want to go back and check, we're able to do that. I hope that answered your question. That respect. And then choosing Slack and Backstage.So endjin heavily use Slack for communication. So it was very much the obvious choice. Cause everyone looks at Slack regularly. So definitely that was one that was already used. And Backstage as well. I think I'm not sure how regularly, but endjin, definitely we're already using it. I guess that's the point is you, it's very important to use some technologies that you do already use because you're more likely to use them in the future going on, and you're more likely to see the content and you know it works.
Shane Coughlan: That's actually a really good point. One thing that has come up many times over the years is the question of to what extent do I need to introduce new infrastructure or change infrastructure? And the answer is yes. A recommendation, as little as possible. If things can fit into existing processes, that's fantastic. And to start with, that mental model seems sensible. So it's really heartening to hear that was the case as well.
We have a comment in from Howard, just in reply to Steve as well. Howard was just saying we have CodeOps processes. The processes for managing DevOps it's a little bit meta. Given the CodeOps processes, we wanted something that could integrate into this, so we could scale it out across our IP estate.The SBOM gives us a dependency graph of all components. The reason we needed a custom format is because we wanted to capture more information than the specifications supported. So like code branch names and so on. The reason we used an Azure Synapses, Data Lake, were that these were skills Charlotte developed in her internship. The work we've done subsequently is to containerize all of this logic so you can run it inside a GitHub action and decide where you want the SBOM data or files to be written. So Howard's note there explains some detail and also flags. I think an interesting fact that the work in Endjin has continued to refine on this. Regarding Slack and backstage, also building on Charlotte's comment, Howard notes echoes that endjin wanted to integrate into existing processes that the team already uses to reduce friction for adopting. So that's really good. We've had a very productive presentation here and there's, I think, time for one more question.
Oh, An earthquake is about to hit me. Sorry for that noise. That's interesting. Apparently now. Okay. While the earthquake is hitting there's time for one more question if people have it. And I did notice a comment from Howard. We do want to open source the work that's been done so others can benefit.
But there's a few more things to do to decouple it. Howard, that's really good news. And it's something we've seen in the past. For instance, LG Electronics open sourced their internal compliance tooling. It's called Fosslight. But it took them a considerable time to get that ready.
Any last questions?
Jari Koivisto: May I?
Shane Coughlan: Yeah. I'm going to be hit by the earthquake in 9. 3 seconds. So I'll go on mute.
Jari Koivisto: Good luck. This could be a bit larger question, but like I don't know, Charlotte, if you can talk a little bit more like the compliance let's say clearance site and the business logic, how that was done, because I'm thinking that, okay, there could be a component with some copy left license. But how it's used in a application, for example, the usage could be okay. Like how this clearance was done or was it done at your work?
Charlotte Gayton: We predefined generally which licenses we'd be all right with using and not. And obviously you will come across more licenses that you haven't predefined because you can't go through every single license and determine whether you like it or not. And so those would be flagged up as like an unknown one and require someone manually to decide. But we also didn't want to Just generally across the whole system, lock ourselves into deciding yes or no for every single repository. MIT, just the first one that came to my head, might be fine for one repository, but for another, it might not.
So I think we, we wanted to design it in a way that we could specify different permissions for different repositories. We had a company level Permissions form in a way, and then the way endjin's code is organizes, then into organizations and then repositories. So there was this hierarchy of permissions, so that if a repository had specific permissions, then that would overwrite the the company ones. I hope that made sense. But so it's you can then define for each repository which ones specifically you would want to use or not use as well. But you don't have to do it for each repository.
Jari Koivisto: Because what I have seen in the past was that for example, there can be, let's say corner cases, maybe that, okay, this is strong copy of component, but it's used that way and it's, it runs in on red and it's not directly accessed, et cetera, et cetera. Then the usage could be okay. So there's exceptions that you could have deny list. this license is on denialist, but when used that way, it's okay. But I don't know if those are handled one by one, or were you able to do some automation there as well? Cause that could be interesting because more and more open source is used. And I think more and more, we will be seeing these cases that, okay, this is, I don't know, strong copy left, but when used that way. In this environment, it's okay still.
Charlotte Gayton: Yeah. Yeah. similar to I was saying before as in endjin wants to be able to use endjin's own software. That's Exception case that we wanted to be able to define. So I think the way that we did it, we looked at the repository name or the organization name and flagged that as an organization that would be fine using. So I guess you would have to do that bit. Manually, but then it would automatically flag up if you applied it to each repository or as a company wide rule.
Jari Koivisto: And then, you do it once and that's okay for next whatever release or round or however it was done, like CI/CD round.
Charlotte Gayton: Absolutely.
Shane Coughlan: I saw some comments from Howard in the chat. We have some components that are released under AGPL, but it's essentially dual license. And that's why we needed to be able to say, we don't want to take a dependency on this external AGPL, but this is endjin, x component, which we publish as AGPL, it's okay for us to consume as we are the copyright holders.
So the whole point is being able to apply business rules what you need to be able to do to layer on the complexities. And the key guiding thing, the key point in the end is to figure out how to manage risk. Now, Stephen had a note that the IP maturity index is a really interesting concept and it would be useful if it was adopted more widely across the industry. He asked, can we be told a little bit more about how that's calculated because the SBOM working group in OpenChain are looking at quality metrics and Howard replied just on firstly a note about automation, that if we can manage 80 percent of stuff automatically, that's great, because we have bandwidth now to focus on the 20 percent that needs human intervention or is nuanced.
Going back to the IP Maturity Model he notes that it's really useful for endjin because we want to encourage internal people to adopt open source components that endjin has created and we need to be able to have an easy way for people to assess how mature the code is and whether they should take a bet on it.
This is really exciting. Howard has shared some links about this on GitHub. So there's the maturity matrix from endjin on GitHub, and then there's the rules and definitions. And these links are in the chat transcript. So what I'll try to do is extract those later and put them beside the recording of this call.
I noticed that Steven Pollard is saying many thanks for that, and Steve Kilbane is just noting that this stuff is really useful for inner source as well. Howard it's fantastic that the IP maturity matrix and the rules and definitions are public and open source themselves. That is a really significant community contribution that we will echo and share with people in detail.
That's great. Really nice. Okay we're, I think, at a really good point where we can say this is one of our most information dense and super practical webinars yet. So I'll be publishing the recording either the end of this week or the beginning of next week, and it will be promoted on our social media and so on.
We'll be probably repeating it quite a few times in the next few months. We're going to be pushing on social media in August, September, and through to the Open Compliance Summit in the October in Japan. So hopefully, if you're listening to this recording sometime in the next three months, we managed to get it to you, and you're someone new, and if you're one of our More regular community I'm glad you're listening in as well. We would love for you to give feedback on the kind of process learning here, have a look at the maturity matrix, and perhaps contribute to our education work group with some of the learnings and inspiration from this call. Steve Howard. Stephen, all sending congratulations to Charlotte, and also saying that endjin has some nice blog posts on other topics, so head over to their website, it'll be linked on the page of this recording, and I'll just say, Charlotte you're a really good presenter, and the work you've done has been truly useful.
I'm looking forward to having you back and seeing what you're doing next. Have a beautiful day, everyone, and thank you for being here. Ooh, I nearly forgot to say, the earthquake was fine, not heavy here, but I think Kagoshima and Miyazaki have got 4.6, and there's a tsunami warning, so they're having a rough day.
Thank you all, have a beautiful day, and thank you, Howard, as well, for ending and saying that we can ping you with any questions. Bye bye, all.
Charlotte Gayton: Thank you. Bye.