Re: clang and FSF's strategy

[David Kastrup]

address@hidden (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