Dan Shearer wrote:
On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:
Florian Weimer has correctly pointed out that Oracle has decided to change
the BDB 6.0 license to AGPLv3 (
https://oss.oracle.com/pipermail/bdb/2013-June/000056.html).
:
we (as the Debian project) need to take a decision.
:
(because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
and there is code under these licenses which depends on BDB. There is
also code which depends on BDB that is compatible with the AGPLv3
legally, but whose deployment would then be restricted in ways the users
would not be expecting.)
As far as I am aware the most prominent users of Berkeley DB are
moving away from the library anyway ...
There are actually very few true alternatives to BDB. While there are
many KVP (key value pair) stores [1] not many are transactional, allow
multi-version concurrency control [2] and support multi-threaded and
multi-process access. BDB is all of the above, and in addition the BDB
API has become very widely used over nearly 30 years. And of course the
BSD license allowed BDB to be embedded in a huge amount of software -
like the BSD networking stack, it turns up just about everywhere.
So there are three things to think about in a replacement:
1. Is the licensing as suitable as the BSD license has been, and is
the primary maintainer likely to do what Oracle just did to BDB?
2. Are the features at least as good as BDB, and is the API close enough
to make replacement reasonably easy?
3. BDB is very old code. When replacing it can we also adopt modern
approaches more suited to modern hardware and use cases?
I've looked at all of the KVP options I am aware of and consulted people
who specialise in the space and can only see one that fits each of these
well. MDB from the OpenLDAP project, http://symas.com/mdb/ .
As to point 1, the rights holders of MDB need to make a public
statement, but I have asked them in private and in any case the OpenLDAP
history speaks for itself.
Just to be very clear about this, from the perspectives of both me
personally and the OpenLDAP Project.
Personally, I am a very strong supporter of GPL/copyleft. Having been a
gcc maintainer in the gcc 1.x-2.x days, and contributing to gmake,
screen, texinfo, and a variety of other FSF projects, it's been in my
blood for nearly 30 years. (Indeed, I have one of the oldest
GPL-licensed projects around, with a source revision history spanning
back 25+ years http://sourceforge.net/projects/arc/)
Another personal view I hold strongly is that a project's license
shouldn't change unless it isn't working for the users, or the users
approve of a change to cater for some anticipated need.
The OpenLDAP Project's license is BSD-flavored and was established
before I joined. As Chief Architect of the Project I see no reason to
change this. It has served the Project well with no user complaints. The
LMDB code was written for and is part of OpenLDAP, and we consciously chose to
have it covered by the OpenLDAP license. Dan asks, in effect, "will the LMDB
maintainers do with the OpenLDAP license what Oracle just did with the BDB
license?"
The first thing is, nobody has privileged ownership of OpenLDAP code
because the Project does not require copyright assignment. It is not
possible for anyone to build a business model selling secret code
versions while preventing anyone else from building the same business
model through a license such as the AGPL.
Secondly, the OpenLDAP Project is not interested in any kind of
relicensing for any portion of our code, even given that it would not
put anyone in a privileged position. We can't predict the future, but we
have not seen anything indicating it might be needed. We know that there
are other projects which rely on OpenLDAP code being BSD-ish and we
respect that dependency.
There is another party involved who have funded a lot of OpenLDAP over
the years, Symas Corporation. I'm CTO of Symas, and I can tell you I am
quite pleased that even though the company is a good OSS citizen, there
is nothing that could happen in the company which would put Symas in the
position of power that Oracle has over BDB. So Symas' involvement is not
relevant to calculating the risk of a relicensing happening.
In short: OpenLDAP has no intention of relicensing and would not without
consultation with the community, and we have no intention of requiring
copyright assignment to us or anyone else.
As to point 2, MDB provides a superset of the KVP-specific features of
BDB, and the API is similar to BDB but somewhat simpler.
We deliberately modeled the LMDB API after BDB's transactional API because it
made it easier for us to build an OpenLDAP slapd backend based on our existing
BDB backend code. Feedback from other projects shows that our approach has
helped others migrate easily as well.
As to point 3, MDB is a from-scratch implementation in the modern world.
MDB object code is a tiny fraction of BDB, and by adopting a
memory-mapped architecture and dispensing with caching and locking it
relies on modern operating system features rather than trying to
implement them internally. This means greatly increased performance and
very much smaller windows for corruption to occur. MDB has very clean
support for concurrency compared to BDB, which makes it much more
suitable for modern applications.
There is an technical discussion of MDB here:
http://symas.com/mdb/20120829-LinuxCon-MDB-txt.pdf . Some performance
data has been published, one simple test that has a minimum of
imaginable bias is to compare the SQLite3 API that comes with Oracle BDB
with the SQLite3 ported to MDB. The other obvious speed test (that has
had reproducible data published) is with OpenLDAP, which has pluggable
back ends including both BDB and MDB.
We can provide plenty more documentation on LMDB performance and reliability
if desired.
I'll be delighted if someone can suggest something that is even more
suitable than MDB, but so far I haven't seen it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d305b7.8030...@symas.com
