 Hey everybody, I am Matthew Miller, the Fedora Project Leader, and this is a Fedora Council video meeting. So in Fedora, we try not to drive all of our business through meetings because meetings are terrible, but it turns out you actually need meetings to make things work. So as a compromise, we do meetings. Oh, yeah, that's how that works. Most of the meetings are actually chat based. They're on our matrix chat every week or so. But once a month, we do a video call to do kind of a high bandwidth conversation about something interesting going on in the project, hopefully something that's going well, not something that's going wrong, something somebody has done or is doing, and I have a conversation about that and show something off. So today, we are talking about licensing, which is an important topic for Fedora since everything is all open source in our project, free and open source software. We kind of need to know how it's licensed to keep track of that. And so we recently went through a big change in how we do that. So we have David Cantrell, who is a member of the Fedora Council, but also worked a lot on this, Miroslav Tsuchi and Jelaine Lovejoy and Richard Fontana here to talk about this with, I guess, David says, a tag team sort of presentation. So with that, I will turn it over to you. Do you want us to, people with questions to jump in during the presentation, or would you like us to let you do your dog and pony show? Yes. So the slides probably won't take that long. I would prefer if we can get through these slides and then do a larger Q&A at the end. Another reason I ask for that is I have to drop exactly at 11 because I have another meeting. So if we can do that, if everyone's cool with that. That sounds good to me. Okay. All right. Now let me present the window here. Okay. Yep. Looking good. Okay. Okay. This is Fedora's adoption of SPDX license and expressions. Sorry. Yes. This is a very interesting topic. There's a lot to it. It sounds really simple, but let's get into it. First off, who are we? I'm not going to go in this order. I'm going to call on people. So as Matthew said, I'm David Cantrell. I work on the software management team. So I work on RPM and DNF and things adjacent to that. I'm a member of Fesco and on the Fedora council. Jolene? Hi. I'm Jolene Lovejoy. I'm a product council at Red Hat. I've also worked on the SPDX legal team pretty much since the beginning of SPDX and kind of always kept an eye on what Fedora was doing since the Fedora license list was a big influence for SPDX at the very beginning especially. And I've worked on other sort of open source legal type community issues over my career. Miroslav? My name is Miroslav Sukhi, I'm manager in packet and CPT team where we try to eat package maintenance and as a side job slash volunteering I'm a package maintainer of few packages in Fedora and related to this change maintainer of federal license data package in Fedora and license validate package. And Richard? Hi. I'm Richard Fontana. I'm a lawyer at Red Hat. I am on what's now called the technology and open source legal team and I've done work mainly around open source legal issues for a long time now, been at Red Hat for a long time, actually have worked, provided advice around Fedora related legal issues actually even before I got to Red Hat, which is an interesting fun fact, so I got to Red Hat in 2008. But that's me. Okay. Thank you. And I, before we keep going, I just want to point out that this, to me, this project we've been working on this for a couple of years now and it is a successful community project in Fedora that involves not just engineering but also people from Red Hat legal and I think this is a first for Fedora to have this level of involvement. I think it's worked out really well. So with that, I mentioned SPDX. So I want to ask Jolaine to kind of give us a little bit of information about SPDX. Yeah. So hopefully most of you have heard of SPDX before, but if you haven't or if you're not entirely sure what it is, it stands for the Software Package Data Exchange. Obviously, SPDX is what we usually go by and it's basically an open standard for communicating software build material information, including license information, which is of course what we're talking about here, as well as other information. So think about it as like a language, right? In the software supply chain, people often want to know what the software is made of and they ask for that in various forms and having various forms in your supply chain is not a very efficient thing. So SPDX was created the idea of like, let's communicate this information in a standard way and define that and that'll make everything more efficient. Now, you may have heard about software build materials a lot in the news the last couple of years, especially since the US government is now requiring them. However, this is not new, SPDX has been around since 2010. So been asking for this information since then, it's just gotten a lot more headlines, I guess you'd say in the last couple of years. SPDX, the specification, just a little side note, it's quite lengthy document with a lot of information in it and there's a 3.0 coming out, which will be a bit more modular to accommodate sort of different use cases by way of profiles. So for example, if you're interested in provenance but you don't care so much about licensing or so forth and so on. It became a standard, an ISO standard in September 2021, but the thing that we sort of care about most here is a sort of a subset of the bigger project and that is the SPDX license list, which is not simply a list as I always say, although that's what everybody thinks of it and obviously that's what it's called. But there are, if you go to the website, there's a list of licenses and you see the names and most importantly the license IDs, but the sort of work around that to make that a reliable way to identify the licenses and exceptions is that there's also some standards of how and guidelines of how things get added and there's matching guidelines to make sure that one ID truly represents an identified amount of text and we don't have two things called the same thing for, you know, or two things called different things that are the same vice versa. And so, yeah, so the SPDX license list is often used even if someone doesn't use the SBX specification, which is sort of what we're doing here. And just as a side note, there's been a long history of involvement with Fedora and SBX. I kind of looked back at the history in the course of this and Tom Callaway was involved in the early days and, you know, we were looking at the good and bad list and how things were tracked at Fedora and then in 2014, around that time, SBX legal team reviewed all of the, well, all of the software Fedora good licenses and added many of them to the SBX license list. I think this is notable because we added about 80 licenses at that time list, which is the biggest addition ever in one rev of the license list. And just last, last release of the SBX license list, I think we added about 40. Most of those were because of Fedora's adoption of SBX IDs. I don't think there's been another, like, you know, addition of that many licenses in the entire history of the SBX license list that's met that. So Fedora has been an amazing contributor to the SBX license list, which is really contributing to the bigger, you know, ecosystem, if you want to call it that, of being able to identify licenses and track them. All right. Thank you. So I'm a package maintainer, Miroslav is a package maintainer of Fedora, and I'm pretty sure that we already have license information on the packages. So I, like, why are we doing this? Richard, can you tell me why we're doing this? Well, yeah, I think we probably all have somewhat different perspectives on this. Like, for me, SBX expressions, so not just the identifiers that are in the SBX license list, but the sort of larger system of SBX expressions, which are, as Elaine said, a language which you can use for representing any sort of license information. This enables, the advantage that I see is it enables a kind of well-defined highly precise way of describing the licenses that apply to the various parts of a package. And that in itself, like, that degree of accuracy and completeness of information is sort of, to me, inherently valuable. Because otherwise, you know, you either have kind of inaccurate information or information that is like sort of too fuzzy and, you know, isn't going to mean the same thing from package to package, different conventions from package to package. SBX provides a way to have a uniform way of describing in a very precise way the licenses that apply to all the packages and products. So if you think that license description is valuable at all and we do, SBX is really the best system that we have right now for doing that. I would just add, I think, you know, the sort of stating the obvious, the reason this is important obviously is if, you know, we want to be able to reuse code and collaborate and open source license enable that, right? So the license, you know, does matter. I know sometimes developers might think otherwise, but that's what kind of helps create the framework for all the things we do, especially in Fedora. And one thing that, you know, Richard and I have debated sort of, is this important to Fedora package maintainers or Fedora contributors or not? But it's something I think that you should be aware of is if you aren't, you know, if you're creating open source software and you're not clear about your license, you know, you don't make it sort of easy for someone to know what that license is. It creates a lot of churn downstream because people who are redistributing, especially if it's in products, are going to, they really want, you know, they want to make sure they know what licenses they are dealing with. And so there's a lot of time spent and energy on sort of unraveling license information. And so, you know, I think there's almost a whole business around that. I think it's a better use of time to just let's make it the information better upstream. And then there's less time spent downstream instead of everybody redoing that work downstream. So I think it is important. It just makes it easier for everybody. However, they're using the code once it's created. Okay. Well, this is good because like as an engineer, I definitely like things to be correct and accurate. If I'm telling someone that something that I am offering them is open source or free software or both, I definitely want to know that they understand that and that the licensing information is correct. So this is good. Fedora has an opportunity to participate in this existing standard as a community member. And we get to sort of ensure that everything that we have in Fedora is represented correctly or advertises the correct licensing information. But also as a package maintainer, naturally we get a little bit of pushback. We have a well-established system that, well, I used the term established loosely because it was mostly the work of Tom Calloway and there wasn't a clear process to get information on there. So basically, you know, have a discussion with whoever wanted to have the discussion and then agree on a short name. And the objectives seem to be focused around what short abbreviation were we going to give the license. Not really are these the same thing? Are they different licenses? Are they actually things we can ship? It was focused more on the technical aspect. And we had no clear owner of this data. And it was duplicated in multiple places. We just, you know, we had grown past what it could provide us. So with all that, what have we done? All right. Here's the big reveal. It's text surprise. So we have Fedora legal resources documentation on docs.fedora.doraproject.org. This was lacking, missing. It was inconsistent. We have clear processes for everything now. And it's on GitLab. So if you see mistakes or you want to add something or information about a tool, please send a merge request. Fedora license data. This is what used to be those big license lists on the Fedora Wiki. We now have this managed as a project in GitLab. And it releases as a package. So the package is installed so our tools can read it. But it also gets published to the docs site, which is quite nice. I'll kind of go clockwise here. Contributions to SPDX. As we review packages and licenses here, we are contributing new licenses or changes to matching rules back to SPDX. Fedora has a lot of software, a lot of open source software, a lot of free software. There are changes that we can contribute back. And that's been going well. And it's nice to see that happening. And then the big part of this project is obviously the migration to the expressions in the spec files. This is obviously complicated and we've broken it down into a number of different phases. I just want to add, I think, just as a sort of a timeline and when I joined Red Hat in February of 2021, I think the discussion about moving the data off the Wiki had was already, you know, had predated sort of me. And of course, I had been talking to Tom and Richard for over a decade. I think we figured out about Fedora adopting SPDX expressions. I think the focus was on sort of those two buckets and across from each other on the slide. The documentation piece, I think, you know, we realized that the Wiki is getting old and everything should be moved to docs. And so that turned out to be a much bigger project than, you know, we didn't really count in the beginning and then, you know, sort of its own project to sort of revise and update all of that. So I think all of this, you know, is a bit more work than we anticipated. You think, oh, we'll just like, you know, just switch to SPDX identifiers, like how hard stuff to get lobbed at repo. And then I would just add from the SPDX perspective, I mean, besides I mentioned all those new licenses that were added, you know, I know Richard in times and others have said, you know, well, the SPDX license list is not, there's not enough licenses on there. It doesn't reflect, you know, say what's in an entire Linux distro. I mean, Linux kernel adopted SPDX IDs and so that, you know, definitely added. But it's as long as anyone, you know, there's as many licenses on it as people ask for there to be. So, I mean, other than when the SPDX legal went out and of course the initial release and then later went and tried to pull stuff off of Fedora. I mean, we sort of wait for someone to submit stuff. So I think that Fedora is adopting SBX IDs is having this really great, you know, and sometimes challenging knockdown effect on SPDX and therefore like a much wider range of people and community and influence, you know, beyond this Fedora community, which is I think a great thing about open source, right? And, you know, that's forced SPDX to kind of look at some of our processes and make it a little more efficient, hopefully, and, you know, that work will continue. Yeah. I would just want to emphasize also that this is kind of a, this is a project that's larger than just the SPDX piece of it. We've been improving, so we've been improving all the legal documentation by kind of creating this new documentation. We're making it sort of clearer and updating it and kind of rationalizing it. So there were certain contradictions in the way things were laid out in the Wiki in terms of documentation around not just like license names, but all sorts of other related Fedora legal issues. Also, the use of GitLab just by itself has enabled a kind of collaborativeness and transparency, a sort of way of working that is, I think, much better than, you know, the past approach of, you know, kind of having a mailing list and then kind of having some back channel email discussions between me and Tom Calloway. This is a much improved approach, I think, to just kind of getting this kind of work done. Yeah, that's a good point. It's really nice because people can see how the stuff plays out, how the process works, and they can get involved that way. I think, you know, just to build off of Richard's point about the documentation, I mean, I don't know if it's happening yet, but I think it's very foreseeable that that articulation of the license standards for Fedora and all of the information in that documentation could be reasonable for other projects, so it would be interesting to see if people follow from that. So, with all that, and that large overview, we did it, we're done, everything's finished. Well, the easy part was, so now we actually get to the business end of what we're doing, and that's going back to the migration here. So this is the part where we've been planning some HackFest. We will be sending out notices about that, but what we have found and what we've agreed on approach-wise is there's a subset of packages where the license identifier that's in there is simple. Maybe it's just GPL V2 plus the old Fedora license, and the software is well understood. It's something major and we know what it is. So there's some things like that that we can generate an SPDX expression for, but really what this comes down to, and to get this information really correct, is manual inspection of source code, either by a scanning tool or reading it or something like that. And that is a thing that we need to incorporate into the general package maintenance process, the new package process, but we do understand that this is kind of new. It's a change from how we have done things. So that's why we want to do these HackFest days to show people kind of the process that you can use to go through this. Now, revised policy here, Richard, I wanted you to touch on these two main objectives here for package maintainers here. Yeah, so this is not conceptually new. This is the same thing that we did in the past before we were using SPDX Expressions to represent licenses, but this is kind of how we are using SPDX Expressions now. So there are two parts of this. First, as we encounter new licenses in Fedora packages, that's, you know, source code of Fedora packages. You know, if they're not already on our in Fedora license data and already classified, we undergo a review based on GitLab issues and determine, you know, did they, did they fit into one of our approval categories or are they, are we going to treat them as disallowed. And in some cases, we actually have licenses that are disallowed, but we grant certain limited exceptions to their use. And the way we kind of conceptualize what a license is in that phase is really from the start, sort of, we may not have an SPDX expression because there may not be an identifier yet to represent it. But we're always thinking, how would this fit in with the SPDX model of what a license is? And that's one piece of it. And then if something is approved, then the normal process is, or some exceptions is to kind of submit an issue to the SPDX project to add the license as a license identifier to the SPDX license. So that's, that's one part. And then the other part is once you do have an SPDX expression, you know, we have this practice in Fedora of representing license metadata. In RPM spec files. And so we created some updated documentation about this, but, you know, in addition to, you know, the fact that we're now using SPDX expressions in the license field in the spec file, we also have kind of clear documentation on how you sort of figure out what that representation should be. And so the, the sort of summary of the rule we have, which is, which is not different from the past rule under the Tom Callaway system, really, but it's more clearly sort of set out is that that the license field is supposed to be a simple enumeration of all the licenses covering code and content and, you know, anything that's in the binary RPMs that are shipped by Fedora. So there, there are going to be some packages that will have some material covered by a license, a particular license in, in the source code, where that particular license won't be represented in the license field. That's just because of this policy we have that Fedora has as far as I know had for at least 15 years of attempting to only have the license field represent what's in a given binary RPM. So that's the two pieces of how we are using SPDX expressions in this, you know, new system. Yes, thank you. So that that's the thing that I keep trying to communicate consistently to package maintainers is that the expression that you're generating is for code and content in the binary RPMs. Yes, that has been sort of an understood policy, but I don't remember where it was written down and I know that some people thought otherwise and would add other licenses to the license tag. So this is important when we have maintainers using scanning tools, because it's going to pick up, for example, auto conf and auto make template files which are littered with GPL boilerplate but that stuff for building the software that doesn't actually ship in the binary RPM in some instances. So we just need to work with package maintainers so they understand, you know, how to look at the scanning tool output and things like that. So, there's a lot of work ahead of us and Miroslav has been posting progress reports for us and sort of giving us an idea of where we stand so Miroslav. So I tried to send every two weeks to further our development in this legal mailing list status where we are. I create a burned out chart out of this data, which can give us some estimate where when we are going to be finished. Because we are at early stage it always go one month left one month right so this it oscillate around the summer 2024 right now and we are right now in 34% and done so two thirds are ahead of us. It's like how many 20,000 less than 20,000 packages and yeah we need the help of other people like we can't do that manually. Like if our team like David, Richard and Gillade would work on that solely alone that would probably 20 years estimated time. So we need the help of the maintainers and I'm sending these reports in a silly hope that other maintainers reading these statistics will like say, okay I see this mail with SPD statistics for 25 times already so maybe I can read it and usually at the bottom there's something so what you can do that your package appears in the done part. If you are curious there is a link for the scripts which actually check the data but it's very simple it checks the spec file changelog and then the disk it changelog. If there is SPD string and then I consider it done and then but it's followed by some heuristic whether license is valid as old and new one and based on that I do some recommendation. That's all. It's great thank you and and I wanted to add to that that I have noticed posting those those reports every two weeks I have seen package maintainers go and take that step and convert their packages on their own. You know not waiting for us to do a hack fast or or something you know that we would start so it is I think it is helping but there is a lot of work to do. So looking forward here to lane what what do we have what do we have down the road. Oh you're muted. I think so that's a great segue to how do we you know update help package maintainers update the packages more efficiently. One thing if anyone's wondering this and was talked about a lot early on was well can we just do like a. I'm going to call it a find and replace like well we have this mapping of the old ideas the new ones you know can we just sort of automate that in some way and that's not. That's not doable on scale for a number of reasons one of which is that the fedora. The four IDs had a concept of sort of category ID so like MIT was used to across a lot of different license texts and that's not how sdx works. And then there's there's there's quite a few like that that represent you know a big chunk of. The packages and so that's sort of it's impossible for those those need to be sort of manually inspected. And then there's also a lot of some of us believe that while you know sometimes package maintainers. Don't update or look at the license except the first you know the very initial. Review and you know this might be a good opportunity to sort of double check things and otherwise you know we just sort of re. Regenerating the wrong information in a new format you know that wouldn't be good so we've now if there's a change order to that's posted on the wiki. That we thought well let's maybe. Kind of do something in the interim will map some IDs that we feel reasonably confident that are sort of a one to one relationship sdx and create. Merge requests on the or issues on those so the package maintainers a chance to actually review them and sort of a little bit of another nudge in addition to mirror slobs. Every other week kind of reminder we haven't done this yet that's going to you know sort of coming later. But in the meantime we have a hackfest planned for April 26. We need to announce that still they'll focus on the LN packages that'll sort of do some training on how. David will do a demo on how to how to kind of review a package so you know and then anyone can attend and. Review their packages during the hackfest and you know we'll have people there to help out so I think that'll be great in fact goes well maybe we'll do another one. I'm going to let Richard you talk about the the PELC data I think I've already mentioned the sort of influence on sdx and impact on other. You know potential for impact on other communities which you know is to be seen. And we've been trying to improve the documentation like ongoing like as people have questions especially on the updating packages we've been you know and it's something's not clear. Richard I've been trying to just stay on top of that so it's it's not it doesn't get stale. Yeah so about the PELC data so PELC is this system you could say a sort of legacy system we have inside Red Hat for among other things it sort of makes use of license. Scanning and it sort of duplicates a lot of what this Fedora activity does it's mainly been sort of oriented towards Red Hat enterprise Linux. And we have this goal you know of kind of taking the license approval and disapproval data we've been kind of developing internally through this PELC tool and kind of like merging it with the Fedora data I think as time goes on that actually is getting less and less significant because as we sort of have migrated to using sdx identifiers and having this new process, we're actually getting that extra data that was, you know, gleaned from analyzing rel internally at Red Hat through this public process we have in Fedora. So I think increasingly, it may be less important to worry about merging that that sort of data but that's still sort of a goal from the Red Hat side that we want to have. Ideally ultimately the single list we speak of a single source of truth of, you know what from Red Hat perspective are approved and unapproved licenses based on you know what Fedora policy is. And then that will then you know Red Hat will use that as the license policy across all of its, you know, portfolio of community projects and and downstream commercial product and so forth. So, so that's, that's an ongoing thing but I think it's sort of in a sense taking care of itself through the progress we've made with Fedora. All right. Thank you. Everyone can see what a simple task software licensing is. Hopefully this answered some questions. I'd like to thank everyone for joining this call I'd like to thank everyone on the Fedora SBDX team for helping with this presentation. I'm going to stop sharing my slides now and we can move to, I guess, Q&A. Oh, my voice is not working. Sorry. Yeah, thank you everybody. This was really great. I don't think I have any questions because it was so thorough. I don't know if that's better. Also, I've been following this all along. So, yes. Does anyone else have a question? I said I would hope you don't have any questions. I should be able to like, you know, ask some leading questions or something. Yeah, I should have sent you some before the call. There's one thing I want to say is, David, I think you were a little bit harsh on the older process. I think there was, it wasn't just talking about like what the short ID should be. There were a lot of interesting conversations about. Yeah, so I should clarify with that. That was not my intent. I feel like we kind of had, we had two sides to that process. And it was separate groups that didn't always necessarily know the other was talking. So from my point of view as a package maintainer, I would ask about something and then I was just waiting to be told what the short ID would be. You know, and so I didn't know what the rest of the involvement was. The process we have now moving to SPDX, everything is all tied together. You can see the whole workflow through the entire process, which I think is better, but I did not mean to be too harsh on the old system. Yeah, in the old system we actually had, as far as I was involved in it, going back to 2008, actually 2007, before I was at Red Hat. Tom Calloway was exploring like, you know, issues of boss license policy at an extremely deep and intricate level and I got involved in that. And so there are all these discussions happening largely between me and Tom Calloway behind the scenes, but that was not public. And I think we're, I think we're still sort of guilty, you know, in this new system of not being as transparent about this thinking process, part of it as we could be. But I'm trying to, like in dealing with issues on GitLab, I'm trying to do a better job of kind of publicly explaining like the reasoning process. And we want to, and this is also why we have better documentation. So one thing we didn't have in the old system is any attempt to have kind of like a distilled explanation of what Fedora license policy is, for the most part. We now have a sort of a more elaborate explanation of like what is our policy around documentation license? What is our policy around bond licenses in a way that we didn't quite have before? I mean, it wasn't that bad before, but I think it's better now. And I'll just add to that. I mean, it was very really interesting, that whole process of what Richard described of looking at the documentation, updating it, because even as someone who's not like intimately involved in Fedora, but have been sort of watching and was really familiar with the list and, you know, new Tom Calloway. I, you know, I thought I was like, Oh, well, of course it's written down, like, don't we all know what it is. And so it was really interesting. I mean, I think it speaks to Tom's influence that like you kind of knew, you kind of knew what it was, the policy of what was allowed. If you watch the Fedora legal mailing list and, you know, sort of like we all got to be a little bit inside Tom's head. But you never want to have like a, you know, a single point of failure with one person holding all that in their head and everyone just assuming they know what it is. And you really need to have it documented. And I think that's a common problem in open source projects that reflected a lot on my role in SBX in the same way. We have someone who's just been involved for a long time and it takes a lot of discipline to kind of write it all down because, you know, it's like as Richard said, even he's kind of, you know, having to really think about doing that, and now that we have a more transparent process in GILAP. So I think it's a common challenge. And of course documentation is usually always like lagging, right? But, you know, it's good to refresh that and think about that again. And, you know, we've done the same thing at SBX, our documentation is not great. And when I start thinking about, okay, a package maintainer has never done, you know, double the SBX has come in and like can I point them to something that like clearly and consistently explains what the process is, you know. That's, it's always a good, good improvement. I want to also clarify for anybody watching. Tom Calloway is not dead. He's still around. We sounded like we're giving eulogies here. No, he's just went to work for Amazon and open source community stuff there and is very busy. He's still active in Fedora and maintains like 300 packages or something as well. Thank you, Matthew. Yeah, I think I was actually going to say something along those lines, but that's more extreme than I was thinking. That I think we were all a bit self conscious of like, oh gosh, you know, what's what's Tom thinking during all this, like, are we, you know, it's he like, and so unfortunately, David and I did a presentation about this whole process on early days and at all things open in Raleigh in October and Tom was there and we all went and had a beer, which was lovely and he was very supportive. And of course, you know, he was Tom, but we had a nice time chatting and joking about the whole thing. So yeah, not hating us for doing this. No, in fact, I think there were a few instances reset it. It seems like you're, you're solving a lot of long standing concerns and questions I had, you know, that we're just kind of like back burner issues, which was, which was nice. But yes, he was very supportive of everything we were doing and moving Fedora in this direction. One thing that I didn't mention in the presentation, but you'll see if you go to the legal documentation site is we we did not carry over. There was the compatibility table for GPL licenses. And yeah, Richard. And that that is a question that comes up from time to time from package maintainers because that was kind of a long established being that we had in and had in Fedora and our conversations with it have have basically been around trying to figure out where that came from, you know, where that sort of, you know, concept and maybe fear of using something licensed that wasn't GPL compatible where did it come from. And there and that led down this this whole path of, I was digging up old emails about questions about GPL, GPL v3 and v2 and things like that. And Richard, I can't remember if we ever actually conclusively found we are where this started we just sort of maybe theorized that it was around the drafting of GPL v3 and that the notion of license compatibility was a concern, but now going forward. Is that something that that we need to think about in the same way. Yeah, I mean, I don't I don't know how far back Tom Callaway was was making an attempt to to sort of notate judgments about GPL compatibility it may have actually been earlier than GPL v3. The issue is, you know, so Florian Weimer said on I think the Fedora legal list and a thread about this, you know, what would we actually do someone was saying like why'd you get rid of this information about GPL compatibility. And there's there's also just a compatibility with non GPL I think that Fedora never made any attempts to provide like documented information. And Florian said, Well, what what did Fedora ever do with this information. And I think that that's that's a fair comment. I don't think Fedora in general did use this information. I think we did sometimes like there's some things with like read line in particular I remember people being very careful about that, and making sure that you know, if he hasn't made wasn't GPL compatible you didn't link it with read line that that sort of thing. I think I at least used it used it for that kind of thing. I don't know. But I don't think we were consistent. I think that's fair to say we weren't consistent and it was like you said, like, mostly a self policing thing like we saw, we saw this chart we have to follow these rules kind of things. Yeah, I mean, the, this is actually my views on this topic were shaped in part by working on these Fedora issues that basically what we found was when license compatibility issues came up, we would always find a reason to explain why the general rule didn't apply in a given case. So the exception always canceled out the rule. And, and I think that we found that there was a big divide between sort of false community. I don't know how to describe like false community doctrine sort of like removed from practical day to day issues of software development and what what software developers, what project maintainers actually do in in in terms of like like what, what code under what licenses they introduced into their projects or what license of dependencies they use there was a big divide and this is a whole kind of big topic I've been obsessed with for for a while as Jolaine knows. But I think the picture that Fedora was giving and in kind of maintaining that information was not actually helpful because because in the typical case, we would actually determine that there was no license and compatibility problem at all. And we still say, we actually have some documentation about this now because someone raises on the Fedora legalists, we explained that this is a very confusing doctrine. But if you if you are concerned about license compatibility issue, submit a bugzilla issue and we'll look into it and I think that may have happened once since we published that. And the reason I brought that up is I wanted to reiterate on the on the license tag in the spec file is enumerating all of the license identifiers that appear in code that goes into code and content that goes into the binary RPMs. What we didn't mention in the presentation was that there's no effective license computation we don't like package maintainer should not be saying like oh well that's some BSD code and that's some GPL code that means my packages GPL they're not That's a big change. That is a big change. Well, I don't agree with the change. But but but it's a change from from the practice of a lot of package maintainers. That is that is accurate. Yes. So there was an instance. So one of the reasons why we have this rule. So I would contend that it was the old rule as I understood it. Maybe I misunderstood at least how some people were interpreting it. I think that the documentation some of the documentation expressed this as the old rule. The problem is that people package maintainers were applying it inconsistently from package to package. And so we had some people applying this effective license rule. Each person was basically interpreting the GPL on their own. And so the goal of having kind of a uniform sort of system that is going to be consistent from package to package was not being realized. Now it's one of the advantages of moving to SPDX is that you can have the potential of having a uniform standard system of license description. But if everyone is kind of interpreting like licensing in ways that sort of allow you to kind of remove certain licenses in different ways from package to package that advantage is is going to be it's going to be law. So yes. Yeah. So one of the things that's come up kind of related to that. Generally, if there was any other license whatsoever on anything that said public domain dedication or this is in the public domain, we would just ignore forever because hey that's not that doesn't matter. So now we are looking at identifying those public domain statements because each of those actually is a license or often is a license or a license the statement or something in its own way at least needs to be looked at like what what is this meant to does acting like a license. I don't know. So when you see something like that, we should bring that as a possible thing as well so that can get looked at by the people who know what they're talking about. And faces at my statements. This is another case where it's really not a change. So there was a Callaway public domain, not identify a rapid name. Maybe it wasn't used consistently from package to package just like we were just talking about. Generally, if something had was GPL with some public domain things in there, no one would bother to list GPL and public domain they would just list. Yeah, so that's that. But we have packages that do use that public domain. Kind of old name and I think what you probably said without maybe even realizing it Matthews like there's a there I've noticed in my many years of like dealing with looking at license and license type information in source files that sometimes something sort of reports to be public domain but it's really a license and so you know, because of using just a kind of a short name without really describing like rules around when it was used or you know, kind of being a little bit loose. You know, those things need to be looked at because maybe they're not really a public domain dedication. Maybe there's it's actually licensed or maybe it is now in an interesting kind of potentially come full circle. Scenario what we have been doing is we've actually been investigating those and like go look at it figure out what it is and then submit it and get lab. And we've been sort of collecting those in one text file and telling people to use a license ref license ref is an SBX specification designation for a license it's not on or license type stuff that's not on the SBX license list because there's no way the license list can accommodate everything that's found in software and the reason that we did that is and I kind of anticipated that like we don't really know how many of these these things will find and what they look like. And if we just submit them to SBX one one by one it doesn't really give a full picture of the scenario so like maybe there aren't that many or maybe there's like 100 variations that say kind of the same thing and so I wanted to say like let's just kind of do it's a little bit of a potential you know possibly a a you know interim fix that we might have to go back and change later but if we collect like all these things that look like a public domain you know a simple public domain dedication is what we kind of presume it would have been under the Callaway system and then we say hey look SBX going through you know this Linux distro fedora we found you know this line I'm actually about to send an email because now we have enough data like how should SBX deal with this because SBX has traditionally always been like a one you know one ID means one specific set of text and there needs to be identifiable text people have tried to suggest we should have a public domain tag but not define what that means and like that is super problematic. Like though our license right now is one single license ref that goes to a thought so if I find a dedication and get that added to the collected file and not need to come up with a new license each one that seems very sensible. Yeah and you know it's possible that SBX will look at that and say yeah maybe we'll adopt something like that for these and there's also some like ultra we call it we have another similar thing we're dealing with ultra permissive licenses where it's it's just like a one liner with no license conditions or anything and just again we don't know how many things like that are out there and maybe SBX will say you know we are going to create like a ironically a bit of a category ID I mean I'm not predicting the future big big big caveat disclaimer. But it's defined as meaning one of these defined things right like there's no way it's not helpful to just have some undefined thing that people have to figure out what it means right that we like. And a lot of these things are like I came across one that said this is public domain do not copyright this code. Which what does that mean I don't engineer shouldn't be writing statements like that I'm going to say it's a blanket thing because it's lawyers are bad at writing licenses. No one should write any of these things stop it everything's terrible we ended up with that piece of software just changing it to an existing very permissive license that. Yeah well. The problem is is even when you change the license that old the old versions probably exists with that other line. But I mean if the door is like going to only have the new version with a new license and like great you know. The old ones don't exist but yeah. Yeah that's a thing Fedora gets to do but yeah. Well you're at the hour here. I think David had to had to leave already. Anybody have any final thoughts or questions here. Okay, well thank you again very much this was great thank you for all this work and ongoing work and explaining it is very nice. This month we are having a Fedora Linux release rather than having one of these meetings so I think we will not have a video meetings at correct Ben. Well so we had sort of preemptively cancelled it but the release party is going to be a little later than normal. Okay. So if we might actually decide we want to do it in May and skip the June meeting so that's something for us to figure out later on. So stay tuned to discussion.floraproject.org to find out. Sounds good. All right. Goodbye everybody.