db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: 10.2 licensing issue...
Date Tue, 12 Sep 2006 17:34:27 GMT
Hi Geir,

I hate to be the broken record, but there are real user compatibility  
issues in releasing a production version of software that depends on  
pre-release versions of software.

Real users can get hurt.

Craig

On Sep 12, 2006, at 9:57 AM, Geir Magnusson Jr wrote:

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

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