Is Java open source now or what?
James Gosling wrote in his weblog "If we do something to make Java even more open-source than it is already, having safeguards to protect the developer community will be something we pay a lot of attention to."
Well, I'm a curious person. I'm usually up-to-date with what's happening in the Java world, so I figured I must have missed the day Java became open source. Alas, I decided to put the great James Gosling to a test. My tools will be the Open Source definition version 1.9 and the Sun Community Source License version 2.3.
Since James talks about making Sun's Java implementation "even more open-source", let's see how open source Sun's code already is, by checking each clause of the open source definition against the SCSL.
Open Source Definition vs. SCSL
* Free Redistribution
Nope.
* Source Code
Doesn't allow free redistribution, so redistribution in source code fails, too.
* Derived Works
Nope.
* Integrity of The Author's Source Code
Doesn't allow free distribution of separate modifications either.
* No Discrimination Against Persons or Groups
I guess it passes that one, yay!
* No Discrimination Against Fields of Endeavor
Nope. Explicitely limits fields of endeavor to research, commercial use, or internal use.
* Distribution of License
Nope. The TCK license comes with what's effectively a NDA.
* License Must Not Be Specific to a Product
I guess it passes that one, yay!
* License Must Not Restrict Other Software
Nope. Once you've agreed to SCSL, you can't distribute non-compliant software. So you couldn't redistribute kaffe, gcj, or even more up-to-date versions of Xerces if they break tests in the TCK.
* License Must Be Technology-Neutral
Nope. It's a click-wrap license. It even has a pointless [ACCEPT] [REJECT] at the bottom
Total: 2 out of 10.
I'd guess that Sun's java implementation is slightly more open source than my Microsoft Windows 98SE installation CD-ROM. I haven't bothered to check the Microsoft Windows 98SE EULA, though, so I may be wrong.
Protecting Java developers with SCSL: The Top 5 Safeguards
But wait, there is more. The SCSL is a fascinating read if you're into mind-boggling legalese that's being marketed as 'sort of open-source'. I'll do you the favour and post the funniest bits and pieces on how the SCSL protects the Java developers.
Top 5: Debugging your Java code can violate the license
People often think that the SCSL is there to prevent forking and stealing of Java. That's not the whole deal, as the following exhibit from the SCSL shows:
GLOSSARY, 1:"Commercial Use" means any use (excluding Internal
Deployment Use) or distribution, directly or indirectly of
Compliant Covered Code by You to any third party, alone or
bundled with any other software or hardware, for direct or
indirect commercial or strategic gain or advantage, subject
to execution of Attachment D by You and Original
Contributor.
So let's say you're writing a J2SE application for a customer, and debugging it in one of those friendly IDEs that allow you to trace through system library code. You see in system code why it breaks, and discover there is some facet of the API that was not well documented in the J2SE docs, that breaks your code. You fix your code to work around it, and ship it to the customer.
Congratulations, you've just violated the SCSL, unless you've got a commercial license use with Sun, since your use of SCSL covered code is no longer limited to your company.
You'd need to enter a real, written contract with Sun, that costs hard cash, indemnifies Sun, allows them to inspect your bookkeeping, and a lot of other interesting things. Of course, the commercial license in Attachment D does not really allow you to debug Sun's code anyway.
Top 4: All Your Java Are Belong To Sun
GLOSSARY, 13. "Modification(s)" means (i) any change to Covered Code;
(ii) any new file or other representation of computer
program statements that contains any portion of Covered
Code; and/or (iii) any new Source Code implementing any
portion of the Specifications.
13(i) is your normal copyright law. 13(ii) is your normal copyright law with an extra spin: it tries to prohibit fair use by claiming that containing *any portion* of SCSL covered code turns your code into a modification of SCSL covered code.
Given that you're writing your code in java, chances are that any class you write shares a certain amount of text with some SCSLd covered code, simply because they are written in the same programming language. So 13(ii) covers pretty much all java code ever written by anyone who licensed code under SCSL. To put more graphically, GLOSSARY,13(ii) == All your Java are belong to us
Let's get to 13(iii), which is a little more convulted. It says any *new* Source Code implementing *any portion* of the *Specifications*. New code is quite obvious, so it coveres all new code you write. Then we have a clarification, it's any new code you write that implements any portion of some specs. "implementing any portion of specs" doesn't say 'extending Object is OK', it says "there are some specs, you implement any single bit out of them, your code is covered". Both the JDK API spec and the JLS cover java.lang.Object's method signatures. If your code extends java.lang.Object, it implements "a portion" of the JLS and JDK API, since you can call the methods covered by the Object API on it. If that's too far fetched for you, take classes implementing the Serializable interface, or your classes extending SCSL covered classes, and overriding methods in them.
But the really convulted part of 13(iii) is in the reference to "Specifications". If we look up "Specifications" in the glossary, we'll find
GLOSSARY, 21. "Specifications" means the specifications for the
Technology and other documentation, as designated on the
Technology Download Site, as may be revised by Original
Contributor from time to time.
This clause gives the copyright owner (or whoever hacks the site) a backdoor to revise the specifications, and claim violation afterwards, even if you were compliant originally. The license does not specify the "Technology download site" precisely (with some URL) anywhere. It does specify the community source download site, but that one has no JDK specs. Beautyful.
Top 3: Shut up, And Don't You Dare To Write Tests
One of the cute things about Sun's Java implementation is that Sun has apparently written a huge set of test cases to verify the conformance of their implementation to the API specification. At least that's what the rumour says. If someone who licensed the TCK would really tell you if Sun's own VM passes the tests, he'd have to kill you, according to the license.
ATTACHMENT E TECHNOLOGY COMPATIBILITY KIT, 1. TCK License.:
b) TCK Use Restrictions. You are not authorized to create
derivative works of the TCK or use the TCK to test any
implementation of the Specification that is not Covered
Code. You may not publish your test results or make claims
of comparative compatibility with respect to other
implementations of the Specification. In consideration for
the license grant in Section 1.a above you agree not to
develop your own tests which are intended to validate
conformation with the Specification.
That's a NDA, as far as I can see it. You can not talk about your TCK results. You can not say that you're more TCK compatible than Sun for example, even if it was true. Noone can check how TCK compatible Sun's implementation is, and publish their findings.
So you can't take IBM's and Sun's runtimes and see which one is better wrt to TCK compliance on your particular system. Now you may be asking: why should I care, Java works everywhere ?
Except that it doesn't. It usually takes me a few minutes to crash Sun's. I bet it passed the TCK on the particular operating system version they tested it on last year, but operating systems change, security patches get applied, and whoops, the rock-solid JVM is no more rock-solid. But you can not test your client's specific os+vm setup with JDK TCK and share that information with your client, without breaching the TCK license. Beautyful.
On a side note, I especially appreciate the 'you may not write your own tests' clause. If you write your own test to find a bug in Sun's code that violates the spec, and submit a bug report to the BugParade, and have licensed the TCK, you've breached the license.
Top 2: Show Me Your Code, Or Else
Beside claiming ownership to all the code anyone who licensed the J2SE code from Sun, the SCSL has also a second ace up its sleeve to protect the mean Java developers from themselves: requiring access to all your extensions' interfaces. With your TCK due in 90 days. Or else.
3.e) Extensions.
(i) Covered Code. You may not include any Source Code of
Community Code in any Extensions;
(ii) Publication. No later than the date on which You first
distribute such Extension for Commercial Use, You must
publish to the industry, on a non-confidential basis and
free of all copyright restrictions with respect to
reproduction and use, an accurate and current specification
for any Extension. In addition, You must make available an
appropriate test suite, pursuant to the same rights as the
specification, sufficiently detailed to allow any third
party reasonably skilled in the technology to produce
implementations of the Extension compatible with the
specification. Such test suites must be made available as
soon as reasonably practicable but, in no event, later than
ninety (90) days after Your first Commercial Use of the
Extension. You must use reasonable efforts to promptly
clarify and correct the specification and the test suite
upon written request by Original Contributor.
(iii) Open. You agree to refrain from enforcing any
Intellectual Property Rights You may have covering any
interface(s) of Your Extension, which would prevent the
implementation of such interface(s) by Original Contributor
or any Licensee. This obligation does not prevent You from
enforcing any Intellectual Property Right You have that
would otherwise be infringed by an implementation of Your
Extension.
Basically, this means your extension's specification must be published "free of all copyright restrictions with respect to
reproduction and use", and so must be the TCK, i.e. the test code for your library. Why Sun fails to provide their TCK under similarly liberal terms is a very interesting question.
Anyway, for some added fun, 3.e.iii prohibts enforcing the GPL on your Java libraries if you agree to SCSL.
Top 1: All Your Libraries Are Nothing But Simple Extensions
Oh, and of course, the term Extension is so broadly worded that it covers all Java library code licensees ever wrote:
9. "Extension(s)" means any additional classes or other
programming code and/or interfaces developed by or for You
which: (i) are designed for use with the Technology; (ii)
constitute an API for a library of computing functions or
services; and (iii) are disclosed to third party software
developers for the purpose of developing software which
invokes such additional classes or other programming code
and/or interfaces. The foregoing shall not apply to
software development by Your subcontractors to be
exclusively used by You.
(i) covers all java code, (ii) reduces coverage to exported (i.e. public/protected) members, (iii) reduces coverage to libraries.
Unless the library code you ship to your clients consists of package-private classes and methods, you have to disclose your APIs and *write a freely available TCK* for it. I've never seen such things for most of the Java code out there, which strikes me as mildly weird. If the SCSL is so cool, you'd expect a lot of people documenting their "extensions", no?
Bonus Top For Consultancies: Keep Off The Javax
Oh well. So you decide to give up writing Java library code just to have it owned by Sun, and go into consulting to sell code other people wrote to your clients. No go, the SCSL has a weird package naming clause, that doesn't allow you to use what Sun considers to be its own namespace turf.
3.e.(iv) Class, Interface and Package Naming. You may not add
any packages, or any public or protected classes or
interfaces with names that originate or might appear to
originate from Original Contributor including, without
limitation, package or class names which begin with "sun",
"java", "javax", "jini", "net.jini", "com.sun" or their
equivalents in any subsequent class, interface and/ or
package naming convention adopted by Original Contributor.
The great thing about that clause is that it actually prohibits the distribution of J2EE servers with Sun's JVM by licensees of J2SE source code under SCSL.
A J2EE server implements packages in the javax namespace by definition. So going from 'start enterprise Java consulting' to 'jail' takes three simple steps:
- Step 1: license J2SE source code under SCSL
-
Step 2: Distribute JBoss to your client with Sun's JVM
-
Step 3: go to jail for voilating 3.e.iv.
Keep Trying, James
A license that's so broadly (and poorly, in my opinion) worded that it allows such (unintentional, I assume) interpretation should be reworded in a cleaner fashion, really. It's very, very far from open source. It doesn't even protect Java developers from anything, it just puts them under extra legal risk, and makes abstruse claims of code ownership, not unsimilar to those of SCO in the IBM case.
While I don't think Sun's management would try to enforce the SCSL to the letter, it would be quite funny if Microsoft bought Java from a bankrupt Sun, and then went ahead to enforce the SCSL against developers who accepted the license if they wouldn't switch to dotNet.
Meanwhile, ...
There was a new GNU Classpath release that looks very good. A new Kaffe OpenVM release is in preparation, too.
No "safeguards", there, though. We couldn't make either "even more open-sorce" then they already are, being licensed under GPL(Kaffe) and GPL+linking exception(Classpath).
