www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: [Draft] New ASF/JCP Policies
Date Fri, 29 Jun 2007 20:25:11 GMT

Geir Magnusson Jr. wrote:
>> One question I have on the FOU restriction for the Java TCK is what
>> would happen if we did certify Harmony with the TCK under its current
>> terms?
> We couldn't ship under the Apache license.

Let's be clear;

 * Source code - ASF insists on providing (so does Sun, incidently).
   However, it isn't the object of certification (TCK) and therefore
   the source code (the thing the ASF creates) can't be Java or the
   implementation of the JSR.

 * Binary build; not TCK validated.  This simply cannot be called
   Java nor an implementation of the related JSR.  An examples, kaffe.
   To quote them; "Kaffe is a clean room implementation of the Java
   virtual machine, plus the associated class libraries needed to
   provide a Java runtime environment." And continues; "It is legal
   -- but Sun controls the Java trademark, and has never endorsed
   Kaffe, so technically, Kaffe is not Java."

 * Binary build; TCK validated.  Once a build of our Source Code on
   a specific platform passes the TCK, that binary becomes an
   implementation of the associated JSR, and can be referred to as Java.

Nothing stops us from shipping Binary builds today without the TCK,
provided they aren't called Java.  Nothing stops us from accepting
the TCK, passing it on the platforms that fall under the FoU clause,
and calling that Java.  Nothing stops the user from changing the code
and using it themselves as they prefer (but no longer calling it Java).

Except for the fuzzy-gray area of Patents.  Once something passes the
TCK, the spec participants engage their patent-sharing clauses and so
we have an Apache License-friendly patent license for that specific
implementation, but not for derivative works.  So the ASF is going
to have to make a call one way or the other that we are willing
to dance under the umbrella of those patents which might-apply but
are not disclosed by the signatories to that JSR.

If someone can modify our code, recompile and use a non-TCK'ed build
of Harmony, are /they/ in violation of the same patents that applied to
our binary TCK'ed build?  If so, that code does not meet our definition
of open source, and the entire discussion is moot.  (I'm not talking
about the finer points of extending the source code to trigger those
patent clauses which *weren't* granted by an official implementation;
simply changing the code to accomplish the same thing more efficiently,
or with fewer bugs.)

Rolling a release of Harmony without the TCK is no different than this
position we would put our /source code users/ under.  So perhaps it's
time to move on, disclaim WHY the implementation is not TCK validated,
and consider what our next steps are in relationship to non-Open JSR's?


View raw message