Interview with A. Cord-Landwehr about REUSE adoption in the KDE community

Cord-Landwehr: During our annual KDE conference in 2019, we had a workshop for planning the next major release of our libraries, commonly known as KDE Frameworks. During that session we talked about improving our license consistency by introducing SPDX identifiers, a core element of REUSE's best practices. Our goal was to establish automatic tools that would help to ensure license statement quality. This is quite important to KDE, because we have a long history and there are even files in our codebase, which are actually older than some of our contributors. Thus, those files might have seen many edits and license versions over the years.

"From the outside, it might look that the process of deciding and implementing something like REUSE might be tedious in a big community. But actually, it was quite straight-forward."

From the outside, it might look that the process of deciding and implementing something like REUSE might be tedious in a big community. But actually, it was quite straight-forward: as a kickoff I sent a proposal mail to our community list to start the discussion. In response to this, I was made aware of the REUSE initiative for the first time. And since the feedback was quite positive, the discussion resulted in a proposal to change our license policy with the goal to make it REUSE compatible. This proposal was backed with a detailed blog post that explained the background and the reasoning why to follow REUSE.

Well, the discussion quickly went to, "Yeah, let's do it" - and so we did. Of course, after some waiting time to ensure that everybody was aware of the move.

KDE Frameworks are a set of libraries on top of Qt. Many of these libraries provide useful stand alone functionality, like a library for handling archive files like zip, a library for barcode generation, a UI framework for touch interfaces etc. And then there are also those that help to make KDE software more consistent and integrated. As such, our KDE frameworks are a product of their own and especially the first group of libraries are used in many projects and businesses that build on top of Qt. For these "customers" of our frameworks, it is very important to have a clear licensing statement and ways to assure the statement is true.

We have many libraries containing source code that originates from different decades and originally might even have been developed for another library. To ensure that we still get distributable artifacts, we have a license policy which focuses on movability of source code within our code base. However, errors can be made and we spend quite some time in manual checking of license consistency and even relicensing of files in order to gain a desired outbound license of a library or application. For me, it was a key goal to simplify and improve this process by involving automatic checks and tools.

Over the years I saw other approaches for standardising licensing, but at the end, there are two key features of REUSE for me: even simple tools or scripts suffice to check REUSE compliance and to get data out of the license statements. Which is important because it allows to create custom tooling tailored to your project's needs. Secondly, REUSE focuses on being simple to use for developers. In a big community like KDE you often have newcomers or one-time contributors and it helps a lot if they can state licenses correctly and consistently with ease.

The main tool we use for our conversion is licensedigger. This is a self-crafted tool that I started with the only purpose of converting traditional license headers, with all their quirks and funny different statements, to well-formed REUSE compatible license headers. It also assists with the initial conversion of a code repository by adding the required license text files and reporting an overview of the used licenses. For the conversion we use a dedicated tool because we wanted to enforce a very strict license detection mechanism, and it allows to focus on reviewing the reference license texts that are added to the tool instead of reviewing every single license header when it gets replaced. As soon as a repository is converted to being REUSE compatible, we switch to use the REUSE tool to do quality assurance.

Another, still emerging tool, is a CMake build system plugin I created to instrument the REUSE tool together with the build system information, in particular which source file is compiled into which artifact. This allows to generate license consistency checks as simple unit tests, which warn the developer if accidentally incompatible licenses are combined.

Our codebase is big and major parts are still waiting to be converted into being REUSE compatible. But there is progress! And I am extremely happy that this progress comes from many different people and not just from one person. Believe it or not, there are nicer things in the world than doing or reviewing license statement conversions all day long :-)

So far we mostly talked about inbound licenses. But I think that for compiled languages like C++ it is important to also take binary artifacts and their outbound licenses into the picture. This is a task that many distributions handled over the years with custom license checkers and an enormous amount of manual review, to ensure that the source licenses are compatible with the distributed outbound licenses.

I believe that it is possible to find a way that states the outbound license in a standardised way, which would make those statements reusable for users of a binary artifact. This would allow a completely new dimension of automatic license compatibility checks.