 And there will be a buff on Tuesday, so if you have questions, you can answer all of them then. Okay, I have too many slides for this short talk, I think. I want to start with, well, what is copyright? Because before we talk about licenses and SPDX, yeah, what is the right to copy? It's a legal construct that defines that you have a right on your own work, on your creative work, and you simply have it by creating something. And, well, it's owned by you, you can give it away, it's sometimes even reasonable to give it away, you should go to Adrian's talk about giving it to the KDE in some situations. But you can see a lot more about copyrights at this link below, they explained really, really good. But I don't want to talk about the things behind copyright and licenses, but what to do and how to, well, allow somebody to use the creative work that you did. For example, you created a picture, you wrote a text, you wrote a source code, and you allow somebody else to do something with it. And the way to do it is, well, you grant a license to somebody else to use it under certain conditions. Such a license that you use for giving away your work, we call a free software license, if it contains four fundamental rights, which is the right to use it, the right to study it, the right to share it, and also the right to improve it. Then there are also two often used terms in copyright or in licenses, which is we have copy left licenses, which simply means you are granting a piece of work under a license and whoever is sharing it again with some improvements or changes has to keep the license. Mostly the same. And we have permissive licenses where the license may vanish during the sharing effect. So now if we talk about a source code piece of work, so I looked at some source code files we have in KDE, and this is a real work example from the ROX project. We have a license statement, also a copyright statement. Actually the copyright statement is not really necessary because you have your copyright, but to make it usable to the outside world, you already should state your copyright that you have an ownership on this piece of work. Here in that file, you can see there are a few contributors, Thomas, Hugo, Wagner, and me. We did some changes to the code, some significant changes which mean we have copyright over this code, and we stated what are the terms to use it. And this statement here is what we call a traditional license header or license statement that explains that whoever wants to use it can use this piece of code under the GNU, general public license version 2 or any later version. And well, that was it until some time ago, because this statement has a few problems. Legally, it's fine, but from the usability aspect, it's not that good because we have a long text that's, well, it's hard to read. For example, even the cute creator hides the copyright or license statement because they think it's too hard to read and nobody's interested in, but well, then nobody reads it and thinks that it shouldn't happen. For example, there are different ways to say that this code is under the GPL. You can even create your completely own license header, and you can use a license header where there's an address of the Free Software Foundation. And when the Free Software Foundation moves, the license header changes. And you can use one license header and modify it by hand, create a new license header out of it, and maybe you do some copy-paste errors, and then you have an ambitious statement. It's not clear if it's a GPL or an LGPL license. That is quite a big problem because we are talking about legal texts here. And just to bring an example, for the LGPL 2.0 or later usage and KD-FrameRox5, I found about 36 different license statements in all of our code. So that's not a good way because it's hard to read for humans. It's extremely hard to read it as a tool because we have to do some fuzzy checking, and it's never a good idea for a tool. So an improvement is to do something that's machine-readable. And for that, we have the so-called SPDX markers. There's a database, actually, at this link below, the SPDX.org licenses list, which lists a lot of open source licenses. And well, instead of just pasting and just adding such a long text, you simply say, this ID, look up this ID, and this explains the license of your file. SPDX actually does a lot more, but the two most important points there are we have a standardized identifier for copyright, this SPDX file copyright text, and an SPDX license identifier. And after that, you can simply add the ID or a specific format, the year, the ownership, and the contact to the auth. And well, if you look up SPDX, you will see it's quite a big legal spec written by legal experts, and you can express much more than simply the copyright and the license. There are many, many things next to it, and usually it's really hard to apply by developer. So there's initiative by the Free Software Foundation Europe, which is called the reuse.softwareinitiative. And that defines a really small subset of rules that you can use to apply to the project to make it machine readable and compatible with the SPDX specification. And well, we actually apply this since some time in KDE. It's done quite simple. Actually in a nutshell, you only have to do three things. You have to add the license identifier, you add copyright identifier for every contributor, and for the license, you add the license file to a certain location in your source code repository. For details there, we have a wiki page for how to, that explains how to do licensing with videos in SPDX, and that also links to the license policy of KDE. To bring an example, just look at the copyright header that I showed you before. If you re-convert it to SPDX or the reuse-compatible SPDX usage, then it's much simpler. We have identifiers for the copyright holders. We have one line that points to the license to use, and that's it. And it's machine readable and really, really simple. And that's a big idea. And it's actually important that we do it, because if we don't care about licenses, we can get to the situation where we have conflicting, contradicting licenses in the same application or same library. And that's the problem for distributions and everybody who uses the compiled binaries. We try in the KDE community to use licenses that are mostly compatible to each other. Actually, there are licenses in the world that are not really, not compatible, and you have to be careful there. So we have only a subset of licenses that we encourage to use, mostly GPL, LGPL, DSDCC. Also for all the details, we have a policy that explains when and how to use it. And the big problem here is often that you really have to be careful about the certain versions of the license, also in details at that page. And if we... Oh, time's up. Then we have good tooling that is just coming up. And we have a really cool tool to test everything. It's here on the slides. And the slides are attached to the talk and on the website. And if you want to convert your project, come to the booth and we explain how to do it. Thanks.