Hacker News Reader

Comment by rbanffy | Hacker News Reader

Clang/LLVM is BSD while GCC is GPL. That means Apple can extend them all they want without ever giving you, or their competition, any sources.

If they ever perceive a threat from their competition, Clang/LLVM provides a lot more maneuvering space than GCC ever would.

And yes, GCC is a very hard thing to integrate into tools and it's that way by design.

View on HN

I would like to point out that Apple employs the guy that builds LLVM/clang and all those projects and yet they are still releasing the source code and everything out there for the public to use.

My appologies for accidental down vote instead of up vote. :(

Oh, I think I'll live :-). Apology accepted! Cheers mate!

> Apple employs the guy that builds LLVM/clang

Curious. Is the copyright Apple's?

The copyright belongs to each contributor: http://llvm.org/docs/DeveloperPolicy.html#copyright

> That means Apple can extend them all they want without ever giving you, or their competition, any sources.

It mostly means that they can use the libraries without having to open-source Xcode itself. A compiler is not exactly a competitive advantage for a company as big as Apple.

> And yes, GCC is a very hard thing to integrate into tools and it's that way by design.

Uh yes and?

> It mostly means that they can use the libraries without having to open-source Xcode itself.

LGPL would be fine for that.

Yeah, but why bother? It's not like Apple has any reason to go LGPL (and actually, now that I looked it up Clang seems to use the same license as LLVM — which makes sense — and that's the University of Illinois/NCSA Open Source License not the 3-clauses BSD, which again makes sense considering LLVM got started at UIUC, so it's not even Apple who decided on the license of the LLVM suite and related tools, they got into LLVM years after the project started and just used the same license for the stuff they built on/around LLVM)

http://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Ope...

Looks a lot like a 3-clause BSD, but it's a cross between MIT and BSD. The point on LGPL is that if GCC were LGPL, Apple would be able to link it to Xcode.

On an afterthought, I wonder how much patent protection clang/llvm's license provide for downstream users.

"A compiler is not exactly a competitive advantage for a company as big as Apple."

Apple might not make money directly with its compiler, but for its 3rd party developers to be stuck with a mediocre compiler is definitely a disadvantage for Apple.

Hypothetical: The hardware under the hood is identical to that of a Dell. Compare an application written for both, but the one running on the Dell uses Intel's highly optimized compiler while Apple uses one that's not tuned for any particular platform, and therefore performs somewhat poorly on x86.

Result: Apple has a 20% performance deficit.

Now say that application is Photorealistic RenderMan or Cinema4D or Modo.

That 20% performance deficit, that has nothing to do with the hardware, just created a significant cost disadvantage for a mac user -- to implement a renderfarm, the mac adds either 20% in rendering time, or 20% in extra hardware costs to offset the rendering time (which ends up costing more still in logistics).

Result? Apple would lose a potentially non-trivial sale.

Having an optimized in-house compiler would probably also help to improve OpenGL performance on the mac -- because odds are the entire OS is compiled with the same compiler...

Though it may not be a significant direct revenue generator, having a good compiler would probably still be very beneficial for Apple AND its customers, not to mention developers.

> Having an optimized in-house compiler

Not only that, but making tweaks and optimizations (remember that Apple's compiler has to target a very narrow subset of what general Clang, or GCC, target) to an internal version even while releasing the sources for the "base" version would also give Apple a competitive advantage.

Since they own the product, the licence would not bother them much - they could just relicense it - but I assume that by using GPL they would be educating their customers in subjects they would rather keep them ignorant.

edit: Apple doesn't own Clang or LLVM. Copyright belongs to individual contributors. However, since it's BSD, Apple's ability to tune a "secret-sauce" version to its hardware is unhindered.

Somewhat of an aside, but because Apple jumped to x86 late in the game, they can make more assumptions about their CPU than Windows can (for example, all Intel processors on Macs have SSE2 or higher).

64-bit processors allow similar assumptions on Windows, too.

And yes, GCC is a very hard thing to integrate into tools and it's that way by design.

Any reference for that claim? This would seem to be an absurd design decision. It's more work to design this way but the benefits are enormous.

http://gcc.gnu.org/wiki/GCC_Plugins gives some background.

GCC has always been a centerpiece in the plan for the "viralization" of the GPL, and support for its role in this plan has always driven design decisions in GCC. This policy has caused a lot of headaches even just within the free software community (eg. http://lwn.net/Articles/343608/).

I can't find a citation for this at the moment, but RMS has said on several occasions that GCC has to be difficult to integrate into other tools just for the sake of pushing the GPL. For example, this was his explanation for why improvements to GCC's intermediate representation formats (GIMPLE and friends) were refused for a long time.

...RMS has said on several occasions that GCC has to be difficult to integrate into other tools just for the sake of pushing the GPL. For example, this was his explanation for why improvements to GCC's intermediate representation formats (GIMPLE and friends) were refused for a long time.

Weird. Though not as bad as the worst of Microsoft's shenanigans, this strikes me as in the same class of uncivil moves that the FSF complains about proprietary software vendors pulling.

> this strikes me as in the same class of uncivil moves that the FSF complains about proprietary software vendors pulling

Why? Did you buy a copy of GCC?

Making your software hard to interface with is making it less open. It's the same sort of move as making your word processor use an incompletely documented binary format.

> Making your software hard to interface with is making it less open

We are using two different definitions of "open". Back in the 80's Unix was considered "open" because you could compile a program for various flavors and the various flavors could share data on the same network (contrary to other platforms of the time). GCC is open not because it runs on many platforms, but because you can freely inspect, change it and redistribute it. Those are two completely different meanings.

These are both important. Sometimes the letter of the law is convenient. Needing to resort to the letter of the law is not "open" -- a 3rd meaning!

It makes some sense if you view it from the perspective of users rather than developers. The FSF comes from the perspective of being interested in what rights/freedoms end users have to modify software they receive, which takes precedence over other concerns. So basically anything that would make it easier for developers to ship stuff that end users aren't allowed to hack is bad.

So basically anything that would make it easier for developers to ship stuff that end users aren't allowed to hack is bad.

But if end users are hacking stuff, then they are also developers. Replace "end users" with "developers" and it gets interesting:

"So basically anything that would make it easier for developers to ship stuff that developers aren't allowed to hack is bad."

So making it hard to hack X for people trying to make Y hard to hack is okay. Seems a bit weird.

Weird but plausible...

Reply on news.ycombinator.com