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
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