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