Home [ade] cookies

KDE Licensing Policy

I have been invoked by John Layt to explain some bits of the KDE licensing policy. It’s related to my recent writing on copyright assignment in the sense that it discusses reasons for picking particular licenses and how licenses interact. The back story is the KDE Licensing Policy, which lays down which licenses are acceptable in the various parts of the KDE platform technologies and applications. Roughly, the libraries need to be liberally licensed (which means they can be taken proprietary or shipped with otherwise closed devices — a common choice of GUI libraries nowadays). More concretely: (LGPL 2.1+) or (LGPL 2.1 or LGPL 3 or later approved) or BSD or MIT or X11. The idea is that you can either go for any version of LGPL from 2.1 onwards, or only selected versions of the LGPL which have been approved by the membership of KDE e.V. (if you don’t want to give a blanket permission to the FSF to update the license terms) or something very liberal.

You must offer the choice, though: you cannot put just the LGPL 2.1 on there: it must be “or later”. You also cannot just put LGPL 3 on there. It must be “version 2.1 or version 3 or any later version approved by the membership.” That’s KDE policy. There is a technical (well, licensing-technical) reason for this as well, and that is license compatibility.

The issue of compatibility is more pronounced in applications, where we also allow GPL variations similar to the LGPL variations mentioned above. The reason is that the GPL version 3 is incompatible with the GPL version 2. As long as there is GPL version 2-only code somewhere in the software stack, we must be able to license the software under something compatible with that license — and that means the application code must be available under GPLv2 (or something else, but not GPLv3-only). Let’s take a look at the licenses used in libraries in a typical KDE application. I’ll use Konqueror on Kubuntu 9.04 as an example, with ldd providing the list of libraries. Here’s just a partial list:


Now, it’s important to choose at the moment of running, a license for each component such that the whole is compatible. For each component there must be a concrete choice made. So for libfreetype I could choose the GPL (I guess it’s version 2 only then, but the Debian copyright file gave me no additional information and I’m too lazy right now to look it up), and then all the other choices I make need to be GPLv2 compatible. And now you see the problem looming: if I choose GPLv2 for the Freetype part, then I can’t mix in any GPLv3-only components. Or conversely, when you put in GPLv3 code into a KDE application, you are forcing GPLv3-compatible choices in the rest of the stack.

I don’t see any GPLv3 incompatible components in this listing, but that doesn’t mean there are none anywhere in the stack, ever. So we don’t want to force the choice for GPLv3 by including GPLv3-only code. For the purpose of risk avoidance we have the policy requiring licensing as GPLv2-or-later so that we can, if need be, choose the GPLv2 version to remain compatible with GPLv2-only compatible libraries. So it’s basically us keeping license compatibility with software components using older licenses. But it’s uncomfortable to me, because at some point we might end up in a jam with license versions as other parts of the software stack migrate (although very unlikely with all the liberally-licenses software in the stack).


5 Responses to “KDE Licensing Policy”

  1. Alex Merry Says:

    Just checked – libfreetype is indeed GPL2 only (plus FTL).

  2. Stephen Says:

    “Now, it’s important to choose at the moment of running, a license for each component such that the whole is compatible”

    This is the part I don’t understand. I thought the (L)GPL governed distribution, but did not restrict use. Why must I make a choice of which licence I’m using the work under at the time of using it?

  3. adridg Says:

    Thanks for checking. That means I really need to read up on the FTL and add it to my list of badged licenses (for ease of reference later). The FSF says FTL is GPLv3 compatible not GPLv2 — so we end up with being able to choose *something* compatible, anyway.

  4. adridg Says:

    Bear in mind it’s more the GPL (not LGPL) we’re talking about here, but still: before you *run* the program, you create a modified version in memory (by linking it with the libraries it depends on). At that point, some license conditions may be triggered. It’s the means (interpretation) through which the FSF interprets the GPL to mean “you cannot link a proprietary-licensed program with a GPL library.”

  5. The FreeType License « Bobulate Says:

    [...] return to my earlier consideration of KDE license policies: there’s nothing there that makes it impossible to have GPLv3-or-later code in there [...]