OpenJDK GB Minutes: 2007/8/23

[Carla.Schroer at Sun.COM]

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