Hi Folks,
I'm sorry to be a bit late to the party here, Mark Reinhold forwarded
Andy's questions and comments to me, and I just signed up for the list
and read this thread.
I am really glad to see interest in these issues. I certainly think
they are important and I have spent a lot of the last 12 years working
on them. Some of these issues have easy answers, others don't. I'm
going to break with convention and respond to some general themes I see
running through this thread, rather than going item by item. I hope
this will provide a bit more background and thinking for the
discussion. I also want to encourage folks to continue to discuss these
issues with the TCK team, once the proposed conformance group is formed.
Paul Rank is leading the effort from the TCK group.
You can get the JCK (The TCK for Java SE) in it's entirety, including
the user guide with the compatibility rules, under a "read-only"
license. it's been available for 3 years. If anyone wants to look at
things that way, it's available here: https://jck.dev.java.net/
Graham Hamilton wrote a blog about it at the time that discusses the
license and why we did it:
http://weblogs.java.net/blog/kgh/archive/2004/12/j2se_compatibil.html
We are also looking at ways to release more TCK information publicly. We
will use the conformance group page to do this. Stay tuned.
There was a bunch of discussion about people's "intent" when they sign a
contract. I'm not a lawyer. I do work with the legal team here at Sun
quite a bit, and am often in the role of liaison to legal from
engineering. Most contracts are forward looking and try to cover
situations expected to arise in the future during the course of the
agreement. It is not uncommon to have some language around the parties'
intent. There is also usually language about what happens if either
party doesn't do what they intended at the time they signed the
license. My point is that I don't think there is anything weird about
setting up a license that makes clear who is eligible and who it's
intended users are.
This comment of mine seemed to spark a lot of discussion:
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.
I'll add a bit more explanation. The folks who have commercial source
code licenses with Sun have obligations under those license around
compatibility. Sun has the ability to negotiate a "remedy" if a
company's implementation turns out to not be compatible. This has
happened many times over the years. The only case that folks know about
publicly is the Microsoft one, because it ended in litigation. No one
in their right mind wants to litigate. It's a last resort, and in the
case with Microsoft we had discussed with them on several occasions
compatibility issues with their implementation. They made it clear that
they had no intention of fixing the problems. That's why it went to
litigation. In all the other cases, including Netscape in 1997, the
companies worked with us to create a "get well plan" for fixing the
issues. Those plans might include notification to their users, not
using the brand until the issue was fixed, and other similar things.
So, what did I mean by the "good faith" item above? Really it's about
the fact that testing something as complex and broad as the Java SE
platform means that there are some things that aren't testable, some
things we don't have the resources to write tests for, and there is more
to testing than just running a test suite once and seeing if everything
passes. We had to create a program that was practical for our source
licensees and for us. We also had to have a program that could be used
to certify implementations on platforms we don't have and don't know
anything about, and that may not be publicly available at the time of
certification (hardware and/or software) We also felt that the
implementors themselves were the best experts on their implementations
and all the configurations of their implementations. Further, the
licensees all had to have a support license, so we could work with them
to answer questions and resolve issues. At the end of the day, they
needed to use our tools and tests and rules to test their products and
then state back to us that they met all the requirements. As stated
above, we have recourse if someone makes a mistake or misses something
that turns out to be an issue. In my experience, all of our commercial
licensees since 1995 except one (and you can probably guess who) have
wanted compatibility, and supported the program. It was in their best
interest to ship compatible implementations. Sure, some mistakes were
made, but they were mistakes, and they worked with us to resolve them
when they were pointed out.
The last item I will comment on in this email is quality vs
conformance. The TCKs are about testing for conformance to the specs.
They can only be as good as the specs, and practically speaking they
can't test everything in the specs. So, we do a lot of other testing
besides the TCKs. We have a large regression test suite, much of which
is available in the OpenJDK project under GPL, and more will be over
time (some things contain 3rd party code or media files we don't have
distribution rights to, etc.) We strongly encourage members of the
community to contribute to this test suite and to use it as well. We
also have a variety of additional tests for performance, reliability,
and implementation specific behavior, not required by the specs. Our
licensing model has always assumed that conformance to the specs was
critical across implementations, but that licensees could and should
compete on these other factors like performance and reliability.
Thanks for listening.
Carla
