From turnbull at sk.tsukuba.ac.jp Sun Feb 26 16:42:15 2017 Content-Type: multipart/mixed; boundary="===============3733705948505611058==" MIME-Version: 1.0 From: Stephen J. Turnbull To: xemacs-beta at xemacs.org Subject: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-12 19:13:33 +0900 Message-ID: <14821.36557.295756.684110@turnbull.sk.tsukuba.ac.jp> --===============3733705948505611058== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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%

XEmacs vs. GNU Emacs

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.

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 = xemacs-beta(a)xemacs.org and bug-gnu-emacs(a)prep.ai= .mit.edu.

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.

Difference between XEmacs and GNU Emacs, from the XEmacs Point of View=

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.

User-Visible Editing Features

In XEmacs, images of arbitrary size can be embedded in a buffer. (Soon available in GNU Emacs 21.)

In XEmacs, variable width fonts work. (Soon available in GNU Emacs 21.)

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.)

XEmacs provides support for ToolTalk on systems that have it. Experimental support for drag-and-drop protocols is provided from XEmacs 21.

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.

XEmacs has a built-in toolbar. Four toolbars can actually be configured: top, bottom, left, and right toolbars.

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.)

General Platform Support

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.

XEmacs 21 supports database protocols with LISP bindings, currently including LDAP and PostgreSQL (21.2 only).

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.

LISP Programming

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.

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.

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.

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.

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).

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.

Packaged LISP Libraries

Many more packages are provided standard with XEmacs than with GNU Emacs 19 or 20.

XEmacs 21 supports an integrated package management system which uses EFS to download, then automatically install prebuilt LISP libraries.

Window System Programming Interface

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.

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.

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.

Community Participation

Starting with XEmacs 20, joining the XEmacs development team is simple. Mail to XEmacs Developers <xemacs-beta(a)xemacs.org>, and you're in! (If you want 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.

The "bleeding edge" of mainline XEmacs development is available by anonymous CVS as are some subsidiary branches (check out the xemacs-gtk module for the latest in GUI features!)

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. =

The FSF Point of View

Richard Stallman writes:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

What Is the Legal Issue?

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.

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.

However, copyright is governed by the civil 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 cannot act on the complaints of third parties.

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.)

Based on this advice, Stallman has concluded that incorporating some code copyrighted by another entity into a work such as Emacs puts the copyright of all 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.

What Is the Role of the FSF?

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.

Well, Isn't That Paranoid?

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.

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.

Don't the XEmacs Developers Care?

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 we write will remain free. What we are possibly losing is the ability to force others 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.

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.

Fear of Forking Considered Harmful

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 his direction to merge those features that he wanted, making changes to their code as he 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.

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.

And a little competition may be good for you! Without the fork, GNU Emacs 20 might not have added Mule, and GNU Emacs 21 might not 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.

Of course, we all think it is best when all the good code that results can be shared:

All Emacs developers are free software developers.

But whether or not it can 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.

Author's Disclaimer

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.

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!)

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.)

