how did you know that is the exact past example I was thinking of that plagued me in the past!!  (and hoping it's a bit less common these days... or at least not found as part of the complex scenario that Fabio just mentioned)

:)

On 7/13/22 3:14 PM, Richard Fontana wrote:
I would add, though I guess it's covered by what I said, that there
are situations where it's not clear, as a matter of what's basically
legal analysis, which side of a FOSS dual license is actually
'better'. A good example might be the Sun GPLv2 with Classpath
Exception | CDDL case -- in the cases where that dual license applies,
you can come up with arguments why one or the other license is
preferable based on various factors.

- Richard

On Wed, Jul 13, 2022 at 4:37 PM Jilayne Lovejoy <jlovejoy@redhat.com> wrote:


On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini <decathorpe@gmail.com> wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana@redhat.com> wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe@iki.fi> wrote:

I wonder what you think about simple cases of "effective" licenses?
For example, most Rust projects are dual-licensed as "Apache-2.0 OR
MIT", but some odd ones are released under "MIT"-only or
"Apache-2.0"-only licenses.

So, for a binary package that contains code from both "Apache-2.0 OR
MIT" and "MIT"-only projects, we usually "collapsed" that into just
"MIT".
Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we
are stubbornly clinging to the practice of recording a FOSS dual
license in the license tag, when not doing so could provide some
simplification of license tag expressions.

In my mind, there were a few reasons for this practice: (1) it was
what Fedora traditionally did; (2) it matches general upstream culture
(the idea of passing down a FOSS license choice through a chain of
distributees; (3) there's a contrary corporate culture seen in some
quarters of making sure that "bad" (from their perspective) FOSS
licenses in a dual license scheme are eliminated, which I think is
based mostly on ignorance and copyleftphobia and so forth, which we
don't want to encourage or be associated with; (4) there isn't going
to be a good, consistently-applicable basis for selecting one or the
other license -- this is related to (3). (4) is also related to the
"effective license" problem: there isn't really any coherent effective
license doctrine that can be consistently applied. I guess also (5)
which is a community counterpart to (3): you would end up with
licenses being selected out of a dual license based on the individual
preferences of a Fedora packager. In one case, a Fedora packager might
personally prefer the Apache License 2.0 over MIT, in another case the
opposite. This contradicts the tradition of passing down the choice to
the user.
Ha, you start out with "stubbornly clinging" and that maybe not
recording the dual license in the license tag helping simply things, but
then after reading your points (1) through (5), I felt even more
convinced of the value in recording/retaining such info!

I must say - the scenario where someone makes the choices (point (3) by
example) can be really annoying for downstream recipients or downstream
of downstream. I have memories of doing source code audits and running
into this and relying on some form of "tribal knowledge" that there was
a choice upstream that had gotten removed and then going upstream to
find it, so the choice could be made "again". Fedora, as a free and open
source software distro, need not make an explicit choice between two
free and open source licenses (in the way a commercial software
distribution might), so the policy of passing along the original choice
makes sense to me as a matter of convenience (for downstream recipients)
and in keeping with the principles of Fedora being free and open more
generally.

          
Adding the full "Apache-2.0 OR MIT" choice from the first project
seems to be pointless, since it actually cannot result in a choice of
license - because that choice is already forced by the "MIT"-only
second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture
"(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to
what is going on.
I understand this point but the idea that the choice is forced seems
to be a form of "effective license" analysis. I am not dismissive of
the idea since I think there is something fundamentally unclear about
what composite licensing means. However, the general problems with
effective license analysis apply to this case too.

Richard
_______________________________________________
packaging mailing list -- packaging@lists.fedoraproject.org
To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
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/packaging@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure