Re: [yocto] Issue with INCOMPATIBLE_LICENSE

2019-06-06 Thread Quentin Schulz
FYI,

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

+ LICENSE_FLAGS = "${@ "commercial" if 
(incompatible_license_contains('GPL-3.0', True, False, d) or \
+ incompatible_license_contains('The-Qt-Company-GPL-Exception-1.0', 
True, False, d) or \
+ (incompatible_license_contains('GPL-2.0+', True, False, d) and \  
 
+  incompatible_license_contains('LGPL-3.0', True, False, d))) \
 
+  else ''}"

For qtbase_git.bb seems to work fine.

LICENSE is 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 
)
So it is commercial if
GPL-3.0 | The-Qt-Company-GPL-Exception-1.0 | (GPL-2.0+ & LGPL-3.0) is
False.

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

FYI, a patch was sent regarding this issue:
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283266.html

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


Re: [yocto] Issue with INCOMPATIBLE_LICENSE

2019-06-04 Thread Alexander Kanavin
On Tue, 4 Jun 2019 at 17:12, Quentin Schulz <
quentin.sch...@streamunlimited.com> wrote:

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

Sending patches is far more efficient than asking questions; generally,
everyone is busy with their own problems. If you see a deficiency, and have
a clear idea how to make it better, please do contribute improvements.

Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Issue with INCOMPATIBLE_LICENSE

2019-06-04 Thread 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.sch...@streamunlimited.com, www.streamunlimited.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Issue with INCOMPATIBLE_LICENSE

2019-05-31 Thread Quentin Schulz
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.

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