[EMAIL PROTECTED] wrote:
Kasper Nielsen <[EMAIL PROTECTED]> writes:
David Van Couvering wrote:
To be honest, this looks more like a job for BDB than for Derby. I
would love to see the Derby store API made public at some point, but
currently it's not public and I suspect it may be difficult to work
with. Are there reasons BDB/Java won't work for you?
Not besides the license:)
Its for an BSD licensed project, so BDB is pretty much out of the picture.
According to David's recent blog
http://weblogs.java.net/blog/davidvc/archive/2006/11/oracle_benchmar_1.html
"The BDB license is clear: if your product that uses BDB is
closed-source, or you want indemnification, then you need to us pony
up $$$ for the commercial license. If your product is open source, you
can use the BDB open source license, which is a variant of a BSD
license."
So if your project is BSD also, shouldn't you be able to use BDB in
it?
The BDB license is a viral license much like GPL and in fact was
designed to be identical in effect with the GPL. But for some historical
reasons they didn't choose GPL. So if you include BDB in your library.
Anybody using your library would need to make their application open
source.
Now, I'm no expert on licenses. But wouldn't the following scenario be
allowed? In fact I don't see any difference compared to how you would
use MySQL or PostgreSQL from within a Java application.
Launch a process with a standalone BDB database with a small (open
sourced) network layer on top. Then launch your application (in another
process) which would use a another small network layer to communicate
with the BDB process. There would probably be some overhead involved
with using local socket communication. But probably not much compared to
disk latency.
Of course the application would require two VM instances but for some
applications that might not be a problem. Perhaps you could even launch
the BDB database from within your own program. So users wouldn't need to
start both manually.
Cheers
Kasper
