Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang and FSF's strategy

gcc.gnu.org

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Clang and FSF's strategy

#111

Post by frezik »

cwyers wrote: post #79
frezik wrote: post #62

Earlier quoted context omitted.

Seems like ESR is still fighting the Open Source vs Free Software battle of the late 90s. It hasn't dawned on him yet that everyone else thinks that there's little purpose in cannibalizing the movement over minor philosophical differences.

By "everybody else" I think you're excluding the people who run the Free Software Foundation, in other words the very people ESR was addressing.

Not really. Even RMS only mentions the distinction in passing. The fight has simply gone out of this one for everyone who isn't ESR, probably because the late 90s was the last time he was relevant.

Re: Clang and FSF's strategy

#112

Post by mcguire »

dragonwriter wrote: post #90
chimeracoder wrote: post #55

Earlier quoted context omitted.

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

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

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

Re: Clang and FSF's strategy

#113

Post by teddyh »

asdasf wrote: post #72
teddyh wrote: post #40

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.

No, it is not still true. It was never true. It is pure FUD. Apple has absolutely no way to "close the development" of llvm. Why do GPL zealots still post such crappy FUD even when MIT/BSD/apache/ISC licensed projects make up a massive portion of the infrastructure of the net, and no magical closing has ever managed to cause any problems at all?

Well, strictly speaking, neither one of us can be sure what would happen. It’s just what I think would happen. Is it “FUD” if I still really believe it? I don’t know.

And speaking of closing; just look at Android with its complete anti-GPL, purged system. Only Linux remains there.

Of course, I (or you) can’t prove anything either way, but I have the feeling of Google, Apple, and the rest of the permissive license promulgators all the time going “Relax, it’s fine now, the war is over, you can all go home! You won!” And if we turn our backs, if we relax in our supposed victory, we will slowly find that all the contributors to these better (completely coincidentally non-GPL) projects are mostly employees of these same companies, and they all have CLAs. And one fine day they will turn off the freedom and turn it all proprietary. We then cannot hope of competing with the current project owners, since they have all the experience and infrastructure.

Re: Clang and FSF's strategy

#114

Post by teddyh »

anon1385 wrote: post #61
teddyh wrote: post #40

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.

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.

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

Re: Clang and FSF's strategy

#115

Post by teddyh »

anon1385 wrote: post #74
teddyh wrote: post #47

Earlier quoted context omitted.

The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.

Apple is not the largest contributor to LLVM, Google is. The various other non-Apple contributors also outweigh Apple. It would be hugely expensive for Apple to hire all those compiler developers from Google and Intel and dozens of other companies. Why would they do it? What would it gain them other than to be comically villainous. The reality is that GCC is stagnating because a lot of things people want to do are ju…

So substitute “Apple” with “Google, Apple, Intel, etc.” in my original dystopic vision. Should we trust them?

The technical problems with GCC’s unstable plugin API can be fixed, and is, from what I understand, not something put there intentionally.

Re: Clang and FSF's strategy

#116

Post by teddyh »

pjmlp wrote: post #48
teddyh wrote: post #40

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.

Lets not forget the private war Steve Jobs had on FSF for being forced to release the NeXT Objective-C frontend to gcc, if I remember the events correctly.

“Forced to release” does not really describe what happened. It was more like NeXT thought they could take GCC, extend it to compile Objective C and make NeXT’s version of GCC proprietary. When the FSF told them, using lawyers, that NeXT could not, in fact, blatantly violate the GPL, NeXT could have chosen not to release their version and use another compiler for Objective C. But they chose to release their Objective C compiler under the GPL, which was their other option.

This is what happens when you don’t read the license, think that things like copyright doesn’t apply to things you get off the internet, and dig yourself into a hole – your options are limited. But releasing the code as GPL was never their only option, is what I’m saying.

Re: Clang and FSF's strategy

#117

Post by teddyh »

asdasf wrote: post #73
teddyh wrote: post #47

Earlier quoted context omitted.

The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.

The open one would stagnate because it has over 3 times as many developers, writing over 3 times as much code? You seriously think that?

No, I think that the proprietary one would get all the company contributors, and therefore have the lion’s share of developers.

Re: Clang and FSF's strategy

#118

Post by protomyth »

fafner wrote: post #110
protomyth wrote: post #95

Earlier quoted context omitted.

I guess I see it a bit different and GCC is a pretty good example. 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 s…

> 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. That's simply not true.

So, if Apple had incorporated GCC's parser into Xcode like they have included clang's, what would have been the effect?

Re: Clang and FSF's strategy

#119

Post by asdasf »

teddyh wrote: post #117
asdasf wrote: post #73

Earlier quoted context omitted.

The open one would stagnate because it has over 3 times as many developers, writing over 3 times as much code? You seriously think that?

No, I think that the proprietary one would get all the company contributors, and therefore have the lion’s share of developers.

The apple employees working on it are the minority, that is the point. If apple decided to have their employees work on a closed source fork, they would have less than 25% of the current developers of LLVM/clang working on their compiler. LLVM/clang would still have the other 75%+.

Re: Clang and FSF's strategy

#120

Post by fafner »

protomyth wrote: post #118
fafner wrote: post #110

Earlier quoted context omitted.

> 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. That's simply not true.

So, if Apple had incorporated GCC's parser into Xcode like they have included clang's, what would have been the effect?

They would have to honour GCC's license, like they have to do with clang's license or any other piece of software.
Post reply on HN