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: > > > > > > As a maintainer of modest amount of packages and occassional new package > > > reviewer, > > > the issues I have with the current licensing policy as linked above are: > > > > > > 1. The "effective license" thing that is already discussed in another > > > thread does not appear in the policy at all, and it does not appear in > > > Fedora Licensing page, either. The only places that mention it that I > > > have discovered are Licensing:FAQ [1] and random discussions at mailing > > > lists and so on. This makes it quite difficult to understand if > > > "effective licensing" is actually part of the policy or not. It would be > > > easier to understand its status if it was covered in the policy itself. > > > The policy itself should be unambiguous and possible to interpret > > > without reference to any FAQ. A FAQ should not introduce new > > > requirements and exceptions. > > > > That part of the FAQ will have to be revisited, if the approach I > > suggested today is adopted (a good example of why it isn't exactly > > maintaining the existing policy). Basically, the "simple enumeration" > > approach would mean that there is no such thing as "effective > > licensing". > > 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. > 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. 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
