clang and FSF's strategy

clang and FSF's strategy

[Eric S. Raymond]

David Kastrup's recent question on emacs-devel motivates me to bring
up a larger related question I've been meaning to open for a while: Are the
FSF's goals best served by continuing to technically restrict GCC?

This is a question in which I have some positive stake.  Yes, I
continue to be opposed to the FSF's style of propaganda exactly
because I think it hinders an end goal - a software ecosystem that is
open-source and user-controlled - that I agree with and have worked
hard to achieve. On the other hand, I have always said that the FSF's
artifacts are its best artillery, and GCC is certainly one of the
biggest guns in that arsenal.

I want GCC to do what the FSF wants it to do - promote freedom and
openness, erode proprietary control, prevent vendor lock-in of
development toolchains. I think it is time to question whether the
anti-plugins policy is still the best way to accomplish this.

What gives this question point is the very existence of clang.  The
clang developers aren't shy about saying in public that they regard
the FSF's anti-plugin policy as obstructive and that this is a major
motivation for their work.  And they're making excellent progress;
clang is a production-quality tool today, not yet as mature as GCC but
with better features in some areas - its error messages, in particular
are *far* superior.

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, and I judge that they
are a credible threat to GCCs's dominance in the 3- to 5-year
timeframe.

It might be that my goals would actually be advanced if clang were to
kick GCC off the top of the heap.  That is, there is at least a
possible world in which a serious hit to FSF's prestige would decrease
its ability to hinder progress through PR I have made no secret of
considering ham-handed and counterproductive.

For the present I choose to ignore this possibility. It seems better
to me to promote as vigorous as possible a competitive race between 
GCC and clang, so that both will improve and the the aggregate position
of open-source toolchains will strengthen.

Therefore, I point out that FSF can no longer prevent proprietary
vendors from plugging into a free compiler to improve their tools.
That horse has left the barn; the strategic goal of the anti-plugin
policy has been definitively busted.

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.

Wouldn't it make sense, then, to entirely drop the factoring
restrictions from GCC so it can compete for developer attention more
effectively with clang?

Before clang existed, back when GCC had a near monopoly in its
competitive space, there might have been a functional case for those
restrictions. Reasonable people may differ on that; there's no point
in arguing it retrospectively. Now, I submit, they have become a pointless
gesture that serves only to hinder GCC development abd increase
clang's competitive advantage.

GCC has a lot of strengths to play from, most notably the maturity of
its multiplatform and cross-development support.  I urge the FSF to
fully free the code - drop the policy restrictions, encourage a
flourishing ecosystem of surrounding plugins.  Let GCC, clang, and
other alternatives compete for attention on pure technical merit.

I think the last fifteen years have demonstrated that in this sort of
competition, the proprietary vendors will eat dust if they try to
outcompete open-source tools on their own ground. Furthermore, they've
learned this the hard way, and are quite unlikely to try.  There are
less risky uses for their NRE.

In some sense I don't really care who wins.  Either GCC or clang
will serve my needs. I do prefer that both tools be as excellent
as possible.  And it would be nice if the FSF were to demonstrate that
it can recognize changed conditions and move with the times.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

There's a tendency today to absolve individuals of
moral responsibility and treat them as victims of
social circumstance.  You buy that, you pay with your
soul.
		-Tom Robbins, Still Life with Woodpecker

Re: clang and FSF's strategy

[David Kastrup]

esr@thyrsus.com (Eric S. Raymond) writes:

> David Kastrup's recent question on emacs-devel motivates me to bring
> up a larger related question I've been meaning to open for a while:
> Are the FSF's goals best served by continuing to technically restrict
> GCC?

I don't think that's even a sensible question.  The point of the GPL is
to promote expansion of Free Software, and the tool it uses for doing so
is by covering licensing of "the work as a whole".  When providing full
technical capabilities for accessing the functionality of of program
without creating a larger whole in the process, we are basically down to
the LGPL.

So most definitely the FSF's goals are best served by continuing to
technically restrict GCC.  If there is any question, the question is
rather _what_ restrictions serve its interests more than it impedes
them.  Since any lifted restrictions cannot easily be reinstated, it
makes sense to be conservative.

