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...
-Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] 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.
Re: 10.2 licensing issue...
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...
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...
-- Original message -- From: Geir Magnusson Jr [EMAIL PROTECTED] 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? JDBC 4
Re: 10.2 licensing issue...
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...
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...
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
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 [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: 10.2 licensing issue...
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 [EMAIL PROTECTED] http://db.apache.org/jdo
Re: 10.2 licensing issue...
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: 10.2 licensing issue...
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
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 [EMAIL PROTECTED] http://db.apache.org/jdo Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
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 [EMAIL PROTECTED] http://db.apache.org/jdo Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: 10.2 licensing issue...
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: 10.2 licensing issue...
So 10.2 only runs on Java SE 6? I sorta doubt this given your traditional care and focus in backwards compatibility. geir [EMAIL PROTECTED] wrote: -- Original message -- From: Geir Magnusson Jr [EMAIL PROTECTED] 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? JDBC 4
Re: 10.2 licensing issue...
Geir Magnusson Jr wrote: So 10.2 only runs on Java SE 6? I sorta doubt this given your traditional care and focus in backwards compatibility. geir Hi Geir, The current beta candidate behaves as follows: i) The application sees JDBC3 functionality when running on the 1.3, 1.4, or 1.5 vms. ii) The application sees JDBC4 functionality when running on JDK 6. We're proposing to change this for the release candidate. We're proposing that, instead, the application will see JDBC3 when running on JDK 6. Regards, -Rick [EMAIL PROTECTED] wrote: -- Original message -- From: Geir Magnusson Jr [EMAIL PROTECTED] 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? JDBC 4
10.2 licensing issue
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. This restriction is meant to forestall binary incompatibilities with the final, GA version of the JDK. These incompatibilities might arise due to late-breaking changes in the JDK during its beta cycle. Due to these late-breaking changes, applications compiled against earlier, beta versions of the JDK could behave erratically when run against the GA JDK. Such a disclaimer would need to appear in the NOTICES file of any Derby release built using the beta JDK's tools and libraries. This, in turn, is unacceptable for GA releases of Derby. Therefore at this time we cannot build a Derby release candidate which includes JDBC4 drivers--today those drivers can only be built using beta tools and libraries. For this reason, we, the Derby community must change our plan to ship imminently an official release of Derby that includes JDBC4. I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in 10.2, I think that (1) is a better plan. Of course, this is up to the community to decide. Regards, -Rick
Re: 10.2 licensing issue
Wow! Thanks for the update, Rick. I agree that option #1 (release 10.2 without JDBC 4) is best. -jean Rick Hillegas wrote: 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. This restriction is meant to forestall binary incompatibilities with the final, GA version of the JDK. These incompatibilities might arise due to late-breaking changes in the JDK during its beta cycle. Due to these late-breaking changes, applications compiled against earlier, beta versions of the JDK could behave erratically when run against the GA JDK. Such a disclaimer would need to appear in the NOTICES file of any Derby release built using the beta JDK's tools and libraries. This, in turn, is unacceptable for GA releases of Derby. Therefore at this time we cannot build a Derby release candidate which includes JDBC4 drivers--today those drivers can only be built using beta tools and libraries. For this reason, we, the Derby community must change our plan to ship imminently an official release of Derby that includes JDBC4. I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in 10.2, I think that (1) is a better plan. Of course, this is up to the community to decide. Regards, -Rick
Re: 10.2 licensing issue
On 9/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in +1 to option one, then. Should we plan to have another release with JDBC 4 once JDK 1.6 ships? andrew
Re: 10.2 licensing issue
Andrew McIntyre wrote: On 9/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in +1 to option one, then. Should we plan to have another release with JDBC 4 once JDK 1.6 ships? andrew +1 I think that would be a great idea. Regards, -Rick
Re: 10.2 licensing issue
Rick Hillegas wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in 10.2, I think that (1) is a better plan. Of course, this is up to the community to decide. I do not think we have enough user feedback for 10.2 release just based on regression risk. We heard that the JDO tests passed and the Torque tutorial ran. We got a few questions on the list about how to upgrade. We got serious feedback from a single user who reported multiple serious optimizer regressions. That's it as far as I can tell from users. We got quite a few regression reports from development that folks stumbled upon. Many of these regressions sadly have already made their way into 10.1.3 and therefore are being picked up by users for production. If this were a medical trial for a blood pressure medicine and not a database what would we do? Our one patient in the trial of our next generation medication is finding multiple issues that have made him very sick and we find that many of these same regressions are in pharmacies now. I think we need to notify the user community of the situation, try to get more user input on 10.2 and flush out more regressions. We port fixes to 10.1 to try to get it to a stable state and then release 10.2. Also any ideas anyone has for new optimizer tests would be good and folks could write those. Those are all my ideas for now. It could be that lots of users have tried 10.2 without problems but haven't reported in and then it is just a matter of getting them to speak up. I will work to rattle the bushes around here and please ping groups where you work and ask them to try 10.2. I will also send a message to the user list to try to get more user input. See feedback I know of at : http://wiki.apache.org/db-derby/RegressionSearchAndDestroy http://wiki.apache.org/db-derby/TenTwoApplicationTesting Kathey
