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

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

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

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