[meta-oe][PATCH 1/4] libgcc: made libgcc-lic "GPL-3.0-with-GCC-exception"

[meta-oe][PATCH 1/4] libgcc: made libgcc-lic "GPL-3.0-with-GCC-exception"

[Matthias Schoepfer]

From: Matthias Schoepfer <matthias.schoepfer@ithinx.io>

libgcc LICENSE_${PN} is "GPL-3.0-with-GCC-exception". If libgcc-lic
is not also set to the same license, creating of image with

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"

will fail because libgcc-lic will have incompatible license.

Signed-off-by: Matthias Schoepfer <matthias.schoepfer@ithinx.io>
---
 meta/recipes-devtools/gcc/libgcc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/libgcc.inc b/meta/recipes-devtools/gcc/libgcc.inc
index 6d48ec9809..2e5b1fe492 100644
--- a/meta/recipes-devtools/gcc/libgcc.inc
+++ b/meta/recipes-devtools/gcc/libgcc.inc
@@ -35,7 +35,7 @@ PACKAGES = "\
 LICENSE_${PN} = "GPL-3.0-with-GCC-exception"
 LICENSE_${PN}-dev = "GPL-3.0-with-GCC-exception"
 LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception"
-
+LICENSE_${PN}-lic = "GPL-3.0-with-GCC-exception"
 
 FILES_${PN}-dev = "\
     ${base_libdir}/libgcc*.so \
-- 
2.26.2

[meta-oe][PATCH 2/4] elfutils: made elfutils-lic "GPLv2 | LGPLv3+"

[Matthias Schoepfer]

From: Matthias Schoepfer <matthias.schoepfer@ithinx.io>

If not set manually to "GPLv2 | LGPLv3+", install of non GPLv3 parts
of elfutils will be prevented in a setup that has

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"

set, because during image creation, elfutils-lic will have incompatible
license.

Signed-off-by: Matthias Schoepfer <matthias.schoepfer@ithinx.io>
---
 meta/recipes-devtools/elfutils/elfutils_0.179.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.179.bb b/meta/recipes-devtools/elfutils/elfutils_0.179.bb
index 1da95ec1de..ea185abd83 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.179.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.179.bb
@@ -105,6 +105,7 @@ PACKAGES =+ "${PN}-binutils libelf libasm libdw"
 # submit patches."
 LICENSE_${PN}-binutils = "GPLv3+"
 LICENSE_${PN} = "GPLv3+"
+LICENSE_${PN}-lic = "GPLv2 | LGPLv3+"
 LICENSE_libelf = "GPLv2 | LGPLv3+"
 LICENSE_libasm = "GPLv2 | LGPLv3+"
 LICENSE_libdw = "GPLv2 | LGPLv3+"
-- 
2.26.2

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

[Matthias Schoepfer]

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+"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-- 
2.26.2

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

[Richard Purdie]

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

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

[Matthias Schoepfer]

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...

Thanks and Regards,

   Matthias

-- 
Dr.-Ing. Matthias Schöpfer
matthias.schoepfer@googlemail.com

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

[Adrian Bunk]

On Tue, May 26, 2020 at 01:20:50PM +0200, Matthias Schoepfer via lists.openembedded.org wrote:
>...
> The question here seems to be, is the GPLv3 License itself GPLv3 licensed.
>...

  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.


cu
Adrian

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

[Richard Purdie]

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

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

[Matthias Schoepfer]

Hi Richard,

On 5/26/20 1:37 PM, Richard Purdie wrote:
> 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

I do not mean to annoy you by any means, but what is the status here. 
What would be a good approach? Adrian said, at least GPL License is free 
to copy and distribute. So another idea would be, to generally whitelist 
those license packages instead one by one.

Regards,

   Matthias

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

[Richard Purdie]

On Mon, 2020-07-06 at 18:16 +0200, Matthias Schoepfer wrote:
> On 5/26/20 1:37 PM, Richard Purdie wrote:
> > 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
> 
> I do not mean to annoy you by any means, but what is the status here. 
> What would be a good approach? Adrian said, at least GPL License is free 
> to copy and distribute. So another idea would be, to generally whitelist 
> those license packages instead one by one.

I did eventually get a response from the people on the SPDX-legal
mailing list. There wasn't a 100% clear consensus but for Yocto
Project/OE's situation, I think the LICENSE for these packages needs to
be:

XXX-license-text

which for SPDX identifiers would be exported as:

LicenseRef-XXX-license-text

The idea here is to spell out that it is the license text. People can
then process that accordingly in output data from the build system but
its clear its different from the license itself. It avoids us making
any claims as to what this license actually is, for the FSF licences
its relatively clear, for others it may not be.

We could factor all of the *GPL licenses into "FSF-license-text" since
they're all common as far as I know, but that isn't easily automated so
is probably not worth doing.

Does that help move things forward?

Cheers,

Richard

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

[Matthias Schoepfer]

Hi Richard,

