SPEC: https://pbrobinson.fedorapeople.org/libpisp.spec SRPM: https://pbrobinson.fedorapeople.org/libpisp-1.2.0-1.fc42.src.rpm Description: A helper library to generate run-time configuration for the Raspberry Pi ISP (PiSP), consisting of the Frontend and Backend hardware components. koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=131098324 FAS: pbrobinson Reproducible: Always
Copr build: https://copr.fedorainfracloud.org/coprs/build/8860655 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2357479-libpisp/fedora-rawhide-x86_64/08860655-libpisp/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
The CC0-1.0 license is allowed for content in Fedora, but not-allowed for code. The meson wrap file utils/libpisp.wrap is an ini-style configuration file and can be considered content. I think the meson options configuration file meson_options.txt should also be considered content. On the other hand, meson is a (domain-specific, limited) programming language, so I think all of the meson.build files should be considered code. The versioning script utils/version.py is certainly code. Even though these are all build-system files that do not contribute to the licenses of the binary RPMs, CC0-1.0 code cannot be included in source RPMs, either. For utils/version.py, you could upload a “filtered” source archive to the lookaside cache with the problematic file removed. For the meson.build files, this is not an option, because you need them to build the libary. The only possibilities would seem to be (1) convincing upstream to relicense the files, or (2) convincing Fedora Legal that a usage exception (https://docs.fedoraproject.org/en-US/legal/license-field/#_usage_exceptions) should apply in this case.
I have filed an issue with upstream, also note utils/version.py like the meson files aren't shipped.
Hey so an update. Upstream has changed the license on the items in the utils directory. So a question for the initial reviewer, with that change do you feel things are now in compliance? ref: https://github.com/raspberrypi/libpisp/pull/51
(In reply to Jef Spaleta from comment #4) > Hey so an update. > Upstream has changed the license on the items in the utils directory. So a > question for the initial reviewer, with that change do you feel things are > now in compliance? > > ref: https://github.com/raspberrypi/libpisp/pull/51 Note that I’m just a commenter for now, and I haven’t assigned myself the review. As of the latest upstream commit[1], the only remaining CC0-1.0 files in the source are meson files, e.g. [2]. While these don’t contribute to the License field, they are still distributed in the source RPM and need to be acceptably-licensed. There is an exception in the CC0-1.0 usage notes[3] that may be somewhat relevant here: > Upstream application of CC0-1.0 to trivial, noncreative, unoriginal, > and nonexpressive material as part of an effort to achieve conformance > to the REUSE specification (https://reuse.software/) (for example, > CI/CD configuration files) is permitted regardless of whether such > material would normally be classified as "content". That nearly applies to this case, but it does not look like upstream is actually targeting REUSE, and some of the meson.build files seem to be pushing the bounds of “trivial.” I still think it makes sense to ask upstream to relicense the meson.build files too, or run this case by Fedora Legal if that approach doesn’t bear fruit. [1] https://github.com/raspberrypi/libpisp/commit/dbbcf4f828396b494bcefe42fdc48beb6ae2a1c5 [2] https://github.com/raspberrypi/libpisp/blob/dbbcf4f828396b494bcefe42fdc48beb6ae2a1c5/src/meson.build [3] https://gitlab.com/fedora/legal/fedora-license-data/-/blob/56aeba99ba1b551e82b359bde277d1c51cc26e13/data/CC0-1.0.toml#L16-L20