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@xxxxxxxxxx> wrote: > > > > On 7/12/22 8:31 AM, Richard Fontana wrote: > > On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > >> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > >>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
