
Clang and FSF's strategy - wisesage5001
http://gcc.gnu.org/ml/gcc/2014-01/msg00176.html
======
ja30278
I found the counter-argument made in the first reply to be more compelling.
[http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html](http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html)

Whether you agree with the FSF or not, their whole existence stems from their
beliefs about software freedom. If they compromise their principles in
exchange for 'market share', then they quite literally have no purpose.

~~~
chimeracoder
Agreed. It's very rare these days to find people who are willing to stick to
their principles; we should respect those who do, rather than criticize them
for _not_ compromising on their principles[0].

From your linked post:

> You are crossposting to two public project lists of the GNU project with
> inflammatory language and mischaracterizations. You have been involved with
> the GNU project long enough to be well aware that this kind of crowbar
> approach does not lead to much more than headlines about Free Software
> infighting.

ESR is doing little more than trolling here. He knows exactly where the FSF
stands, and he knows exactly why that's not going to change (asking the FSF to
do something that they believe hinders free software is like asking MADD to
open a drive-through liquor store).

The FSF has always been very clear that they see the "open source" movement as
complementary to (though not the same as) the free software movement, fighting
for similar goals but for different reasons[1]. It's sad to see ESR, an "open
source" advocate, actively try to fan the flames.

Nobody wins from this. Except advocates of closed, proprietary software.

[0] Of course, ESR knows exactly what he's doing here - the issue is that he
disagrees with their principles, but instead of debating those, he'd rather
attack them for executing on their principles rather than executing on _his_
principles. It's a cheap rhetorical trick and a rather low move.

[1] "We don't think of the Open Source movement as an enemy. The enemy is
proprietary software.", from [https://www.gnu.org/philosophy/free-software-
for-freedom.en....](https://www.gnu.org/philosophy/free-software-for-
freedom.en.html). (Don't be fooled by the title - the content of the article
is very even-keeled).

~~~
dragonwriter
> It's very rare these days to find people who are willing to stick to their
> principles; we should respect those who do, rather than criticize them for
> not compromising on their principles

Why should I respect someone for sticking with principles that are misguided?
The whole idea that "sticking to principles" is a virtue independent of the
merits of the principles involved is perverse.

Its even more perverse when the "principles" being stuck too are _tactical
judgments about how to best acheive strategic aims_ , and they are being stuck
too even when they are operating _against_ the strategic aims -- which is,
precisely, the charge ESR is levelling against the anti-plugin policy vis-a-
vis the stated goals of the FSF with regard to GCC.

> asking the FSF to do something that they believe hinders free software is
> like asking MADD to open a drive-through liquor store

ESR's argument is that FSF is _wrong_ that this hinders free software, and in
fact that FSF's status quo approach inhibits the FSF's stated goals for GCC.

~~~
mcguire
" _the 'principles' being stuck too are tactical judgments about how to best
acheive strategic aims, and they are being stuck too even when they are
operating against the strategic aims -- which is, precisely, the charge ESR is
levelling against the anti-plugin policy vis-a-vis the stated goals of the FSF
with regard to GCC._"

I believe ESR is wrong.

In years past, there was BSD unix, a modified version of the unix shipped from
Bell Labs. The BSD changes were theoretically "free", in that if you had a
license from AT&T (which were easy to get, since at the time AT&T couldn't
sell software), you could do anything you wanted with them.

What people did was to fork BSD, take their modifications proprietary, and
create Solaris (well, SunOS), HP-UX, AIX, Irix, and a fair-sized stack of
others that did even worse in the marketplace. The end result of _that_ was
fragmentation in the Unix ecosystem, which was bad on many levels. (One
example: Don't like autoconf/automake/libtool? Guess where the necessity of
those came from?)

Or, how about Jordi Gutiérrez Hermoso's response to ESR:

"The FSF sure can prevent it, and proprietary compilers still thrive. Here is
one that particularly bugs me as an Octave developer: we routinely see people
being lured to use Nvidia's non-free nvcc for GPU computing, which they
gleefully admit is based on clang and LLVM. And there is Xcode, of course,
completely non-free and completely based on clang and LLVM.

"The fact that these non-free tools are not based on gcc are a testament to
how proprietary software developers cannot plug into gcc, and how clang is
fostering non-free software.

