On Wed, Jun 2, 2021 at 11:41 AM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > On Wed, Jun 02, 2021 at 01:31:15PM -0000, Benjamin Beasley wrote: > > > So, it doesn't really matter if two source files are distributed under > > > the GPLv2+ license. > > > The resulting binary (i.e. /usr/bin/cdparanoia) will always be GPLv2. > > > […] > > > But Licensing Guidelines make clear that the License: field refers to the > > > binary packages not source ones. > > > > > > BR, > > > > > > Andrea > > > > The “effective license” approach you advocated is not mentioned in the > > packaging guidelines but has historical support in the wiki > > (https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F). > > It has also come up on the fedora-legal list recently > > (https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/W57JRNLWVOT55D7TDF7VYFMJT5QMBEGR/). > > FWIW, the licensing guidelines live on the wiki. There is nothing > "historical" about the Licensing:FAQ document, it is still the official > guide of how to interpret the Licensing:Main page. > > I know Ben wrote something that disagrees with the document, but > I think he is wrong. It also goes against the long-established practice. > And if we want to change the rules, the document that specifies them > should be changed, a post on the mailing list is not enough. > > > There is, I think, a valid question of how much mechanistic detail to apply > > to documenting the source files *that contribute to the binary RPM > > contents.* One approach, which I have favored in my packages, exhaustively > > lists licenses of such files. The other, which you have advocated, > > simplifies the license field into an “effective license” when clearly > > appropriate. Both philosophies seem to be well-established as acceptable. > > My view is therefore this patch seems to be correct but not absolutely > > required. > > No, the patch is wrong. It's not super harmful, but it's still wrong. > > > HOWEVER: I have to agree with you that the idea of documenting the licenses > > of SRPM contents seems to be a questionable justification, as current > > Guidelines are clear that the License field is for the binary package > > contents. If documenting SRPM contents became policy, it would require > > pervasive changes to existing packages. For example, sources that belong to > > the build system would need to be documented. Nearly all autotools-based > > packages would have to add several licenses, as install-sh is commonly MIT, > > aclocal.m4 and various generated files are commonly FSFULLR, configure > > scripts are commonly FSFUL, at least GNU configure.ac files are commonly > > FSFAP, and so on. If following this approach strictly, even the licenses of > > bundled libraries removed in %prep would need to be documented—after all, > > they are still in the source tarball, so they are in the SRPM. In addition > > to being tedious, I think that would make the License field less useful > > than it is now. > > Yes, exactly. And if we try to go down this path (which I don't think > we should), we would need a plan to change all packages, not just one > or two. >
For what it's worth, I prefer the effective license approach too. I'm just working with what people tell me. :( -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 on the list, report it: https://pagure.io/fedora-infrastructure
