-----Original Message-----
From: openembedded-devel@... <openembedded-
devel@...> On Behalf Of Jon Mason
Sent: den 24 januari 2022 17:18
To: yocto@...; Patches and discussions about the oe-
core layer <openembedded-core@...>; OpenEmbedded Devel
List <openembedded-devel@...>
Subject: [oe] Inclusive Language Proposal for YP/OE

[cut]

For license handling, we’d use the opportunity to clean up the
WHITELIST_(ANY LICENSE) syntax and replace it with a
INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of
recipes which are of a blocked the INCOMPATIBLE_LICENSE list.

I am not so sure about this name. Not only is it extremely long,
but at least I would like to revise the entire system of how
licenses are handled. The major reason for this is that our
legal department requires us to have a list of allowed licenses
rather than a list of disallowed licenses. Thus we have a
COMPATIBLE_LICENSES variable. We then set INCOMPATIBLE_LICENSE
to AVAILABLE_LICENSES - COMPATIBLE_LICENSES. However, after the
introduction of all official SPDX licenses into OE-Core a while
ago this became problematic as the current implementation will
go through all licenses specified in INCOMPATIBLE_LICENSE many,
many times during recipe parsing, which caused the time to parse
all recipes to increase three times for us. Thus I would like to
implement proper support for COMPATIBLE_LICENSES in addition to
the INCOMPATIABLE_LICENSE variable to allow choosing the option
that suits the situation best.

However, in either case there would still need to be a way to
specify exceptions to the incompatible licenses, which is why I
would prefer that the name is not locked to the
INCOMPATIBLE_LICENSE variable. Here are a couple of alternatives:

* LICENSE_EXCEPTIONS
* ALLOWED_RECIPES
* LICENSE_ALLOWED_RECIPES

It is also that the WHITELIST variables have two use cases today,
one is to allow a _recipe_ to be built and the other is to allow
a _package_ to be added to an image even if it has an incompatible
license. The first use case can just as easily be achieved by
setting INCOMPATIBLE_LICENSE:pn-foo = "" for a recipe foo that
shall be allowed to be built even if it has an incompatible
license. With this in mind, maybe the variable should actually be
an image variable and specify a list of allowed packages instead,
e.g., IMAGE_ALLOWED_PACKAGES. Whether the variable with a list of
allowed recipes is then still needed or if it is enough to
manipulate INCOMPATIBLE_LICENSE as per above can be discussed.

//Peter