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
