Hello, Thanks, Andreas, for getting this important discussion started.
> On 24. Nov 2019, at 19:04, Andreas Cord-Landwehr <cordlandw...@kde.org> wrote: > > ... > 1. SPDX is the way to go for specifying license headers and we are joining > the > party already late. We should not feel bad, we are not that late. However it is kick off this effort now to be ready for the new release. > > 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. Agreed to all the points. One key goal should be to make the license statements machine readable and following the REUSE principles. I think the KDE community is generally doing well in this regard. We should however go through the REUSE specifications and make sure we tick all the boxes. > 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 > <http://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 > <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? Again, “machine readable”. Getting a proper SPDX identifier for our policy is the right approach. The alternative of using a combined SPDX expression may be correct, but it looses the details of our own policy. I support the suggested approach. Best, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. Qt Certified Specialist and Trainer Request a meeting: https://doodle.com/mirkoboehm
