Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <449BCE21.2000207@pobox.com>
Date: Fri, 23 Jun 2006 07:18:57 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: catch-22: Derby, Mustang, and JCP issue
References: <449B3321.6080701@bristowhill.com>
 <449B4D5F.8070008@apache.org>	 <449B5B49.5040601@pobox.com>
 <449B7BD6.8030601@apache.org>
 <54ac72d70606222332w75f301f2y627f3ac97fa68017@mail.gmail.com>
In-Reply-To: <54ac72d70606222332w75f301f2y627f3ac97fa68017@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Nice post.  Comments inline :

Andrew McIntyre wrote:
> 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 just can't agree that this is true as much as I want to, because the
draft license is clear, and the spec itself claims that any
implementation of a driver is a JDBC implementation.

However, it may not matter.

> 
> 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:
> 
[snip spec license blurb]

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

The Apache License is the only copyright license on the code for
downstream licensees.  Nothing else - Sun's weird theories about spec
copyright notwithstanding.

Patents are another story, of course, but unless Sun or other
contributors to the 221 EG assert that there are necessary patents, we
should ignore them here.  (Which brings up an interesting situation for
discussion at another tim that if there are necessary patents held by an
EG member, and there is no TCK for which to certify compatibility of an
implementation, which the spec claims a driver is....)

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

This is where things start to smell like a fork.

If JavaDB behaves differently than Apache Derby for the same version
number, that's a problem.

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

Don't worry about the "expiration" mechanism - once the spec is final,
it's clear Derby can ship an implementation of it.

BTW, those "bits in question" are *always* covered by the Apache License
(it's not the "ASL" by the way - that was v1.x)  The issue is if the
project can distribute them.  The issue really is if it's legal to
implement, but Sun has acknowledged this problem with a new version of
the spec license this last May.

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

Exactly.

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

What does it mean "upgrade enabled"?

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

Could you simply uptick the version as appropriate when JDBC4 is finally
added?

geir