 Hi, this is your host of the party on behalf of the Linux Foundation today We have with us once again Katie Stewart VP of dependable embedded systems at the Linux Foundation Kate is great to have you back on the show great to be talking to you again today We're going to talk about spdx up just for our viewers. Tell us. What is it about? So spdx is an acronym that's short for software package data exchange and this is a way of expressing data about metadata about software right now. And the project started about 10 years ago. And so we've been slowly and surely evolving it based on the use cases of what people need to want to share about software. It initially started from the licensing side. And so it's been pretty happy on that. But obviously in the last five years, we've been linking into other applications like security. People want to share information about security about things. And so the specification that came out last year also has recognition recognition for like global identifiers, like the software heritage IDs as well as it's always had for several years now it's had the CPs which are sort of a way of referring to vulnerabilities and then the pearls and so forth. So we're trying to be inclusive of being able to let people understand what the metadata is and then what the relationships are between packages, like what are the dependencies, because if you've got a vulnerability, what you want to be able to do is understand what is the implications of it and oh, hey, I'm depending on this library buried down 20 dependencies deep in this container in this container, you need some way of being able to identify it. So SPTX is a way of summarizing the components and the relationships between them as well as quite frankly, if you need to, the source and what sources form which packages and what snippets are in the packages, in the sources as well. Yeah, if you look at today's modern software development, you mentioned all the security is a big challenge. Compliance is a big challenge. So when we look at it, it becomes more or less like a supply chain or, you know, a kind of bill of materials in content software. So because when companies consume it, most cases, they may not even know what are the components in there. So pulling all the information, what license is being used. So talk about when we do talk about in traditional world or early days, I love to call it when it was proprietary, you just get for one vendor, that's your done. Now you're pulling in for things from so many different sources. So talk about the role that SPTX is playing in helping companies leverage all these open source technologies without having to worry about what goes in what. Like I say, when you ship something, your license terms with someone else, you're assuming responsibility. The challenge is that 90% based on some of the black duck surveys, I think from last year, 90% of products have open source in them. And so you when you're shipping your product are assuming responsibility for what was in that open source. And right now it tends to be an archaeological expedition to try to figure out all these little pieces that one needs to capsulate. So we need to automate. Okay, we've got a lot of things automated. This is the thing that needs to be automated. We need to get this working at scale. And we need to make it accessible so that like anyone in the open source community, when they're summarizing their licensing for their packages, for instance, or for what they're doing can get an accurate picture pretty much quickly or automatically. And that's missing today. So there's a lot, you know, initiatives, they're part of this to try to take it so that we can actually automate these things. One of the projects I'm really quite excited about is, you know, Zephyr has now started to create a not software build materials of this, you know, when they're putting out their release. And we're got some prototypes going on and pull requests and so forth to summarize and when you actually build your binary. Pull in all the pieces you need at down to the file level so you have the accurate licensing, because that's where you're going to look to figure out if you've got vulnerability or not. A lot of people just want to work at the component level, but sometimes the file level is really needed. And so making this all automated and transparent for the upstream open source developers is what we're really trying to go after here. What kind of adoption is there or how organizations, projects are embracing it? How easy it is also for them to just, you know, leverage it for to get the whole stack of what they're running. Like I say, we've got, we've got huge ecosystem and open source and products here. And so we've got to sort of tackle it from multiple ways simultaneously. We've actually had a fair amount of adoption, Intel, ARM, some of the larger silicon vendors have all have been adopting for several years. We've got like, you know, Hitachi, Fujitsu and a variety of other companies in Japan, they've been working with it in their supply chains. We've got, you know, groups who are looking at certain years cases and starting to mandate it as part of their procurement requirements. So that when they get the data, you know, they get the right metadata so that their system can absorb it. So they all have their different ways of implementing it. What we're trying to do in the project is make sure that there's two links to support them ingesting it and, you know, exporting it. And getting that to the thing there, as well as, you know, obviously working with the upstream communities to make sure we have a good solid starting point. Excellent. Now, let's talk about anything new that's going on within the community or with the project. Yeah, there's a lot of new stuff that's going on right now. One of the things that should be coming out later this year is we should actually formally be an ISO specification. We've been working behind the scenes for the last two to one release that came out last year to take it through ISO so that it's easier for the procurement people to specify and adopt. That's work in progress and the balloting has completed now and it's approved from the balloting so it'll be a while, but we should be hopefully seeing an ISO number showing up with SPDX this fall. Another thing that's going on in parallel right now is we are working with some other communities, in particular the OMG community, as it had an initial, observe a parallel effort going on for looking at something called 3T, you know, tool to tool and looking at automation as well. So they can focus on the same problem. So we've been working on getting these two communities to work together in the SPDX framework and then moving it forward from there. So this 3.0 version of the specification, which will be the next version, we're going to be refactoring it to make it easier for, if you don't care about licensing stuff, you don't have to carry the licensing fields. If you don't care about security, you don't have to carry the security fields. So there's a lot of really good active work going on and people are welcome to join in if they've got use cases they want to know how to represent. There's other efforts that are working on creating software build materials or S-bombs. And there's a group working in the NTIA that is trying to make sure that there's awareness of S-bombs growing. And SPDX is recognized as one of the formats in there for being able to represent an S-bomb amongst others. So what we're trying to do, and they're trying really hard not to pick winners, so to speak, but we're trying to make sure that any sort of guidance they come up with we're trying to align with. Okay, thank you so much for talking about SPDX and also this latest release, not really release, but latest development, which is with ISO. Before we wrap this up, just a quick closing thoughts from you. What would this mean for not only community but industry also when it gets the ISO mark there as well? It is more about the confidence or is it about visibility or reach? It's more about visibility and reach. We've gotten the ISO mark now for Open Chain, which says how to use an open source in your organization. And so SPDX is following along on that path. And so that we have, okay, you're supposed to use an S-bomb according to Open Chain. Well, here's an S-bomb format that we know people are using and has been adopted by the industry already. Awesome. Thank you. Pleasure as always.