apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <da...@jetnet.co.uk>
Subject Re: gdbm licence issue
Date Tue, 24 Feb 2004 17:56:03 GMT
> > > 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
> > of programs, free and proprietary, is easy GDBM support worth the
> > 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.


Can we make this a priority for the PMC Chair to persue with the board?

Given that SVN is now 1.0 we should really get our asses in gear and get 1.0
out the door. Given the strong opinions that have been shown on list about
this issue this is for sure a showstopper...


View raw message