Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: RE: [OE-core] [PATCH 4/4] license: Rework INCOMPATIBLE_LICENSE wildcard handling
Date: Wed, 2 Mar 2022 15:09:30 +0000	[thread overview]
Message-ID: <7d61dda553234e96b0be45bd550b0918@axis.com> (raw)
In-Reply-To: <20220301234214.247172-4-richard.purdie@linuxfoundation.org>

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 2 mars 2022 00:42
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 4/4] license: Rework INCOMPATIBLE_LICENSE
> wildcard handling
> 
> The current wildcard handling is badly documented and inconsistently
> used and understood.
> 
> Forcing users to have to use "GPL-3.0-only GPL-3.0-or-later" whilst
> explict is not very user friendly. Equally, using the current wildcards
> is ambigious. This supports pre-defined expansions only and at least makes
> it clear what GPL-3.0* means (it doesn't include the exception licenses).
> 
> This is hopefully an acceptable compromise between literal meaning and
> having something usable.
> 
> Non-SPDX forms of license in this field have been dropped and errors are
> shown for unsupported expansions and unsupported old style license terms.
> 
> Users need to carefully consider how to migrate to the new syntax but
> the meaning should be well defined and clear from here forward.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/license.bbclass                  | 41 +++++----
>  .../oeqa/selftest/cases/incompatible_lic.py   | 86 +++++++++++--------
>  2 files changed, 70 insertions(+), 57 deletions(-)
> 
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index 68c022248c8..cb1f46983ac 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -277,28 +277,27 @@ AVAILABLE_LICENSES := "${@' '.join(available_licenses(d))}"
> 
>  def expand_wildcard_licenses(d, wildcard_licenses):
>      """
> -    Return actual spdx format license names if wildcards are used. We expand
> -    wildcards from SPDXLICENSEMAP flags and AVAILABLE_LICENSES.
> +    There are some common wildcard values users may want to use. Support them
> +    here.
>      """
> -    import fnmatch
> -
> -    licenses = wildcard_licenses[:]
> -    spdxmapkeys = d.getVarFlags('SPDXLICENSEMAP').keys()
> -    for wld_lic in wildcard_licenses:
> -        spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
> -        licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in spdxflags]
> -        # Assume that if we are passed "GPL-3.0" or "*GPL-3.0", then it means
> -        # "-or-later" as well.
> -        if not wld_lic.endswith(("-or-later", "-only", "*", "+")):
> -            spdxflags = fnmatch.filter(spdxmapkeys, wld_lic + "+")
> -            licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in spdxflags]
> -
> -    spdx_lics = d.getVar('AVAILABLE_LICENSES').split()
> -    for wld_lic in wildcard_licenses:
> -        licenses += fnmatch.filter(spdx_lics, wld_lic)
> -
> -    licenses = list(set(licenses))
> -    return licenses
> +    licenses = set(wildcard_licenses)
> +    mapping = {
> +        "GPL-3.0*" : ["GPL-3.0-only", "GPL-3.0-or-later"],
> +        "LGPL-3.0*" : ["LGPL-3.0-only", "LGPL-3.0-or-later"],

If you are adamant about using "*" in these shortcuts (which I 
still think is a mistake), then you should add these two as well:

        "AGPL-3.0*" : ["AGPL-3.0-only", "AGPL-3.0-or-later"],
        "*GPL-3.0*" : ["GPL-3.0-only", "GPL-3.0-or-later", "LGPL-3.0-only", "LGPL-3.0-or-later", "AGPL-3.0-only", "AGPL-3.0-or-later"],

I believe the last one is what most really want to do, i.e., 
exclude all GPL-3.0 variants.

//Peter


  reply	other threads:[~2022-03-02 15:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 23:42 [PATCH 1/4] mutlilib: Handle WHITELIST_GPL-3.0 being unset Richard Purdie
2022-03-01 23:42 ` [PATCH 2/4] base/license: Rework INCOMPATIBLE_LICENSE variable handling Richard Purdie
2022-03-01 23:42 ` [PATCH 3/4] license/insane: Show warning for obsolete license usage Richard Purdie
2022-03-02 15:17   ` [OE-core] " Peter Kjellerstedt
2022-03-02 15:19     ` Richard Purdie
2022-03-01 23:42 ` [PATCH 4/4] license: Rework INCOMPATIBLE_LICENSE wildcard handling Richard Purdie
2022-03-02 15:09   ` Peter Kjellerstedt [this message]
2022-03-02 15:34     ` [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=7d61dda553234e96b0be45bd550b0918@axis.com \
    --to=peter.kjellerstedt@axis.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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