Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44D7A7BC.3010804@sun.com>
Date: Mon, 07 Aug 2006 13:51:08 -0700
From: Bill Shannon <bill.shannon@sun.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509
MIME-Version: 1.0
To: legal-discuss@apache.org
CC: Craig L Russell <Craig.Russell@sun.com>
Subject: Re: Derby and the JCP
References: <AAE5D953-AA49-4EBB-8194-9BD2413C33B3@Sun.COM>
 <44D3E25C.1030103@apache.org> <F166B029-D46C-4554-B4C6-379304B361F8@Sun.COM>
 <44D47160.6000003@apache.org> <7FD55B31-96A3-4CB3-B58F-0D1E8E396A14@Sun.COM>
In-Reply-To: <7FD55B31-96A3-4CB3-B58F-0D1E8E396A14@Sun.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

(If this message doesn't make it through to the legal-discuss mailing list,
please forward it.)

Hi Geir.  As you know, I'm not a lawyer, but I have quite a bit of
experience dealing with Java compatibility issues.  I've talked to
Mark and Lance and cleared up their misunderstanding of the Java
compatibility requirements.

Part of the confusion here is over the use of the word "implements"
in the Java language vs. the use of the word "implements" in the
Java compatibility rules.  These two uses do *not* have the same
meaning.

The spec for the java.util.Map API describes the requirements for
a Java platform product that provides that API - in this case largely
just the API signature.  It also describes the expected, but entirely
optional, requirements of a class that "implements" (in the Java language
sense) that API.  If your application has its own MyMap class that
implements the Map API, are you required by the Java compatibility
rules to obey all the details of the Map contract?  No, you're not.
You can have a high quality, accurate implementation of the Map API,
or you can have a low quality, buggy implementation of the Map API
in your MyMap class.  The Java compatibility rules don't care.

The same is true for JDBC.  The JDBC spec defines the requirements of
a Java platform product that provides the java.sql and javax.sql APIs.
It also defines the expected, but entirely optional, requirements for
a class that implements those APIs (i.e., a JDBC device driver).  A
JDBC device driver that meets certain additional requirements may be
labeled as JDBC 4.0 compatible, but it's not required that all drivers
do that, and such requirements have nothing to do with the Java
compatibility requirements in the JDBC spec license.

 From the perspective of the Java spec license, both the MyMap class
and the JDBC driver are users of the spec, not implementations of the
spec.

Yes, this can all be very confusing.  And yes, the combination of legal
and technical language doesn't make it any clearer.

Hopefully I've clarified this particular issue.  Provided Derby itself
does not include any of the java.sql or javax.sql API definitions, you
don't need to worry about the JDBC spec license compatibility requirements
that apply to implementations of the spec.

(Please be careful about generalizing this conclusion to other cases
involving other specs.  Different specs have different requirements
that may not be immediately obvious from the brief discussion above.)

	Bill Shannon
	Java EE Spec Lead


Craig L Russell wrote:
> Hi Geir,
> 
> I'm participating in this discussion as an Apache committer who is
> interested in getting through the legal thicket so we can ship Derby.
> I can say I've talked to people at Sun whose opinion I'm reflecting.
> You can take this as input to the process.
> 
> Craig
> 
> 
> On Aug 5, 2006, at 3:22 AM, Geir Magnusson Jr wrote:
> 
>>
>>
>> Craig L Russell wrote:
>>
>>>
>>> On Aug 4, 2006, at 5:12 PM, Geir Magnusson Jr wrote:
>>>
>>>>
>>>>
>>>> Craig L Russell wrote:
>>>>
>>>>> IANAL, but I don't think there is a problem. Derby is not an
>>>>> application.
>>>>>
>>>>> The only way you can run Derby that exposes JDBC4 functionality  is by
>>>>> running a User Application with Java SE 6. If a User Application  
>>>>> runs in
>>>>> this environment, is is subject to the testing and evaluation  
>>>>> terms of
>>>>> the license.
>>>>>
>>>>> So there is no need to encumber Derby NOTICEs with this disclaimer.
>>>>>
>>>>
>>>> Rick quoted the wrong part of the spec license. The relevant part is
>>>> this notice :
>>>>
>>>> "This is an implementation of an early-draft
>>>> specification developed under the Java Community
>>>> Process (JCP) and is made available for testing and
>>>> evaluation purposes only. The code is not compatible
>>>> with any specification of the JCP."
>>>>
>>>> Derby cannot be encumbered with this disclaimer, as it would make  the
>>>> combination of terms presented to the user inconsistent with Open  
>>>> Source
>>>> - namely restrictions on field of use.
>>>
>>>
>>> As we already discussed, Derby is not an implementation of the
>>> specification. I don't see the need to encumber Derby with any  
>>> disclaimer.
>>
>>
>> Are you speaking officially as a Sun employee?  If so, I'd be  overjoyed
>> to resolve it this way.
>>
>> If not, I think you'll need to point me to such discussion, because  if I
>> recall correctly both Mark Reinhold (Mustang lead) as well as Lance
>> Andersen (JDBC4 lead) have asserted that anything implementing a JDBC4
>> driver is an implementation of the spec.
>>
>>>
>>> So it seems that there are two kinds of programs that run into the
>>> license issue: implementations (such as JRocket VM) and applications
>>> (e.g. third party software that runs only on Mustang). Derby is  neither
>>> of these.
>>
>>
>> It has an implementation of the JDBC4 driver, right?  According to  Mark
>> and Lance, that's enough.
>>
>> geir
>>
>>>
>>> Craig
>>>
>>>>
>>>> geir
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
> 


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org