On 6/22/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Isn't an implementation of JSR221 writing (clean room) classes in the java.sql and javax.sql name spaces. (e.g. java.sql.Driver & javax.sql.DataSource). Derby is not doing that, Derby is providing an implementation of a JDBC driver, not an implementation of JSR221 itself. Implementing JSR221 is something that Harmony would (might) do. My point is that the JCP rules for implementation of the spec itself do not apply here.
+1 I agree, on rereading the JSPA agreement, the text I quoted in my previous email refers to independent implementations of the core classes covered by JSR-221. i.e. the java.sql.* classes, etc. Applications which happen to implement interfaces in those packages in their own namespace don't seem to be covered by anything in the JSPA. But, looking at the evaluation license you need to agree to download the spec, it contains this: Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification only for the purposes of evaluation. This license includes the right to discuss the Specification (including the right to provide limited excerpts of text to the extent relevant to the point[s] under discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. *Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property*, and the Specification may only be used in accordance with the license terms set forth herein. This license will expire on the earlier of: ... (ii) the date on which the final version of the Specification is publicly released; Presumably this is where the idea that you can't ship something that implements an interface in a JSR comes from, because you would have needed to copy material which is copyrighted by Sun, and to which you've agreed to this license to have knowledge of. Let's assume that the people who implemented the Derby implementations of the JDBC 4 interfaces are subject to this agreement. And, that this means that the method signatures described in the spec and any javadoc comments in the JDBC 4.0 spec are the IP in question here that we have 'acquired no right' to use. The method signatures in the Derby classes were clearly copied from the spec, and I believe perhaps some javadoc comments as well, although I would need to check that. Now, there are two things involved in our catch-22: * Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. Sun wants to release a version of Derby with the JDK that (I would assume) includes javadoc for Derby that includes material copied from the JDBC 4 spec. But if Sun shipping the JDK is the event which satisifes ' (ii) the date on which the final version of the Specification is publicly released' then the license above expires and the people who were reading the spec and copied parts of it into Derby are no longer bound by this agreement either. It's not clear what license is then in effect, but I would like to think that by virtue of the contributors in question, the ASL is the license in effect on that code, since it was contributed to Derby by employees of Sun under its CCLA and the various ICLAS in effect for the individual contributors. But then, IANAL. As far as the Derby bits that Sun ships in the JDK, well, it's not really Derby they've committed to shipping but JavaDB. So they can twiddle the bits as they see fit I suppose, as long as they don't call it an official Derby release anywhere in the JDK. I could imagine a situation where they simply flip the beta flag and update the version so that Derby reports itself as a 10.2.0.0 database at whatever revision it happens to be the day the JDK ships, along with the modified 'M' flag in the version string. If Sun says that all that did was ship the Derby code at that revision level with the necessary version bits modified, then anyone using the Derby bundled with the JDK will just have to believe them. If, say, that version happens to not upgrade to official Derby releases for some bizarre reason, then suddenly there are lots of new, irate users complaining that Derby is broken. This would make the Derby community look bad through no fault of its own (and Sun has a sticky problem to boot). Hopefully this won't be an issue, though. * Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. One modification here: Derby could ship a GA 10.2 any time it likes. Just not with the JDBC 4 bits. Nor would it want to, anyway, since besides the evaluation license probably covering material that Derby would be releaseing, Derby could possibly ship incorrect implementations of interfaces defined in the spec, and nobody in the community is interested in that. :-) But, once the spec is final, then the Derby community can release its JDBC 4 bits at its leisure, since the evaluation license has expired and presumably the bits in question (i hope) are then covered by the ASL. And, hopefully whatever Derby bits Sun releases as part of the JDK will be compatible with future Derby releases. The Derby community obviously has no responsibility for anything Sun releases, but it can definitely be affected, negatively or positively, by whether or not they get this 'right'. Let's hope they do. So, I can see any of the following things as possibilities: 1) The Derby community could release a 10.2.1.x minus the JDBC 4 bits whenever it likes. Maybe even next week. :-) 2) Sun releases a version of Derby with JDK 1.6 that reports as 10.2.1.x and has upgrade enabled, however they want to do that. Hopefully they get this right and it upgrades to the official 10.2. 3) Once the JDBC 4 spec is final, the Derby community could release 10.2.(1|2).x + JDBC 4 bits pretty much any time it feels it is ready. Regarding (1) and (3), I believe I've seen comments to the effect that there are members of the Derby community that would object to adding the JDBC 4 feature set in a maintenance release (which would be the 10.1.2 in (3) ) which supposedly would not contain any new features. That's the way I see it at the moment. Opinions? Did I miss anything? (Probably. :-) ) andrew
