RE: [oe] Inclusive Language Proposal for YP/OE

From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: Jon Mason <jdmason@kudzu.us>,
	"yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>,
	"Patches and discussions about the oe-core layer"
	<openembedded-core@lists.openembedded.org>,
	OpenEmbedded Devel List
	<openembedded-devel@lists.openembedded.org>
Subject: RE: [oe] Inclusive Language Proposal for YP/OE
Date: Sat, 29 Jan 2022 03:30:00 +0000	[thread overview]
Message-ID: <14f6714d84944cba85099cb1d0ed24cf@axis.com> (raw)
In-Reply-To: <CAPoiz9wL16OTzxNHdw_5-L72GOHkhhM0--WZF7An071cx6sr_A@mail.gmail.com>

> -----Original Message-----
> From: openembedded-devel@lists.openembedded.org <openembedded-
> devel@lists.openembedded.org> On Behalf Of Jon Mason
> Sent: den 24 januari 2022 17:18
> To: yocto@lists.yoctoproject.org; Patches and discussions about the oe-
> core layer <openembedded-core@lists.openembedded.org>; OpenEmbedded Devel
> List <openembedded-devel@lists.openembedded.org>
> 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