You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/09/12 12:37:52 UTC
10.2 licensing issue...
I read Rick's note on the 10.2 licensing issue in an archive because of
strange move to the user list, so sorry for the weird quoting :
He said :
"I must report today that the restrictions imposed by the beta JDK
license have not been lifted.
As you know, the JDK 6 beta license requires a disclaimer that bars the
use of the code for any productive use....
snip
...For this reason, we, the Derby community must change our
plan to ship imminently an official release of Derby that includes JDBC4."
Let me start with a question :
Why? Is this all about having a set of API jars to compile against, or
is it something more?
geir
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Craig L Russell wrote:
>
> On Sep 12, 2006, at 9:49 AM, Geir Magnusson Jr wrote:
>
>>
>> Craig L Russell wrote:
>>> Hi Geir,
>>>
>>> On Sep 12, 2006, at 3:37 AM, Geir Magnusson Jr wrote:
>>>
>>>> I read Rick's note on the 10.2 licensing issue in an archive because of
>>>> strange move to the user list, so sorry for the weird quoting :
>>>
>>> This issue affects users of Derby just as much as developers. Users
>>> counting on a production release of Derby to be used with a production
>>> version of JDK6 with JDBC4 are directly affected by this change.
>>
>> Isn't that the case with every aspect of development?
>
> Nah.
>
> Users care about their bugs and the features that they use, and the
> schedule for the next production release. The topic of discussion is
> about the schedule for the next production release.
>
> It was a judgement call, and I think it was the right one. Should we
> have a vote? ;-)
>
The problem I was pointing out that it was an important topic of concern
to people that have been following on dev. You should give a bit of a
notice before kicking things off like that, IMO.
geir
> Craig
>>
>> geir
>>
>>>
>>> Craig
>>>
>>> Craig Russell
>>> clr@apache.org http://db.apache.org/jdo
>>>
>>>
>
> 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!
>
Re: 10.2 licensing issue...
Posted by Craig L Russell <Cr...@Sun.COM>.
On Sep 12, 2006, at 9:49 AM, Geir Magnusson Jr wrote:
>
> Craig L Russell wrote:
>> Hi Geir,
>>
>> On Sep 12, 2006, at 3:37 AM, Geir Magnusson Jr wrote:
>>
>>> I read Rick's note on the 10.2 licensing issue in an archive
>>> because of
>>> strange move to the user list, so sorry for the weird quoting :
>>
>> This issue affects users of Derby just as much as developers. Users
>> counting on a production release of Derby to be used with a
>> production
>> version of JDK6 with JDBC4 are directly affected by this change.
>
> Isn't that the case with every aspect of development?
Nah.
Users care about their bugs and the features that they use, and the
schedule for the next production release. The topic of discussion is
about the schedule for the next production release.
It was a judgement call, and I think it was the right one. Should we
have a vote? ;-)
Craig
>
> geir
>
>>
>> Craig
>>
>> Craig Russell
>> clr@apache.org http://db.apache.org/jdo
>>
>>
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!
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Craig L Russell wrote:
> Hi Geir,
>
> On Sep 12, 2006, at 3:37 AM, Geir Magnusson Jr wrote:
>
>> I read Rick's note on the 10.2 licensing issue in an archive because of
>> strange move to the user list, so sorry for the weird quoting :
>
> This issue affects users of Derby just as much as developers. Users
> counting on a production release of Derby to be used with a production
> version of JDK6 with JDBC4 are directly affected by this change.
Isn't that the case with every aspect of development?
geir
>
> Craig
>
> Craig Russell
> clr@apache.org http://db.apache.org/jdo
>
>
Re: 10.2 licensing issue...
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Geir,
On Sep 12, 2006, at 3:37 AM, Geir Magnusson Jr wrote:
> I read Rick's note on the 10.2 licensing issue in an archive
> because of
> strange move to the user list, so sorry for the weird quoting :
This issue affects users of Derby just as much as developers. Users
counting on a production release of Derby to be used with a
production version of JDK6 with JDBC4 are directly affected by this
change.
Craig
Craig Russell
clr@apache.org http://db.apache.org/jdo
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Craig L Russell wrote:
> 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.
>
Sure, and this is FUD at this point, because I don't really believe that
this is going to be a problem. Do you really think so? If you really
were concerned, you wouldn't be releasing against *untested* software
like the Sun JDK 6 until there has been production testing by real users
of that codebase too. (Clearly, I can FUD with the best of them.)
Also, you can simply test it against JDK 6.
If we were past the Project Formerly Known as Mustang release, there's
no requirement that a user's application compiles against the binaries
from Mustang, because as I noted, the user spec license doesn't
proscribe or prohibit in what matter the user application is created.
So lets try to find a working solution that restores Derby's release and
feature schedule management back to the community. Don't you agree?
geir
> 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!
>
Re: 10.2 licensing issue...
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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!
>>
>
>
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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!
>
Re: 10.2 licensing issue...
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
>
>>
>> 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. For example, constants from
the compile jars get incorporated into the binaries and this conflict
won't be detected via the normal compatibility checks.
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!
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Rick Hillegas wrote:
> Geir Magnusson Jr wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>> Geir Magnusson Jr wrote:
>>>
>>>
>>>> I read Rick's note on the 10.2 licensing issue in an archive because of
>>>> strange move to the user list, so sorry for the weird quoting :
>>>>
>>>> He said :
>>>>
>>>> "I must report today that the restrictions imposed by the beta JDK
>>>> license have not been lifted.
>>>>
>>>> As you know, the JDK 6 beta license requires a disclaimer that bars the
>>>> use of the code for any productive use....
>>>>
>>>> snip
>>>>
>>>> ...For this reason, we, the Derby community must change our
>>>> plan to ship imminently an official release of Derby that includes
>>>> JDBC4."
>>>>
>>>> Let me start with a question :
>>>>
>>>> Why? Is this all about having a set of API jars to compile against, or
>>>> is it something more?
>>>>
>>>>
>>>>
>>> Hi Geir,
>>>
>>> In a nutshell, yes. We can use the compiler from JDK 5 without any
>>> licensing restrictions--for our purposes it's just as good as the JDK 6
>>> compiler. However, a restrictive beta license covers the apis in the JDK
>>> 6 jars.
>>>
>>
>> This reminds me of the old gag :
>>
>> "Doctor, my arm hurts when I lift it"
>> "Don't lift it then..."
>>
>> Don't use the JDK 6 jars. All you need to do is *compile*, so lets make
>> our own JARs that get things to compile.
>>
>>
> Hi Geir,
>
> I did consider this option. The following problems bothered me:
>
> 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? IIRC, there are no prohibitions for
this. We wouldn't be distributing those jars. AS a matter of fact,
maybe the JDBC4 EG could make them available :)
>
> 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?
geir
>
> Regards,
> -Rick
>
>> Is there any runtime dependency on Java SE 6?
>>
>> geir
>>
>>
>>
>
>
>
Re: 10.2 licensing issue...
Posted by Rick Hillegas <Ri...@Sun.COM>.
Geir Magnusson Jr wrote:
>Rick Hillegas wrote:
>
>
>>Geir Magnusson Jr wrote:
>>
>>
>>
>>>I read Rick's note on the 10.2 licensing issue in an archive because of
>>>strange move to the user list, so sorry for the weird quoting :
>>>
>>>He said :
>>>
>>>"I must report today that the restrictions imposed by the beta JDK
>>>license have not been lifted.
>>>
>>>As you know, the JDK 6 beta license requires a disclaimer that bars the
>>>use of the code for any productive use....
>>>
>>>snip
>>>
>>>...For this reason, we, the Derby community must change our
>>>plan to ship imminently an official release of Derby that includes
>>>JDBC4."
>>>
>>>Let me start with a question :
>>>
>>>Why? Is this all about having a set of API jars to compile against, or
>>>is it something more?
>>>
>>>
>>>
>>>
>>Hi Geir,
>>
>>In a nutshell, yes. We can use the compiler from JDK 5 without any
>>licensing restrictions--for our purposes it's just as good as the JDK 6
>>compiler. However, a restrictive beta license covers the apis in the JDK
>>6 jars.
>>
>>
>
>This reminds me of the old gag :
>
>"Doctor, my arm hurts when I lift it"
>"Don't lift it then..."
>
>Don't use the JDK 6 jars. All you need to do is *compile*, so lets make
>our own JARs that get things to compile.
>
>
Hi Geir,
I did consider this option. The following problems bothered me:
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.
B) It seemed, frankly, a little sneaky and a violation of the spirit of
the license.
Regards,
-Rick
>Is there any runtime dependency on Java SE 6?
>
>geir
>
>
>
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Rick Hillegas wrote:
>
> Geir Magnusson Jr wrote:
>
>> I read Rick's note on the 10.2 licensing issue in an archive because of
>> strange move to the user list, so sorry for the weird quoting :
>>
>> He said :
>>
>> "I must report today that the restrictions imposed by the beta JDK
>> license have not been lifted.
>>
>> As you know, the JDK 6 beta license requires a disclaimer that bars the
>> use of the code for any productive use....
>>
>> snip
>>
>> ...For this reason, we, the Derby community must change our
>> plan to ship imminently an official release of Derby that includes
>> JDBC4."
>>
>> Let me start with a question :
>>
>> Why? Is this all about having a set of API jars to compile against, or
>> is it something more?
>>
>>
> Hi Geir,
>
> In a nutshell, yes. We can use the compiler from JDK 5 without any
> licensing restrictions--for our purposes it's just as good as the JDK 6
> compiler. However, a restrictive beta license covers the apis in the JDK
> 6 jars.
This reminds me of the old gag :
"Doctor, my arm hurts when I lift it"
"Don't lift it then..."
Don't use the JDK 6 jars. All you need to do is *compile*, so lets make
our own JARs that get things to compile.
Is there any runtime dependency on Java SE 6?
geir
Re: 10.2 licensing issue...
Posted by Rick Hillegas <Ri...@Sun.COM>.
Geir Magnusson Jr wrote:
>I read Rick's note on the 10.2 licensing issue in an archive because of
>strange move to the user list, so sorry for the weird quoting :
>
>He said :
>
>"I must report today that the restrictions imposed by the beta JDK
>license have not been lifted.
>
>As you know, the JDK 6 beta license requires a disclaimer that bars the
>use of the code for any productive use....
>
>snip
>
>...For this reason, we, the Derby community must change our
>plan to ship imminently an official release of Derby that includes JDBC4."
>
>Let me start with a question :
>
>Why? Is this all about having a set of API jars to compile against, or
>is it something more?
>
>
Hi Geir,
In a nutshell, yes. We can use the compiler from JDK 5 without any
licensing restrictions--for our purposes it's just as good as the JDK 6
compiler. However, a restrictive beta license covers the apis in the JDK
6 jars.
Regards,
-Rick
>
>geir
>
>
>
Re: 10.2 licensing issue...
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Michael Segel wrote:
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Tuesday, September 12, 2006 5:38 AM
>> To: derby-user@db.apache.org
>> Subject: 10.2 licensing issue...
>>
>> I read Rick's note on the 10.2 licensing issue in an archive because of
>> strange move to the user list, so sorry for the weird quoting :
>>
>> He said :
>>
>> "I must report today that the restrictions imposed by the beta JDK
>> license have not been lifted.
>>
>> As you know, the JDK 6 beta license requires a disclaimer that bars the
>> use of the code for any productive use....
>>
>> snip
>>
>> ...For this reason, we, the Derby community must change our
>> plan to ship imminently an official release of Derby that includes JDBC4."
>>
>
>
>> Let me start with a question :
>>
>> Why? Is this all about having a set of API jars to compile against, or
>> is it something more?
>>
>>
>> geir
>
> Something more.
>
> The trouble is that JDK 6 isn't ready for primetime and from the discussion,
> 10.2 is supposed to go GA prior to JDK 6 going GA. Whenever you're going GA
> and relying on a component that isn't GA, you're going to run in to trouble.
So... what *exactly* do you need from JDK 6 if it isn't a JDBC4 jar to
compile against?
RE: 10.2 licensing issue...
Posted by Michael Segel <ms...@segel.com>.
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Tuesday, September 12, 2006 5:38 AM
> To: derby-user@db.apache.org
> Subject: 10.2 licensing issue...
>
> I read Rick's note on the 10.2 licensing issue in an archive because of
> strange move to the user list, so sorry for the weird quoting :
>
> He said :
>
> "I must report today that the restrictions imposed by the beta JDK
> license have not been lifted.
>
> As you know, the JDK 6 beta license requires a disclaimer that bars the
> use of the code for any productive use....
>
> snip
>
> ...For this reason, we, the Derby community must change our
> plan to ship imminently an official release of Derby that includes JDBC4."
>
> Let me start with a question :
>
> Why? Is this all about having a set of API jars to compile against, or
> is it something more?
>
>
> geir
Something more.
The trouble is that JDK 6 isn't ready for primetime and from the discussion,
10.2 is supposed to go GA prior to JDK 6 going GA. Whenever you're going GA
and relying on a component that isn't GA, you're going to run in to trouble.
Don't take my word for it, just ask Murphy... ;-) (He's the guy sitting at
the end of the bar ...)
I don't think that there is a problem of running beta releases off of JDK6
so the issue is how to handle this. It's a no brainer.