From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Saul Wold <Saul.Wold@windriver.com>,
openembedded-architecture@lists.openembedded.org,
OE-core <openembedded-core@lists.openembedded.org>,
OpenEmbedded Devel List
<openembedded-devel@lists.openembedded.org>
Subject: Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_<license> usage
Date: Fri, 18 Feb 2022 14:13:30 +0000 [thread overview]
Message-ID: <df167d230c66ea8a975e7bc4b8d731cf58798e81.camel@linuxfoundation.org> (raw)
In-Reply-To: <7d187920-92f0-a0fe-22b9-a77a1c98fd7d@windriver.com>
On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote:
> I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used
> and processed to possibly include a COMPATIBLE_LICENSES variable as
> well, see PeterK's email [0]
>
> I am trying to determine the usage of WHITELIST_<license> which would be
> used to override a license that might be listed in INCOMPATIBLE_LICENSES
> variable.
>
> Randy and I have done a quick and dirty survey of a 100 or so layers
> (thanks Randy) and could not find any real usage other than what's
> currently in OE-Core for WHITELIST_GPL-3.0.
>
> If you are using WHITELIST_<license>, please let me reply with your usage.
>
>
> [0] https://lists.openembedded.org/g/openembedded-devel/message/95166
We need to be mindful that we need to resolve this to unblock the other language
changes and feature creep here is potentially problematic. I do think it is
worth trying to improve things rather than blindly allowing the horrible syntax
in this variable to continue though.
The test case we have for this currently is:
WHITELIST_GPL-3.0:pn-core-image-minimal = "bash"
so I'd wondered about an alternative of:
INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0"
which matches the current functionality, removes the issue that the name of the
variable is unknown without iterating every possible license name and makes it
clear where it is applying to.
I don't really like INCOMPATIBLE_LICENSE_ALLOWED_RECIPES since:
a) it is long
b) it refers to recipes when it works against packages
(INCOMPATIBLE_LICENSE_PACKAGE_EXCEPTIONS is more correct but still long)
I do like it mentioning INCOMPATIBLE_LICENSE in full since it works in
conjunction with that variable and that is definitely not clear from the current
WHITELIST_XXX until you look at the code.
I'm still of the opinion the AVAILABLE_LICENSES variable is something we should
be aiming to remove ultimately too, it has horrible issues with layers changing
hashes for all recipes.
Cheers,
Richard
next prev parent reply other threads:[~2022-02-18 14:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 23:01 INCOMPATIBLE_LICENSES and WHITELIST_<license> usage Saul Wold
2022-02-18 0:20 ` [oe] " Andre McCurdy
2022-02-18 8:00 ` [Openembedded-architecture] " Mikko.Rapeli
2022-02-18 8:03 ` Alexander Kanavin
2022-02-18 8:16 ` Mikko.Rapeli
2022-02-18 14:13 ` Richard Purdie [this message]
2022-02-18 23:34 ` Peter Kjellerstedt
[not found] ` <6bba214d8ca17f438191ca84b3a8c3a97da41e1d.camel@linuxfoundation.org>
2022-02-19 4:42 ` Peter Kjellerstedt
[not found] ` <16D4E6E0715A89F5.27450@lists.openembedded.org>
2022-02-18 14:24 ` [OE-core] " Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=df167d230c66ea8a975e7bc4b8d731cf58798e81.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=Saul.Wold@windriver.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox