Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 6/6] xz: Remove GPLv3 license checksum
Date: Wed, 4 Sep 2019 22:53:51 +0300	[thread overview]
Message-ID: <20190904195351.GA21155@localhost> (raw)
In-Reply-To: <0f8a4a800e70afe1eef8875571dbb50e1dc8f865.camel@linuxfoundation.org>

On Wed, Sep 04, 2019 at 07:50:35PM +0100, Richard Purdie wrote:
> On Wed, 2019-09-04 at 08:07 -0400, Mark Hatle wrote:
> > On 9/3/19 1:59 PM, Wes Lindauer wrote:
> > > Mark,
> > > 
> > > In reference to "It typically does NOT include the license of
> > > things used to
> > > build the software (such as makefiles, autoconf fragments, etc)".
> > > Since the only file that is licensed under GPLv3 is a M4 macro,
> > > does that mean
> > > the current patch is still valid? Shouldn't the GPLv3 license be
> > > removed from
> > > this recipe?
> > 
> > Unless the M4 file is generating/injecting code into the build(very
> > few I've
> > seen do this), then I would say it's not under GPLv3 at all.  (And I
> > wouldn't
> > have included GPLv3 in the LICENSE statement.)
> > 
> > But we need more consensus then just me saying so.
> > 
> > This may be a good question for the OE-TSC to ensure that we have
> > clarification
> > on this issue, and it's not just me saying I think one way or
> > another.
> 
> Not sure it needs to go to the TSC, we just need a patch which clearly
> says why the LICENSE statement is incorrect. I don't think the original
> patch in the series was clear about why GPLv3 didn't apply but if the
> commit message is improved, its probably fine.

I am getting more and more confused about both the patch and the 
semantics of LICENSE.

The status quo in the recipe is:

<--  snip  ->

# The source includes bits of PD, GPLv2, GPLv3, LGPLv2.1+, but the only file
# which is GPLv3 is an m4 macro which isn't shipped in any of our packages,
# and the LGPL bits are under lib/, which appears to be used for libgnu, which
# appears to be used for DOS builds. So we're left with GPLv2+ and PD.
LICENSE = "GPLv2+ & GPL-3.0-with-autoconf-exception & LGPLv2.1+ & PD"
LICENSE_${PN} = "GPLv2+"
LICENSE_${PN}-dev = "GPLv2+"
LICENSE_${PN}-staticdev = "GPLv2+"
LICENSE_${PN}-doc = "GPLv2+"
LICENSE_${PN}-dbg = "GPLv2+"
LICENSE_${PN}-locale = "GPLv2+"
LICENSE_liblzma = "PD"

LIC_FILES_CHKSUM = "file://COPYING;md5=97d554a32881fee0aa283d96e47cb24a \
                    file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
                    file://COPYING.GPLv3;md5=d32239bcb673463ab874e80d47fae504 \
                    file://COPYING.LGPLv2.1;md5=4fbd65380cdd255951079008b364516c \
                    file://lib/getopt.c;endline=23;md5=2069b0ee710572c03bb3114e4532cd84 \
                    "

<--  snip  -->

My confusion about the patch is that it removes COPYING.GPLv3 from 
LIC_FILES_CHKSUM but keeps GPL-3.0-with-autoconf-exception in LICENSE.

My confusion about the semantics of LICENSE is that I fail to find a 
clear statement in the documentation that the legal meaning of LICENSE 
in OE is what Mark claims it would be. Is this just Marks personal 
opinion on what should be done, or is this undocumented tribal 
knowledge, or is the exact semantics of LICENSE documented
somewhere in a language that lawyers understand?

My guess for the latter would be "undocumented tribal knowledge",
and clarification is required what is actually correct or incorrect
here. And I think this is also what Mark was asking for.

> Cheers,
> 
> Richard

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



  reply	other threads:[~2019-09-04 19:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16 19:44 [PATCH 1/6] iw: Fix license field to BSD-2-Clause Wes Lindauer
2019-08-16 19:44 ` [PATCH 2/6] openssh: Update LICENSE field with missing values Wes Lindauer
2019-08-16 19:44 ` [PATCH 3/6] shadow: Fix BSD license file checksum Wes Lindauer
2019-08-16 19:44 ` [PATCH 4/6] sudo: " Wes Lindauer
2019-08-16 19:44 ` [PATCH 5/6] libunwind: Fix MIT " Wes Lindauer
2019-08-16 19:44 ` [PATCH 6/6] xz: Remove GPLv3 license checksum Wes Lindauer
2019-08-16 20:50   ` Khem Raj
2019-08-27 17:34     ` Wes Lindauer
2019-08-27 18:04     ` Adrian Bunk
2019-08-27 18:27       ` Mark Hatle
2019-09-03 18:59         ` Wes Lindauer
2019-09-04 12:07           ` Mark Hatle
2019-09-04 18:50             ` Richard Purdie
2019-09-04 19:53               ` Adrian Bunk [this message]
2019-09-04 20:18                 ` Mark Hatle
2019-09-04 20:30                   ` Mark Hatle
2019-09-04 20:36                   ` richard.purdie
2019-09-05  9:35                 ` Peter Kjellerstedt
2019-09-04 20:27             ` Adrian Bunk
2019-09-04 20:42               ` Mark Hatle
2019-09-05  5:40                 ` Adrian Bunk
2019-08-16 20:02 ` ✗ patchtest: failure for "iw: Fix license field to BSD-2..." and 5 more Patchwork

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=20190904195351.GA21155@localhost \
    --to=bunk@stusta.de \
    --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