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

["Khem Raj" <raj.khem@gmail.com>]

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