linux-kernel - Re: [PATCH] gpio: uapi: use the preferred SPDX license identifier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 10 Feb 2021 14:05:27 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Kent Gibson <warthog618@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: uapi: use the preferred SPDX license identifier

On Thu, Feb 4, 2021 at 4:29 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Thu, Feb 04, 2021 at 04:17:51PM +0100, Bartosz Golaszewski wrote:
> > On Thu, Feb 4, 2021 at 3:35 PM Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Thu, Feb 04, 2021 at 03:15:50PM +0100, Bartosz Golaszewski wrote:
> > > > On Thu, Feb 4, 2021 at 2:47 PM Greg Kroah-Hartman
> > > > <gregkh@...uxfoundation.org> wrote:
> > > > >
> > > > > On Thu, Feb 04, 2021 at 01:43:57PM +0100, Bartosz Golaszewski wrote:
> > > > > > From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> > > > > >
> > > > > > GPL-2.0 license identifier is deprecated, let's use the preferred
> > > > > > identifier: GPL-2.0-only.
> > > > > >
> > > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
> > > > > > ---
> > > > > > Hi Kent, Greg,
> > > > > >
> > > > > > I started working on making libgpiod licensing reuse-compliant and noticed
> > > > > > that the reuse-tool is telling me that the GPL-2.0 SPDX identifier in the
> > > > > > GPIO uapi header is deprecated. Since I'm required to copy the header
> > > > > > verbatim into libgpiod's repository, I think we need to fix that at source
> > > > > > first.
> > > > > >
> > > > > >  include/uapi/linux/gpio.h | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
> > > > > > index e4eb0b8c5cf9..3e01ededbf36 100644
> > > > > > --- a/include/uapi/linux/gpio.h
> > > > > > +++ b/include/uapi/linux/gpio.h
> > > > > > @@ -1,4 +1,4 @@
> > > > > > -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > > > > +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> > > > >
> > > > > No, there is no need to convert the kernel to the "latest" spdx level,
> > > > > when we started out there was no "-only" nonsense (hint no other license
> > > > > has that crud), and "GPL-2.0" is a totally valid summary of the license.
> > > > >
> > > > > So please don't go changing it all in-kernel, that way lies madness.
> > > > > Let's finish fixing up ALL kernel files before worrying about what SPDX
> > > > > "version" we are at.
> > > > >
> > > >
> > > > But then, the reuse script is telling me:
> > > >
> > > >     Unfortunately, your project is not compliant with version 3.0 of
> > > > the REUSE Specification :-(
> > > >
> > > > because I'm using a deprecated license. :(
> > >
> > > Go yell at the REUSE people, there's no requirement to have the most
> > > recent version of SPDX, is there?   :)
> > >
> > > And if that's the only thing wrong with the project when running 'reuse
> > > lint' then you should be happy, no one will complain at all.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Ok, I get it but let me try one last time: there's absolutely no harm
> > in merging this patch for the next release, is there? Currently there
> > are around 15000 instances of "GPL-2.0-only" in the kernel vs 30000
> > "GPL-2.0" - so the former is not that uncommon.
>
> It's up to the owner/maintainer of this file in the end, but I don't
> want to see patches doing this for many more files, as it's pointless
> churn as far as the kernel is concerned.
>

Since it's up to me to decide - I'll apply this but I'll clarify in
the commit message why user-space may want this change.

Bart