[DoubleMalt]

The difference being that these projects had the restrictive licenses from early on. They did not change from permissive (and in the context of web service infrastructure GPL is actually a permissive license) to something more restrictive.

On the contrary Qt changed the license from GPL to LGPL what definitely helped the proliferation (and the survival after the Nokia disaster).

MySQL ... well moving this to AGPL would give MariaDB the final push it needs (if it still needs one). So they just let it rot.

Too bad there was no equivalent project for BerkeleyDB.

[davidw]

You can always fork from the last version that had a license you found acceptable.

Also, a relatively restrictive (not BSD!) license has been a feature of Berkeley DB for a while:

http://en.wikipedia.org/wiki/Sleepycat_Software

[jcrites]

Regarding a Berkeley DB equivalent, how about Tupl?

https://github.com/cojen/Tupl

> Tupl is a high-performance, concurrent, transactional, scalable, low-level database. Intended to replace BerkeleyDB, Tupl supports true record-level locking. Unlike BerkeleyDB-JE, Tupl doesn't suffer from garbage collection pauses with very large databases. Tupl also includes support for cursors, upgradable locks, deadlock detection, hot backups, striped files, encryption, nested transaction scopes, and direct lock control.

[evgen]

In Java. For a low-level in-process library that most people link in to their actual app Java is completely unsuitable. Not quite sure how this replaces most of the BDB use-cases, but if you are going to run in another process then there are a whole host of options to consider. Tupl looks pretty interesting and it would be fun to have a reason to play with it, but this does not handle any of the cases where I turn to BDB.

[moderation]

OpenLDAP LMDB (http://symas.com/mdb/) may be an alternative via http://developers.slashdot.org/story/13/07/05/1647215/oracle...