On Wed, 10 Aug 2022 at 14:23, Richard Fontana <rfontana@xxxxxxxxxx> wrote:
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák
<dan.cermak@xxxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On August 10, 2022 4:35:10 PM UTC, Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
> >With the move to SPDX license nomenclature I'm starting to reevaluate how
> >I review licenses during a package review.
> >
> >I'm working on a review and it looks like some of the documentation, i.e.
> >stuff that would go in %doc has a specific license. I don't know if this is
> >uncommon or if I just hadn't noticed before, but does this actually impact
> >the package licensing?
>
> If the %doc part belongs to the main package, then I'd just combine all licenses via AND including the license of the documentation. If it's a separate package, the use the doc license for the -doc subpackage (provided that rpm supports this). But IANAL applies as usual.
That sounds right to me ...
> >In general, I would say that the package license should be based on what's
> >actually in the resultant package (not build system stuff like autotools,
> >random scripts, etc).
Yes, and that is consistent with both the new Fedora legal
documentation as well as the earlier guidelines (as I read them,
anyway).
> That seems pretty straightforward, but documentation?
I think there's a couple of issues. First, all documentation files
distributed by Fedora should be under a Fedora-allowed license for
documentation. This is true even if the documentation files are not in
the built package. Second, to what extent should licenses unique to
documentation in a built package be reflected in the License: field?
Up to now it's pretty clear Fedora packages have been inconsistent in
how they've handled this. My assumption however is that documentation
licensing should not be ignored in populating the License: field and
we can make this clear with an example in the new legal documentation.
(I *think* for the vast majority of Fedora packages there is no
license for documentation distinct from the software license.)
I think we are overloading a tool (the License tag) which was meant for a 'simpler' time when packages usually had a single license and was not meant to be more useful than that. We are putting a lot of things in here which are 'nuanced' in a way that one License line does not give and needs a more complex solution. People are going to read that the package says 'License: GPL-2.0-only and GFDL-1.2-or-later' and now have to determine.. is the program running under GFDL? Also what is the license that the actual GPL License is under? It is not covered under the GPL but has a distinctly different one. Do we need to add that into the mix?
I keep feeling this is like sending a lot of untrained people with hot-glue guns to fix leaks in the Hoover dam. There are a LOT of different licenses in a package ranging from fonts, straight documentation text, various header files, source code, the licenses themselves, etc. We are then trying to parse all that and put it in a one line summary which will somehow give a person/machine reading it enough context to know what to do with the code.
I think we should look at the problem from the beginning and try to find a good tool to help fix the problem. Then deploy and correct the tool until it helps fix the problem in the first place.
On a general note, it's important to pay attention to documentation
licensing even though it may seem less critical than software
licensing. Although this is still being looked into, there seems to be
some evidence of Fedora packages that are including upstream
documentation under disallowed licenses (in particular "NC" varieties
of Creative Commons licenses).
Richard
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
