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