Hi all,
I'm in the progress of migrating the Mooltice [0] package to SPDX, but it proved to be more difficult than anticipated. I would be grateful if someone could review my current analysis. The license tag and accompanying comment I have at the moment is the following:
# The entire source code is GPL-3.0-or-later except: # src/qwinoverlappedionotifier.[cpp|h] which is LGPL-3.0 OR GPL-2.0-or-later, # src/AnsiEscapeCodeHandler.[cpp|h] which is Qt-GPL-exception-1.0, # src/CyoEncode/ which is BSD-2-Clause, # src/QtAwesome/ which is MIT AND OFL-1.1 AND CC-BY-3.0 (see src/QtAwesome/README.md for details), # src/SimpleCrypt/ which is BSD-3-Clause, # src/http-parser/ which is MIT, # src/qtcsv/ which is MIT, # src/qtcsv6/ which is MIT, # src/utils/qurltlds_p.h which is MPL-2.0 OR GPL-2.0-or-later OR LGPL-2.1-or-later, # src/zxcvbn-c which is BSD-3-Clause. License: GPL-3.0-only AND GPL-3.0-or-later AND (LGPL-3.0 OR GPL-2.0-or-later) AND BSD-2-Clause AND BSD-3-Clause AND MIT AND OFL-1.1 AND CC-BY-3.0 AND (MPL-2.0 OR GPL-2.0-or-later OR LGPL-2.1-or-later)
You can find the output of licensecheck here: https://principis.fedorapeople.org/moolticute-0.55.18-testing-licensecheck.t... . Note that src/QSimpleUpdater is removed as a patch.
Besides that I also couldn't find any reference to Qt-GPL-exception-1.0. Is this license allowed?
[0] https://src.fedoraproject.org/rpms/moolticute
Thank in advance!
On Wed, Nov 9, 2022 at 10:29 AM Arthur Bols arthur@bols.dev wrote:
Hi all,
I'm in the progress of migrating the Mooltice [0] package to SPDX, but it proved to be more difficult than anticipated. I would be grateful if someone could review my current analysis. The license tag and accompanying comment I have at the moment is the following:
[...]
# src/AnsiEscapeCodeHandler.[cpp|h] which is Qt-GPL-exception-1.0,
[...]
Besides that I also couldn't find any reference to Qt-GPL-exception-1.0. Is this license allowed?
It hasn't been reviewed before -- please submit an issue to https://gitlab.com/fedora/legal/fedora-license-data/ to have it reviewed and added to the Fedora license list.
Richard
On 9/11/2022 18:17, Richard Fontana wrote:
It hasn't been reviewed before -- please submit an issue to https://gitlab.com/fedora/legal/fedora-license-data/ to have it reviewed and added to the Fedora license list.
Thank you. I have submitted an issue: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/98
Arthur
On Wed, Nov 9, 2022 at 10:29 AM Arthur Bols arthur@bols.dev wrote:
Hi all,
I'm in the progress of migrating the Mooltice [0] package to SPDX, but it proved to be more difficult than anticipated. I would be grateful if someone could review my current analysis. The license tag and accompanying comment I have at the moment is the following:
# The entire source code is GPL-3.0-or-later except: # src/qwinoverlappedionotifier.[cpp|h] which is LGPL-3.0 OR
GPL-2.0-or-later,
<projects mountain bike signal onto clouds>
Jilayne, these files actually say LGPLv3 (ambiguous as to later versions but let's assume as a matter of common sense the Qt licensors intended LGPLv3 only), or:
** 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.)
# src/AnsiEscapeCodeHandler.[cpp|h] which is Qt-GPL-exception-1.0,
More precisely, GPL-3.0-only WITH Qt-GPL-exception-1.0, I think.
# 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.
Richard
On Wed, Nov 9, 2022 at 1:00 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Nov 9, 2022 at 10:29 AM Arthur Bols arthur@bols.dev wrote:
Hi all,
I'm in the progress of migrating the Mooltice [0] package to SPDX, but it proved to be more difficult than anticipated. I would be grateful if someone could review my current analysis. The license tag and accompanying comment I have at the moment is the following:
# The entire source code is GPL-3.0-or-later except: # src/qwinoverlappedionotifier.[cpp|h] which is LGPL-3.0 OR
GPL-2.0-or-later,
<projects mountain bike signal onto clouds>
Jilayne, these files actually say LGPLv3 (ambiguous as to later versions but let's assume as a matter of common sense the Qt licensors intended LGPLv3 only), or:
** 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.)
# src/AnsiEscapeCodeHandler.[cpp|h] which is Qt-GPL-exception-1.0,
More precisely, GPL-3.0-only WITH Qt-GPL-exception-1.0, I think.
# 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.
There are KDE exception clauses in SPDX: LicenseRef-KDE-Accepted-GPL and LicenseRef-KDE-Accepted-LGPL
They have not been added to mainline SPDX, and I'm not sure why.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Wed, Nov 9, 2022 at 1:08 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Nov 9, 2022 at 1:00 PM Richard Fontana rfontana@redhat.com 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.
There are KDE exception clauses in SPDX: LicenseRef-KDE-Accepted-GPL and LicenseRef-KDE-Accepted-LGPL
They have not been added to mainline SPDX, and I'm not sure why.
Although, LicenseRef-KDE-Accepted-GPL (etc.) is defined by KDE to refer to the KDE e.V. entity (https://community.kde.org/Policies/Licensing_Policy#LicenseRef-KDE-Accepted-...) while the Qt formula refers to the KDE Free Qt Foundation which apparently consists of a board half appointed by The Qt Company and half appointed by the KDE e.V. entity. (https://kde.org/community/whatiskde/kdefreeqtfoundation/).
Richard
On 9/11/2022 19:21, Richard Fontana wrote:
Although, LicenseRef-KDE-Accepted-GPL (etc.) is defined by KDE to refer to the KDE e.V. entity (https://community.kde.org/Policies/Licensing_Policy#LicenseRef-KDE-Accepted-...) while the Qt formula refers to the KDE Free Qt Foundation which apparently consists of a board half appointed by The Qt Company and half appointed by the KDE e.V. entity. (https://kde.org/community/whatiskde/kdefreeqtfoundation/).
Richard
Thank you for looking into this. I'm not sure how I should proceed with this. Would it be possible to ignore the "or later" part and use it as LGPL-3.0 OR GPL-2.0-only OR GPL-3.0-only? The license is changed in a newer version of the file: https://github.com/qt/qtserialport/blob/6.4/src/serialport/qwinoverlappedion...
In the meantime, I'll ask upstream if the file could be removed or updated. It may be used for compatibility with an older Qt release.
Arthur
On 11/9/22 11:00 AM, Richard Fontana wrote:
On Wed, Nov 9, 2022 at 10:29 AM Arthur Bols arthur@bols.dev wrote:
Hi all,
I'm in the progress of migrating the Mooltice [0] package to SPDX, but it proved to be more difficult than anticipated. I would be grateful if someone could review my current analysis. The license tag and accompanying comment I have at the moment is the following:
# The entire source code is GPL-3.0-or-later except: # src/qwinoverlappedionotifier.[cpp|h] which is LGPL-3.0 OR
GPL-2.0-or-later,
<projects mountain bike signal onto clouds>
oh my, is this a thing now?
Jilayne, these files actually say LGPLv3 (ambiguous as to later versions but let's assume as a matter of common sense the Qt licensors intended LGPLv3 only), or:
** 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 ?
# src/AnsiEscapeCodeHandler.[cpp|h] which is Qt-GPL-exception-1.0,
More precisely, GPL-3.0-only WITH Qt-GPL-exception-1.0, I think.
that sounds right
# 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?
Jilayne
Richard _______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Nov 10, 2022 at 11:45 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 11/9/22 11:00 AM, Richard Fontana wrote:
On Wed, Nov 9, 2022 at 10:29 AM Arthur Bols arthur@bols.dev wrote:
Hi all,
I'm in the progress of migrating the Mooltice [0] package to SPDX, but it proved to be more difficult than anticipated. I would be grateful if someone could review my current analysis. The license tag and accompanying comment I have at the moment is the following:
# The entire source code is GPL-3.0-or-later except: # src/qwinoverlappedionotifier.[cpp|h] which is LGPL-3.0 OR
GPL-2.0-or-later,
<projects mountain bike signal onto clouds>
oh my, is this a thing now?
Jilayne, these files actually say LGPLv3 (ambiguous as to later versions but let's assume as a matter of common sense the Qt licensors intended LGPLv3 only), or:
** 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 ?
Yes. Oh lord, does this mean we need a LicenseRef-(RedHat|Fedora)-KDE-Accepted-(GPL|LGPL) local exception set?
On Thu, Nov 10, 2022 at 11:54 PM Jilayne Lovejoy jlovejoy@redhat.com 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.
Maybe if Arthur needs a relatively quick answer it should be to just use 'GPL-2.0-only OR GPL-3.0-only'? (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
On 12/11/2022 03:12, Richard Fontana wrote:
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.
Maybe if Arthur needs a relatively quick answer it should be to just use 'GPL-2.0-only OR GPL-3.0-only'? (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.)
(I replied on this particular issue in the different thread, sorry) I would like to fix the license: field with the next update of moolticute, but it can wait. There is no time pressure from my side.
# 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
That would be appreciated! However, there is the problem that due to my limited knowledge about licensing, I cannot defend this choice if questions are raised in the future. With that in mind, it might be better to include it anyway?
Arthur
On Sat, Nov 19, 2022 at 9:49 AM Arthur Bols arthur@bols.dev wrote:
On 12/11/2022 03:12, Richard Fontana wrote:
# 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
That would be appreciated! However, there is the problem that due to my limited knowledge about licensing, I cannot defend this choice if questions are raised in the future. With that in mind, it might be better to include it anyway?
I don't know if it's better but it seems okay to include it.
Richard
On 11/11/22 7:12 PM, Richard Fontana wrote:
On Thu, Nov 10, 2022 at 11:54 PM Jilayne Lovejoy jlovejoy@redhat.com 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