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