INCOMPATIBLE_LICENSE - how to use it properly?

INCOMPATIBLE_LICENSE - how to use it properly?

[John Ernberg]

Hi,

I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable 
licenses for us from our images. I started simple and picked the 
examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).

Currently we're based on Warrior, but I also did a short test on master 
(results later in the message)

Our images use systemd as init system. We use busybox ash as shell on 
these images for now.

When setting the INCOMPATIBLE_LICENSE according to the manual example, 
systemd cannot be built anymore because bash is being skipped due to 
license.

Turns out that because systemd-bash-completion and 
systemd-kernel-install both rdepend on bash, we can't build systemd at 
all, because bash is not buildable. Even if we're not installing those 
features of systemd.

A dive into TaskData suggests that all the rdepends of all packages 
provided by a recipe are flattened into depends of the recipe when 
testing buildability.

A quick test on master from about 2 weeks ago show the same behavior.

For the test on master all I did was change the DISTRO_FEATURES of 
core-image-minimal to include systemd.


Am I using ICOMPATIBLE_LICENSE properly so far?
If so, is being unable to fulfill an rdepend for an unused package meant 
to fail the whole build, and how can I avoid it short of including 
meta-gplv2 or writing lots of .bbappends to remove the dependencies?
Otherwise, where did I go wrong, and what should I be trying instead?

Thank you.

Best regards // John Ernberg

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

On master, you can set INCOMPATIBLE_LICENSE in the image recipe, rather
than globally, then the check would only be performed on items that
actually go into that image.

Warrior does not have that feature yet, I think, so your only option there
is meta-gpl2.

Alex

On Tue, 30 Jun 2020 at 11:34, John Ernberg <john.ernberg@actia.se> wrote:

> Hi,
>
> I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable
> licenses for us from our images. I started simple and picked the
> examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).
>
> Currently we're based on Warrior, but I also did a short test on master
> (results later in the message)
>
> Our images use systemd as init system. We use busybox ash as shell on
> these images for now.
>
> When setting the INCOMPATIBLE_LICENSE according to the manual example,
> systemd cannot be built anymore because bash is being skipped due to
> license.
>
> Turns out that because systemd-bash-completion and
> systemd-kernel-install both rdepend on bash, we can't build systemd at
> all, because bash is not buildable. Even if we're not installing those
> features of systemd.
>
> A dive into TaskData suggests that all the rdepends of all packages
> provided by a recipe are flattened into depends of the recipe when
> testing buildability.
>
> A quick test on master from about 2 weeks ago show the same behavior.
>
> For the test on master all I did was change the DISTRO_FEATURES of
> core-image-minimal to include systemd.
>
>
> Am I using ICOMPATIBLE_LICENSE properly so far?
> If so, is being unable to fulfill an rdepend for an unused package meant
> to fail the whole build, and how can I avoid it short of including
> meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> Otherwise, where did I go wrong, and what should I be trying instead?
>
> Thank you.
>
> Best regards // John Ernberg
> 
>

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

[John Ernberg]

Hi Alex,

I will give this a try on master.

One question though, will this still catch build-only libraries? (i.e. a 
library that consists only of headers). I don't think we have such 
recipes right now, it's more to understand how this feature works.

Thank you.

Best regards // John Ernberg

