On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote:
The License tag was never formally defined. If we agree that there can be anything, then let it be.
The Pending PR here updates that to: SPDX License identifier or expression (from our "Good" list).
https://pagure.io/packaging-committee/pull-request/1142#_1__38
Although given the context here, I note that that's ambiguous about whether the _whole expression_ must be on the list — I don't think that's the intention!
[CC'ing this to the legal list, btw.]
On Mon, Jan 03, 2022 at 12:12:38PM -0500, Matthew Miller wrote:
On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote:
The License tag was never formally defined. If we agree that there can be anything, then let it be.
The Pending PR here updates that to: SPDX License identifier or expression (from our "Good" list).
https://pagure.io/packaging-committee/pull-request/1142#_1__38
Although given the context here, I note that that's ambiguous about whether the _whole expression_ must be on the list — I don't think that's the intention!
I think in some cases, it may be. As our discussions on this PR have noted, Fedora may approve an expression but not all expressions that SPDX can represent. So the objective is more about using the tokens and expression syntax defined by SPDX, but then we have our list of approved expressions. This is also necessary because we need to maintain our own list of LicenseRef tokens for things we approve for Fedora but that do not have an upstream SPDX token.
However, in many cases Fedora is ok with combining something with GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been working through has some of these expressions that are a license token and then a WITH qualifier. So this may be more about ensuring that a WITH clause isn't noted as approved without also requiring the main token.
IANAL, so take my comments with that in mind. And this is where I defer to Jilayne for the actual expertise here. :)
On 1/5/22 7:59 AM, David Cantrell wrote:
On Mon, Jan 03, 2022 at 12:12:38PM -0500, Matthew Miller wrote:
On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote:
The License tag was never formally defined. If we agree that there can be anything, then let it be.
The Pending PR here updates that to: SPDX License identifier or expression (from our "Good" list).
https://pagure.io/packaging-committee/pull-request/1142#_1__38
Although given the context here, I note that that's ambiguous about whether the _whole expression_ must be on the list — I don't think that's the intention!
I think in some cases, it may be. As our discussions on this PR have noted, Fedora may approve an expression but not all expressions that SPDX can represent. So the objective is more about using the tokens and expression syntax defined by SPDX, but then we have our list of approved expressions. This is also necessary because we need to maintain our own list of LicenseRef tokens for things we approve for Fedora but that do not have an upstream SPDX token.
There were some license combinations (could be AND, OR, or WITH) that are on the "good" list but a different combination might need separate approval.
Off top of head, I think any L/GPL WITH [exception] would fall into the category of needing to be capture as the full license expression since the specific exception would need to be reviewed and approved and would be different text than another exception.
But for any combination of previously approved license for Fedora - e.g., "MIT OR GPL-2.0-only", "Apache-2.0 AND BSD-3-Clause" and so on - separate listings would not be necessary - agreed?
(and this concept needs to be documented... adding to the list of items to better document)
However, in many cases Fedora is ok with combining something with GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been working through has some of these expressions that are a license token and then a WITH qualifier. So this may be more about ensuring that a WITH clause isn't noted as approved without also requiring the main token.
See above. Also, as per SPDX License List expression syntax (found in an appendix to the SPDX spec), you have to have a valid license ID on the left side of the WITH operator and a valid exception ID on the right side (as one would expect)
IANAL, so take my comments with that in mind. And this is where I defer to Jilayne for the actual expertise here. :)
On Wed, Jan 5, 2022 at 3:45 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
There were some license combinations (could be AND, OR, or WITH) that are on the "good" list but a different combination might need separate approval.
Off top of head, I think any L/GPL WITH [exception] would fall into the category of needing to be capture as the full license expression since the specific exception would need to be reviewed and approved and would be different text than another exception.
But for any combination of previously approved license for Fedora - e.g., "MIT OR GPL-2.0-only", "Apache-2.0 AND BSD-3-Clause" and so on - separate listings would not be necessary - agreed?
(and this concept needs to be documented... adding to the list of items to better document)
However, in many cases Fedora is ok with combining something with GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been working through has some of these expressions that are a license token and then a WITH qualifier. So this may be more about ensuring that a WITH clause isn't noted as approved without also requiring the main token.
See above. Also, as per SPDX License List expression syntax (found in an appendix to the SPDX spec), you have to have a valid license ID on the left side of the WITH operator and a valid exception ID on the right side (as one would expect)
In related internal work being done largely by Bryan Sutula and Russell Gelvin on certain Red Hat products, there's been an effort to review for approval exceptions (what SPDX would consider exceptions) identified mainly through ScanCode Toolkit. I believe a given exception text will be approved basically without regard to the license it is associated with. If you look at the current Fedora good list, the impression is that there are a small number of uses of exceptions out there used with particular licenses (I think in all cases, licenses in the GPL family). But as Bryan and Russell have been finding, the actual picture is much bigger and more complex. I am pretty sure I've seen cases where an exception normally used with GPL version 2 is used with LGPL version 2.x.
This reminds me that not too long ago I suggested that Fedora abandon any effort to note the existence of (permissive) exceptions in license tags, as being too much work for dubious gain beyond classification for the sake of classification. But the anticipated switch to SPDX identifiers raises the issue of what the license tag is actually *for*, and how much detail or specificity it ought to embody, since SPDX identifiers permit and in a sense encourage a relatively high level of detail of license description. That's a whole other topic but something I think has to be addressed as well. We might be assuming now that license tags ought to have as much detail as possible (something akin to a human review of the output of a scanner like ScanCode Toolkit on the files in a source tarball, with only limited processing); this isn't the approach consistently taken by Fedora packagers today.
Richard
-
David Cantrell -
Jilayne Lovejoy -
Matthew Miller -
Richard Fontana