On Wed, 10 Aug 2022 at 14:23, Richard Fontana <rfontana(a)redhat.com> wrote:
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák
<dan.cermak(a)cgc-instruments.de> wrote:
>
>
>
> On August 10, 2022 4:35:10 PM UTC, Richard Shaw <hobbes1069(a)gmail.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
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