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