Adding broader audience: https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4 Neither @pjones nor @ajax are responding.

On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera <jkucera(a)redhat.com&gt; wrote: > > > > Adding broader audience: https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4 > > > > Neither @pjones nor @ajax are responding. > > > > I'll deal with it. > This is done, and updates have been proposed for stable releases: * Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-31358601f8 * Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4c93fe43a0 Please karma them up for release to stable. -- 真実はいつも一つ！/ Always, there's only one truth!

I believe this patch is not correct. "The License: field refers to the licenses of the contents of the binary rpm." https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... In the README file there is writted: "cdparanoia (the command line tool) is released under the GPLv2. The interface and paranoia libraries are covered by the LGPLv2.1." 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.

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

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...). It has also come up on the fedora-legal list recently (https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...). 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.

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...). It has also come up on the fedora-legal list recently ( https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o... ). 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.

Hi Zbyszek, reply inline On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek < zbyszek(a)in.waw.pl&gt; 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...). > It has also come up on the fedora-legal list recently ( > https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o... > ). > > 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. > So what should be the correct License then? According to [1], the one possibility is License: (GPLv2 and GPLv2+) and LGPLv2 but according to [2] point 2, this should be shortened to License: GPLv2 and LGPLv2 because GPLv2 is stricter.

Should the patch be reverted with the comment explaining multiple licensing situations?