 All right, so I think many of you in the room are familiar with the SPDX tool. I'll probably go through this relatively quickly because I'd like to make sure we have some good time at the end for some discussion on what the future is. And quite honestly, I'm going to get some benefits from all of you is to get some feedback on what we should be working for next. I want to make sure we have time to do that. But if I start to go too fast and you want some more detail, just help me to slow down, you know, or pause and answer questions, whatever. So I used to call these the SPDX tools, but that's a little confusing because you saw a bunch of SPDX tools and they're not from SPDX. They're from a lot of different contributors. So they're now called the SPDX work group tools in case you need the translation. So SPDX work group tools are really SPDX tools that are built maintained by the SPDX technical group. Most of it's mine, but there's quite a few contributions from other code writers. And everything in here is essentially contributed to by the entire technical group. I don't think there's a single line of code that wasn't influenced by some discussion within the SPDX technical, you know, working group. So it really is a collaborative work that's available to everybody in open source under Apache 2.0, whether you like Apache or not. That's the one we decided on. What did the SPDX tools do? Well, you know, they really are, most of them really are intended for the consumption of SPDX, which is a little bit different than some of the other tools that are out there that are a little bit more targeted towards the production. But it's for reading and analyzing the SPDX document. Now where these tools actually came from, and I mentioned this at the beginning, but it may give you a little bit of context where these have come from. We really support two different formats. We support the tag value format, which the Linux community just loves. And then it supports the RDF format, which a lot of the Java community just loves, right? And so this kind of brings those two different worlds together, the tag value format and the good, I'm sorry, the RDF format. So we couldn't agree on the format, so we decided to write some tools that translate between RDF and tag values. That really was the genesis of the tool, but they've evolved quite a bit since then. So there's viewers that will basically take an SPDX file and just dump it up to a text file for easy reading. Very simple command line. We've extended that to be an HTML format. And if any of you are HTML programmers and would love to create a very nice looking HTML file, there is a template file that I would welcome anybody to contribute to, because I'm the one who wrote the template. I'm guaranteed it's not very good HTML. It's not very elegant HTML. Somebody could write a much better one, contribute that back, and we have a really nice HTML fuel for the SPDX file that encourage contributions on that front. I'll put it on the list. And while I'm at it, I'll make one more plea for contributions, which is the tag. I mentioned I'm an RDF guy in Timboren coming from. Nobody's maintaining the tag part of the translators. When we go to SPDX 2.0, there's a really interesting, I think it's a really interesting computer science problem of being able to write a new parser that can interpret something with a hierarchy. Right now it's very flat. Every tag is unique. It's very simple. I got this tag. That's where it goes in the SPDX file. Now you're going to have in 2.0, I've got a document. This document may have other documents, or you've got a document. This document has a package. The package may have other packages. It may be the production. And so how do you create this hierarchy, and how do you represent that in a language? So any of you that are into LALR parsers, or a compiler guy, or if there's like a university that has a compiler course, that has some students that would like to contribute something interesting to be part of a new language, we have an opportunity to contribute to the SPDX community. So I'll put that up here too. Right now I'm doing it. Again, I'm not sure I'm the best person to do it, but it's there. So in addition to translating between tag and RDF, we also translate between spreadsheets. This is particularly useful for those of you in the legal community that don't read RDF or tag value, but like to work inside a spreadsheet. So basically it goes both ways. So you can take something that Matt and the UNO tools produce in the SPDX, and you can import it into a spreadsheet and you easily read it. What's neat is you can go in and you can make modifications, and then you can translate it back into a tag value or an RDF file format that can then be interpreted by the tools and be uploaded to the diff tools again that you saw earlier. So that's a very, very useful translation. What's new is we did some command-length comparison. Originally I did a comparison of two different files, but based on a lot of basically the bake-off that's coming up tomorrow with a lot of help from Phil and Kirsten and I have actually been collaborating on this for quite a while in terms of the comparison document. This afternoon's bake-off right after lunch. Here, here. That's right. Come back and then you'll see a demo of the comparison tool, in addition to a lot of different tag value formats that will then be compared. So now it'll actually produce this very, nice-looking spreadsheet that'll compare multiple documents. So when we do the bake-off, all these different, you know, tag value formats that are produced by all these different tools, you just load it all up in one spreadsheet and then we can go through different tabs and it'll show you color-coded. Thanks Phil for the suggestion. Color-coded, you know, what are all the differences in there. So that's, and all these tools are available uploaded in open stores. Talked about this, and then this one here. Does anybody in here a Java programmer by chance? How many of you are programmers, software writers? Okay, good. How many of you are Java programmers? Okay, close enough. Oh yeah, Android is Java. If you write Android apps, even if you're not a Java programmer, I'd encourage you to look at the actual source code as a model for implementing things in any other language. The model is fairly complete. Any object-oriented language will recognize the structure and be able to leverage at least some of the concepts from the other source code. So in addition to the actual tools, there's the library that implements the tools. And I'm just gonna, since there isn't that many Java programmers in the room, I won't spend much time at all, but I'll give you a few features that are much out there, much available. Like I mentioned, there's a lot of different contributors to this. I just wanted to call out a few people. Protocode, Raina was the previous author of the tag value. I solely miss Raina. She was very, very helpful for the organization. Peter Williams at OpenLogic did a lot of the RDFA support. Kirsten, in addition to collaborating on the comparison tool, she's been doing a lot of the documentation and the requirements analysis for it. Kate's done the tag value design and the ever-popular spreadsheet format. And then the technical and business working groups, like I mentioned before, done a lot of the requirements and betting out the different implementation options. And of course, I've done some new implementation. So this is just a little bit more detail. I'll tell you all these slides, say it's the same thing. Command line driven. Nothing elegant. It'd be nice if it was on the web. It'd be nice if it was like the UNO tools where you just go to a website and do it. But you can download these. You do a Java dash jar. You give it the name of the application and the name of the file. And it runs and introduces what it produces. It also, all of these tools actually do a validation. So there's been some talk in the technical and business teams that, boy, we need a validation tool. Quite honestly, those discussions are frustrating because we've got one. Just run these tools. It actually does a fairly deep validation of the file. It goes through everything that we've discussed in the technical team and things that need to be validated. So for example, organization, according to the spec, need to have person colon, organization colon, or tool colon. If it doesn't have one of those, it's not a valid STDX document according to the spec. So I actually go down into the fields, parse that out, and I'll report back. I may not fail the tool. It depends on the severity of the verification error. But I'll actually produce a list of warnings. Let's say this STDX document is not valid because, you know, it goes all the way down to the files. So that's another feature that's present in these tools. Just a view of the spreadsheet translator. This is the comparison. And I'd encourage you to stick around for the backup so you can see that. The spreadsheet output of that gives you a view. The two-way comparison is just a text document. The one thing I'll say about that is it does go through a fairly detailed analysis. It's extremely nitpicky at the differences. What it fails at is the summary analysis. It doesn't give you a very good feel for how similar or dissimilar they are. But it will tell you even if the most minute is to detail. It's different. It actually implements a license comparator that will take two different licenses. So we use the proposed license matching guidelines of STDX to see if the two texts are the same. So in the comparison, you know, you may have license rough 23 here, license rough 70 here, and it includes a text in there. We'll do a coconut comparison that, you know, does the British, I'm not particularly British. It might be American English to non-American English translation. And I'll tell you if those two licenses are close enough to be called the same. And then it'll tell you these two are the same for the same license. Yeah. Yeah. But thanks for that. Yeah. So this is an interesting one now. I think in practice that when I think about it, if it's made by the same tool, it's probably going to show up to being the same license because the license references are never the same because they're usually generated by the tool that collects them. Yeah. You know, so if it's the same tool, I'm going to tell you the same, but because these things are extracted and the tools have different mechanisms for extracting those licenses, I'd be surprised if we ever have the same license show up as being equal, you know, because one's going to grab more lines than the other. And, you know, one's going to include the like in the tool that the source editor has, he turns out the comment. So you won't see, you know, the slash slash or the slash star. So we have a comment part that just, you know, gets rid of all that. A lot of other tools like we saw that the NINCA tools, actually NINCA does that as well. But I think the solubility leads to the comments in there. So those aren't going to match because of comment characteristics. In practice, it may not be that useful, but it was some interesting programming. So tag value translator, not much to say here, other than contributor to maintain the tag side of it. And this is my short, I don't want to scare you with this. I'm not going to go into detail on the model, but this is the object model that's implemented in Java that supports the DSPDX standard. So this is the same model that you'll find in the spec only represented as a more of a formal UML class diagram. So you'll find Java code behind each one of those that you can go in and look at the implementation. All of them have a common method called verify. So you can go in and look and see how we actually verify each of these different classes to see, you know, if, you know, if your tool is forming at the same way, you can see the same rules that the DSPDX tools are. The other thing I'll just mention as far as these Java library tools, they are using commercial applications. I know of three of them that use at least some of it, source auditor, a black duck, I believe uses some of the DSPDX library. And I believe protocol uses some of it as well. So, and their license in a way to encourage commercial adoption. One of the reasons I put time into this is I wanted to see SPDX adopted. And I wanted to make it easy for tool vendors to do it. So here's the set of libraries. And the only problem is you have to be using Java or have a Java bridge. So that is a little bit of inhibitor for some of the, some of the tools, but maybe somebody will write some movie, you know, SPDX, like what is that, can be used for some of the others. The model is transportable. Exactly. So you can definitely, there's licenses. Oh, I almost forgot to mention this. I've been talking a lot about the tools in terms of the translators and displays and everything else. There's almost like a different set of libraries, different aspects of the tool, which is just related to the SPDX standard license list. If you want to programmatically go find the SPDX standard license, you want to programmatically be able to understand what's in that license, what the text of the license list, what the title of the license list, what the URLs are. There's a set of libraries that are implemented into the SPDX tools that will allow you to do that. And it actually, it's actually pretty pretty sophisticated. It will go against the, the, the actual website that stores the licenses. When you go look at SPDX.org.licenses, you see a bunch of tax, you see it rendered for you as a human. Behind that, there is an implementation in RDF that can be parked. And these libraries are basically a programmatic interface for those parts licenses. Now there may be a situation. I mean, I do a lot of audits where I'm not allowed to access the internet. It's a real pain, by the way, but some people are very sensitive about the security around this source code. So I needed to have that offline. So in addition to that, the library has a copy of all those licenses locally so that, you know, but if it fails a connection to the internet, the tools will still work. So that's all implemented. It won't do, it won't do any kind of real time caching. There is a resource directory that stores it all. So you think you can do that manually, but it's really the updates to the tools that, that really, you know, download a new version of the tool when there's a new version. So the offline, you know, if you're using it offline, you do have to be careful that you're using the most recent version, you know, of them. But the user can update that directly. You don't have to, it's nothing, that's hard coded in Java. And it's basically download the archive file of licenses and dump it into the resources, you know, directly. And I mentioned the license comparison functions that are not set to the comparison. If you are interested in using the Java, there's really two starting points at point two. There's a class called the spdx document that's the top of the model for spdx documents. If we were to find that spdx packages, licenses, spdx files, checksums, all those things that were in that other diagram can be created from this class. So go look at this and you'll find different ways to open or create. So basically, if you point it to an existing URL on the web page or RDF, or an existing file, it'll be able to open and read it. Similarly, for the license functionality, there's an spdx license info factory. And what you can actually, there's two different main interfaces to this. One is to basically create licenses, but you can also pass it strings that are in the standard spdx format, and it'll basically parse that string for you. And it'll be able to detect if it's an spdx standard license, a non-standard license, keep track of the non-standard license IDs, all that stuff, and be able to hand you back to the right license. So that's for the programmers in the world. That's for the three quarters of the Java program. What's next? You know, actually, this isn't as important as it used to be. Personally, I'd love to have the tools online because I like to see them be unique. It's really hard to download a jar file and type in all the command lines to be able to use it. But you know, when I look at the work that UNO has done, you know, you guys have really done a nice job of making the spdx functionality available on the web. So it may not be as important as it was before. The HTML viewer would be really nice to enhance and make that look a lot better. It's very flat. You have to scroll a lot to be able to look at it currently. I've been asked to provide a JSON format for the license website, you know, so that's how the list of things can do this, and people that would like to use that as a good CRGF. I guess a good idea is a very popular format to be used. And then it's whatever you guys would like to see. So, and again, when we get to the last part of the discussion, make it much more, I'd like to see if you guys have ideas on what you'd like to see in the spdx. What would help you guys, whether you're a tool developer, if you want something in the library, or you're a user, a consumer, or you're producing spdx, what would help you get it done into the document. So I won't ask that now because I wanted to say that for the very and the very important access discussions on that. Okay. So see, do I have one slide on this one? It's important. It's all open source. There's a git repository that has the tool. Contributions, suggestions are welcome. If you want to, if you want to, for example, maintain the tag value, I'll make you a, I'll give you access, you can commit the file directly to git. If you just have a few small improvements that you, you want to make, feel free to email me a pass pot or just let me know the idea or the suggestion. We do have a defect website that you can go to, a bugzilla, and you can feel free to sign up and contribute to that. Did I mention we need a maintainer for the spdx tag? So I feel like I got to change you to a different person now. So this is a different presentation. And again, I'm going to make this relatively brief because if I, if I spend too much time on this, I'll expose some of my biases. But this is a, this is just a landscape of the tools. And I think this is something that came up with the business team. I think Scott, you mentioned this, is it would be nice at the Linux collaboration summit to, to basically be able to review all the tools that are out there that support spdx. So the support that we sent out a survey about two months ago, and we asked everybody in the spdx organization to please tell us any tools you have, any tools you know of, any, you know, even remotely know of that support the spdx, whether they're open source or commercial. And I just have a few slides here that present the results of that survey. This is the summary. So these are all the tools here. If you're curious about the order, these are the order they submitted them. So the people that were really fast. But by the way, I got to say though that the, this is set up on the UNO site of all the cosmology that's got there first. But that's the order of them. The license that they have, you'll see it in, you know, pathology, PPL, the spdx tools sort of patching, three bsd for the dashboard, as Matt mentioned. And these are all the different commercial tools that are there. The other thing we asked in the survey is are these tools intended for production or consumption of the of the spdx? Most of them today are production with the, with the fuel that are consumed. But what I found interesting on the commercial side especially is a lot of the consumption is in development. Because you know, when you think about a tool that's primarily scanning and identifying the sources of it, you think okay, they're going to be producing, but there seems to be an interest now on the commercial side of being able to import the results, whether it's to compare against the finding or just to be able to bring it into the workflow within the own tool, those are those are actually planned in many cases as well. And then the last question we asked is, is this something that you intend to be fully automated, turn key, push the button and it's done? Or is this something that's more toward being used by an expert where it's really not intended to be a tool to assist in the analysis? So like in my case, the source order of the tools, you know, you need training to be able to use it. It's really intended for somebody to do the manual process and be able to assist that. But there's other tools that are really more of a website tool where you can go in and you can look at the information and it displays it in a format that gets compatible. Those are, those are much more fully automated. So I'll, you can look over the results there. Oh, I'm sorry, I shouldn't be using that. That should be as to get more tools like this one. And that's when, yes. And I actually have the detailed slides here. And we've already gone over the passology tool. So I won't go into more details here unless you ask me to pause dashboard. And the media reporter pause here because we haven't talked about this one. And you can see the integration pieces that they have available. Just to give you an idea of the format, the thing, format of the slide for all of these, just the description as described by the survey respondents. And in some cases, like here, it didn't fit. The full packs of the replies are in an appendix to the slide that are on the website for the collab summit. So if you need, if you have trouble finding that, just let me know. I'll email you a copy of it. But do refer to that, you know, if you want to get some more information in terms of the background and the tools. And of course, the most important is how do you find more information from the URLs, Black Duck, in terms of what they're doing, the integration pieces. They mentioned they use the libraries and have contributed back to the library creation as part of their integration with the STDF. So I don't know if you guys want to add anything. And these two people right here can give you more information. So in here, STDF, say, I got the workers on the slides and I already talked about that. The tools that my company produces, OpenLogic Exchange, we do have the representative of the logic back there. I don't gather any more information. You guys getting those kind of protocols. Another contributor, by the way, to the STDF libraries, especially on the tag value side. Thank you. And STDF's cloud, the wind river, I believe. So we talked about some of the pieces of that. And that's as far as the