Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Tue, 2020-05-26 at 13:20 +0200, Matthias Schoepfer wrote:
> Hi Richard,
> 
> On 5/26/20 10:19 AM, Richard Purdie wrote:
> > 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.
> 
> The question here seems to be, is the GPLv3 License itself GPLv3 
> licensed. I followed the approach Khem Raj gave me on the yocto mailing 
> list. I do not like the approach either, but lack a better solution. In 
> this very specific package, only one .c file is licensed GPLv3, even the 
> COPYING file claims, everything is GPLv2 and LGPLv2.1+.
> 
> dumpsexp, the only GPLv3 file, is not even in the package by default. 
> The line
> LICENSE_${PN} = "LGPLv2.1+"
> pretty much tells the tale here.
> 
> Also, LICENSE file states, that there are other licenses also involved, 
> BSD 3 Clause, Public Domain and OCB license...

I think we need to be really clear about what the license of ${PN}-lic
means.

That leads to a really good question, which license is the license text
itself under?

I've asked this on our licensing list to see if anyone knows.

Cheers,

Richard