public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Poole <mdpoole@troilus.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Charles Cazabon <linux@discworld.dyndns.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: GPL version, "at your option"?
Date: 17 Nov 2004 11:33:04 -0500	[thread overview]
Message-ID: <87y8h08mgv.fsf@sanosuke.troilus.org> (raw)
In-Reply-To: <1100704019.32698.24.camel@localhost.localdomain>

Alan Cox writes:

> The use of this by some kernel people is to issue "this version only"
> licenses is unfortunate, ill advised and potentially harmful. Firstly it
> isn't remotely clear what it means because the license itself never
> talks about this case, only the "or later" case. Secondly it may force
> code chunks to be rewritten if the GPL is modified to fix a legal
> problem in future and the original author or their estate or company [*]
> cannot be traced. Thirdly it may actually be meaningless anyway - the
> GPL doesn't talk about "this version only" in any of its text so it may
> be an "additional restriction" and thus a void clause.

I have no argument that restricting it to v2 is potentially harmful,
but allowing distribution under GPL v3 is also potentially harmful
since the terms are not yet known, and later v3plus changes would
restrict the whole work to v3plus.

As for the "additional restriction" theory, the FSF apparently does
not think it is a restriction; the GPL says what happens *if* the
program says "or any later version."  If the intent were to always
allow newer license, that should be clearly written into the license
rather than making it conditional.  The GPL FAQ[1] implies that "or
any later version" is optional.  When the issue came up on
debian-legal earlier this year, Dave Turner provided an answer[2].

Michael Poole

[1]- http://www.fsf.org/licenses/gpl-faq.html#VersionTwoOrLater
[2]- http://lists.debian.org/debian-legal/2004/08/msg00821.html

  reply	other threads:[~2004-11-17 16:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-16 14:08 GPL version, "at your option"? Fruhwirth Clemens
2004-11-16 14:35 ` Erik Mouw
2004-11-16 14:58   ` Fruhwirth Clemens
2004-11-16 14:40 ` Charles Cazabon
2004-11-17 15:07   ` Alan Cox
2004-11-17 16:33     ` Michael Poole [this message]
2004-11-17 16:09       ` Alan Cox
2004-11-16 14:48 ` Tim Schmielau
2004-11-16 15:46   ` Linus Torvalds
2004-11-17 15:09     ` Alan Cox
2004-11-17 16:28       ` Linus Torvalds
2004-11-17 16:16         ` Alan Cox
2004-11-17 17:59           ` Linus Torvalds
2004-11-17 21:11           ` Jesper Juhl
2004-11-16 15:38 ` James Morris
2004-11-18  1:04 ` David Schwartz
2004-11-18  2:12   ` Kyle Moffett
2004-11-18  2:50     ` Dmitry Torokhov
2004-11-18  3:11       ` Kyle Moffett
2004-11-18  4:54         ` Dmitry Torokhov
2004-11-18 15:46         ` David Schwartz

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=87y8h08mgv.fsf@sanosuke.troilus.org \
    --to=mdpoole@troilus.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@discworld.dyndns.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