linux-kernel - Re: GPLv3 Position Statement

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]

Message-ID: <20060927123247.GA14668@thunk.org>
Date:	Wed, 27 Sep 2006 08:32:47 -0400
From:	Theodore Tso <tytso@....edu>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	Sergey Panov <sipan@...an.org>,
	James Bottomley <James.Bottomley@...elEye.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: GPLv3 Position Statement

On Wed, Sep 27, 2006 at 07:55:41AM +0200, Jan Engelhardt wrote:
> If by operating system you mean the surrounding userland application, 
> then yes, why should there be a problem with a GPL2 kernel and a GPL3 
> userland? After all, the userland is not only GPL, but also BSD and 
> other stuff.

Actually, the biggest problem will likely be userland applications and
shared libraries.  Many people believe that the GPL infects across
shared library links.  Whether or not that's true, it's never been
tested in court, and probably depends on the legal jurisdiction.  In
any case, many parts of the community, and certainly distributions
like Debian, behave as if the GPL infects across shared libraries.
But if that's true, then we have a big problem, because just as the
CDDL is incompatible with GPLv2, so too is the GPLv3 incompatible with
GPLv2.  (It has to be; the whole point of the GPLv3 is to fix "bugs"
such as spiking out companies considered evil like Tivo.  If you're
going to make the argument that there are no differences and so the
GPLv2 and v3 are compatible, then why are we wasting all of this time
and money on GPLv3?)

And if there are additional restrictoins in GPLv3 (and I've never
heard Eben deny it), then there's nothing you can do in GPLv3 to fix
the compatibility problem, because GPLv3 has more restrictions than
GPLv2, and the GPLv2 prohibits additional restrictions.  So the
incompatibility is forced from the GPLv2 side, and no textual changes
in GPLv3 can possibly hope to fix things.  Hence, for userspace code
which is licensed under a GPLv2 only license, it must be strictly
incompatible with any GPLv3 shared library.

And given that Stallman has announced that the new LGPL will be (to
use programming terms) a subclass of GPLv3, it means that the LGPLv3
is by extension incompatible with the GPLv2.  So that means that there
will have to be two different versions of glibc (and every other
shared library) shipped with every distributions --- one which is
GPLv2, and one which is GPLv3.  And this fork is going to be forced by
the FSF!  

So that brings up an interesting question --- which fork is Uhlrich
Drepper going to continue to work on?  The GPLv2 or GPLv3 version?  :-)

						- Ted

P.S.  I guess there is another alternative, which is that all shared
libraries must be dual licensed under a "your choice of LGPLv2 or
LGPLv3".  Of course, then that won't prohibit CCE's (Companies
Considered as Evil) from using said code.  And certainly, for people
who care more about code reuse, I would urge them to dual license
their code, since otherwise GPLv2 and GPLv3 code will not be able to
coexist, and the FSF will be making the license fragmentation problem
even worse for everyone, just to pursue their political goals.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/