So, in Fabio's example, you could simplify it somewhat, because under our in-progress guidelines we say or intend to say that order of license identifiers in a license expression doesn't matter: i.e., (MIT OR Apache-2.0) is the same as (Apache-2.0 OR MIT) (Jilayne, does the SPDX spec itself say this?). So you wouldn't repeat those, any more than you'd repeat multiple occurrences of "MIT" (say, a package with multiple executable binaries each determined to be under the MIT license). This is an aspect of the "simple enumeration" policy. The resulting license expression will still be pretty lengthy, I admit. For me personally, I think experience has shown that simplification of license description is fraught with problems and it is better to attempt greater accuracy around license description. This is a major reason why I (a longtime skeptic of SPDX) got on board with the idea of Fedora using SPDX identifiers, because if used properly they provide more information than counterpart Callaway expressions. On the other hand, if the license tags don't really matter to users, why have them at all? I just don't see the point of a middle ground between no license tags and license tags that attempt accurate description, where the middle ground is going to involve value judgements and legal analysis that will differ from packager to packager. If we were to start entertaining some rules around license expression simplification, though, I think the dual licenses would be a logical place to start. Richard On Wed, Jul 13, 2022 at 5:19 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote: > > HI Fabio > > On 7/13/22 3:09 PM, Fabio Valentini wrote: > > On Wed, Jul 13, 2022 at 10:38 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. > > Sorry, I'm somewhat confused by these last two responses to my question. > > On the other hand, you seem to be making arguments that *favor* > simplification of dual licenses. > But the conclusion seems to be that "just specify everything" is still better? > > yeah... I think Richard and I are both sort of working through this as you all come up with additional and perhaps more complex examples :) > (and trying to add to/draft guidance that will be (relative) easy to follow and captures enough actual examples as well) > > > 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. > > It might be accurate. But this is also a very simplified example to > illustrate my point. > > ok, fair enough - that was a simple example. And I have a feeling that the guidance on dual-licensed packages probably contemplated more simple scenarios, but... > > Here's a more realistic one (taken from one of my packages, where I > also happen to be the upstream developer). > > great! > > This is the list of licenses of the project itself and its > dependencies, which are all statically linked together into a final > binary: > > # (ASL 2.0 or MIT) and BSD > # ASL 2.0 > # ASL 2.0 or Boost > # ASL 2.0 or MIT > # BSD > # MIT > # MIT or ASL 2.0 > # MIT or ASL 2.0 or zlib > # Unlicense or MIT > # zlib or ASL 2.0 or MIT > > Just recording everything would result in a license string of: > License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost) > and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or > ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT) > > This is already kind of silly, because it's stupidly long, and there > are duplicates, or clauses that are identical except for the order of > their contents. > I would not say that this is "somewhat obvious as to what is going > on", because nobody will even read this string in its entirety. > > yeah, this is a more interesting example for sure and agreed, it does get a bit ridiculous looking even if still "accurate" > > Now, is reordering the contents of the clauses and removing any > duplicates already considered as doing an "effective license > analysis"? :) > > Anyhow, for this package, I have "simplified" the license string to: > License: ASL 2.0 and BSD and MIT > > This satisfies every clause, and I'd argue it is *much more obvious* > to users what it means than the silly long string above. > It doesn't give users any "choices", but any "choice" they would have > made (differently than what I did when packaging this project) would > have resulted in a package with *strictly more* restrictions, but > never *fewer*. > > I'd argue that 1) minimizing restrictions and 2) making the resulting > license actually understandable for users is much more important than > to preserve any "choice" that, if exercised differently, would only > result in either more restrictions, more complicated licensing terms, > or both. > > Thanks for this, really helpful. Richard and I will discuss a bit more... > > Going back to some of the original comments in this thread (or another similar one?) - is the above actual example a common scenario for Rust and Go packages? And can it get even more complex or lengthy than this example? Just trying to get a sense of the typical range of examples you all come up against, so we can be sure to try to cover those. > > Thanks! > Jilayne > > Fabio > _______________________________________________ > 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 _______________________________________________ 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
