On Thu, Apr 03, 2003 at 10:46:31AM +0900, Stephen J. Turnbull wrote:
> Er, now that rings a bell.  Is everybody aware that much djb code
> suffers from legal problems that potentially make it unmaintainable by
> law?  And it is not legal to distribute modified versions (usually,
...
> Which of the several djb (non-)licenses apply here?

None. Although http://cr.yp.to/cdb/cdb.txt is Copyright 1996 D. J.
Bernstein, I'm pretty sure that that copyright does not apply to
an implementation based on reading the description. There are also other
implementations, freecdb and tinycdb, but they don't provide the ability
to update the database at run-time.

Some things are quite different in my implementation, which makes it
definitely fall in the category 'inspired by cdb' as opposed to
'API compatible with cdb',

- Function names are prefixed with rwcdb_ instead of cdb_  ;)
- rwcdb_init takes a file name and O_RDONLY/O_RDWR mode, necessary to do
  correct locking and to write out a new database when it is updated.
- rwcdb doesn't allow multiple data values for one key, this makes is
  easier to remove items, also means that there was no need to implement
  cdb_findinit/cdb_findnext
- There is a new iterator rwcdb_next to iterate over all items in the
  database. Looking at that now, I probably could have used
  cdb_findinit/findnext with a NULL key or something.
- New functions rwcdb_insert, rwcdb_delete. Delete simply inserts an
  item with a NULL data value.
- New function rwcdb_sync, used by writers to force all pending updates
  to disk, readers use it to check if the named cdb files has a new
  inodenumber and reopen the file. I.e. updates are not visible until both
  the writer and the reader explicitly mark a place that won't affect
  consistency, I'm not sure what the technical name is for a barrier
  where you don't have to block.

> That results in decisions like removing db from GNU libc, and Debian
> refusing to support libdb1.

Hmm, RedHat already dropped it in 8.0, and they just announced the 9.0
release. Debian still supports it in stable, and only removed it from
unstable a few months ago. But with their release cycle it will be
another year before it hits the 'stable' users.

And it isn't really the distribution that refuses to support it. It is
stuff like the following in a manpage that I just found with google,


    This version of berkeley db (1.85) is free software which is not
    developed nor maintained by SGI. It is known to have some bugs that
    are unlikely to get fixed (See NOTES below) in particular, certain

* Ok, must be a fragment of a SGI manpage, and clearly they didn't
* develop and don't fix it.

    cursor and certain deletion/overwrite operations are known to have
    problems, up to corrupting databases, and should be avoided
    according to http://www.sleepycat.com/db.185.html.  See hash(3), and
    btree(3) for details.

* Hmm, scary, and that URL doesn't work anymore. I guess nobody really
* uses this library for it's cursors.

  NOTES
    The default hash function in this version of db is the
    Fowler/Vo/Noll hash which gives better distributions (less
    collisions) on average than the publicly released version.

* Ok, not developed or maintained by SGI. But if you change the hash it
* isn't berkeley db 1.85 anymore now is it? This is one example where
* someone might try to share Coda database files and it will break
* unexpectedly.

Jan