 So, hello, okay, yeah, so my name is Lina, I am a project coordinator at the Free Software Foundation Europe, or FZP, and for those who don't know us, we are a charity that empowers users to control technology, and yeah, we believe that that's possible with Free Software. So, among, like together with other activities, we have our reuse initiative, which is a set of best practices that aims to make the display of legal information, and by this I mean copyright and license information in a free software. It aims to make it easier and also easily verifiable as well as it seeks to already implement existing practices. So yeah, let's get started. So first I would like to start with a short quiz. I know the answers, I think, but let's give it a try. So please raise your hand, who has ever programmed some code here, okay, and then now please raise your hand, who has ever released some of this code under a free software license, perfect. I'd like to see all the hands, right, so it's the same, like with just two questions. And last, please raise your hand, who has never been confused by how to declare or properly declare license and copyright information in your free software project. Yes, okay, so basically this is the goal of reuse, reuse 6-2, I don't know if you, I think it's only this one, right, yeah, okay, yeah, so basically reuse 6-2 help in this process that might become a little bit complicated sometimes. So let's talk about how the state of play is at the moment, and unfortunately it's not in a galaxy far, far away, but it's happening in our ecosystem right now, and these are some of the common mistakes that we've seen so far. So the first one is that there is missing information about license and copyright of own or third party code, so sometimes we go to a repository and it's really unclear, it's really hard to identify this legal information in the code. The second one, which is connected to the first one is that re-users may overlook the chosen licenses for all or some individual files in our repository, and I think you all know that to a big extent the freedoms that we give depend a lot on the licenses we choose, so this information is really, really important. The third one is that it's a little bit tricky to know how to deal with multiple licenses, so we don't know how to display this information when our project is under more than one license and it's also hard to get to know this information as someone outside the project, let's say. And the fourth one is that it is a little bit of ambiguity on the licenses, so for instance, we find that some projects are under the GPO license, but we don't know, we can be the version three, but we don't know if it's version three only or later, so it becomes a little bit ambiguous to know exactly what license the project is under. And the last one is that there might be some conflicting best practices. I like to give this example, for instance, with the license, some projects store the license in a file called copying, others store it in a file called license, others in the readme files, so it's really difficult to really get to identify and know where the license is and what license we're using. And these are not the best practices you're looking for because we want to make it as clear as possible for the whole ecosystem and for everybody, so that's why I want to invite you today to reuse the force and reuse is basically trying to make this easy to find and to also display this copyright and license information because this information is going to be stored in every single file of our repository and it's going to be added through a header, so every single file in a repository is going to have a header that is going to contain this information. Reuse is also trying to avoid silos because we're going to store this legal information as close as possible to the code, so again, if you go to every single file, you will be able to identify this information. Reuse is also aiming to make this information readable for humans and for machines alike, so we all are going to be able to understand this information as well as our tools. And last but not least, reuse is aiming to make licensing easy, but why not find as well for developers, no matter the size of the project. And so how do you do that, right? It's very simple. It's only three steps. The first one, you will choose and provide a license. The second one, you will add this copyright and license information to each file of your repository, and the third one, with the help of our linter tool, you're going to confirm that your project is reuse compliant. So let's go one by one. The first one is we're going to choose and provide a license. So again, we advise to make a wise decision on the kind of license you want to choose for your project, because again, that's basically terms of conditions that you're going to select for your project. And we also recommend to use already well-known and often used licenses. And we're going to save the license of the text, like the text of this license in a file, and we're going to store it in a directory that is going to be named licenses. So this is one of the first features of reuse. We're going to just have a dedicated directory for our licenses, and all the files, all the licenses are going to be stored here. And we're going to name this text file after the XPDX license identifier. So here we're making use of existing practices, and that's why we're making use of the XPDX license identifier. So basically our project is going to look like this. It's going to have the license directory, and then you will see that the text of this file is named after the XPDX license identifier. One small remark here is that reuse doesn't support license compatibility so far. So it is important for you to double check that if you're going to select more than one license in your project, we at the FSV also have a dedicated mailing list for license questions in case you have any trouble, or you're a little bit unsure how to proceed, you can always reach us out in our mailing list. Okay, and now the second one. So now we're going to go and add a header to every single of our files, and the header is going to look like the example. So we're going to use the XPDX tags, the license identifier, as well as the file copyright tags. And again we're going to make use of the XPDX license identifier, so in this case we know it's very easy to understand that we're using the GPL three or later, and then we're just going to name the author of the code. Our reuse limter is able to identify if you just have the copyright symbol, or you just have copyright written on your code, however we want to make use of the XPDX tags, so we recommend to use the XPDX file copyright text. And I know that you might be wondering how to proceed with files that you cannot edit, such as image files, or JSON files, and so on. So for this we have two alternatives. The first one, we're going to create a separate text file with the text of this legal information, so we're just going to add the header in a text file. And we're going to name this file under the file, and it's going to be called dot license. So again in this example we see that there is a picture of a cat, and then we're just going to name it exactly the same dot license. And then everybody that go to this directory and then see the picture of the cat, then we'll be able to recognize that there is a license file and this information is stored there. But we also know that for some projects that are pretty big, creating a dedicated license like a text file for every single file can become a little bit of a burden and also it's not ideal because you can of course double the size of the project. So for these cases we also have the option of creating a depth file file that we're going to store in a directory that it's going to be called dot reuse. The depth file is a project from the devian and then you're just going to look like this and it's going to be also pretty straightforward to identify this. So we're going to see that all the files in the image directory are under the CCBY4. Great artist is the author of those images. And for these cases I think it's important to note that it's good to have like to really know this information for the whole directory because you have to make sure that this information is correct, right? Like if there are an image in this directory that is not under this license then you have to make sure to document or to note this. And the third one, yeah, we're just going to confirm that our project is for use. We're going to use a Hepper tool or Linter tool and in seconds it's going to be able to scan the whole project and then it's going to let us know, yeah, what kind of licenses we're using and if there are some missing files and it's going to just let us know exactly how it works. So now I would like to show you how you can make use of this tool. And for this, I have prepared this, yeah, I have prepared this small project. Can you hear me? Okay. Yeah, so I have this project here. It has some directory, some couple of code files and then you have some images. So we are going to first make use of our Linter tool. So we're going to run our command for use lint. And then we're going to be able to see that, yeah, basically scans everything and then just told us that none of our files contains this legal information. So we're just going to start using like implemented, right? So we're going to make use again of our tool. We're going to make use of our reuse at header command. So first the copyright. So let's say Jane Doe is the author of this code and now the license. And for this project, Jane Doe decided to use the GPL tree or later. So she makes use of the SPDX license identifier. And then in this case, if you don't specify the year, the tool is going to add the current year. So if we don't specify, then it's going to be 2022. But it turns out that she wants to make sure that the year that she wrote the code is 2018. So she's just going to write it here. And then we're just going to let know the tool, what directories we're going to add this header. So let's use add it to the source directories. Oh, yeah. Thank you. Okay, now it should be fine. Yes. So now if we go to the directory, then we'll see that the tool add the header and also recognizes the syntax and just add the information that we add there. So okay, now we have included this to all our source code. Now let's scan again and let's see what our tool tells us. And then, yeah, just told us that we have five files that are missing this information. So let's just go and add this information for the image files. So we're just going to add the same, we're just going to make use of the same command. But in this case, the license is the CCBY4 and the year, yeah, it's 2012. And we're going to tell the tool to add all directory. And then if we go to the directory, to the image directory, then we will be able to see that the tool automatically has created a text file with this information for every file in this case. So once again, we're going to run the linter tool and then we still have three more files. I'm just going to leave the git ignore for last. So let's just make use of the same command. And then in this case, we'll just add it to the mech file and to the readme file. And then just did it automatically as well. We can check, again, can identify the syntax. And yeah, in this case, the git ignore is technically not a copy writeable file. But the whole idea of reuse is that all our files contain this information. So in this case, I would recommend that you have two options. You can just put this file under the public domain, under the cco. Or you can just make use of the same license that you have been using for your project. Nobody's going to stop you from that. But if in any case you go to a court, the judge is going to decide that it's under the public domain or that it's not copy writeable. So let's just add the header to this with the same license. And yeah, let's just keep the year. So I'll just add it please to the git ignore. So now, technically, our files contain this legal information. So if we use our LinkedIn tool, it's going to tell us that, yeah, the 18 files of our 18 contain this information. But still, our project is not reuse compliant. And this is because we haven't created the license directory, which is an important feature of reuse. But with this, we can also make use of our tool. So you can just sell the tool to download all the licenses that you're using in your repository. And then, yeah, the tool is going to create a directory. And it's going to download the text. And it's going to name it on the DSPDX, the license identifier. So if we go one last time, then we will see that finally, our project follows the specifications of reuse. So yeah, this is basically how reuse looks in practice. I know that it's a very small project. And then in reality, it's completely different. But yeah, the whole idea was to show how the tool works. And I mean, you guys who are developers can make very use of this tool. And probably it's going to help you a lot. But now I would like to talk a little bit about the components of reuse. So reuse is like an umbrella, like the initiative of a reuse is an umbrella. So it's composed of best practices, which I just more or less explain, which are the specifications, such as the licenses directory, the headers in every single file, and alternatives for files that you cannot comment. And basically with these specifications, we are aiming to reuse the standard way to display this information. We also have a tutorial and an FAQ to help people getting started. So the tutorial is basically what I just show in the practical example. And there are also another bunch of features that the tool has that can also help a lot. And in the FAQ, we give answers to questions that go from the tool itself, but also more legal oriented complex questions. Because what we are aiming to do is to lower the threshold so more people can actually start making use of reuse. As I just show, we have the helper tool, which also, I mean, is just seeking to support developers in making the project reuse compliant. And it actually helps a lot. For, like, after you implement reuse, there are also some options to, like, such as a pre-commit hook or the CI workflow implementation. So once your project is reuse compliant, you can adopt this and then it's going to start scanning and helping you to keep track of your project in the future. And we have also an API in which you can register your project once it's reuse compliant. And then if it's reuse compliant, you will create a batch that you can put on your repository later to let others know that your project follows the specifications of reuse. And in that sense, we can also keep track of how many projects have been implemented in reuse. So once again, where are the reuse specialties? What is so special about reuse? So we have the license text. Every single license that we're going to use doesn't matter if it's only for pictures, for one piece of code, or for everything. Everything is going to be stored in this license directory. Every file is going to contain this legal information through a comment header. And we are going to make use of the SPDX license identifier tags, as well as the SPDX copyright file text. Reuse has alternatives for files that you cannot comment. And in the long run, it's trying to make an ambiguous the way we display this copyright and license information, because again, every file of our repository is going to contain this information. So now, I would like to talk a little bit about the ongoing developments with reuse. So again, our tool is an ongoing improvement. Then it's seeking to further improve the helper tool, as well as the API. Our developers are, on a daily basis, working to improve it. The specifications, as well. For instance, here, I would like to mention very quickly that we are trying to change the depth firefighter for a demo file in the future to make it more flexible, as well. And probably that's going to change, as well. It's going to be better. But this is an ongoing process. And there is still some time to get there. There is also snippet support in the pipeline. So in the future, if you have snippet on your code, you're going to be able to declare legal information for that specific snippet, as well. And there is a bunch of other changes that are in the queue at the moment. We are also trying to better integrate in other platforms and other initiatives. And again, that's why we're making use of the SPDX license identifier and tags on the file, and so on. And we are trying to spread the work, which is basically what I'm doing here. We're trying to let as many developers as possible know that this tool is here for you guys to make use of it. So we're also supporting communities, but also companies in adopting the best practices of reuse. So here, for example, so we have the software that I just showed with the tool. But we make use of that. And we help communities and companies through different frameworks. So for instance, we have the Next Generation Internet, which is a European Commission initiative, which is aiming to shape the internet of the future. And there are a bunch of projects on that framework that we're helping to become very compliant. So we do so through some guidance, but also through practical examples. So we send merchant requests to these projects. And then, yeah, in the future, they decide if they implement it or not. But we like to support these projects because they're just starting. And then it's easier for them to just go for reuse from the beginning. We also have, as I already mentioned, our mailing list, which is focused on license questions. So all our free software community is welcome to just drop any questions. And our legal team is going to do its best to help and to guide in these kind of issues because we know that this might become a little bit complicated sometimes, even for us as well. And then last year, we launched our Reuse Booster Project, which basically is aiming to change a little bit the workflow. So now we are approaching projects, and we're trying to work closely with them, trying to understand their workflow, trying to understand their needs, and just helping them in a closer way to implement reuse. For instance, in this framework, CURL has implement reuse, and GNU Health has also decided to implement reuse on all its components. So yeah, we have seen the shift of just sending merchant requests to a more closer approach, and I think projects value that a lot because, yeah, then you get to understand better how they work and what kind of needs they have and also what kind of questions they have. So it's kind of like an ongoing process, but in the end it really helps. So yeah, talking about who has adopted reuse, so in our API we have more than 1,200 projects registered. We like to believe that it's more, but they haven't registered yet. And as I already mentioned, the majority of projects of the next generation internet initiative have implement reuse, which we're talking about more than 100. Again, like KDE and all its frameworks and has implemented some of its licensing policies, so yeah, good job, KDE. And as I already mentioned, CURL and GNU Health have decided to also implement reuse. GNU Health is still in process, but the wheel is there. And from the corporate side, we have seen companies such as Siemens, Huawei, SAP, LiveRaid, LF Energy, who have also implement reuse in their licensing policies. And the kernel of Linux partially has implement reuse, because of course it's huge. And the question is whether you and your project want to also implement reuse and its specifications. So how can you join us? We have also a dedicated mailing list for reuse, in which you can also ask some questions. If there is something that is not clear with the FAQ or in the tutorial, you can always ask anything there. There is always a debate going on there. Again, you can make one or all of your projects reuse compliant. I just showed that it's very straightforward and once you get to understand all the features that reuse has, it's pretty easy to use it. You can integrate reuse into your community, like KDE has done. Again, reuse is a free software, so you can always contribute with code to the tool as well. All the improvements that we have done are because of the community as well, all the issues and merchant quests that are open there. So that's very valuable. And also, I mean, this tool is for you guys, developers. So if there is something that can be improved, we will be very happy to know. And yeah, you can help or guide others to implement reuse or to adopt reuse. Again, it's very straightforward, so it's pretty easy to use it. And here, I would like to give a big thank you to all the FSF supporters because really, you have enabled our work and it wouldn't have been possible with your support if you haven't always welcomed to support us. And yes, with this, I would like to close my presentation. I would be very happy to take any questions. And if maybe we don't have the time to answer all of them, you can always drop me an email or join our mailing list. We'll be more than happy to help. Thank you. Thank you very much. Do we have questions in the audience? Yes? It's a little bit outside of the software context, but have you thought about reaching out to open science initiatives? So many universities are adopting policies of publishing data, software code, and other things related to the scientific process. And I think this would be really relevant for what they're doing to standardize that process. So it's a bit outside of the software context, but have you thought about something like this? Well, I mean, in the FESFEE, we're trying to really get involved with different communities. Maybe also this is a little bit out of the topic, but we've been following a little bit what's happening with the AI Act and so on. And then based on that, we're also trying to get involved with open data communities as well. So yeah, I mean, this is definitely that we see as an opportunity, because why not? Yeah, but I mean, it requires some time and human capacity, so we are just doing our best. But yeah, we have that in mind. Thank you. Thank you for your presentation. I'm really looking forward for the specification updates with the new features. Maybe I would like to add two points from my personal visualist. One is maybe a smaller thing that might help reuse adoption. It's mainly in GitLab and GitHub that those online platforms mostly fall back to the old copyright file or the license file and do not adopt the licenses in the reuse directory, which is hiding what the license really are on the repository. I think that might help, because in KDE we see it, because the licenses are not shown, because GitLab is not supporting it. That might help if the FESFEE talks to them and triggers them, would be good in that direction to go. Yeah, I'm sorry, I don't know if I completely got your point. Maybe because of the mask is also a little bit hard. It's the display of licenses in a repository. You have all the licenses in the licenses directory, but several online platforms ignore it. They use the old locations, the copyright file, or the license file, and it only displays those. So it's not visible what you have there. Okay, yeah, yeah, yeah, I see what you mean. Yeah, this is also discussed by our reuse team, actually. Yeah, mainly on like GitLab and other platforms. But yeah, I mean, this is something as well that requires some communication with them as well and feedback and back and forth. But yeah, this is definitely in the pipeline. Yeah. Can you use the tool to switch from one license already used to another or update an existing license to a newer version for the whole project automatically? I mean, if your project doesn't have yet the hitters, so it's pretty easy and pretty straightforward, I know that there is a way to replace the information, so you could always change the header. So yeah, I mean, if your project hasn't really adopted reuse yet changing the licenses pretty straightforward because you just use the tool as I showed. In KDE frameworks, we have the situation that we have code that's grown over many years and we have libraries or applications that mix source files with different licenses. But when we release the software, we want to say, for example, the library's LGPL2.0 or 3.0 is FSFE also interested in that trying to figure out from the used licenses in the project if that's possible to say that I can release this entire project under a certain license that is compatible with all the licenses that are used. Yeah, no, sorry. Can you repeat the question again? I think the question was about checking the compatibility of licenses. And I think you mentioned in the slides that you cannot do that at this point. I wanted to ask if FSFE is interested in explaining that with the reuse tool or something different. With the compatibility. OK, yeah, I mean, this has been also discussed. But I mean, it's not in our priorities yet because that requires, I mean, you need to understand the terms of the license as well. And I think it's important that there is some human oversight on that decision, so to say. So yeah, I mean, this is a thing that has been discussed and also by the community. But so far, it's not part of the priorities. Why do you use a file as the basic unit for copyright? Why every file has to have a license? Why can I say all files in this project are under the same license? OK, OK, yeah. Because, I mean, if your project is only under one license, it's pretty straightforward and very easy. But we know that a lot of projects use more than one license. And therefore, it's very hard to know exactly what piece of code or what file is under which license. So we believe that the closer you store this information to the source or to the code or to the file, the less likely is that people would misunderstood this information. And I mean, misunderstanding this legal information, it's a little bit complicated. And we're talking about infringing license requirements and so on. So we really try to make it as simple as possible to avoid these legal issues in the long run. I think that's it for questions. Thank you very much. Thank you very much.