www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [Draft] New ASF/JCP Policies
Date Sat, 30 Jun 2007 01:49:37 GMT

On Jun 29, 2007, at 10:25 PM, William A. Rowe, Jr. wrote:

> [resending]
> 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.

Yes, of course.

>  * 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.

I know.  We do that.  But the goal of the project is shipping a  
certified Java SE.

> 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).

That's not true.  You don't quite grok the FOU clause.

The FOU clause doesn't restrict platform, it restricts context of use.

My canonical example :

Harmony can ship a binary tested on Dell hardware running Ubuntu  
linux, but if you happen to use that same configuration in a manner  
that Sun considers embedded (like putting the same machine into the  
case of an X-Ray machine to control the UI), it's no longer certified  
and doesn't get the necessary IP grant.


> 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?
> Bill

View raw message