 I think we're going to do a quick round of introductions just so we're aware of who's in the room. My name is Rose Judge. I work at VMware. I'm on the SPDX steering committee, and I've been working on the SPDX security profile. My name is Adolfo Garcia. I am a software engineer with Gengar, and I'm a contributor to SPDX. I also maintain a bunch of other SPLM tools. Awesome. Hi, I'm Brandon. I'm a software engineer at Google. I help maintain the Golang tools, SPDX library, as well as help with the build profile. And also, along with Adolfo, also helping build some tools around SBOMS and ecosystem. Hi, I'm Karen Bennett. I'm representing IEEE, but I also work in building AI models for the last six years for self-driving cars. Hello, I'm Tom Seller, software engineer at the BBC on Smart TV apps. Here to learn about SPDX. Hey there. David Buckhurst also from the BBC. So I guess me and Tom are the closest to an Ospo that we have. So yeah, but we're looking to sort of give that more emphasis. So yeah, really interested in this. Good morning all. I'm Steve Cobain. I'm not at the BBC. I work for Analog Devices. I'm mainly involved in Open Chain, and I'm here just to learn much more about SPDX and SPDX3 in general. Hi, my name is Jordi, and I'm the SPDX marketing manager. So happy to elevate everyone's voice from the ecosystem that is contributing or just want to learn more about SPDX. Hi, my name is Soin Kim. I'm an Ospo in LG Electronics, and I have many interested in SPDX. Hello, I'm Jeff Shapiro. I'm with Linux Foundation, and I do lots and lots of license scanning. Hi, my name is Aaron Reffett. I'm at Carnegie Mellon University. I'm primarily with the federal government, and I'm just interested whether or not I spawn this way. Crazy right now. So I'm learning about the tooling ecosystem to help them do their jobs better. Hi, I'm Denver Gingrich, Director of Compliance at Software Freedom Conservancy, and I'm curious to see how SPDX can help with compliance, and especially to see how we can make sure that some of the other parts of the cobbled licenses can be upheld through some of the work SPDX is doing. So, collaboration there. Thanks. Good morning. I'm a material solo. I'm part of the reproducible builds community, especially working with producers in Debian. I'm here to learn more about SPDX and how it's evolving, and if we can do something together, maybe, possibly. Hello, my name is Mark Geese. I'm with WinRiver Systems. I'm head of the open source program office, and I've been using SPDX since 2012. We've been delivering, I guess, bombs to our customers since then, and I'm always interested in seeing how it's evolving. Hello, I'm Tom Medford from Bloomberg, and I've apparently been nominated by a bunch of people who can raise their hands, who are also from Bloomberg. We are part of a group that help with our supply chain efforts, internally looking to how we can leverage SPDX more and also contribute back. Hello, I'm Kevin Connor. I was with Red Hat. I'm now unfortunately unemployed, so I'm here as an independent. I've done a fair bit of work with Cycling DX and S-Bombs. I'm now here to learn about SPDX and strengthen my knowledge of that, so thanks very much. I'm also from here in Vancouver. I just live on the North Shore, so I enjoy the scenery every day. Yeah, that would be great. Hi, everybody. I'm Vinit Agir. I'm Sam. I'm Chandan. Hi, I'm Akshay. Lisa. I also work at Bloomberg. Hi, I'm Nisha. I work for Oracle. I have been a contributor to SPDX for a while now and also maintainer with Rose and Adolfo and Fredham. Nice to meet you. I am Norio Kobota. I am also staff in Sony Group Corporation and I'm participating in Open Change Japan Working Group and contributed to SPDX Lite or next... Sorry, I forgot. Usage profile. Usage profile to SPDX version 3.0. Nice to meet you. Good morning, everyone. I'm Takashi Nijioji from Tsushima. I'm the head of the open source program office. I'm also working with SPDX, SPDX Lite from the Open Change Japan Work Groups. So I'm really happy to join this discussion. Thank you. Hi. Hi, my name is Daisuke Morishita from Japan. I am working for a company named Hitachi Solutions and I'm working for open source management. Thank you. My name is Tomasakashi. I'm a software developer in Hitachi Solutions and I usually go working at Morishita. And I publish it for SPDX. Thank you. Hi, everyone. My name is Ayumi Watanabe. I'm working for Hitachi Solutions Japan and I am an IT consultant and who is helping Japanese companies to use and understand open source compliance and open source management and especially for SPDX. So thank you very much. Nice to meet you, everyone. Hi, my name is Dan. I'm an open source maintainer and developer in a number of different projects and we've just recently implemented the SPDX source code tags on one of our projects with some outside prompting so I'm here to learn a little bit more about what we can do to help downstream users. Hi, my name is Alex Wright. I'm with the United States Air Force and I'm here to learn about the next upcoming standard of SPDX and furthering our SPOM efforts. Thank you very much. I'm Kate Stewart and I've been pretty much with SPDX since the start of it and so we're here to sort of talk about what's coming down the pipe and get your input and hopefully help get the tools. So with that, I'll move it over to Rose. Okay, so just a quick agenda so you all know what to expect. Kate's going to give us an SPDX 3.0 overview and then Steve and Jeff are going to give us an overview of the license compliance use cases with SPDX 3.0. Adolfo and I are going to go over security use cases for SPDX 3.0 and then Karen and Gopi or maybe just Karen, I'm not sure are going to go over how to utilize SPDX for AI use cases. Brandon, maybe Nisha too. Okay, are going to cover the build profile for us and then Gary who is arriving shortly is going to wrap it all up by kind of summarizing the differences between 2.x and 3.0. At 10.30 we're going to have a group photo and then we'll let discussion follow after that so possible discussion topics are the transition paths for tools and if you have any questions, concerns, comments, please bring those up and we'd love to discuss those. So I'm going to turn it over to Kate. Yeah, thanks. And if people have a... Oops, thanks. And if people have topics that they want to see, please write them down. Also we're trying to collect so those who are watching this remotely, we have a Gitter room and if you want to basically put your questions in the Gitter room, someone here will be keeping an eye, probably me, will be keeping an eye on it and then I'll raise them on your behalf so that we can have a little bit of interactivity. Not a lot but at least a little bit and so like I say, there is the app, Gitter in and then the lobby. Hopefully you can catch that. We'll bring it back up again later. So with that, talking about 3.0 and where we're going with it. So why are we doing 3.0? Well, there's been a lot of interest in using SPDX for non-licensing scenarios. That being said, we want to make sure we are coherent and stay true to being able to support all the licensing scenarios. But getting the security and some of the needs for safety critical systems available to be represented was one of the motivators. Also, we're seeing a tremendous surge in AI. In fact, we started working on this over a year ago, if not longer, and on data sets and how we can get the transparency for those. Because similarly, as you compile and build an application, you're creating your trained models and the information there could have vulnerabilities, could have licensing issues. All of these things at SPDX is good at representing. So we want to be able to extend the model for that. And there was efforts going on doing work on SBOMs at the OMG SISC efforts. And so, I guess about two years ago, we combined forces with them to make sure what we were coming up with was going to work for both communities. So not yet another SBOM, we actually tried to very adjust on the SPDX side as well as on the OMG side, so we had something that would work for both groups. The OMG SISC efforts were very much focused on data lakes and moving so that they could represent the information in a data lake and query it. And so this is part of the main direction we've been going for. And then, you know, there's a lot of... The other piece of critique we've heard through the years is, oh, it's too complicated. I don't want to carry the licensing information. I just want the straight S-BOM stuff. I just want a component and I think, well, you could do that today. However, making it very simple to see was part of it. So making that the minimum, easy to just basically access and use was a motivator here on what we've been working on and then being able to include the profiles you care about, like licensing, like security, like the AI and ML, the assets build usage. These are scenarios that people have brought to us, use cases people have brought to us that we're trying to basically make sure we can support. So just to give you guys a bit of a history, we've been around for quite a while, as you can see. One of the big transitions was between 1.2 and 2.0. So we've gone through a breaking change before as a community. And there we basically went to enable an arbitrary hierarchy and the documents and so forth. And so that was one of those shifts. So some of the things that we've learned from that lesson we're trying to make sure we apply this time around as we're going into 3.0. We basically added the SPDX Lite, again, thinking that people just wanted to have the minimum set at one point in time. That got added in and then we took that to ISO. So SPDX is an international standard and has been recognized as such and has gone through the extra level of scrutiny to make sure we could actually do that. We will be taking the 3.0 work after it matures a bit in the field, back to ISO as well. But we have to basically, because there's so many new use cases, so much thing we want a little bit of experience to make sure we've got it right. We have 3.0 or 3.1 we take to it, but we want to do a little bit of bake-in in practice with the tools and everything else before we go. However, we will be releasing the 3.0 spec center this year. The 3.0 model release candidate is out now as of last weekend. So if you want to get a feel for what's happening with SPDX, now that you can look at that model and understand the classes, the properties, the vocabulary, it's how this is all fitting together. And so just to sort of talk a bit about it, literally we went from a 1.2 where it was just one package per document effectively to allowing multiple packages per document and having an arbitrary hierarchy. That was a significant change for us at the time. You know, other systems that are out there right now for S-bombs are sort of talking in this type of mode. And in terms of like one package per thing, it's only one thing in there, it's just the dependencies. And so we learned from our communities that we needed to be able to have multiple scenarios. We also initially had a Google Docs effectively, and Word Docs was how we wrote our spec initially. And then we would generate a model underneath from that. We moved out over to being in Markdown, up on GitHub, so we had much more closer tracking of it. And so that happened in the 2.2 release, I think, actually. And then from that is what we went to ISO with, with the 2.2.1. Oops, let me go back. And now we're here in the 3.0 with that release candidate model. And we are working towards the next step right now is we're going to be serializing it and getting serializations out from the model so that people can sort of see the files and so forth. There's a lot of examples right now already in play and there'll be more showing up. And then the specification will be available. So before we used to do the specification, then put the model, we've changed the order right now. We're having the model out there and then the specification will be generated in a more readable fashion. So at this point in time, it's very much oriented towards tools, people working on tools, because these schemas will be there and you should be able to build from that. And then eventually we'll try to go for ISO submission after we get that. But that's the flow we're aiming towards right now. So the specification, as you say, is being transformed. It used to be straight text. It's now being in Markdown and we're also having the classes, properties, and enumerations of vocabularies. The metadata is there for each element and will be basically automatically generating schemas now. So there's a preliminary JSON schema sitting there and we've been working on the Python tools as we've been sort of finalizing this stuff. So there will be a Python library out there for people to play with in the next week or two, at least to start playing with anyhow. And then we'll be adding more of the formats generation after that. And it's these profiles. The way to work with them is if you care about them, you indicate you want to use it. And there are certain things that are mandatory and things that are optional and those properties are available to you. All the properties that are in SPDX are available to you, but there are certain ones that the schemas would automatically check if you've indicated you want to be following a profile. And so there's a link to the model and that's what we want to focus people at and focus people at making things more interesting. Issues and pull requests right now are very much welcome as we try to get this hardened. So just to sort of, you know, what we sort of did is we found, with the 2x we found the Fulmermo model, really helped us enable the transition between formats or using the same thing. That's why we're doing the model approach. And with 3.0, we're basically looking at having the same sort of thing between the formats, but we're adding in support for data lakes and addition S-bombs documents and formats. So there's different types of S-bombs that are included here. So some of you may have seen that CISA published, that CISA of the U.S. published this set of types of S-bombs, which is where the type of information is available. The licensing people historically have focused mostly on the source S-bombs. The security people have focused on the... Sorry about that, just getting over cold. Security people have focused mostly on the build S-bombs. So if you have security people talking about S-bombs, they're usually thinking build. If you have licensing people in OSPOS thinking S-bombs, they're mostly talking source. And so we needed a way of basically separating these use cases out. And so there was an industry group that got together. CISA helped conven us and we worked Smiths for six months on these definitions. And so we've got some degree of consensus and all the people who have signed off on these definitions are a pretty wide swath of the industry. So you can go to that link at the bottom in the slides or just go into CISA S-bombs site and then you'll find the reference to this. It came out on the 21st of last month, along with the VEX document too, which I'm sure Adolfo will reference at some point. But build and source are really what's out there today. Design is going to be really useful for safety and requirements catching, things like that. There's work going on there. Deploy it once you've actually configured something and putting on a system recording it and understanding what you've put on a system and recording it as it's in progress. Now, each of these types of S-bombs can refer back to others in there. Okay, I think that's important to understand. An S-bomb isn't just one and everything. We learned that lesson before. And we've got various clean mechanisms for linking from one type of S-bomb to another type of S-bomb to refer to the information. So you can generate the information where it is locally. And these most are around life cycle. However, historically, someone may take a... I've got this binary. I want to try to understand what's in it. You may need an analyzed one. But we see this merging pretty much through the ecosystem. So I just want you to be aware of this because you'll start to see people talking about it. And it sort of maps pretty well to a software life cycle in that your design is happening when you're doing your planning. Your source S-bombs usually are happening on procurement and development. Your build S-bombs or your build tests and release, that's when they're generated. Because that's where the information is, at the heart of it. That's where you actually have facts as opposed to guesses. And the more times in this ecosystem we can record facts rather than guesses, the more we're going to be able to trust these documents to be useful in the system. And then, okay, hey, you've got your release. You've got your release. Oh, you've just given it to a customer. Hey, they're going to deploy it. Well, record how they were going to deploy it. That's effectively a deployed S-bomb. We don't see a lot of that today. I think we're going to see more and more of that. And certainly from the safety side, we're going to need it. And then, oh, hey, I've got this system. It's been changing out from underneath me over time. I want to look and see what's actually showing up. So this guy maybe called an instrumented S-bomb or something like that. But it's a way of summarizing what is actually running on a system and being able to compare it to what you think it should be running on the system with the deployed. So a deployed S-bomb could refer, actually a runtime S-bomb could refer to a couple of deployed. The deployed S-bomb could refer to a build. The build could refer to the source. And the design could basically be pointing at all of them. So there's going to be some interesting new use cases being shown up by this. But this is a pretty powerful mechanism and it will represent these safety use cases we're trying to aim for.