Re: [Fedora-legal-list] Re: List of packages with problematic license

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

 



On Wed, Jan 5, 2022 at 3:45 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> 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
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux