Sun, Java and GPLv2
I just posted a comment on Cringely's pulpit which (a) ended up being a little long and (b) had its formatting dropped. Here is what it was supposed to look like:
> Because this isn't your father's GPL,
> that's why. Sun put Java under GPL v.2,
> which gives the original licensor some
> unique rights.
Gnu GPLv2 is now 15 years old and covers substantially _ALL_ software that's under any version of the Gnu GPL (indeed, I had trouble locating a copy of the text of GPLv1). This has been the case since before the term "open source" entered wide use.
(It's possible that you're thinking about GPLv3 but (a) it's still a draft and (b) it's even more hostile to the sort of co-opting that you describe.)
What Sun's actually done, and what almost no company before them has done, is to bend over backwards to do this right. They've resisted the siren-song of corporate counsel who feel the need to FUD their employer into paying them to invent entirely new legalise, which doesn't interoperate with anyone else's legalise. (My own failure to convince Zawinski that a GPL dual-license was a good thing for Mozilla still smarts; it meant that for the first couple of years of the Mozilla project (until dual-licensing took place, after Zawinski quit), Gnome developers were shut out completely. This experience has perhaps biased me, but to see a major corporate source drop done right is fantastic.)
Further, note that Sun hasn't merely pinned the tail on a politically-correct GPLv2 donkey, they've gone through this in excruciating detail to get it just right. Instead of taking the "obvious" LGPLv2.1 option for the libraries, they've taken note of the existing practice by other open-source Java projects and adopted GPLv2 with "the classpath exception". With respect to the transition period for their own libraries (they hold outright copyrights in the compiler and VM, but the libraries contain encumberances which will take time to remove, so they've not made a library release yet), they've worked with the Software Freedom Law Center to craft a specific exemption that avoids trapping applications atop the standard APIs becoming GPLv2 encumbered when shiped _with_ the open-source Sun VM under GPLv2 and closed Sun libraries.
The legal groundwork that they've done is exemplary; it's really, really impressive. Someone inside Sun has asked some open-source/free-software advocates how it _should_ be done, and then listened very closely to the answer(s).
> Say you extend Java, under GPLv2 the way to
> give your improvements to the world is by
> giving them back to Sun.
No, your obligation is to make the complete source for the modified work available to your own licensees under the terms of the GPLv2. Note that Sun will not accept contributions into their _own_ source tree unless you sign a contribution agreement granting them what amounts to co-ownership. (You lose no rights, other than the right to sue Sun for using your work; Sun gains equal rights.) This is actually a weaker requirement than the FSF itself requires for contributions to the GNU project (they require outright assignment). In Sun's case it allows them to solve the sticky problem of continuing to service their paying customers for whom GPLv2 is a non-option (primarily embedded software developers). I wish I'd known about this variant of dual-licensing in 1998!
(Note also that Sun has the good sense/fortune to own almost the entire JRE+JDK outright; Mozilla had far more encumberances in 1998, so the GPLv2 was never going to work as the only option. They ended up releasing an eviscerated source tree anyway (wouldn't even build), but this is as much about how widespread the encumberances were as about licensing limitations. This takes nothing away from the brilliance of what Sun has actually done.)
> Or, if you'd like to keep those changes to
> yourself, it requires negotiating a non-GPL
> license with Sun, which means you'll have to
> PAY Sun to USE YOUR OWN CODE.
Here copyright and property concepts get a little muddled (and thus Stallman's railing against the term "intellectual property"). If you keep your changes to yourself, or only distribute them within your own organisation, then the GPL does not oblige you to do anything. Indeed it cannot, as a naked license (not a contract/agreement), it cannot impose obligations unless you are performing an act (e.g. distribution) that is controlled by copyright law. Note that "use" is _not_ controlled by copyright law, and therefore not restricted by GPL.
On the other hand, if you want to take Sun's source, create a derivative work and distribute it without GPL obligations then, yes, Sun offers an option which involes money changing hands. Note that the difference with other projects using the GPL (Linux, GNU toolchain, EMACS, ...) is that there is _no_ legal way to distribute your derivate work without GPL obligations (most projects' copyrights are too widespread to get get unanimous consent (not hypothetical; it's actually been tried with the Linux kernel) and the FSF would point-blank refuse), so Sun is providing an additional option (for a fee) not extracting monies for activities that would otherwise be free of charge.
> Under GPLv2 Sun benefits significantly more
> than it would have under the original GPL.
No, GPLv2 was essentially a cleanup of GPLv1.
> Sun controls the code, it controls forking,
No, it doesn't. Anyone is free to fork it tomorrow. Seriously.
> and anyone who wants a special deal has to pay.
True, this option exists. For most projects using GPLv2, anyone who wants a special deal simply can't get one. This plays nicely into the hands of proprietary software developers. Sun's approach avoids this competitive exposure.
> For a product that was generally given away,
> anyway, going with GPLv2 will probably make
> Sun more money -- probably a LOT more money
> -- than the company would have made by
> keeping the source closed.
Perhaps. The JRE+JDK was a loss-leader from the outset; the intent was to get adoption as widespread as possible so that they could sell related products and services. Sadly, they were obsessively focussed on preventing forks, which meant no open-source licensing, which severely curtailed reach amongst their largest natural constituency (developers with horizons wider than "we use it because it comes from Microsoft"). Sun has at last realised this error, realised that trademark law makes it possible to prevent forks from creating confusion, perhaps even realised that the ability to fork is a good thing, not a bad thing (Stallman himself opposed the EGCS changes to gcc, until that group forked gcc, refined the approach and convinced everyone that it was a better approach; Stallman finally relented, so EGCS is now known as gcc version 3).
So, big picture, yes, if opening the most widely used Java implementation (a) releases a lot of pent up demand (there was so much that there are already open-source implementations of most of the JRE+JDK) and, (b) more importantly, leads to the embrace of Java by a lot of open-source developers who have to date carefully avoided it because of Sun's stance, then yes, the platform's presence will enlarge and Sun's related-products-and-services revenue will increase substantially. This is good for Sun, good for the open-source community and good for the free-software movement. In fact it's good for just about everyone except Microsoft.
> Because this isn't your father's GPL,
> that's why. Sun put Java under GPL v.2,
> which gives the original licensor some
> unique rights.
Gnu GPLv2 is now 15 years old and covers substantially _ALL_ software that's under any version of the Gnu GPL (indeed, I had trouble locating a copy of the text of GPLv1). This has been the case since before the term "open source" entered wide use.
(It's possible that you're thinking about GPLv3 but (a) it's still a draft and (b) it's even more hostile to the sort of co-opting that you describe.)
What Sun's actually done, and what almost no company before them has done, is to bend over backwards to do this right. They've resisted the siren-song of corporate counsel who feel the need to FUD their employer into paying them to invent entirely new legalise, which doesn't interoperate with anyone else's legalise. (My own failure to convince Zawinski that a GPL dual-license was a good thing for Mozilla still smarts; it meant that for the first couple of years of the Mozilla project (until dual-licensing took place, after Zawinski quit), Gnome developers were shut out completely. This experience has perhaps biased me, but to see a major corporate source drop done right is fantastic.)
Further, note that Sun hasn't merely pinned the tail on a politically-correct GPLv2 donkey, they've gone through this in excruciating detail to get it just right. Instead of taking the "obvious" LGPLv2.1 option for the libraries, they've taken note of the existing practice by other open-source Java projects and adopted GPLv2 with "the classpath exception". With respect to the transition period for their own libraries (they hold outright copyrights in the compiler and VM, but the libraries contain encumberances which will take time to remove, so they've not made a library release yet), they've worked with the Software Freedom Law Center to craft a specific exemption that avoids trapping applications atop the standard APIs becoming GPLv2 encumbered when shiped _with_ the open-source Sun VM under GPLv2 and closed Sun libraries.
The legal groundwork that they've done is exemplary; it's really, really impressive. Someone inside Sun has asked some open-source/free-software advocates how it _should_ be done, and then listened very closely to the answer(s).
> Say you extend Java, under GPLv2 the way to
> give your improvements to the world is by
> giving them back to Sun.
No, your obligation is to make the complete source for the modified work available to your own licensees under the terms of the GPLv2. Note that Sun will not accept contributions into their _own_ source tree unless you sign a contribution agreement granting them what amounts to co-ownership. (You lose no rights, other than the right to sue Sun for using your work; Sun gains equal rights.) This is actually a weaker requirement than the FSF itself requires for contributions to the GNU project (they require outright assignment). In Sun's case it allows them to solve the sticky problem of continuing to service their paying customers for whom GPLv2 is a non-option (primarily embedded software developers). I wish I'd known about this variant of dual-licensing in 1998!
(Note also that Sun has the good sense/fortune to own almost the entire JRE+JDK outright; Mozilla had far more encumberances in 1998, so the GPLv2 was never going to work as the only option. They ended up releasing an eviscerated source tree anyway (wouldn't even build), but this is as much about how widespread the encumberances were as about licensing limitations. This takes nothing away from the brilliance of what Sun has actually done.)
> Or, if you'd like to keep those changes to
> yourself, it requires negotiating a non-GPL
> license with Sun, which means you'll have to
> PAY Sun to USE YOUR OWN CODE.
Here copyright and property concepts get a little muddled (and thus Stallman's railing against the term "intellectual property"). If you keep your changes to yourself, or only distribute them within your own organisation, then the GPL does not oblige you to do anything. Indeed it cannot, as a naked license (not a contract/agreement), it cannot impose obligations unless you are performing an act (e.g. distribution) that is controlled by copyright law. Note that "use" is _not_ controlled by copyright law, and therefore not restricted by GPL.
On the other hand, if you want to take Sun's source, create a derivative work and distribute it without GPL obligations then, yes, Sun offers an option which involes money changing hands. Note that the difference with other projects using the GPL (Linux, GNU toolchain, EMACS, ...) is that there is _no_ legal way to distribute your derivate work without GPL obligations (most projects' copyrights are too widespread to get get unanimous consent (not hypothetical; it's actually been tried with the Linux kernel) and the FSF would point-blank refuse), so Sun is providing an additional option (for a fee) not extracting monies for activities that would otherwise be free of charge.
> Under GPLv2 Sun benefits significantly more
> than it would have under the original GPL.
No, GPLv2 was essentially a cleanup of GPLv1.
> Sun controls the code, it controls forking,
No, it doesn't. Anyone is free to fork it tomorrow. Seriously.
> and anyone who wants a special deal has to pay.
True, this option exists. For most projects using GPLv2, anyone who wants a special deal simply can't get one. This plays nicely into the hands of proprietary software developers. Sun's approach avoids this competitive exposure.
> For a product that was generally given away,
> anyway, going with GPLv2 will probably make
> Sun more money -- probably a LOT more money
> -- than the company would have made by
> keeping the source closed.
Perhaps. The JRE+JDK was a loss-leader from the outset; the intent was to get adoption as widespread as possible so that they could sell related products and services. Sadly, they were obsessively focussed on preventing forks, which meant no open-source licensing, which severely curtailed reach amongst their largest natural constituency (developers with horizons wider than "we use it because it comes from Microsoft"). Sun has at last realised this error, realised that trademark law makes it possible to prevent forks from creating confusion, perhaps even realised that the ability to fork is a good thing, not a bad thing (Stallman himself opposed the EGCS changes to gcc, until that group forked gcc, refined the approach and convinced everyone that it was a better approach; Stallman finally relented, so EGCS is now known as gcc version 3).
So, big picture, yes, if opening the most widely used Java implementation (a) releases a lot of pent up demand (there was so much that there are already open-source implementations of most of the JRE+JDK) and, (b) more importantly, leads to the embrace of Java by a lot of open-source developers who have to date carefully avoided it because of Sun's stance, then yes, the platform's presence will enlarge and Sun's related-products-and-services revenue will increase substantially. This is good for Sun, good for the open-source community and good for the free-software movement. In fact it's good for just about everyone except Microsoft.
<< Home