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 [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
