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] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