Dne 05. 01. 22 v 19:52 David Cantrell napsal(a):
On Wed, Jan 05, 2022 at 12:39:50PM +0100, Vít Ondruch wrote:
>
> Dne 05. 01. 22 v 11:16 Neal Gompa napsal(a):
>> On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana <rfontana(a)redhat.com>
>> wrote:
>>> On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy
>>> <jlovejoy(a)redhat.com> wrote:
>>>> On 1/4/22 9:27 AM, David Cantrell wrote:
>>>>> Does it follow that we [Fedora] take an open source project that is
>>>>> dual licensed and use the license that is acceptable in our project
>>>>> and redistribute under those terms? Is that even a thing one can
>>>>> do?
>>>>> Given the "or" usage, my assumption is yes. The author is
giving
>>>>> the
>>>>> downstream user the choice of using that work under the terms of
the
>>>>> GPL or the terms of the Artistic license. In the case of Fedora,
>>>>> we've deemed Artistic undesirable which means our use of the
modules
>>>>> is technically under the terms of the GPL.
>>>> Correct.
>>>>
>>>>> For me, I would prefer to see this reflected in the License tags in
>>>>> spec files so we can see how we're integrating components in to
>>>>> Fedora. If we note a license that we can't use or that we are
not
>>>>> using, it makes it harder to see at a glance _what_ terms actually
>>>>> apply to that component. And that makes it harder for other
>>>>> packagers
>>>>> looking for license-compatible dependencies.
>>>> Agreed.
>>> I sort of agree.
>>>
>>>>> I realize this is yet another work project and also that I may be
>>>>> incorrect regarding what we can and can't do with regard to
>>>>> dual-licensed projects. If we are unable to say "we're
using the
>>>>> Perl
>>>>> modules under the terms of the GPL" and exclude the Artistic
>>>>> license,
>>>>> then really the "or" boolean doesn't apply and it's
really always
>>>>> "and".
>>>> I think you mean that there would not be a need for the "OR"
>>>> operator in
>>>> Fedora, but there are open source projects that may be licensed
>>>> under a
>>>> choice of two "good" Fedora licenses, in which case, it would
make
>>>> sense
>>>> to simply pass downstream the choice of both, I would think.
>>> The only reason why "GPL+ or Artistic" (or, presumably in SPDX
>>> notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used
by
>>> Fedora is that Artistic-1.0 is "bad" from Fedora's perspective
and
>>> Fedora has a policy of not distributing code in packages under
"bad"
>>> licenses. Or else we should revisit that classification of
>>> Artistic-1.0, or else document that there is a special exception for
>>> Perl modules because Perl module developers upstream objected to the
>>> use of merely 'GPL" in the spec file license tag. (I don't
really like
>>> that last possibility.)
>>>
>>> Otherwise, if the disjunctive license expression involves two licenses
>>> Fedora considers "good", then I agree with Jilayne, the choice
should
>>> be passed on -- even if there is some argument that it *can't* be
>>> (which would mainly be for license compatibility reasons, I guess).
>>> That has in fact been the practice in Fedora, and in all the projects
>>> and products developed by Red Hat that I'm aware of. At Red Hat
we've
>>> even explained this to the occasional customer who asks us which
>>> license of a FOSS-dual-licensed package, or file, we are shipping
>>> under.
>>>
>>> I am aware anecdotally that there are other companies that do the
>>> opposite: they are careful to somehow ceremonially or otherwise
"pick"
>>> one of the licenses in the disjunct. It is important to note that this
>>> is *not* what is done upstream, i.e. by upstream projects using other
>>> projects' FOSS code, except in extremely rare cases, and I see Fedora,
>>> as well as Red Hat, as perpetuating that general upstream FOSS
>>> community practice of passing on FOSS license choices without further
>>> analysis. One reason for this is that it's generally never clear which
>>> of the licenses ought to be selected or would be preferable, if one
>>> had to make a choice. The result is more complex license identifier
>>> expressions in package metadata, but I think there the complexity is
>>> justified.
>>>
>>> What it actually *means* for an intermediary to distribute upstream
>>> code under the upstream choice of licenses, with conditions that might
>>> simultaneously apply to that intermediary on either side of the
>>> disjunct, I'm not entirely sure, but in all normal practical scenarios
>>> it never really matters -- which is another reason for the "pass the
>>> choice on" practice. I'd rather copy the practices of upstream
>>> community projects than the practices of GPL-phobic companies
>>> downstream, basically.
>>>
>> With my upstream hat, I greatly prefer that Fedora *not* make
>> decisions about the licenses. I even kind of prefer what Fedora does
>> today with Perl modules (that is, document both "good" and
"bad"
>> licenses). With my Fedora contributor "hat" on (lol), I'd prefer
to
>> strip "bad" licenses since we never want to allow that choice of
>> license combinations. I know some think that documenting "bad"
>> licenses means we give permission to use under those terms (that's not
>> even *close* to what that means, but meh). With my downstream consumer
>> hat on, I worry that Fedora making decisions on licenses might lead to
>> weird effects for me when working with other things. I'd prefer Fedora
>> to stay out of picking licenses for packages and allow "runtime
>> evaluation" of license combinations instead.
>>
>> All of this to say, I agree with Richard that we should more or less
>> keep the status quo.
>>
>
> Why the license tag couldn't be something like:
>
> License: upstream(GPL+ or Artistic) and fedora(GPL+)
>
> There could even be macro based e.g. on Mirek's tool to reduce the
> upstream license set to Fedora license set:
>
> %{license:GPL+ or Artistic}
>
> because as a packager, I'd be much happier if I can just list the
> upstream licenses and don't bother what is effective Fedora license.
I don't think using a macro for the License tag is a good idea because it
risks changing it to something invalid at each rebuild of the package.
Nowadays, we don't even know the License tag is broken, so if it was
change by macro from something broken to something broken differently,
it can be worse.
But I actually see this as and opportunity for improvement. E.g. if I
specified just `Artistic` license, the build would fail right away. If I
specified `GPL+ or Artistic`, it would pass. If I specified `foo or
Artistic`, it would also pass.
In the
case of mass rebuilds and other builds that the maintainer may not do
correctly, we risk introducing invalid values in the License tag.
We are constantly in the risk of this. If the tool should produce broken
results, then fix and another mass rebuild would fix them.
Also, packages relicense from time to time, some more than others
(e.g., Qt).
It's best that we capture this as static data in the spec file tied to
the
version of the software being packaged.
I am not sure what is the difference to current state. Packages
relicense and we are changing (or forget to change) the License tag all
the time. The macro won't change it, because there must be the licenses
specified the same way as for the current tag.
Vít