db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: 10.2 licensing issue...
Date Tue, 12 Sep 2006 16:57:08 GMT
Excuse me - I looked at the 220 license as noted by Craig below, not the
*221* license, which is the one that actually applies.

It turns out there are *no rights* enumerated for users as far as I can
tell in the spec license.

So the solution to this really annoying, tiresome and really avoidable
problem is either :

1)  Sun to put a user-oriented spec license that lets us just  create
those API jars and let us _compile_.

2) Sun to put the API binary jars for JDBC4 under CDDL or even the BCL.

geir


Geir Magnusson Jr wrote:
> 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!
>>
> 
> 

Mime
View raw message