> This is a question in which I have some positive stake.  Yes, I
> continue to be opposed to the FSF's style of propaganda exactly
> because I think it hinders an end goal - a software ecosystem that is
> open-source and user-controlled - that I agree with and have worked
> hard to achieve.

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.

> The clang developers very carefully do *not* say that they aim to make
> GCC obsolete and relegate it to the dustbin of discarded tech.

Like most Free Software, GCC started out in a state where its technical
competitiveness placed it in the dustbin.  And that's a state the GNU
project prefers over that of it being an enabling and seminal part of
proprietary software "ecosystems".  That's the reason GNU software is
licensed under copyleft rather than permissive licenses, and the
criterion of popularity should not render that choice irrelevant.

There is leeway for making and balancing individual decisions according
to individual tradeoffs.

Your black-and-white and all-or-nothing rhetoric and confrontational
style is not helpful for that.

> Therefore, I point out that FSF can no longer prevent proprietary
> vendors from plugging into a free compiler to improve their tools.

And we could not prevent proprietary vendors from plugging into
proprietary compilers to improve their tools, either.  And things like
Microsoft Visual C++ and the Intel compilers are quite competitive in
technical respects.  The only thing we ever have been able to prevent
people to do is them plugging into _our_ free compiler.

> That horse has left the barn;

Lots of horses have left the barn.  That's irrelevant as long as it is
not the horse we are sitting on.

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

Huh?  Intel still writes proprietary compilers, basically every GPU
vendor boosts his own proprietary compiler.

> In some sense I don't really care who wins.  Either GCC or clang will
> serve my needs. I do prefer that both tools be as excellent as
> possible.  And it would be nice if the FSF were to demonstrate that it
> can recognize changed conditions and move with the times.

The whole point of the FSF was _not_ to "move with the times".  If you
would be willing to forego your popularity contest based approach, you
might have a better chance of getting actual adjustments in the details.

But at the core level, I see a fundamental miscomprehension about the
contexts in which strong copyleft and the GNU project operate and make
sense.  As long as you don't come to terms with that, I don't see this
discussion leading anywhere.  And that's not even taking into account
that key players tend to be less than amused about such a
confrontational approach.

-- 
David Kastrup

Re: clang and FSF's strategy

[Alexandre Oliva]

On Jan 21, 2014, esr@thyrsus.com (Eric S. Raymond) wrote:

> I think it is time to question whether the anti-plugins policy is
> still the best way to accomplish this.

Err...  Excuse me, but what anti-plugins policy are you talking about?

The runtime license exception designed to make room for GCC plugins
without endangering its copyleft is almost 5 years old!

Did you feel so aligned with clang's FSF-disparaging propaganda that you
failed to check the facts, or are you being intentionally specious?


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

If you were to applaud one while voicing objections to the other,
someone might even get the idea you're using double standards ;-)

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist     Red Hat Brazil Toolchain Engineer

Re: clang and FSF's strategy

[Stefan Monnier]

> up a larger related question I've been meaning to open for a while: Are the
> FSF's goals best served by continuing to technically restrict GCC?

Let me repeat: please stop discussing such things on this list.
There are things like gnu.misc.discuss for that.


        Stefan

Re: clang and FSF's strategy

[Ian Lance Taylor]

On Tue, Jan 21, 2014 at 12:19 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>
> Wouldn't it make sense, then, to entirely drop the factoring
> restrictions from GCC so it can compete for developer attention more
> effectively with clang?
>
> Before clang existed, back when GCC had a near monopoly in its
> competitive space, there might have been a functional case for those
> restrictions. Reasonable people may differ on that; there's no point
> in arguing it retrospectively. Now, I submit, they have become a pointless
> gesture that serves only to hinder GCC development abd increase
> clang's competitive advantage.
>
> GCC has a lot of strengths to play from, most notably the maturity of
> its multiplatform and cross-development support.  I urge the FSF to
> fully free the code - drop the policy restrictions, encourage a
> flourishing ecosystem of surrounding plugins.  Let GCC, clang, and
> other alternatives compete for attention on pure technical merit.

