On Tue, Jan 23, 2024 at 4:52 AM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote: > > Lots of packages in Fedora use license LicenseRef-KDE-Accepted-GPL and LicenseRef-KDE-Accepted-LGPL. These licenses were never approved. It took lots of time to discuss it and document it. We finally come with: > > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_licenseref_kde_accepted > > (copy for your convience) > > > KDE project uses LicenseRef-KDE-Accepted-* licenses. This was discussed here and here. The consensus is that upstream license LicenseRef-KDE-Accepted-GPL should be replaced in Fedora by GPL-2.0-only OR GPL-3.0-only. And upstream license LicenseRef-KDE-Accepted-LGPL should be replaced by LGPL-2.1-only OR LGPL-3.0-only. Thinking about this some more, it's a little confusing and a specific case of how we have been somewhat mixing up two issues, (1) approval of licenses for Fedora, and (2) policy on what should go in the License tag. I've been trying to revise the legal docs to clear some of this up. The KDE formulation is basically an alternative to the traditional "or any later version" approach to *GPL licensing. Basically, instead of allowing blanket use of future versions authored by the FSF, KDE is saying you can use future versions authored by the FSF and authorized by KDE. I'll call this the KDE "proxy" permission because the term "proxy" is used with this scenario in mind in *GPLv3. "LicenseRef-" is an SPDX construct that allows creation of custom license identifiers (i.e., license identifiers not on the SPDX license list). SPDX has to date chosen not to adopt any sort of namespacing system for LicenseRef-s despite some proposals. So the KDE LicenseRefs are not Fedora LicenseRefs. That's one complication here, resulting from multiple differing uses of SPDX license expressions by two projects. Another issue was that I found that KDE has not had a stable definition of at least one of these LicenseRefs, so we can't just easily adopt the KDE LicenseRef as a Fedora LicenseRef pointing to wherever KDE defines what it means since we can't be sure that KDE might not revise it again. There's no reason why the KDE formulation should be *disapproved* -- in that sense, maybe we should add some representation of it to Fedora License Data somehow. But the existing Fedora approach (to the extent there was any guidance on this), from the Callaway System Era (i.e. prior to the adoption of SPDX license expressions), was not to represent the KDE proxy permission in License tags. So the thought was not to depart from the Callaway tradition. Logically, there's no basis for disapproving the KDE proxy permission since it's a subset of a permission that Fedora already approves (the general *GPL "or later" permission). So: don't use the KDE proxy permission in License tags. But we might have to revise the docs and Fedora License Data in some way. Richard -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
