 Do we have any, yeah. Do you guys share the same test unit tests? Oh boy, I gotta thank Max for the unit tests? Yeah, because I think that would be a very good thing if you're using exactly the same data to test it because then if you know that both tools are very Java or Python are exactly the same. Yeah, actually, I've gotten a lot of value from having them be different because we find different issues but being able to compare the output between the two, Max's team actually had written a whole testing suite before they even started writing the Java code. So the short answer is yes. That's been developed. I can't take credit for it, I think. Max, did you want to add? No, I just wanted to let you know that you're not standing in front of the microphone. Okay. All right. Yeah, good point though. Yeah, yes, yes. Contribute, yeah. Contribute to the, okay, okay. So, I'm sorry, Kate. Why don't you, why don't you just. I can do that. Yeah, the comment or the statement to make is that there is the SPDX Testbed Project which is where you can add your tool or your two suite and challenge it against some test cases if it is compliant and if it can accomplish them and that also helps to get the tools in sync and that they are on an equal level of quality. Max, is that in the SPDX Git repository? It's in the SPDX org as SPDX Testbed. So, you guys can check that out and if you find any issues with it, it's open source and welcome to contributions. So, great. So, actually Rose, did you want to open that up just to general questions first? Yeah. You're just going to open it up to general questions that you have for the presentation and then we are going to talk more about kind of the tooling landscape, some of the gaps there. We're really looking to get feedback as to what you all need as tooling implementers as users to move forward with 3.0. So, what are some of the biggest blockers? What are you struggling with? What are you looking forward to? We're looking to collect that information and these are discussion prompts. If reading any of this sparks curiosity, feel free to speak up. Just make sure that you speak into the microphone so that the live stream people can also hear. Yeah. Okay, first question is when will we have a final 3.0 spec? I'm kicking that too hard. Sorry for the question. Oh, that's not fair. This is my least favorite question. Yes, I know. Because I can't give you a good answer on that. What I can tell you is that we're pretty close to the release candidate two. We've already done release candidate one, which basically is a release of the model. And the intention behind release candidate one, which actually was released what, two or three months ago? I think it's two or three months ago, was that the specification is stable enough for tools developers to start working with it and try out the implementation. As you heard, the Python libraries have been updated with the prototype. I've been doing some Java work on the prototype and I'd be very interested to hear if any of you have tried doing SPDX3 as well and your experience. Now what's happened is, this is a very long answer, I'm sorry. I know. What's happened is we've learned a lot through this implementation and we found some issues with the model that kind of prevented us from being able to move forward until we solved those issues. So I have a call at 6 o'clock tonight to try to close on, I think, one of the last three remaining issues that we have, big issues that we have open and then we'll be ready for release candidate two. So I'm thinking, I'm going to go out a limit and say two to three weeks we should have release candidate two out there. Well, release candidate two will have, first of all, it's going to fix the problems we found in release candidate one, most important. And it's going to be a serialization specification for one of the serializations we support. It'll be JSON-LD. If you're not familiar with JSON-LD, it looks a lot like JSON, but it has linked data. So if you're an RDF geek, like me, it'll look kind of familiar as well because you can easily convert it to RDF. The reason we picked JSON-LD is it is one of the harder formats to support because it requires not just the syntactical JSON information, but the semantic information about what these things really mean. So we picked the hardest one first because the other ones should be easy. So we'll have that spec out there, hopefully in two to three weeks. We'll get that out there, get feedback based on the model and the serialization and who knows, hopefully within two or three months. I don't know. I can't give you a good answer beyond that because it depends on what we find in the release candidate two. Thank you. Yes. Just making the point that the more people come in and help us test the faster it's going to be released. I'll also say that that's where we find the most amount of bugs is when we're actually trying to write code and implement these solutions. So basically in the next Linux Foundation we'll send you up next year? Before then. Don't give him a mic for that question. I just want to know what feedback you've had on the 3.0 from people from different companies. Any positive things you can share? Let's see. Most of the feedback has been around these issues that we've been finding from the serialization. I'd say on the positive feedback side are just some of the new use cases that are being supported. I tell you, people are pretty excited about the AI use cases. That's pretty cool in terms of what it supports and some, what's that? I was going to say the build profile. Build profile, which unfortunately we didn't get the presentation of here today but it basically supports the repeatability of the build process and the provenance of all the build artifacts that are in there. So if you're interested in security having that build information is really, really helpful. And the security profile that you did get to see, we've been getting some good feedback on that. And then like I said, the other feedback is around a couple of the issues that we're almost worked through. It was certainly the first time I've seen all those profiles come together. I think it's a great concept look forward to seeing the future in a bit of an opening. Thank you. Other questions, general questions? So where can I find like the RC1 spec so I can try it out in my tool and a second question is can there be multiple profiles in the same SPDX document? Yes, yes and yes. So the GitHub repository for the spec is called the spdx-3-model. Yeah, just pull it up over here. So github.com-spdx-spdx-3-model and there's a github.io page. It should be in the readme file how to navigate to that. There is a generated set of pages that actually describe the model and then you'll also find a generated Shackle file that is a kind of a schema that supports the JSON-LD serialization so you'll find that in there as well. The one thing I will mention is we do have a to-do item for RC2 to improve the documentation so don't expect great readable documentation but it's kind of machine generated so you'll see the classes and the properties described but it doesn't look all that pretty. We've got a really pretty one coming and it's a little late for RC2 so should see an improvement on the readability soon. Multiple profiles. Yes, you definitely, basically when you generate a, in 3.0 we're calling an spdx collection you can think of it as an spdx document. It has a field that says which profiles am I supporting? It is assumed that CORE is in there so you don't have to put CORE in there because everything has to use CORE so that's always assumed but if you want to communicate to your downstream users of spdx that I am going to put licensing in there I'm going to put security info in there and I'm going to put the build info there is a, it's called profile conformance I think is the name of the property and it's a list so you can put as many in there as you want. The expectation is that if there is a field that's required for that property it'll be there so in fact it would be considered an invalid document if you said you supported the security profile but you didn't include the security information so, yeah long answer but yes. Just on that point Gary in a semantic point is there a certain order that you're going to put those profiles into an spdx file can you put it in any order? Any order, any order, yeah so wait a minute oh I see yeah during the presentation about the AI profiles I noticed several properties were text based I noticed the energy consumption for example which was a neat description but putting that into something more codified and machine readable would be great how do you think that will deal with the naming of the fields is that just that the field names will be the same and when is the virgins update? I'll pick that up since Gopi isn't here and I'm in those meetings all the time we've actually discussed that physically and we've been planning that we'll probably change the name slightly for the when there's an actual formal enumeration but we didn't feel that the state of the enumerations was ready yet for us to code it up so we went for text to try to get the data and we'll refine it over time if you've got versions of views on what the enumeration should be just start mailing us on our mailing list and we'll start working for it for 3.1 still on the profiles it was said today that the AI profile has borrowed from properties from other profiles so does that mean that if I include the AI profile I should also include these other profiles should it be automatic or no it's just based on the model so there's certain software things like packages and files that are going to be there for the AI as well and so the properties are coming in from that portion of it and so there are things that are already required in the core and so the core is inheriting so we're just insisting that these profiles must be there because one or two there were optional for the core but they're mandatory if you're in the AI profile so I can show the slide from the security example which is basically the idea is that if you're implementing AI you probably have a piece of software that you need to create an element for and so you're going to use the software profile for that but then you're going to use the AI profile to actually describe characteristics of the AI while we're waiting for the microphone to transition I'll just add a little to that within the profile definition we allow the profile to further restrict the core properties in classes so you could say okay like concluded license is not required in core but it's actually there it's part of you can put a concluded license on a package in core the licensing profile if you support the licensing profile it requires that property be there that relationship actually be there so you can add further restrictions but you can never make it more general so if you say you comply to a license profile you may be further restricting things that are defined in other profiles if that makes sense this is an example from security the security profile contains information about the CVEs but there will still be the core profile which has information about the agents that interact with the software the organizations software profile the actual software and then security is just enumerating vulnerabilities related to the software and software profile yeah I have a question I don't know if this is too detailed for the whole audience but just that you know there are projects where we use as pedics not as an output format only but also as an input format you might be familiar with that with the OSS review tool kit and here's a very specific question because we observe some package managers that allow you to not specify the version of a dependency that you use but can say latest now my colleagues told me that I'm not going to use the as pedic because the hash code for external references is a mandatory field and so they are fighting every time we have such a situation the question because you mentioned early hash code now is this more flexible with the new version is there a way then so how would you handle that in future is this the strict no you also need to define the final version or is there also an option where we could then represent such it's not recommended to everyone right to do this but sometimes we cannot choose change this and then we need to handle that somehow yeah so I'm going to give you two answers one is from the spdx spec point of view which is more flexible and so you don't have to put that in there however there's another answer which is if you're trying to comply like the NTIA minimum specification I'd give you a different answer because there they do state that it's required that you put in the specific version Kate and I were just in an email dialogue last week about something similar with the supplier information and the thinking is if you're the producer of the package itself you're building an S-bomb and you're building the software that's being delivered the idea is you should be able to put in the real version you should know that so making it required for that scenario seems reasonable what's hard is if you're going through the dependencies of that build you may not know all of the information for that in that scenario I would suggest you put in what you know so if it's latest in a string latest put in the information that you know and if you can get the information you can now the problem is that still doesn't meet the letter of the law for the minimum specification because they say it's got to have the actual but I do know in practice that sometimes you just can't get that information for that artifact because it's two or three levels away if you're a third level dependency and they didn't capture it in their S-bomb but if everybody followed the practice they're always putting it in when they produce it and they always produce S-bombs we should be able to get there I'll also comment that the CISA tooling working group is basically looking at each of these fields and trying to determine what is pragmatic and what makes sense and this issue was actually talked about last week in that meeting as well and the view that seemed to come in from the room is do you put no information then just declare it as unknown completely or do you put in what you know and the view was put in what you know because that at least gives people clues to go find out more even if it's not perfect Github also has this issue right now and they generate a SPDX document for just a repo and when they're scanning requirement files they will run into like version ranges where it's between one and two but they don't know which version so they put the version range as the version and perhaps we should publicly blame that as bad practice to do it yeah but we're trying to figure out what should we guide people to try to standardize on and so that's part of you know here's how to do it pragmatically and if everyone tries to line up with the same pragmatism at least we can start to exchange but again if you're producing the package put the version in then everybody downstream can you know put in the right stuff just wanted to add to that if the version is stable you resolve it to something and you hand it downstream the version might still might not be the same for them to resolve so I wouldn't say that it's just half the issue I still think there's some complexity involved that is not yet represented there so Max you triggered a thought I got one more thing to add is in SPDX there are different relationship a wide variety of relationship types to pick from for dependencies so like you could have one that basically says this is provided so if you pick a relationship type that says if it's provided meaning that it's going to be on the system that it's being delivered to so you know that you got a dependency on this but your package doesn't include that so you can pick relationship types to better convey in a more granular fashion and what you don't know so that's just another possible loss I wouldn't call it a solution but another hint as to what's known SPDX 3.0 uses JSON-LD and JSON-LD requires context JSON and what I'd like to ask you is context JSON will be provided from SPDX working group it can be distributed each company or some kind of organization yeah so we will be providing the context for the JSON-LD in fact I think it's going to be generated from the from the specification so there's already a prototype didn't Armin he produced a prototype to do that oh it's there okay so yeah so I guess we're generating the generated files for the spec today yeah so it's fairly static if those of you not familiar with context files it just provides the mapping between the actual field names that are used and the semantic information or the meaning behind it it's the linking in the JSON-LD data so I'd like to talk a little bit about the post-3.0 era and the new profiles so the harder profile this is going to be I often see that a lot of harder manufacturers they really have their electronic bill of materials which are delivered in a certain sometimes customized standard sometimes it's really like a spreadsheet of some sort is there anything that is foreseen in the tooling in this regard so how to motivate people to really start to produce that in the SPDX form I think getting it motivated for people to start producing the SPDX form means that they see that they can put all the pieces together and then quite frankly people who are integrating needs to ask for it so if someone is buying hardware from someone that is the way to say hey I want this in this form when you give it to me I don't want to spreadsheet anymore maybe they can start to automate it and ingest it when they're creating an integrated system so it's a similar kind of thing is if we are consuming software packages and that's going to be you in that way and then do the integration people need to start asking for it but we need to make sure we've got a format that people can use and that will integrate for the safety cases so anyone who is doing safety and functional safety analysis may have certain motivations to getting apart from someone that they actually provide this information in this format so the whole automotive industry hopefully will help necessitate the change that will be one of the customers that I'm going to be interested in as well yeah so if we are at SPDX so I like this profile approach so thank you for that first of all it's in the direction of everything as code and therefore the question for the roadmap because if you look at export control or potentially also liability things like that where you also need a business context to do then the whole evolution is there already a planning of also having a kind of business profile then or how would be the way to come chat with me afterwards there's a project called OSCAR that's basically trying to hook SPDX up with the OSCAR controls coming out of NIST and so what they're trying to do is come up with some of the controls and then see how it's implemented and then figure out and we'll adjust SPDX so that it can support it so we're heading in that direction but we're looking to make sure we get enough people giving us input if you're familiar with doing input on business controls just please come let me know and I'll connect you up and maybe we can get that project launched I mean excellent any other questions on the presentation if not we were how much more time do we have 12 minutes well we could do 12 minutes on that there's a landscape part of the discussion now one of the things we wanted to do with the group is kind of landscape oriented but you know we wanted to get some feedback for SPDX 3.0 what do you need to adopt it if you're a tool provider what do you need out of the spec if you're a consumer or producer what kind of tools do you need what are you looking for what's your roadblock what's in your way getting close to being done on the spec and now we're turning the shift into the tooling and we'd like to get some guidance from all of you on where to focus so that's one of the thoughts so it's a little bit landscapy but you know well I more meant the landscape page like the CNCF landscape what I wanted to say at least I'm also involved with the Linux Foundation Energy we also have a landscape page it contains less projects than the one of the CNCF maybe therefore it's a bit more structured but also we came up with an overarching architecture and that defines the categories we have on that page I think that is the main and that was also addressed in the setup getting some categories at first that will really help to identify the projects and structure them once you start adding them so I think that will be the main first step to fill the landscape we would certainly welcome your input on helping us look at the categories we were initially thinking of lining up with the Sbomb types they're coming in so which tools are working with which Sbomb types as well as which versions of the spec are supporting which tools some of the filtering criteria we're looking to see which tools are supporting which versions of SPDX because we'll be seeing a shift from tools from 1.2.3 over to 3.0 and people are going to be wanting to know which one they're working with over time too but anyone who is interested in working on the landscape basically Jordy and myself come see us and we would definitely welcome input that's helpful though it's got me thinking I wonder if profiles should be in the mix somehow too are tools supporting which profiles? yeah it's a good thought thank you last 8 or 9 minutes or so what do you guys think as far as feedback for 3.0 adoption what's in your way what could we do to help you do adoption how many of you use Python as part of your ecosystem Python have you looked at the Python library have you how does it look do you think that's something that you could use that's stable something you could that haven't looked at Python do you know how would be Python do you know how the Python library is compared to the Java tools when it comes to performance so this is something I am struggling in the last days that I have validated what is it 2.2 million lines of JSON file with the Python tool and it ran overnight just to complete without any output before that so the Java tools are really fast I maintain the Java tools by the way I think that's been fixed yeah let's say the Python tools in 0.8.0 version created the license list for every license check things that cost a lot of traffic and that was fixed and is now a lot faster and I would be interested if you still see issues with the latest version that was 3 weeks ago it was released I am interested let's talk I am just curious have you tried validating with the Java tools if you go to the online tools that's a big file to upload but the online tools which is tools.spdx.org tools.spdx.org there is a validate you upload your file and that's running Java in the back end submit an issue if it's slow and then I can compare notes with max and see which one is faster Rust the other one we are looking at is JavaScript Rust would be really useful somebody should write a Rust library the Go library is coming up that's why I am talking about we need to come on unit tests because all the tools need to use the same test otherwise we are not using in this way I should be running every merge or every commit do we still need the CICD? I can help you I can use help I am a bit curious about the ecosystem using spdx3 have you got connections because we were working a lot with Yachto project for instance that's why we can actually more or less use the Python tool because Yachto is written in Python so it should be quite okay and I know they plan to work on that so I don't know if you have some forecast on that because it's quite sensitive and on the other side for the sbomb conceptions we also made some analysis about the tools to check sbomb and to check cps and so on we checked Daggerboard and a lot of different tools and we didn't find so much very accurate tools with all the spdx2 for the moment but I guess for the spdx3 you are going to have the same issue so have you got some connections with some open source projects to include sbomb and to make sure that we can actually track cbe correctly on the Python side I definitely encourage you to switch over to the libraries because it's your best chance of keeping up with 3.0 I think the hard part in answering the I should turn it over to Max give you the hard question when is it going to fully support 3.0 but then you need to know when the spec is done it depends on when the spec is done so it's a tough question but if you're using the libraries you got a lot of people that are pushing to keep that current the second question you had on the upstream sbombs from the definitely want to get more upstream suppliers to have accurate sbombs in there and I don't have a good answer on that but I will say something I've been trying to do in spdx almost from the day I started working on this is getting the package managers to natively output spdx we're going to see some progress in npm the node package manager there's an rfi and they actually have a pull request to actually implement generating spdx as part of npm so then it should be hard it almost be hard not to produce an spdx document once that's implemented we do have plugins for maven we have plugins for gradle now that generate spdx it's like okay they're out there but people aren't using it I'd be open to any help or suggestions maybe it's just awareness I don't know we did start by the way to help overcome one of the hurdles just knowing that they're out there and knowing how to actually get started so I'm hoping that helps sorry do you think you can maintain a map on your website to say okay we've got this tool which is spdx 3 compliant because it would help we have today a list we have a list of tools on the website if you go to spdx.dev you'll see lists for open source and commercial tools and we do list which versions they support so as they two things have to happen they have to support 3.0 and they have to tell us they support 3.0 then we'll update the website and keep that current so here's the quick start guides if you're interested we are always looking for people who's tools use or consume generate spdx to put a quick just it doesn't have to be long just this is how you get started using spdx using our tools that will help bring awareness and then I was going to go to the tools page on spdx.dev so for example yachto I just put in the link to the existing quick start guides for yachto on that but if any of you have tools and it doesn't have to be 3.0 this is for 2.1 2.2 you know any of the current versions if you have tools that generate or consume spdx and you want to make that tool visible submit a pull request to that get hub repo that was up on the screen a minute ago yeah so these are open source tools um that we know support it and this is the most up to date information we have with the versions supported and the sbomb types which comes from sysa um that's produced consumer transform so transform yeah and then within that there's translate merge and tool support so exactly based on like what you said there is not much awareness which I also feel because like if you go to cyclone dx website they have a very nice similar kind of tool page where you can select your language what you want to support or the package manager and is it commercial is it open source you will find something but yeah now I see this it's a good initiative from spdx because people are generally not aware that there is something for this particular use case and the tooling landscape will hopefully address some of that as well landscape will be a much more interactive searchable version of this table that we have right now so other thoughts I guess we don't really well I don't know if it matters what's that but is it we're at time yeah so thank you again for coming today we'll be all of us will be here all conference so um if you have questions we'd love to answer them and have those discussions with you and if you think of anything tomorrow the spdx this is all on our website drop something into the mail list and you should be able to get some good responses through that so thank you and I just got the build presentation from Nisha so we'll publish the slides it will have an overview of the build profile if you're looking forward to that today okay great okay so yeah look for an email with the slides thank you