Re: [cdparanoia] License field fix awaiting to be merged
On Mon, Jun 07, 2021 at 06:27:17PM +0200, Jiri Kucera wrote: > Hi Zbyszek, > > reply inline > > On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > On Wed, Jun 02, 2021 at 01:31:15PM -, 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. > > > > 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. Yes, the second version is correct. The first version is not correct, because it's trying to say that you can distribute some specific binary under terms of "GPLv2 and GPLv2-or-any-later" at the same time, and the only way to you can do this without violating the terms of the first part is to ignore the "-or-any-later" clause of the second part. > Should the patch be reverted with the comment > explaining multiple licensing situations? Or just reverted. I think the comment that was there before was sufficient. Zbyszek ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
CC'ing Zbyszek On Mon, Jun 7, 2021 at 6:27 PM Jiri Kucera wrote: > Hi Zbyszek, > > reply inline > > On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > >> On Wed, Jun 02, 2021 at 01:31:15PM -, 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. >> > > 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? > > Regards, > Jiri > > [1] > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario > [2] > https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F > ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
Hi Zbyszek, reply inline On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Jun 02, 2021 at 01:31:15PM -, 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. > 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? Regards, Jiri [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario [2] https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
If the README has the last word here and it does not matter that some sequences of bits of /usr/bin/cdparanoia are licensed under GPLv2+ and the rest of it under GPLv2, so be it. On the other hand, https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario states that if /usr/bin/foo is generated from foo1.c licensed under A and foo2.c licensed under B, where A and B are compatible, but different, licenses, then this scenario should be handled by "(A and B)" in License field. The best way to deal with this situation would be to ask upstream to re-license those two files to GPLv2, but cdparanoia upstream is effectively dead. Regards, Jiri On Wed, Jun 2, 2021 at 2:23 PM Andrea Musuruane wrote: > 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/LicensingGuidelines/ > > 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. > > BR, > > Andrea > > > On Wed, Jun 2, 2021 at 2:03 PM Jiri Kucera wrote: > >> Thanks Neal! >> >> On Wed, Jun 2, 2021 at 1:06 PM Neal Gompa wrote: >> >>> On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa wrote: >>> > >>> > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera 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! >>> >>> ___ >> 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 >> > ___ > 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 > ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
Am 02.06.21 um 17:42 schrieb Neal Gompa: For what it's worth, I prefer the effective license approach too. I'm just working with what people tell me. :( If we just mention the source license(s) in the License tag this means it will become harder to check if some software can depend on a specific RPM. For example I maintain a package which has a test suite under the AGPL (which is not shipped) but the actual software uses a 3-clause BSD. I guess some users might prefer not to use the packaged library if they see the AGPL even though that only affects tests. Felix ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
On Wed, Jun 2, 2021 at 11:41 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jun 02, 2021 at 01:31:15PM -, 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
Re: [cdparanoia] License field fix awaiting to be merged
On Wed, Jun 02, 2021 at 01:31:15PM -, 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. Zbyszek ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
> 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/). 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. 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. ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
> > The issue here is that there's not a way to describe the SRPM license > separate from the binary RPM license. So that information is important > for SRPM distribution. > But Licensing Guidelines make clear that the License: field refers to the binary packages not source ones. BR, Andrea ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
On Wed, Jun 2, 2021 at 8:15 AM Andrea Musuruane wrote: > > 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/LicensingGuidelines/ > > 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. > The issue here is that there's not a way to describe the SRPM license separate from the binary RPM license. So that information is important for SRPM distribution. -- 真実はいつも一つ！/ 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
Re: [cdparanoia] License field fix awaiting to be merged
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/LicensingGuidelines/ 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. BR, Andrea On Wed, Jun 2, 2021 at 2:03 PM Jiri Kucera wrote: > Thanks Neal! > > On Wed, Jun 2, 2021 at 1:06 PM Neal Gompa wrote: > >> On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa wrote: >> > >> > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera 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! >> >> ___ > 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 > ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
Thanks Neal! On Wed, Jun 2, 2021 at 1:06 PM Neal Gompa wrote: > On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa wrote: > > > > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera 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! > > ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa wrote: > > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera 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! ___ 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
Re: [cdparanoia] License field fix awaiting to be merged
On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera wrote: > > Adding broader audience: > https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4 > > Neither @pjones nor @ajax are responding. > I'll deal with it. -- 真実はいつも一つ！/ 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
