Hi, Stephen Smoogen <ssmoogen@xxxxxxxxxx> writes: > 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. 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 _______________________________________________ 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
