Hi,
I would like to get an authoritative answer regarding the removal of a copyrighted file from upstream's source tarball.
The package in question is vxl [1] and the file in question is the Lenna image [2,3]. We currently remove it from the tarball manually and then upload the cleansed archive to the side cache. However, that effectively breaks scratch builds, since the source is not available.
I would like to remove the offending file in %prep, thereby excluding it from the RPMs. However the original archive as present in SRPM and side cache would then contain a non-free copyrighted file. Is that allowed?
Either way, since I couldn't find a clear answer in the packaging guidelines, I would also like to get approval for a text that could be published in the guidelines, so we have a place to point people to should this come up during review.
[1] https://src.fedoraproject.org/rpms/vxl [2] https://bugzilla.redhat.com/show_bug.cgi?id=1965175 [3] https://lintian.debian.org/tags/license-problem-non-free-img-lenna
Thanks for your advice,
I think that this paragraph in Packaging Guidelines / SourceURL answers the question:
Some upstream packages include patents or trademarks that we are not allowed to ship even as source code. In these cases you have to modify the source tarball to remove this code before you even upload it to the build system.
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-up...
The paragraph talks about code, but I imagine the same purpose would apply to binary files.
A.FI.
On Mon, Jul 10, 2023 at 12:53 PM Artur Frenszek-Iwicki suve@fedoraproject.org wrote:
I think that this paragraph in Packaging Guidelines / SourceURL answers the question:
Some upstream packages include patents or trademarks that we are not allowed to ship even as source code. In these cases you have to modify the source tarball to remove this code before you even upload it to the build system.
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-up...
The paragraph talks about code, but I imagine the same purpose would apply to binary files.
I agree. I had to deal with a similar issue (non-freely-redistributable test data), and the only way to handle this "safely" is to create "downstream" tarballs that don't include the affected files. This will make scratch builds break, but you can always turn those off if you're bothered by the error messages (i.e. switch from "Monitoring and Scratch build" to just "Monitoring").
Fabio
-
Artur Frenszek-Iwicki -
Fabio Valentini -
Sandro