linux-kernel - Re: [PATCH] usb: raw-gadget: upgrade 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]

Message-ID: <YclgRzE1uO/FsPPX@kroah.com>
Date:   Mon, 27 Dec 2021 07:42:15 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Andrey Konovalov <andreyknvl@...il.com>
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 04:46:04PM +0100, Andrey Konovalov wrote:
> 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.

Ah, right, good, I didn't mess up then :)

> > 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.

Employers _BETTER_ be giving their developers who contribute to open
source projects basic legal training in licenses, copyrights, and other
related things.  If not they are very derelict in their duties.  I had
my first such training way back in 2001 or so, this is something that
most companies have been doing for decades and is nothing new.  Every
company I have worked at since has always had something like this in
place.

I would argue that any company that did NOT do this is not covering
their legal bases well at all, and that's a huge failure on their part.

Heck, the Linux Foundation even provides free training material for this
type of thing, online, if companies don't want to do it themselves.  I
recommend everyone at least glancing at this if they have to do any open
source work:
	https://training.linuxfoundation.org/training/open-source-licensing-basics-for-software-developers/

> 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.

That's what you agree with with the "Signed-off-by:" line that you added
to your patch.  You did read the Developer's Certificate of Origin (DCO)
that decribes this in our documentation, right?  The DCO is very simple
and should be easy to understand.

> 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.

See the free course information above for what is there for independent
contributors if they are interested in it.

thanks,

greg k-h