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(a)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(a)gmail.com>
wrote:
>>> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana<rfontana(a)redhat.com>
wrote:
>>>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen<oturpe(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email topackaging-leave(a)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.fe...
>> Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure