Hi,
Stephen Smoogen ssmoogen@redhat.com writes:
On Wed, 10 Aug 2022 at 14:23, Richard Fontana rfontana@redhat.com wrote:
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
On August 10, 2022 4:35:10 PM UTC, Richard Shaw hobbes1069@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.
The question that we should first ask ourselves should be: what is the license field used for? Who is *actually* the target audience? Someone who would like to only put GPL code on their system? Someone who would like to prevent GPLv3 code from getting on their system?
Depending on the target usecase, we'll arrive at different solutions for this problem.
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.
One possible solution would be to attach a license to every file in a package. This would make it to a certain extend easier to enumerate all the licenses, but it would definitely blow up the package metadata tremendously for a questionable benefit.
Cheers,
Dan