[opensuse-packaging] Bootstrapping legal-auto
Hi, As most of you will be painfully aware - our process for legal reviews is at its limits. This is nothing new, but meanwhile the situation is so bad, that a new package requires months to pass Factory review and this is just nothing I could stand watching. So I'm in the process of redefining the legal process and the tools used for it - and it will mean some changes for packages. Some for the better, but some for the worse. The legal-auto bot so far only checked one thing: does it know the package name with the same license. If not, it would redirect the review to legal-team, which was overwhelmed by the stupid bot. So what we needed was a more clever bot. So this is what we're working on - but it will not happen in days. The problem deserves too much care to rush it. But we will introduce new features step by step - and it will mean for now that reviews of legal-auto will stay open longer than what you are used to. And we also check different things as legal-auto actually checks the licenses itself and no longer redirects blindly. One of the consequences is that we now check something automatically that was checked only manually so far: if sub-packages have sub-licenses. Take ant-antlr.spec - its source rpm has License: Apache-2.0, but it has a ant-javamail sub-package with CDDL-1.0. So the bot will not accept this package, because the sub-package has a license not part of the sources license. The proper fix is to have License: Apache-2.0 AND CDDL-1.0 Right now we're not declining requests - but we will shortly. So don't be surprised! I hope to have good news too soonish ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday, 15 February 2017 13:29 Stephan Kulow wrote:
Take ant-antlr.spec - its source rpm has License: Apache-2.0, but it has a ant-javamail sub-package with CDDL-1.0. So the bot will not accept this package, because the sub-package has a license not part of the sources license.
The proper fix is to have License: Apache-2.0 AND CDDL-1.0
Wouldn't that cause this to be propagated to _all_ subpackages (including the main binary one) unless each of them (except the CDDL one) has its own "License: Apache-2.0"? Michal Kubecek -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 15.02.2017 13:39, Michal Kubecek wrote:
On Wednesday, 15 February 2017 13:29 Stephan Kulow wrote:
Take ant-antlr.spec - its source rpm has License: Apache-2.0, but it has a ant-javamail sub-package with CDDL-1.0. So the bot will not accept this package, because the sub-package has a license not part of the sources license.
The proper fix is to have License: Apache-2.0 AND CDDL-1.0
Wouldn't that cause this to be propagated to _all_ subpackages (including the main binary one) unless each of them (except the CDDL one) has its own "License: Apache-2.0"?
Yes. And so the spec-cleaner will multipy the main license into all subpackages if they don't already have one - and you should correct it if it's *not* the combination. If your licenses are so complicated, you better don't build a main package - as rpm has to my knowledge no way to express different licenses between the main rpm and the source rpm. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 15 Feb 2017, Stephan Kulow wrote:
On 15.02.2017 13:39, Michal Kubecek wrote:
On Wednesday, 15 February 2017 13:29 Stephan Kulow wrote:
Take ant-antlr.spec - its source rpm has License: Apache-2.0, but it has a ant-javamail sub-package with CDDL-1.0. So the bot will not accept this package, because the sub-package has a license not part of the sources license.
The proper fix is to have License: Apache-2.0 AND CDDL-1.0
Wouldn't that cause this to be propagated to _all_ subpackages (including the main binary one) unless each of them (except the CDDL one) has its own "License: Apache-2.0"?
Yes. And so the spec-cleaner will multipy the main license into all subpackages if they don't already have one - and you should correct it if it's *not* the combination.
If your licenses are so complicated, you better don't build a main package - as rpm has to my knowledge no way to express different licenses between the main rpm and the source rpm.
grep 'Name:\|%package\|License' gcc6.spec Name: gcc6 License: GPL-3.0+ %package -n gcc6-32bit License: GPL-3.0+ %package -n gcc6-64bit License: GPL-3.0+ %package devel License: GPL-3.0+ %package locale License: GPL-3.0+ %package c++ License: GPL-3.0+ %package c++-32bit License: GPL-3.0+ %package c++-64bit License: GPL-3.0+ %package -n libstdc++%{libstdcxx_sover}-devel%{libdevel_suffix} License: GPL-3.0-with-GCC-exception %package -n libstdc++%{libstdcxx_sover}-devel%{libdevel_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libstdc++%{libstdcxx_sover}-devel%{libdevel_suffix}-64bit License: GPL-3.0-with-GCC-exception %package -n libgcc_s%{libgcc_s}%{libgcc_s_suffix} License: GPL-3.0-with-GCC-exception %package -n libgcc_s%{libgcc_s}%{libgcc_s_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libgcc_s%{libgcc_s}%{libgcc_s_suffix}-64bit License: GPL-3.0-with-GCC-exception %package -n libgomp%{libgomp_sover}%{libgomp_suffix} License: GPL-3.0-with-GCC-exception %package -n libgomp%{libgomp_sover}%{libgomp_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libgomp%{libgomp_sover}%{libgomp_suffix}-64bit License: GPL-3.0-with-GCC-exception %package -n libstdc++%{libstdcxx_sover}%{libstdcxx_suffix} License: GPL-3.0-with-GCC-exception %package -n libstdc++%{libstdcxx_sover}%{libstdcxx_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libstdc++%{libstdcxx_sover}%{libstdcxx_suffix}-64bit License: GPL-3.0-with-GCC-exception %package -n libstdc++%{libstdcxx_sover}%{libstdcxx_suffix}-locale License: GPL-3.0-with-GCC-exception %package info License: GFDL-1.2 %package objc License: GPL-3.0+ %package objc-32bit License: GPL-3.0+ %package objc-64bit License: GPL-3.0+ %package -n libobjc%{libobjc_sover}%{libobjc_suffix} License: GPL-3.0-with-GCC-exception %package -n libobjc%{libobjc_sover}%{libobjc_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libobjc%{libobjc_sover}%{libobjc_suffix}-64bit License: GPL-3.0-with-GCC-exception %package obj-c++ License: GPL-3.0+ %package obj-c++-32bit License: GPL-3.0+ %package obj-c++-64bit License: GPL-3.0+ %package -n cpp6 License: GPL-3.0+ %package ada License: GPL-3.0+ %package ada-32bit License: GPL-3.0+ %package ada-64bit License: GPL-3.0+ %package -n libada6 License: GPL-3.0-with-GCC-exception %package -n libada6-32bit License: GPL-3.0-with-GCC-exception %package -n libada6-64bit License: GPL-3.0-with-GCC-exception %package fortran License: GPL-3.0+ %package fortran-32bit License: GPL-3.0+ %package fortran-64bit License: GPL-3.0+ %package -n libgfortran%{libgfortran_sover}%{libgfortran_suffix} License: GPL-3.0-with-GCC-exception %package -n libgfortran%{libgfortran_sover}%{libgfortran_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libgfortran%{libgfortran_sover}%{libgfortran_suffix}-64bit License: GPL-3.0-with-GCC-exception %package -n libquadmath%{libquadmath_sover}%{libquadmath_suffix} License: LGPL-2.1 %package -n libquadmath%{libquadmath_sover}%{libquadmath_suffix}-32bit License: LGPL-2.1 %package -n libquadmath%{libquadmath_sover}%{libquadmath_suffix}-64bit License: LGPL-2.1 %package -n libitm%{libitm_sover}%{libitm_suffix} License: MIT %package -n libitm%{libitm_sover}%{libitm_suffix}-32bit License: MIT %package -n libitm%{libitm_sover}%{libitm_suffix}-64bit License: MIT %package -n libasan%{libasan_sover}%{libasan_suffix} License: MIT %package -n libasan%{libasan_sover}%{libasan_suffix}-32bit License: MIT %package -n libasan%{libasan_sover}%{libasan_suffix}-64bit License: MIT %package -n libtsan%{libtsan_sover}%{libtsan_suffix} License: MIT %package -n libtsan%{libtsan_sover}%{libtsan_suffix}-32bit License: MIT %package -n libtsan%{libtsan_sover}%{libtsan_suffix}-64bit License: MIT %package -n libatomic%{libatomic_sover}%{libatomic_suffix} License: GPL-3.0-with-GCC-exception %package -n libatomic%{libatomic_sover}%{libatomic_suffix}-32bit License: GPL-3.0-with-GCC-exception %package -n libatomic%{libatomic_sover}%{libatomic_suffix}-64bit License: GPL-3.0-with-GCC-exception %package -n libcilkrts%{libcilkrts_sover}%{libcilkrts_suffix} License: MIT %package -n libcilkrts%{libcilkrts_sover}%{libcilkrts_suffix}-32bit License: MIT %package -n libcilkrts%{libcilkrts_sover}%{libcilkrts_suffix}-64bit License: MIT %package -n liblsan%{liblsan_sover}%{liblsan_suffix} License: MIT %package -n liblsan%{liblsan_sover}%{liblsan_suffix}-32bit License: MIT %package -n liblsan%{liblsan_sover}%{liblsan_suffix}-64bit License: MIT %package -n libubsan%{libubsan_sover}%{libubsan_suffix} License: MIT %package -n libubsan%{libubsan_sover}%{libubsan_suffix}-32bit License: MIT %package -n libubsan%{libubsan_sover}%{libubsan_suffix}-64bit License: MIT %package -n libvtv%{libvtv_sover}%{libvtv_suffix} License: MIT %package -n libvtv%{libvtv_sover}%{libvtv_suffix}-32bit License: MIT %package -n libvtv%{libvtv_sover}%{libvtv_suffix}-64bit License: MIT %package -n libmpx%{libmpx_sover}%{libmpx_suffix} License: BSD-3-Clause %package -n libmpx%{libmpx_sover}%{libmpx_suffix}-32bit License: BSD-3-Clause %package -n libmpx%{libmpx_sover}%{libmpx_suffix}-64bit License: BSD-3-Clause %package -n libmpxwrappers%{libmpxwrappers_sover}%{libmpxwrappers_suffix} License: BSD-3-Clause %package -n
Ick. For example take gcc6: libmpxwrappers%{libmpxwrappers_sover}%{libmpxwrappers_suffix}-32bit License: BSD-3-Clause %package -n libmpxwrappers%{libmpxwrappers_sover}%{libmpxwrappers_suffix}-64bit License: BSD-3-Clause %package -n libgcj%{libdevel_suffix} License: GPL-2.0-with-classpath-exception %package -n gcc6-java License: GPL-3.0+ %package -n libgcj_bc%{libgcj_bc_sover}%{libgcj_bc_suffix} License: GPL-2.0-with-classpath-exception %package -n libgcj-jar%{libdevel_suffix} License: GPL-2.0-with-classpath-exception %package -n libgcj-devel%{libdevel_suffix} License: GPL-2.0-with-classpath-exception %package -n gcc6-gij License: GPL-2.0-with-classpath-exception %package -n libstdc++%{libstdcxx_sover}%{libdevel_suffix}-doc License: GPL-3.0+ %package -n libffi%{libffi_sover}%{libffi_suffix} License: BSD-3-Clause %package -n libffi%{libffi_sover}%{libffi_suffix}-32bit License: BSD-3-Clause %package -n libffi%{libffi_sover}%{libffi_suffix}-64bit License: BSD-3-Clause %package -n libffi-devel%{libdevel_suffix} License: BSD-3-Clause %package -n libffi-devel%{libdevel_suffix}-32bit License: BSD-3-Clause %package -n libffi-devel%{libdevel_suffix}-64bit License: BSD-3-Clause %package go License: GPL-3.0+ %package go-32bit License: GPL-3.0+ %package go-64bit License: GPL-3.0+ %package -n libgo%{libgo_sover}%{libgo_suffix} License: BSD-3-Clause %package -n libgo%{libgo_sover}%{libgo_suffix}-32bit License: BSD-3-Clause %package -n libgo%{libgo_sover}%{libgo_suffix}-64bit License: BSD-3-Clause %package -n gcc6-testresults License: SUSE-Public-Domain that will be "fun" to fix. gcc6 is also a "real" package and we have multiple .spec files (gcc6-testresults is a source package as well as a real package). But given gcc6 License (GPL-3.0+) is compatible with all the other licenses why bother? Currently it works just fine (all licenses of all subpackages are correct), but indeed the source package license is GPL-3.0+ only. But rather than trying to fix the .spec file why not (f***) fix RPM to put all licenses into the SPM license field?! It's clearly a RPM bug (IMHO). Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 15 Feb 2017, Stephan Kulow wrote:
But given gcc6 License (GPL-3.0+) is compatible with all the other licenses why bother? Let me ask the other way around: why did you bother to put licenses in
On 16.02.2017 10:44, Richard Biener wrote: the subpackages if it doesn't matter? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 16 Feb 2017, Stephan Kulow wrote:
On Wed, 15 Feb 2017, Stephan Kulow wrote:
But given gcc6 License (GPL-3.0+) is compatible with all the other licenses why bother? Let me ask the other way around: why did you bother to put licenses in
On 16.02.2017 10:44, Richard Biener wrote: the subpackages if it doesn't matter?
Because compatibility is only one way (GPL-3.0+ covers all). For runtime libs a program links against the actual license of the runtime is important, and for example libgcc_s1 is _not_ viral GPL-3.0+ but GPL-3.0+ plus runtime exception. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2017-02-15 13:29, Stephan Kulow wrote:
As most of you will be painfully aware - our process for legal reviews is at its limits. But we will introduce new features step by step -
What other features beside subpackage checking are on your mind? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 15.02.2017 14:48, Jan Engelhardt wrote:
On Wednesday 2017-02-15 13:29, Stephan Kulow wrote:
As most of you will be painfully aware - our process for legal reviews is at its limits. But we will introduce new features step by step -
What other features beside subpackage checking are on your mind?
Good you ask! I didn't want my mail to become too long, so I left out the master plan ;) But the main feature is to pass packages with detectable open source licenses quicker and only with delayed human interaction. For this we move the actual review process out of OBS into an app of its own (that is unfortunately required to be internal) and mirror informations using the (new) legal-auto bot. An side effect of this is that we will detect licensing problems also in updates - and not just in new packages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Stephan, the most common source of failed legal reviews I have encountered in my packaging efforts so far are cases where upstream declares the package's license to be X in some meta data, but when you actually look at the distributed LICENSE file or the headers of the code, then it turns out the license is in fact Y. I suppose many people just don't know how to distinguish between BSD2, BSD3, and MIT licenses, and then they put misleading information into their package descriptions. It would be great of a tool could detect those cases, i.e. by scanning all distributed files for well-known license texts in order to *guess* a SPDX identifier. Now, whenever that guess is different from the one declared in the spec file, that should raise a red flag (maybe in the form of a comment on the submit request). It would be particularly nice to have such a tool were available for packagers to run locally before they even submit the request. Best regards, Peter -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 16.02.2017 11:23, Peter Simons wrote:
Hi Stephan,
the most common source of failed legal reviews I have encountered in my packaging efforts so far are cases where upstream declares the package's license to be X in some meta data, but when you actually look at the distributed LICENSE file or the headers of the code, then it turns out the license is in fact Y. I suppose many people just don't know how to distinguish between BSD2, BSD3, and MIT licenses, and then they put misleading information into their package descriptions.
It would be great of a tool could detect those cases, i.e. by scanning all distributed files for well-known license texts in order to *guess* a SPDX identifier. Now, whenever that guess is different from the one declared in the spec file, that should raise a red flag (maybe in the form of a comment on the submit request). It would be particularly nice to have such a tool were available for packagers to run locally before they even submit the request.
Yeah, it's really strange to me that this area of FOSS didn't drive any combined effort of distributions. Last time I attended FOSDEM, the legal room was full of sad stories :) Debian has a huge bunch of tools you might want to try: https://wiki.debian.org/CopyrightReviewTools Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 2017-02-16 at 11:23 +0100, Peter Simons wrote:
It would be great of a tool could detect those cases, i.e. by scanning all distributed files for well-known license texts in order to *guess* a SPDX identifier. Now, whenever that guess is different from the one declared in the spec file, that should raise a red flag (maybe in the form of a comment on the submit request). It would be particularly nice to have such a tool were available for packagers to run locally before they even submit the request.
I generally use 'licensecheck' (from the 'devscripts' package) to help me get someinformation of what I might all find.. this has worked out reasonably well for me so far. Cheers Dominique
On Wed, Feb 15, 2017 at 7:29 AM, Stephan Kulow <coolo@suse.de> wrote:
The proper fix is to have License: Apache-2.0 AND CDDL-1.0
Now would be a good time to enforce that AND with automation in spec-cleaner at a minimum. I added a second license to a package a couple days ago and left out the AND. I ran it through spec-cleaner to male sure I had the syntax right. No complaints, then this morning I got what looks like a manual decline of my SR due to the missing AND. A waste of energy for all. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (7)
-
Dominique Leuenberger / DimStar -
Greg Freemyer -
Jan Engelhardt -
Michal Kubecek -
Peter Simons -
Richard Biener -
Stephan Kulow