On 1/4/22 11:30 PM, Richard Fontana 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:
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.)
+1 to revisiting the policy of the classification of Artistic-1.0 as "bad"
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.
By way of example re: other companies and picking one of the licenses
(for anyone interested) - a couple scenarios I've seen where it might
matter: you are a company that does not have an
all-products-are-open-source policy, or your open source project wants
to make sure its incorporated licenses are all compatible (in theory and
practically). Say you have an open source project that is licensed
under: GPL-2.0-or-later OR MIT
a) you want to incorporate this into your proprietary product, but your
policy does not allow using any GPL code - then you will want to clarify
that your distribution is under MIT.
b) You also may choose MIT even if you don't have a policy against GPL
for the simple reason the MIT is "easier" to comply with.
b) you want to incorporate this into your open source project which is
under Apache-2.0 - you choose MIT because of the FSF alleged
incompatibility between Apache-2.0 and GPL-*
c) you have other code you are combining this with that is under
GPL-3.0-only - so you choose GPL-3.0-only (because another choice here
you had from upstream was GPL-2.0-or-later) because it's easier to
comply with one/the same license for all your code and GPL-3.0 has
better/more modern source code provision options
So, it matters to some, but I can't see any of these scenarios really
applying here for Fedora (with the exception of the already stated Perl
issue)
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.
I agree that it never really matters in all practical scenarios *when
you are providing source code anyway*, as is our case here. It's more of
an issue when you are distributing code in binary form only.
Fortunately, that is not our ship :)
Jilayne
_______________________________________________
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
