apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <stri...@apache.org>
Subject Re: gdbm licence issue
Date Tue, 24 Feb 2004 14:37:41 GMT
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

Mime
View raw message