Re: Moolticute SPDX update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/11/22 7:12 PM, Richard Fontana wrote:
On Thu, Nov 10, 2022 at 11:54 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote:

** Alternatively, this file may be used under the terms of the GNU
** General Public License version 2.0 or (at your option) the GNU General
** Public license version 3 or any later version approved by the KDE Free
** Qt Foundation.

That is not equivalent to GPL-2.0-or-later, if you assume it is
possible the KDE Free Qt Foundation might not approve the FSF's GPLv4,
say; how should this be represented as an SPDX expression? Should a
new GPL exception be submitted to SPDX? Is it even what SPDX would
classify as an "exception"? Does there need to be a 'Qt GPL' SPDX
identifier to cover this case, which I think is unique to Qt? Should
we just represent it as 'GPL-2.0-only OR GPL-3.0-only'? (Surprised if
this hasn't come up before in an SPDX context.)
Are we talking about the proxy issue with KDE as discussed here:
https://github.com/spdx/license-list-XML/issues/928 ?
Related but different. This is a different proxy, controlled by the
KDE Free Qt Foundation, not KDE e.V. That issue would seem to suggest
that if we want to represent this at all (and if we want to do this
for the various KDE packages in Fedora) it should be through a
LicenseRef-. The question is, should we? Outside of KDE, Qt and (IIRC)
git, I am not sure I've ever seen a use of such a 'proxy' mechanism,
so if it's that uncommon maybe it's not worth bothering to represent.
Then again, there are a lot of KDE-related packages in Fedora.
right. I knew there were more and older discussions on this, and did some more digging into the SPDX email archives, minutes, etc. (fell down rabbit hole for a bit on that, too many browser windows!) Indeed this specific situation has been discussed a few times over the past 9 years. Most notably, when SPDX was discussing the change to GNU license identifiers with the FSF in 2017, it came up and an idea of adding a 'PROXY' operator to signify this scenario was raised. However, it didn't get any traction given the reality that it is used very infrequently, as Richard has noted.

Maybe if Arthur needs a relatively quick answer it should be to just
use 'GPL-2.0-only OR GPL-3.0-only'?
That seems like the most practical and realistic way to go.
(I think there's a deeper question
here, which is why we should care so much about representing
'or-later' at this stage of FOSS legal history... To me, the
justification for doing it in Fedora license metadata is primarily
tradition.)

       # src/utils/qurltlds_p.h which is MPL-2.0 OR GPL-2.0-or-later OR
LGPL-2.1-or-later,
Given the nature of this file, I'd just omit this.
why do you say this?
This header file basically just contains a list of domain name
suffixes. In a number of cases I can remember over the years Fedora
has treated nominal nonfree licenses on analogous kinds of data as not
being an obstacle to Fedora packaging. Unlike those other cases, here
we don't have to address the issue of whether there is anything
actually licensable in this file; the file appears to be
self-compliant at least with MPL 2.0 and the licenses indicated here
are all Fedora-allowed. But it seems like an appropriate opportunity
to slightly simplify the License: field which I'm mindful that Arthur
is probably already finding very complex (given that it was previously
just "GPLv3").

Richard

_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-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/legal@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Gnome Users]     [KDE Users]

  Powered by Linux