On 6/22/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
>> I think we want that database to play well with the approved >> release candidate which goes GA. >> >> > >The mid-Sep Derby release candidate will be marked alpha or beta (JCP >rules) so the databases won't upgrade anyway. > > I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in.
A release candidate that the Derby community votes on would not be marked alpha/beta by necessity. A vote on a release candidate is for that set of bits to become the release. If the release candidate is marked alpha/beta, and that's what people had voted on, and then the RM rebuilds the distributions to change the version string and publishes that, then the RM would be publishing something that the community had not vetted. Not a good idea. Elsewhere, Daniel John Debrunner wrote:
Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir prominently featured on their "about JCP 2.6 page" [2]): 5.B. License to Create Independent Implementations. For any Specification produced under a new JSR, the Spec Lead for such JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights in and patent claims covering the Specification (including rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to anyone who wishes to create and/or distribute an Independent Implementation of the Spec. Such license will authorize the creation and distribution of Independent Implementations provided such Independent Implementations: (a) fully implement the Spec(s) including all its required interfaces and functionality; (b) do not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Spec or Specs being implemented; and (c) pass the TCK for such Spec. So, all we really need is for Lance, as Spec Lead, to indemnify the ASF from any legal action regarding Derby's implementation of the JDBC 4 spec. Hey Lance, just send a note to the ASF Board that Sun's not going to sue the ASF. Thanks! ;o) Anyway, what's the trigger for breaching the contract here? If it's 'creation' alone, then rolling that release candidate surely qualifies as as creation. If it's 'creation and distribution,' well, is posting the release candidate in a public forum and on a public website (like one would have to do to vote on it) considered distribution in this case? I have no idea, because i'm not a lawyer. Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] andrew p.s. I'm assuming there's no TCK for JSR-221. [1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf [2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html [3] http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt (search for "SUN ISSUES")