On 6/30/20 11:55 AM, Alexander Kanavin wrote:
> On master, you can set INCOMPATIBLE_LICENSE in the image recipe, rather 
> than globally, then the check would only be performed on items that 
> actually go into that image.
> 
> Warrior does not have that feature yet, I think, so your only option 
> there is meta-gpl2.
> 
> Alex
> 
> On Tue, 30 Jun 2020 at 11:34, John Ernberg <john.ernberg@actia.se 
> <mailto:john.ernberg@actia.se>> wrote:
> 
>     Hi,
> 
>     I have been trying to use INCOMPATIBLE_LICENSE to filter out
>     undesirable
>     licenses for us from our images. I started simple and picked the
>     examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).
> 
>     Currently we're based on Warrior, but I also did a short test on master
>     (results later in the message)
> 
>     Our images use systemd as init system. We use busybox ash as shell on
>     these images for now.
> 
>     When setting the INCOMPATIBLE_LICENSE according to the manual example,
>     systemd cannot be built anymore because bash is being skipped due to
>     license.
> 
>     Turns out that because systemd-bash-completion and
>     systemd-kernel-install both rdepend on bash, we can't build systemd at
>     all, because bash is not buildable. Even if we're not installing those
>     features of systemd.
> 
>     A dive into TaskData suggests that all the rdepends of all packages
>     provided by a recipe are flattened into depends of the recipe when
>     testing buildability.
> 
>     A quick test on master from about 2 weeks ago show the same behavior.
> 
>     For the test on master all I did was change the DISTRO_FEATURES of
>     core-image-minimal to include systemd.
> 
> 
>     Am I using ICOMPATIBLE_LICENSE properly so far?
>     If so, is being unable to fulfill an rdepend for an unused package
>     meant
>     to fail the whole build, and how can I avoid it short of including
>     meta-gplv2 or writing lots of .bbappends to remove the dependencies?
>     Otherwise, where did I go wrong, and what should I be trying instead?
> 
>     Thank you.
> 
>     Best regards // John Ernberg
>     
> 

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

[Mikko Rapeli]

Hi,

On Tue, Jun 30, 2020 at 09:34:39AM +0000, John Ernberg wrote:
> Hi,
> 
> I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable 
> licenses for us from our images. I started simple and picked the 
> examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).
> 
> Currently we're based on Warrior, but I also did a short test on master 
> (results later in the message)
> 
> Our images use systemd as init system. We use busybox ash as shell on 
> these images for now.
> 
> When setting the INCOMPATIBLE_LICENSE according to the manual example, 
> systemd cannot be built anymore because bash is being skipped due to 
> license.
> 
> Turns out that because systemd-bash-completion and 
> systemd-kernel-install both rdepend on bash, we can't build systemd at 
> all, because bash is not buildable. Even if we're not installing those 
> features of systemd.
> 
> A dive into TaskData suggests that all the rdepends of all packages 
> provided by a recipe are flattened into depends of the recipe when 
> testing buildability.
> 
> A quick test on master from about 2 weeks ago show the same behavior.
> 
> For the test on master all I did was change the DISTRO_FEATURES of 
> core-image-minimal to include systemd.
> 
> 
> Am I using ICOMPATIBLE_LICENSE properly so far?
> If so, is being unable to fulfill an rdepend for an unused package meant 
> to fail the whole build, and how can I avoid it short of including 
> meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> Otherwise, where did I go wrong, and what should I be trying instead?

You need to add exceptions to build a lot GPLv3 components but not let them
be part of product images.

In distro config:

INCOMPATIBLE_LICENSE += "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
...
WHITELIST_GPL-3.0 += "bash"
PACKAGE_EXCLUDE += "bash-ptest bash-dbg bash-staticdev bash-dev bash-doc bash-locale bashbug bash"
...

The PACKAGE_EXCLUDE must be complete list of binary packages produced by the recipe.

I end up enabling a large set of GPLv3 tools for use as development tooling at build
time or in SDK:

