I have a few questions and comments about the IGB meeting on the TCK...
Mark Reinhold wrote:
2 License eligibility
Q5: What about hybrid implementations, for example what the Cacao folks
are working on, where they're using the OpenJDK class libraries on
top of their own VM to run on PowerPC or S/390 machines? Would they
be eligible for the TCK license?
The Classpath library running with the HotSpot VM would certainly count as
substantially derived, since the HotSpot VM is a significant chunk of code.
It doesn't make sense to me that both of these would be considered
"substantially derived":
a) Your own VM with OpenJDK libraries
b) Your own libraries with the OpenJDK VM
That seems to me like saying that both of these are "derived" from a Honda:
a) A Honda engine in a non-Honda car
b) A non-Honda engine in a Honda car
What's to stop, say, Apache Harmony, from releasing three versions:
1) A GPL2 version, tested with TCK, consisting of Harmony libraries and
Hotspot
2) A GPL2 version, tested with TCK, consisting of Harmony VM and OpenJDK
libraries
3) Their current product, Apache license, not tested with TCK, but
consisting of the *same code* that
has been tested with the TCK
Also, the explanations given just don't seem to match up with a
reasonable definition of
"substantially derived". Rather, they're just talking about
mixing-and-matching pieces
(VM and libraries) of a whole. I think neither a Honda engine in a
non-Honda car
nor a Honda car with some other engine is "substantially derived" from
an original Honda.
The engine is just too big of a part of the car, and a VM is too big a
part of a JDK.
And I think there's just no "deriving" going on here anyway. "Deriving"
would be to modify something
from the original, not mix-and-match parts.
because the OpenJDK TCK
license requires that a tested implementation be released under the same
license as the OpenJDK code itself, which at the moment is GPL version 2
only.
I don't see how you can decide whether some release qualifies based on
what might be done with it
in the future (more below).
Q8: Would the Harmony class libraries combined with the HotSpot VM be
considered "substantially derived?"
In terms of the code, yes, this combination would be considered to be
substantially derived.
To be eligible for the OpenJDK TCK License, however, you'd have to be
planning to release the whole combination under GPLv2, and that's likely a
problem. Neither Apache, the FSF, nor Sun view the Apache license as
compatible with GPLv2, at least not if you're incorporating Apache code
as-is. You'd have to decide for yourself whether such a combination is
legitimate.
Again, how can you decide based on what someone is "planning" to do in
the future? What if,
say, Classpath says they're "planning" a future release under GPL2, but
then never actually
release it? What if Apache says they are "planning" a GPL2 release, but
you don't believe them?
Q13: Does an implementation have to pass every single test?
Yes, every single valid test in the suite must pass. You can challenge the
validity of specific tests, however, and sometimes tests are thrown out as a
result of such challenges.
How will this challenge process work? For example, the "spec" (javadoc)
for the DateFormat.equals() says something
so vague that virtually anything should pass the test. Assuming that the
test actually tests something,
and assuming that some implementation fails, what happens? Does "thrown
out" mean the test is actually
removed from the suite, or is the test case fixed to match the spec? If
the test case is fixed, is the
implementation considered to have passed in the meantime? If it's the
spec that's to be fixed (which could
take a very long time), what's the status of the implementation in the
meantime?
Q14: What's the difference between passing the test suite and actually
certifying an implementation as compatible?
That's an important distinction. A compatible implementation must meet all
the requirements that are spelled out in the TCK User's Guide, specifically
those in Chapter 2. It must not only pass the test suite but also satisfy a
set of rules that are, inherently, untestable. In other words, there are
parts of the certification process that amount to you asserting that, to the
best of your knowledge, you're not breaking compatibility. It doesn't mean
that you don't have any bugs, it just means that you're not knowingly
violating any of the relevant specifications and other requirements.
Is there a way to find out what the TCK User's Guide says before
actually licensing it?
The reason I ask is that its wording here is crucial. Historically, C
and C++ implementors have worked hard for years on
standards to ensure that they're not "breaking compatibility", and yet
one of the major advantages of
Java is WORA - that it's compatible across platforms and
implementations, while C and C++ are not.
So how can someone like me, who wants Java to succeed but has not built
my own implementation,
figure out whether this is just "the C/C++ standards process all over
again" or something better?
One good example here is keywords. Both the C/C++ standards and the JLS
specify a list of valid
keywords. But they do not say "...and these are the only keywords". This
was a key issue in the MS
trial, where MS added their own keywords.
Isn't it reasonable for the general Java developer community to know
what this TCK User's Guide says?
For example, I wouldn't dare try another implementation unless I know
that the other implementation
has no additional keywords. The TCK User's Guide may ensure reasonable
compatibility, but if only
licencees can read it, very few people will care.
Suppose an implementation feels that they do comply with the TCK User's
Guide wording, but
Sun disagrees. Then what? Or suppose an implementation feels that the
wording should be changed?
Than what? Does an implementation have any way to appeal Sun's decision?
Now the practical reality, of course, is that there will be modes that don't
pass, e.g., modes that just print a version string and exit, or that provide
certain kinds of debugging information. The rules cover all these sorts of
special cases and exceptions.
I don't see how it's possible to have wording that allows things like
"debug mode", where arbitrary trace info is printed,
but disallows "fast mode" where array bounds checking is skipped. I
guess I'll have to take your word for it,
if I can't see the TCK User's Guide.
The expectation is that people are acting in good faith, trying to meet the
compatibility requirements, and that they aren't knowingly doing something
that would violate them. They're expected to make their own choices around
risk, with the understanding that if a mistake is made and an implementation
isn't compatible then Sun could ask them to stop claiming it's compatible and
stop using the Java logo with it.
Sun should know better than to assume that it's as simple as expecting
people to be acting in good faith.
For example, there was a discussion on the Classpath mailing list a
while back about what the various
toString() methods should print. There's nothing in the "spec" (Javadoc)
covering this, and people naturally
wondered "should I print what I think is reasonable, or do I have to go
through lots of work to figure out
exactly what Sun's implementation prints and match that
character-for-character?" These people are
clearly working in good faith, but it's completely unreasonable to
expect them to have full compatibility.
IIRC, it was left up to each developer.
Also, some say that the Netscape implementation was less compatible than
the Microsoft implementation
at the time that Sun sued Microsoft for being incompatible. Most Java
developers think that was the
right decision, and it was a decision that certainly did not expect that
everyone was acting in good faith.
And Apache may be acting "in good faith" when it comes to compatibility,
but not so much when it comes
to releasing under a GPL-compatible license.
This is pretty much how Sun has worked with its commercial licensees for many
years now. This should scale to the relatively modest expected number of new
OpenJDK TCK licensees that will want to self-certify and carry the brand.
Of course, there's the problem that an implementation may start out
compatible, become dominant, and
then stray. This is exactly what's happened with C, C++, Javascript,
HTML, CSS, and other languages.
Q19: If an OpenJDK-derived implementation is still in beta, or is
declared final but isn't compatible, can it still be shipped?
Yes. This is a key difference between the OpenJDK TCK license and the
traditional TCK license available under commercial terms from Sun.
Under the commercial license an implementor can ship early-access or beta
releases and not worry about compatibility, so long as they don't claim
compatibility and don't allow production use. Once they're ready to ship the
final release to customers and support it in production, however, then it
must be compatible -- otherwise they can't ship it.
Well, anyone can ship anything they want, they just can't claim that
it's "Java compatible", right?
And in practice, they could even do that, and it would be up to Sun to
take them to court to stop them.
5 Confidentiality
Q21: What about the confidentiality clause in the OpenJDK TCK license?
Does it allow for the publication of test results? That is, can
one talk about what passes and fails in public?
Yes. Sharing the results of test runs is fine, per section 5.1 of the
license. You can say things like "I passed all the tests," or "I passed all
the VM tests, but failed these seven compiler tests," or you could even, if
you really wanted to, publish the entire log of a TCK run.
Sun doesn't, however, want people to make comparative claims of
compatibility, e.g., "I'm just as compatible as that other guy over there,
but not really actually compatible," since that will tend to confuse people
about what compatibility means.
I assume that when you talk about what "Sun wants" here, you actually
mean that the license has wording
to enforce what "Sun wants". Yes?
The confidentiality clause is intended to protect the tests themselves, not
the results of running the tests. You can't disclose the details of the
tests publicly, though you can discuss them with other parties who've also
signed the OpenJDK TCK license.
If a licensee can't disclose the details of tests publicly, how will
that work? Say Classpath has a license.
Does that mean that Classpath developers can't say "...the TCK checks
for such-and-such here, could
someone fix that?" on their public mailing list?
And who is even considered "a Classpath developer", and
so is allowed to see the TCK, considering that to become "a Classpath
developer", you just need
to go ahead and contribute?
Finally there are functional, performance, and reliability test suites. Some
of these will likely be open-sourced over time although some cannot, again
due to legal constraints.
Suppose an implementation is compatible, but very unreliable. Is there
any provision in the TCK (or
elsewhere) where Sun can attempt to stop the use of the Java trademark
in that case where Sun just
wants to protect the integrity of the brand?
Thanks for making all these discussions so open.
I hope you find these comments useful and not just paranoid ranting.
Enough people have struggled with incompatible compilers for decades to
justify some paranoia.
Andy Tripp
