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 cooperate 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 long
and all of them coming from the XEmacs side. All have failed because they have
eventually come to the same conclusion, which is that RMS has no real interest
in cooperation at all. If you work with him, you have to do it his way -- "my
way or the highway". Specifically:
- 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 these 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 we 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
that because many of the large copyright holders of XEmacs (for example
Sun Microsystems) refuse to sign legal papers. Although they have not
stated their reasons, there are quite a number of reasons not to sign
- 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 project 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 as a result
feel very uncomfortable about signing legal papers.
- 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.
- RMS does not like abstract data structures. Abstract data structures
are the foundation of XEmacs and most other modern programming projects.
In my opinion, is difficult to impossible to write maintainable and
expandable code without using abstract data structures. In merging talks
with RMS he has said we can have any abstract 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.
- RMS is very unwilling to compromise when it comes to divergent
implementations of the same functionality, which is very common between
XEmacs 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 (rather than implementing one in C and the other on top if it),
so that code that uses 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 support two divergent interfaces, and would be
difficult to maintain in this state.
- RMS’s idea of compromise and cooperation is almost purely political
rather 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
result of such a process is typically a big mess, because there is no
overarching design but instead a great deal of incompatible things
If only some of the above differences were firmly held by RMS, and if he were
willing to compromise effectively on the others and to demonstrate willingness
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 redundant
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 XEmacs
project would be willing to do it all, given that it is a tremendous amount of
extra work and the XEmacs project is already strapped for coding resources. (Not
to mention the inherent difficulty in convincing people to redo existing work
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 terms
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 principles.
The fact that few if any people share his principles is meaningless to him.