There was a post and comment thread on Javalobby/DZone (Did Sun C&D them to get the name changed too?) regarding the ASFs ongoing battle with Sun to secure a test kit for Apache Harmony. It's interesting because of the confusion that still exists surrounding the issue. It's worth a read through. Be sure to read my comments at the end, as I try to frame the problem around the core issue of spec lead obligations, and how Sun's behavior is threatening the JCP's ability to deliver "open" specifications.
Anyway, I saw the thread late, and when I was traveling to London for QCon and jetlagged and tired, so I skipped over Dalibor's response (as I know he understands the facts) and tried to address the comments from others.
Yesterday, someone suggested I read his response, as it represents a really unique change in Sun's positioning of the situation. I think it boils down to the following (my interpretation):
Sun is withholding TCK licenses from those of us doing independent implementations for our own good. Passing the tests is hard, Sun is very concerned about us, and Sun don't want us to waste time and resources.
In the thread, Dalibor says :
So why does Sun restrict the OpenJDK Community TCK to 'substantially derived' implementations? I wasn't at Sun when the license was conceived, but I think the obvious answer is that TCK testing is a lot of (manual) work, even when one is starting from a feature-complete implementation, like OpenJDK 6, and just needs to focus on setup, testing and bug fixing.
I keep reading this over and over, thinking "he didn't really just say that, did he? He must mean something else..." Later on, he says :
So, in a world in which any compatible free software Java SE 6 implementation in the foreseeable future is likely going to be substantially derived from OpenJDK 6 for very simple, rational economic reasons (it works well, it can be done on a rational schedule, etc.) - do you just toss the TCK binaries over the wall, or do you nurture the community of free software, fully compatible Java SE 6 implementations and work on gradually having a sequence of doable success stories, while expanding the clout of the platform? The latter approach works actually much better in practice, as experience shows, and has already delivered several fully compatible, fully free software Java SE 6 implementations.
This is such utter, self-serving nonsense, it's hard to know where to start. Let me throw a few facts into this :
- The only logical reason why "any compatible free software Java SE 6 implementation in the foreseeable future is likely going to be substantially derived from OpenJDK 6" is because Sun won't allow any other free or open implementation to get a TCK license. If people can't get a license for the test kit unless they agree to add Sun's terms to the license under which the implementation is distributed, then of course you won't see any other open implementations that are compatible, because Sun's additional terms aren't open. Without the TCK, you can't test compatibility. If you can't test compatibility, you can't be compatible. Nice how that works out for Sun, doesn't it?
- Sun has made the mistake of underestimating what others are capable of doing before. When we started Apache Harmony, they were very gracious and welcoming publicly, as (so the inside baseball goes), they were utterly convinced internally we had no hope of succeeding. Their perspective changed radically a year later when we showed up at JavaOne with a functional implementation of AWT and Swing, and good progress with a virtual machine w/ a JIT and modern GC. (Ironically, the lore has it that Sun was running the TCK on Harmony to track our progress...) So implying that doing an independent implementation is economically irrational is either conveniently forgetting history, or willfully misdirecting the discussion.
Finally, I'm just astonished that Dalibor of all people - someone I respect, with a very commendable track record of open/free software contribution and leadership - would be directly suggesting that instead of a free ecosystem where people are able to spend their time and effort where they choose (independently implementing a spec and testing it), that it would be better instead to artificially limit work only to [the Sun controlled] OpenJDK codebase and derivatives (why do I keep thinking of Bush's limitations on stem-cell research here?) for the "clout of the platform" (for the good of the State?).
This stinks. The beauty of the Java ecosystem is that there can be multiple implementations of a spec. This has served us so well over the years, I'm surprised that I have to bring this up.
Think about Java EE for a second. (BTW, we had the same knuckle-headed resistance from Sun when the ASF licensed the Java EE TCK for the first time for Geronimo.) The incredible choice we have had over the years - Apache Geronimo, JBoss, Sun's Glassfish, IBM's WebSphere, BEA's WebLogic, Oracle's appserver, JOnAS, etc - gave users options in licensing, support, performance and features. Without sacrificing compatibility (which was Sun's public motivation for the resistance). We've also had beneficial variety in the Java SE space - Sun, IBM and BEA all had competitive, compatible SE implementations. While all licensing Sun's class library implementation, they had independent or semi-independent virtual machines, which helped drive benefits in performance, stability and manageability to a degree that a single-vendor ecosystem would never have realized.
Think of the positive, constructive disruption that Google's Android platform (which is powered in part by Harmony's class library) is bringing to the phone/embedded ecosystem. Smart phones are exciting again.
I hope I'm just misunderstanding what Dalibor is trying to say.
Sometimes it helps to put words in the context in which they were said.
The context of the question I was answering is:
"GNU classpath cannot be tested either. Sun only provides a testing kit license to projects "derived from OpenJDK". GNU classpath is not derived from OpenJDK, so would not be eligible. Without the ability to create new implementations, the 'Java trap' effectively still exists."
I was replying to a statement from Stephen whether GNU Classpath could make use of OpenJDK's Community TCK license. He believed the answer was 'no', so I explained why 'yes' is a more likely answer, for GNU Classpath in a combination with HotSpot.
Getting HotSpot + GNU Classpath through the TCK would be a considerable effort, though - efforts replacing small parts of OpenJDK with other implementations have succeeded, but they took their time. Getting HotSpot + GNU Classpath through the TCK would likely take a lot longer, because the amount of code that hasn't seen the TCK would be much higher.
So in that regard, having a steady sequence of fully compatible free software implementation that are building upon OpenJDK 6 (it's the compartment store for IcedTea, etc.) while expanding the amount of code that can be used to build compatible implementations is a good thing.
That's basically what I'm seeing with the current license - so as I said, I wasn't there when the license was made, but it seems to work well in retrospect for building a community of compatible implementations around OpenJDK.
So I'm not sure why you have decided to call me out for statements I made in the scope of a statement about OpenJDK, the OpenJDK Community TCK license, GNU Classpath, HotSpot and IcedTea as if they were made about Apache Harmony.
They weren't.
Feel free to call me next time something I said causes you to scratch your head - you've still got my number from the early Harmony days.
The thread was about Apache Harmony and Sun.
As much as I'd like to give you the benefit of the doubt here, I'm still not buying it. The reason Sun restricts the TCK to things "substantially derived" is to ensure that they fall under the GPL and therefore cannot be used by any of Sun's customers. I think that's fine, actually - Sun should be free to license its software as it chooses. But don't try to spin this as Sun doing the world a favor.
You're a Sun employee, and well-placed within the Java organization. You know the real reasons behind Sun's refusal to give the ASF an regular, JSPA-compliant license. I'm not suggesting that you should publicly speak out against your management and put your job at risk (I've known you long enough and I can't believe that you really support patent aggression), but I also don't think that you should be actively spinning for them in the context of discussing Harmony.
However, as it's true that it's undeniably a good thing that there is a steady sequence of compatible free software built from OpenJDK, I'll take you at your word on that bit.
That said, I'll still call BS because of the second quote, where it's clear you mean any implementation of Java SE, and clearly indicate that it wouldn't be good to "throw it [the TCK] over the wall". I assume that would be out of the "Walled Garden" you claim isn't there.
Free access to the test suite is a thing that you used to fight for before you joined Sun, and again, while I'm not surprised that you stopped fighting for it, I am surprised that you now are against it.
Also, letting others have the TCK to use, and nurturing your own projects aren't in conflict. The Apache Harmony project built an implementation of Java SE without any help from Sun or need for Sun's code. Letting Harmony go forward wouldn't distract from Sun's work on OpenJDK one bit (and you know it).
As for calling you? We've done a lot of things over the years, so I have no problem calling you, or calling you a friend.
But Sun is relying on secrecy around this subject so they can continue with this travesty, so the best thing that can happen is sunlight and fresh air. The ASF's request for the Java SE TCK was the sunlight that lit up this last remaining dark corner of the JCP. Lets keep that light burning and keep our discussion public.
geir
You'll notice that I, in fact, did not in my post in the thread mention Harmony at all.
You'll also notice that I mentioned OpenJDK, GNU Classpath, Kaffe, IcedTea, CACAO, etc. quite a bit though - setting the context of my reply very clearly apart from the thread about Apache vs. Sun, to the context of the reply to Stephen's mistaken statement about GNU Classpath and the OpenJDK Community TCK.
If you chose to interpret what I said as being about something that I don't mention anywhere, then maybe your anger is not really about what I actually said, but about what you believe that I meant when I didn't say the things you think I meant to say.
Interpretations have a way of being subjective. So, I'll repeat what I said above: my comments weren't about Harmony.
With that out of the way, let's talk about the throwing the OpenJDK Community TCK over the wall quote. That quote is about the hypothetical alternative scenario of removing the substantially derived bit - my bad for not actually making an effort to spell that out in a way in which it can't be claimed to be about something else - I had assumed that the context was clear from Stephen's framing of the issue around GNU Classpath and the TCK as wrongly being a matter of GNU Classpath solely not being derivative of OpenJDK.
In that hypothetical scenario, releasing the OpenJDK Community TCK with the same license as it has now, with the substantially derived clause removed, would not really accomplish something substantially different from what we have today - for the then elligible, GPLd implementations like Kaffe, CACAO, etc. it would still make the most sense to reuse large parts from OpenJDK in as many places as they need.
I see. Well, given our history, I'll give you the benefit of the doubt for most of it. But...
I don't understand the difference between the "OpenJDK Community TCK" (which isn't what you said) from "the TCK binaries" (which is what you said), since the TCK for the spec should be same no matter who uses it and no matter what code it's being used on.
Also, since you framed the discussion about the TCK and your Walled Garden with
"any compatible free software Java SE 6 implementation in the foreseeable future is likely going to be substantially derived from OpenJDK 6 for very simple, rational economic reasons "
and given that
a) Harmony proved that you don't need to be based on Sun code to make substantial progress that is both economically rational and timely
b) Sun won't give a TCK to anyone that isn't based on Sun code, thereby proving your assertion that there won't be any others
you can see why I thought your contribution to the thread was - being as generous as I can here - 'unhelpful'.
And as for the hypothetical scenario, it would make a world of a difference if the requirement to be based on Sun code was removed - other projects could then use the TCK, and we'd have a richer, stronger and more diverse Java ecosystem.
We proposed such a thing a while ago as it would solve all of our problems :
http://people.apache.org/~geirm/PROPOSAL-NFP-OSI-JCK-20080623.pdf
In the interest of clearing things up, without re-direction or vagueness :
1) Are you for or against Sun releasing the Java SE 5 and Jave SE 6 TCKs under licenses that place no constraints, limits, licensing requirements or similar upon the tested implementation?
[] For
[] Against
2) Should Sun base TCK licensing decisions on internal business needs? Putting it another way, should Sun's software sales force be involved in deciding who and under what terms a TCK license should be made available?
[] Yes
[] No
Thanks in advance.
geir
As the statement in the thread by Stephen was about the OpenJDK Community TCK license agreement's interaction with GNU Classpath, my responses were about that OpenJDK Community TCK, not about anything else. I'm not familiar with anything else - so I couldn't make any useful comments about it.
I understand how you could misinterpret them. Feel free to simply ask next time - that has worked well before, afaik.
As far as your questions go, I'm not involved in either the JCP or Apache Harmony, so in the interest of avoiding further contributions to threads that then turn out to be unhelpful when interpreted from a radically different perspective, I'll have to take a pass.
And a nap, too - have a nice weekend, Geir.
The questions are general - they aren't related to Harmony, but they are related to TCK licensing, a subject about which you were happy to discuss both here and in a lengthy post to the DZone comment thread.
Feel free to clarify the questions if you feel that they are ambiguous and could be misinterpreted.
My asking them of you is actually to help clarify your position on this subject, which appears to be ambiguous, with the result that you are misinterpreted.
So I'm simply asking. Happy napping.
geir
I would guess the problem is Sun knows that there is little in the way of Spec for the Java Libraries and you would find that that is the main fail point for almost all of the test fails you get. I'd say, wink wink, that as it stands with GNU Classpath you could pass about 60% of the tests. There is also a browser based version of the TCK as I recall.
You are right about the expectation of failure: a month or two after Harmony was launched a senior exec in Sun swore that, when I asked, Java would never be in any way an open sourced platform from Sun, despite my insistence that it was inevitable. Opps.
Sun just wants all future open source implementations be derived from OpenJDK. It is clear that do they want and also why. Speaking about 60 % of the passing GNU Classpath tests actually sucks. From the past I have enough third party tests - not mine - to arrange such a "TCK" for Sun's CORBA that they will be happy to pass the half. Keep on your way, Geir. When possible, accept sorry for everything that I have said against Harmony in the past.