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.

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

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

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

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
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,

StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria

Join to automatically receive all group messages.