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