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.
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.
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? 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.
Perhaps somebody on this list understands this topic and can explain how this situation should be handled?
Regards, Otto
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1939875 [2]: https://github.com/vim/vim/tree/master/src/xxd [3]: https://github.com/vim/vim/blob/master/LICENSE [4]: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
Otto Urpelainen wrote on 2021/03/21 18:47:
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:
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.
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.
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? 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.
Perhaps somebody on this list understands this topic and can explain how this situation should be handled?
Regards, Otto
If you think the relevant files are not allowed to be included in srpm, remove the file and regenerate tarball, see: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-up...
Regards, Mamoru
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:
- 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].
- 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/LicensingGuideline... [2] https://src.fedoraproject.org/rpms/calibre/blob/fea70390a1a085be6155894425c3...
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_Licen...
Zbyszek
First of all, thank your for your answers Zbigniew and Mamoru in another thread. The matter is now clear, I am sure that the packager can create a working solution from these answers.
Zbigniew Jędrzejewski-Szmek kirjoitti 21.3.2021 klo 12.52:
On Sun, Mar 21, 2021 at 11:47:17AM +0200, Otto Urpelainen wrote:
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.
Thank you for the clarification. It is just like I interpreted it.
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_Licen...
Yes, that is related, and also this: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
Also, fedora-review's template actually also contains a checklist item for this.
[ ]: Sources contain only permissible code or content.
Dne 21. 03. 21 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a):
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:
- 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…
Just FTR, including license file as SOURCE have always been wrong suggestion, because the review guidelines [1] states the following:
MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %license.[4]
Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1].
And this is just SHOULD:
SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [28]
Granted, the licensing guidelines you are referring to might be interpreted differently.
Vít
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
On Mon, Mar 22, 2021 at 09:19:43AM +0100, Vít Ondruch wrote:
Dne 21. 03. 21 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a):
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:
- 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…
Just FTR, including license file as SOURCE have always been wrong suggestion, because the review guidelines [1] states the following:
My interpretation was based on the text in the Licensing Guidelines. I consider those to be authoritative over the Review Guidelines, which after all are and must be just a derived checklist of things specified elsewhere in the guidelines.
MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %license.[4]
The authoritative text is unequivocal:
[when the license text is required by the license] either "Include a copy of what they believe the license text is" or "Choose not to package that software for Fedora".
Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1].
And this is just SHOULD:
SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [28]
Again, the authoritative text says:
"Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager."
"It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code. but are still encouraged to point out this issue to upstream and encourage them to remedy it."
It does NOT say "MUST", but comes very close. Also by saying "NOT required [in the other case]", it implies that [in this case] it is.
Granted, the licensing guidelines you are referring to might be interpreted differently.
"might be"? I don't think there's much wiggle room.
I think the confusion in the Review Guidelines stems from the fact that we didn't always appreciate that there are some licenses which require the text to be present, and the lack of the text is a violation of the license itself. Many of the popular licenses are *not* like this (in particular various flavours of GPL and CC), so the Review Guidelines erroneously treat this is a minor issue.
Zbyszek
Dne 22. 03. 21 v 10:49 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Mar 22, 2021 at 09:19:43AM +0100, Vít Ondruch wrote:
Dne 21. 03. 21 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a):
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:
- 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…
Just FTR, including license file as SOURCE have always been wrong suggestion, because the review guidelines [1] states the following:
My interpretation was based on the text in the Licensing Guidelines. I consider those to be authoritative over the Review Guidelines, which after all are and must be just a derived checklist of things specified elsewhere in the guidelines.
MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %license.[4]
The authoritative text is unequivocal:
[when the license text is required by the license] either "Include a copy of what they believe the license text is" or "Choose not to package that software for Fedora".
Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1].
And this is just SHOULD:
SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [28]
Again, the authoritative text says:
"Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager."
"It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code. but are still encouraged to point out this issue to upstream and encourage them to remedy it."
It does NOT say "MUST", but comes very close. Also by saying "NOT required [in the other case]", it implies that [in this case] it is.
Granted, the licensing guidelines you are referring to might be interpreted differently.
"might be"? I don't think there's much wiggle room.
If there is no wiggle room, then you can't start suggesting "just include the license file as another Source." You should start with "Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1]." followed by that the package is forbidden from Fedora as long as there is no license file included or "that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream,".
My interpretation is that it is reasonably fine to include the package into Fedora even without license file, while the situation should be certainly clarified with upstream.
But I'll be glad, if the licensing guidelines as well as review guidelines are unambiguous and aligned.
Vít
I think the confusion in the Review Guidelines stems from the fact that we didn't always appreciate that there are some licenses which require the text to be present, and the lack of the text is a violation of the license itself. Many of the popular licenses are *not* like this (in particular various flavours of GPL and CC), so the Review Guidelines erroneously treat this is a minor issue.
Zbyszek _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@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/packaging@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Mar 22, 2021 at 12:10:50PM +0100, Vít Ondruch wrote:
Dne 22. 03. 21 v 10:49 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Mar 22, 2021 at 09:19:43AM +0100, Vít Ondruch wrote:
Dne 21. 03. 21 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a):
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:
- 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…
Just FTR, including license file as SOURCE have always been wrong suggestion, because the review guidelines [1] states the following:
My interpretation was based on the text in the Licensing Guidelines. I consider those to be authoritative over the Review Guidelines, which after all are and must be just a derived checklist of things specified elsewhere in the guidelines.
MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %license.[4]
The authoritative text is unequivocal:
[when the license text is required by the license] either "Include a copy of what they believe the license text is" or "Choose not to package that software for Fedora".
Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1].
And this is just SHOULD:
SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [28]
Again, the authoritative text says:
"Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager."
"It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code. but are still encouraged to point out this issue to upstream and encourage them to remedy it."
It does NOT say "MUST", but comes very close. Also by saying "NOT required [in the other case]", it implies that [in this case] it is.
Granted, the licensing guidelines you are referring to might be interpreted differently.
"might be"? I don't think there's much wiggle room.
My interpretation is that it is reasonably fine to include the package into Fedora even without license file, while the situation should be certainly clarified with upstream.
This is the issue we disagree on. My interpretation is that (in the case where the license requires the text to be distributed) this is not optional.
(We would certainly be violating that license if we were to distribute the code without the license text. In practice, the effect of this is small and it's trivial to rectify, but as a matter of principle, we want to obey the licenses. And the Licensing Guidelines seem to support this interpretation.)
If there is no wiggle room, then you can't start suggesting "just include the license file as another Source." You should start with "Please note that the guidelines also say that the packager MUST contact upstream and ask them to fix the issue [1]." followed by that the package is forbidden from Fedora as long as there is no license file included
This is what I wrote (just in a slightly different order)...
or "that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream,".
No, "or" is not appropriate here. The recommendation to "exhaust all attempts to work with upstream" is there because we don't want packagers to "guess" the license text and include something different than the upstream intended. But following that recommendation does not absolve the packager from the requirement to include the license text.
(In this particular case that started this discussion, there is no ambiguity about the license text, because upstream provided a working URL to the license text. Hence my recommendation to immediately include it.)
But I'll be glad, if the licensing guidelines as well as review guidelines are unambiguous and aligned.
Me too ;)
Zbyszek
packaging@lists.fedoraproject.org
-
Mamoru TASAKA -
Otto Urpelainen -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek