[opensuse-packaging] How to proceed when upstream bundles prohibited sofware
Hi, As the subject says how do we proceed when there is problematic bundled library code in the upstream. darktable package has bundled squish library in the sources, and after discussing with the legal team it is best we follow the same route as fedora. https://bugzilla.redhat.com/show_bug.cgi?id=972604 In fedora guidelines the solution outlined can be found in the following link: https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohib... Since there is no suggestion in our guidelines, how do I proceed in this case, as implementing the removal of offending code is not the issue but AFAIK our buildservice has some checks for the source code from the Source URL Also does this removal of the code should be applied in the home project also, as I am providing nightly git builds as well in addition to the official package. Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
toganm@opensuse.org wrote:
As the subject says how do we proceed when there is problematic bundled library code in the upstream. darktable package has bundled squish library in the sources, and after discussing with the legal team it is best we follow the same route as fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=972604
In fedora guidelines the solution outlined can be found in the following link:
https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohib...
Since there is no suggestion in our guidelines, how do I proceed in this case, as implementing the removal of offending code is not the issue but AFAIK our buildservice has some checks for the source code from the Source URL
It might be sufficient to put an rm -r in the spec file and clearly document there that with this you are removing the offending code so there is absolutely no way for it to end up in the binary package. As additional safeguard you could also add some additional grepping on the binaries after make install and fail the build if the offending code somehow sneaked in nevertheless. With those measurements it might be acceptable for legal while still adhering to the pristine source principle. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
In article <51B857C9.5060808@suse.de>, Ludwig Nussel <ludwig.nussel@suse.de> writes:
Ludwig> It might be sufficient to put an rm -r in the spec file and Ludwig> clearly document there that with this you are removing the Ludwig> offending code so there is absolutely no way for it to end Ludwig> up in the binary package. As additional safeguard you could Ludwig> also add some additional grepping on the binaries after make Ludwig> install and fail the build if the offending code somehow Ludwig> sneaked in nevertheless. With those measurements it might be Ludwig> acceptable for legal while still adhering to the pristine Ludwig> source principle. This approach makes more sense, though I will get clarification from legal if they are happy with this approach. Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Mittwoch, 12. Juni 2013, 14:50:20 schrieb toganm@opensuse.org:
In article <51B857C9.5060808@suse.de>, Ludwig Nussel <ludwig.nussel@suse.de> writes: Ludwig> It might be sufficient to put an rm -r in the spec file and Ludwig> clearly document there that with this you are removing the Ludwig> offending code so there is absolutely no way for it to end Ludwig> up in the binary package. As additional safeguard you could Ludwig> also add some additional grepping on the binaries after make Ludwig> install and fail the build if the offending code somehow Ludwig> sneaked in nevertheless. With those measurements it might be Ludwig> acceptable for legal while still adhering to the pristine Ludwig> source principle.
This approach makes more sense, though I will get clarification from legal if they are happy with this approach.
sure, that approach is much better. However, I thought you speak about cases where even the source tar ball must not allow these files. In this case the src.rpm still contains the original source tar ball. But if that is acceptable (depends on your legal issue) it is definitive the best way. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
In article <13070722.1PDs8778KL@scherben.suse.de>, Adrian Schröter <adrian@suse.de> writes:
Adrian> Am Mittwoch, 12. Juni 2013, 14:50:20 schrieb Adrian> toganm@opensuse.org: >> >>>>> In article <51B857C9.5060808@suse.de>, Ludwig Nussel Adrian> <ludwig.nussel@suse.de> writes: Ludwig> It might be sufficient to put an rm -r in the spec file and Ludwig> clearly document there that with this you are removing the Ludwig> offending code so there is absolutely no way for it to end Ludwig> up in the binary package. As additional safeguard you could Ludwig> also add some additional grepping on the binaries after make Ludwig> install and fail the build if the offending code somehow Ludwig> sneaked in nevertheless. With those measurements it might be Ludwig> acceptable for legal while still adhering to the pristine Ludwig> source principle. >> This approach makes more sense, though I will get clarification >> from legal if they are happy with this approach. Adrian> sure, that approach is much better. Adrian> However, I thought you speak about cases where even the Adrian> source tar ball must not allow these files. In this case the Adrian> src.rpm still contains the original source tar ball. You are right that is the case since the code in question is patented. The bugzilla is https://bugzilla.novell.com/show_bug.cgi?id=824484 I do not know if you would be able to see it. Adrian> But if that is acceptable (depends on your legal issue) it Adrian> is definitive the best way. If it is OK by legal this is the way I would proceed, if not I'll let the list know and see how can I find a solution that makes everyone happy Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Mittwoch, 12. Juni 2013, 10:26:23 schrieb toganm@opensuse.org:
Hi,
As the subject says how do we proceed when there is problematic bundled library code in the upstream. darktable package has bundled squish library in the sources, and after discussing with the legal team it is best we follow the same route as fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=972604
In fedora guidelines the solution outlined can be found in the following link:
https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohib ited_Code
Since there is no suggestion in our guidelines, how do I proceed in this case, as implementing the removal of offending code is not the issue but AFAIK our buildservice has some checks for the source code from the Source URL
yes ... not widely used yet... What I dislike about the fedora approach is that a random script gets executed on the developer workstation. That means you have to review this script each time before running it if it does come from some random submission. I doubt everybody will do that, so you would even need to review the factory scripts each time :/ A better approach would be to have some generic tool which would parse some config file and removes for example the questioning files. Maybe with support of reg-exp's. But not with the possibility to inject code.
Also does this removal of the code should be applied in the home project also, as I am providing nightly git builds as well in addition to the official package.
Togan --
Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2013-06-12 10:26, toganm@opensuse.org wrote:
https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohib...
Since there is no suggestion in our guidelines, how do I proceed in this case, as implementing the removal of offending code is not the issue but AFAIK our buildservice has some checks for the source code from the Source URL
The Build Service does not do any checks in general. People may want to make you believe that in that they submit SRs that include lots of URLs, but by default, nothing pertaining to source is done. Only manual intervention in the form of a _service can influence that; the "download_files" service for example, because it always redownloads the full file (taking time, nerve, and a toll on people's download volumes), obviously requires that the remote URL not throw 404 or an other error. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Mittwoch, 12. Juni 2013, 14:02:20 schrieb Jan Engelhardt:
On Wednesday 2013-06-12 10:26, toganm@opensuse.org wrote:
https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohi bited_Code
Since there is no suggestion in our guidelines, how do I proceed in this case, as implementing the removal of offending code is not the issue but AFAIK our buildservice has some checks for the source code from the Source URL
The Build Service does not do any checks in general. People may want to make you believe that in that they submit SRs that include lots of URLs, but by default, nothing pertaining to source is done.
Only manual intervention in the form of a _service can influence that; the "download_files" service for example, because it always redownloads the full file
not when you have a configured cache.
(taking time, nerve, and a toll on people's download volumes), obviously requires that the remote URL not throw 404 or an other error. --
Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Adrian Schröter -
Jan Engelhardt -
Ludwig Nussel -
toganm＠opensuse.org