Re: 10.2 licensing issue...

[Craig L Russell]

Hi Geir,




Real users can get hurt.

Craig

On Sep 12, 2006, at 9:57 AM, Geir Magnusson Jr wrote:

I hate to be the broken record, but there are real user compatibility issues in releasing a production version of software that depends on pre-release versions of software.

Excuse me - I looked at the 220 license as noted by Craig below, not the

*221* license, which is the one that actually applies.


tell in the spec license.

So the solution to this really annoying, tiresome and really avoidable
problem is either :

1)  Sun to put a user-oriented spec license that lets us just  create
those API jars and let us _compile_.



geir


Geir Magnusson Jr wrote:

It turns out there are *no rights* enumerated for users as far as I can 2) Sun to put the API binary jars for JDBC4 under CDDL or even the BCL.

Craig L Russell wrote:

Hi Geir,

On Sep 12, 2006, at 9:17 AM, Geir Magnusson Jr wrote:

A) I couldn't figure out how to build the dummy jars without cribbing templates from either the beta code or beta javadoc. To me this cribbing

seemed like a forbidden, productive use of the beta-licensed
distribution.

What's the license on the spec?

The spec license has the same restriction on implementations of JSR 220.

If Derby were to build our own "dummy jars" then we would be an

implementation of 220 not just a user of the classes defined in the spec.

Nah.


the rights for "developing applications intended to run on an

not themselves implement any portion(s) of the Specification"


the specification to achieve the goal of "developing applications

such applications do not themselves implement any portion(s) of the
Specification"

Given that :

1) We have no choice

2) we aren't going to ship the spec jars needed to compile


needed to build and ship applications "intended to run on an
implementation of the Specification"

I think we should go forward.

Under the license currently for users on the JSR-220, I as a user have implementation of the Specification, provided that such applications do The spec license - thank goodness - has no limitations on how I may use intended to run on an implementation of the Specification, provided that 3) we aren't going to include them in our application and such jars are

B) It seemed, frankly, a little sneaky and a violation of the spirit of

the license.

As I grok it, the spirit of the license is all about ensuring
compatibility.  Is there anything that you feel about what we're

proposing in any way violates compatibility or puts it at risk for users?

This is precisely the issue. A user of Derby 10.2 compiled with

jars differ from the pre-release jars.

pre-release JDBC4 jars might get unexpected results if the final release

we can test the resulting binary on the Genuine(tm) JDK from Sun.

Sure. There's always a possibility, but I think extremely unlikely, as

For example, constants from the

be detected via the normal compatibility checks.

compile jars get incorporated into the binaries and this conflict won't

under a reasonable license ...

So, assuming we do a good job, do you think there will be a problem?

geir

This sure would be easier if those Genuine(tm) spec jars were available

Craig

geir

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature