 So, thank you for joining me at this quite early hour in the morning. I'm afraid you also just got up, but we dive directly into a quite complex topic which we try to simplify. So this talk is about reuse. Reuse tries to simplify licensing code and also declaring copyright and so on. So the idea here is that we want to make it easier for people to use free software and to license free software or open source code and this is made possible by reuse which is a set of best practices basically and also tools that simplify all of this. A few words about myself. My name is Max Mehl. I work for the Free Software Foundation Europe, the FSFE, and we are a charity that empowers users to control technology. In this presentation we will first have a look at the whole sphere of issues that we have in the field of licensing which some of you may also perceive either as a user but also as a developer, as a re-user of third party code or also as a package maintainer which some of you might be. So we will have a look at these issues that you might have and at the solutions and the principles that reuse gives. We will manually make a whole repository reuse compliant and conformant with the best practices. Have a look at the tool that reuse offers and also the API. And last but not least I will give you a few pointers for next steps in your career or path for reuse and I hope that some of you in the BST community will also adopt reuse for their projects. So this is how a very simple repository might look like. We have a C file, we have a make file, a readme file, so text files, and we have here two JPEG images. And let's assume in this example that the images are not by us. So we took them from a third party. So how would you normally tackle this issue now? We will add this license file that you can see here. This could be let's say a BST two clause license. But that isn't sufficient, right? So first of all we have one license file but we have stuff from the two different licenses or even more we don't know. Like if we add a library and external CSS file from someone else or a different copyright then we run into issues. How do we do that? How do we make clear that these pictures up there are under different license by different copyright holders whose conditions for reuse we should respect, right? Yeah, now it gets complex here with these things. It could also be that for instance the C file contains code by other people. So in this case there are several solutions and all of them are rather I would say non-ideal. And we have a few additional issues with licensing and copyright and all of this. And some of you may already have stumbled upon them. So most prominently we have missing information about license and copyright of your own code or also a third party code. So either the user or even yourself as a developer don't know anymore about the license and the copyright whether something is compatible whether you can for instance make a BSD package out of it because as I know not every license is allowed to be uploaded or to be used in a BSD distribution. And also reuse it like if you're a developer and you share your software with other people they can also reuse it. Use it in their own code. That's the great thing of free and open source software. And it may well happen that they overlook your chosen licenses. So perhaps they see a license file but perhaps they don't and they just ignore it. They just copy a file from the internet from a public repository. And this can happen for all funds or also for individual files like let's say you have a third party library in your repository from a different copyright holder perhaps under a different license. And the reuse just assume oh well that's from this person who just uploaded the code in this repository. So I take him or her as a copyright holder and I just take the general license that I somehow find. But that might not be correct. And as I said before how to deal with multiple licenses and there's also the issue of license ambiguity like you know there are different license or versions of BSD licenses but most prominently also GPL licenses version two version three only this version or later versions or AJ GPL or like all these variants and exceptions that you can see you should somehow communicate that in a clear way. And everyone who gets on board on the project may be a BSD distribution or some other free software open source project. All of them need some sort of training how to deal with this ideally. Like they add some code how should they end their copyright. They take a third party library how to do that. And overall we have a lot of conflicting best practices right. So we have organizations that propose some ideas how to solve some of these issues. We have some distributions like the Debian project. I'm sure also within BSD projects that there are also some best practices. And unfortunately most of them conflict and they often do not solve all the issues that we see while still making it very simple for developers and users. So that is why before 2017 or in 2017 we asked ourselves how can we make licensing and copyright easier for everyone. Easier for everyone for users for developers for re-users of code for package maintainers and how can we really keep it simple without like creating another big standard or big best practice that just conflicts with everything else. And the result of that was reuse. Here are some of the principles of reuse. So we want to make it easy as I said to find copyright and licensing information for every single file in repository. And that's probably something that is quite unique to reuse that we target every single file in repository and not like one or two license files that somehow say which licenses are available in this repository. We also avoid silos like there are some projects, some initiatives that somehow try to find out the licensing and copyright information but they store it in a database somewhere else or even in a web service. What happens if this database is not available anymore? Of the web services down and you don't have internet. So this is a silo and we want to store this information that are just covered inside of the repository. And we want to make it readable for humans and machines. So for humans, that's quite obvious. So that the human developer can just see or quite easily see a file and say well this is under those license and copyright holders. But also for machines like we have a lot of cool tools that scrape repositories find out whether everything is compatible and whether some files are missing. And so this should also be readable for them. And overall, we did not want to reinvent the wheel. So we had a really strong look at all the initiatives out there and we want to be compatible wherever possible. But sometimes we also have to set up our own rules and I hope and I'm really sure that this is for the better. And last but not least and this is the most important thing for us all the time. We want to make licensing and copyright easy and fun for developers. I know this is a tough topic, this is a dry topic, but it's so important. It's important that we respect the licenses of developers, that we make clear our terms of reconditions to other people, to companies, to users, to other developers. And it's important that this is possible for every project size. So that you don't need a legal department behind your back covering you and fixing your issues. But that you can also do this for the one person project or for a small community. So these are the principles. And all of this is solved by, let's say, three simple steps that the reuse best practices propose. And I will now guide you through these steps. First of all, rather manually, but later we will also have a look at the tool that reuse offers. So this makes things a lot easier. The first step is to choose and provide licenses. So let's say you have a new project. First of all, you should think about, really think about how under which license you want to publish your code. That's up to you. We don't make any recommendations or any like preconditions you can choose licenses for free. And you have to provide them, like you have to provide the full license text in some way. The second step is probably the most work-intensive one to add copyright and license information to each file. If you start with a project from scratch, that's quite simple. If you have an existing project, the more files you have, a little bit trickier it might be, even if you have a, or especially if you have a long history of the project, or let's say you take over maintenance ship for another project. And of course, you would just have to dig a little bit into it and find out what was the licensing and copyright history. But once you've made it, it's quite simple to maintain. And the third step again is quite simple. You're asked to confirm reuse compliance with a reuse helper tool. So as I said, I will now go into this process to make you understand it in principle, but also later, as I said, we use the tool for this, which is much simpler. So first step is to choose and provide licenses. So as I said, you choose the license and you were asked to save the license text inside of a licenses directory. So that's quite rather new for, or with reuse. So traditionally, you had a file called license or copying or something else. But as I said, it might become tricky if you have two licenses, three licenses in the project, which is very common. So there are also different conventions. We say, let's set up a directory for this, a dedicated directory where all need license text files are stored in. And the trick here is that we name them after the SPDX license identifier. What is SPDX? SPDX is an initiative, meanwhile under the Linux Foundation. And I would say their main contribution is that they have a list of licenses, of a lot of licenses, and they gave each of them a unique identifier. So for all these different versions of BSD, GPL, but also like other common licenses and really uncommon licenses, they have a unique license identifier. And if there's a license, which is not on the list, there's also a standardized way how to mark this. So that you have some kind of an identifier. And in this example, we have rather back to the example from the beginning from the screenshots. We say, well, we start with a BSD two clause license here and we have the licenses directory. So let's start with this. That's your main license or your license for your code. Now we label the files inside of the repository with this information. So ideally, as I said, we want to have it as close to the file as possible. So inside of the repository. And for this, we have two, let's say, tags. For the license, we use the SPDX license identifier tag. So here we are now in machine readability, like if a tool sees this and the string behind, it can guess or it can say under which license the file is under. So we don't need these big license notices or so. And we have the copyright order. Here, traditionally it was rather common to use just copyright with a C symbol or something else. We suggest the SPDX file copyright text. Again, here we are at machine readability, but both are supported. So in the example below, let's say this is the C file. We have it under our BST2 clause and we have two copyright holders for some reason. It's Jando and it's also Fubar. And both of those strings are supported. You can have multiple copyright holders and one license identifier, where you can also say you have two licenses or it's dual license or something else. So what can you do if the file itself is not editable? So you cannot add text on top of it, like a JSON file or as a picture. So the first is to create a separate dot license file. So let's say we have a picture cat.jpeg, you create a plain text file called cat.jpeg.license. And inside of this text file, you can just add the same information that we've seen before. In this example, it's now under CC by 4.0 license because we took the image from someone else, namely from the create artist. So this works quite well if you have a number or a few number of files which are not editable. Now let's assume you have a directory full of JSON files or a directory full of icons, 500 icons. What do you do then? Of course you could create 500 additional dot license files, but I see that this is not really practical. So for this we adopted the depth five standard by the DVM project. So this is the way how they label in one file or mark the copyright and licensing of all files in a package. And we just adopted it and said, well, here you can bulk license files or files that you could not edit directly. So let's say in this example, you can scrap the first five lines. We have now all files in the IMG folder, which are now under the copyright of the create artist under the CC by license that we've seen before. So that's another clever way how to label copyright and licensing for your files. And with this combination, the header, the dot license file and the depth five file, you're quite easy to set and can label all files. A small teaser, we are also working on an additional format since we see that the depth five format is a little bit strange or parked, not so well fitting. I will come to that a little bit later. Then the third and last step is to confirm reuse compliance. So you can install the reuse helper tool to check for missing information. The helper tool is a Python tool, quite easily installed, quite lightweight, which can also be used in CI pipelines, by the way. And you just run the reuse lint command within your repository. And it goes over every single file in the repository, which is not, you can award for instance. And it checks rather for every single file, there's copyright and licensing information available. And in this case, in this very simple repository, we have only six files. And we say we have here now used licenses, CC by, the BST two clause, but also CC zero. We will see that later because we say, well, we have one additional CC zero file, for instance. And the last line is the most important one. It says, well, your project is now compliant with the version of the re-specification, the current one. So great. In the end, your repository might look a little bit like this. So we have on the top, we have the dot license files for the pictures. We don't have the depth five file in this example. We have a number of licenses. In this example, it's gpl3.0, just from the screenshot. In this case, it would be your BST two clause license. And you have the other files where you cannot see licensing information from the outside, because we wrote the information inside of the files as a header. So to wrap it up a little bit, what are the specialties of reuse? What reuse brought new into the game? Don't we have the license text file stored in the licenses directory? I would say that's a huge gain, because now you can see on one side of the eye which licenses are available in your repository. You don't have to click in the license file or trust on heuristics or proprietary platforms like GitHub to tell you which licenses is in there. You can just see it from the outside. Then we're quite special in the way that we recommend or we require that every file shall contain some sort of information about copyright and licensing in either of the three ways that I just highlighted. We offer alternative for uncommentable files that was not existent before. And we provide unambiguous copyright and licensing information. So you no longer from the outside as a user but also as the developer and package maintainer, no longer are unsure what was the license of this file that I just copied from the interwebs. No, you just know it now, once you label it. Over the course of the years, like we are now in the, or completed the fourth year of reuse, we develop the number of components. First of all, we have these best practices. So that's the core of reuse and also quite formal specification. This is ready to be integrated by communities but also by industry. Then we offer to lower the threshold a tutorial and an FAQ. So you can go on reuse.software. You see an example repository and can just follow the steps which we also go through now. And a large FAQ, which is not only focused on reuse per se but also explaining what is licensing, what is copyright, how does this all work and some other frequently asked questions. So have a look at it. Also, if you're generally interested in the topic. And we have the set helper tool. So with this, we support developers in making their projects reuse compliant. And we try to automate or see me automate a lot of things. And I'm very confident that we now can run a demo. Hope the demo gods are with me today. Off the tool. Exercise is okay. So I will now go again under this example repository and show you how the reuse tool simplifies a lot of things. So let's first have a look at the whole repository. Again, we have a gitignore file, a very simple text file. We have these two images, the JPEG files. We have a make file, a read me file and the C file. And with a few commands, we make all of them reuse compliant or the whole repository reuse compliant. But first of all, let's check the lint status of reuse. You can see, well, we have missing copyright and licensing information for every file here. So no file carries any information. And because of that, the whole project is not compliant with the reuse. We will change that now. We use the add header command and say, well, now we label the C file, the make file and this markdown file with a copyright holder on the Jane Doe. Let's assume this is us and license the BSD to clause. And the tool detects automatically the license or the file types and also the comment style. So we will see here with a diff command that it added now to the make file, to the read me file and to the C file, the correct information, like these two texts here, the file copyright text and also the license identifier and in the according comment style of the file type. So now these files are labeled. Now we take over the image files. So we have now all files, we say all files here in the IMG folder. And now by this great artist, which we took from the internet, for instance, under CC by 4.0 license. So I say it again, these strings here are by the SPDX project. So you can see on SPDX.org slash licenses, I think, all the different types of licenses which already have a tag, which is a lot. And well, we use now understand this. And you can see here, it created an additional file. Let's have a look at one of them. Or let's see here, we have these two files here. Let's have a look at the content of the cat file. And we can see here the same tags. We have the file copyright text with a great artist and this license identifier. So we take now the last file, which is a gittignore file. And we say, well, it's so insignificant. We don't want to have any copyright in it and well, make it just really usable. Could also be a picture and you say, it's very close to the public domain, for instance. You say it's insignificant. So for this, we suggest the CT0 license and we just add the header here. And it's now, well, having this information. So what do you think? Are we now, we just compliant? I mean, now we labeled every single file. So we should be good, right? Unfortunately not. So we have here missing licenses. The tool detects that we have the BSD2 clause. We have the CC by license and also the CC0 license in these files. So these files carry the information that we have missing licenses. Of course, because we didn't download the full license text of all these three licenses. Now we could of course go to any website on Creative Commons, but also on the BSD project trying to find somewhere the license file or copy it from another project. That would be extra work, but the reuse tool automates this. Just say, reuse download dash dash all. With this, the tool just downloads all the licenses text files, which are used inside of the repository. You could also say, well, I just don't want to download an additional license and give the SBDX identifier afterwards. And since we have internet, we downloaded all the things here and now we are fully reuse compliant. Because now we have all the three steps completed. We have the license text files. We have labeled all the files in the repository and we now check to do with the reuse tool. And as the cherry on the cake, you could also create an SBDX bill of materials. Probably not really useful to most of you if you're working as a compliance officer in a company or so that might be useful. It's very simple for the reuse tool to do. Yeah, it's a bill of material. That's it. And this is the tool. And of course, you can do a lot of things with it, especially in larger repositories, thanks to the wild card feature. And yeah, you can automate a lot of things. It's just a small look at the features that the tool has. You can also participate in the tool. Of course, I would later show the links to the repositories and yeah, participation is very welcome. We already have a lot of automation going on. I just see the chat. I don't follow it during the talk. It's licensed under like the main license here is GPL 3.0 or later. Probably that's not ideal for UBSD people. It also contains code of other license holders. Of course, it's really compliant so you can just see the whole license information. I will now go back to the presentation. Great. And well, these are now the three components that we have and we have a last component or another component, which is the API or the batch. So the idea here is that we don't want people to always have to install the reuse helper tool, although it's quite simple, to check whether repositories reuse compliant. And we also want that people can show that their repositories reuse compliant. I mean, that's a big step, especially if you have a larger project. And for this we created basically reuse as a service, you could say. You can register your project online and get a dynamic batch that continuously checks whether your project is still reuse compliant. And also here we have a demo. Okay, demo is a little bit too much. We just show you how the API service looks like. Here we go on API.reuse.software. And well, what we can see here already is the already compliant projects that we have, which is currently, oh, 750. It's growing quite fast. And you can see all the here rated after the last check or sorted after that last check. We can see here this project. We can say, show me this information about this project. And we can have now a current check or the latest check of the reuse API about this project. This could be your project, by the way as well. And we see here the lint output that you already know. And we have this batch, which you can copy the markdown code for and just add to your readme file, for instance. And quite important, we are not bound to any special code source forage. So you don't have to use any proprietary software. Basically, we support everything we just get. We are currently working on also supporting the curial. Also here, contributions are welcome. Also the code of the API and everything else is of course also free and open source software. And to register, you just go here and check my repository. You just enter your name and email, which is to confirm that we have a valid person here. And you add your project URL. As I said, we currently support git. And well, then you get an email, confirm it, and you see the link to your last check output. Add this to the readme file or somewhere else and it continuously checks whether your project is still reuse compliant. So that's really great and very simple. But of course, if you want to check the reuse status during your development phase, like for a pull request or so, I would always suggest to include it in CI pipelines. So we have Docker images, GitHub actions, whatever. It's quite simple. You just run the reuse lint command some step and you can see for instance, with a pull request, a merge request, whether something is still reuse compliant. So, going back to presentation, they're almost done. Okay. Yeah, sorry for all the switching here between the different screens. No, doesn't need to take my, okay. All right, so I just want to give a short outlook on the ongoing developments in the reuse project and initiative. So of course, we are currently continuously working on the tools. We want to improve the tool, also add more automation for the reuse helper tool, but also with the API. Again, here suggestions and also contributions are very welcome. Everything is developed in the public. We work on the specification and here especially we want to add another possibility to bulk license files with a reuse YAML file, which you can have one or multiple files of. And this reuse YAML file is in the YAML format. So easier to parse than the depth file format. And well, it's more flexible in a sense. And we also want to enable snippet declaration. So let's say you copied a larger bunch of code from Stack Overflow, which is always under the CC by SA license of some sort under different copy right holder. And if you want to market, which you should, then this is currently rather complex or not even working and not supported by tools. And we also want to support this but of course we have to coordinate a lot here with the other projects that we work with. Then most importantly, I'd say is to integrate reuse in different platforms. So that it's easier to use with different version control formats, but also like let's say softforges, like GitLab, GitLab, GitHub, Git here, so that it's more like reuse check by default, ideally. And also with other initiatives in the whole license compliance field. And we want to spread the word, I would say this is most important. So we want to support communities, but also companies with adopting these best practices because the more people use reuse, the easier it is for everyone. Like I'd say you want to reuse code from a third-party project and it's already reused compliant. It's very simple for you to respect the copyright and also the license by this third-party because you can just easily find out which license, which copyright holder, can copy the file or contents from the file and you're good as long as your license compliant, of course. So we want to spread the word here and this is also where I'm speaking to you today. And I hope you help me with spreading word in the BSD community. Speaking of people who use reuse, who are the adopters of reuse, that's quite hard to say because since we don't have a central instance or a need to register somewhere, we know of these 750 plus registered API projects that are reuse compliant. Then the FCE works in the Next Generation Internet Project as a consortium partner where we help these projects who which applied successfully for funding by the European Commission and which helped to make the internet a better, safer, more privacy-friendly world place. We help them to become reuse compliant and already did so with more than 100 projects. Then the quite well-known KDE community changed their policy or contribution guidelines to reuse and they already made their frameworks basically the basis of most of their tools already fully reuse compliant. Then we have the Linux kernel which is, I would say, 70% reuse compliant already which is quite a success given the very long history of the whole project and also the quite complex licensing situation with all these exceptions drivers and companies which don't exist anymore. So here we are roughly at 70% and they're still working on it. And on the more corporate side which is also important, we know that reuse is part of the policies of Siemens, the European part of Huawei, SAP, LiveRay, Linux Foundation Energy and probably many more. They don't tell us, we just find out by randomly most of the time but it's really great that we now have more doctors in general and I hope that you will become one too. So what are the next steps for you if you are now interested in reuse? Well, the easiest one is to sign up the mailing list and take part in all the discussions that we have in the project. So this is rather low frequency so no harm done for your inbox and we develop reuse quite in the open. So all these specification changes also tool like larger steps with the tooling, we announce on the mailing list, we can discuss there. So if you're somehow interested in all these topics, just sign up the mailing list. Then the next easy step is to make one of your projects reuse compliant. You don't have to start with the biggest one, you can take a personal one or a smaller BSD project and just try out reuse for this. Then a cool step would be to integrate reuse in your community. All these BSD communities, communities around the BSD ecosystem are very important in general operating systems, distributions, so it would be great if we had more adopters here and also have the input and feedback by them and it would be great if you can make a start here. You can of course contribute code to reuse, to the API, to the tool but also textual wise to the specification, FAQ and so on. And most importantly, please help others to adopt reuse. Once you understood it, help others to make this. We're just a smaller organization and we need like the mass effect by other helping each other to make licensing and copyright much simpler than it is today. So with this, I end this talk, I'm looking forward to your questions. If I cannot answer all the questions, please just ping me via email on social media, join the mailing list, join the repositories. Yeah, thank you very much for intending my talk. So how do we do this with the questions? In the shared notes, so I would just have a look at the shared notes. Is there an option to lint that will download the missing license files? No, these are separate steps if you mean that. So you make a lint and depending on the output, you can say, well now I want to download the license files that are missing. Of course, you can just combine these two commands, but we don't have it in the tool. Are there any significant situations where this entire model software sources have specific copyright holders and specific licenses breaks down? I mean, this model has solidified over decades. Are there any changes in legal environment, ETC, which make this model outdated? I'm not aware of any, to be honest. I mean, that's the way how free software and open source software develops, right? So we don't have these silos of code, but we stand on the shoulders of giants. So this is why this community, this whole ecosystem develops so quickly and so steadily and so with such a high quality because we don't have to reinvent the wheel all the time. We can just use components by other people, of course, respecting their conditions and making sure that these licenses are compliant. But I would say it's, I didn't see a big benefit in reducing the complexity of the model. I would say we have to make it simpler for people to live in this world. And I think it's a larger step in this direction. Oh, they're piling up the questions. Does the tool flag up or deal with a case where someone has manually used the spelling license instead of license in the directory name, file name or the header? In one case it does, yeah. We have a currently still in a working in project progress feature, which lists all the supported licenses that we have where we have an alias for the different spelling types of American and British English. Actually, I never found a case where like attack was mistyped, like for instance, the SPDX license identifier. I guess this is because most people use the tool which use American spelling for the sake of simplicity. And I'm not aware whether the SPDX project where we borrowed all these terms or from deals with a different spelling type. So I'm not sure if we have a case or where we see this is really an issue. We could think about how we flag this and not mark this just as an error, which it is, unfortunately, but where we give pointers to the reuse tool users in how to circumvent this or how to fix this easily. Buck report your license file. JPEG.License is missing in ending line fee. Yeah, there's an issue. I thought we sorted this out. I'm using a development version here. So it seems we have a regression buck here. I noticed that as well and I'm sorry that you noticed it as well. And yeah, hope we can fix this soon. I think there's still an issue. What's the legal status of reuse? Was this challenged or is there a lawyer who watched for this scheme? I'm not sure what you mean by this. Perhaps whoever wrote this could clarify this or also speak up. I'm not sure whether you want to do this. I will just cover another question here down below. And do you have ways to audit legacy projects which already have explicit licenses over a hundred of files? Not really. I mean, I know there are different conventions of labeling these files. And I mean, DVM project, for instance, some maintainers put a lot of work into making sure that all the different licenses and copyright situation is well reflected in the depth five file in their case. But also like the Linux kernel was not unclear in a sense. They just had a whole mess of different ways how to communicate licensing and copyright. I would say like these license notice headers, these two or three paragraphs which somehow try to explain the license and the conditions. And I mean, there are some tools I know from the KDE project. I think it's called license digger which at least like in the KDE sphere tries to detect these big notice headers and converts them into their corresponding SPDX license identifier, which is great. I know that the Linux project also has a similar tool. I think it's still in the main tree. For reuse, we thought it's rather hard because it's some kind of heuristics. So we don't want to interpret someone's license headers which is often quite complex which would also blow up the project size of the reuse helper tool and the complexity. So we said, well, actually, if you want to become reuse compliant, we really recommend to use these unique identifiers which are unambiguous. And this is also the reason why we opted to not use these heuristics and just say, well, that's in the, I know it's in some extra work but let's start from scratch or let's overhaul all of this and use the modern, simpler and easy to understand the way how to propagate the licensing and copyright of a project. So going back to the other question, the legal status. I mean, it's stuff that needs to go to court at some point. So it's going to stand up. You mean because of the way how we label the files? I would say, I'm not sure whether it has been tested before. I'm not a lawyer. I didn't follow up any case law but since the SBDX license identifier is around or has been around for, I don't know, more than 10 years, of course with growing usage, we have these SBDX bits of materials that we've seen. Now SBDX has recently become an ISO standard. So the way how to label or to communicate different kinds of information for files like in the reuse case, copyright and licensing. In the SBDX case, you can communicate a lot of things more is rather common standardized. And I would say it would be a relative many court cases. So I don't see a reason for this. Of course, it can become complex. Let's say the Linux project longly argued about what to do with these copyright notices or license notices that I just talked about. Whether they can just replace it and replace it by the SBDX license identifier and delete all the old text. I think the solution here was that they, in the funds themselves, they deleted the text but that they have an archive basically of all the old license notices and so put them to a separate file to somehow archive them. I think that was their solution. And I think for this, there's no case law already out there which defines this, I'm afraid. What about using common fields for binary files? For instance, JPEG and PNG file can include copyright. That's true. It's also for like, for Enscape, the vector graphics files and some others. We said over the different development steps of reuse that we don't want to support them for different reasons. First of all, it's not from the outside directly visible for people. So if I open a JPEG file, I don't immediately see the license and the copyright holder. It's very simple to override. Like if I run it through a mini fire or so or through a compressor, then this information is lost. If I cut the image out or modify it in some way and some other tool, the information might be lost. What cannot be lost is the extra.license file or it's really like it really jumps in your eye, right? The same is true for storing this information about copyright and licensing inside of the version control system. So there were also ideas and also recent or earlier reuse versions of the specification where we said where you can also put the information inside of the version control system as meta data. And we also said, well, it doesn't bring anything if I just go on a public repository and open the file in the raw format to copy out the text and I don't see any copyright and licensing. It's easy to forget if you migrate to different control systems. So where we said, well, let's use ideally plain text files where we're possible as close to the files as possible so that we avoid all these different issues. So follow up. So I'm not going to move to reuse without any kind of legal assurance. Even though BSD licenses are cumbersome, we know they work in court. SBDX ISO and everything, that's not enough as a risk reassurance, sorry. I mean, I would be happy to discuss this with you later. I'm not sure whether we can cover this now here. I mean, the BSD license still persists. You have still the BSD license in your file. You can still have the copyright notice, the big header in your file. All you need to do is to add the SBDX license identifier string and some kind of copyright information. That's all you need. And I mean, that's how the Linux corner works and I know a lot of court cases at least around this. Sorry, I'm not so much in the BSD field but I'm sure there are also some court cases here. So it holds up in court. It's just some way how to label the information. So I'm pretty sure it would stand up in court although I'm not a lawyer. I'm not aware of any counter case. Probably there are also cases which can assure you or make you more comfortable with using SBDX. But again, please feel up to bring up this question on the mailing list. We're also more lawyer-ish competent people than me and I would be happy to discuss this and also like clear up your doubts. Do we have any more questions? I don't see any. There's some discussion here. Not sure how much time do we have left or shall we just close the session then? Okay, I mean, I will go over through this other chat instance, we can continue the discussion there. I will be around for a few minutes. Unfortunately, I have to leave afterwards due to my family, but otherwise since there don't seem to be any additional questions, I would again like to thank you for your attention. I hope I convinced you to adopt reuse in some sort, at least have a look at it. I would be really much interested in learning how the BST community thinks about this. I know like operating systems distributions have quite special ways and also a lot of experience in labeling, licensing and copyright. And yeah, I would love to learn how we can combine the work here and also learn from each other. So please join the mailing list, please join the discussion afterwards and thank you again.