Re: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, May 20, 2013 at 11:24:02AM +0100, Ian Stirling wrote:
> >i wish to know the procedure by which my formally and publicly
> >announced release of all linux kernel contributions under the dual
> >licenses of GPLv2 and GPLv3+ may be entered - formally - upstream and
> >into the linux kernel sources being maintained on git.kernel.org
> 
> Umm - that was my point - though I did not make it explicitly.
> 
> Either there is a policy change, and it is decided to allow such
> dual-licenced code in the repo, or your code does not get checked in,
> as it does not have a compatible licence.

Actually, it's more subtle than that.  As I said earlier, we *do*
allow dual-licensed code in the repo, but it's on a per-file basis.
There is no way to designate that certain lines in a files has a
different copyright license than the lines in the file; I assume
people will understand why that's an accounting nightmare.

The more subtle thing to consider is that with dual-licensed code,
***anyone*** has the ability to strip one of the licenses from the
code in the course of making modification.  So for example, suppose I
released e2fsck/recovery.c under GPLv2+.  I would never do that,
because then someone might make improvements to the e2fsck/recovery.c
under GPLv3-only terms, and then strip the GPLv2 license from the file
and release it under GPLv3-only terms.  That's a completely legal
thing to do; it may not be ethical, and it may not improve that
person's standing in the community, but it's completely legal.  (It's
also identical to what the FSF has done when it has converted GPLv2+
projects to GPLv3-only projects, although it's a more acceptable when
the primary copyright owner of the file does it; what I'm calling out
here is that ***anyone*** can legally take GPLv2/v3 code and turn it
into GPLv2 or GPLv3 only code.)

The reason why I dislike someone taking GPLv2/v3 code and stripping
out the GPLv2 license is because it makes new versions of code which I
had originally written becoming available only under a GPLv3 license.
This would mean that in my example of e2fsck/recovery.c, those
enhacements would not be available for use in the Linux kernel as
fs/ext4/recovery.c.  It's for the same reason why BSD folks get upset
when BSD code gets turned into GPLv2 code --- and the standard retort
to their being upset is "well, you shouldn't have released it under
the BSD license, then, since the BSD license will allow you to do
this".  Applied to this GPLv2/GPLv3 incompatibility issue, and my
extreme dislike of the anti-Tivo clause in GPLv3, this explains why I
choose not to release my code under a GPLv2/GPLv3 dual-license or a
GPLv2+ license.

But there's a flip side to this, which is the same legal argument
***also*** allows a kernel maintainer to take a contribution which is
under a GPLv2/v3 or GPLv2+ license, and incorporate it into a
GPLv2-only file, and not bother to mark that it originally came from a
GPLv2+ or GPLv2/v3 contribution.  The original contribution is still
licensed that way, and if you go through the mailing list archives,
you could find that contribution and extract that code and use it in
some other GPLv3 project.  But we are under no obligation to mark that
a particular set of lines in a file originally came from a GPLv2/v3 or
GPLv2+ contribution.

But a very large number of senior Linux kernel developers (not just
Linus) have stated that we stand against the GPLv3 anti-Tivoization
clause, and so we intend to keep the Linux kernel sources under a
GPLv2-only license.  That's not to say that certain drivers won't be
dual licensed, for specific reasons, but you shouldn't expect that
core kernel files will be GPLv3 compatible in the near future.

     	    	       	  		      - Ted