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/legal@xxxxxxxxxxxxxxxxxxxxxxx/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. Zbyszek _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
