Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

[James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>]

On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote:
> > table development go under copyleft-next, Rusty recently asked for 
> > code to go in prior to the license tag being added denoting this 
> > license as GPL-compatible [3] -- I had noted in the patch 
> > submission which annotated copyleft-next's compatibility to GPLv2 
> > that copyleft-next is the license of choice for ongoing kernel 
> > development on my end [4]. If this is objectionable I'm happy to 
> > change it to GPLv2 however I'd like a reason provided as I've gone 
> > through all possible channels to ensure this is kosher, including
> > vetting by 3 attorneys now, 2 at SUSE.
> 
> You don't need a new tag, you can use "GPL" or "GPL and additional
> rights". In fact you don't want any other tag because when combined
>  with the kernel it is GPLv2 anyway because the only way the two are 
> fully compatible is for the kernel community to license the derived 
> work under the GPL.

This is the module tag ... it says what licence the module is under,
not the licence for the module combined with the kernel, which is
always GPLv2 because the stricter licence rules.

> The second reason you must use the GPL or GPL with additional tag is
> clause 8. We don't want anyone to create a module under your licence,
> claim it is "open source" then fifteen years later release the module 
> in binary only form still with a tag saying "copyleft-next" which we
> treat as GPL compatible. It's the same reason we don't have a BSD tag 
> but use "GPL with additional rights" to stop abuse of the module
> tags.

I don't follow you here.  We do have separate Dual licence tags. Dual
BSD/GPL allows me to do this today, without waiting fifteen years.  I
think you're conflating two issues:

   1. The licence of the actual module, which must be compatible with the
      kernel to do an insmod.  This is actually what MODULE_LICENSE
      declares
   2. The conditions the creation of the combined work imposes on me

It's the latter, even in the case of Dual BSD/GPL which still requires
me to release source code, so the combination with the kernel forces
GPL conditions even in the case of a BSD module (which is otherwise
compatible) and even after 15 years of this copyleft-next.

The point is: I can create a pure BSD module.  You can pick it up and
put it into the kernel source as Dual BSD/GPL, because BSD allows this,
but I'm still free to create binary only versions under BSD (as long as
they're for something other than inserting into Linux).  However, if I
want my binary only modules to be combined with Linux, I have to follow
GPLv2 compliance because GPLv2 becomes the ruling licence of the
combination.  The same would apply to this copyleft-next, even after 15
years.

> However you need to clarify the licence first I think. Linux is 
> GPLv2, your document only allows use of GPL with "GPL" works - not 
> GPL v2 works ?

A reasonable person would take GPL to mean any version of GPL.

> As PS: btw your licence is kind of weird. I can combine it with GPL 
> work, make it GPL therefore, and then use the GPL rights to remove 
> the bits I added thereby meaning I have your exact original work 
> under the GPL. Not sure how it's intended to work ?

What you describe is how it's always worked.  You may always distribute
a compatibly licensed piece of code under the stricter licence. 
 Additional permissions are always strippable in GPLv3 terms.

> It would also be good if someone clarified whether 6 and 7 are 
> intended to combine so you can take contributed patches and put them 
> in your own proprietary version. As a non-lawyer the intent is not
> clear at all.

The US copyright office defines a copyright work as anything which is
"an original work of authorship fixed in any tangible medium of
expression".  That means any change to an existing work (i.e. by a
patch) which contains enough originality to make the changed work
distinct from the old work is ipso facto a new work.  under copyright
-next this new work has a sunset 15 years from its creation by
combination, not 15 years from the original.  This means a constantly
updated work never sunsets.  Sure, you can go back 15 years and claim
the code at that time has passed into the public domain but you can't
do that if you also want the benefit of later changes.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel