 Are you hearing me? Oh, all right. All right, I think let's go ahead and get started. So thank you all for coming. I'm Steve Winslow. I work with Boston Technology Law, which is a small law firm in the Boston area, focusing on tech licensing, open source, data privacy, that sort of thing. I am going to talk today about the SPDX license list and getting into which you may have heard of, but getting into some of the weeds of what it is, how it's developed, and ways that it might be useful for you in your OSPOs or other things related to licensing and open source projects. So before we jump in, just to kind of level set, just as a show of hands, how many of you have heard of SPDX prior to this conversation? Cool, cool. All right, most of the hands. What about the SPDX license list? Are you familiar with that as well? OK, so folks have heard of it. Which of you have used it, used the license list in any way in the past year? So good number, all right? And then have any of you ever contributed or participated in the SPDX license list? And I see someone coming in who I know the answer is yes, but so. So I'm going to talk today about what it is and then get into some of the details of how it's developed and maintained. So SPDX, you probably have seen this already, but it's the Software Package Data Exchange. It's an open standard. It's an open source project for developing a specification to communicate SBOM information. It's been around since the early 2010s, or possibly before that, and originally was focused on primarily conveying licensing information, has expanded to cover a variety of other security and other matters relating to identifying software. And last year became an official ISO spec. But specifically, the SPDX license list is also part of the same open source project as a community curated list of licenses that are particularly licenses that are used in collaborative software development. And so early in the SPDX project, the first beta version of it was about 100 licenses. At this point, for the latest release, we had over 500 licenses and license exceptions that are tracked on the license list. And if you've used the license list at all, you've probably seen this website. That's probably where you've gone to find the text and the identifiers. But I want to talk a bit more about what specifically makes up the license list. Because those pieces are probably what you've seen if you've used it before. That each license on the list has a unique identifier. It has license text associated with that identifier. And then there's some other metadata about the license. So information about whether it's OSI approved, whether it's recognized by FSF, the Free Software Foundation, as Free or Libre, and then some other cross references and notes, some other metadata about the license. So that's kind of what you find on the website. There's also a number of other related components that are used along with the license list. So in particular, the SPDX matching guidelines and the license expression syntax, which is really a mechanism for communicating more detailed license info than you might get from just a single identifier. It's particularly talking about ways to combine references to two licenses and communicate more specific information about multiple licenses. So the license list, like other open source projects, it starts with the contributors, with people from the community who participate. There's one repo in the SPDX org on GitHub, the license list XML repo. And that's really the primary upstream source of all of the contents of the license list. So it consists of, for each license, one XML template file and then a corresponding text file, which is used in the CI process to map against and validate the XML. From the XML repo, the CI system spits out the website and also outputs the license list content in various formats in the license list data repo. So as a user of the license list, you're probably looking at one or the other of these bottom components or bottom resources. If you're going to participate in and contribute to the repo, the license list XML is where you find really the primary upstream sources of all of it. So that's what the license list is. So I want to also say a bit about what it isn't, because this is useful kind of understanding the scoping of the problem that the license list was trying to solve originally. First off, the license list is not legal interpretation. So it's not about what do I have to do to comply with this or that license. It's really about identifying licenses and having an efficient and machine-readable way to communicate license information. So similarly, it's not about categorizing licenses. We're not on the license list itself. We're not bucketing licenses and saying, these are permissive. These are copy left, anything like that. It's really just a flat list of licenses and then a list of license exceptions. And there are downstream projects. There's a number of other downstream efforts, other communities that might take and use the license list identifiers to create their own categorizations or to talk about licenses. But really what we're trying to do within SPDX is just create that kind of upstream curated list of licenses. It's also, it's not a list of only free or open software licenses. There are licenses that you'll find on there that don't fit within the free software foundation definitions or the open source definition from OSI. The bulk of the licenses that you'll find on there do meet those requirements, but there are some that are on there that don't. And we'll talk a bit more about that. Yep. It's also not a list of only software licenses. There you'll find licenses on there, such as the Creative Commons licenses that are really more intended for creative content or documentation. There have been use cases where we've added some licenses meant more for open data or even for open hardware. So not everything on there is just for software. On the flip side, it's not a list of every software license ever. Like there are reasons, they're part of the review process that I'll go into is there are some standards and some principles that we apply in determining, does it make sense to add a particular license to the list or not? What's gonna be most useful to the broader community that's using the license list? So. And then just a couple other things. The fact that something is on the license list does not kind of related to saying that it's not a list of all free and open source licenses. You also shouldn't look at it and think that these licenses are particularly approved or recommended for any sort of use. Kind of from SPDX's perspective, we're curating these, we're assigning identifiers to enable communication about them, but the fact that something is on the list doesn't mean that we're recommending it for particular use. And then finally, it's not intended to be a workshop for kind of getting guidance on how to draft new licenses. Like it's intended to be more noticing what's out in the community, noticing what licenses are being used, reflecting and curating that, but not work, sometimes we'll have people show up wanting to get a new license on the list when they're clearly still in the middle of drafting or adjusting it. And that's really not the focus of the SPDX group to kind of help draft a new license more to reflect what is being seen out in the community. So that's kind of what it is. So why is this useful? Like why kind of go to this effort? And I want to talk both for open source projects and then I'll talk a bit for companies and organizations. What does this gain you? Having this list of these licenses with these identifiers and these license texts. And for open source projects, I think what we've particularly seen is that there's been an ongoing uptake of using those short form identifiers in source code. Excuse me, and you can see an example here. The Linux kernel is one of the projects that just picked this up for a increasing number of their source code files. They'll use this SPDX license identifier format. Just a one line comment that has that prefix and then the license ID or a license expression based on that meets the license expression syntax. Basically what this gives you is it gives you a machine readable, greppable way to quickly identify what license is being used for source code. So as opposed to something where you've got kind of 10 lines of comments that are spelling out in English pros what license applies. This reduces it to something that can be machine passable, doesn't have errors slip in or at least is easily passable if there are errors slip in just to make it easier to know what license applies to this file or to this project. And there are other efforts out there in particular the Reuse Software Project from the Free Software Foundation Europe is kind of uses the SPDX license list a bit as an upstream. Reuse adds some other recommendations for ways to use that in connection with particular places to put your license texts or to basically their recommendations for how to structure your repo to help communicate this information again in a kind of clear standardized and machine readable sort of way. So and I'll mention that at the end of these slides there's I've got a bunch of links to particular resources on here. So if you haven't downloaded the slides you can do that from the schedule. It may be useful if you're looking at this further offline. So that's for open source projects and then for companies and orgs that are using open source, free and open source software. I think some of the benefits of the license list in particular someone else has already done the work so take advantage of that. Avoid I think having a common language and using it across communities and within companies saves you from having to recreate your own version from scratch. So again, even though we're not categorizing licenses according to permissive versus copy left or strong or weak copy left or anything like that I know that there are organizations and there are companies that internally will use their same IDs and apply their own categorization their own policies to that. So I think also for things like the short form IDs in source code it helps to reduce friction in compliance processes internally for companies. It makes it easier to find what license applies to this code so that we can then go and talk to our legal teams about well what does that mean what do we have to do because of that. And kind of related to that part of what using these IDs helps to do is to disentangle what are really often two different processes within a company one being finding out what software do we have and what licenses apply to it so that's sort of determining what the facts are and then separating that from the interpretation process from saying all right now that we know what license applies to this code now we can have the conversation what does that mean how do we comply with it how does that fit in with our own company or project licensing that sort of thing. So I'm gonna go on since we're a fairly small group let me kind of pause and see if there are there any questions so far I'm happy to take a couple questions just as we're going through this I saw yeah. So the question was if license if kind of a wide variety of licenses are being submitted to the list as a user of the list how do you know which version of a particular ID is the right one to use. And so I think a couple answers to that and one of these will dig into a bit more as we go on but partly the process of adding new licenses to the list is actually I'll say fairly heavy handed that we don't just like anybody can submit a request to add a license to the list but we apply a number of different principles and different checks to make sure that when something is being added it's not duplicative of what's already there taking certain matching rules into account. And so we do take some efforts to try to make sure that there is one specific identifier corresponding to a particular license. So the other part of the answer is in the GPL family of licenses this is much more complicated for a variety of reasons that relate to both the way that they were historically included on the license list and subsequent kind of requests from the Free Software Foundation about how to refer to GPL licenses that we tried that we made some changes to the license list to reflect that. So in yeah, go for it. So I think so a couple and so I think if you're looking for a recommendation for which license to use for something just which license to use I think that is probably more of a talk to your legal counsel or talk to more of a like which license makes sense to use for my project or for what I'm releasing. If it's more about I know what license I'm using and I'm not sure which ID to use that's the sort of question that is something so the SPDX project and there will be links to this too but there's a mailing list there are different kind of ways that you could contact the SPDX legal community and ask about that. Yeah. So all right, so I'm gonna keep going. All right and this relates to that. So I said there are about a little over 500 licenses on the list right now so why are there only certain licenses on the list? And part of this is really the goal of the SPDX legal team was to keep the list useful keep it as something that is gonna be useful to the broader community by avoiding either extreme because on the one hand it could be a list of just the top 10 open source licenses that people are gonna use and honestly that probably gets you about I'm making up numbers but 50, 75% of the projects that are out there are probably using some flavor of a GPL license or MIT or Apache 2 or something. You know if you take the top 10 to 20 that gets you a good percentage of the licenses so one end of the spectrum could be a list of just those. On the other end you could go every license ever like any time that there's any sort of change to a license text it gets its own identifier. And I think the problem with either end of that is that it's either if you go too far in either direction it's not useful to the broader community because something that misses a large chunk of the licenses that people are actually encountering in practice isn't useful because you've got too many caveats and too many things that don't fall into the what's on the list. But if you're including every license ever if you end up with a list of 10,000 license IDs and 10,000 licenses that doesn't necessarily help compliance either because if you've got like 17 different identifiers to talk about minor variations of the MIT license that may make it harder for you to really do reasoning about how do we comply with these and what should our policies and compliance be. So the way that we've tried to approach this is to aim for something in the middle by applying license inclusion principles and these are either on the next slide or they'll come up in a bit. But one of the key points here is that we decided early on that for the licenses that go on the list itself it's we're not going to try to add things that are really purely proprietary, executable only, binary only sorts of licenses. So every company's own custom EULA we're not gonna add to the license list. Really it's gonna be the sorts of things that are licenses you're likely to encounter in collaborative software development and in particular where there's licenses for software that's included in packages in a Linux distro particularly for distros that really pay attention to licensing. So kind of leveraging some of the work that certain distributions have done to care about licensing matters and saying, all right they've really focused on this we will work with them and understand kind of the way that they've been thinking about licensing and reflect that in what goes on the list. And this is kind of saying similarly in the principles that we use to decide what goes on the list we do we don't require strict compliance with the open source definition to add a license to the list but we certainly favor licenses that do in the kind of mix of factors that we take into account. We do add we do sometimes add other source available licenses when there's a sufficient showing that it's in wide enough use that it's a unique license text it's widely enough used that people are likely to encounter it in the community in the broader kind of software collaborative development community then in some cases we have added source available licenses to the list. And so the way we do that is by applying our license inclusion principles and our judgment kind of the community judgment in figuring out whether a license meets those principles or not. But sometimes we get the question, all right well I wanna use this license but it's not on the list. So if it's something that meets those inclusion principles then it's a candidate to add to the list for somebody to submit it for review and for us to look at adding it but the way the SPDX syntax and the SPDX spec is set up is that it does enable referring to any sort of custom license even those that aren't on the list and this is done using what on in the SPDX community we refer to as license refs because that license ref prefix was really from the beginning intended as a way to designate your own custom license and to be able to create your own identifier so that in the context of an SPDX SBOM or even in source code even in those short form IDs and source code for you to be able to define a custom identifier and the text that goes along with that and refer to that in the same way that you refer to the SPDX identifiers. And so there are a couple links in here that give some more information about how you actually implement this if you're looking to communicate license information about a license that's not on the list and particularly one that if you're wanting to use the SPDX syntax for something that is a proprietary license, is a ULA is something that's never actually going to end up on the main license list you can still kind of use existing SPDX processes to still communicate that in a compatible way. Yeah. Historically. Oh, thank you. Great. So if I've created a sort of a hybrid license that might be multiple combinations of you know I want more constraints covered I want it to be more restrictive for my developers and I apply to have it added and it gets added and it means that it's public now so anybody who gets my product can actually see that that's the license that being used and they could actually track down some of the constraints for example through the license. So if a license is added to the SPDX license list so there's just the single list and it's publicly available in the different formats that I mentioned before so if something is added to that list then the identifier that's assigned to it anyone can use that and that'll correspond to the text of that license. For something that is kind of a custom one-off that's being developed by a particular company for their particular product or something that's likely not gonna meet the SPDX inclusion guidelines or inclusion principles to add to the license list but you can still kind of without ever coming and talking to anyone at SPDX you can go and use this license ref format to refer to that license text in SPDX S-bombs or in the short form IDs in your own company source code or kind of use it as that same machine readable way of talking about license information. So it's basically a mechanism that you can use to make your own custom licenses without ever talking to anyone at the SPDX project about it. I mentioned the matching guidelines and I apologize because I realized the slides here are jumping around a little bit but I mentioned earlier the matching guidelines are one part of the broader kind of license list and what it is and how it works. The matching guidelines are a list of rules that are kind of very specific technical considerations for deciding are these two licenses the same substantive license? Because I mentioned at the beginning that from the SPDX legal team side we don't wanna get into legal interpretation like we don't wanna be in the position of telling anyone in the community like this is what this license means and if you've ever talked to a lawyer you've heard us say I'm not your lawyer and so we try to be pretty careful about that but the way that this works with the matching guidelines is that there's a handful of principles that we've landed on to say these are like you could match these two texts and treat them as the same license text and there's really no substantive difference between them and so some of those rules are very technical so some of them are just basic things you'd expect like ignore white space or treat different kinds of hyphens and dashes as the same thing and the intention here is that these would be things that you could program into a tool to have a tool apply these guidelines and do matching of license text in a meaningful way. So some of them are those sort of technical like treat these characters this way or treat these words as the same even if they're spelled differently. Others that were tied to the markup in the license text and so if you actually if you've used the license list you've probably seen where there's some sort of highlighting for some of the different sections where some of the text will show up in red if it's text that could be replaced with different variants or blue if it's text that could just be omitted and I know this is a bit hard to see from the back probably but basically the idea here is that we didn't want to have it be what's on the license list only applies this identifier only applies if it's byte for byte exactly the same as this other text. It's more useful to people to say this is the MIT license whether it says the authors or copyright holders or whether it gives somebody's name here like we don't want to have 50 different variants of the MIT text every time somebody puts their name in in place of the authors or copyright holders. So the markup that's on the website and I'll show this a bit further on the highlighting on the website in the different colors reflects the markup in the XML files where the legal team does these sort of identify things as replaceable or omittable text. And I meant, so I was just mentioning the legal team so the SPDX legal team are the ones who maintain the license list. It's a group of some lawyers, some developers some people who wear both hats that meet twice a month to work through the issues in the pull requests on GitHub all of the development is done publicly through those meetings or through the discussions on the issues there's also the mailing list where some conversations are had about typically about broader sorts of topics but the main, excuse me, the main thing that the legal team does is maintain the license list review new licenses as they come in or adjust the markup to existing licenses when new requests come in. We also do a lot of work with the SPDX tech team on matters in the SPDX spec that overlap between having technically and legal or licensing considerations, so. But this is open to anyone to participate in. And so the way that when a new request comes in to add a license to the list, it can either be an issue added to the GitHub repo or there's an online submission tool where people who may not be as partly because we work with a lot of lawyers some of who don't know GitHub, we've tried to add some tooling to make it easier to add a license or to request to have a license added. And when one of those requests come in the SPDX legal team and the broader community reviews it, really with like two steps, the first one being, all right, we'll decide whether or not this should be added as a new entry on the license list. And then if yes, if it should be, then we'll create the pull request and we'll add it. And the first step of that, the deciding whether it should go to the list, this is where the kind of the benchmark for that is the license inclusion principles. And these are also in the XML repo, you can take a look, it breaks, there's a set of definitive factors that have to be met and then there's a set of other factors that are a kind of judgment call, totality of the circumstances, use our judgment to decide whether or not this issue, it meets enough of those other factors that it warrants being added. In the definitive factors, that's a pretty small number of things but they're basically things like, it has to be a unique license, it can't be something that's already on the license list. It can't be in the middle of being drafted, it needs to actually have a stable text that this is the license we're talking about. And then also if it's anything that is added to the OSI, the open source initiative, anything that they add to their list of OSI approved licenses, by default, we will add that in SPDX as well. But it's a fairly small number of definitive factors, the other factors are really where it gets into more of a judgment call and that's where we look at kind of the, putting the big pot things like, in our judgment, does it meet the open source definition or if we're talking something like an open hardware license, does it meet the open source hardware definition? Just different standards that have been put out there by other communities, in our community judgment, do we think it meets one of those standards? Looking at things like, is it a license that was drafted just for one particular project or one particular company or is it something that was really drafted, intended as a template for lots of folks to use? If it's latter, it's probably more likely, more appropriate to add it to the list. So different factors like that that we look at, how broadly is it used in the community? Is it something that somebody just drafted for fun yesterday and it's used by one project with two stars on GitHub or is it something that actually has a number of third parties that are actually using it so that you're likely to encounter it in the wild? Those sorts of things. So we hold it up against that benchmark, use our judgment and have discussions in the repo to decide, does it meet those principles and if the answer is yes, then we move to adding it. And this is where, I mentioned a bit earlier, but in the license list XML repo, for each license on the list, there's one XML file that has that templating and the metadata and then there's a corresponding test text file, which is used by the CI system to do validation against the XML file, make sure that it matches the way that it's expected to and that the formatting is correct and everything. And in the past, the legal team has done a lot of the creating the XML files for this. I think we're doing more, more looking to the community and to folks who are coming in, submitting requests to new licenses, we're starting to do more looking to them to help with the creating the XML files, but this is gonna be illegible from the back, so. But if you look in the slides later, if you go and look at the repo itself, basically, if you look at one of the XML files and MIT is a good example, if you look at the XML file on the repo for the MIT license and then hold it up against the MIT license on the website, you can see the different XML tags that are used for the ways that optional text or replaceable text is formatted in ways that that's reflected in both places. Yeah, so that is the basics of what we do and how we maintain the license list. For people who are interested, we are always happy to get new involvement. We have a number of folks who show up to the twice a month meetings. Again, some of whom are lawyers, some of whom are developers. There's no real requirements to start participating, but I think for someone who wanted to show up and start getting involved, I think first, I'd probably recommend reading up a bit on what we do, some of which I've touched on in the talk, but understanding a bit about the background and the context, it's worth taking a look in particular at the license inclusion principles just to understand, because that informs a lot of how we decide what's in scope and what's out of scope, and sort of reflects the decisions that have been made by the community in the past to get to where it is now, and really to understand kind of how and why things are, licenses are added to the list or decided not to be added to the list, but then, yeah, if you decide you want to participate, we're happy to have you. You can do that by attending the meetings, or even if you can't make the meetings just by starting to review submissions that show up on GitHub, like any other open source project. You can go look at issue threads, comment on your thoughts on whether or not a request looks like it meets the license inclusion principles, even if you're not a lawyer, you can do that. We have several folks who are not attorneys at all and who participate in that process. And then, you know, moving from there, if it's decided a license is appropriate to add, then also always looking for help to draft pull requests to add new licenses. So, yeah, so, you know, we hope that the license list is something that's useful to companies and to projects in their own operations, but like any other open source project, it's kind of as good as the contributors who show up and participate. So, we're always looking for more involvement from folks who are interested. So, that's pretty much what I've got. So, we've got some time, so we can definitely take some questions. Yeah, go for it. Hi there. I have a question regarding the license identifiers, the source code based ones. Can you say a few words about adoption of those and if there's like, based on your experience, how is that going? Are there activities ongoing to kind of kindly push this out into the world? Because it's really useful. It's not as erroneous as the typical license scanning guesswork that's happening or that needs to be done by many tools. So, the more we would have of this, the better for everybody but I don't know how well the adoption is if the SPDX team tries to actively drive this into the world. Yeah, yeah, great question. It's something that one of the interesting things about is it's using those tags and even that format of tags is not something the SPDX project came up with. Like it actually emerged from, I think UBoot may have been the first project in 2012 or so that started using them with that SPDX license identifier tag. And so, it's really been something that has been kind of grow organically and that we've started recommending because it was useful there and we've seen an uptick of other projects taking it. So, as far as adoption, I don't have hard numbers on how many projects or whatever have adopted them. I know that the Linux kernel has been largely adopting them throughout their source code. I'm aware of a large number of significant other projects that have been using them but it's something that I think that there are, there are efforts both within SPDX and other organizations like FSFE and the reuse initiative in particular, leverage that and recommend that format for projects that wanna communicate their licensing in a clear way. So, within SPDX, the outreach, the SPDX outreach team does a lot of the thinking about better ways to communicate details and I think this is something that can be a big, yeah, that I hope they're also looking at. Yeah, sorry, just. Hi, well, first of all, thank you so much for the great talk. I had a question, because in the hospital world, there are a lot of people indeed that are using SPDX and I was wondering if, are there any training course or yeah, or some kind of course on SPDX licensing, license list, like some practical implementation that people can, you know, have hands on this? Yeah, so as far as training courses, training materials, I think there's two things I would point people to. So one is the Linux Foundation has a free training course which is, I'm blanking on the specific name, but it's basically licensing basics for software developers. So it gives a bit of background on copyright patent sort of concepts, just like the basics of IP and how it works and how licensing works. But it gets into some of the weeds on the specifics of what are recommendations for how to reflect licensing information in source code. So it gets into some details about that exactly the sort of thing, like what is the license list? How do you use these identifiers in source code? So that's a place that I would point people. The other thing that, let me see if I can, on the SPDX site, there is a, we'll see if this comes up. Yeah, so there is, thought that was gonna come up, there we go. So just spdx.dev slash IDs is a, not showing up on there, just realized. Okay, spdx.dev slash IDs is a page on the SPDX site that has a pretty straightforward description of how to use the identifiers. And it talks a bit about some of the details of the license list also. So it's linked there. I thought it was gonna pop up on the screen, but it's not. So that is a page that I would suggest folks take a look at. Okay, thank you. Sure. Yeah. Copyrights, you brought that up in the EU. So if I'm a development team in a company, and I'm gonna use the SPDX tag that you talked about in my source, you're using XML tags inside the actual source. So it's saying any copyright, any name, right? So if you go back to the templates page, a few back. And there's definitely companies that want to put their date and their names in there. And then there's, yeah, Linus has it. Oh, you're talking about the actual template for the license. Yeah, but this is a good example. So the GPL20 has tags for the copyright. And in this example, you've got the copyright and the dates and the user there. Is that sort of the recommended way to do it? Because I know with Germany, especially, but a lot of the EU is really pushing hard on the copyrights to make sure that you show all of that when you provide an S-Bomb. So from the SPDX licensing perspective, what I would say is that the use of the tags there, the using this or that identifier is really meant, like that is, I would think of that as a separate thing from the copyright notice, from the copyright notice that says a year, years or a range of years or a particular person or company that owns the copyright. I would think of those as two separate things. One is communicating information about copyright holders and the other is communicating what license applies to this file. But it's in the license though, right? Right, so then in the license itself, let me see if I can, so like for the MIT license, what part of the matching guidelines that I mentioned before is that copyright notices are essentially ignored for matching purposes. So when you see, for most of the licenses on there, when you look at the copyright notice on the license list, you'll see it as highlighted as that replaceable text with the idea that it could be whatever sort of copyright notice could go there or nothing at all might go there and you would still treat it as a match to the MIT license for these purposes. So as far as like recommendations for a particular format of a copyright notice or where it should be placed, that sort of thing, I think that's something that's probably outside the scope of what SPDX as a project would have recommendations for what to put. Because there are pretty broad, you'll get, this is another thing, you'll get different answers from different lawyers. It gets back to your company, the legal team at your company, what they're gonna recommend to, right? Because they're gonna want to. Exactly, yeah, they'll have their, each company will have their preferred way of this is how you should, how you shalt put our copyright notice on things. Gary, I saw, had your hand. Can I add to that, you might look at the reuse site, FSFE Reuse does have some recommendations for copyright notices from that organization. So it's not SPDX, but we do work closely with them and they do use the license identifiers in a lot of our syntax, which is quite nice actually. Yeah, thank you. I'd forgotten, yeah, reuse has their recommendations for that and that's something that we do. Was there a, was there a hand? Yeah. Where at work we have a CI job that checks for these headers. And I'm, you know, waiting all this time for my CI and then I see that. And then we also have locally like a script that will inject them based on the different source file. I'm wondering, and I just Googled it while I was waiting, but there might be something third party, but something like a VS code plugin that could look at your license file and does this injection so that like people start to adopt this. That's it. So are you saying, so something that'll look at your repo and say these files didn't have a tag, didn't have an SPDX license ID tag in the source code and so adds them to where they're missing, is that right? Yeah, like I'm not, you know, I don't know too much about VS code, but you can say things like for go source files always enable this plugin to put that as the first line. Yeah. Just an idea I'm having out loud. No, it's a great thought and there might be tools out there that do that already. I don't actually know offhand. I think it's something that I'm sure someone has looked at doing that. I think the thing that someone would need to keep in mind for that would be, I think, two things. One being that, yeah, I mean, so obviously some files are not gonna be plain text files so you would care about, you know, is this a binary files and image files? Like adding it to the right sort of files where you can't actually add that, you know, JSON files are particularly annoying because they don't have a comment format, so kind of how you add this is tricky, but the other thing for sort of automated adding of it is that you're not always gonna have the same identifier for every file in a repo. So particularly if you've pulled in code from a third-party source, that might be under a different license and added it to your own repo, you might have that, the license for that particular file might be different, you might have a different notice for that than you would have for something that you wrote from scratch. So it's just not to say that you couldn't do that but it's just something that might require a bit more thought beyond just always put this notice in every place. You mentioned this a little bit, but we're going on to extend this for data and especially we see combinations of data and code together, which makes it even more interesting. So for open data, there are a number of licenses that are on the license, excuse me, that are on the license list now that are primarily intended for use with data. So for instance, the community data license agreements that the LF put out a few years ago, the open database license I know is on there and also the whole family of Creative Commons licenses that, several of which commonly get used for open data. Others could be added, but those are licenses that could be used in combination or with source code licenses or other ways. I think we're close to time, but Mark, if you've got another question. But just to speak to that, not a question, but just to speak to that, it is entirely unsurprising now to find SPDX license identifier tags and the comments sections of PingFiles, SVG files, gives video media in general. It shows up there. Yeah, so we've tried to keep it flexible enough that it can meet other use cases while still being kind of limited enough that it is useful and doesn't spiral out of control. So I think we're right at time. So thank you all, really appreciate the questions. Thank you.