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:
> > 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
> > 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  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
> > 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
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
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 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
Adding the full "Apache-2.0 OR MIT" choice from the first
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.