Clang and FSF's strategy • Hacker News Board

Re: Clang and FSF's strategy

#31

Post by ja30278 » Wed, Jan 22, 2014, 12:53 PM UTC

I found the counter-argument made in the first reply to be more compelling. 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.

Re: Clang and FSF's strategy

#32

Post by dalke » Wed, Jan 22, 2014, 12:54 PM UTC

e12e wrote: post #26

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, in…

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... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Group) and PGI (The Portland Group).

Re: Clang and FSF's strategy

#33

Post by fulafel » Wed, Jan 22, 2014, 1:00 PM UTC

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

Re: Clang and FSF's strategy

#34

Post by vadiml » Wed, Jan 22, 2014, 1:06 PM UTC

e12e wrote: post #26

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, in…

Xcode is clang based

Re: Clang and FSF's strategy

#35

Post by unmole » Wed, Jan 22, 2014, 1:06 PM UTC

ja30278 wrote: post #31

I found the counter-argument made in the first reply to be more compelling. 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.

Hear, hear!

Re: Clang and FSF's strategy

#36

Post by asb » Wed, Jan 22, 2014, 1:08 PM UTC

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

Re: Clang and FSF's strategy

#37

Post by Fede_V » Wed, Jan 22, 2014, 1:18 PM UTC

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.

Re: Clang and FSF's strategy

#38

Post by dded » Wed, Jan 22, 2014, 1:37 PM UTC

dalke wrote: post #32

e12e wrote: post #26

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, in…

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... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Gr…

I'm not part of the Ada world, so I don't actually know, but I thought the important Ada compiler(s) were also proprietary.

Re: Clang and FSF's strategy

#39

Post by vonbladet » Wed, Jan 22, 2014, 1:54 PM UTC

Devid2014 wrote: post #28

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 d…

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

Re: Clang and FSF's strategy

#40

Post by teddyh » Wed, Jan 22, 2014, 1:55 PM UTC

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)

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