www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Derby and the JCP
Date Wed, 16 Aug 2006 03:45:01 GMT
Geir Magnusson Jr wrote:

> Daniel John Debrunner wrote:
>>Bill Shannon wrote:
>>>We've approved an update to the spec license for non-final specs that
>>>removes the notification requirement for applications.  We'll be
>>>publishing an updated version of the JDBC 4.0 spec ASAP, with luck
>>>this week.  I hope this will address your concerns.
>>Thanks Bill.
>>Now for the next concern, which in a way is a more general concern. :-(
>>For an ASF release, what are rules for the third-party items a release
>>manager used to *build* the release? I'm not asking about distributing
>>such items, just the use of them during the build process.
>>>>From this discussion it seems clear that any use of a third-party
>>licence that imposes a restriction on the resulting build is not acceptable.
>>What about if the release manager belongs a select group of folks who
>>can get some technology under a licence that does *not* impose
>>restrictions, while the generally available licence does impose
> I would be curious to learn about how a project decided to get itself
> into that situation.

The story for Derby is that it has three optional build components:

A) JDBC driver implementing JSR 221 JDBC 4.0 proposed final draft
B) JDBC driver implementing JSR 169 JDBC Optional Package for
CDC/Foundation Profile 1.0
C) OSGi bundle activator class

These were all made optional because the jar downloads required to build
them were not "easily" available. E.g. in beta, hard to obtain, under a
licence that may be incompatible with ALv2 and/or required registration.

This actually fits in well with the Apache 3rd party licence draft policy


Having references to these classes or api's in Derby's source seems fine
from a legal point of view (at least for JSR 169 and 221).

The issue I was wondering about was building ASF releases by compiling
against third-party jars (but not distributing the third-party jars)
that implement these interfaces. These jars tend to be under licences
that possible place restrictions on the resulting derby jar, e.g.
Mustang's beta licence, SCSL etc.

Now since all those optional components were set up, the ASF now has the
Harmony & Felix projects in the incubator that provide the raw material
to build JSR 169 jar and the classes required from OSGi. Thus those
classes could be checked into Derby's svn and reduce the downloads and
make them not optional targets. One issue I'm not sure about here is
taking code that's under the ALv2 from an incubator project before it
has graduated into another ASF project.  Is that ok or not?

Not sure if something similar can be done for the requirement to use
Mustang to build JDBC4 support because I don't know the details of what
is really required from Mustang.


DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message