Stephen J. Turnbull <stephen(a)xemacs.org>
-- = 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." --===============3733705948505611058==-- From ben at 666.com Sun Feb 26 16:42:17 2017 Content-Type: multipart/mixed; boundary="===============6776603235824799099==" MIME-Version: 1.0 From: Ben Wing To: xemacs-beta at xemacs.org Subject: Re: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-17 23:56:04 -0700 Message-ID: <39ED4984.ADE574F0@666.com> In-Reply-To: 14821.36557.295756.684110@turnbull.sk.tsukuba.ac.jp --===============6776603235824799099== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable hello there. awhile ago the faq had a link to something i wrote going into this in more detail. steve removed it without consulting me, probably because he consid= ered it incendiary and was trying to cooperate with rms on merging [futilely, of course]. thus he deleted all advocacy on our side; thus the "pusillanimous" commentary from jamie. some time more recently, i rewrote my opinion piece; here it is. obviously i am not objective, but i think it's important to ha= ve an "our side" piece to match rms's "their side" piece that we include. ---------------------------------------------------------------------------= ------------ Many people look at the split between GNU Emacs and XEmacs and are convinced that the XEmacs team is being needlessly divisive and just needs to coopera= te a bit with RMS, and the two versions of Emacs will merge. In fact there have = been six to seven major attempts at merging, each running hundreds of messages l= ong and all of them coming from the XEmacs side. All have failed because they h= ave eventually come to the same conclusion, which is that RMS has no real inter= est in cooperation at all. If you work with him, you have to do it his way -- "= my way or the highway". Specifically: 1. RMS insists on having legal papers signed for every bit of code that goes into GNU Emacs. RMS's lawyers have told him that every contribution over ten lines long requires legal papers. These papers cannot be filled out over to= the web but must be done so in person and mailed to the FSF. Obviously this by itself has a tendency to inhibit contributions because of the hassle factor. Furthermore, many people (and especially organizations) are either hesitant= to or refuse to sign legal papers, for reasons mentioned below. Because of th= ese reasons, XEmacs has never enforced legal signed papers for the code in it. = Such papers are not a part of the GPL and are not required by any projects other= than those of the FSF (for example. Linux does not require such papers). Since w= e do not know exactly who is the author of every bit of code that has been contributed to XEmacs in the last nine years, we would essentially have to rewrite large sections of the code. The situation however, is worse than th= at because many of the large copyright holders of XEmacs (for example Sun Microsystems) refuse to sign legal papers. Although they have not stated th= eir reasons, there are quite a number of reasons not to sign legal papers: 1. By doing so you essentially give up all control over your code. You can = no longer release your code under a different license. If you want to use your= code that you've contributed to the FSF in a project of your own, and that proje= ct is not released under the GPL, you are not allowed to do this. Obviously, large companies tend to want to reuse their code in many different projects and a= s a result feel very uncomfortable about signing legal papers. 2. One of the dangers of assigning copyright to the FSF is that if the FSF happens to be taken over by some evil corporate identity or anyone with different ideas than RMS, they will own all copyright-assigned code, and can revoke the GPL and enforce any license they please. If the code has many different copyright holders, this is much less likely of a scenario. 2. RMS does not like abstract data structures. Abstract data structures are= the foundation of XEmacs and all other modern programming projects. It is diffi= cult to impossible to write maintainable and expandable code without using abstr= act data structures. In merging talks with RMS he has said we can have any abst= ract data structures we want in a merged version but must allow direct access to= the implementation as well, which defeats the primary purpose of having abstract data structures. 3. RMS is very unwilling to compromise when it comes to divergents implementations of the same functionality which is very common between XEma= cs and GNU Emacs. Rather than taking the better interface on technical grounds= , RMS insists that both interfaces must be implemented in C at the same level (ra= ther than implementing one in C and the other on top if it), so that code that u= ses either interface is just as fast. This means that the resulting merged Emacs would be filled with a lot of very complicated code to simultaneously suppo= rt two divergent interfaces, and would be difficult to maintain in this state. 4. RMS's idea of compromise and cooperation is almost purely political rath= er than technical. The XEmacs maintainers would like to have issues resolved by examining them technically and deciding what makes the most sense from a technical prospective. RMS however, wants to proceed on a tit for tat kind = of basis, which is to say, "If we support this feature of yours, we also get to support this other feature of mine." The results of such a process is typic= ally a big mess, because there is no overarching design but instead a great deal= of incompatible things hodgepodged together. If only some of the above differences were firmly held by RMS, and if he we= re willing to compromise effectively on the others and to demonstrate willingn= ess to work with us on the issues that he is less willing to compromise on, we = might go ahead with the merge despite misgivings. However RMS has shown no real interest at all in compromising. He has never stated how all of the redunda= nt work that would be required to support his preconditions would get done. It= 's unlikely that he would do it all and it's certainly not clear that the XEma= cs project would be willing to do it all, given that it is a tremendous amount= of extra work and the XEmacs project is already scrapped for coding resources.= (Not to mention the inherent difficulty in convincing people to redo existing wo= rk for primarily political reasons.) In general the free software community is quite strapped as a whole for coding resources; duplicative efforts amount = to very little positively and have a lot of negative effects in that they take= away what few resources we do have from projects that would actually be useful. RMS however, does not seem to be bothered by this. He is more interested in sticking firm to his principles, though the heavens may fall down, than in working forward to create genuinely useful software. It is abundantly clear= that RMS has no real interest in unity except if it happens to be on his own ter= ms and allows him ultimate control over the result. He would rather see nothing happen at all than something that is not exactly according to his principle= s. The fact that few, of any, if any people share his principles is meaningles= s to him. "Stephen J. Turnbull" wrote: > = > 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% >

XEmacs vs. GNU Emacs

> = >

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. > = >

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 > xemacs-beta(a)xemacs.= org > and > bug-gnu-emacs(= a)prep.ai.mit.edu. > = >

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. > = >

Difference between XEmacs and GNU Emacs, from the XEmacs Poin= t of View

> = >

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. > = >

User-Visible Editing Features

> = >

