SPDX License Headers (for KF6)
cordlandwehr at kde.org
Sun Nov 24 18:04:50 GMT 2019
Hi and sorry for the really long mail. (busy readers with SPDX context, just
look at point 5; readers without SPDX experience, look first at the end of the
This mail is about getting prepared to use SPDX license headers in KDE
Frameworks (and anywhere else, where we want to use it).
During the Akademy KF6 BoF there was much support for the idea of introducing
SPDX license headers in the KF6 sources. I got the same response in several
further chats, which gives me the impression that such a move is mostly
uncontroversial. Thus, I would like to get (legally) ready for really doing
Today, I had the opportunity to grab Mirko and Ade and we sat together to talk
about the legal bits (there will be technical bits, but those or mostly the
"doing" stuff and are not in the scope of this mail). The points from our
today's chat are the following (@Mirco and Ade, please object if you remember
1. SPDX is the way to go for specifying license headers and we are joining the
party already late.
2. We have to be very clear in our discussions about SPDX to distinguish
inbound licenses (the license a contributor assign to the code by adding a
license header) and outbound licenses (the license a library/application is
released with by KDE); inbound and outbound licenses can differ for a
framework, e.g. when not all source files have the same license, then the more
restrictive license has to be chosen.
3. Files should not mix two license headers. This means, the SPDX headers
shall be used to fully replace the existing license headers. However, by doing
this, they must not change the meaning of any license header. By mixing it, we
expect them to deviate at some time, which would lead to having inconsistent
licensing information in our sources.
4. LGPL-2, LGPL-2.1, LGPL-3, LGPL-2-or-any-later, etc. licenses are straight
forward and can be directly be used from the SPDX list.
5. The next big question is: What do we do with the (L)GPL licenses that have
a "KDE e.V." exception?
- In our license policy we name them "LGPL-2.1+3+KDEeV" (see <https://
community.kde.org/Policies/Licensing_Policy#GPL_3.2BKDEeV>), yet the values we
are using there are not official SPDX markers.
- During Akademy, I requested at the SPDX GibHub project such an official marker
(<https://github.com/spdx/license-list-XML/issues/928>). Yet there were two
responses, which actually propose different solutions.
- Today, we came to the point that we think the best next step is to request a
clarification from OSI how to name the license, which we are describing in our
license headers (i.e. with the KDEeV-exception). Essentially, we would name
the license "LGPL-2.1-or-later-or-KDE", but would ask OSI to confirm before we
bring this topic back to SPDX.
Do you have any comments, amendments or even rejections to this approach?
Or shall we simply proceed?
PS: a few SPDX Details:
- SPDX provides standardized language to express a license
- the language is machine readable
- it allows automatic checking of if a combination of licenses (e.g. the if a
library's license is valid by checking its source code licenses)
- SPDX is adopted by the Linux Kernel to specify the source code licenses:
More information about the kde-community