apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: gdbm licence issue
Date Tue, 24 Feb 2004 14:35:48 GMT
Noah Misch wrote:
> > The only question in my mind is whether or not apr_dbm_gdbm.c is a
> > derivative work of GDBM.  I think the filename alone gives a pretty
> > strong clue: and unless we want to get Genuine Legal Advice to the
> > contrary, we must default to the presumption that it is a derivative
> > work.
> Based on everything I've read on the FSF website, I'm sure it thinks this file
> is indeed a derivative work.  In my opinion, observing its wishes with regard to
> its own software is important regardless of what we must do, legally.
> Furthermore, since this is a library designed for eventual use in a wide variety
> of programs, free and proprietary, is easy GDBM support worth the associating
> this sort of license uncertainty with the software?

If the simple fact of having completely optional support for gdbm
and writing a code fragment which utilizes the API of gdbm and
the fact that the *name* of the file says "this is the APR
dbm interface for gdbm" means that the code is now a "derivative"
work, APU is one of many many many non-compliant efforts out there.
We don't require gdbm, we don't redistribute it, and it's not
our "preferred" implementation (sdbm is).

I think we should simply ask FSF directly. If it is, then the
Perl/PHP/Python/OpenLDAP, etc... guys would like to know as
well I think.

   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

View raw message