From: "Robert J. Chassell" <bob@rattlesnake.com>
Subject: Re: Permission to use portions of the recent GNU Emacs Manual
Date: Wed, 15 Dec 2004 23:32:58 +0000 (UTC) [thread overview]
Message-ID: <m1Ceide-0004QaC@rattlesnake.com> (raw)
In-Reply-To: <x5hdmnl3gj.fsf@lola.goethe.zz> (message from David Kastrup on Wed, 15 Dec 2004 21:19:08 +0100)
Anyway, could we keep off the picturesque rhetoric?
It is not merely picturesque rhetoric, it is true: you do not have to
spend all your time supporting freedom to be a fellow who helps others.
In the case of software, you can do this by choosing a license.
Stephen J. Turnbull said
... free software advocacy is only part of my life ...
and suggested, although he did not say so, that choosing a good
license, and dealing with legal paperwork, takes a great deal of time.
But that is not true. He framed the issue erroneously.
We have two different problems:
A) Emacs changed its manual licence from the old licence to the GFDL,
and XEmacs can't or does not want to easily follow suit without
contacting _their_ contributors.
Right. Andy Piper said that
XEmacs explicitly does not collect papers because we believe that
hinders development of the product.
which means that XEmacs depends on `security by obscurity'. This
means that if XEmacs becomes widely used, this policy may cause
unanticipated trouble.
B) Both the old as well as the new Emacs manual licence are
GPL-incompatible and thus present problems for integrating work
on the manual and the code for derived works that are not
copyrighted all by the same legal entity.
That might be true. On the other hand, it might not -- waking up in
the middle of the night, I realized that the legal right to modify
that is inherent in both the GNU GPL and the GFDL may make it legal to
integrate work between the two. I am not a lawyer and I don't know.
In my remarks I have been focusing on the invariant issues, the
`freedoms from', rather than on the `freedoms to'. But the `freedoms
to' are also important. I cannot tell you one way or the other.
(As far as I am concerned, this is a bug, and I am glad you showed it
to me. Like the GNU GPL, the GFDL should be understandable by lay
people with only a little legal knowledge and not much patience. It
is not.)
It would appear to me that "A" is not something that we can reasonably
deal with in isolation: if we accompany every change of the licence of
the Emacs manual with an exception for old times' sakes, there is no
point in changing the licence in the first place.
True.
However, A is in some manner an outgrowth of problem B, and if we got
B solved in a satisfactory way, it might mean that XEmacs developers
(like everybody else) would need to adapt at most _one_ more time.
Maybe. But more likely more than one more time. That is because of
the people who think that software and its documentation should be
restricted. They will not `leave well enough alone'. They will do
something that forces us to react.
If, for example, the GPL depends on copyright, then anti-GPL people
will say, get rid of copyright for software! (There is an effort to
do just this in the US.) Companies such as Microsoft own thousands of
patents. Patents enable worse restrictions than copyright. (There is
an effort to introduce software patents into Europe, even though the
European parliament has voted against them.)
Moreover, some of people who are against software freedom can can
readily afford to fund think tanks, books, legal cases, patents,
lobbying, and FUD. An anti-free software person who has the money
need not spend his time on the issue. This means the conflict will be
ongoing.
And then there are mistakes on our side. As you say, there is
... no reason to cheer the good guys when they are shooting
themselves and their friends in the foot.
The GNU GPL took a long time to become accepted. The language for it
sometimes failed. It is like RMS still calling Emacs an editor, when
it is an integrated computational environment that offers editing
facilities, just as BASH offers editing facilities in VIM or KDE
offers them in Koffice.
There are failures on several sides. People like me not explaining
well enough. RMS not explaining well enough.
Another group are people like Andy Piper, who said
I highly doubt that anyone in the real world actually cares
anymore.
which suggests that all this licensing activity is a waste of time. I
do not know how to talk to people like Andy.
The question is how you view the world: do you figure that the
non-programmers you must deal with are entirely, rather than mostly,
helpful and friendly? Or do you figure that a few are not so good?
I am talking to people who think the latter, but not the former.
Or do you avoid thinking about non-programmers with reference to
programming? I don't know how to talk with such people since I look
on licenses as an interface to non-programmers.
On the long run, I'd hope that the next version of the GPL would
become suitable to cover the generated of printed manuals in a
satisfactory way without the need for a separate licence.
I would like that. But I am not sure it is legally possible or
rhetorically useful. After all, the purpose of the GFDL is to ensure
more freedom over all, and `freedom from' monopolies by permitting
certain publishers a limited `freedom to'. That kind of attempted
balancing does not occur in the GNU GPL.
Put another way, you seldom buy a book for its paper, you buy it for
what specifically is printed in it. Books are sold for their content
(not, as the jokes have it, for their covers; people are influenced by
covers because they expect them to indicate content). On the other
hand, a computer is sold for its hardware, not for its software.
There is reason to separate the GFDL from the GPL.
(As for embedded systems: it may be hard to change the software in an
embedded computer system like one in a car, but it is easy to change
the software in its parent computer. Embedded computer systems are
not like books; they are not sold for their contained software. On
the other hand, their software is more permanent than in desktop
computers. So embedded systems form yet another category although
linked to its parents.)
All of those choices don't look very appealing.
I agree. It is not an appealing world. And it is getting worse.
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
next prev parent reply other threads:[~2004-12-15 23: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 [this message]
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
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=m1Ceide-0004QaC@rattlesnake.com \
--to=bob@rattlesnake.com \
/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).