On Sun, Mar 21, 2021 at 11:47:17AM +0200, Otto Urpelainen wrote: > Greetings, > > I am doing my first Fedora package review [1], for litehtml library. > The source tree contains some bundled items that, in violation of > original licenses, do not include a copy of the relevant licenses. > There are two problem items: > > 1. gumbo-parser is included in source form and only contains link to > the correct license in source files and repository README, but > license text itself is not included like the license, Apache > Software License 2.0, demands. This one is easy to fix: just include the license file as another Source. It'll then be part of the srpm, even though it's not part of the Source0 tarball. Since the upstream *links* to a license, there is no risk of confusion about the text, you can even use this exact URL for the Source line… Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1]. > 2. tools/xxd.exe is included as a (Windows) binary used during the > build. It does not have any mention of licensing. Supposedly, it > comes from Vim [2] and uses the Vim License [3], which also demands > including copy of the license. This one is harder. If the licensing is unclear or cumbersome, or if the file is sufficiently large to be worth optimizing out, I'd try to regenerate the sources. [2] is a old script from calibre.rpm to do similar "tarball optimization" on the fly. With such a script, downloading sources is not much of an extra effort, as long as one remembers to use the script instead of 'spectool -g'. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text [2] https://src.fedoraproject.org/rpms/calibre/blob/fea70390a1a085be6155894425c353922861bc18/f/getsources.sh Also note that if decide to leave the file in the tarball, and the file is distributed under the Vim license, and the file is removed in %prep, information about this license belongs in a comment in the spec file. The License tag is for the binary rpm [1]. > Neither of these are actually required for anything. Fedora already > has the gumbo-parser package that can be used, while the Windows > binary is obviously useless, but the vim-common package contains a > usable xxd binary. > > Since neither 1 or 2 is needed for anything, they can be removed in > %prep section of the specfile. However, they still end up in the > srpm. The fedora-review tool does not see this as a problem: "Note: > Checking patched sources after %prep for licenses." > > Is it really so that srpms are allowed have content that violates > licenses, as long as %prep removes them? No, you are not allowed to create an srpm that would violate the license of the contents, or that would cause Fedora or the mirrors to violate the license when distributed. But it is allowed to have content which would violate the packaging guidelines, if it was present in binary rpms, as long as that doesn't actually happen. Essentially, if the file is something that we would be *allowed* to distribute, but which we just don't like, it's OK to have it in srpm and remove in %prep. So for example, we often remove .jar files in %prep of java packages, because the contents are not useful for us, but don't cause licensing problems during distribution. OTOH, we often have fonts files which do not allow redistribution, and those need to be cleaned from the tarball. > I am not able to find any > explicit confirmation for this interpretation the the Licensing > Guidelines [4]. Actually, the guidelines are generally do not make a > clear distinction between srpms and binary rpms. Maybe this: https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#Does_the_License:_tag_cover_the_SRPM_or_the_binary_RPM.3F Zbyszek _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
