Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

On Thu, Jun 02, 2022 at 04:11:16AM +0000, Bird, Tim wrote:
> > -----Original Message-----
> > From: Thomas Gleixner <tglx@linutronix.de>
> > 
> > Tim!
> > 
> > On Wed, May 25 2022 at 19:05, Bird, Tim wrote:
> > >> From: Luis Chamberlain <mcgrof@infradead.org> On Behalf Of Luis Chamberlain
> > >> I agree that we want to keep the number of licenses as small as
> > >> possible but we cannot really dictate which dual licensing options a
> > >> submitter selects unless the license is GPL-2.0-only incompatible,
> > >> which copyleft-next is not.
> > >
> > > Um, yes we can dictate that.
> > 
> > No!
> Sorry for the delayed response.  I was on vacation over memorial day weekend
> (holiday in the US.)
> 
> I think that the option to reject a contribution based on its license should be
> available to the community, using criteria beyond those that Luis has mentioned
> (and that you mention below).
> 
> I could create a license that was GPL-2.0-only compatible, and use it to cover a new
> contribution to the Linux kernel (in dual-license format), in order to get exposure
> for the license or to promote it.  We could use the SPDX identifier "Tims-license-0.1".
> I think it would be fair for the community to reject a contribution based
> on those license circumstances, even though it met all the criteria you mention.
> 
> I don't think that the Linux kernel should be used for license promotion, but if it is,
> then it should be used to promote GPL-v2-only.

I agree, and in a way, I feel like that is what is happening here for
this original submission.  See below for more...

> > > There were good reasons that the original BSD dual-licenses were
> > > allowed.  Those same reasons don't apply here.
> > 
> > That's just wrong. The reason why dual licensing is allowed is to share
> > code across licesce preferences. The very same reason applies here.
> 
> I was talking about why dual licensing was originally introduced, which was
> a situation different from what went on in 2016, when the copyleft-next
> dual license was discussed.
> 
> Dual-licensing in the Linux kernel was originally introduced because code was being
> taken from BSD and placed into Linux (under GPL v2), often by someone other than the
> original author.  This created a bit of hard feelings between the BSD community
> and the Linux community.  So dual-licensing was introduced so that derivative works
> (created by Linux developers) of BSD code could flow back into the BSD project.
> 
> This was code that existed before being introduced into Linux, and there was
> no notion of using the kernel to promote the BSD license.

I agree, dual licensed code that is added to the kernel is either done:
	- because the original code had a non-GPL license and it was
	  added so that it could be compatible so that it could be added
	  to Linux.
	- because the code being accepted into Linux can also be used in
	  another non-Linux codebase now or in the future.

The submission here was neither of these.

It was to test core Linux kernel functionality that is ONLY GPL-v2.
That functionality and interactions within the Linux core could never be
used in any non-Linux project as it does not make any sense.  Or if it
could be used in a non-Linux project, that would only be if that project
was also GPLv2 licensed as the kernel core code would have been copied
out of Linux into that other project.

I feel that the dual-license of this code is purely done to support an
additional license and give it attention as it could never be invoked on
this codebase due to the contents of it.  Which makes it not necessary
and has only distracted us from the real technical issues of why I
rejected this code in the first place :(

thanks,

greg k-h