 So, yeah, hello everyone, and thank you for joining me today at this Libreplanet conference the day two. I'm excited to be here and I'm excited to tell you something about reuse. So reuse provides simple steps to declare your copyright and licenses. But first of all, let me set roughly the frame of this whole talk. So here at Libreplanet, I assume we are all aware of the benefits of free software. So I do not have to convince you about those. And no matter whether we are developers or not, we all care about all four freedoms of free software. And one of these four freedoms is the freedom to share software. But if you're a developer, you might decide and many people decide to share their software only under certain conditions. And thanks to free software, we can set different conditions. So we do this by choosing a free software license. They have different types, different settings. But yes, we clarify these conditions for use and reuse. Now, of course, if you're a developer, but perhaps also if you're a user, you want to make sure that users and especially re-users, so people that incorporate code into their own software are aware of those licenses. But also, of course, about you as a copyright holder, for instance. So in an ideal world, finding this license and copyright information should be that simple. But unfortunately, that's not the case. Let's be honest. It's often very hard and this uncertainty around this whole finding, licensing, and copyright information about a project or software often leads to confusion and to ignorance after all. Of course, we do not want to have this. So reuse could be understood as a solution to communicate this information a little bit better. But before we dive directly into these issues, let me quickly introduce myself. My name is Max Mehl. I work for the Free Software Foundation Europe as a program manager. Yes, and I'm really happy that we can be here today and have these 45 minutes. So, yes. So what are these typical issues with licensing? Especially free software licensing. So it's often the case that people lack information about the license and copyright of their own code or of third party code. What do I mean by that? A third party code is a little bit easier. Say you want to reuse someone else's code, which is completely fine if the conditions are met. You should be aware of their licensing choice, whether it's compatible, whether it's actually free software. And often, this is quite hard to find out. But it could also be your own code, right? We all remember if you was someone coded a script or something else five years ago, never touched it since then. You're not really sure like what was, is this all my own code or is it perhaps someone else's and which license did I pick? Did I ever give it to someone else? And if so, under which condition? So yeah, we have this missing information. Then if you reuse code, sorry, share code with others, those re-users may overlook your chosen licenses, either for all files because they do not have any clue about your licensing choice or for individual files. Oh, it could be that you have, for instance, images or blog files or configuration files or something else that is under a different license than your main chosen license if there's any. Which brings us to the next issue, how to deal with multiple licenses. I mean, you may be aware of some guidelines, how to set one license for a repository, but what if you have two, three, four or even more? That's quite realistic. Then we have license ambiguity. I mean, we are all aware of the GPR license, but hey, there's not only one license, GPR license. There are so many different variants, versions, expression, exceptions and so on. So there's a lot of ambiguity in this area. And now think of, if you have a bigger project, like a bigger community, you also want to have your contributors being aware of how you do licensing, like what's the license, how do you declare it to re-users and users? So you need to give them some sort of training and need to check that. And like, there are so many issues, like these have been around for ages. So in the meantime, there have been developed so many different best practices that are sometimes even conflicting. So this was the set of issues that we've seen when we in 2017 as the FSFE thought about, how can we do something about this? How can we make licensing and copyright easier for everyone? And by everyone, I mean not only humans, but also machines. There are so many cool tools that help you with licensing and that are used at larger re-users or somewhere else. So we also want to make it easier for machines, but of course also for humans. So these are a lot of challenges in there, right? And what we came up with is reuse basically and the principles of reuse. So this is a short summary of what we thought back then would be great to have. So a great goal or one of the big goals is that we want to make it easy to find copyright and licensing information for every single file in the repository. And by every single file, I really mean that. No matter if it rather it's a 50,000 lines of code source code file, or whether it's an image or whether it's a configuration file, it should be easy to find out the licensing and copyright for this file. But we also want to avoid silos. So silos, we often see that in the corporate area where you have some databases or some cloud services where there's information stored about different software projects. But this is not really good because this might also be conflicting and you have to find it somewhere. So in the ideal world, this information about copyright and licensing would be stored directly inside of the repository. And not in a version control system which might be migrated or break broken or something else, but really as plain text, ideally. We want to have this information readable by humans and machines. I told you that. And we want to be compatible with other initiatives with other best practices as far as possible. So in the end, we do not want to reinvent the wheel. But the most important point for me was back then to make licensing easy and fun for developers. Easy and fun again, if it was ever fun, let's be honest, but more easy, more fun for developers, no matter the project size. So whether it's your 10 files hobbyist project or whether it's a 100,000 files project like the Linux kernel or something else, we use should be applicable for all of these projects. And so basically, since it should be simple, we boil it down to three steps. And these may sound a little bit like naive to you, but you will see that these three steps actually suffers to reach all these sort of suit all these principles. So the first point is on the first step is to choose and provide licenses. That may sound easy, but it's a really important choice. You will know that you should choose a license that matches your expectations, your conditions. And there are a lot of free software licenses and you should make a really knowledgeable choice. And as soon as you chose the license or even the licenses, if you want to apply multiple licenses, you have to provide them. And we will see later how to do this. The second step is probably the most complicated and the work intensive, which is to add copyright and licensing information to each file in the repository. And the third step again is quite simple. You are asked to confirm we use compliance. Now we'll look a little bit into these three steps. So the first step again is to choose and provide licenses. So pick a license or multiple licenses. So as I said, it could well be that you have for your source code, you have a GPL version of three license, but for the images that you created, you may have some Creative Commons license. That's completely fine. And you've got to save these license texts inside of the licenses directory. So this licenses directory is a novelty that we use introduced actually, because as I said before, what to do if you have multiple licenses? There are different techniques how to do that, like people traditionally have, if they only had one license, they had a license text file at the root of their repository or copying file. But yeah, this got quite complex if you had multiple licenses. So our solution is to provide a licenses directory. Every license text file is stored in. And these, to make it even easier, are named after their SPDX license identifier. So products cursors, what is SPDX? SPDX is nowadays a project by the Linux Foundation, but I started with something really simple. They wanted to provide a unique identifier for every free software license, because as I said, there are many different variants, for instance, of the GPL license, GPL two, GPL three, and then the different things do you only apply it to like, do you only say, well, this is GPL two and not any later version, or do you say GPL two and any later version? Do you also have some exceptions? Well, this is so complex and this created so much confusion because well, people just wrote it somewhat, some way into their README files or at the commentators in the source code files. And so SPDX provides these unique identifiers for every license that is out there. So in this example, we say, well, we choose here the GPL 3.0 or any later version. And so you store the license text inside of the licenses directory as you see below. Then the second step is the most interesting one. You're asked to add information about copyright and licensing as a comment in the file header. So most source code format support comments. And for the license, we say that you should use the SPDX license identifier tag. So this is a string, how tools, but also humans can find out which SPDX license identifier actually applies. So in the example below, we see that here we say this example file has the GPL 3.0 or later license. For copyright, there are many variants. We suggest to use the SPDX file copyright text. That's a tag also as you see by the SPDX project. We use this because it's quite simple to find for tools, but also for machines. But of course, you can also stick to more traditional copyright lines like we see also in the last line. So with a copyright symbol or some other variants. So we use doesn't mandate anything in this regard. You can use any, but yeah. So in this example, this file as a comment header defines that the file is under GPL 3.0 and has two copyright holders. But now what to do if you have files that do not support comment headers or comments at all, like a JSON file or a picture or something else. We have two alternatives. I would say the most preferred alternative as a separate dot license file. So in this example below, we have an image with the name cat.jpeg. And now you're asked to create a text file called cat.jpeg.license. So this is plain text file where you're at the same information as we've seen before. This time it's a different license and a different copyright holder, but otherwise it's fine. But now there may be cases where you have a lot of binary files, like let's say a directory full of icons for your application, 500 icon files that are binary and cannot be commented. Of course, now the first alternative would mandate you to create 500 additional files, like for every single file is separate dot license file. Of course, that may not be the best solution. Now we offer a depth five file for bulk information. That five is a format introduced by the Debian project that we used here. And so there's one right now, one file called depth five inside of a specified directory where you can define directories and multiple directors with different patterns to communicate copyright and licensing for these files. So in the example below we say, every single file in the IMG images directory should be under the copyright holder, create artist and the license CC by 4.0. It's a little bit of different syntax than the rest of reuse. We are currently planning to make that a little bit more reuse style and more flexible, but I will perhaps come to that later. So with this, we can make sure or we have all options to define copyright and license for every single file in a repository. And as I said, also a configuration files and something else because we want to have this unambiguous and easy to find. And the last step is really simple. You're invited to install for instance, the reuse helper tool to check for missing information. So it's a quite lightweight Python script of course, free software can check out, and also contribute. And the simplest command is to run the reuse lint and it will call through the whole repository, tries to find copyright and licensing information according to the reuse best practices. And in this example, it tells us, well, everything is fine, you're compliant with a specification, really good. So to wrap this all up, what are the reuse specialties? What is new or what is different? So as I said, the first novelty is that restore license text files in the licenses directory. We thought about this because people complained, they wanted to use or continue with a more traditional license or copying file, only one file or writing this in the README file. Well, after a few experiments and also other specifications that did differently, we said, well, the easiest really is to have this separate directory. It's unambiguous, it's easy to find for machines and for humans. And well, it just makes sense to store this in the separate directory. A second thing is that I said again, we want to have information about copyright and licensing for every single file. And ideally as a commentator, because that would be as close to the actual file as possible, but also with alternatives. So that may sound a little bit, I would say really strong or a little bit pedantic, but it makes sense because otherwise authors just define for themselves, well, for this file, I don't need a copyright or a license, but perhaps there should be a license for this and people want to find out what licenses apply to repository. So that's why we are really strict here. And also these alternatives for uncommentable files, this is also a novelty and I would say they make sense. And yes, again, we have this unambiguous copyright and licensing information. That's, I would say, is the biggest plus of reuse. Over the course of the years, as I said to you, we started in 2017 with this project. We created different components, I would say. So nowadays I would say we have four components, roughly. So the first and foremost component is the best practices. So we wrote reuse as a specification, quite formal specification. This is important because we want that community projects but also industry actors can integrate reuse into their policies and to have a really formal specification for this. But of course, not everyone loves to read like quite dry specifications. Therefore we created a tutorial and an FAQ section. So this provides a really low entry barrier. We explain reuse from scratch with an example repository and the FAQ doesn't only cover reuse questions but also more general licensing and copyright questions that we have been asked for so many times. And then we have the reuse helper tool which I quickly introduced already. And the helper tool started with having this lint command just trying to figure out whether the reuse specification is met in the repository. But nowadays it also supports developers in making their projects reuse compliant. So automatically or see me automatically adding this licensing and copyright information to headers and these alternatives but also many other things generating a bill of materials and so on. And to show you a little bit more about this and how quick making a repository reuse compliant is by the help of the reuse helper tool I would just try to show you a demo. Let's hope for the demo gods to be friendly to me today. That sounds good. Okay, I hope you see my terminal now. So what we do here is to go through the example repository that we've set up. So you can also follow this by following the tutorial downloading or cloning the real, the example repository. But yeah, we just quickly go through it. So what's inside here? Let's see what files we have. So this is really a simple thing. We have a source code file at the very bottom, C file. We have a readme file, a make file. We have two binary files, cat and dog and a gitignal file. So in total six files, two directories. So let's start with finding out what the reuse helper tool thinks about this repository. Yeah, well, that's not so positive. Let's start from the top. It tells us that these six files do not have any copyright and licensing information. And so, yeah, it's not compliant obviously and no license got detected, but we will change that in a matter of a few commands. So we were gonna use the reuse add header command from the tool. So we add here to the files the copyright for Jane Doe and with a GPL 3.0 or later license. And for three files for the C file, for the make file and for the readme file. Okay. And it tells us, yeah, successfully changed the header of the files. So let's find out what happened in this repository by these three commands. So we see here the diff for the three files and we see that for every single or for all three files, we have this information about Jane Doe as copyright holder and the GPL 3.0 or later license in the respective comment type of the file type. Yeah, so that seemed to have worked. Now we add the information about copyright and licensing, in this case for great artist and with a CC by 4.0 license to all files in the image directory. So note here we use the asterisk that also seemed to have worked. So we see here that it got created a cat.jpeg.license file and the same for doc. So let's look what we have here. Yeah, we have two new files and let's see the license and copyright information for the cat image. Yes, so as you can see it's plain text file. You have the information as you already seen it a number of times before about copyright and licensing. So now we are going to add this information that the copyright holder of the git ignore file is again Jane Doe, but now with a CC zero license because we say, well, we do not really care about copyright of this file or for some different reasons we say this file should have a different license and it changed the header. Now what's the situation that reuse sees in this repository? Do you think it's already reuse compliant? Let's start from the top again. We see here missing licenses. So we have successfully found three different licenses and different files, but yeah, the license text files are missing. So we didn't download them yet. Therefore, yeah, but now we could of course go to the canoe.org or fsf.org website to the creative comments website and then again, yeah, try to find the license text files, but we could also just run the reuse command. We use download the dash dash all. So we could also download individual licenses, but here we say, well, download every single license that you found in the repository. And since I have internet here, it downloaded the information and we are going to run reuse lint again So what do you think? Yes, now we are completely reuse compliant. So it tells us which licenses we used and that all six files have copyright and licensing information. And as a small bonus for those people who need it, we have the reuse SPDX command. So this gives us a bill of material. Not really necessary for most, I would say hobbyistic rather pros, but for lawyers and license compliance officers, this is quite an interesting information. Okay, so switching back. So as you can see that the tool really helps to make this whole process a little bit easier. It's, I mean, in this example, we've seen just six files, but if you have a number of C files in a whole directory, just run the command, the tool on all files there where they ask the risk and you will be fine. But of course, check first the information that you actually have. If you know that you're only the only copyright holder and licensor, that's easier. But if you have a whole project, do not just run the reuse command or the reuse tool over every single file. Just saying, well, this should be GPL 3.0 or later, but be sure about this so you don't make an error. But if you know this information, then you can really guarantee that your software project is really simple to reuse for everyone. Okay, so the fourth component component that got reinvented a little bit, invented a little bit later is the API or the batch. So we didn't want that everyone had to install the reuse helper to just see the reuse stages of a project, but we wanted to have a continuous check about this. So in this case, you can just register your project with our API, it's like reuse as a service, you could say. And this generates a really quick check of your repository, basically running reuse lint on your main branch. And it creates a batch that you can integrate into your readme file, like you see on many good projects or so. And we will also gonna have a look at how this looks in real life. Switch over, okay, I think you should see it now. So this is ap.reuse.software. To register your project with the API, it doesn't really matter right now whether it's already reuse compliant or not. You could go to check my repository here. And all you're gonna have to do is to enter your name, your email address so we can contact you in case of urgent changes and your project URL. Right now we only support Git projects here, but we are like support for different version control systems is in the pipeline. And yeah, happy to see your contributions if you're interested or your issue requests. But we don't, we'll not go through the registration here but have a look at compliant projects. You will see them here. Yeah, so we see there are 481 repositories that are currently registered to the API. And we just see what the reuse website for instance, there was a recent change, how this looks like now. So this is the public page for a repository that you registered. And it gives you this pretty bad batch that you can just copy here as markdown. So it will always show the current status and it will always check after every single commit. You even have for developers, you have a JSON file that you can integrate into your further services. And it gives you basically the last lint output that we've already seen. So in this case, the reuse website uses a lot of different licenses and for 76 files. So that's quite simple. Of course, the API suits a different need than the tool. Like the tool can be really easily integrated into your CI CD system, for instance. So you can have it also for pull requests. While the API is more for your public phase and to show the batch and still having an alert if something is wrong from the reuse perspective. So now these were the four main components of reuse. But of course we didn't stop here. Reuse has been started in 2017 and we are continuously working on it and we have quite big plans. On the tooling side, we want to have more improvements and more automation so that it's even easier to adopt reuse to your own projects. And also for the API, we have a number of ideas and we are really open to collaboration. So if you're interested, please join the community. On the specification end, so the quite formal side of reuse, we in the future want to support more flexibility. So the step file format now is a little bit un-flexible. It's a little bit un-flexible. There's only one single file. It's hard to parse for tools. So we're thinking about something like a YAML file or JSON file that can be more easily integrated into the project, which is easier for humans to read but also for machines. And we also want to support a snippet declaration. So it's quite common that, for instance, in Stack Overflow, developers copy a snippet, some contribution by someone else and just integrate it into their source code, which is file, of course, it's three software. But of course, you are asked to also then declare the licensing and copyright of the snippet. And this is right now not possible but we are working together with the SPDX project on how to make that possible and easy to integrate. Speaking of integration, we want to further integrate reuse in platforms and also with other initiatives. So we want to collaborate here with different source forges so that they're supporting, for instance, the licenses directory, and but also integrate this with other initiatives so that we are not going on split ways but that we're working together on solving all these typical issues that we have with licensing and especially free software licensing. And of course, what I'm doing right now here, is spreading the word. So we want to support communities and also companies with adopting the best practices because that's important. If the more projects and more people, the more actors stand behind reuse and make their projects reuse compliant, the easier it is to use and reuse free software and the more ambiguity we erase who already uses reuse. So as you've seen, we have almost 500 registered API projects. And then another cool thing is that the majority of the projects of the next generation internet project is already reuse compliant or is in the process of becoming so. So especially for the US listeners, the next generation internet project is an EU project. So funded by the European Commission. And it's a great thing because those projects are all free software meant to make the internet of the future a little bit more safer, previously friendly and so on. And all of these projects funded by public money will also be reuse compliant. So that's a great thing. On the, I would say community project side, we are quite happy for instance that we have the KDE project there. So they started with the making their frameworks which basically the fundamentals of the whole KDE project are reuse compliant. And they also integrated reuse in their policies so that all contributors, all developers in KDE are asked to follow the reuse best practices which we come to the beginning of the after talk also eases the onboarding of developers. So they just have to follow these quite simple best practices. On the company side, we have, we know we are aware that a reuse is part of the policies of, for instance, Siemens, SAP, LiveRay also of different working groups like Linux Foundation Energy. So we see that the adoption increases quite quickly. Also the Linux kernel is partly reuse compliant already. They have a long road and a long history of course and a lot of ambiguity. And yeah, so we are quite happy that I would say roughly 60 to 70% of the Linux kernel are already reuse compliant. Now the question is, are you already an adopter of reuse? If so, it's great. If not, then follow these five steps. So the easiest part of course is to sign up the mailing list. So we have a mailing list for reuse where it's quite low volume but where we spread information about the latest releases but also where we discuss about the next steps. So reuse is a quite collaborative and open project. So we ask for feedback there. You're happy to or invited to share your feedback and also your proposals for the next iterations. Then the next step would be to make one of your projects reuse compliant actually. As you've seen with the tool and the API, that's quite simple. So just write out, right? And if you're a part of a community, try to integrate reuse into the community. For many projects, there are like these contribution guidelines or you can just make this project from the start on reuse compliant to really try to, I would say, invest the time the first time basically to really clear the information to avoid ambiguity inside of the community project. Try to find out the license and copyright holders for all files. And then from this point on, go reuse compliant and keep this level because the later you start the harder it will be to improve your licensing and copyright information. Then if you're really convinced of reuse, which I hope you do, then you can contribute code to reuse. So all things we have are free software, open, are accessible. You can create issues there, pull requests. We're really happy to work with you here. And most importantly, help others to adopt reuse. May it be in your company, in your job, in your community, just help them or spread the word about this. That would be really great. And with this, I would like to end this talk. I thank you for your attendance and I'm very much looking forward to your questions. Thank you. Hi everyone, this is Stefan. Let me introduce myself quickly. I hope everyone can hear me. I'm the room monitor for this talk. And I'm happy to restate the questions that you already put into the IRC channel for the Jupiter room. And please go on, please go on writing questions. And we have about 10 minutes left. So I suggest to go quickly. We have many good questions and I try to pull those up and just start with the first one. So let's just dive into the question. There was one question. Is there any specific handling of Apache 2.0 notice files? So can you say something about that, Max? I'm not sure what you mean with notice files. I know, not really. No, in this case, not really. I mean, we have many licenses, also like MIT or BSD licenses that are customized in a sense. And in the FAQ, we have a few suggestions how to deal with those. You could, in the reuse term, make this a custom license and treat it as a custom license where you add this information in the license text file, for instance. I'm not quite sure whether I know how this works with Apache 2.0, but yeah, this is the whole deal. That could be a way how to integrate this, especially for MIT and BSD. You're just saying there are so many licenses out there. That is true. One question in this area was the reuse project now supporting all licenses out there or is it aware of all or how do you handle this variation? That's a good question. So we integrate the, I would say, license database of SPDX, which is quite huge. Go on spdx.org slash licenses or so. We support these from scratch. So we can use these license identifiers, but as I said, you can add custom licenses and yeah, you can just give them a name or name them differently. Like for instance, you have multiple MIT licenses that have different templates because perhaps you note that in the MIT license, you could add your name and the year and your email address and have basically a custom license that differs from other MIT licenses. So it's quite simple there to make these custom licenses in the real sense and in practice, it supports any license that you have. But of course, I should add this. We use doesn't know, is not aware of license compatibility. So you know that there are different licenses that are incompatible. So we use is not aware of this, especially since we have something like custom licenses. So that's a different step. There are projects out there that try to solve this. We use cares about the communication of licensing and copyright and from then on other tools and other practices can pick this up. Okay, good. So that is something I have to keep in mind for myself. You talked a lot about SPDX and we have some question about SPDX. So, you know, in general, um, of like, here was one question. Most efforts like this, so like like reuse are controlled by companies and that trade association. So it's to a question reuse relies on SPDX identifiers which are controlled by Linux Foundation. Does it mean is it somehow bound to the Linux Foundation or controlled or are you independent of that? And you know, there's always, you probably know that best. There's always a high potential of politicalization when you come to those big foundations like Linux Foundation or something else. No, so reuse is a completely independent project in the sense that it's the FSFE, Free Software Foundation Europe, is the coordinator of the project. So we kickstarted this, but everything that we have is under a free software license and we are in a charity organization like our sister organization in the US. Of course we rely on different tools and best practices like the SPDX project but their specification also is free software in the sense. Of course I can see that the, I would say the potential for misuse, but right now we use the specification from them which is quite great. And we find this important to not, we invent the wheel here. We had this, we saw this initiative there that already solved a lot of issues like having unique identifiers for licenses for instance, having these tags that are understood by many different other tools and initiatives. So we do not want to split the efforts here. Of course we, then depending on how you see it, there might be different sides, but in the end it suits everyone. If you create free software, it can also be used by companies behind the Linux Foundation for instance. And that's fine, that's free software. And reuse and also the part that reuse uses from SPDX is completely free software. It's an open specification. So I don't see any potential for misuse here. Yeah, I understand. There's a related question that goes like this. The Linux Foundation has voted identifiers for some licenses that are used in wild. Are you planning to have a supplement license list to fill this gap? I'm not so aware of what you said about this, but not really, no, we are not in trying to integrate like a separate license list for this. As I said, you can add custom licenses. That would be a way to do this other than that. I mean, this is perhaps a more general or brings me to a more general topic. We have been asked so many times about whether we want to integrate more functionality in reuse like security checks or more meta information. And in the end, we always said no to those things because copyright and licensing itself is already quite complicated. And now we do not want to load up this whole thing, but instead make like concentrate on these core issues, copyright and licensing and concentrate on making those easier also for, I would say more hobbyist developers who do not have legal staff that they can ask all the time. And so this is still the main goal. And therefore we want to keep it simple and keep it quite slim. Okay, let me restate a more specific question. Let's say that I work in a project with code licensed on the GPL version three and with some text files and images which have some other custom licenses. How can I use reuse in the reuse project for this case? Did you say other common or uncommon licenses? I didn't understand. No other like the GPL and which some text file and image file which in some other custom license. Custom license. Well, it's quite simple. Basically like we did it in the demo with a tool for the GPL license is not an issue. You can just say, well, you run the add header command on the files that are licensed on the GPL. You should decide whether GPL three only or three.o or later, that should be defined. And you can download the license text for this GPL license then. For the custom license, I again refer to the FAQ on reuse.software slash FAQ. There's a section how to add these custom licenses. Of course, it's some manual work here. We currently don't have to like not the complete tooling for this, but in the end, yeah, for these custom licenses, you can create a custom license text file basically in which you like download the text file for the custom license, put it into the licenses directory and then apply this custom license to all the files that apply to it. So basically for the reuse, in the reuse practice, there is no difference between the custom license and something that is on the SPDX license list. There's also no difference between a proprietary, permissive license or copy left license. Reuse treats all licenses the same in this regard to make it easy because we do not want to have a different hierarchy of licenses there because that would be even harder for people. But again, we want to make it fun and easy. Okay, Max, can you have a quick word on another specific question? Would the reuse use project be willing to maintain a list of important or well-known license that need identifiers that SPDX refuses to list instead of using custom fields? I'm not so aware of which licenses could be meant by that. I would say just write me an email and I'm happy to look at what the issue there is and also happy perhaps to collaborate with the SPDX project here that they add this license. I think that would be, again, no split brain here but instead trying to work together, that would be my primary goal. But please write me an email for such a specific case. So far, no experience on that. Okay, one quick question about tooling. Can the tooling help generation and maintenance of DAP5, Debian or copyright files, say converting from to reuse formats? Unfortunately not. That's a little bit also the case why we wanted to deprecate this DAP5 format since it's a little bit different from how reuse treats things and wanted to more go into an own format. Basically, in this case reinvent the wheel actually for the first time, but no, unfortunately not. But if we migrate away from this DAP5 format to the YAML file, there could be some conversion tool anyway or there should be one anyway. So it could well be that we also have like the other way around conversion tool. Could work, okay. But again, write an issue there. That's a good idea, please write an issue on the repository and I'm happy to think about how we can integrate this. Okay, thank you very much, Max. We are close to the end of the session and I invite you to join the IRC. There's a good discussion going on and maybe when you jump in maybe there will be some interesting sorts. If we have more time, I can maybe talk about another general topic. What is your experience about source forges and their reaction to the reuse philosophy? How are you, what information was the new directory and so on are there like trying to understand it? You know, some source forges, say look into the files and try to find the license so that it is displayed somehow in the repository. Like what I know from GitHub for instance is they just look for the license or copying file and try with some heuristics, try to match this to an actual license. I'm not so much a fan of this. Of course, as you might imagine, unfortunately the licenses directory by reuse is not yet supported. I just know that they are generally open to this idea but they did not have the time or not the priority yet to integrate this and they're also not certain how to display potentially multiple licenses there. For GitLab, I unfortunately don't have a really direct contact. We tried numerous times to find someone to have it integrated into their display of which licenses use in the repository. In the end, I think the source forges should not try to crawl the repository themselves. I think it's completely sufficient if they list which license text files are inside of the repository. Otherwise we have again a heuristic there and I made really bad experiences with heuristics because well, no one can tell you whether it's a GPL 3.0 only license or any later version. Other smaller variants and exceptions to licenses. So here I think this information should be provided by the repository owners, by the maintainers because they know best and not by the hosters of the source code and not by the re-users because in the end, otherwise we just do it all over again and we should tackle the sole problem of this ambiguity and this uncertainty. We should tackle that at the root and which is the actual project and its maintainers. Okay, good understood. I didn't get any signal about the end of the session so we can just go on until someone just let us know that we are off record and there's kind of a discussion going on about the IDs, the SPDX IDs and there is probably a big specification behind SPDX so how can I find out about what, like the text, the text when I have an editable file and I put the text in the header and how do I find out what text I supported and how do I find out what identifiers SPDX present and how can I learn about that? For the identifiers, as I said, there's spdx.org slash licenses no promise, SPDX is not my project but yeah, there's a list of all licenses and all IDs for licenses that are supported by SPDX. Regarding the other text, yeah, the specification by SPDX is quite big. They initially started with an XML format t-thing. We just basically chose these two texts that were interesting to us, namely the SPDX license identifier and the SPDX file copyright text and yeah, basically there are many other different texts that are available, I think, some even for upstream contact or so. Unfortunately, I cannot tell you, please ask the SPDX project there, quite friendly guys still. That's good and understood. I also got the signal that we should end so I would ask you to close this session and you are invited to join the discussion on the IRC and I thank you again for the talk and hope to see you later. Yeah, thank you very much, I just joined the discussion. Thank you.