 Hello, everyone. It is a pleasure to be here, and yes, this talk will be in English. I promise I'm doing my best to practice my German, so maybe next year I will be able to host it in German. Yeah. Let me first introduce myself. My name is Lina Cevachos. I am a project manager at the Free Software Foundation Europe, also known as FSFE. For those who don't know us, we are a charity that empowers users to control technology, and we believe that that's possible with Free Software. But today I came to talk about this nice initiative called Reuse. So Reuse is an initiative from the FSFE since 2017, and it's basically a set of recommendations that aims to make licensing and copyright display easy for everybody. It aims to make it readable for humans and machines alike. It's also pretty simple and very easy to verify, and also it seeks to be integrated in already existing practices. So I will give a brief overview of what Reuse is. Then I will show you with three simple steps how you can make your project Reuse compliant. I will also do a demo here with a chore project that I prepare to show you how the tool and these specifications look like. I will talk a little bit about some ongoing developments of the tool, and yeah, that's kind of like the overview of today. But today I want to start with some questions for you. So first, please raise your hand who has ever programmed some code. Yes, I cannot knew the answer. This is also pretty straightforward and pretty simple who has ever released some of these codes as Free Software. Yes, please. Okay, I don't know if someone is already falling asleep or is developing proprietary software and who has never been confused by how to properly declare license and copyright information in your Free Software project. Okay, yeah. I know declaring this kind of information, it's a hassle. We know that. And that's exactly what Reuse is trying to achieve to make it simple but also fun for everybody. So let's start first with the common issues or the common mistakes that we see in some Free Software projects or how people are displaying this kind of legal information. So first of all, there is some missing information about license and copyright information of own or third party code. So sometimes we see some code and we are not sure under what license it is or who the copyright holder is. And then this is connected to this other mistake or issue is that re-users of the code may overlook these chosen licenses. For all or for some individual files in your project. And we know that the terms under which your software release are defined by the licenses. So this legal information is quite important and overlooking this information might become a little bit problematic. And then there is a little bit of uncertainty on how to deal with multiple licenses because you all have developed some code and then you know that a lot of Free Software projects are under many licenses. And then it is a little bit unclear how to manage this information. There is also quite a lot of ambiguity with some licenses. So sometimes we find some text of a GPL tree but then it's a little bit hard to know if it's the GPL tree or later if it's only GPL. So it's a little bit ambiguous if it's not very clear, specified. And there is also some sort of conflicting best practices because let's say again the example with the licenses. Some people store this text in the copying file or they're stored in the license file or they're in the read me file. So it's a little bit you always have to go and try to find where the license is if there are even more licenses. And that's many of the reasons why Reuse started to help you developers but also to help users and re-users of Free Software and how is Reuse actually helping. So we make it easy to find this copyright and license information because we're gonna add this information in every single file of the repository using a header. So you will see this information in every piece of code. And with this we want to avoid silos because we want to store this legal information as close as possible to the repository or to every piece of code. Again as I already mentioned we want to make this information readable by humans but also by machine. So if you go and see every file you would be able to understand and also the tool would be able to know and identify this information. And as I already mentioned we're really trying and putting a lot of effort of making licensing or dealing with this legal information easy but also fun for developers without no matter the size of the project because we know that there might be a lot of big projects but Reuse helps with this. So how does Reuse help with all these issues? It's really three simple steps. I will go one by one and I will also show you in the demo how this works. But then first you just choose and provide the license or the licenses of your repository. We of course encourage people to select well-known and recognize licenses although we know that you can also create your own license. The second is that we can add this copyright and licensing information to each file of your repository. And third we're just gonna confirm that your project is Reuse compliant. So let's go step by step. So the first one is to choose and provide the licenses. So let's say you select the GDPL tree or only. So you're gonna save the license text of this file in a directory that we're gonna create that it's gonna be called licenses. So all the licenses that you are using in your repository either for the whole project for the pictures, for the documentation is gonna be stored in this directory. So people who go and check your project are gonna know what kind of licenses you're using. And then you're gonna name this file after the SPDX license identifier because as I already mentioned, Reuse is integrating already some best practices. So we're using the SPDX license identifier. So in this example you can see that we have the directory called licenses and then our GPL tree or later, it's saved under the SPDX license identifier like the license name of this specific license. One important thing here is that Reuse doesn't support yet license compatibility. So if you have any questions about your project is licensed under a certain one and then you want to use or reuse something from another license and you're a little bit unsure if they're compatible. I mean, first of all, I think there are a lot of, quite a lot of tools to check that but we also have a licensing question mailing list in which we help developers with these more legal oriented issues. So you have to be aware of that. The tool is not gonna warn, like does not gonna make any warning on like if there is some uncompetibility regarding licenses. So we already got the licenses and now we're gonna add the copyright and license information to the files. So we're gonna do it through a header who's gonna look like here in the example. So for the license identifier again, we use the SPDX tag and the license name and then regarding the copyright text, we again encourage people to use the SPDX by copyright text, this tag, but if you already in your project have the copyright or use the symbol of the copyright, it's also fine. The tool will be able to identify it but regarding the license, yeah. Only the SPDX license identifier tag will be recognized by the tool and then I know that by now you might be wondering, I mean in my project there are some files that I cannot comment like images or some binary files or JSON files. So for these we have two alternatives. The first one is to create a separate dot license file for this specific file. So again in this example, we have the file of a cat, the image of a cat and then what we're gonna do is just create a dot license that we're gonna name after the file as you can see and then in this separate license file, we're gonna add the legal information. So we know now that the cat was taking or the copyright holder of this picture is a great artist and that the cat, the picture is licensed under the CCBY4. But now I know you might also be wondering like I have a project and my project has 1000 pictures and then creating 1000 separate files for this might be a little bit of a hassle and also not a good idea because we'll double the size of the project. So we have an alternative for this case that there are some ongoing developments I will talk about this later on but we have this depth file file that we're gonna store in a directory called dot reuse. The depth file, it's the VM project. We're also again integrating already existing practices and then in this case, you can see that we just select a whole directory because we're not, we're sure that this information is correct because this is the downside of this alternative is that you might overlook some pictures that were not, that the copyright holder is not this person or is under different licenses. So if you're 100% sure that you know the legal information of this that you're gonna use it and then you're gonna tell that the whole directory of images is under this license and the copyright holder is great artist or yeah, the copyright holder. And the third one is that we're gonna confirm that our project is reuse compliant and we have a tool for that, a linter tool that runs pretty easy, it's quite fast and then it's gonna scan your project and it's gonna identify it, what licenses you're using if there are some files that are missing some license information or not. So in this case, our project is reuse compliant so it's all good. So these are the three steps. Now I would like to show you how the tool works. So for this, I have prepared this project. It's pretty small. So it has some code, it has some images here. We can see that it has some copying files so we have the GPL version three. We don't know which one it is. But yeah, so let's start it. Let's say I am, I have a release. I am the owner and the copyright holder of this project so I'm gonna do the whole process. So first I'm gonna scan my project to see how it looks like. So we're gonna use our command reuse lint and then here reuse the tool which will show us you have these files and zero of them have this legal information. So we're gonna tell the tool to help us. So we're gonna use reuse add header command to add these headers. So I'm gonna start with the code. So I'm gonna add to the whole beam directory and to this source. So let's run add header and then we're gonna start with the license. So I know that my project is under the GPL tree. Or later. And then we're gonna use, sorry, the copyright. We're gonna specify. So Jane Doe is the copyright holder. Here if you don't specify the year then the tool is gonna add the current year. So I want to specify that the year is the year of the first publication so I start this project into 2012. So let's add the year. And I'm gonna tell the tool to which directory. So please add it to the whole beam. And also to this directory. So now the tool automatically create the headers. So if I go here, maybe it's a little bit small but then you will see that the headers are there. And the tool is able to identify the syntax as well. And then yeah I just add this header to, I don't know, 15 files in three seconds. So we would check again how the project looks like. So I recognize us that 13 of these files have this information but we're still missing some. So within those we're still missing the image files. So let's ask our tool to add again this. So we're just gonna use the same commands but then the pictures were taken by Dave though. And yeah, the year was 2013. And yeah in this case I'm gonna also change the license because these pictures are under the CCBY4. So we're just gonna change this. And yeah, the year and then we're gonna tell the tool, yes please add this to all the image in this directory. So yeah, the tool already did this if we go again. We will see that the tool has created this individual dot license. And then if we open then we can see the information is there. Okay, yeah, so we are almost there. Let's check once again how the project looks like. We still have three more files. I'm gonna add the header to the make file and the read me file because the git ignore I'm gonna briefly explain it later. So let's just add the same license and yeah Jane Doe is also the copyright holder. So if you go again, then you will see it's there. The make file again, it recognizes the syntax and it creates the comment header. So for the git ignore, I mean git ignore is like an insignificant file. So technically it's not copyrightable but the idea of reuse is that the whole repository, every single file has this information. So you have two options. You can either license it under the main license of this project, so the GPL tree. Or I mean, no things wanna stop you for doing that. Or you can also put it under the public domain. So we can do that if we go here then let's just put it under the public domain. So let's use the, yeah, cc0. And then, yeah, I'm just gonna change this, Jane Doe. Let's keep the same year. And then just tell the tool please, add it to the git ignore. And then yeah, it would add it now. So now technically all our files have this legal information. So let's see how the tool reacts. So it's still telling us that it's not reuse compliant. And it's actually telling us here that there are some missing licenses. So we know that we have used these two licenses and the text of the licenses are not still, are not in the repository yet, you can see. But the tool will also help you to do this. So with our command reuse download all, the tool will basically download all the licenses that you have used. And then if you go to the root of the project then you can see that the tool has created the licenses directory and the three licenses are stored there. And it's pretty easy and pretty straightforward. So if you scan it once again, it will tell you congratulations, this project is reuse compliant. So yeah, I mean, this is very quick and simple example. I know that in reality it's not that easy, but it was meant to show you how the tool works. And you could also see that we save a lot of time. We did a lot of things. Thank you, thanks to the tool. So let's keep talking about a little bit of reuse as a whole. So the components of reuse are this set of best practices. So the specifications that I have mentioned already, the licenses directory adding headers to every single file of the repository because we are aiming to make reuse a standard. So the more projects implement reuse, the easier it's gonna become to first identify this information and then second to just implement it as a standard practice. We have the helper tool that I just show a little bit how it works. Because yeah, it aims to support developers in making their projects reuse compliant. So it really helps, there are a lot of commands and there is a lot of ongoing development to make it better, of course. And there are more features that probably, you know, you guys that are developers know how to use better. And then there we have also a tutorial and a FAQ because we are trying to lower the threshold to for people to get started with reuse. So our tutorial is pretty much explained pretty much what I just did. And then we also have some FAQs on FAQ to answer a lot of questions regarding the tool but also regarding some legal questions, a little bit more advanced questions. So there you can find maybe the answer to a lot of the questions that you might have and now if I'm not able to reply to answer them after my presentation. But yeah, the idea is that pretty much everybody can implement reuse and everybody can yeah, can make a project reuse compliant just by checking the tutorial and also by having this FAQ available. And then we also have our API which you can also find through our reuse.software page. And then there you can, once you have done your project, you have made your project reuse compliant, you can add it there, you can register your project and then the API will create dynamic batch that you can put in your project. So you can add it in the readme file and then in the future, people who visit your project will know that your project follows the specifications of reuse. So we are also now encouraging projects to register because then we can also know how many projects have been using these specifications. So a little bit about what's special, what is special about reuse. So again, we have this directory called licenses where we're gonna find all the licenses that you're using. And therefore it's also easy to identify if there is some uncompability toward, like between them. And it's again easier for users and re-users to spot this information very quick. Again, every file will contain this legal information. So we'll add the SPDX Copyright and License Identifier tags. So it will become again way easier to track to know what the license of a specific piece of code is. And we have some alternatives for uncommentable files. As I already show, so we have the dot license or the defi file. And most importantly, we're gonna make less ambiguous the display of this information because we know exactly what licenses been used. And then we also know for every piece of code what the legal information is. So now let's talk a little bit about the ongoing developments of the reuse. So first of all, the tool that I just show is seeking to improve itself. Our team of developers are really constantly checking the feedback and also trying to find issues or bugs that are in the tool to make it easier for everybody as well as the API. So we're changing the documentation and really actually improving it as much as we can. That's why the feedback from the community is so important and the feedback from developers. You are the ones who are actually using the tool and then it's important for us to also know how you feel about it, what could be improved. And yeah, so again, the more projects use, reuse, the more, the better you will get because the more feedback we will also get. And then the specifications are also changing and improving. So here I would like to mention a little bit the defi file, we are trying to change it a little bit for a YAML file because it might be more flexible. But yeah, this is our ongoing process, but the whole idea would remain. So we still want to offer projects with like a big size to be able to display this information in a easier way instead of creating an individual file for every file, for every of these uncommentable files. There is also ongoing development on some snippet support. So if you have a snippet on your code, then you will be able to declare the legal information of this specific one. So yeah, that's also in the pipeline. And yeah, we are working on some other changes in the queue. The tool has the version one, one zero has been released some weeks ago. And now we are immediately working on the version one one because there is still a lot of feedback going on. But yeah, this is for the future. And again, we're trying to integrate reuse to make it better to integrating already existing platforms and also in other initiatives. That's why we're, for instance, using the SPDX tags. And then yeah, we're trying to make it better. So it really doesn't become a burden for you guys to make a project reuse compliant, but they can make a whole use of the whole ecosystem because in the end that's what free software does, right? It can help us to improve through collaboration. And then spreading the word, which is basically what I'm doing here. Showing the tool, I'm kind of impressed that a lot of people don't know about the tool. And honestly, I feel that it's a tool that actually helps a lot. And I know that it might sound a little bit like a burden to make a project reuse compliant, even more when your project is big. But I mean, I think in the long term, the benefits in the long term that this will have way more. So yeah, we're just trying really, really hard to make it easier every time for you to make your project reuse compliant. And then yeah, with this, I would like to talk a little bit about our activities around reuse. So for instance, we are also working with the next generation initiative, also known as NGI, which is a European Commission initiative that it's trying to shape the future, like the future of the internet of the future. And then we're helping a lot of these small projects to become reuse compliant. Yeah, some of them are not small at all. So yeah, our work there has been quite also good. We really have been successful in implementing reusing a lot of these projects from the NGI. We recently, last year, released our reuse booster, which is trying to change a little bit the workflow. So we're now approaching projects to help them to become reuse compliant. So we're kind of establishing a closer communication with the projects, because again, we want to make it as easy and smooth as possible. So we're trying to identify and understand their workflow and their policies and how they develop their project. And then we are working closely with them to help them implement and reuse. So for instance, CUR has become reuse compliant lately in the framework of the reuse booster. And then also GNU Health has decided to implement reuse in all its components. It's also big projects, so it's an ongoing process, but the wheel is there. And yeah, so our team is really trying to work closely with projects. And in the beginning, reuse booster was aimed for projects to reach us out to tell us to help. But now we're trying to identify these interesting projects that we could help with reuse. And then we also have, as I already mentioned, the license questions. So we have a mailing list for that. If you have any questions on your project regarding some legal issues, we will do our best to try to help you with that, because as I already mentioned, the tool doesn't really support that, but in our team and also in our community, we have lawyers or legal experts that can help to solve these questions. So this is kind of like a whole umbrella of activities around reuse. So now talking a little bit about who has adopted reuse. So in our API, we have already more than 1,100 projects registered, so we like to believe that it's more. And so I haven't registered yet. So I mean, this is quite a big number. And that's why sometimes I'm a little bit surprised that people don't know reuse. And we're actually working on promoting this tool more because I think it will really benefit the whole free software ecosystem. And as I already mentioned, with the next generation internet, we have helped more than 100 projects there. And then, yeah, we also try to make it as easy as possible for them. In terms of community oriented, so we have KDE and its frameworks and then reuse is also implementing in their licensing policy. So basically all the KDE frameworks are following the reuse specifications. As I already mentioned, CUR has recently become reuse compliant. And yeah, Canoe Health, which is in process, but I'm really looking forward to see that. In the, from the corporate side, we can also see reuse implemented in the policies of Siemens and Huawei, SAP, Live Ray, LF Energy. The kernel of Linux is partially following the reuse specifications because of the size. But yeah, this is also quite exciting. Yeah, and then the question is if you and your projects want to implement reuse, want to follow the reuse specifications. So how can you guys join? For reuse, we also have a mailing list where we discuss things, when we, some people charge some questions or things that are not clear. So you can always sign up there. To join the discussion in general. Again, you can make one or two or all of the projects reuse compliant. You will find all the information on our website, reuse.software, and everything is connected, the tutorial, the FAQ, the API, and yeah, et cetera. You can integrate reuse into your community. Again, you can also share the, spread the word, tell that you attend this very interesting talk in FrostCon. Yeah, and yeah, just make more and more people aware of reuse. You can also contribute with code. Now that you all have developed some code, I mean, reuse is a free software, so it's hosted there, the code is there, you can see, you can always help us improve it. So feel free because the more, again, the more people help us and the more people give us feedback, the better it will get. And you can also help and guide others to adopt reuse. I mean, using that tool is pretty easy and it's pretty straightforward. And once you understand how it works, you will be able to help others and share the word. And yeah, I mean, this is really, it's a very easy tool. Even for me that I'm not a developer, it's quite user-friendly, I have to say. And yeah, with this, I would like to thank you and also thank all our FSFE supporters because they help us to, and they enable of work. So this is an invitation if you're not to become part of it in fsfe.org support slash support. All is welcome. And yeah, with this, I will finish my presentation. These are the sites and this is also the mailing list and our guide repositories with the reuse and also our FSFE repository. So if you have any questions, I will be more than happy to take them. Yeah, and otherwise thank you so much for the attention and I hope you enjoy it. Thank you. Sorry? Yeah, yeah. We have also some tools for developers so you can implement this like a pre-hook. So whenever you're gonna implement your code, then they will identify if it's missing some of these specifications. So yeah, in the reuse.software you can find, there is a specific page for that where you can find also how to implement it because yeah, again, we try to make it easier and also, I mean, if you make your project reuse compliant then you will have to check and check every time but with this, yeah, it will make life easier. So yeah, you can find it in the website. Sorry, should we take the, yeah, I think we should take the questions with microphone for the recording. Sorry. Oh, mind. When we manage security informations and also license informations in the SPDX format so that they don't destroy each other when I use a reuse tool. Yeah, I think I wouldn't, I'm not very familiar with the security features of SPDX so I think I cannot really answer that question but here's my email on the slide. Please feel free to remind it again and then I will check with our developers that are a little bit more close to that and then I will come back to you with that, yeah, answer. Yeah. Is that, does anybody, yeah. Thank you. Maybe do you have an additional service to find out which license I actually need to my files? So like, you mean what kind of license you should use for your code, depending on your needs? For my code, for my pictures, for something in my project, something like it has some questions, I answer them and then I can see which license I actually need. Yeah, okay. I mean, I would say that there are some tools that do that because every time I work with that I'm surprised by the amount of tools that have been developed on that regard. I personally don't know any but on our FAQ we have, for instance, these kind of questions like I have these pictures, what license should I use? So we try to recommend to use the most common ones because it's also easier for re-users to they already know the license and they know the terms and the conditions. So we tend to encourage people to use the most common ones and the most well-known licenses for code or for pictures. So on our FAQ you will find some of these suggestions but if you have any specific questions regarding like certain terms of conditions that you want to use during like for your whole project you can always ask in the licenses questions and then we'll be more than happy to help you to guide you there to have like a more closer help from us. But yeah regarding a tool I am not very familiar with any but I would say there might be some. Thank you. Thank you. I can also take it. Thank you. Do you have any hints how we should manage a project with many authors? In the example we saw a project with two authors and the typical project for example has 30 authors or more and the author changes one file then he's already one of the many authors and this continuously changes and the most easiest way would be to take this information automatically from Git and add it to the files. Is there any API for this? Yeah, I mean from what I know I think there are some ongoing conversations with Git, I mean GitHub let's say but in this specific case we would recommend to for instance as a copyright holder make I don't know your project I don't know very useful contributors and then in the root of your project you will specify who the contributors are so you will list them and then if someone adds something then the person would add him or herself to this document and then you don't have to change the header every time but it's just like a, just wrap it up by just mentioned contributors of the project but then you will have to make sure you specify who they are. Yeah, does anyone else have any questions? Okay, then I, yeah glad everything was clear and thank you so much for the attention and if you have any questions we also have a booth from the FZP you can always go there, reach me out my email is there, contact at FZP as well. Yeah, feel free to reach us out and if you have any questions of need in terms of legal issues again or mailing list is open for you. Thank you.