Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: unknown (idunn.apache.osuosl.org: domain pobox.com does not
 designate 64.74.244.70 as permitted sender)
Message-ID: <4506E469.2040801@pobox.com>
Date: Tue, 12 Sep 2006 12:46:33 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: 10.2 licensing issue...
References: <45068E00.4040305@pobox.com> <4506BB50.4080508@sun.com>
 <4506C2E0.7070904@pobox.com> <4506D4E4.4000100@sun.com>
 <4506DD86.1030204@pobox.com> <C0CDEE41-E3E2-458E-8401-A742BDADE076@SUN.com>
In-Reply-To: <C0CDEE41-E3E2-458E-8401-A742BDADE076@SUN.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Craig L Russell wrote:
> Hi Geir,
> 
> On Sep 12, 2006, at 9:17 AM, Geir Magnusson Jr wrote:
>>> A) I couldn't figure out how to build the dummy jars without cribbing
>>> templates from either the beta code or beta javadoc. To me this cribbing
>>> seemed like a forbidden, productive use of the beta-licensed
>>> distribution.
>>>
>>
>> What's the license on the spec?
> 
> The spec license has the same restriction on implementations of JSR 220.
> If Derby were to build our own "dummy jars" then we would be an
> implementation of 220 not just a user of the classes defined in the spec.

Nah.

Under the license currently for users on the JSR-220, I as a user have
the rights for "developing applications intended to run on an
implementation of the Specification, provided that such applications do
not themselves implement any portion(s) of the Specification"

The spec license - thank goodness - has no limitations on how I may use
the specification to achieve the goal of "developing applications
intended to run on an implementation of the Specification, provided that
such applications do not themselves implement any portion(s) of the
Specification"

Given that :

1) We have no choice

2) we aren't going to ship the spec jars needed to compile

3) we aren't going to include them in our application and such jars are
needed to build and ship applications "intended to run on an
implementation of the Specification"

I think we should go forward.

>>
>>>
>>> B) It seemed, frankly, a little sneaky and a violation of the spirit of
>>> the license.
>>
>> As I grok it, the spirit of the license is all about ensuring
>> compatibility.  Is there anything that you feel about what we're
>> proposing in any way violates compatibility or puts it at risk for users?
> 
> This is precisely the issue. A user of Derby 10.2 compiled with
> pre-release JDBC4 jars might get unexpected results if the final release
> jars differ from the pre-release jars. 

Sure.  There's always a possibility, but I think extremely unlikely, as
we can test the resulting binary on the Genuine(tm) JDK from Sun.

> For example, constants from the
> compile jars get incorporated into the binaries and this conflict won't
> be detected via the normal compatibility checks.

This sure would be easier if those Genuine(tm) spec jars were available
under a reasonable license ...

So, assuming we do a good job, do you think there will be a problem?

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