db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: catch-22: Derby, Mustang, and JCP issue
Date Fri, 23 Jun 2006 06:32:12 GMT
On 6/22/06, Daniel John Debrunner <djd@apache.org> 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

Mime
View raw message