4:13 p.m.
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".
If people think that "effective licensing" is something that is so
valuable that it is worth the resulting unavoidable complexity of
analysis and inconsistency across packages, that view should be
voiced. I *can* imagine providing some more detailed rules about what
"effective licensing" means (and at an earlier stage I was actually
thinking of working on something like this). I basically gave up
because it's clear no one agrees on what effective licensing means,
which means it's not effective. :)
2. In general, it is confusing that the policy is split between
Packaging Guidelines, Fedora Licensing main page and, apparently, also
the FAQ. How can I determine if any given docs or wiki page is
authorative? Would it be possible to consolidate everything that is
authorative to a single page and declare it such?
Good idea.
3. Specifically related to the effective licensing question, MIT and
BSD
basically *only* ask to include the license text when shipping binaries.
The effective licensing thing then erases those licenses, if there is
GPL somewhere in the mix. The cognitive dissonance between wanting to
honor upstream licenses and not shipping them due to effective licensing
is serious. Since MIT and BSD are very common licenses, and code under
them is also very commonly found embedded in otherwise GPL projects, I
would like the licensing policy explicitly cover this situation and
explain why it is allowed to not ship the MIT/BSD license in this case.
(Perhaps, it would be good to revisit the part of the policy that
discussed shipping license texts and consider, why is that required: It
is in order to honor upstream licenses, or for some other reason, like
end user convenience?)
All the licenses are shipped in that they are found in the SRPM.
Implicitly, Fedora's position is that this is compliant with those
permissive licenses. I think the issue you're raising is Fedora's
policy on what license texts to install in /usr/share/licenses. I
don't think that issue is directly tied to how the License: field is
populated. I couldn't immediately find any documentation on the
/usr/share/licenses policy, but my intuition from looking at lots of
Fedora and RHEL packages is that this contains any license text that
seems to be "global" in some way, and in cases where there is no
obvious such license, some appropriate license is selected from the
source files for this purpose. We might want to separately revisit the
/usr/share/licenses policy at some point if there is interest.
Richard
[1]: https://fedoraproject.org/wiki/Licensing:FAQ
_______________________________________________
packaging mailing list -- packaging(a)lists.fedoraproject.org
To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--