Re: Berkeley DB 6.0 license change to AGPLv3

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/