In XEmacs, images of arbitrary size can be embedded in a > buffer. (Soon available in GNU Emacs 21.) > = >

In XEmacs, variable width fonts work. (Soon available in > GNU Emacs 21.) > = >

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.) > = > >

XEmacs provides support for ToolTalk on systems that have > it. > >

Community Participation

> = >

Starting with XEmacs 20, joining the XEmacs development > team is simple. Mail to href=3D"mailto:xemacs-beta(a)xemacs.org">XEmacs Developers > <xemacs-beta(a)xemacs.org>, and you're in! (If you > want 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. > = >

The "bleeding edge" of mainline XEmacs development is > available by anonymous CVS > as are some subsidiary branches (check out the xemacs-gtk > module for the latest in GUI features!) > = >

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. > = >

The FSF Point of View

> = >

Richard Stallman writes:<= /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. > = >

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. > = >

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. > = >

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. > = >

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. > = >

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. > = >

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. > = >

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. > = >

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. > = >

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. > = >

> = > > = >

What Is the Legal Issue?

> = >

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. > = >

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. > = >

However, copyright is governed by the civil 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 cannot act on the > complaints of third parties. > = >

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.) > = >

Based on this advice, Stallman has concluded that > incorporating some code copyrighted by another entity > into a work such as Emacs puts the copyright of all > 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. > = >

What Is the Role of the FSF?

> = >

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. > = >

Well, Isn't That Paranoid?

> = >

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. > = >

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. > = >

Don't the XEmacs Developers Care?

> = >

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 we write will remain free. What we > are possibly losing is the ability to force others 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. > = >

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. > = >

Fear of Forking Considered Harmful

> = >

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 his direction > to merge those features that he wanted, making > changes to their code as he 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. > = >

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. > = >

And a little competition may be good for you! Without the > fork, GNU Emacs 20 might not have added Mule, and GNU > Emacs 21 might not 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. > = >

Of course, we all think it is best when all the good code > that results can be shared: > = >

> All Emacs developers are free software developers. >
> = >

But whether or not it can 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. > = > > = >

Author's Disclaimer

> = >

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. > = >

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!) > = > >

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.) > = >

