mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKMECFGJAC.davids@webmaster.com> (raw)
In-Reply-To: <20070902140306.GA27317@lain.home>


> 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



  parent reply	other threads:[~2007-09-03  2:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-02 14:03 Marc Espie
2007-09-02 16:52 ` Kyle Moffett
2007-09-02 16:54 ` Alan Cox
2007-09-02 17:16 ` Oleg Verych
2007-09-02 17:34 ` Michael Tharp
2007-09-02 17:41 ` Jeff Garzik
2007-09-02 17:57 ` Jeff Garzik
2007-09-02 20:22 ` Bernd Petrovitsch
2007-09-03  2:01 ` David Schwartz [this message]
2007-09-03  2:57   ` Daniel Hazelton
2007-09-03  9:47     ` David Schwartz
2007-09-03 17:43       ` Daniel Hazelton
2007-09-04  0:23         ` David Schwartz
2007-09-04  0:49           ` Daniel Hazelton
2007-09-04 15:10           ` Valdis.Kletnieks
2007-09-04 17:20             ` Daniel Hazelton
2007-09-03 17:18     ` Krzysztof Halasa
2007-09-03 18:11       ` Daniel Hazelton
2007-09-03 16:12 ` Valdis.Kletnieks
2007-09-04 15:01   ` Jarek Poplawski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MDEHLPKNGKAHNMBLJOLKMECFGJAC.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=espie@nerim.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®