lkml.org 
[lkml]   [2017]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] input: pegasus_notetaker: add license information
On Sun, Nov 26, 2017 at 12:28:49PM +0100, Philippe Ombredanne wrote:
> Greg, Martin:
>
> On Sun, Nov 26, 2017 at 9:59 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Nov 25, 2017 at 04:42:59PM -0800, Dmitry Torokhov wrote:
> >> Hi Martin,
> >>
> >> On Sat, Nov 18, 2017 at 09:45:18AM +0100, Martin Kepplinger wrote:
> >> > This adds an SPDX license identifier to this driver I wrote some time back.
> >> >
> >> > Signed-off-by: Martin Kepplinger <martink@posteo.de>
> >> > ---
> >> > drivers/input/tablet/pegasus_notetaker.c | 1 +
> >> > 1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/drivers/input/tablet/pegasus_notetaker.c b/drivers/input/tablet/pegasus_notetaker.c
> >> > index 47de5a81172f..cdf75c989469 100644
> >> > --- a/drivers/input/tablet/pegasus_notetaker.c
> >> > +++ b/drivers/input/tablet/pegasus_notetaker.c
> >> > @@ -1,3 +1,4 @@
> >> > +// SPDX-License-Identifier: GPL-2.0
> >>
> >> Should this be GPL-2.0+? The MODULE_LICENSE specifies that the module is
> >> "GPL" which in kernel land means GPLv2+. Or we should change the module
> >> license to strict "GPLv2"?
> >
> > That is up to Martin, given that he is the author, as to what he wants
> > to mark this as. Odd that it missed the big "fix up all files with no
> > license information" sweep.
> >
> > Philippe, how did we miss this one?
>
> It was not missed but instead was set aside by design.
> drivers/input/tablet/pegasus_notetaker.c does not have (or rather did
> not have until now) any licensing information beside a
> MODULE_LICENSE("GPL") and these were left aside as requiring some
> extra review and the eventual need of a clarification by the author,
> just as Martin is rightfully doing so just now.

Ah, thanks for the explaination, that makes more sense.

> >> Doing this would prevent mismatches between license notices, SPDX tags
> >> and MODULE_LCENSE() strings, which happen very often.
> >
> > I agree, but now that we are getting SPDX tags, we can fix up all of the
> > mismatches in MODULE_LICENSE() strings, of which there are a lot.
>
> I said that I would take a stab at it... but I did not attack this yet:
> Let me get over the ThanksGiving hangover and provide a list this
> week. I guess there could be three lists in fact:
>
> - modules with only a MODULE_LICENSE and no other license info: these
> could be candidates for adding an SPDX id matching the MODULE_LICENSE
>
> - modules updated to use an SPDX id and with a conflicting
> MODULE_LICENSE: the MODULE_LICENSE should be aligned to match the SPDX
> id
>
> - modules not yet updated to use an SPDX id and with a license notice
> conflicting with the MODULE_LICENSE: the MODULE_LICENSE should be
> aligned to match the licensing
>
> I'll run a scancode-toolkit scan on the tip of Linus' tree and create
> a CSV from that to surface these oddities.
> Unless you prefer me to use another tree like on the USB side for a start.

Just doing a big sweep of all of 4.15-rc1 to catch the new files /
deleted files for the large "here is a first pass of what the spdx id
should be" like you did before would be great as we are working with the
4.14 info at the moment.

Any additional work on the MODULE_LICENSE stuff would also be wonderful,
but might be a bit premature given that we don't have much SPDX coverage
at the moment.

But, if you want to try out the MODULE_LICENSE stuff, doing it on
drivers/usb/ would be great as that should be all finished with SPDX
tags now.

thanks,

greg k-h

\
 
 \ /
  Last update: 2017-11-27 08:56    [W:0.092 / U:35.732 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site