Clang and FSF's strategy

ESR is just trolling. What his bug is, I don't know. Seems like he's dancing around something that might be interesting and more inline with the social observation that he's a little better at. I assert that GCC doesn't actually compete and doesn't need to compete. It just has to be available and it simply has to have hackers that are willing to work on it for the principle. Let's just assume that clang takes over the world, consistently produced better code than GCC, etc.. What exactly does that matter to GCC? Presumably hackers will stop working on GCC, but guile, hurd, and numerous other GNU projects show that that isn't always the case. I think that as long as GNU exists and they have some money and fans, there will be GCC contributors. Is there some other fear of what will happen if people use a different tool chain? Conversely, BSD has depended upon GCC for decades and I'm not convinced that that has affected it in any way and their switch to clang I suspect isn't going to radially alter things either. If we go back a week or two, I don't know that emacs' choice of revision control software makes any difference to its use, it may have some amount of impact on people contributing to it but I don't think that is clear cut either, there are A LOT of emacs contributions that aren't in the main tree... Also these projects don't want 'drive by' contributions, they want actively involved supporters.

Seems like he's dancing around some social observations that he wants to be true but can't prove or they might not be true. People hack on stuff because they have an itch, that itch might be technical need, it might be some sense of aesthetic that they think isn't being answered, it could also be related to something like freedom. When do other factors outweigh the itch? Now maybe GCC is GNU's most important software asset and there is some larger social thing ESR is worried about or has observed.

For example RMS vetoed the first attempts to add support for Java bytecode to GCC because he thought it would allow people to interact with GCC from other non-free software: http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html

That same reasoning is why there is no GCC equivalent to LLVM IR or libclang or libtooling.

https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00...

Part of the reason why clang/llvm weakens our commnity, compared with GCC, is that the clang front ends can feed their data to nonfree tools.

There are some links in this wiki page that cover some of the arguments made against adding support for plugins to GCC. http://gcc.gnu.org/wiki/GCC_Plugins under 'Potential disadvantages of supporting a plugin architecture in GCC'

Here is a post from a GCC maintainer explaining that RMS was personally blocking the inclusion of this much desired basic functionality for political reasons: http://gcc.gnu.org/ml/gcc/2007-11/msg00193.html

> Is there any progress in the gcc-plugin project ?

Non-technical holdups. RMS is worried that this will make it too easy to integrate proprietary code directly with GCC.

LLVM and clang can be used in pretty much any project. They have provided every developer tools to use in anyway we wish. GCC's parts cannot be included in other projects because they are licensed in such a way that tells us that the GCC code is more important than the code we are using. Why does a 1,000 line GPL count for more than 100,000 lines of some other license?

I think the best community is a voluntary one, and with security the way it is, I would rather developers who don't want to be part of the community benefit from the code just as I like the idea of everyone (who can) being vaccinated.

GPL generates a self-selected community that has barriers to participation with other communities because the GPL code is held as more important than the rest.

Even if that is a real ideological division between the two, pragmatically I think that the permissive licenses that the FSF argues are less than ideal have done more after the initial demonstration of the value of F/OSS to promote a community of people who add to the public knowledge of software engineering than have copyleft licenses.

I think the divide over licensing approaches is as much over differing views of effective tactics and the real conditions in the environment as it is about differing views of values and strategic goals, and that permissive vs. copyleft is the real current divide more than free software vs. open source, and that, over time, the permissive side is gaining ground for reasons that have nothing to do with the main cited ideological differences between the open source and free software camps.

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