Features Download

From: Dalibor Topic <robilad <at> kaffe.org>
Subject: Re: [Off-Topic] TCK Certification
Newsgroups: gmane.comp.java.classpath.devel
Date: Friday 13th April 2007 01:18:13 UTC (over 11 years ago)
Mark Wielaard wrote:
> Hi Davanum,
> On Fri, 2007-04-20 at 10:46 -0400, Davanum Srinivas wrote:
>> Wanted to poll everyone on what their thoughts are regarding
>> certification. Feathercast has an interview with Geir [1] outlining
>> our current situation and the open letter [2] we sent to Sun.
>> - Would anyone working of the VM's based on classpath be interested in
>> the TCK? (Yes, i know Dalibor tried once before)
> Yes, but the TCK is many things. Source code tests, compatibility
> claims, certification processes, trademarks, branding rights &
> obligations, etc. Some of these don't really make sense for a free
> software project, or at least to the . Certification is often tied to a
> specific binary release on a specific hardware/platform. GNU Classpath
> does only release source code for example. But extra tests are always
> welcome.
> We did indeed try to get access to the JCK (that is the TCK covering the
> core java platform) about 2.5 years ago. But that soon stopped because
> of NDA restrictions that just don't make sense for any open distributed
> collaborative effort like GNU Classpath, Kaffe, GCJ, etc.

See also my explanations of why my attempt to certify Kaffe/Classpath is 
currently dormant. I've written the following in a comment on Geir's 
blog on the subject, clarifying an error in ASF's FAQ to its open letter:

'"It is our understanding that we are the first non-profit with no 
commercial ties to Sun to attempt to license the JCK."

I believe Blackdown was first, FreeBSD was second, and I was third. 
Blackdown and FreeBSD successfully obtained licenses, afaict.

I suspended the negotiations eventually in order to pick them up at a 
later point when Kaffe/Classpath were 100% complete wrt to a current 
Java release, and could be expected to pass all of the test suite.

Having to deal with the overhead of communicating many test failures on 
proprietary test suites to FSF's developers, whom I can't expect to sign 
NDAs, or to use proprietary software in the first place, would not have 
worked out as long as we just had 80%, or 90% of the API completed and 
in a good shape. By the time we got to having 95% of Java 1.5 APIs 
implemented in GNU Classpath last year in summer, Java 1.6 was just a 
few months away, making certification of a 1.5 release pointless.

Contrary to some members of the ASF, many members of the communities we 
use code from in Kaffe have little desire to deal with proprietary 
software themselves, or NDAs. An effort to pass a test suite would not 
have worked out without the close collaboration with the other 
communities Kaffe shares code & developers with.

Since Kaffe is a project ran by volunteers, and not being funded by 
Intel, IBM, Sun, Red Hat or some other corporation, I can't simply throw 
money at the problem and just hire some people in a remote place to do 
the TCK work for me ;), so I decided to suspend the negotiations and 
pick them up again at a future point when Kaffe & Classpath have merged 
in code from OpenJDK, and can be expected to pass the current test suite 
with flying colors.

Meanwhile, I'll simply point out that having open source TCKs for all 
JSRs would solve all future instances of this problem without the need 
for open letters, so I'd hope that the JSR spec leads at IBM, Intel, 
Apache, Sun, Red Hat, Google, BEA, Oracle, etc. take that into account 
for their current and next JSRs.
--Dalibor Topic, April 11, 2007 07:28 AM'

For more information from me on my attempt to get the TCK, see 

The time line of events is probably important as well:
We started the negotiation after the Boston runtime summit, after the 
release of Java 1.5, and spent some time clarifying the terms I was 
unfamiliar with. Eventually, the ASF wanted to get in on the game, so, 
since the ASF had experience with getting and managing TCKs, I switched 
gears and rather than certifying Kaffe/Classpath worked on turning 
Harmony into the unifying project for different VMs, making ASF embrace 
GNU Classpath, and all that idealistic & fun stuff that you're read me 
talking about back in the day.

After a while it became very apparent that would not happen, and Harmony 
turned out to be a rewrite of what we already had with 
Kaffe/JamVM/Cacao/gcj/IKVM/* & Classpath from scratch, so I switched 
gears back to pushing Kaffe/Classpath again, as it was clear to me that 
Harmony would not be finished implementing 1.5 before 1.6 appears, if at 
all, and a GNU Classpath-based runtime presented a much better 
opportunity to get a free runtime certified as compatible. This was 
still quite some time before Sun's announcement of embracing Free 
Software for their own Java implementation stack.

It turned out that getting the last 5% of the API done right took a lot 
longer than I had hoped, so that last summer I decided to put the 
negotiations to sleep, until we've got 100% of a current API implemented.

The rationale behind that is simple: certification only makes sense if 
one has 100% of the current APIs implemented, as afaik the JCP in 
general does not allow 'certifying backwards in time', once a new 
version of a spec is out. Neither Harmony nor Classpath have that, or
are close enough to it to be able to say: yeah, it'll be done in two weeks.

The TCK license I've discussed with Sun is quite clearly not a free 
software license, so it would have been pointless to encourage GNU 
Classpath developers to get bound by a proprietary software license in 
order to fix compatibility bugs exposed by the test suite, as long as we 
have a bug tracker chock full of compatibility bugs exposed by other 
free software. We *know* that we're not fully compatible with Java 1.6 
yet every time we struggle with getting NetBeans to run, for example.

I could have spent Sun's legal team's time trashing around specific 
clauses of the TCK license we discussed. But I don't see the point of 
spending good will debating specifics of proprietary certification 
licenses as long as we are not done with the implementation. By the time 
we are done, the legal framework covering the certification might be 
quite different, and I'm interested in helping make that happen.

I could have spent Sun's PR team's time trashing Sun in public for 
having a proprietary TCK license, written open letters, and what not. 
I've made fun of Sun's 'Read Only' license for the TCK, back when it was 
released, for example. That didn't have any influence on that particular 
license, as far as I can tell, despite my best attempts at stand up comedy.

Trying to 'shame' a multi-billion dollar corporation into making one's 
wishes true doesn't really work, as far as I've seen it, and usually 
just pisses the very people off one's trying to work with 
constructively. Been there, done that, learned from it during the 
Harmony founding excursion.

Rather than fighting licensing fights one VM after another, I prefer to 
work on changing the system such that no such fights are necessary.

>> - If so, Would you be willing to accept "Field of Use" restriction
>> basically telling downstream users where/how they can use your code?
> It was unclear what these 'restrictions' actually were from reading that
> letter and the faq. Do they hold for the source code or only for the
> certified binaries for a specific platform? Anyway, the only
> 'restrictions' that we would accept for the GNU Classpath code would be
> that people share-and-share-alike as stipulated in the GPL.

Kaffe being free software, we're in the same boat as GNU Classpath, of 

I can't comment on the specifics of the license, as I have no idea what 
the TCK license ASF has looks like. But I wouldn't find it surprising if 
it was quite different from the other TCK licenses the ASF has, as 
certifying a java program on top of a well-defined platform and 
certifying a well-defined platform on top of a not-well-defined 
operating environment are two pairs of shoes.

dalibor topic
CD: 156ms