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
http://www.javalobby.org/java/forums/t93053.html?start=30#92140389 and
http://www.javalobby.org/java/forums/t93053.html?start=30#92140423
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
course.
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.
cheers,
dalibor topic
