From: David Kastrup <dak@gnu.org>
Cc: rms@gnu.org, xemacs-beta@xemacs.org, emacs-devel@gnu.org,
bob@rattlesnake.com, stephen@xemacs.org, andy@xemacs.org,
Ben Wing <ben@666.com>
Subject: Re: Permission to use portions of the recent GNU Emacs Manual
Date: Sun, 19 Dec 2004 22:32:20 +0100 [thread overview]
Message-ID: <x5652y0yaj.fsf@lola.goethe.zz> (raw)
In-Reply-To: <200412191810.21569.pogonyshev@gmx.net> (Paul Pogonyshev's message of "Sun, 19 Dec 2004 18:10:21 +0200")
Paul Pogonyshev <pogonyshev@gmx.net> writes:
> David Kastrup wrote:
>> b) why it would be technically impossible for you to change the XEmacs
>> manual licence to the GFDL: it does not seem like you have handed out
>> any written assurances that the licence is never going to change.
>
> I think because contributing a piece of work implicitly means that you
> agree to distribute it under the _current_ license.
Whose theory is that? I don't see any of it in copyright law, and I
don't see any of it in the GPL. This sounds suspiciously like the
"viral licence" theories where a contact with GPLed software magically
makes all of your software free for the taking.
This is simply not true. To have software GPLed, you need to
explicitly licence it that way, regardless of whether it has come in
contact with other GPLed software or not. Only if it has, you must
not redistribute a combined product under a different licence. But
there is no automatic remedy involved: you always have _several_
choices to come into compliance: licence the whole under GPL, or
replace the GPLed parts by something different, or stop distributing
it.
> So, to relicense a piece of contributed work, you need an agreement
> from the author, either got in advance (like FSF copyright
> assignment includes) or got right before the license change.
To "relince" something it must have been licensed in the first place.
> Since XEmacs has many contributors who hold their copyright, this
> means that license switch would require collecting agreements from
> all of them, which might be practically impossible.
Well, this "practical impossibility" is exactly what Emacs development
has to put up with: collecting agreements from all contributors.
> That said, I agree with you that this is mostly an XEmacs problem,
> largely caused by their policy of not collecting copyright
> assignments.
It is not only collection of a copyright assignment (which makes
relicensing possible). As far as I can see, their process does not
involve even getting _any_ formal licence to use the work.
As long as they are just relying on contributors playing nice with
them in case of necessity (and GPL v2 is going to be replaced with GPL
v3 at one time, too, and that will probably also mean that XEmacs has
to follow suit at one time), they might as well see how the
contributors will react to a licence change.
> The situation is not nice, but I don't see why FSF should go against
> its decision and its policies. As Robert Chassell said (or meant),
> FSF cannot ask other to use GFDL if it doesn't use it itself. After
> all, XEmacs isn't fully cooperative either, since FSF won't merge in
> non-assigned code.
Which is the FSF's choice. The difference is that XEmacs has decided
not to bother about assignments and stuff, and due to that decision
they don't have such a general cooperation to offer in a manner useful
for Emacs. In contrast, the FSF still has the choice to licence the
Emacs manual under different free licences because they bothered about
the assignment, and they bother about licences.
So the FSF, in contrast to XEmacs, has retained the technical
possibility to "cooperate" (namely abandon the business of trying to
choose a licence of their own and instead let the terms be determined
by XEmacs' different processes), simply because they have been more
careful.
I have yet to see a good reason why this should be necessary (I don't
think the "contributions are automagically licenced from the
contributor to the potential redistributor without explicit agreement
like the rest is" theory holds much legal merit) as well as desirable.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2004-12-19 21:32 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 22:28 Permission to use portions of the recent GNU Emacs Manual Ben Wing
2004-12-10 23:14 ` Richard Stallman
2004-12-11 0:59 ` Ben Wing
2004-12-11 1:06 ` Miles Bader
2004-12-11 10:27 ` Alan Mackenzie
2004-12-11 18:19 ` Eli Zaretskii
2004-12-11 20:43 ` David Kastrup
2004-12-11 19:02 ` Stefan Monnier
2004-12-12 0:26 ` Karl Fogel
2004-12-12 8:57 ` David Kastrup
2004-12-12 16:56 ` Brian Palmer
2004-12-12 13:31 ` Matthew Mundell
2004-12-12 13:40 ` David Kastrup
2004-12-12 2:03 ` Robert J. Chassell
2004-12-12 4:59 ` Karl Fogel
[not found] ` <m1CdWGG-0004R2C@rattlesnake.com>
2004-12-12 17:43 ` David Kastrup
2004-12-12 18:39 ` Florian Weimer
2004-12-12 19:24 ` David Kastrup
2004-12-12 19:49 ` Florian Weimer
2004-12-12 19:43 ` Robert J. Chassell
2004-12-12 19:59 ` David Kastrup
2004-12-12 20:46 ` Robert J. Chassell
2004-12-12 21:00 ` Andy Piper
2004-12-13 1:59 ` Robert J. Chassell
2004-12-13 2:23 ` David Kastrup
2004-12-13 12:34 ` Thien-Thi Nguyen
2004-12-13 16:53 ` Robert J. Chassell
2004-12-15 14:23 ` Stephen J. Turnbull
2004-12-15 19:14 ` Robert J. Chassell
2004-12-15 20:19 ` David Kastrup
2004-12-15 23:32 ` Robert J. Chassell
2004-12-17 5:36 ` Stephen J. Turnbull
2004-12-15 23:20 ` Richard Stallman
2004-12-16 10:58 ` David Kastrup
2004-12-16 12:18 ` Eli Zaretskii
2004-12-16 12:29 ` Kim F. Storm
2004-12-17 0:53 ` Richard Stallman
2004-12-18 10:20 ` Ben Wing
2004-12-18 23:32 ` Miles Bader
2004-12-19 6:31 ` Ben Wing
2004-12-19 6:32 ` Ben Wing
2004-12-19 13:54 ` Robert J. Chassell
2004-12-19 15:40 ` David Kastrup
2004-12-19 16:10 ` Paul Pogonyshev
2004-12-19 21:32 ` David Kastrup [this message]
2004-12-19 23:48 ` Paul Pogonyshev
2004-12-20 8:07 ` David Kastrup
2004-12-20 14:05 ` Robert J. Chassell
2004-12-20 0:19 ` Ben Wing
2004-12-20 7:20 ` David Kastrup
2004-12-20 10:58 ` Stephen J. Turnbull
2004-12-20 10:56 ` Richard Stallman
2004-12-20 12:47 ` David Kastrup
2004-12-17 1:32 ` Stephen J. Turnbull
2004-12-12 4:39 ` Richard Stallman
2004-12-12 6:16 ` Stefan Monnier
2004-12-12 21:28 ` Eli Zaretskii
2004-12-12 21:43 ` David Kastrup
2004-12-13 2:22 ` Robert J. Chassell
2004-12-13 6:48 ` Brian Palmer
2004-12-13 10:05 ` David Kastrup
2004-12-13 17:44 ` Bruce Stephens
2004-12-14 13:09 ` Stephen J. Turnbull
2004-12-14 2:56 ` Karl Fogel
2004-12-14 14:16 ` Robert J. Chassell
2004-12-13 4:23 ` Dhruva
2004-12-13 19:51 ` Richard Stallman
2004-12-13 20:03 ` David Kastrup
2004-12-14 10:03 ` Per Abrahamsen
2004-12-14 10:14 ` David Kastrup
2004-12-14 14:09 ` Robert J. Chassell
2004-12-14 14:25 ` David Kastrup
2004-12-14 20:19 ` Robert J. Chassell
2004-12-14 22:09 ` David Kastrup
2004-12-15 0:12 ` Robert J. Chassell
2004-12-15 8:03 ` Per Abrahamsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x5652y0yaj.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=andy@xemacs.org \
--cc=ben@666.com \
--cc=bob@rattlesnake.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--cc=stephen@xemacs.org \
--cc=xemacs-beta@xemacs.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).