LLVM's license (http://llvm.org/docs/DeveloperPolicy.html#copyright-license-...) is much more like BSD than the GNU one ever was.
Of all the good reasons behind switching to Clang (or behind having a two-compiler ecosystem in general), "license purity" is IMHO the dumbest.
Believe me, recent GCC (4.7, 4.8) is worlds better than 4.2. We pine for something better.
Like I said, this argument is dumb. The fact that Very Important People With Decision Power are making dumb decisions doesn't make it less dumb. FreeBSD isn't really doing this to support their business customers (again, things like Android are existence proofs to the contrary), they're doing it to stick it to the FSF (c.f. some of the comments in this very thread. That's dumb.
(Which is not to argue that clang is a bad choice -- it isn't!)
This is precisly why FreeBSD chose this route. It was a deliberate communicated decision years ago from the FreeBSD Foundation. I wonder if you have ever heard this quote:
> I believe it is an established maxim in morals that he who makes an assertion without knowing whether it is true or false, is guilty of falsehood; and the accidental truth of the assertion, does not justify or excuse him.
--Abraham Lincoln
However, note that it doesn't _bundle_ it. And Google has gone to some lengths to produce their own non-[L]GPL libc (Bionic). As far as I know, the Android userland is pretty much a no-GPL zone these days.
We can discuss if one should be allowed to modify ones own property, but lets at least be clear if that is the discussion we have.
Finally a compiler comes along that shares the same license philosophy and can be imported wholesale WITHOUT having to worry about licensing issues due to changes that may need o be made.
If clang/llvm hadn't come along FreeBSD would have upgraded to a later version of GCC.
Patents. A company need to know if they have patents, or patent agreement covering the GCC compiler.
Binary only modifications to GCC need to have corresponding source code.
If you include a GCC compiler in a router/hardware device, users need to be able to run their own modified compiler.
Thats about it. Cant really figure out any more use cases where GCC and Clang would differ.
GCC is no longer a GPLv2 toolchain.
Right, which has been a sign that with GPLv3, GCC was on the way out for sure: if its not being kept current, it's got a limited lifespan.
> I was being specific, not making a point about GPLv3 (arguments against which I also view as dumb, FWIW).
The GPLv3 itself was shaped very much by the FSFs analysis of what it thought business users would require (filtered through the FSF's ideology -- see the limits on the applicability of the antitivoization for a key example.)
That FreeBSD would be shaped by its view of what business users want, without constraint by the FSF's ideology, should not be surprising, nor should it be surprising that that conflicts in irreconcilable ways from the FSF's view made concrete in the GPLv3.
Open-source, unix-like OS's for users whose visions align more with the FSF's views are readily available. (And nothing stops a sufficiently-motivated party from making a GPLv3, FreeBSD-derived, GCC-using OS if they really want it.)
Well, that's a viewpoint that welcomes open and reasonable discussion.