All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: matthias.schoepfer@googlemail.com,
	 openembedded-core@lists.openembedded.org
Cc: Matthias Schoepfer <matthias.schoepfer@ithinx.io>
Subject: Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"
Date: Tue, 26 May 2020 09:19:22 +0100	[thread overview]
Message-ID: <de59b9f118c6d51c902e50dce97a7680f77e7402.camel@linuxfoundation.org> (raw)
In-Reply-To: <20200526081233.62413-3-matthias.schoepfer@googlemail.com>

On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via
lists.openembedded.org wrote:
> From: Matthias Schoepfer <matthias.schoepfer@ithinx.io>
> 
> With the exception of dumpsexp.c, which is GPLv3, all other parts
> of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive"
> licenses.
> 
> If libgcrypt-lic is not set to "GPLv2+ & LGPLv2.1+", image creation
> will
> fail with settings like
> 
> INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0
> AGPL-3.0"
> COPY_LIC_MANIFEST = "1"
> COPY_LIC_DIRS = "1"
> LICENSE_CREATE_PACKAGE = "1"
> 
> Signed-off-by: Matthias Schoepfer <matthias.schoepfer@ithinx.io>
> ---
>  meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> index 4e0eb0a169..fd40cdcf83 100644
> --- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> +++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> @@ -7,6 +7,7 @@ SECTION = "libs"
>  LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
>  LICENSE_${PN} = "LGPLv2.1+"
>  LICENSE_${PN}-dev = "GPLv2+ & LGPLv2.1+"
> +LICENSE_${PN}-lic = "GPLv2+ & LGPLv2.1+"
>  LICENSE_dumpsexp-dev = "GPLv3+"

I don't like this approach at all. Its obviously inconvenient if your
image uses only the non-GPLv3 pieces but this doesn't change the fact
that the main package license does include GLPv3 and ${PN}-lic is right
to include it. You're breaking the metadata to fit your use case for
convenience.

If you're excluding GPLv3 things from packaging, you could then (and
only then) justifiably adjust ${PN}-lic to a different license so the
code should be doing that, not changing the underlying metadata to suit
you.

Cheers,

Richard


  reply	other threads:[~2020-05-26  8:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  8:12 [meta-oe][PATCH 1/4] libgcc: made libgcc-lic "GPL-3.0-with-GCC-exception" Matthias Schoepfer
2020-05-26  8:12 ` [meta-oe][PATCH 2/4] elfutils: made elfutils-lic "GPLv2 | LGPLv3+" Matthias Schoepfer
2020-05-26  8:12 ` [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+" Matthias Schoepfer
2020-05-26  8:19   ` Richard Purdie [this message]
2020-05-26 11:20     ` [OE-core] " Matthias Schoepfer
2020-05-26 11:37       ` Adrian Bunk
2020-05-26 11:37       ` Richard Purdie
2020-07-06 16:16         ` Matthias Schoepfer
2020-07-06 16:26           ` Richard Purdie
2020-07-08  8:19             ` Matthias Schoepfer
2020-07-08  9:00               ` Richard Purdie
2020-05-26  8:12 ` [meta-oe][PATCH 4/4] libksba: made libksba-lic "GPLv2+ | LGPLv3+" Matthias Schoepfer

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=de59b9f118c6d51c902e50dce97a7680f77e7402.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=matthias.schoepfer@googlemail.com \
    --cc=matthias.schoepfer@ithinx.io \
    --cc=openembedded-core@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.