Hi all, On Fri, May 31, 2019 at 11:31:43AM +0200, Quentin Schulz wrote: > Hi all, > > We're in the middle of an upgrade to Thud 2.6.2. While doing so, we > blindly updated all upstream layers we use and we found out (during > integration phase, no need to send lawyers :) ) that even though we have > GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built. > > conf/local.conf > INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+" > > https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb > LICENSE = "GFDL-1.3 & BSD & ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 | > The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | > The-Qt-Company-Commercial )" > > My understanding of the above LICENSE is that even though I have GPLv3 > blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the > package got built. I'm not really happy with Qt doing that (no warning, > no LICENSE_FLAGS). Quick question unrelated to the actual important > question: > > Would it be possible (theoritically, I know you've nothing to do with > maintenance of meta-qt5; also not tested, just "pseudo-code") to have > something like: > python() { > if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'): > d.setVar("LICENSE_FLAGS", "commercial") > } > > so if we are blacklisting GPLv3, we have to add commercial_qtbase to > LICENSE_FLAGS_WHITELIST to be able to build it. > > So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as > well and qtbase is still building. How so? > > For me, it results in the following: > LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 | > not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )" > which in the end looks like: > LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )" > which is basically: > LICENSE = "not-compat" > > Is there an error in this simplification? > Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto? > Have I missed something? > Is there something actually buggy in the INCOMPATIBLE_LICENSE > implementation? > > Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as > I wanted to exclude license "aliases" not being supported by > INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what > is said in the mega-manual). > > I want to be sure to not be able to build qt >= 5.7, we're never too far > from an unfortunate upgrade or people in the company not knowing we > cannot use qt >= 5.7. >
It's actually a bit worse than I expected. If I create a simple baz recipe with LICENSE = "FooLicense" and have INCOMPATIBLE_LICENSE = "FooLicense" in conf/local.conf, `bitbake baz` will NOT complain, and will be built. Now, my understanding is that INCOMPATIBLE_LICENSE is passed[1] as an argument to expand_wildcard_licenses[2] which returns a list of licenses which have to be part of either SPDXLICENSEMAP or SRC_DISTRIBUTE_LICENSES. However, in the case of qtbase, The-Qt-Company-Commercial is nowhere to be found in those variables. Why do we filter INCOMPATIBLE_LICENSE to have only SPDX licenses or their aliases (my understanding of respectively SRC_DISTRIBUTE_LICENSES and SPDXLICENSEMAP)? Is this actually expected? If it is, can we please actually document it? Also, how should one add a custom license? I could find this[3] discussion on the ML but nothing "official". Can we document it? I wouldn't know today what to do without having to read the source code and the licensing is critical to most companies. Let me know how and if I can help, Thanks, Quentin [1] https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/base.bbclass#n524 [2] https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/license.bbclass#n265 [3] https://lists.yoctoproject.org/pipermail/yocto/2013-June/014366.html -- StreamUnlimited Engineering GmbH High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria quentin.sch...@streamunlimited.com, www.streamunlimited.com -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
