On Wed, Jan 05, 2022 at 05:16:41AM -0500, Neal Gompa wrote:
On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana <rfontana@xxxxxxxxxx> wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> 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
Out of curiosity, what do you think listing forbidden licenses means in a
Fedora package?
(I ask this too because when asking other people, I get slightly different
answers and I think this is something we need clarified in the Packaging
Guidelines and the forthcoming Fedora Legal Guidelines.)
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.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
