Mailing-List: contact jcp-open-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: jcp-open@apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <46856AA7.2010005@apache.org>
References: <3d4032300705140644r4bc3664fx1a2ad34b139806be@mail.gmail.com>
 <D3DC739E-CDDA-45B8-9B38-03E100676945@hogstrom.org>
 <FEA7981A-1244-41DB-9475-50E4F6AC381A@pobox.com>
 <46856AA7.2010005@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <99A0A271-F775-4D2C-AE47-B56C80730B9F@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [Draft] New ASF/JCP Policies
Date: Sat, 30 Jun 2007 03:49:37 +0200
To: jcp-open@apache.org


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

Yep.

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

Yep

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

geir

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