Notice Stallman's revised comment at the head of the article:
"Since this article was first published, Sun has relicensed most of its Java platform reference implementation under the GNU General Public License, and there is now a free development environment for Java. Thus, the Java language as such is no longer a trap."
This case is among few high-profile instances in which the GPL may not be free enough -- that is, Oracle may have a strong claim despite Sun's licensing of much of the JVM and JDK under the GPL, because the provisions of the license only extend to VMs which fully implement the Java spec. The license grant for the Java specification explicitly does not apply to VMs implementing a sub- or super-set.
See the patent grant released in Dec 2006 [1] – specifically the portion where it's stated that the implementor must "not modify, subset, superset or otherwise extend the Licensor Name Space," and that the VM must "[pass] the Technology Compatibility Kit." Under this interpretation, Google's App Engine platform might also be considered non-compliant, depending on the underlying VM.
While I personally choose to release code under BSD or MIT-style licenses to avoid the GPL's viral restrictions, it is interesting to consider cases where liberal licensing alone is not enough to ensure the liberty of a platform.
The GPL version 3 includes a similar clause. You don't have to give up your patents. You just have to license them to anyone who has rights to use the code from a copyright perspective. If I understand it correctly, this gives the GPL sharper teeth, since someone who violates the GPL not only loses the distribution/derivative rights from the copyright license, but also the patent license.
Hmm... so you could use patents as a club to enforce dual licensing with GPLv3 then. Violate the GPL and you lose your patent license, so now you're a patent infringer too. At the same time, you're FOSS-friendly since your patents are meaningless to FOSS projects.
The only way to fully comply with GPLv2 - giving the right to redistribute to your downstream users - is to refrain to use patents to curb the right of your downstream users.
If Google makes a GPLv2-derived product P of a GPLv2-licensed thing T, the owner of the T cannot enforce patent rights on P because the license states they gave Google the right to redistribute T-derived stuff under the same conditions.
Unless I misremember, Sun never did give Apache a license to the Java Technology Compatibility Kit. I looked into their policy at around the time they got bought for issuing licenses and it was very restrictive.
One wonders what Oracle policy going forward will be WRT supplying any TCK licenses....
"Since this article was first published, Sun has relicensed most of its Java platform reference implementation under the GNU General Public License, and there is now a free development environment for Java. Thus, the Java language as such is no longer a trap."
This case is among few high-profile instances in which the GPL may not be free enough -- that is, Oracle may have a strong claim despite Sun's licensing of much of the JVM and JDK under the GPL, because the provisions of the license only extend to VMs which fully implement the Java spec. The license grant for the Java specification explicitly does not apply to VMs implementing a sub- or super-set.
See the patent grant released in Dec 2006 [1] – specifically the portion where it's stated that the implementor must "not modify, subset, superset or otherwise extend the Licensor Name Space," and that the VM must "[pass] the Technology Compatibility Kit." Under this interpretation, Google's App Engine platform might also be considered non-compliant, depending on the underlying VM.
While I personally choose to release code under BSD or MIT-style licenses to avoid the GPL's viral restrictions, it is interesting to consider cases where liberal licensing alone is not enough to ensure the liberty of a platform.
[1] http://java.sun.com/javase/6/jdk-6u21-doc-license.txt