Re: RFC: xemacsweb - XEmacs vs. GNU Emacs

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 &amp;lt;stephen(a)xemacs.org&amp;gt; %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 &amp;lt;xemacs-beta(a)xemacs.org&amp;gt;&lt;/a&gt;, 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 &amp;lt;stephen(a)xemacs.org&amp;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."