$ grep WHITELIST_ distro.conf
WHITELIST_GPL-3.0 += "autoconf"
WHITELIST_GPL-3.0 += "bash"
WHITELIST_GPL-3.0 += "bc"
WHITELIST_GPL-3.0 += "binutils"
WHITELIST_GPL-3.0 += "bison"
WHITELIST_GPL-3.0 += "ccache"
WHITELIST_GPL-3.0 += "coreutils"
WHITELIST_GPL-3.0 += "diffutils"
WHITELIST_GPL-3.0 += "elfutils"
WHITELIST_GPL-3.0 += "findutils"
WHITELIST_GPL-3.0 += "gawk"
WHITELIST_GPL-3.0 += "gdb"
WHITELIST_GPL-3.0 += "gdbm"
WHITELIST_GPL-3.0 += "gettext"
WHITELIST_GPL-3.0 += "gnutls"
WHITELIST_GPL-3.0 += "grep"
WHITELIST_GPL-3.0 += "libevent"
WHITELIST_GPL-3.0 += "libpipeline"
WHITELIST_GPL-3.0 += "libunistring"
WHITELIST_GPL-3.0 += "m4"
WHITELIST_GPL-3.0 += "make"
WHITELIST_GPL-3.0 += "readline"
WHITELIST_GPL-3.0 += "rsync"
WHITELIST_GPL-3.0 += "sed"
WHITELIST_GPL-3.0 += "which"

If one does not do this, alternative is to use a bunch of old and deprecated tool
versions from meta-gplv2.

Hope this helps,

-Mikko

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

It goes over a list of packages installed into their image, and checks
their licensing. If something was directly built into something else, it
will not produce a separate package, and therefore you need to handle that
separately: perhaps by setting the package license appropriately in
respective recipes (they needs to carry the licenses of items coming
directly as headers from other recipes).

Alex

On Tue, 30 Jun 2020 at 12:01, John Ernberg <john.ernberg@actia.se> wrote:

> Hi Alex,
>
> I will give this a try on master.
>
> One question though, will this still catch build-only libraries? (i.e. a
> library that consists only of headers). I don't think we have such
> recipes right now, it's more to understand how this feature works.
>
> Thank you.
>
> Best regards // John Ernberg
>
> On 6/30/20 11:55 AM, Alexander Kanavin wrote:
> > On master, you can set INCOMPATIBLE_LICENSE in the image recipe, rather
> > than globally, then the check would only be performed on items that
> > actually go into that image.
> >
> > Warrior does not have that feature yet, I think, so your only option
> > there is meta-gpl2.
> >
> > Alex
> >
> > On Tue, 30 Jun 2020 at 11:34, John Ernberg <john.ernberg@actia.se
> > <mailto:john.ernberg@actia.se>> wrote:
> >
> >     Hi,
> >
> >     I have been trying to use INCOMPATIBLE_LICENSE to filter out
> >     undesirable
> >     licenses for us from our images. I started simple and picked the
> >     examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).
> >
> >     Currently we're based on Warrior, but I also did a short test on
> master
> >     (results later in the message)
> >
> >     Our images use systemd as init system. We use busybox ash as shell on
> >     these images for now.
> >
> >     When setting the INCOMPATIBLE_LICENSE according to the manual
> example,
> >     systemd cannot be built anymore because bash is being skipped due to
> >     license.
> >
> >     Turns out that because systemd-bash-completion and
> >     systemd-kernel-install both rdepend on bash, we can't build systemd
> at
> >     all, because bash is not buildable. Even if we're not installing
> those
> >     features of systemd.
> >
> >     A dive into TaskData suggests that all the rdepends of all packages
> >     provided by a recipe are flattened into depends of the recipe when
> >     testing buildability.
> >
> >     A quick test on master from about 2 weeks ago show the same behavior.
> >
> >     For the test on master all I did was change the DISTRO_FEATURES of
> >     core-image-minimal to include systemd.
> >
> >
> >     Am I using ICOMPATIBLE_LICENSE properly so far?
> >     If so, is being unable to fulfill an rdepend for an unused package
> >     meant
> >     to fail the whole build, and how can I avoid it short of including
> >     meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> >     Otherwise, where did I go wrong, and what should I be trying instead?
> >
> >     Thank you.
> >
> >     Best regards // John Ernberg
> >     
> >
>

