Re: Permission to use portions of the recent GNU Emacs Manual
Florian Weimer <fw(a)deneb.enyo.de> writes:
* David Kastrup:
> d) is it a good idea to change a large body of free software (like
> the GNU Emacs manual) to a different licence when it is well-known
> that substantial forks exist for which no licence change is
> possible, not least of all because the fork does not have the
> permission of the FSF to change the licence for old derived
> material to the GFDL, even in the case (which is not the current
> case) that they'd wanted to do it?
d) doesn't apply to the situation which sparked this discussion
because the Emacs manual hasn't been released under the GPL. If the
XEmacs manual is GPLed, it's not a fork of the Emacs manual, because
the Emacs manual licensing terms have been GPL-incompatible since at
least 1992, probably even longer.
So what is the actual situation with the licence of the XEmacs manual?
What kind of licensing are they _free_ to place on the XEmacs manual
without the possibility of XEmacs contributors vetoing that decision?
This would give us some sort of idea whether the requirements of the
XEmacs team can be accommodated in a manner that is not equivalent to
returning to the old licensing conditions completely.
The widely held belief that the GFDL relicensing of the Emacs manual
introduced the GPL incompatibility (and invariant sections) is
wrong.
Well, ok, so we just substituted one idea I don't like with another
one. So what terms in the old licence were GPL-incompatible?
And, putting back the XEmacs manual problem for a moment, do we have a
reasonable chance to place the GPL on the manual source code in a
sensible way, without causing insurmountable problems for printed
manuals?
I'd think that the problems with printed manuals from GPLed source
might be somewhat similar to the problems with embedded controllers
based upon GPLed source: in both cases the usual end product is used
without accessing the source. There is a difference, though: in the
case of the manual, the usual customer will _benefit_ from a
machine-readable source code copy since he can then use text search
and indexing and similar.
Since this problem does not seem restricted to GNU Emacs and its
printed manual, is there a more appropriate list where we could try
discussing how to cope with the general problem that gets exhibited
here?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum