Geir Magnusson Jr wrote: > Daniel John Debrunner wrote: > >>Jean T. Anderson wrote: >> >> >>>David posted a good summary of the legal catch-22 at [1]. But the >>>shortest story is: >>> >>> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. >>> + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. >>> >>>Let's keep this thread confined to the JCP issue Andrew raised that to >>>roll a release candidate qualifies as "creation".[2] And those release >>>candidates will be generally available. >> >>I don't think the JCP rules apply since we are not creating an >>implementation of JSR221. > > > How could that be? Where did the information for the APIs come from?
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. >>I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver >>until Mustang goes GA, but that's not the JCP rules that Andrew provided >>references to. It would be good to get Lance to expand on what he meant >>when he said: >> >>"You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final." >> >>Where does this restriction come from? > > > I'm not sure. The license on the public review draft gives no rights to > distribute an implementation under *any* label (more recent public > review draft licenses do now after the whole EJB3 brouhaha) My point is "implementation" of what exactly. I think Lance (JSR221 spec lead) has already said that the TCK for JSR221 just checks the the classes (java.sql etc.) exist and have the correct methods & signatures, that implies to me that implementing JSR221 means providing those classes. Dan.
