From: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: xemacs-beta@xemacs.org, emacs-devel@gnu.org
Subject: Re: Permission to use portions of the recent GNU Emacs Manual
Date: Fri, 17 Dec 2004 14:36:18 +0900 [thread overview]
Message-ID: <87fz25bi5p.fsf@tleepslib.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <m1Ceide-0004QaC@rattlesnake.com> (Robert J. Chassell's message of "Wed, 15 Dec 2004 23:32:58 +0000 (UTC)")
>>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:
Robert> It is not merely picturesque rhetoric, it is true: you do
Robert> not have to spend all your time supporting freedom to be a
Robert> fellow who helps others. In the case of software, you can
Robert> do this by choosing a license.
Excuse me? Richard just denied exactly that possibility to us, in
<E1CctyU-0007l0-D7@fencepost.gnu.org>. In general, authors of
derivatives of works licensed under strong copyleft have _no_ choice.
I can choose not to distribute my work on XEmacs, but _the FSF_ chose
XEmacs's licenses many years ago, leaving _me_ with _no_ choice[1] of
license. That's what strong copyleft is all about, removing certain
freedoms in order to protect certain other freedoms, deemed to be of
overriding importance. IIRC, the FSF openly acknowledges this on the
GNU web site among other places. It's a reasonable compromise, but it
is compromise.
XEmacs's documentation problem is simply "collateral damage" in the
FSF's war against proprietary abuses. Richard says "too bad." It's a
clear inconvenience for us, and he could have been more gracious, but
he's exactly right. It is both undesirable and unavoidable.
Robert> and suggested, although he did not say so, that choosing a
Robert> good license, and dealing with legal paperwork, takes a
Robert> great deal of time.
You are correct that I did not say so. However, I did not suggest
that choosing a license takes time. I suggested that dealing with a
license chosen by someone else does. That's what this thread is
about, at least for everyone who has posted except you.
Robert> But that is not true. He framed the issue erroneously.
Wrong. You are trying to switch discussion from the difficulties of
dealing with someone else's license to the simplicity of choosing your
own. That doesn't make my framing of _my_ issue erroneous.
[...]
Robert> which means that XEmacs depends on `security by
Robert> obscurity'. This means that if XEmacs becomes widely
No "if", at least not if GNU Emacs is the standard of "widely used."
;-)
Robert> used, this policy may cause unanticipated trouble.
Wrong again. I am satisfied with the XEmacs strategy as I understand
it because I believe that there is no security, period. The SCO case
proves that. SCO did not attack "code of dubious provenance"; they
went after IBM's well-documented contribution. If the meanest patent
shark in the ocean, IBM, doesn't know what "good papers" look like,
who does? Therefore I do not worry about "unanticipated" technical
trouble when the bad guys simply resort to brute force---lies, FUD and
expensive lawyers---rather than anything resembling legal reasoning.
"The Internet interprets censorship as damage, and routes around it."
Similarly, our (implicit) strategy is to interpret copyright claims as
damage, and to code around it. (We already have to do that, with the
Emacs documentation. With friends like these ... well, I'll take such
friends any day---and ask them to stop plinking BBs at my foot.)
Risky strategy? Of course. The FSF's strategy is less risky, but not
a sure thing. (For example, it is always vulnerable to attack via a
completely independent patent on any technology it implements.) In
return for risk reduction in the long run, it does, however, involve
known and certain damage to the interests of some free software users
and developers in the short run. A reasonable compromise---as is
ours. Any ecologist will tell you that monoculture itself is risky.
Vive la difference! Let Freedom ring![2]
In the next paragraphs,
A = practical difficulty of changing license of community-owned
software
B = incompatibility of GPL and GFDL
dak> However, A is in some manner an outgrowth of problem B,
dak> and if we got B solved in a satisfactory way, it might mean
dak> that XEmacs developers (like everybody else) would need to
dak> adapt at most _one_ more time.
Robert> Maybe. But more likely more than one more time.
Doesn't worry me. The big Problem A XEmacs faces with the FSF's old
Emacs documentation license (aka the current XEmacs documentation
license) is that it is unnamed and unversioned. Satisfactory
resolution of B will involve a named versioned license so that a
permission statement of the form "may be redistributed under the GNU
Perfected License, version 1.0 or later, at your option" can be used.
Robert> There is reason to separate the GFDL from the GPL.
IMO, this is very short-sighted. Several hackers have pointed out the
convergence between code and documentation as exemplified by uh, well,
GNU Emacs itself. Don't forget "literate programming". The library
association's brief in the Eldridge case points out the importance of
cut and paste in compilations of existing documents. I have musician
and film acquaintances who wish to have the same freedom to borrow the
recordings of others that I have to borrow the code of GNU Emacs. I'm
sure there are classes of information that you and I would intuitively
agree are "not software" that I have not yet considered.
I don't see why they shouldn't all benefit from the same definition of
freedom as software.
There simply is no reason not to use the GPL, perhaps in a slightly
modified version to avoid referring to documentation as "the Program",
etc, except for reasons of encouraging commerce.[3][4] Those reasons
apply with equal force to software, yet in the case of software are
rejected most vehemently by exactly the folks who insist that the GFDL
is a free license. A rather unappealing combination.
dak> All of those choices don't look very appealing.
Robert> I agree. It is not an appealing world. And it is getting
Robert> worse.
It's always darkest before the dawn. When Milton Friedman and Kenneth
Arrow can sign the same amicus brief for Eldridge, there is hope.
Footnotes:
[1] Yes, I have the option of delegating that choice to the FSF, and
in fact I have done so. This eliminates the problem of
incompatibility between GNU Emacs and XEmacs licenses for my own
contributions, but still leaves me with _no choice of license_.
[2] Sorry, David, but I do so love my own picturesque rhetoric.
[3] Albeit on better terms than the "sorry for the legalese, but the
net effect is that copying without explicit permission is forbidden"
that graces O'Reilly's _X Window System_ series.
[4] Of course there are clauses of the GFDL that deal with issues
like "technical means to prevent copying". But it has long been
recognized that the GPL needs to be amended to deal with those issues,
and the GFDL's terms are arguably problematic.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
next prev parent reply other threads:[~2004-12-17 5:36 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 [this message]
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=87fz25bi5p.fsf@tleepslib.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.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).