Today, the Apache Software Foundation sent an open letter to Jonathan Schwartz, CEO of Sun Microsystems, regarding the ASF's inability to acquire an acceptable TCK license for the Java SE TCK (also called the "JCK") in over 7 months of trying.
For more information, there is also a FAQ available.
Update : Links :
Hey geir. Story's up at www.sdtimes.com
http://www.sdtimes.com/breakingNews.html
"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.
What I'd like to find out, but with no luck so far, are exactly what the field-of-use restrictions are that Sun is imposing, and what code they affect. Is this non-disclosable?
Not sure if this is what you want: (From FAQ)
"Q : What is a "field of use" restriction?
A : A "field of use" restriction is a restriction that limits how a user can use a given piece of software, either directly or indirectly. To give a concrete example from the Sun / Apache dispute, if Apache accepted Sun's terms, then users of a standard, tested build of Apache Harmony for Linux on a standard general purpose x86-based computer (for example, a Dell desktop) would be prevented from freely using that software and that hardware in any application where the computer was placed in an enclosed cabinet, like an information kiosk at a shopping mall, or an X-ray machine at an airport."