"The nvidia situation is particularly dire becuase today, free GPU computing
is almost nonexistent. It's almost all based on CUDA and nvidia's massive pro-
CUDA marketing campaign. Even most OpenCL implementations are non-free, and
the scant few free implementations of OpenCL that exist are not fully
functional."

So we have several examples of ESR's approaches _failing_. On the other hand,
the GPL does a pretty successful job of preventing the kind of fragmentation
that damages ESR's "hacker community". And part of the reason it does is the
FSF's dogmatic stance.

~~~
dragonwriter
I think there is a conflict of goals here, but it's one that often goes
unstated; ESR is about fostering free software, even if that incidentally also
foster's non-free software.

Many on the FSF are about _preventing_ code from being used in non-Free
software, even if that incidentally is less than optimal for fostering Free
software.

The thing is, many of those who act based on the latter priority present
themselves as if there concern was for promoting Free software.

------
e12e
As other's have noted, GCC has a plugin system (and not a [edit:stable]
external interface) -- so that extensions/tools (plugins) will have to link to
GCC, and be covered by the GPL. This is similar to how the Linux kernel tries
to limit binary drivers, by explicitly not having a stable ABI (although, in
the case of the Linux kernel I _think_ it is also a case of "we don't want the
burden of maintaining an outdated, inferior ABI for the sake your proprietary
crap -- share or GTFO (And it's easier for everyone if we can just see your
code, bugs and all)").

However, isn't this paragraph:

"I also think it bears noticing that nobody outside of Microsoft seems to
particularly want to write proprietary compilers any more. GCC won its war;
the cost and time-to-market advantages of hooking into open-source toolchains
are now so widely understood that new processor designs support them as a
matter of course."

proved wrong by Apple's Xcode? Isn't that exactly what Aplle is (partially)
doing? I know Apple makes great contributions to (among other projects, clang)
-- but is upstream clang the same as what comes with Xcode?

~~~
dalke
As one of the commenters points out, Intel continues to develop a proprietary
compiler. I think that's a better example than Apple for this case.

In general, the world is more than just C/C++. IBM dominates the enterprise
COBOL market. (See [http://www.itworldcanada.com/article/most-wanted-the-
elusive...](http://www.itworldcanada.com/article/most-wanted-the-elusive-
cobol-compiler/46686) .) And there are several commercial Fortran compilers
besides Intel, including that of NAG (Numerical Algorithms Group) and PGI (The
Portland Group).

~~~
pdw
Proprietary C compilers are also alive and well in the embedded world.

~~~
frezik
But a lot of them use GCC, too. Atmel, for example.

------
crististm
ESR is comming hard on FSF to what is actually embracing "open source"
movement. His arguments are technical only as a means to hide the politics.

This is not going to happen. I think David Kastrup's reply was pretty clear in
that sense.

[http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html](http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html)

------
fhd2
Sounds like the open source vs free software debate all over again. I don't
have a strong position in that one, but I find GCC's position rather obvious:
They want to support free tools, and they explicitly don't want to support
proprietary tools.

I cannot believe that this isn't obvious to esr, of all people. Is this just
him trying to start a flame war?

edit: I'm now aware that esr is not talking about license restrictions but
technical restrictions here. I have yet to find any evidence of technical
restrictions for political reasons though, and it looks like the folks
responding to him on the mailing list are not sure what he means either.

~~~
erichocean
_GCC 's position [is] rather obvious: They want to support free tools_

I don't have a strong position either, but unless you work for the FSF in
their PR department, software developers should really be stating the FSF's
position accurately, which is:

 _The Free Software Foundation only want to promote free^H^H^H^HFree Software
Foundation-licensed tools, primarily tools that use its GPL license._

To the FSF, "free" is just a shorthand way of saying "Free Software
Foundation-licensed". It doesn't mean "free" as normally understood. Just
because the FSF wants to conflate the two to obscure what's going on doesn't
mean the rest of the world should go along with the ruse.

(And it _is_ clearly non-standard, which is easily demonstrated by how often
FSF people have to explain what "free" means. As they say in politics, if
you're explaining, you're losing. If there was no difference from the standard
usage, no explanation would be needed. Therefore, the FSF usage is non-
standard. QED)

FWIW I doubt anyone has a problem with the FSF's actual mission, since people
are free (normal usage) to do what they want (and even encouraged to do so).
It's the rhetorical duplicity of their PR that we shouldn't be supporting. Let
the FSF's mission stand on it's own merits, rather than by trying to gain
credibility/respectability by association with something else (in this case,
our pre-existing affinity for freedom).

~~~
dragonwriter
> To the FSF, "free" is just a shorthand way of saying "Free Software
> Foundation-licensed".

Not entirely true; the FSF recognizes lots of other licenses as "free".

Its true that the FSF thinks that its licenses are the _most appropriate_ for
promoting software freedom.

I think they're _wrong_ : if you can convince people that Free Software has
value, you don't need a copyleft license forcing them to give back, and if you
can't convince them of that, a copyleft license doesn't help you get them to
create free software, it just prevents them from engaging with it at all, gets
them to commit to an alternative, and makes them less likely to to commit back
even if they later realize a value in Free (since if they commit to a non-Free
third-party alternative, the cost of switching it out is higher.)

------
Devid2014
IMHO GCC has already lost this batle. Today one developer can create
incredible tools using Clang/LLVM coda-base and release it as open-source or
if he wants as closed source. This is just impossible with GCC. GCC is just a
compiler but Clang is much more as this is a very powerful compiler building
library... If we talk about C++ then Clang already support C++14 but GCC still
not. And yes License matters, GPL just does not allow to use GCC in most
cases. But today one does not need GCC at all any more, there is Clang. gcc-
xml was a hope many years ago but it just died, and today all this can be made
much much easier and faster using Clang. Clang is standard on OSX. Some Linux
distributions already switching to the Clang. Clang support for Windows is
already on the way.

So if nothing will be changes in GCC politics then it will become unnecessary
in the future. Of course some will still use it but only as political reasons.

~~~
vonbladet
> Today one developer can create incredible tools using Clang/LLVM coda-base
> and release it as open-source or if he wants as closed source. This is just
> impossible with GCC.

By design.

> And yes License matters, GPL just does not allow to use GCC in most cases.

By design.

~~~
coldcode
At that rate GCC will eventually die in obsolescence. By design, apparently.

------
lazyjones
esr seems to conflate technical differences with political issues here. clang
is not superior in some areas because it isn't GPL'd. It's because it is a
newer project with more resources and different priorities. Sure, it attracted
some developers who didn't like gcc's and the FSF's policies, but so do all
kinds of crappy proprietary products. The point is, gcc doesn't need to relax
its policies to better compete with LLVM, it just needs to become a
technically better product. I don't buy the implication that it cannot become
that without dropping some of the FSF's goals.

The gcc project is ancient and while I don't know the code base well, I'd
assume that the fact doesn't necessarily help make it more approachable for
new developers. Why can't a newer version of gcc be based on parts of LLVM, if
the latter is considered superior by so many people? The licenses seem to
allow it.

~~~
fafner
I think GCC receives a lot of undeserved hate at the moment. It is still a
very good compiler which constantly improves. E.g., for my projects it
generates better (faster) code. But still there are a lot of flame comments
made against GCC. It was very similar when Chrome was released and suddenly
the web was filled with flame comments against Firefox.

I think one problem is that many developers on Apple systems think the Apple
GCC was state of the art. When in fact the latest release (a patched 4.1?) was
rather old and obsolete. The Clang homepage still used to compares itself to
GCC 4.1 instead of 4.8.2 or 4.9. It was similar when Chrome was released and
Firefox was stuck on 3.6.1 waiting for 4.0. Sure Chrome was a lot faster but
Firefox quickly caught on. But still people seem to think otherwise.

There is a GCC for LLVM, called DragonEgg
[http://dragonegg.llvm.org/](http://dragonegg.llvm.org/). It is a _plugin_
(yes GCC has those since 4.5) for GCC. But I don't know what huge advantage
it's supposed to bring. Especially when GCC seems to have the better backend
(at least for my projects) at the moment.

I think the GCC folks should make the GCC Python plugin official because it
provides a more stable and clean API (mentioned by ian lance taylor here:
[http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html](http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html)).
They should continue with the transition for C++ (which will help to clean up
the code base a lot, no matter what the C++ haters say) and increase the work
towards modularization
([http://gcc.gnu.org/wiki/ModularGCC](http://gcc.gnu.org/wiki/ModularGCC) that
would probably allow making the frontend available as a library similar to
libclang). Libgccjit could be very interesting as well
[http://gcc.gnu.org/wiki/JIT](http://gcc.gnu.org/wiki/JIT)

~~~
Raphael_Amiard
There are very real differences between Clang and GCC - not when you use them
as a _client_ , to compile your code in the CLI, where gcc did indeed make big
improvements in the areas it was not as good as clang, and was already pretty
kick ass anyway, but when you try to use them as libraries, eg. use the AST to
do source transformations, or use the code generator to make a backend for a
new language.

Using clang/llvm for this is a _breeze_. They were concieved for that from the
get go. Using gcc's AST to do anything is an horrible nightmare, _and_ you
pretty much have to fork the whole gcc code base to do that anyway.

Using gcc to implement a backend for a new language is possible, but still a
lot harder than doing so with LLVM, which actually has a spec for its IR, and
is well documented.

Those things are not going to be easy to change because GCC wasn't designed to
account those needs.

~~~
fafner
> Using gcc's AST to do anything is an horrible nightmare, and you pretty much
> have to fork the whole gcc code base to do that anyway.

GCC supports Plugins which allow you to access all internal structures.

> Those things are not going to be easy to change because GCC wasn't designed
> to account those needs.

They are working towards modularization. It will certainly not be an easy
task. But I hope they accomplish that.

~~~
anon1385
>They are working towards modularization. It will certainly not be an easy
task. But I hope they accomplish that.

gcc-xml was already written and the gcc devs refused to merge it. Has that
changed in the last year?

~~~
belorn
[http://gccxml.github.io/HTML/News.html](http://gccxml.github.io/HTML/News.html)

Looks quite dead to me, and I recall reading that the author do not recommend
using it anymore.

~~~
fafner
There are still commits (latest ~1 month ago)
[https://github.com/gccxml/gccxml/commits/master](https://github.com/gccxml/gccxml/commits/master)

------
asb
The idea that the FSF (and perhaps more specifically, RMS) are holding back
GCC technically due to concerns about people working around the GPL dates way
back. As people have pointed out, GCC now has a plugin system but I imagine
ESR is thinking back to exchanges such as this one, where RMS rejected the
contribution of a Java bytecode backend to GCC purely on the grounds that it
could be used with proprietary tools using the bytecode as an IR
[http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html](http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html)

------
ahazred8ta
ESR may be incorrect; GCC has a plugin system. (YMMV)

[http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html](http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html)
/
[http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html](http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html)

~~~
Tuna-Fish
However, the interfaces are not stable across releases, making using the
system sufficiently hard that almost no-one bothers.

~~~
Shamanmuni
There's a reply to esr by Alexandre Oliva which touches this point. I'll quote
what he says:

"That GCC plugin interface is not sufficiently stable for major uncoordinated
developments by third-parties is just as true as that Linux's module interface
is constantly changing, and complaints about its lack of stability in it are
often responded with such phrases as contribute your driver and we'll even
help you keep it up-to-date".

I don't know about the subject but it seems a quite reasonable stand and it
certainly doesn't hinder the Linux kernel development, I don't see why it
wouldn't work in GCC.

~~~
bjourne
I believe he is talking about different kind of plugins. For example, suppose
you are an editor and you want to syntax highlight c source code. You could
then feed .c files to clang, get back a parsed ast and use that for awesome
syntax highlighting.

You can _not_ do that with gcc and the fsf does explicitly _not_ want you to
be able to. Because you could then be writing a non-free editor to take
advantage of and using gcc as a free front-end.

~~~
Shamanmuni
Oh, I think you are right, esr was talking about using GCC as a plugin and I
understood plugins for GCC. Apparently Alexandre Oliva and many of us made the
same mistake.

Considering that, I mostly agree with David Kastrup; it doesn't make sense for
the FSF to bend its principles and help propietary software in order to get
market-share. But, unfortunately, it's also affecting FOSS developers.

~~~
icefox
Yup, there are many, many times when I want to be able to do simple things
with C or C++ code. Writing a little static analyzer tool that can check some
internal code for a practice we have found harmful, parse some headers to
automatically generate python bindings, documentation stubs, generate _really
good_ unit tests stubs with the information the ast give you, grab all of the
comments and run your own verification on them, automagically re-write code to
not use an old api anymore. And this is all just with using the source parser
side of things of llvm

These are the tools I write, they are not big commercial enterprises, most of
them are one off projects that are used and tossed away within a year, very
few are ever published. Clang makes me more productive because they give me
the ability flat out do this type of thing. It doesn't matter what GNU
political agenda is, their tool flat out doesn't let me do this like llvm can.
As long as this is the case long term I will use llvm more and more over gcc.

------
teddyh
I wrote this six months ago:

 _If people switch from GCC to Clang /LLVM in enough numbers that Apple think
they can get away with it, Apple will, in a heartbeat, close the development
of Clang/LLVM and make all new versions proprietary._
([https://news.ycombinator.com/item?id=6146066](https://news.ycombinator.com/item?id=6146066))

This is still true, and _this_ is the reason we cannot allow GCC to give up or
declare “victory” and move on.

~~~
anon1385
I really don't see that happening. Google engineers are the largest
contributors to LLVM/Clang these days. Why would Apple reject the
contributions of a company that employs some of the best compiler engineers?
It would make it much more expensive for them to maintain and develop LLVM.

~~~
teddyh
Why can you not see the possibility of Google collaborating with Apple to take
LLVM proprietary?

------
adamtj
As I see it, the whole disagreement seems to stem from differing opinions
about what happens when free/open software and non-free/closed software meet,
and which is "stronger".

FSF lives on an island and worries that even one contaminated inhabitant will
infect everybody. They seem to hold that non-free is a contagious disease that
will overtake and destroy their freedom. FSF is worried about diminishing:
what they have is perfect and it can only be reduced. FSF are Tolkein's Elves.

ESR would welcome contaminated people to that island, believing strongly in
it's restorative properties. He seems to hold that open-source is more
powerful and will stamp out closed software whenever they meet. ESR is worried
about not expanding quickly enough and dying of stagnation. ESR would probably
be Aragorn.

That's how I see this argument.

------
fulafel
Sounds like this was posted without reading the linked thread. He retracted
the post in a followup as he didn't know about the GCC plugin system:
[http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html](http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html)

------
Aqueous
I see GCC as performing the necessary function of defining the radical
antithesis to proprietary tools, historically like Think C, C++, Borland,and
Metrowerks, and presents tools like Microsoft's Visual C/C++.

Without GCC staking out the position it has clang wouldn't have its middle
ground to stake out. The middle ground would instead be a lot more proprietary
than it is now.

Without Stallman being as radical as he is, there would be no Linus' who
bridge the gap between completely free and completely proprietary software.
There would be nothing to react to.

Many wrongs actually do make a right, as long as we're all wrong in opposite
directions.

------
Fede_V
I doubt ESR was genuinely interested in changing GCC policy - that seems to be
like a well written piece of concern trolling. If you want to make
suggestions, you discuss it politely with the stakeholders, you don't make
intentionally provocative suggestions on a public mailing list.

------
jejones3141
"I also think it bears noticing that nobody outside of Microsoft seems to
particularly want to write proprietary compilers any more."

Someone should tell Intel that. Don't they still do things to intentionally
make AMD CPUs look bad?

------
Someone
_" The clang developers very carefully do _not_ say that they aim to make GCC
obsolete and relegate it to the dustbin of discarded tech. But I believe that
is unmistakably among their goals"_

Beliefs don't need them, but I don't see a rational argument supporting that.
IMO, clang developers just won't cripple their product to prevent the
potential collateral damage to gcc.

------
VikingCoder
The best part: reading ESR call others ham-handed and counterproductive.

------
zombie_hitler
esr trolling the gnu mailing lists...

------
bane
Ugh, more free software vs. open source politics. In the interest of actually
collaborating and getting shit done, I'd like "freedom" from all this nonsense
please.

