SPDX License Headers (for KF6)

Andreas Cord-Landwehr 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 
mail).

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 
it.

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 
differently):

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?

Cheers,
Andreas

PS: a few SPDX Details:
- SPDX provides standardized language to express a license
   --> https://spdx.org/
- 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:
  --> https://www.kernel.org/doc/html/latest/process/license-rules.html





More information about the kde-community mailing list