 Can you hear me now? Much better. OK, great. So just talking through some of the details of what's in what we're now calling the licensing profile, as Kate described, their SPDX from the beginning was focused on representing licensing metadata for software. But as part of the expansion of use cases, we're pulling that out into a separate profile. So what this profile consists of is classes and properties for the different components of how to model licenses and license combinations, as well as the fields for the properties and the metadata that store information about those licenses. So a lot of this is going to be a refinement of what you'll have seen before if you've used anything relating to SPDX licenses in the past. And if you go on to the next slide, we've included links for where you'll find the current model definitions for the different classes that make up the licensing model. A lot of this pulling together pre-existing content from the RDF model or from other aspects of the SPDX spec. You'll find the link for the definitions of the different properties for licenses. And then finally, because these are properties, and I'll touch on this in a bit, because these are properties on defines to be tied to files or packages or snippets, the properties themselves for concluded licenses, declared licenses, and so on. These are currently stored in the software artifact subset in the software profile. So we'll touch on that in a bit. Go on to the next slide. So the components of a license model, and you'll see this in just a moment in the next slide about how these reflect, but the primary pieces are going to be things that you're familiar with. So the idea of a license, either being a license that's listed on the official SPDX license list, or the ability to define custom licenses, just like you've always been able to do. There's also one thing that is changing in SPDX 30 based on recent discussions of the legal team. There's always been the ability on the official license list to also include license exceptions that are defined on the list. We're now adding in the ability to define custom additions, which are additional text that supplements a license, and we'll touch on that as well. Just as before, and as you've always been able to do in the license expressions, you can use and or to reflect more information about how multiple licenses are combined, plus to indicate that you're talking about a license or subsequent versions, or the with operator tied to exceptions or additional text. And then all of this tied to none, or also being able to say none or no assertion if you're not specifying a license in an SPOM. So if you go to the next slide, you'll see that these are, so the overarching class is any license info, and I don't think you should have the spaces in there. I think those are by mistake, but any license info is the kind of abstract parent class for licenses or accommodations of licenses. None and no assertion are defined also as separate classes. If you go to the next slide, you'll see that's something we're sorting through and there's a, you can go on to the next slide. I think there's an open issue to resolve between the release candidate and for three hour, we're gonna sort through whether to be representing none and no assertion as separate classes or how exactly we're going to represent that. So that's one of the open topics for discussion currently. If you go on to the, I think in the next slide, you'd see an example of how this license expression, the way that it appears in source, in currently in tag value files or in more often, you'll have seen this in headers for source code, SPDX license expressions that combine multiple licenses. These are using the different classes that we just showed, those can be modeled in a syntax tree style. And again, there's nothing about this that's actually new. This is always something that you've been able to do in SPDX 2.3 and earlier, it's just because of the way that we're defining the classes, defining the models, I think a lot of this is going to be elevated and more visible and a little clearer how to translate license expressions into this format. So we can go to the next slide. So as I mentioned for licenses themselves, these two concepts, listed licenses and custom licenses have been around since the beginning of SPDX. Listed licenses being those that are on the official SPDX license list and custom licenses being those that are user defined in an SPDX document. So changing the name slightly to help clarify their purpose and reflect some of the changes in properties that are available to define on each of these licenses. So we go to the next slide. And again, for listed license exceptions, this is also something that's been around since, in this case, since SPDX 2.0, to be able to use on the right side of a with expression, any of the exceptions that are publicly defined on the official SPDX license list. But if you go to the next slide, something that's been a topic of discussion for a long time is how to represent things that, there's been a desire to represent things that are not fully official exceptions to license conditions or additional permissions. And so in SPDX 3.0, we're adding the ability to define custom license additions, which are essentially additional texts that is not itself a standalone license. So this is gonna be, you see here, an example in the bottom with addition ref to be used for additional text. Just to be clear, the exceptions list on the official license list is going to continue to be only official exceptions, things that are truly exceptions to license conditions or additional permissions. So go on to the next slide. And then the other major point is just that we're kind of rationalizing and cleaning up some of the property names and unifying them across packages, files and snippets. I think in the past, there's been some different names for these properties and different ways that the names are used. And so one of the goals for 3.0 for the licensing profile was to align on common names in terms for the properties across the different types of software. Now, the way that they apply or the way that they're reflected may have slightly different definitions, but that's part of what you'll see as we go into, as you take a look at the property definitions for these. So go on to the next slide. And then finally, so there are a number of open issues, a number of some of which are more technical or mechanical, but a handful of which are open substantive questions. And I'm not gonna, given the time for the moment, I'm not gonna get into these right now, but you can take a look on GitHub, please come, please join in. We'll be looking to discuss these in upcoming SPX legal team calls, balancing, talking about the licensing profile and continuing to do the work we do on maintaining the license list. So we'll also likely be looking to schedule additional joint calls with the tech team and the legal team to move the licensing profile forward, just as needed between now and the three hour lease. And I think with that, I'm gonna turn it over to Jeff. I think we're gonna look at a couple of use cases for the licensing profile. Thanks, Steve. So I'm relatively new to SPDX. Kate and Rose asked me to talk about use cases a little bit regarding the licensing profile. Before I jump into the specific examples, I wanted to bring up one point, which is having done lots and lots of license scanning and use many tools over the years. It's pretty common for tools to think of a file as sort of an atomic piece. Sort of the, you know, we think about software components in an S-bomb. You have packages, you have files, you have snippets, you have other artifacts, binaries, et cetera. It is very common from a licensing perspective to find multiple licenses in one file. But that doesn't mean that all the licenses apply to everything in the file. It's very common for one license to apply to a snippet and another license or set of licenses to apply to another snippet. So we're gonna talk about that a little bit with these use cases. In fact, here we have an example showing in the file header that we have the Apache 2 license and then immediately below that we have a comment indicating a specific component and we show another license or in fact two licenses here. So one way to look at this is say a scanning tool might scan this file and think of this as, okay, all of the licenses just apply to this file. So we've got this license and this license and this license and in this particular case we're making the assumption that GPL is unspecified. So it is a custom license. It's not one of the standard license because it's also extremely common for people to be lazy. Go figure, especially software engineers. We like to be lazy. We like to just do things quick and get them working. So that's just fine. But it can lead to confusion. Oh, by the way, this wasn't a part of a plan in the talk but I'm just gonna pitch, please use SPDX license identifiers always, thank you. So this is pretty common for a scanning tool to look at the file and come up with this result. But another way to look at it is we have Apache 2.0 and because of this second comment we have the next phrase which is MIT or GPL. And in this case we've gone ahead and made the assumption that it's GPL 3.0 only. But what I like to see is this case which is you don't have all of these licenses apply to the file. What you have is you have two distinct snippets. You have one snippet that is Apache 2.0 and then you have another distinct separate snippet which is MIT or GPL 3.0 only. And in this case in the S-bomb each of these would be a separate entry in the S-bomb. These are both snippets and they're separate. Even though it's one file you end up with two entries in the S-bomb. So the next use case is a license that's pretty common except that it's been modified a little bit and this is actually not unusual at all when it comes to licenses. People, again software engineers, developers are humans. Okay we're not talking about AI here that's a different session. And when we put the license in the file header sometimes we add extra comments. So in this case we have standard GPL 3.0 or later and then we have an exception that's pretty common, the auto-config exception but there's some extra text added. So currently in SPDX 2.3 what we end up with is most, it'd be common for scanning tools for example come up with this concluded license of GPL 3.0 or later with the auto-config exception except in this case because the exception has extra text added to it it's not a standard license or a standard exception. So we end up with a custom license. That's okay, SPDX 2.3 allows us to put this custom license in except that, I don't know, I talk to a lot of lawyers it's a pretty common thing for me and lawyers like to see, lawyers do a lot of license compliance and they like to see things that they already know about and understand. So this could be a little bit harder to understand just because it's like, oh it's a custom license what's this, I haven't ever seen it before. But what we can do now is we recognize that oh this is maybe the auditor or the scanning person would say oh this is just a standard thing plus one extra little bit. So I can handle that, it's really simple. What we have is we have the standard GPL 3.0 or later and we use the with clause which of course is always been there but we have this new custom license edition and it's this addition ref auto conf GPL 3.0. So what this is is we're not using one of the standard license exceptions that Steve mentioned, there's a list of standard license exceptions. This is a modified license exception. So instead of having a completely new custom license we have a standard license with a custom license exception. So I think it's much, much simpler and straightforward to understand.