From: "David Schwartz" <davids@webmaster.com>
To: <espie@nerim.net>, <linux-kernel@vger.kernel.org>
Subject: RE: GPL weasels and the atheros stink
Date: Sun, 2 Sep 2007 19:01:17 -0700
Message-ID: <MDEHLPKNGKAHNMBLJOLKMECFGJAC.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20070902140306.GA27317@lain.home>
Importance: Normal
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3673
Lines: 74


> Letting aside the legality of that change, why would such a change
> be needed ? The licensing is perfectly clear: the file is available
> under the ISC licence, OR the GPL licence.  This doesn't cause any
> problem for the linux kernel. The ISC licence is perfectly compatible
> with the GPL (note to GPL trolls: this new licence does not have any
> advertizing clause, which was the ONLY issue with the old licence). And
> heck, they can use the code under the GPL licence. There is no
> incompatibility
> in there.

Your entire argument is based on the false assumption that these licenses
are compatible. They are not. You cannot put code that was offered under the
GPLv2 into code that is licensed under the dual license and distribute the
result.

> The only possible issue is related to paranoia: if this file stays
> dual-licenced, some of its code may escape from the GPL shrine, and
> become available to the cuddly BSD people... but since their licence
> doesn't protect anything, it could used by the Evil Empire of Microsoft,
> or SCO, or whoever is the villain of the month.

That's not the problem. The problem is that if the file stays dual-licensed,
everyone working on that file in the Linux kernel will have to be careful
not to put any GPLv2-only code into it. That's just untenable. Any
consistent license is better than different files being under different
licenses such that you can't cut and paste code between files.

> Let's extend the story a wee little bit. It seems that these days, some
> parts of the opensource community have gotten confident enough that they
> do not need the other part. We all know the situation is already fairly
> disymetric. The GPL is less free than the ISC licence for instance (for
> some definition of free), and practically, this makes it impossible to
> add GPL code to an ISC project without putting the project under the Aegis
> of the GPL licence. The reciprocal relationship does NOT hold. As you can
> see in various places, it is quite possible to put BSD code inside a GPL
> project without any issue (the FSF libiberty is a nice proof of that. And
> heck, the glibc as well... Read carefully past the COPYING file, you'll
> find numerous instances of BSD-like licences).

If you embed protectable elements from GPLv2-only code into any of those
files, they are no longer dual-licensed. You wind up creating traps and
complexity that makes the code much harder to maintain.

> So, now, it's down to dirty fighting. Absorbing and `relicensing' and
> evolving code.  Have you all been bitten my RMS paranoia (that leads to
> this `interesting GPLv3) ? Do you intend to keep grabbing BSD code and
> putting it exclusively under the GPL ?

It is just impractical to maintain code in the Linux tree under any other
license. See some of my other posts where I discuss the nightmare of trying
to add new hooks to every filesystem if different filesystems are under
different licenses and so you can't cut/paste the implementation from one
file to another.

> Do you really think he's going to keep his work under a
> dual-licence, seeing
> how a bunch of rabid linux zealots are all but intent on stealing his code
> whenever they can.
>
> Nice going, GPL fan-boys...

A dual-license is a compromise. One of the downsides is that you may force
large projects that are under one license or the other to fork the code. If
that bothers you, don't dual license.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/