thanks, that does help maybe a little. Personally, I find the license / 
compliance topic one of the most annoying things in embedded development 
*by far*. I also wonder, why nobody else has stumbled across this, since 
I guess it is quite common to rule out GPLv3, because most project 
managers I have seen are very worried about this. Nobody (at least not 
our lawyers can) can say, how you can safely use GPLv3ed software. 
Starts out with standard template library. It really is only headers. 
Are they subject to the linking exception? My favorite solution would be 
to open source everything. But my company does not like this very much...

Anyhow: There are 4 recipes affected. These are somewhat special, 
because GPLv3 is only applicable on certain packages that are not 
commonly installed on the target.

If I got you right, we should set:

LICENSE_${PN}-lic = "FSF-license-text"

If that is correct, I will happily prepare a patch set...

Regards,

     Matthias

On 7/6/20 6:26 PM, Richard Purdie wrote:
> I did eventually get a response from the people on the SPDX-legal
> mailing list. There wasn't a 100% clear consensus but for Yocto
> Project/OE's situation, I think the LICENSE for these packages needs to
> be:
>
> XXX-license-text
>
> which for SPDX identifiers would be exported as:
>
> LicenseRef-XXX-license-text
>
> The idea here is to spell out that it is the license text. People can
> then process that accordingly in output data from the build system but
> its clear its different from the license itself. It avoids us making
> any claims as to what this license actually is, for the FSF licences
> its relatively clear, for others it may not be.
>
> We could factor all of the *GPL licenses into "FSF-license-text" since
> they're all common as far as I know, but that isn't easily automated so
> is probably not worth doing.
>
> Does that help move things forward?
>
> Cheers,
>
> Richard

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

[Richard Purdie]

On Wed, 2020-07-08 at 10:19 +0200, Matthias Schoepfer wrote:
> thanks, that does help maybe a little. Personally, I find the license
> / compliance topic one of the most annoying things in embedded
> development *by far*. I also wonder, why nobody else has stumbled
> across this, since I guess it is quite common to rule out GPLv3,
> because most project  managers I have seen are very worried about
> this. Nobody (at least not our lawyers can) can say, how you can
> safely use GPLv3ed software. 
> Starts out with standard template library. It really is only
> headers. headers. 
> Are they subject to the linking exception? My favorite solution would
> be to open source everything. But my company does not like this very
> much...
> 
> Anyhow: There are 4 recipes affected. These are somewhat special, 
> because GPLv3 is only applicable on certain packages that are not 
> commonly installed on the target.
> 
> If I got you right, we should set:
> 
> LICENSE_${PN}-lic = "FSF-license-text"
> 
> If that is correct, I will happily prepare a patch set...

I've been looking at the license.bbclass code for other reasons and it
has a few issues. I suspect not many people are actually enabling the
separate license packages, I don't think its enabled anywhere in our
automated testing either.

I think we'll have to have some code which translates "XXX" into "XXX-
license-text" for the license of ${PN}-lic.

Something like:

def convert_to_license_texts(d):
    licenses = d.getVar("LICENSE")
    ret = []
    for x in licenses.split():
        if "|" in x or "&" in x:
            ret.append(x)
        else:
            ret.append(x + "-license-text")
    return ret.join(" ")

LICENSE_${PN}-lic = "${@convert_to_license_texts(d)}"

(admittedly completely untested)

Ideally we'd have some mapping to convert the GPL/LGPL entries to FSF-
license-text and simplify out any |/& expressions but for now the above
is probably good enough.

Cheers,

Richard

[meta-oe][PATCH 4/4] libksba: made libksba-lic "GPLv2+ | LGPLv3+"

[Matthias Schoepfer]

From: Matthias Schoepfer <matthias.schoepfer@ithinx.io>

If not set manually to "GPLv2+ | LGPLv3+", install of non GPLv3 parts (the
library in this case) will be prevented in a setup that has

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"

set, because during image creation, libksba-lic will have incompatible
license.

Signed-off-by: Matthias Schoepfer <matthias.schoepfer@ithinx.io>
---
 meta/recipes-support/libksba/libksba_1.3.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/libksba/libksba_1.3.5.bb b/meta/recipes-support/libksba/libksba_1.3.5.bb
index 336d7f8177..1a8f18a9ef 100644
--- a/meta/recipes-support/libksba/libksba_1.3.5.bb
+++ b/meta/recipes-support/libksba/libksba_1.3.5.bb
@@ -3,6 +3,7 @@ HOMEPAGE = "http://www.gnupg.org/related_software/libksba/"
 LICENSE = "GPLv3+ & (GPLv2+ | LGPLv3+)"
 LICENSE_${PN} = "GPLv2+ | LGPLv3+"
 LICENSE_${PN}-doc = "GPLv3+"
+LICENSE_${PN}-lic = "GPLv2+ | LGPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=fd541d83f75d038c4e0617b672ed8bda \
                     file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
                     file://COPYING.GPLv3;md5=2f31b266d3440dd7ee50f92cf67d8e6c \
-- 
2.26.2