On 1/4/22 11:30 PM, Richard Fontana wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com 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