OpenJDK GB Minutes: 2007/8/23

[Andy Tripp]

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