apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: gdbm licence issue
Date Tue, 24 Feb 2004 16:46:53 GMT
--On Tuesday, February 24, 2004 10:30 AM +0000 Joe Orton <joe@manyfish.co.uk> 

> 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)

I'm not sure how you view apr_dbm_gdbm.c as a derivative work of GDBM.  Is it 
the fact that it calls some C functions qualifies as a derivative work?  I 
don't think that qualifies under US copyright law.  That'd mean that the FSF 
owns apr_dbm_gdbm.c, which is incorrect.  I believe that line has been solidly 
established.  We're not distributing, copying, or modifying GDBM in that file. 
So, I fail to see how apr_dbm_gdbm.c itself is a violation of the GPL here.

Yes, the fact of apr-util *linking* to GDBM causes the entire work to be GPLd 
(as it is derived from GDBM), but we don't distribute it that way yet doing so 
is not a violation of the AL v2.0.  Please read:


However, this *might* mean issues for downstream participants who package 
apr-util; that in and of itself, might cause us to remove GDBM support, but 
it's not because of any licensing issues.  If we're not comfortable allowing 
third-parties to create GPLd code out of AL v2.0 code, then, yes, that's an 
issue and the code should be removed.  However, that has not yet seemed to be 
our official position.

Thanks!  -- justin

View raw message