Re: Emacs contributions, C and Lisp

[Stephen J. Turnbull]

Richard Stallman writes:

 > Reciprocity is an aspect of the point of the GNU GPL, but its main
 > point is _defending users' freedom_.

Conceded.

 > With the GNU GPL (and copyleft in general), we make sure that all
 > copies of all versions of our code _respect users' freedom_.

That's a nice euphemism for *dis*respect for the users.  You treat
them like children, fearing they will abuse their freedom by choosing
bondage to proprietary software rather than choosing less capable free
software, or even just saying no to the unique benefits of some
proprietary software.  The contrast with your support for removal of
all restraint on various other kinds of dangerous freedoms (where the
most at risk are real children rather than possibly childish adults)
is striking.

 >     stifling friendly competition is a very bad thing,
 > 
 > By calling LLVM "friendly competition" you misrepresent the issue at
 > stake.  You're wasting your time, asking me to change my mind based on
 > ignoring what's at stake.

I apologize for using the word "friendly"; I should remember that your
sense of humor doesn't extend that far.  But I am not misrepresenting
what's at stake any more than you are -- I'm simply presenting a side
you wish we could ignore.

 > In any case, we are not in a position to stifle LLVM, so you're
 > discussing an imaginary issue.

Then what the heck are you trying to do?  The results are increasing
enmity with the LLVM developers and unhappiness among Emacs
developers.  There are no practical benefits of this policy.  The
claim that a really minor potential attraction of Clang/LLVM will be
erased is surely false.  Eclipse and vim, among others, will take
advantage of it.  So at that point, what you have succeeded in doing
is reducing the attractiveness of Emacs, too.  And that's the end of
the "benefits".

I see no good to come of this.  It's unfortunate that GCC is
prohibited from emulating this particular feature of LLVM, but hey,
why not just suck it up, man?  That's *your* *arbitrary* prohibition,
for reasons that apply specifically to GCC, not to Emacs.

So be arbitrary again, and let Emacs implement completion based on
features provided by free software (that happens to compete with GCC,
but this feature could benefit GCC users, too!)  Or let somebody else
implement the feature, and Emacs collect papers and distribute it.

 >     have we learned nothing from the Great Planning Experiments of
 >     Marx-Lenin-Stalin-ism?
 > 
 > Lots of projects make plans and implement them.  If you equate making
 > plans to Communist dictatorship, you've gone off the deep end.  And
 > that's not to mention that your accusation is so nasty that we
 > shouldn't be on speaking terms.

For heaven's sake, Richard, remember I'm an economist and consider
history.  I *did* not mean the "dictatorships of the proletariat".
Note that those dictatorships have mutated (sometimes non-Communist,
sometimes unreconstructed) but survived.

I *did* mean the "great planning experiments" which did stifle
competition.  OK, you're not in a position to stifle LLVM, but you
certainly wish it didn't exist, don't you?  You wish that all that
effort would flow into GCC, don't you?

But (like the Communist planning organs) GCC is a highly political
community, because the stakes are so great.  GNU has played its part
in that politicization (by delaying implementation of plug-ins and
exportation of useful internal data structures for example), but the
fact that GCC is both an important input and partly shaped by the ISO
standardization process is even more important in its politicization.

Now, the "great experiments" did channel the entire efforts of
(national) communities into allegedly rational plans, and *look what
happened to those communities*.  "Post hoc ergo propter hoc," I know,
but even a fallacy can give true results sometimes.  GCC's decade of
dominance, attracting many of the best and brightest compiler writers,
may have done the same thing to it.

And (as I pointed out to David elsewhere), though GNU has surmounted
challenges from XEmacs, separatists in glibc, and EGCS, LLVM may very
well be different because *big* business and projects producing free
software have learned to cooperate well.  LLVM is by far a stronger
challenge to GNU than anything it has experienced except the Linux
kernel itself.

If LLVM does achieve the kind of dominance that GCC has enjoyed for
the past several years, and (as David fears) it becomes the compiler
of choice for GNU/Linux distros (not to mention Android/iOS/OSX), then
what?  Perhaps at that point you'll look at the situation and decide
GNU needs a competitive compiler suite, and allow plug-ins and export
of internal data structures to compete with (even conform to!) LLVM
APIs.  Perhaps you can deny the very *possibility* of such a future.

But if not, why not *consider* using "license judo" on LLVM?

The idea is to preempt that future by (1) allowing Emacs to support
Clang/LLVM features if that suits the Emacs contributors, (2) removing
the absolute block on "export" and the implied refactoring into
multiple executables (and adding a "free software compatible" API as
you recommended for the kernel modules and GCC plugins, if that is
feasible), (3) encourage the GCC community to adopt Clang/LLVM
architecture, API, and implementations, and (4) watch designs,
implementations, and eventually contributors flow *out* of LLVM and
*into* GCC because of the licenses.  In the end, one of two things is
likely to happen: LLVM withers, or LLVM adopts the GPL in order to
stem the one-way flow of innovations.  Either way GNU (if not GCC)
wins.

Note that I do not claim that there is *no* innovation in recent GCC;
merely that it's (a) slower than it might otherwise be because the
incentive of strong competition has been lacking and specifically
slower than in the newly arisen competition, and (b) less effective
than it might be because the absence of competitors (not to mention
administrative restriction on kinds of innovation) means that bold
experiments are far fewer.  The strategy above of course depends on
there being plenty of innovation in GCC still -- thus by efficiently
copying Clang/LLVM it can catch up where it needs to, and innovation
unique to GCC will then attract both commercial support and volunteer
developers.

Caveat: I don't claim there's no risk to that strategy, nor that it
conforms to your principles (though I think it might).  I do insist
that there is an equally big risk to your strategy, minor annoyances
along the way, and I wonder whether it's worth adhering slavishly to
principle only to see that principle end up in the dustbin of history.