List of packages with problematic license
I am processing results of license-validate audit, but it takes longer... So I am providing raw results of what I have. If you are maintainer one of these packages you may expect either BZ report or Pagure PR for your package in upcoming days/weeks. In the attachment you will find more details (albeit not super human friendly). The list likely contains lots of false positives. And it is missing packages I already reported. Miroslav hibernate-jpa-2.0-api.spec hibernate-jpa-2.1-api.spec hunspell-pt.spec iptables.spec ipxe.spec iucode-tool.spec jbosscache-support.spec jboss-jaxrs-2.0-api.spec jsmath-fonts.spec kdevelop-pg-qt.spec knot-resolver.spec knot.spec libprelude.spec librhsm.spec libva-intel-hybrid-driver.spec libvarlink.spec lttng-ust.spec lumina-desktop.spec lvm2.spec man-pages-l10n.spec Mayavi.spec midori.spec mingw-LibRaw.spec mingw-libunistring.spec mingw-python-certifi.spec mlir.spec mono.spec mono.spec mpdecimal.spec mxml.spec nodejs-tape.spec ogre.spec opencascade.spec openjfx.spec openjfx8.spec pacemaker.spec paho-c.spec passwdqc.spec pcs.spec perl-BSSolv.spec perl-Date-HolidayParser.spec perl-Exporter-Tidy.spec perl-PDF-API2.spec perl-PDF-Builder.spec perl-qooxdoo-compat.spec perl-Regexp-Pattern-DefHash.spec perl-Regexp-Pattern.spec perl-RPC-XML.spec perl.spec perl.spec perl-TermReadKey.spec perl-Test-Command-Simple.spec perl-Text-Aligner.spec php-manual-en.spec phpMyAdmin.spec pidgin-sipe.spec pidgin-sipe.spec pokerth.spec ProDy.spec proj.spec python-coverage.spec python-pathspec.spec python-pyface.spec python-pygit2.spec python-resolvelib.spec python-restfly.spec python-Traits.spec python-traitsui.spec python-userpath.spec qmmp.spec qt5-qtfeedback.spec rachota.spec rizin.spec rubygem-webrick.spec rust-ambient-authority.spec rust-base100.spec rust-cap-primitives.spec rust-cap-rand.spec rust-cap-std.spec rust-cranelift-bforest.spec rust-cranelift-codegen-meta.spec rust-cranelift-codegen-shared.spec rust-cranelift-codegen.spec rust-cranelift-entity.spec rust-cranelift-frontend.spec rust-cranelift-native.spec rust-cranelift-wasm.spec rust-file-per-thread-logger.spec rust-fs-set-times.spec rust-io-lifetimes.spec rust-posish.spec rust-rav1e.spec rust-regalloc.spec rust-target-lexicon.spec rust-tpm2-policy.spec rust-unsafe-io.spec rust-wasmparser.spec rust-wasmtime-cache.spec rust-wasmtime-environ.spec rust-wasmtime-fiber.spec rust-wasmtime-types.spec rust-wast.spec rust-wat.spec sblim-cim-client.spec sblim-cim-client2.spec sblim-cmpi-devel.spec sblim-cmpi-devel.spec sblim-cmpi-fsvol.spec sblim-cmpi-network.spec sblim-cmpi-nfsv3.spec sblim-cmpi-nfsv4.spec sblim-cmpi-params.spec sblim-cmpi-sysfs.spec sblim-cmpi-syslog.spec sblim-sfcCommon.spec sblim-smis-hba.spec sblim-testsuite.spec scantailor.spec singularity.spec smc-tools.spec spec-version-maven-plugin.spec star.spec strace.spec stun.spec subscription-manager.spec subscription-manager.spec sunpinyin.spec surgescript.spec surgescript.spec surgescript.spec sympa.spec tcmu-runner.spec texlive-base.spec texlive-base.spec texlive.spec texlive.spec texlive.spec texlive.spec texlive.spec texlive.spec tlog.spec uboot-tools.spec virtualbox-guest-additions.spec wwl.spec yakuake.spec ydotool.spec zfs-fuse.spec 4diac-forte.spec Testing rpm-specs/hibernate-jpa-2.0-api.spec No terminal defined for 'E' at line 1 col 2 EPL and BSD Testing rpm-specs/hibernate-jpa-2.1-api.spec No terminal defined for 'E' at line 1 col 2 EPL and BSD Testing rpm-specs/hunspell-pt.spec No terminal defined for 'M' at line 1 col 14 ((LGPLv3 or MPL) and LGPLv2) and (GPLv2 or LGPLv2 or ^^^ Testing rpm-specs/iptables.spec No terminal defined for 'A' at line 1 col 12 GPLv2 and Artistic Licence 2.0 and ISC ^ Expecting: Testing rpm-specs/ipxe.spec No terminal defined for 'w' at line 1 col 8 GPLv2 with additional permissions and BSD ^ Expecting: {'AND', 'OR'} Testing rpm-specs/iucode-tool.spec No terminal defined for 'G' at line 1 col 2 GPlv2+ ^ Testing rpm-specs/jbosscache-support.spec No terminal defined for 'L' at line 1 col 2 LGPL ^ Testing rpm-specs/jboss-jaxrs-2.0-api.spec No terminal defined for 'C' at line 1 col 3 (CDDL or GPLv2 with exceptions) and ASL 2 ^ Testing rpm-specs/jsmath-fonts.spec No terminal defined for 'P' at line 1 col 2 Public domain ^ Testing rpm-specs/kdevelop-pg-qt.spec No terminal defined for 'w' at line 1 col 21 LGPLv2+ and GPLv2+ with exception ^ Expecting: {'AND', 'OR'} Testing rpm-specs/knot-resolver.spec No terminal defined for 'G' at line 1 col 2 GPL-3.0-or-later ^ Testing rpm-specs/knot.spec No terminal defined for 'G' at line 1 col 2 GPL-3.0-or-later ^ Testing rpm-specs/libprelude.spec No terminal defined for 'L' at line 1 col 2 LGPL-2.1+ ^ Testing rpm-specs/librhsm.spec No terminal defined for '.' at line 1 col 8 LGPLv2.1+ ^ Testing rpm-specs/libva-intel-hybrid-driver.spec No terminal defined for 'N' at line 1 col 18 MIT and B
Re: List of packages with problematic license
On Sat, Jan 1, 2022 at 11:12 AM Miroslav Suchý wrote: > (snip) > > rust-ambient-authority.spec > rust-base100.spec > rust-cap-primitives.spec > rust-cap-rand.spec > rust-cap-std.spec > rust-cranelift-bforest.spec > rust-cranelift-codegen-meta.spec > rust-cranelift-codegen-shared.spec > rust-cranelift-codegen.spec > rust-cranelift-entity.spec > rust-cranelift-frontend.spec > rust-cranelift-native.spec > rust-cranelift-wasm.spec > rust-file-per-thread-logger.spec > rust-fs-set-times.spec > rust-io-lifetimes.spec > rust-posish.spec > rust-rav1e.spec > rust-regalloc.spec > rust-target-lexicon.spec > rust-tpm2-policy.spec > rust-unsafe-io.spec > rust-wasmparser.spec > rust-wasmtime-cache.spec > rust-wasmtime-environ.spec > rust-wasmtime-fiber.spec > rust-wasmtime-types.spec > rust-wast.spec > rust-wat.spec Thanks for working on this! It looks like a lot of the Rust packages in this list are caused by "ASL 2.0 with exceptions". This was translated from the "Apache-2.0 WITH LLVM-Exception" SPDX identifier, but it was only recently pointed out to us, that for the purposes of Fedora packages, this is equivalent to just plain "ASL 2.0" without exceptions. I'll be cleaning up those if and when I come across them. I reported this issue upstream (where the SPDX -> Fedora mapping is maintained for some .spec generators): https://pagure.io/fedora-rust/rust2rpm/issue/163 Though I hope we will in the future be able to just use the SPDX identifier from upstream metadata directly instead of doing conversion. Fabio ___ 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: List of packages with problematic license
On Sat, Jan 01, 2022 at 11:11:47AM +0100, Miroslav Suchý wrote: > ipxe.spec ... > Testing rpm-specs/ipxe.spec > No terminal defined for 'w' at line 1 col 8 > > GPLv2 with additional permissions and BSD >^ > > Expecting: {'AND', 'OR'} The license does appear to be accurate in the sense that it reflects the somewhat unusual license of iPXE. Specifically iPXE permits distributing unmodified binaries without source if they are "built from publicly available source code" but without imposing the usual GPL obligation of the distributor having to provide source. (None of this applies to Fedora of course since we do always provide source.) Also it should be GPLv2+ not GPLv2. I cannot see anywhere where the source limits itself to GPLv2 only. The situation seems a bit similar to OCaml packages where we often use "LGPLv2+ with exceptions". OCaml uses LGPLv2+ but grants additional permissions to do with not requiring distributors to comply with some of the obligations in clause 2 of the LGPLv2. So maybe the iPXE license should be: License: GPLv2+ with exceptions and BSD I didn't change it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: List of packages with problematic license
Dne 02. 01. 22 v 17:19 Richard W.M. Jones napsal(a): Testing rpm-specs/ipxe.spec No terminal defined for 'w' at line 1 col 8 GPLv2 with additional permissions and BSD ^ Expecting: {'AND', 'OR'} The license does appear to be accurate in the sense that it reflects the somewhat unusual license of iPXE. The problem is that GPLv2 with additional permissions is not valid short name from https://fedoraproject.org/wiki/Licensing:Main#Software_License_List The License tag was never formally defined. If we agree that there can be anything, then let it be. Just most of our strings are in the form: license: "(" license ")" | license operator license | short_name operator: "and" | "or" where short_name is the identifier from Licensing:main. If we fix few exceptions like "license, license" then we will benefit from * unified syntax * machine readable string * automatic validation I recommend to track such exceptions in comments. E.g. # the actual license have additional permission allowing to License: GPLv2 and BSD Miroslav ___ 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: List of packages with problematic license
On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote: > Dne 02. 01. 22 v 17:19 Richard W.M. Jones napsal(a): > > Testing rpm-specs/ipxe.spec > No terminal defined for 'w' at line 1 col 8 > > GPLv2 with additional permissions and BSD >^ > > Expecting: {'AND', 'OR'} > > The license does appear to be accurate in the sense that it reflects > the somewhat unusual license of iPXE. > > The problem is that > > GPLv2 with additional permissions > > is not valid short name from > > https://fedoraproject.org/wiki/Licensing:Main#Software_License_List Oh I see, I thought that the OCaml license ("LGPLv2+ with exceptions") was somehow composed of + "with exceptions". But I see from the list that the whole thing is a permitted license. > The License tag was never formally defined. If we agree that there can be > anything, then let it be. > > Just most of our strings are in the form: > > license: "(" license ")" | license operator license | short_name > operator: "and" | "or" > > where short_name is the identifier from Licensing:main. > > If we fix few exceptions like "license, license" then we will benefit from > > * unified syntax > > * machine readable string > > * automatic validation > > I recommend to track such exceptions in comments. E.g. > > # the actual license have additional permission allowing to > License: GPLv2 and BSD Well I'm not so sure since the license for OCaml software is certainly not just LGPLv2+, and the way OCaml is linked makes it impossible for distributors to meaningfully comply with the problematic subclause of clause 2 of the LGPL, hence the need for a permissive exception. This sounds like something we would need to record for automation. Rich. > Miroslav > > ___ > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: List of packages with problematic license
On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote: > The License tag was never formally defined. If we agree that there can be > anything, then let it be. The Pending PR here updates that to: SPDX License identifier or expression (from our "Good" list). https://pagure.io/packaging-committee/pull-request/1142#_1__38 Although given the context here, I note that that's ambiguous about whether the _whole expression_ must be on the list — I don't think that's the intention! [CC'ing this to the legal list, btw.] -- Matthew Miller Fedora Project Leader ___ 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: List of packages with problematic license
On Sat, 2022-01-01 at 11:11 +0100, Miroslav Suchý wrote: > I am processing results of license-validate audit, but it takes > longer... > So I am providing raw results of what I have. If you are maintainer one > of these packages you may expect either BZ report or Pagure PR for your > package in upcoming days/weeks. > In the attachment you will find more details (albeit not super human > friendly). > The list likely contains lots of false positives. And it is missing > packages I already reported. > Miroslav > > hibernate-jpa-2.0-api.spec Testing rpm-specs/hibernate-jpa-2.0-api.spec No terminal defined for 'E' at line 1 col 2 EPL and BSD What is the problem with this one ? > hibernate-jpa-2.1-api.spec > hunspell-pt.spec > iptables.spec > ipxe.spec > iucode-tool.spec > jbosscache-support.spec > jboss-jaxrs-2.0-api.spec > jsmath-fonts.spec > kdevelop-pg-qt.spec > knot-resolver.spec > knot.spec > libprelude.spec > librhsm.spec > libva-intel-hybrid-driver.spec > libvarlink.spec > lttng-ust.spec > lumina-desktop.spec > lvm2.spec > man-pages-l10n.spec > Mayavi.spec > midori.spec > mingw-LibRaw.spec > mingw-libunistring.spec > mingw-python-certifi.spec > mlir.spec > mono.spec > mono.spec > mpdecimal.spec > mxml.spec > nodejs-tape.spec > ogre.spec > opencascade.spec > openjfx.spec > openjfx8.spec > pacemaker.spec > paho-c.spec > passwdqc.spec > pcs.spec > perl-BSSolv.spec > perl-Date-HolidayParser.spec > perl-Exporter-Tidy.spec > perl-PDF-API2.spec > perl-PDF-Builder.spec > perl-qooxdoo-compat.spec > perl-Regexp-Pattern-DefHash.spec > perl-Regexp-Pattern.spec > perl-RPC-XML.spec > perl.spec > perl.spec > perl-TermReadKey.spec > perl-Test-Command-Simple.spec > perl-Text-Aligner.spec > php-manual-en.spec > phpMyAdmin.spec > pidgin-sipe.spec > pidgin-sipe.spec > pokerth.spec > ProDy.spec > proj.spec > python-coverage.spec > python-pathspec.spec > python-pyface.spec > python-pygit2.spec > python-resolvelib.spec > python-restfly.spec > python-Traits.spec > python-traitsui.spec > python-userpath.spec > qmmp.spec > qt5-qtfeedback.spec > rachota.spec > rizin.spec > rubygem-webrick.spec > rust-ambient-authority.spec > rust-base100.spec > rust-cap-primitives.spec > rust-cap-rand.spec > rust-cap-std.spec > rust-cranelift-bforest.spec > rust-cranelift-codegen-meta.spec > rust-cranelift-codegen-shared.spec > rust-cranelift-codegen.spec > rust-cranelift-entity.spec > rust-cranelift-frontend.spec > rust-cranelift-native.spec > rust-cranelift-wasm.spec > rust-file-per-thread-logger.spec > rust-fs-set-times.spec > rust-io-lifetimes.spec > rust-posish.spec > rust-rav1e.spec > rust-regalloc.spec > rust-target-lexicon.spec > rust-tpm2-policy.spec > rust-unsafe-io.spec > rust-wasmparser.spec > rust-wasmtime-cache.spec > rust-wasmtime-environ.spec > rust-wasmtime-fiber.spec > rust-wasmtime-types.spec > rust-wast.spec > rust-wat.spec > sblim-cim-client.spec > sblim-cim-client2.spec > sblim-cmpi-devel.spec > sblim-cmpi-devel.spec > sblim-cmpi-fsvol.spec > sblim-cmpi-network.spec > sblim-cmpi-nfsv3.spec > sblim-cmpi-nfsv4.spec > sblim-cmpi-params.spec > sblim-cmpi-sysfs.spec > sblim-cmpi-syslog.spec > sblim-sfcCommon.spec > sblim-smis-hba.spec > sblim-testsuite.spec > scantailor.spec > singularity.spec > smc-tools.spec > spec-version-maven-plugin.spec > star.spec > strace.spec > stun.spec > subscription-manager.spec > subscription-manager.spec > sunpinyin.spec > surgescript.spec > surgescript.spec > surgescript.spec > sympa.spec > tcmu-runner.spec > texlive-base.spec > texlive-base.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > tlog.spec > uboot-tools.spec > virtualbox-guest-additions.spec > wwl.spec > yakuake.spec > ydotool.spec > zfs-fuse.spec > 4diac-forte.spec > ___ > 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 -- Sérgio M. B. ___ 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.fedorap
Re: List of packages with problematic license
On 03. 01. 22 19:16, Sérgio Basto wrote: Testing rpm-specs/hibernate-jpa-2.0-api.spec No terminal defined for 'E' at line 1 col 2 EPL and BSD What is the problem with this one ? There is no EPL in https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses -- just EPL-1.0 and EPL-2.0. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: List of packages with problematic license
On Sat, Jan 1, 2022 at 11:20 AM Miroslav Suchý wrote: > I am processing results of license-validate audit, but it takes longer... > > So I am providing raw results of what I have. If you are maintainer one of > these packages you may expect either BZ report or Pagure PR for your > package in upcoming days/weeks. > > In the attachment you will find more details (albeit not super human > friendly). > https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses for the Creative Commons licenses seems to e.g. just have CC-BY-SA while e.g. https://spdx.org/licenses/ suggests using the version with those like e.g. CC-BY-SA-4.0. Is there anything in the works already to take care of this issue? The attachment is showing a complaint in the pacemaker-package. Regards, Klaus > The list likely contains lots of false positives. And it is missing > packages I already reported. > > Miroslav > > > hibernate-jpa-2.0-api.spec > hibernate-jpa-2.1-api.spec > hunspell-pt.spec > iptables.spec > ipxe.spec > iucode-tool.spec > jbosscache-support.spec > jboss-jaxrs-2.0-api.spec > jsmath-fonts.spec > kdevelop-pg-qt.spec > knot-resolver.spec > knot.spec > libprelude.spec > librhsm.spec > libva-intel-hybrid-driver.spec > libvarlink.spec > lttng-ust.spec > lumina-desktop.spec > lvm2.spec > man-pages-l10n.spec > Mayavi.spec > midori.spec > mingw-LibRaw.spec > mingw-libunistring.spec > mingw-python-certifi.spec > mlir.spec > mono.spec > mono.spec > mpdecimal.spec > mxml.spec > nodejs-tape.spec > ogre.spec > opencascade.spec > openjfx.spec > openjfx8.spec > pacemaker.spec > paho-c.spec > passwdqc.spec > pcs.spec > perl-BSSolv.spec > perl-Date-HolidayParser.spec > perl-Exporter-Tidy.spec > perl-PDF-API2.spec > perl-PDF-Builder.spec > perl-qooxdoo-compat.spec > perl-Regexp-Pattern-DefHash.spec > perl-Regexp-Pattern.spec > perl-RPC-XML.spec > perl.spec > perl.spec > perl-TermReadKey.spec > perl-Test-Command-Simple.spec > perl-Text-Aligner.spec > php-manual-en.spec > phpMyAdmin.spec > pidgin-sipe.spec > pidgin-sipe.spec > pokerth.spec > ProDy.spec > proj.spec > python-coverage.spec > python-pathspec.spec > python-pyface.spec > python-pygit2.spec > python-resolvelib.spec > python-restfly.spec > python-Traits.spec > python-traitsui.spec > python-userpath.spec > qmmp.spec > qt5-qtfeedback.spec > rachota.spec > rizin.spec > rubygem-webrick.spec > rust-ambient-authority.spec > rust-base100.spec > rust-cap-primitives.spec > rust-cap-rand.spec > rust-cap-std.spec > rust-cranelift-bforest.spec > rust-cranelift-codegen-meta.spec > rust-cranelift-codegen-shared.spec > rust-cranelift-codegen.spec > rust-cranelift-entity.spec > rust-cranelift-frontend.spec > rust-cranelift-native.spec > rust-cranelift-wasm.spec > rust-file-per-thread-logger.spec > rust-fs-set-times.spec > rust-io-lifetimes.spec > rust-posish.spec > rust-rav1e.spec > rust-regalloc.spec > rust-target-lexicon.spec > rust-tpm2-policy.spec > rust-unsafe-io.spec > rust-wasmparser.spec > rust-wasmtime-cache.spec > rust-wasmtime-environ.spec > rust-wasmtime-fiber.spec > rust-wasmtime-types.spec > rust-wast.spec > rust-wat.spec > sblim-cim-client.spec > sblim-cim-client2.spec > sblim-cmpi-devel.spec > sblim-cmpi-devel.spec > sblim-cmpi-fsvol.spec > sblim-cmpi-network.spec > sblim-cmpi-nfsv3.spec > sblim-cmpi-nfsv4.spec > sblim-cmpi-params.spec > sblim-cmpi-sysfs.spec > sblim-cmpi-syslog.spec > sblim-sfcCommon.spec > sblim-smis-hba.spec > sblim-testsuite.spec > scantailor.spec > singularity.spec > smc-tools.spec > spec-version-maven-plugin.spec > star.spec > strace.spec > stun.spec > subscription-manager.spec > subscription-manager.spec > sunpinyin.spec > surgescript.spec > surgescript.spec > surgescript.spec > sympa.spec > tcmu-runner.spec > texlive-base.spec > texlive-base.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > tlog.spec > uboot-tools.spec > virtualbox-guest-additions.spec > wwl.spec > yakuake.spec > ydotool.spec > zfs-fuse.spec > 4diac-forte.spec > ___ > 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
Re: List of packages with problematic license
On Mon, Jan 03, 2022 at 12:12:38PM -0500, Matthew Miller wrote: On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote: The License tag was never formally defined. If we agree that there can be anything, then let it be. The Pending PR here updates that to: SPDX License identifier or expression (from our "Good" list). https://pagure.io/packaging-committee/pull-request/1142#_1__38 Although given the context here, I note that that's ambiguous about whether the _whole expression_ must be on the list — I don't think that's the intention! I think in some cases, it may be. As our discussions on this PR have noted, Fedora may approve an expression but not all expressions that SPDX can represent. So the objective is more about using the tokens and expression syntax defined by SPDX, but then we have our list of approved expressions. This is also necessary because we need to maintain our own list of LicenseRef tokens for things we approve for Fedora but that do not have an upstream SPDX token. However, in many cases Fedora is ok with combining something with GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been working through has some of these expressions that are a license token and then a WITH qualifier. So this may be more about ensuring that a WITH clause isn't noted as approved without also requiring the main token. IANAL, so take my comments with that in mind. And this is where I defer to Jilayne for the actual expertise here. :) -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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: List of packages with problematic license
On Mon, 3 Jan 2022 at 18:35, Miro Hrončok wrote: > > On 03. 01. 22 19:16, Sérgio Basto wrote: > > Testing rpm-specs/hibernate-jpa-2.0-api.spec > > No terminal defined for 'E' at line 1 col 2 > > > > EPL and BSD > > > > What is the problem with this one ? > > There is no EPL in https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses > -- just EPL-1.0 and EPL-2.0. > EPL was renamed as EPL-1.0 when EPL-2.0 was added. However, don't make the assumption that your project is still EPL-1.0 because many projects moved over to EPL-2.0 after it was released. ___ 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: [Fedora-legal-list] Re: List of packages with problematic license
On Wed, Jan 5, 2022 at 3:45 PM Jilayne Lovejoy wrote: > > There were some license combinations (could be AND, OR, or WITH) that > are on the "good" list but a different combination might need separate > approval. > > Off top of head, I think any L/GPL WITH [exception] would fall into the > category of needing to be capture as the full license expression since > the specific exception would need to be reviewed and approved and would > be different text than another exception. > > But for any combination of previously approved license for Fedora - > e.g., "MIT OR GPL-2.0-only", "Apache-2.0 AND BSD-3-Clause" and so on - > separate listings would not be necessary - agreed? > > (and this concept needs to be documented... adding to the list of items > to better document) > > > > > However, in many cases Fedora is ok with combining something with > > GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been > > working through has some of these expressions that are a license token > > and > > then a WITH qualifier. So this may be more about ensuring that a WITH > > clause > > isn't noted as approved without also requiring the main token. > See above. Also, as per SPDX License List expression syntax (found in an > appendix to the SPDX spec), you have to have a valid license ID on the > left side of the WITH operator and a valid exception ID on the right > side (as one would expect) In related internal work being done largely by Bryan Sutula and Russell Gelvin on certain Red Hat products, there's been an effort to review for approval exceptions (what SPDX would consider exceptions) identified mainly through ScanCode Toolkit. I believe a given exception text will be approved basically without regard to the license it is associated with. If you look at the current Fedora good list, the impression is that there are a small number of uses of exceptions out there used with particular licenses (I think in all cases, licenses in the GPL family). But as Bryan and Russell have been finding, the actual picture is much bigger and more complex. I am pretty sure I've seen cases where an exception normally used with GPL version 2 is used with LGPL version 2.x. This reminds me that not too long ago I suggested that Fedora abandon any effort to note the existence of (permissive) exceptions in license tags, as being too much work for dubious gain beyond classification for the sake of classification. But the anticipated switch to SPDX identifiers raises the issue of what the license tag is actually *for*, and how much detail or specificity it ought to embody, since SPDX identifiers permit and in a sense encourage a relatively high level of detail of license description. That's a whole other topic but something I think has to be addressed as well. We might be assuming now that license tags ought to have as much detail as possible (something akin to a human review of the output of a scanner like ScanCode Toolkit on the files in a source tarball, with only limited processing); this isn't the approach consistently taken by Fedora packagers today. Richard ___ 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