I'm sympathetic to our comments regarding GCC vs. clang.  But I'm not
sure I grasp your proposed solution.  GCC does support plugins, and
has supported them for a few releases now.

GCC plugins have what turns out to be a significant defect: the plugin
interface simply exposes GCC internals, and as such is not stable
across releases.  I pushed for plugins in GCC, and I thought this
unstable interface would be OK, but I was wrong.  For general plugins
to be useful, we need a more stable interface.

But that is a technical issue, not a licensing issue.  You are talking
about licensing issues.  Do you think the licensing requirements on
plugins are too onerous?

Because of the non-standard interface, the most effective way for
people to write plugins for GCC today is to use something like MELT
(http://gcc-melt.org) or the GCC Python plugin
(https://fedorahosted.org/gcc-python-plugin/).  These provide a
somewhat more standard interface across releases.

Ideally we would develop a standard interface for C as well.  There
have been some efforts along those lines but as far as I know none of
them have been committed to the tree.

Ian

Re: clang and FSF's strategy

[Eric S. Raymond]

Ian Lance Taylor <iant@google.com>:
> I'm sympathetic to our comments regarding GCC vs. clang.  But I'm not
> sure I grasp your proposed solution.  GCC does support plugins, and
> has supported them for a few releases now.

Then I don't understand why David Kastrup's question was even controversial.

If I have failed to understand the background facts, I apologize and welcome
being corrected.

I hope you (and others) understand that I welcome chances to help the FSF's
projects when I believe doing so serves the hacker community as a whole. The
fact that I am currently working full-time on cleaning up the Emacs repoaitory
for full git conversion is only one instance of this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: clang and FSF's strategy

[grischka]

David Kastrup wrote:
> The whole point of the FSF was _not_ to "move with the times". 

Really?  Is that a theory of everything or still quantum gravity?

--- grischka

Re: clang and FSF's strategy

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Ian Lance Taylor <iant@google.com>:
>> I'm sympathetic to our comments regarding GCC vs. clang.  But I'm not
>> sure I grasp your proposed solution.  GCC does support plugins, and
>> has supported them for a few releases now.
>
> Then I don't understand why David Kastrup's question was even
> controversial.

I must have missed the controversy.

> If I have failed to understand the background facts, I apologize and
> welcome being corrected.

I'll refrain from any comments about wiping the egcs off anybody's face.
My reply to your "call to arms" was actually rooted in as much (or
rather little) actual knowledge of the pertinent situation as your
request appears to have been.

But as you chose an enquiring mail of mine to justify your
confrontational approach, I felt that I should mitigate the damage
purportedly originating from me by addressing those points that I cannot
consider a justifiable conclusion from what I wrote.

-- 
David Kastrup

Re: clang and FSF's strategy

[Jordi Gutiérrez Hermoso]

On Tue, 2014-01-21 at 15:19 -0500, Eric S. Raymond wrote:
> Therefore, I point out that FSF can no longer prevent proprietary
> vendors from plugging into a free compiler to improve their tools.
[snip]
> I also think it bears noticing that nobody outside of Microsoft seems
> to particularly want to write proprietary compilers any more. 

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.

We also have technical reasons in Octave to not use LLVM, even though
we are using it right now: its API is hugely unstable. Each new LLVM
release has needed its own new, complicated autoconf checks. We have
been chatting with Red Hat's David Malcolm who works on libgccjit to
help us get something better and more stable. This thus proves that it
is not impossible to use gcc for the same tasks as LLVM, and its
pluggability is growing.

- Jordi G. H.

Re: clang and FSF's strategy

[Michael Witten]

On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote:

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

What does it matter whether clang fosters non-free software if clang *also*
fosters free software? Indeed, non-free software inspires a lot of free
software, anyway.

Apparently, gcc isn't fostering much of anything, except for a desire to
replace it with llvm/clang.

Where there is the least friction, there is the most freedom.

Re: clang and FSF's strategy

[David Kastrup]

Michael Witten <mfwitten@gmail.com> writes:

> On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote:
>
>> 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.
>
> What does it matter whether clang fosters non-free software if clang *also*
> fosters free software? Indeed, non-free software inspires a lot of free
> software, anyway.
>
> Apparently, gcc isn't fostering much of anything, except for a desire to
> replace it with llvm/clang.
>
> Where there is the least friction, there is the most freedom.

And you can save a lot of money on street construction if everybody just
drives off-road.  Simple solutions for the win.

The GNU project did not get where it is by accident.  If you take a look
at "prisoner's dilemma" tournaments, by far the most successful strategy
invariably is "tit for tat" and slight variations.  The unmodified
strategy will _never_ beat an opponent in any single battle, and it
still emerges as the winner in many tournaments.

At any rate, if you want to bash the strategies of the GNU project,
these lists are the wrong place to go.  Try doing it on the Clang list
though I am skeptical that they do not have better things to do as well.

-- 
David Kastrup

Re: clang and FSF's strategy

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

    What does it matter whether clang fosters non-free software if clang *also*
    fosters free software?

Non-free software is an injustice.  Our goal is to eliminate that
injustice, to give computer users freedom.  Developing free software
part of what we do to achieve this goal.

When any program fosters non-free software, that works directly
against the overall goal.

Copyleft is our method of making sure that our free software does not
generate nonfree competitors which consist of our code plus something
else that is off limits to us.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: clang and FSF's strategy

[Joseph S. Myers]

On Tue, 21 Jan 2014, Alexandre Oliva wrote:

> On Jan 21, 2014, esr@thyrsus.com (Eric S. Raymond) wrote:
> 
> > I think it is time to question whether the anti-plugins policy is
> > still the best way to accomplish this.
> 
> Err...  Excuse me, but what anti-plugins policy are you talking about?

Indeed.

There are people working right now on improvements to modularity in GCC, 
elimination of global state, and support for use of GCC in a JIT library, 
led by Andrew MacLeod and David Malcolm.  Contributions to those sorts of 
efforts (and to the plugin interface) are more useful than rhetoric.  No 
policy objections are being made to these patches, it's simply a matter of 
the work involved.  If people want suggestions that don't conflict with 
what Andrew and David are working on, a couple of suggestions:

* We have about 700 target macros (my script lists 697 right now, but 
there are likely some false positives, and maybe false negatives), all of 
which should move to the hooks mechanism to enable multiple targets to be 
supported in a single compiler binary, and to get other benefits such as 
not having the build of GCC fail with warnings seen only for some targets 
because of differences in the target macro definitions.  I expect a large 
proportion of these (not used in #if or in code built for the target, 
etc.) could be converted to hooks using some form of script-based 
automatic refactoring, possibly with manual fine-tuning of the resulting 
patches.

* Andrew MacLeod's plans for improving static typing are I think largely 
about the middle end - there is plenty of scope for improving static 
typing of datastructures used in the front ends, and cleanly separating 
them from the language-independent compiler as far as possible.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: clang and FSF's strategy

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> esr@thyrsus.com (Eric S. Raymond) writes:
>
>> David Kastrup's recent question on emacs-devel motivates me to bring
>> up a larger related question I've been meaning to open for a while:
>> Are the FSF's goals best served by continuing to technically restrict
>> GCC?

>> This is a question in which I have some positive stake.  Yes, I
>> continue to be opposed to the FSF's style of propaganda exactly
>> because I think it hinders an end goal - a software ecosystem that is
>> open-source and user-controlled - that I agree with and have worked
>> hard to achieve.
>
> 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.

And just for the record, here are some of the headlines.

<URL:http://lwn.net/Articles/582242/>

I'm keeping the crosspost since the main issue started up on
emacs-devel, and it mostly pertains to gcc-devel where some participants
may be interested in using the opportunity to correct misconceptions in
the discussion following the article (which could have been a lot worse
I guess).

With regard to the discussion on the mailing lists itself, I think that
pretty much everything that's relevant to the big rhetorics has been
said already.  That does not mean that nothing remains to be done in the
area of better integrating Emacs and GCC, but it does not appear like
the main obstacles are of the kind that can be overcome by
swashbuckling.

-- 
David Kastrup