On Tue, Feb 24, 2004 at 10:30:19AM +0000, Joe Orton wrote: > > Well, if we believe the AL v2.0 is GPL-compatible, then this is a moot > > point, I believe. We're not distributing GDBM (which would be against ASF > > policy), but our license *is* GPL-compatible (mainly because we say it is). > > However, AIUI, note that when GDBM is linked in, *all* of httpd falls under > > the GPL. *shrug* > > Since apr_dbm_gdbm.c is a derivative work of GDBM, the GPL imposes > restrictions on redistribution of apr_dbm_gdbm.c (if not all of > apr-util): this is true regardless of whether or not GDBM is > redistributed alongside apr-util. GPL clause 2(b) is pretty clear: > > b) You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any > part thereof, to be licensed as a whole at no charge to all third > parties under the terms of this License. > > 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? > Given that fact, it is: > > 1. undesirable to redistribute apr_dbm_gdbm.c since it imposes more > restrictive licensing conditions on the code, and more seriously: > > 2. a violation of the GDBM copyright to redistribute apr_dbm_gdbm.c > under the terms of the ALv2, since the FSF considers the ALv2 to impose > extra restrictions beyond that of the GPL. (and it's the FSF's opinion > that counts) > > joe How about one of these options? (a) Remove GDBM support. (b) Only include GDBM support if the installing user passes --enable-gdbm and --enable-gpl to configure (passing only the former would elicit an error). This ensures that the installer accepts further distribution under the GPL. (c) Split GDBM support off in the form of a patch and post it somewhere convenient but separate from the source. (d) Split GDBM support off in the form of a patch and include that patch in the source tree. Users can then actively choose to apply it and build a GPL'ed apr. Note that only options (a) and (c) technically allow us to distribute the source tarball under any terms other than those of the GPL. However, other software packages Jim mentioned, such as Perl, don't get that pure, so I don't think the other options are terribly problematic. I like (b), personally, and will code it if asked. -Noah
