[yocto] Issue with INCOMPATIBLE_LICENSE

[Quentin Schulz]

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.schulz at streamunlimited.com, www.streamunlimited.com