 Next up, reuse. Hello everybody. Can everybody hear me okay in the back? Then I'll speak up like this, okay? Okay, perfect. So I'm going to give a talk about reuse. I'm Linus. I work for the Free Software Foundation Europe as a sysadmin and I'm also one of the maintainers of the reuse tool. And so this tool, since this is the S-bomb deaf room, I need to relate what we do with reuse to S-bomb somehow. And I think the catchphrase or what I want you to take away from this presentation today is that if you want to have nice S-bomb downstream, you should push everybody to use reuse upstream because it makes everything else much, much easier. Or just how reuse makes everybody's life a bit easier. So typically with free and open source software, you have compliance issues when it comes to license and copyright. There's missing information about license and copyright holders of your own code and of third party code that you might use in your application. There's license ambiguity. So for example, if there's just, it says GPL, but you don't know which version. And often when there's somebody taking the time to put all the information there, it's stored in a silo and it's not actually where the code is. And often another thing is that when you change something in the code, you should or you have a new contributor coming on, then you need to change everything again. Developers also need a lot of training if there's custom solutions and there might also be conflicting compliance practices. So we thought like, why can't we solve these issues here up the stream so that when the water flows down to everybody else who's consuming license and copyright information of source code has just an easier time digesting them. So reuse is based on a couple of principles. It should be easy for copyright and licensing information. Everybody should be able to find this easily. So it should be in the file that it applies to if that's possible. Of course with a binary file, that's not possible, but if it's plain text, that's possible and then it should go in there. Silo's should be avoided and all the licensing copyright information should be stored in the repo. And that info should be readable by humans and machines alike. We also do not want to reinvent the wheel if we don't have to. So yeah, we try to be compatible as compatible as possible. And also licensing should be easy and fun. And yeah, so we try to do that. You can decide whether we manage, but at least we try. So there's three simple steps to using reuse. First, you choose and provide the license. Reuse does it with a nice little dialogue for you when you start it up the first time. I can show you later. Then you add copyright and licensing information, preferably to every file. And then we have a range of tooling that allows you to confirm this reuse compliance, either in a pre-commit hook, in CI, and of course locally on your machine. So I'll go through this quick, maybe just a quick show of hands. Who has heard of reuse before? Okay, so I'm preaching to the choir. Who has used it before? Okay, so I'll go through this rather quickly. One thing that we do is we save license text in a licenses directory. I'll make a quick shout out to GitHub later about this. Then reuse names after the SPDX license identifier, and then they're stored in the licenses repository. Then the copyright and license information is added to every file. Then it looks roughly like that. And then if you have uncommentable files, binary files, images, or executables or whatever, then you can do a separate license file, which is a plain text file, which refers back to that uncommentable file, which then contains this information. And also you can use a .5 file in .reuse directory. This is about to change soon, hopefully, because we're going to develop our own reuse YAML, which sits at the root of the repository, where you can define this type of information for uncommentable files or for whole directories much easier than with .5. And then the third step is you confirm that you're actually compliant with reuse. What are the components of reuse? One thing is a spec where we pretty clearly try to state how licensing information and copyright information should be added to source code. Then there's a helper tool, the reuse tool, the reuse CLI tool. Then there's a very good tutorial in FAQ that you can look into to answer very basic questions about licensing, but also some advanced stuff. And then there's an API where you can sign up your project and then get a nice badge who doesn't like badges. So I've already said that we store the licenses in a licenses directory. So the UI of GitHub, for example, still doesn't pick that up properly. That would be very cool if that happens. It's not very hard. And the rest of that, in the interest of time, I'll skip over that. So now I'll just show you really, really quick because I have five minutes left, I think. That's how this works, how this looks in practice. So here is the text size okay for everybody in the back. So here I'm in a non-compliant repo and I can run reuse lint to confirm that I'm not compliant. I have 6,000 in this repo. None of them have any copyright or licensing information. That's not cool. So I can just run reuse in it. And now I'm asked to provide licenses. So usually I use something like CCO 1.0 for just configuration files and stuff like that. Then we could, let's set GPL. And then did you mean I add GPL? And just call that example. That doesn't matter. So now we see it downloaded the licenses and created that file file for us. Like I said, this will change. And now I can start adding license information to certain files. So for example, now I can add the license CC0 to my gitignore file for example. I can run reuse lint to see what's changed. And I see now I have one file with correct copyright information. And I could now continue doing that for the rest of the files. But I hope this, you get the idea that it's a tool that really simplifies this process. And then you can put the reuse lint checks in your pre-commit hooks. They're very terse. They basically look like this. This is a... That's all you have to do and then run pre-commit install. And then before you commit, it does the reuse lint check. So it's very, very simple. It's very straightforward. I had to jump through this a little bit because I don't have that much time. I just realized. So the ongoing development is of course the tool. And it's all free and open source. And so you can contribute as much as you like. And we're very happy about everybody who contributes. And then there's an API, which is all fully open source and free software. We have a specification which will be extended with reuse YAML really, really soon. We hope that we can do some better integration, especially with Git forages in the future, that the UI shows you which licenses you have in the repository right away. And we want to spread. And you can of course help us with that. So who uses reuse? At the moment we have over 1,400 projects signed up that use our API that have cumulatively more than 80,000 stars on GitHub. Then there's stuff that lives on other forages like KDE and the framework that uses reuse. Curl became reuse compliant as WebLate, a really cool translation project that recently became reuse compliant. GNU Health project, it's an awesome project. The Kona one app in Germany. And the Linux kernel is trying to become reuse compliant. We'll take a while. And yeah, so feel free to check this. I will upload the slides and then you have all the links. If you want to participate, sign up to the mailing list, ask questions, create issues, make one of your own projects, reuse compliant. It's really easy. Integrate reuse into your community and compliance policies, help others adopt reuse. Here I linked the developer section of the website, which is really the best way to get started really, really quickly. And yeah, I don't know, do I have time for questions? Two minutes. Two minutes. Maybe I can take one. I also just a quick note. Carmen is here. She's one of the main creators of reuse. So we'll also be happy to answer questions afterwards. I'll take one now. A bad license. It's not an SPDX license. Ah, yeah. It's not an SPDX license. What does bad license mean? And it means that it's not an actual SPDX license. Yeah, but just on, yeah. How do you handle custom licenses? Yes. I don't think we handle them at all. You can make a custom license. Ah, okay. Yeah, so you can make a custom license ref within SPDX. So that SPDX allows you to do that, and then the reuse tool follows that. Yeah. Sorry, only 15 minutes.