11:13 a.m.
We've had a bunch of queries about "XEmacs vs. GNU Emacs" in the last
couple of months. It's time someone dusted off that page; here's my
hack at it. A reader's guide:
(0) Appointed myself author. I think that's appropriate since I don't
see how there can be a consensus on writing this page correctly.
I volunteer to be maintainer for it even if you can't stand the
way I write and insist that it be ghosted. :-)
(1) I substituted "Stallman" for "RMS" throughout. I'm more
comfortable with that, but would immediately revert if most people
preferred the initials.
Ditto "GNU Emacs" for "FSF" or "FSF Emacs". This one I
feel
stronger about. RMS really gets his back up about it.
(2) Substantial but very tentative reorganization of "The XEmacs Point
of View" according to functional lines. Some updates to recent
versions of XEmacs and FSFmacs. Questions I know I need answers
to marked "####" in HTML comments. I'm sure I slipped on some
other stuff.
(3) Added a "Community Participation" section to "The XEmacs Point
of View". Comments appreciated.
(4) Added a pretty turgid description of the "legal problem" as RMS
perceives it. It's a turgid topic.
(5) Added a bunch of sections describing some philosophical
differences (starting with "What Is the Role of the FSF?").
Seemed good when I wrote it, but the whole topic is flamebait.
Comments requested.
(6) Author's disclaimer. Seems required in context, but what to say?
here it comes, in .content format:
%title%
XEmacs vs. GNU Emacs
%author%
Stephen Turnbull <stephen(a)xemacs.org>
%main%
<h1>XEmacs vs. GNU Emacs</h1>
<p>There are currently irreconcilable differences in the views
about technical, programming, design and organizational
matters between Richard Stallman and the XEmacs development
team which provide little hope for a merge to take place in
the short-term future.
<p>If you have a comment to add regarding the merge, it is a
good idea to avoid posting to the newsgroups, because of the
very heated flamewars that often result. Mail your questions
to
<a href="mailto:xemacs-beta＠xemacs.org">xemacs-beta＠xemacs.org</a>
and
<a
href="mailto:bug-gnu-emacs＠prep.ai.mit.edu">bug-gnu-emacs＠prep.ai.mit.edu</a>.
<p>Many people have noticed the great difference in focus
between the two "Viewpoints" presented here, and also have
expressed confusion about the legal issues Stallman focuses
on. The final sections present some explanation and
interpretation regarding these FAQs.
<h2>Difference between XEmacs and GNU Emacs, from the XEmacs Point of
View</h2>
<p>This section is now quite dated. Much of it refers to GNU
Emacs 19 and XEmacs 20. However, the differences described
persist in the most recent versions of both Emacsen in some
form.
<h3>User-Visible Editing Features</h3>
<p>In XEmacs, images of arbitrary size can be embedded in a
buffer. (Soon available in GNU Emacs 21.)
<p>In XEmacs, variable width fonts work. (Soon available in
GNU Emacs 21.)
<p>The height of a line is the height of the tallest font on
that line, instead of all lines having the same height. (Soon
available in in GNU Emacs 21.)
<!-- #### Is this obsolete? -->
<p>XEmacs provides support for ToolTalk on systems that have
it.
<!-- #### Probably I should drop mention of DnD and xemacs-gtk? -->
Experimental support for drag-and-drop protocols is
provided from XEmacs 21.
<p>XEmacs can ask questions using popup dialog boxes. Any
command executed from a menu will ask yes/no questions with
dialog boxes, while commands executed via the keyboard will
use the minibuffer.
<p>XEmacs has a built-in toolbar. Four toolbars can actually
be configured: top, bottom, left, and right toolbars.
<p>XEmacs has vertical and horizontal scrollbars. Unlike in
GNU Emacs 19 (which provides a primitive form of vertical
scrollbar), these are true toolkit scrollbars. A look-alike
Motif scrollbar is provided for those who don't have
Motif. (Even for those who do, the look-alike may be
preferable as it is faster.)
<h3>General Platform Support</h3>
<p>If you're running on a machine with audio hardware, you can
specify sound files for XEmacs to play instead of the default
X beep. See the documentation of the function load-sound-file
and the variable sound-alist. XEmacs also supports the
network sound protocols NAS and EsounD.
<p>XEmacs 21 supports database protocols with LISP bindings,
currently including LDAP and PostgreSQL (21.2 only).
<p>XEmacs 20 and 21 support the Canna, Wnn, and SJ3 Japanese
input method servers directly, as well as through the X Input
Method (XIM) protocol. GNU Emacs 20 supports only the XIM
protocol. Both Emacsen support the Quail family of input
methods (implemented in LISP) for many languages.
<h3>LISP Programming</h3>
<p>From XEmacs 20 on, characters are first-class objects.
Characters can be converted to integers, but are not integers.
GNU Emacs 19, XEmacs 19, Mule 2.3 (an extensive patch to GNU
Emacs 18.55 and 19.x), and GNU Emacs 20 (incorporating Mule 3
and later Mule 4) represent them as integers.
<p>From XEmacs 20 on, the buffer is treated as an array of
characters, and the representation of buffer text is not
exposed to LISP. The GNU Emacs 20 functions like
buffer-as-multibyte are not supported.
<p>In XEmacs, events are first-class objects. GNU Emacs 19
represents them as integers, which obscures the differences
between a key gesture and the ancient ASCII code used to
represent a particular overlapping subset of them.
<p>In XEmacs, keymaps are first-class opaque objects. GNU Emacs 19
represents them as complicated combinations of association
lists and vectors. If you use the advertised functional
interface to manipulation of keymaps, the same code will work
in XEmacs, GNU Emacs 18, and GNU Emacs 19; if your code depends on
the underlying implementation of keymaps, it will not.
<p>XEmacs uses "extents" to represent all non-textual aspects
of buffers; GNU Emacs 19 uses two distinct objects, "text
properties" and "overlays", which divide up the functionality
between them. Extents are a superset of the functionality of
the two GNU Emacs data types. The full GNU Emacs 19 interface
to text properties and overlays is supported in XEmacs (with
extents being the underlying representation).
<p>Extents can be made to be copied into strings, and thus
restored by kill and yank. Thus, one can specify this
behavior on either "extents" or "text properties", whereas in
GNU Emacs 19 text properties always have this behavior and
overlays never do.
<h3>Packaged LISP Libraries</h3>
<p>Many more packages are provided standard with XEmacs than
with GNU Emacs 19 or 20.
<p>XEmacs 21 supports an integrated package management system
which uses EFS to download, then automatically install
prebuilt LISP libraries.
<h3>Window System Programming Interface</h3>
<p>XEmacs uses the MIT "Xt" toolkit instead of raw Xlib calls,
which makes it be a more well-behaved X citizen (and also
improves portability). A result of this is that it is
possible to include other Xt "Widgets" in the XEmacs window.
Also, XEmacs understands the standard Xt command-line
arguments.
<p>XEmacs supports Motif applications, generic Xt
(e.g. Athena) applications, and raw Xlib applications. An
XEmacs variant which supports GTK+ is available (but not yet
integrated to the main CVS branch), although code to take
advantage of the support is as yet scarce.
<p>An XEmacs frame can be placed within an "external client
widget" managed by another application. This allows an
application to use an XEmacs frame as its text pane rather
than the standard Text widget that is provided with Motif or
Athena.
<!-- #### This is new! -->
<h3>Community Participation</h3>
<p>Starting with XEmacs 20, joining the XEmacs development
team is simple. Mail to <a
href="mailto:xemacs-beta＠xemacs.org">XEmacs Developers
&lt;xemacs-beta(a)xemacs.org&gt;</a>, and you're in! (If you
<em>want</em> to be, of course. You're also welcome to just
post development-related questions and bug reports.) The GNU
Emacs development team and internal mailing lists are still by
invitation only.
<p>The "bleeding edge" of mainline XEmacs development is
available by <a href="http://cvs.xemacs.org">anonymous CVS</a>
as are some subsidiary branches (check out the xemacs-gtk
module for the latest in GUI features!)
<p>CVS commit authority is broadly dispersed. Recognized
maintainers of LISP libraries who are willing to maintain
XEmacs packaged versions automatically qualify for CVS
accounts for their packages.
<h2>The FSF Point of View</h2>
<p><a href="mailto:rms＠gnu.org">Richard Stallman</a>
writes:</p>
<blockquote>
<p>XEmacs is GNU software because it's a modified version of a
GNU program. And it is GNU software because the FSF is the
copyright holder for most of it, and therefore the legal
responsibility for protecting its free status falls on us
whether we want it or not. This is why the term "GNU XEmacs"
is legitimate.
<p>But in another sense it is not GNU software, because we
can't use XEmacs in the GNU system: using it would mean paying
a price in terms of our ability to enforce the GPL. Some of
the people who have worked on XEmacs have not provided, and
have not asked other contributors to provide, the legal papers
to help us enforce the GPL. I have managed to get legal
papers for some parts myself, but most of the XEmacs
developers have not helped me get them.
<p>XEmacs was possible because free software means that anyone
can change it and distribute a modified version. I have no
regrets about establishing this freedom for Emacs. Everyone
should have the freedom to change any program, and this is not
limited to changes that the original author likes.
<p>Many people have taken advantage of the freedom to change
GNU Emacs, over the last decade. Most of them were willing to
cooperate on integrating their changes into Emacs. XEmacs
arose as a separate forked version because some of the
developers--starting with Zawinski--were unwilling to do that.
<p>People should have the freedom to decide what to work on,
including the freedom to compete with the GNU project, but
it's a shame when they make that choice. The whole community
loses when someone chooses competition rather than
cooperation.
<p>But this is worse than competition--it is unfair
competition. The XEmacs developers can and do copy code they
like from Emacs. If I could copy the code I like from XEmacs
in the same way, at least the rivalry would be fair. But I
can't do that't, because substantial parts of XEmacs don't
have legal papers, or don't have known authors.
<p>As long as we cannot use XEmacs in the GNU system, the GNU
project has to make sure that Emacs is not left behind. In
other words, we have to behave like rivals too, even though we
wish there were no rivalry. When XEmacs developers try to
persuade people to use, test, fix and enhance XEmacs instead
of Emacs, the GNU project can't sit still; we need them to
use, test, fix and enhance Emacs instead.
<p>There is good code in XEmacs, which I'd be happy to have in
a merged Emacs any day. But I cannot copy it out of XEmacs
myself because of the uncertain authorship and/or lack of
legal papers.
<p>This problem could probably be resolved, at least for large
parts of XEmacs, with substantial help from the authors of
that code. Otherwise, the GNU project has to write or find
replacements for it.
<p>I invite people who like Emacs, and want the best possible
version of Emacs to be available for use in the GNU system, to
help in one way or the other.
</blockquote>
<!-- #### This really isn't source for the RMS quote. Obsolete?
Does anyone know where that came from? If not, this can go.
<p><strong>Sources:</strong> <a
href="http://www.xemacs.org/FAQ/">FAQ</a>
item 1.0.5, and XEmacs 21.0 NEWS file
-->
<h2>What Is the Legal Issue?</h2>
<p>There is no difference in the nature of the copyrights or
licenses of the two projects. Copyright is defined by law and
international treaty, and is automatically awarded to the
author as soon as a work is published. Both projects use the
GNU General Public License to protect their work while
providing it freely to the community.
<p>XEmacs has no choice, because much of its code is
copyrighted by the Free Software Foundation, and is only
available to XEmacs under the GPL. Under that license,
redistribution is only possible under the GPL. The GNU
Project uses the GPL as a matter of principle. (XEmacs
developers generally subscribe to a similar principle, of
course.) It is the same GPL, so sharing code is 100% legal.
<p>However, copyright is governed by the <em>civil</em> code,
not the criminal code. This means that the government takes
no interest in violations of copyright as such. It only
undertakes to provide law courts where the copyright can be
enforced. It is the responsibility of the copyright holder to
sue to prevent violations and receive damages for past
violations. The government <em>cannot</em> act on the
complaints of third parties.
<p>The FSF has received legal advice that a copyright holder
in a jointly-authored work is in a weak position to enforce
its copyright unless all coauthors participate in the legal
action. Evidently the FSF would be considered a third party
with respect to non-assigned code, weakening its ability to
defend the whole work. (Author's note: You'd have to ask a
lawyer why that might be so. I am not an expert, so I will
just assure you that some lawyers I have asked informally
agree that this theory is plausible, although it has not been
tested in court. It may also be more or less applicable in
jurisdictions other than the U.S.)
<p>Based on this advice, Stallman has concluded that
incorporating <em>some</em> code copyrighted by another entity
into a work such as Emacs puts the copyright of <em>all</em>
of the work at risk of being unenforceable in court in the
case of a violation. He has judged that this risk is
unacceptably large, and therefore insists that the whole
copyright of any software the FSF undertakes to defend be
assigned to the FSF, with few exceptions.
<h3>What Is the Role of the FSF?</h3>
<p>Stallman believes that copyright in software itself is
immoral; Copyleft is a device to undermine the whole idea. He
has little empathy for people who wish to retain
copyright---after all, he has given up his own. This is the
fundamental idea behind the FSF (as opposed to the GNU
Project, which actually develops software): a holding company
for all the software copyrights that shouldn't even exist in
the first place. According to the legal argument above, such
a trust is necessary to defend the GPL, which is what prevents
proprietary firms from misappropriating the software at the
same time as it prevents the holding company (the FSF) from
being a monopoly.
<h2>Well, Isn't That Paranoid?</h2>
<p>Many developers think so, but it seems that noone who holds
a different theory has retained a lawyer to check the
precedents. The FSF has done so, so its position must be
considered most credible.
<p>Also, it is important to remember that Stallman and the FSF
are not (in this context) acting as software developers. Rather,
they perceive themselves as guardians of a social movement.
Their responsibility is not to any one application or project,
but to the whole GNU system. For that reason as well, a
conservative approach can be justified.
<h2>Don't the XEmacs Developers Care?</h2>
<p>Of course we do. But even if we haven't consulted a
lawyer, we have the right to judge the risks to our own
product. Most of us consider it low. Furthermore, many
XEmacs developers take a different approach to the free
software movement itself, and so will differ from GNU/FSF
policy. The code <em>we</em> write will remain free. What we
are possibly losing is the ability to <em>force others</em> to
make their modifications free. This is central to the GNU
Project because it is a social movement. To many developers
as individuals, it is not so crucial.
<p>This also shows why the "Viewpoints" are so different in
style. XEmacs developers consider their project from a
technical point of view, and prefer it for technical reasons.
They see their contributions to the free software movement as
stemming from their development and publication of code.
Stallman, and the FSF, consider their primary role to be more
politically and socially oriented. Thus social and legal
issues come to the fore.
<h2>Fear of Forking Considered Harmful</h2>
<p>Many XEmacs developers do not consider having multiple
implementations of some features a bad thing. The original
Lucid fork arose, as Stallman writes, because the Lucid
developers (primarily Jamie Zawinski) would not "cooperate" in
merging the Lucid code into the GNU mainline. What Stallman
does not mention is that in his vision of "cooperation" the
Lucid developers would be working under <em>his</em> direction
to merge those features that <em>he</em> wanted, making
changes to <em>their</em> code as <em>he</em> directed. This
is obvious, when you think about it; of course Stallman was
the head of the GNU Emacs project, and would reserve the right
to make final decisions. Nor is it surprising that the Lucid
developers refused. They had egos, of course.
<p>But there were also those "irreconcilable technical
differences." Both Lucid Emacs and GNU Emacs 19 were excellent
editors, but in their different ways. The Lucid developers
honestly considered GNU Emacs 19, and the merge as outlined by
Stallman, to be broken in some important ways. He, just as
honestly, considered many of the changes the Lucid developers
demanded to be broken, or at best to be fixing what wasn't
broken. A fork was inevitable. That's what free software is
for, among other things: the right to fix what's broken, and
redistribute the improvements.
<p>And a little competition may be good for you! Without the
fork, GNU Emacs 20 <em>might</em> not have added Mule, and GNU
Emacs 21 might <em>not</em> have the GUI redisplay. Who knows
when GNU Emacs will get a library packaging system? All of
these features were successfully pioneered by Lucid Emacs or
XEmacs, at times when Stallman considered them broken,
irrelevant, or low priority. Conversely, not only is XEmacs
based on GNU Emacs; part of the development effort includes
regular synchronization of features and implementations with
the mainline versions.
<p>Of course, we all think it is best when all the good code
that results can be shared:
<blockquote>
All Emacs developers are free software developers.
</blockquote>
<p>But whether or not it <em>can</em> be shared is a matter of
point of view. On a question quite extraneous to the
development process itself: how much the legal system hinders
you from effectively protecting your copyright when you
cooperate with someone unwilling to give up their copyright.
<!-- #### This next probably should go or be cut way down.
Just taking out my frustrations! -->
<h2>Author's Disclaimer</h2>
<p>I disagree strongly with the Stallman/FSF position in many
respects. However, I have tried to present the facts of the
legal issue as objectively as possible, and have some hope I
succeeded. The interpretation of why XEmacs developers as a
group do not worry about this legal issue is my own; the most
I can say is nobody on the developer's mailing list has
complained about it.
<p>Statements about what Richard Stallman believes, judges,
concludes, and so on should be taken with a grain of salt.
Nobody in their right mind, except Stallman, would pretend to
speak for him. I have found certain conjectures useful for
establishing a coherent interpretation of his actions and
statements, and have taken the liberty of making them
available to you. (Go read the NO WARRANTY section of the
GPL!)
<!-- #### This definitely will go. But isn't "pusillanious"
a wonderful word? -->
<p>Ben Wing probably thinks this is pusillanimous. I don't
care. There are plenty of venues where you can read endless
flames on these issues; with a little effort, you can probably
find some of mine. (I wouldn't bother.)
<address>
Stephen J. Turnbull &lt;stephen(a)xemacs.org&gt;
</address>
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."