> -----Original Message----- > From: openembedded-de...@lists.openembedded.org <openembedded- > de...@lists.openembedded.org> On Behalf Of Jon Mason > Sent: den 24 januari 2022 17:18 > To: yo...@lists.yoctoproject.org; Patches and discussions about the oe- > core layer <openembedded-core@lists.openembedded.org>; OpenEmbedded Devel > List <openembedded-de...@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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161096): https://lists.openembedded.org/g/openembedded-core/message/161096 Mute This Topic: https://lists.openembedded.org/mt/88760881/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
