8 comments

[ 3.2 ms ] story [ 33.2 ms ] thread
In advance: I honestly have no intention of doing link-baiting, but I found it hard to summarize this submission accurately.

If anyone has any better suggestions, I'm all for it and encourage the mods to change the title.

Basically, a bunch of folks are trying to convince RMS to allow GCC to provide more information about parsed C++ programs to Emacs. This would allow Emacs to implement a bunch of modern types of program transformations, e.g.: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

Stefan Monnier, the lead Emacs developer, argues that this is important for Emacs and he's willing to support people in creating a GCC plugin to output this info. Linked post and also here: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

RMS's concern is that allowing GCC to output its internal representation including the AST (Abstract Syntax Tree) would enable non-free software to also use it as a preprocessor: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

Perry E. Metzger points out that people are already using Clang+LLVM for preprocessing: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

He and others are concerned that LLVM has overtaken GCC in terms of mindshare within academic research because of its modular structure: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

LLVM has an MIT/BSD-style license though, which RMS disagrees with: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

Meanwhile, Eli Zaretskii's trying to document the use cases for info from GCC, so that a decision/design can be made with the full perspective: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

Eli's attempt to collect information seems well-intentioned but very silly. There's no way to make some finite list of the things you might want to do to enable an intelligent decision about what information to export from GCC. You want to be able to do everything, so you can write new program transforms as you think of them.

Think of a Guile REPL with C++ syntax trees as values and a set of functions mapping trees to trees. That's the sort of thing that would be very helpful in thinking of what to do in the first place.

It doesn't sound like Richard would appreciate this scenario though, which I find a little sad.

I hate to say it but RMS comes off as a bit petulant in this exchange. The "I'd advise you to stop 'pressuring' me or else" bits in particular.

The other developers are trying to show him that he's keeping GCC crippled by design in order to preserve freedom. They argue that in doing so, the affect will be to drive people away toward more wide open tech, achieving the exact opposite of what RMS hopes to accomplish.

When they cite examples of this already occurring, RMS responds with either a shrug ("it's already happened, so we can't stop it") or with the aforementioned "I'm offended."

Stefan asks point blank:

"Are you saying that if David writes this, and writes code for Emacs to make use of it, you're going to use your leverage to try and make sure this code doesn't make it into Emacs?"

To which RMS responds:

"We do not want to promote that sort of plugin."

That's kind of sad.

He feels a threat to his authority and ideology and is responding accordingly.
It doesn't sound like Richard would appreciate this scenario though, which I find a little sad.

Of course. That's why they're doing it. Everyone is walking on eggshells trying to appease RMS, but he's not having it. Later in the thread it sounds like he's about to have a tantrum. Someone calls him out and says that writing what RMS thinks would be acceptable is a waste of time to which RMS responds

You consider it a waste of time, because you see the value in what I am trying to protect.

That was a typo he meant, "because you do not see the value in what I am trying to protect." He corrected himself in a later email to the thread.
Per David Kastrup earlier in that thread:

> It is a greater problem for us to definitely block free applications from being developed, either completely or by putting up prohibitely high administrative or technical hurdles, than it is to accept the possibility of non-free ones here.

I think this is a good example of why trying to actively fight certain use cases - in this case, potential use by non-free software - might as well be considered harmful. In this particular case, clang/LLVM is proving itself to be more free than GCC.

I'm a pretty strong free software advocate, and at this point, it's sounding like LLVM is the way to go for even that reason alone. Deliberately crippling a compiler to satisfy an ideological agenda does not encourage the development of free software, especially in comparison to making a free software project like LLVM that demonstrates the ways in which free software is better software.

Basically, while I admire RMS' strong convictions, I'm beginning to believe more and more that they're doing the precise opposite of what he - and many other advocates of software freedom - actually want.