[-- Attachment #2: Type: text/html, Size: 3983 bytes --]

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

[Khem Raj]

On 6/30/20 3:07 AM, Mikko Rapeli wrote:
> Hi,
> 
> On Tue, Jun 30, 2020 at 09:34:39AM +0000, John Ernberg wrote:
>> Hi,
>>
>> I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable
>> licenses for us from our images. I started simple and picked the
>> examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).
>>
>> Currently we're based on Warrior, but I also did a short test on master
>> (results later in the message)
>>
>> Our images use systemd as init system. We use busybox ash as shell on
>> these images for now.
>>
>> When setting the INCOMPATIBLE_LICENSE according to the manual example,
>> systemd cannot be built anymore because bash is being skipped due to
>> license.
>>
>> Turns out that because systemd-bash-completion and
>> systemd-kernel-install both rdepend on bash, we can't build systemd at
>> all, because bash is not buildable. Even if we're not installing those
>> features of systemd.
>>
>> A dive into TaskData suggests that all the rdepends of all packages
>> provided by a recipe are flattened into depends of the recipe when
>> testing buildability.
>>
>> A quick test on master from about 2 weeks ago show the same behavior.
>>
>> For the test on master all I did was change the DISTRO_FEATURES of
>> core-image-minimal to include systemd.
>>
>>
>> Am I using ICOMPATIBLE_LICENSE properly so far?
>> If so, is being unable to fulfill an rdepend for an unused package meant
>> to fail the whole build, and how can I avoid it short of including
>> meta-gplv2 or writing lots of .bbappends to remove the dependencies?
>> Otherwise, where did I go wrong, and what should I be trying instead?
> 
> You need to add exceptions to build a lot GPLv3 components but not let them
> be part of product images.
> 
> In distro config:
> 
> INCOMPATIBLE_LICENSE += "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
> ...
> WHITELIST_GPL-3.0 += "bash"
> PACKAGE_EXCLUDE += "bash-ptest bash-dbg bash-staticdev bash-dev bash-doc bash-locale bashbug bash"
> ...
> 
> The PACKAGE_EXCLUDE must be complete list of binary packages produced by the recipe.
> 


I think having two different distro configs is a reliable approach here, 
we keep adding more refined packaging which means you have to be on your 
toes all the time in the allowed list above.

> I end up enabling a large set of GPLv3 tools for use as development tooling at build
> time or in SDK:
> 
> $ grep WHITELIST_ distro.conf
> WHITELIST_GPL-3.0 += "autoconf"
> WHITELIST_GPL-3.0 += "bash"
> WHITELIST_GPL-3.0 += "bc"
> WHITELIST_GPL-3.0 += "binutils"
> WHITELIST_GPL-3.0 += "bison"
> WHITELIST_GPL-3.0 += "ccache"
> WHITELIST_GPL-3.0 += "coreutils"
> WHITELIST_GPL-3.0 += "diffutils"
> WHITELIST_GPL-3.0 += "elfutils"
> WHITELIST_GPL-3.0 += "findutils"
> WHITELIST_GPL-3.0 += "gawk"
> WHITELIST_GPL-3.0 += "gdb"
> WHITELIST_GPL-3.0 += "gdbm"
> WHITELIST_GPL-3.0 += "gettext"
> WHITELIST_GPL-3.0 += "gnutls"
> WHITELIST_GPL-3.0 += "grep"
> WHITELIST_GPL-3.0 += "libevent"
> WHITELIST_GPL-3.0 += "libpipeline"
> WHITELIST_GPL-3.0 += "libunistring"
> WHITELIST_GPL-3.0 += "m4"
> WHITELIST_GPL-3.0 += "make"
> WHITELIST_GPL-3.0 += "readline"
> WHITELIST_GPL-3.0 += "rsync"
> WHITELIST_GPL-3.0 += "sed"
> WHITELIST_GPL-3.0 += "which"
> 
> If one does not do this, alternative is to use a bunch of old and deprecated tool
> versions from meta-gplv2.
> 
> Hope this helps,
> 
> -Mikko
> 
> 
> 
>