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:
<http://www.apache.org/licenses/GPL-compatibility.html>
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
