db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael J. Segel" <mse...@segel.com>
Subject Re: FW: [Fwd: Re: Are you happy with Derby?]
Date Thu, 27 Oct 2005 04:12:19 GMT
On Wednesday 26 October 2005 17:44, Daniel John Debrunner wrote:
> Raji Sridar wrote:
> > Hi Michael,
> >
> > Your opinion was very encouraging - I also built a prototype based on
> > Derby. I am happy to say, that our management has almost decided on
> > Derby, subject to legal approval for the licensing aspects.
> >
Yeah thats the kicker.
I'm not a lawyer, so take what I say with a grain of salt.

If you use Derby embedded in your app, you have to also ship a copy of the 
derby source code with your app.  Note: If your app is actually a 
modification to Derby, then you have to publish the source code of your app. 
And this is where it gets tricky.

Hypothetical Situation #1:

You're embedding Derby in to your IP telephone switch to track call 
information. You do not modify the source code of Derby and use as is.

In this situation, you are required to include the Derby source on your 
distribution CD-Rom. 

Hypothetical Situation #2: 

You're building a new indexing strategy to allow you to use standard Derby 
indexes, and one for full text search. You then embed this in to your web 
server software.

In this situation, you need to include the Derby source code, along with your 
modifications. That is to say, you need to make your IP public and release 
under GPL.

Hypothetical Situation #3:

Instead of creating a second index, you create a method for allowing 
individuals to attach their own indexes to Derby and you extend the SQL to 
allow an end user to specify which index to use. You then embed this in your 
web server along with a proprietary full text index.

In this situation, you have to make public the code which modifies Derby. You 
do not need to GPL your proprietary index technology. 

Sorry to go in to a lot of detail on this. And of course, I may be wrong cause 
I did too much brain damage from OTC's bath tub gin... ;-)   This requirement 
of GPL is something that may scare people off from using GPL or may lead to 
future potential litigation. This is why you will see things released with 
multiple licensing agreements.  MySQL for example is  released under a dual 

So be careful. ;-)

You may want to consider talking to IBM about licensing Cloudscape... ;-)
> > We plan to use Derby as an embedded RDBMS in our Network Management
> > Application. The data stored in Derby will be typical network management
> > data pertaining to the inventory, fault and performance aspects of
> > network elements.
> >
> > With this mind, I would like a clarification:
> >
> > If an external application would like to extract this data for
> > correlation with the typical customer data, the general way will be to
> > use ij and proceed. The double booting issue will prevent this. What are
> > all the possible workarounds for the double booting issue? Can you
> > please give me the required pointers?
I would not recommend ij as a tool for this. 
Its a dumb (simple), generic tool, which will probably bite you in the ass 
down the road.  It would be better to think about the use cases and then 
write a specific tool that will handle potential exceptions better, and 
possibly handle security better.

> You can also embed the network server in your application, either using
> code or just setting a single property. This then allows remote access
> over tcp/ip to your database, while you application continues to access
> Derby via the embedded driver.
Yes. This is probably a good design.  You will definitely need to think about 
remote access and some basic security. 

> The clients access derby using the client driver, either using JDBC or ij.

Skip ij.

Again, I'm not bashing ij, its just that from a design perspective there are 
considerations which would suggest that custom code in place of ij would be a 
better choice.

> For the picture look at pages/slides 53 & 54 of this:
> http://db.apache.org/derby/binaries/djd_derby_intro.pdf
> Doc links at:
> http://db.apache.org/derby/docs/10.1/adminguide/
> > Is there any potential issue when multiple copies of Derby runs in the
> > same PC (Within the same application or within different applications)?
> No issues. You may want to select your own tcp/ip port for the network
> server rather than using the default.
> Dan.

Uhm.... Actually I would disagree. There are always issues when you're 
designing software.  Interestingly enough, Dan points out the issue of tcp/ip 
port selection.... ;-) 

The simple answer is that you *can* have multiple copies of Derby running on 
the same machine.

The longer answer is that for each copy of Derby, you will have a certain 
amount of overhead or system resources allocated to that specific copy. 

So how large is your Derby database? How efficient is your app, and how large 
is your sandbox?

The point being is that these are all considerations when designing an app. 

You also bring up an interesting issue. Why would you want to have a single 
app run multiple copies of Derby? (I can think of a couple of designs but 
you'd have to be really paranoid to justify them... ;-)

But hey, what to I know?
Some may say that I'm a bigger clown than OTC. ;-) (Its an Informix 
thing... ;-)


Michael Segel
(312) 952-8175

View raw message