On Tue, 2004-02-24 at 15:35, Jim Jagielski wrote: > 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.
+1. Sander
