[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+fCnZe5vdz3VSg54To5-zN-xVh8rcYaNXvxLpbL364BBskvow@mail.gmail.com>
Date: Sun, 26 Dec 2021 16:46:04 +0100
From: Andrey Konovalov <andreyknvl@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Joe Perches <joe@...ches.com>,
Andrew Morton <akpm@...ux-foundation.org>,
andrey.konovalov@...ux.dev, Felipe Balbi <balbi@...nel.org>,
USB list <linux-usb@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
linux-spdx@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] usb: raw-gadget: upgrade license identifier
On Sun, Dec 26, 2021 at 4:18 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Sun, Dec 26, 2021 at 03:50:43PM +0100, Andrey Konovalov wrote:
> > On Sun, Dec 26, 2021 at 3:02 PM Joe Perches <joe@...ches.com> wrote:
> > >
> > > On Sun, 2021-12-26 at 14:19 +0100, Andrey Konovalov wrote:
> > > > I wonder if checkpatch could alert about considering GPL-2.0+ when
> > > > adding new files.
> > >
> > > No. Licensing is up to the author/submitter.
> >
> > You're right. However, knowingly choosing a license requires that the
> > author doesn't forget to look into the difference and understand it.
> >
> > When I contributed this code, I didn't realize that GPL-2.0 and
> > GPL-2.0+ are different things. I was focused on the excitement of
> > contributing a new USB gadget driver.
> >
> > What would have allowed my to not overlook this, is that if throughout
> > the _process_ of contributing a new module, something would _ask_ me:
> > "Is this really the license you want to use?".
>
> I normally try to do that when I see GPL-2.0+, sorry I didn't do that
> this time.
Do you mean GPL-2.0+ or GPL-2.0? The code wasn't under GPL-2.0+, so
you would not have said anything, AFAIU.
Anyway, no worries. The only reason I sent the SPDX change was because
of noticing that the tag doesn't match most of the other drivers.
> But really, your open-source training at your employer should have
> covered all of that. If not, then something went wrong there :(
This is a weird statement for the general case.
Employers' processes exist to cover their legal bases. They have
nothing to do with the processes to guide Linux kernel contributors.
Legally, you're right: contributing requires accepting the rules under
which the contribution happens. Which means that contributors need to
read and understand all of the licensing documents before sending
patches. And it's on them, if they forget to do this or make a
mistake.
This is, however, poor from a contributor experience perspective.
Especially for independent contributors, who don't have a legal team
approving each of their actions.
Powered by blists - more mailing lists