> Stephen J. Turnbull <stephen(a)xemacs.org> >
> = > -- > 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." -- = ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. --===============6776603235824799099==-- From martin at xemacs.org Sun Feb 26 16:42:17 2017 Content-Type: multipart/mixed; boundary="===============8240163175851648387==" MIME-Version: 1.0 From: Martin Buchholz To: xemacs-beta at xemacs.org Subject: Re: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-18 16:26:27 +0900 Message-ID: <14829.20643.644530.265810@mule.m17n.org> In-Reply-To: 39ED4984.ADE574F0@666.com --===============8240163175851648387== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >>>>> "Ben" =3D=3D Ben Wing writes: Ben> hello there. Ben> awhile ago the faq had a link to something i wrote going into this in = more Ben> detail. steve removed it without consulting me, probably because he c= onsidered Ben> it incendiary and was trying to cooperate with rms on merging [futilel= y, of Ben> course]. thus he deleted all advocacy on our side; thus the "pusillan= imous" Ben> commentary from jamie. some time more recently, i rewrote my opinion = piece; Ben> here it is. obviously i am not objective, but i think it's important = to have an Ben> "our side" piece to match rms's "their side" piece that we include. I agree that members of the xemacs community should have a place to put their opinion. Our group is too diverse to have an "Our Side", however. So I suggest we have an "Opinion" web page, with opinions clearly identified by author. Consider this a place to put a "personal" web page for XEmacs developers, as long as the content is clearly xemacs-related. I have some opinions lurking in my brain that I would like to write about, if only I ever got around to it.... Martin --===============8240163175851648387==-- From turnbull at sk.tsukuba.ac.jp Sun Feb 26 16:42:17 2017 Content-Type: multipart/mixed; boundary="===============1974625938575167238==" MIME-Version: 1.0 From: Stephen J. Turnbull To: xemacs-beta at xemacs.org Subject: Re: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-18 16:53:06 +0900 Message-ID: <14829.22242.173708.445655@turnbull.sk.tsukuba.ac.jp> In-Reply-To: 39ED4984.ADE574F0@666.com --===============1974625938575167238== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >>>>> "Ben" =3D=3D Ben Wing writes: Ben> some time more recently, i rewrote my opinion piece; here it Ben> is. Thanks! Sorry about the misattribution of "pusillanimous." Ben> obviously i am not objective, but i think it's important to Ben> have an "our side" piece to match rms's "their side" piece Ben> that we include. I see your point. Personally, I'd like to bend over backward to give RMS's response prominence. That looks "objective". I like Martin's suggestion. What I would suggest as an implementation is that I move my discussion under "Fear of Forking Considered Harmful" to a separate page, and add links that that page, Ben's op piece, etc, as explicitly personal opinions. -- = 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." --===============1974625938575167238==-- From ben at 666.com Sun Feb 26 16:42:20 2017 Content-Type: multipart/mixed; boundary="===============0748868726464694365==" MIME-Version: 1.0 From: Ben Wing To: xemacs-beta at xemacs.org Subject: Re: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-25 00:26:59 -0700 Message-ID: <39F68B43.E57BE5C8@666.com> In-Reply-To: 14829.22242.173708.445655@turnbull.sk.tsukuba.ac.jp --===============0748868726464694365== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable "Stephen J. Turnbull" wrote: > = > >>>>> "Ben" =3D=3D Ben Wing writes: > = > Ben> some time more recently, i rewrote my opinion piece; here it > Ben> is. > = > Thanks! > = > Sorry about the misattribution of "pusillanimous." but i completely agree with it. xemacs has ZERO name recognition compared = to emacs outside [and inside, for that matter!] of the miniscule and insulated= free software community. > = > Ben> obviously i am not objective, but i think it's important to > Ben> have an "our side" piece to match rms's "their side" piece > Ben> that we include. > = > I see your point. Personally, I'd like to bend over backward to give > RMS's response prominence. That looks "objective". xemacs is not objective, obviously. nor is rms. rms will never put rebutt= als of his arguments on his site, and if you make his response most prominent, you're letting him have the last word once again! face it, xemacs is in its death throes. what it desperately needs is advocacy, not moral high-mindedness. no one cares whether you take the moral high road or not = if you die in the process. > = > I like Martin's suggestion. What I would suggest as an implementation > is that I move my discussion under "Fear of Forking Considered > Harmful" to a separate page, and add links that that page, Ben's op > piece, etc, as explicitly personal opinions. > = > -- > 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." -- = ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. --===============0748868726464694365==-- From turnbull at sk.tsukuba.ac.jp Sun Feb 26 16:42:20 2017 Content-Type: multipart/mixed; boundary="===============0741881693120654820==" MIME-Version: 1.0 From: Stephen J. Turnbull To: xemacs-beta at xemacs.org Subject: Re: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-25 17:14:31 +0900 Message-ID: <14838.38503.983127.675869@turnbull.sk.tsukuba.ac.jp> In-Reply-To: 39F68B43.E57BE5C8@666.com --===============0741881693120654820== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >>>>> "Ben" =3D=3D Ben Wing writes: Ben> if you make [RMS's] response most prominent, you're letting Ben> him have the last word once again! He'll get it anyway; that's my point. Personally, I've always thought that just posting that monolith of illogic and bile "as is" was the nastiest response we could make to it. But I guess I'm just too subtle.... Ben> face it, xemacs is in its death throes. what it desperately Ben> needs is advocacy, And then what? Advocacy won't overcome the inertial effect that the GNU name has. Ben> not moral high-mindedness. no one cares whether you take the Ben> moral high road or not if you die in the process. Knocking RMS is not the same thing as advocating XEmacs. Rather than explain why working with RMS is impossible, we should be explaining why XEmacs makes your life better. Sure, it's worth responding to him, but what we really need to do is to get it across why XEmacs is better than FSFmacs. >From the point of view of typical users, I don't know that the differences are so perceptible. If you must attack something, find some way to emphasize the advantages of XEmacs over the FSF's version of Emacs, a la MySQL's "crashme" page. -- = 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." --===============0741881693120654820==-- From sj at extundo.com Sun Feb 26 16:42:20 2017 Content-Type: multipart/mixed; boundary="===============4948575046451722025==" MIME-Version: 1.0 From: Simon Josefsson To: xemacs-beta at xemacs.org Subject: Re: RFC: xemacsweb - XEmacs vs. GNU Emacs Date: 2000-10-25 10:52:41 +0200 Message-ID: In-Reply-To: 39F68B43.E57BE5C8@666.com --===============4948575046451722025== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Ben Wing writes: > but i completely agree with it. xemacs has ZERO name recognition compare= d to > emacs outside [and inside, for that matter!] of the miniscule and insulat= ed free > software community. A small note; four out of six core KDE developers mention XEmacs as their "favorite tool": http://www.kde.org/people/people.html (Emacs and joe for the remaining two.) --===============4948575046451722025==--