Re: GPL vs. sweatshops (was Re: Bias)

On Thu, 13 Jun 2002, Roger Fujii wrote:

> Exactly.  If you want a real world example of this, look at gcc on linux vs
> java.  Gcc is pretty much the only game in town.  You are stuck with its
> profilers, debuggers and code generation.  java, on the other hand, even
> though it's free (as in beer), has a wealth of diversity (forte, jbuilder,
> not to mention the small vendors) in development tools (and jvms, profilers,
> compilers, etc).  Any honest person cannot dismiss that GPL has a hand in
> this situation as the GPL denies any party from carving out a nitch to 
> attempt to make a living.  

It's not that simple.  Java has more competition in large part because IBM 
is spending a lot of money on Java technology to make sure Sun doesn't just 
take Microsoft's place as the industry's taskmaster.  (You gotta give IBM 
some credit -- they seem to have learned some lessons from history!)

On the other hand, who cares if GCC is the only game in town, when it comes 
to C compilers on Linux?  It's not putting a company in control at least, 
and despite the GPL, proprietary companies can use GCC to compile their 
proprietary applications.  There's no business incentive to compete with 
GCC under Linux.  (And because of the GPL, little incentive to improve GCC 
either.)

There are other free C compilers in the world (Small C, LCC, PCC, etc.) but 
none of them are as powerful and flexible (to my knowledge) as GCC, and C++ 
compilers are harder to find.  So, people tend to use GCC because that's 
the easiest thing to do.

> > Back around 1990-ish, GCC was generally considered to have one of the best
> > code generators out there; it was often better than proprietary compilers.
> 
> well, one should qualify that.  It was the best 68K (maybe VAX) compiler out
> there.  

Okay, I'll buy that.  (Regardless, it's ancient history now.)

> "good enough" isn't even the reason.  Look at SPARC64 - I'm not certain 
> if gcc 3.x(!) reliably generates code for that (though it must have safe 
> code paths as there are supposedly versions of BSD and linux that run on 
> it - though I can say for certain that 2.95.x certainly does NOT).  The 
> real reason is that as CPUs get more complicated, the compilers are also 
> more complicated to make and there aren't a huge number of people 
> qualified to work on it.  And, given the lack of financial incentive on 
> working on it, it's easy to show why the gcc is where it is today.

This sounds correct to me.