Perhaps the key point here is that there are not 'white knights' or people without stain in this particular fight.
As someone who was there I can tell you the fact is that Sun was going to flush Java down the toilet at the end of Fiscal Year 1995 (June 30th), they had no idea how to monetize it. And when SGI and Microsoft paniced when it got out, well it became a bludgeoning club which they used to bludgeon people they didn't like. And all of the efforts to make it a language for lots of purposes like C or C++ (when is the last time someone got sued by AT&T for making a C compiler?) got tossed into the bucket in the name of bludgeoning.
Bill Joy asserted for a while that the JVM would execute byte code (with the assistance of HotSpot and some other bit of secret sauce that never actually happened) faster than compiled native code. Later when gcj was released (Java to native machine code compiler) that code ran faster than hot spotted code, and it loaded quicker too.)
Google on the other hand knew it was leveraging something it had the code to (and like a third of the original team) and yet it often takes a very literal interpretation on license requirements when that interpretation suits them. An example of that was the lack of any requirement to put any of their changes to Linux back into the repo because they didn't "ship" Linux, they just used it in house. Now a number of engineers were very annoyed at maintaining things that they didn't want to maintain and that forced things to be pushed upstream but that was commit by pain, not commit by intent.
So I really resonate with the comment James made that there isn't anyone with clean hands in this fight. But there are a lot of egos out there.
Google on the other hand knew it was leveraging something it had the code to (and like a third of the original team) and yet it often takes a very literal interpretation on license requirements when that interpretation suits them.
They had the code but they didn't use it, so the license doesn't apply to them. It's not an interpretation of the license at all.
An example of that was the lack of any requirement to put any of their changes to Linux back into the repo because they didn't "ship" Linux, they just used it in house.
That's not their interpretation, that's the FSF's interpretation. The GPL does not, and has never required anyone to "contribute back". Its whole purpose was always to "pay forward" by giving your users the same rights you got. If you're your only user, you don't have to share the code to anyone.
Straight from the horse's mouth in the GPLv2 FAQ:
Does the GPL require that source code of modified versions be posted to the public?
The GPL does not require you to release your modified version. You are free
to make modifications and use them privately, without ever releasing them.
This applies to organizations (including companies), too; an organization can
make a modified version and use it internally without ever releasing it
outside the organization.
>The GPL does not, and has never required anyone to "contribute back". Its whole purpose was always to "pay forward" by giving your users the same rights you got. If you're your only user, you don't have to share the code to anyone.
Oh come on, that's clearly against the spirit of the license. The central point that the FSF makes is that all software should be open (as in, the source code should be freely available). Paying forward the rights that you got (to view and modify the source code) means allowing others to view and modify the source code.
I disagree. Their point is that the user should always be able to share, modify and run the software they have, not that they should have access to every line of code written. Again, from the GNU project:
In general we do not believe it is wrong to develop a program and not release
it. There are occasions when a program is so useful that withholding it from
release is treating humanity badly. However, most programs are not that important,
so not releasing them is not particularly harmful. Thus, there is no conflict
between the development of private or custom software and the principles of the
free software movement.
Nearly all employment for programmers is in development of custom software;
therefore most programming jobs are, or could be, done in a way compatible
with the free software movement.
I doubt their modifications to the kernel (remember we're not talking about userspace stuff here) are "so useful that not releasing them is treating humanity badly".
As someone who was there I can tell you the fact is that Sun was going to flush Java down the toilet at the end of Fiscal Year 1995 (June 30th), they had no idea how to monetize it. And when SGI and Microsoft paniced when it got out, well it became a bludgeoning club which they used to bludgeon people they didn't like. And all of the efforts to make it a language for lots of purposes like C or C++ (when is the last time someone got sued by AT&T for making a C compiler?) got tossed into the bucket in the name of bludgeoning.
Bill Joy asserted for a while that the JVM would execute byte code (with the assistance of HotSpot and some other bit of secret sauce that never actually happened) faster than compiled native code. Later when gcj was released (Java to native machine code compiler) that code ran faster than hot spotted code, and it loaded quicker too.)
Google on the other hand knew it was leveraging something it had the code to (and like a third of the original team) and yet it often takes a very literal interpretation on license requirements when that interpretation suits them. An example of that was the lack of any requirement to put any of their changes to Linux back into the repo because they didn't "ship" Linux, they just used it in house. Now a number of engineers were very annoyed at maintaining things that they didn't want to maintain and that forced things to be pushed upstream but that was commit by pain, not commit by intent.
So I really resonate with the comment James made that there isn't anyone with clean hands in this fight. But there are a lot of egos out there.