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


Alexander Kanavin
 

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


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


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


Alexander Kanavin
 

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@...> 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@...
> <mailto: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?
>
>     Thank you.
>
>     Best regards // John Ernberg
>     
>


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