8158 2015-08-13 16:48:49 +0000 INCOMPATIBLE_LICENSES has unexpected results with GNU libraries 2022-10-14 18:25:39 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment unspecified x86 Multiple RESOLVED WORKSFORME https://bugzilla.yoctoproject.org/show_bug.cgi?id=8197 Medium+ normal 4.99 1 jku joe.slater bogdanx.a.voiculescu elizabeth.flanagan randy.macleod sgw --- --- Don't know oldest_to_newest 53098 0 jku 2015-08-13 16:48:49 +0000 This sort of license blacklist INCOMPATIBLE_LICENSES = "*GPLv3" seems to lead to very unexpected results when combined with the current standard licensing scheme for GNU software ("LGPLv3+ | GPLv2+"). As far as I can tell e.g. the "non-gpl3" autobuilder* seems to happily build gmp-6.0.0 which is "LGPLv3 | GPLv2". I couldn't figure out how the checker works yet but could it be that the license checker goes "oh, it's available as GPLv2 and that's not blacklisted"? Technically that is correct but it also means that now anything that links to gmp, and (by dependency) to nettle or gnutls has to be GPLv2 compatible... I'm going to guess that most users of INCOMPATIBLE_LICENSES were not planning that. If my logic above is correct then maybe the autobuilder should just explicitly blacklist the combo "GPLany | LGPLv3" if that's possible (and docs should have the same suggestion) since this is the common dangerous combination? CCing beth: ross ratted you out as a domain expert. *) https://autobuilder.yoctoproject.org/main/builders/nightly-non-gpl3/builds/437/steps/CheckForGPLv3/logs/stdio 53732 1 jku 2015-09-04 07:34:36 +0000 My test case gmp now has a non-lgpl3 version available in master but the non-gpl3 autobuilder still picks the "LGPLv3+ | GPLv2+" version. 54166 2 elizabeth.flanagan 2015-09-16 15:55:30 +0000 Fixed in autobuilder: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?id=05e209132bd9ab7fe91cfce6d77eebf4c54ea978 and http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?id=e7299636b173e1a5930f46d4566abe094dbfa7f2 Verified on yoctodev autobuilder cluster: [pokybuild@yct51 ~]$ cd yocto-autobuilder/yocto-worker/nightly-non-gpl3/ [pokybuild@yct51 nightly-non-gpl3]$ cd build/ [pokybuild@yct51 build]$ for x in `find ./build/tmp/deploy/licenses -name "license.manifest"`; do cat $x|grep -E "GPLv3|GPL-3"; done 54360 3 stanciux.mihail 2015-09-21 09:46:29 +0000 Verified. 54362 4 jku 2015-09-21 10:21:41 +0000 (In reply to comment #3) > Verified. Has it been verified that the build really does not include gmp-6.0.0? I haven't seen a "non-gpl3" build yet that didn't... The last one (from 16th) seems to not have the license warning anymore but gmp-6.0.0 is still getting built, which seems worse than before. 54368 5 stanciux.mihail 2015-09-21 11:47:06 +0000 (In reply to comment #4) > (In reply to comment #3) > > Verified. > > Has it been verified that the build really does not include gmp-6.0.0? I > haven't seen a "non-gpl3" build yet that didn't... The last one (from 16th) > seems to not have the license warning anymore but gmp-6.0.0 is still getting > built, which seems worse than before. Sorry, should have been more specific. Verified that the patch is in and it does check for GPLv3. We can't really check for more, as we don't have access to the AB infrastructure. 54384 6 stanciux.mihail 2015-09-21 14:17:38 +0000 Reopening. Tried a local build using a freshly downloaded AB(made sure the patches were included) and gmp is still being built and still being included in the resulting image. On the image i found libgmp.so.10.2.0 under /usr/lib, which I THINK is the library that should be skipped. Oddly enough it's not showing up in the package manifest or the license manifest, that's why the "check for gmp" step isn't signaling anything. 54521 7 elizabeth.flanagan 2015-09-23 12:15:31 +0000 pidge@buile ~/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/meta $ more recipes-support/gmp/gmp_6.0.0.bb require gmp.inc LICENSE="GPLv2+ | LGPLv3+" REVISION="a" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \ file://COPYING.LESSERv3;md5=6a6a8e020838b23406c81b19c1d46df6 \ file://COPYINGv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ " As gmp is either GPLv2+ or LGPLv3+ this is actually the correct behaviour: From the package.manifest we see that: PACKAGE NAME: gmp PACKAGE VERSION: 6.0.0 RECIPE NAME: gmp LICENSE: GPLv2+ So, it is picking the correct license here so it should be on the image. 54523 8 jku 2015-09-23 12:38:48 +0000 > As gmp is either GPLv2+ or LGPLv3+ this is actually the correct behaviour: Like I said in my original report: | Technically that is correct but it also means that now anything that | links to gmp, and (by dependency) to nettle or gnutls has to be GPLv2 | compatible... I'm going to guess that most users of | INCOMPATIBLE_LICENSES were not planning that. The people who are allergic to *GPL3 in general are not going to be fine with their libraries suddenly going GPL2 (not LGPL, GPL). Technically the build is 100% correct but I think it's currently testing a set of software that no-one is interested in. 54529 9 elizabeth.flanagan 2015-09-23 13:09:51 +0000 The problem here is that we're going to have to do quite a bit of interspection during the build to figure out who links what to what. We can't blacklist GPLv2+|LGPLv3. So we'll need to do things that really impact the build. I'm not sure if there is something here that we can actually do during the build. I'm going to bump this to 2.1 to give us time to consider it. 58839 10 elizabeth.flanagan 2016-02-10 17:18:57 +0000 I'm dropping this to a medium and moving this out to 2.2. Part of the issue here is that we're going to have to go through all of the RDEPENDS and check if those are compatible with the license on the other side of the |. I can see this getting a bit messy. 62111 11 elizabeth.flanagan 2016-05-11 18:31:46 +0000 I'm wondering if part of this isn't a use case for spdx.bbclass. Tracy, can we look at if this. 73642 12 joshuagloe 2017-06-02 11:52:25 +0000 The Intel RefKit team have developed some code to do license checking on generated images[1]. This is used to perform refkit specific license checks[2] but could easily be used to provide a selftest which sets INCOMPATIBLE_LICENSE and checks to see whether the generated image has any (L)GPLv3 components. 1. http://git.yoctoproject.org/clean/cgit.cgi/intel-iot-refkit/tree/meta-refkit-core/lib/licensecheck.py 2. http://git.yoctoproject.org/clean/cgit.cgi/intel-iot-refkit/tree/meta-iotqa/lib/oeqa/selftest/refkit-license-check.py 3. http://git.yoctoproject.org/clean/cgit.cgi/intel-iot-refkit/commit/?id=5620309e2b22835bc43329b380127dcf20ace535 74781 13 jku 2017-07-05 14:11:00 +0000 (In reply to comment #12) > The Intel RefKit team have developed some code to do license checking on > generated images[1]. This is used to perform refkit specific license > checks[2] but could easily be used to provide a selftest which sets > INCOMPATIBLE_LICENSE and checks to see whether the generated image has any > (L)GPLv3 components. I had a quick look here and I'm not sure I follow... I mean, yes it's probably possible to write a test like that but would it help? We already know the non-gpl3 build ends up with libraries with effective "LGPLv3|GPLv2" licenses. I still think the results of INCOPATIBLE_LICENSES is unexpected but I'm not sure if there's anything we can reasonably do that would really help, especially now that we've removed the obsolete lgplv2 versions (moved to meta-gplv2). I'll build a non-gpl3 image and do some tests. 75008 14 joshuagloe 2017-07-13 15:55:15 +0000 (In reply to comment #13) > (In reply to comment #12) > > The Intel RefKit team have developed some code to do license checking on > > generated images[1]. This is used to perform refkit specific license > > checks[2] but could easily be used to provide a selftest which sets > > INCOMPATIBLE_LICENSE and checks to see whether the generated image has any > > (L)GPLv3 components. > > I had a quick look here and I'm not sure I follow... I mean, yes it's > probably possible to write a test like that but would it help? We already > know the non-gpl3 build ends up with libraries with effective "LGPLv3|GPLv2" > licenses. Would it help? I'm not sure, I certainly defer to you here. Especially as you filed this bug. > I still think the results of INCOPATIBLE_LICENSES is unexpected but I'm not > sure if there's anything we can reasonably do that would really help, > especially now that we've removed the obsolete lgplv2 versions (moved to > meta-gplv2). Perhaps some warning laden documentation to point people at? Maybe we could even generate a warning when the option is set that would warn about the generated content requiring further review? > I'll build a non-gpl3 image and do some tests. Thanks 88334 15 randy.macleod 2020-10-08 08:31:11 +0000 Joe can you see if this is still a problem? 94184 16 randy.macleod 2022-10-14 18:25:39 +0000 I didn't check it myself but I asked Joe and he said that: Nothing with an incompatible license is put on the target. Also we have have several test for the license rules: $ git log --oneline -11 meta/lib/oeqa/selftest/cases/incompatible_lic.py ce08cf4825 lib: Add copyright statements to files without one a74792b15d selftest/runtime_test/incompatible_lic: Use IMAGE_CLASSES for testimage d01b1919dc selftest/incompatible_lic: Remove references to AVAILABLE_LICENSES 82f24d2197 license: Rework INCOMPATIBLE_LICENSE wildcard handling d6449581c9 base/license: Rework INCOMPATIBLE_LICENSE variable handling ebee9854d7 selftest: add core-image-weston to no-gpl3-no-meta-gpl2 image test from 2021, 2022. Re-open with details if there's still a problem.