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

["Mikko Rapeli" <mikko.rapeli@bmw.de>]

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