gdbm licence issue

[Joe Orton <jo...@manyfish.co.uk>]

Bringing this up in the appropriate forum.  IANAL, but...

gdbm is licensed under the GNU GPL.  apr_dbm_gdbm.c uses the GDBM
interface, hence is a work based on GDBM, hence all of apr-util must be
redistributed only under the terms of the GPL.

So I propose to remove apr_dbm_gdbm.c (and associated autofoo) from
apr-util.  Objections?

apr-util has one other surprising licensing gotcha that I'm aware of:
the Berkeley DB licence requires you to provide source to your
application if you redistribute BDB with your app, but I don't know
where the ASF stands on that.

joe

Re: gdbm licence issue

[Klaus Keppler <kl...@informatik.stud.uni-erlangen.de>]

Tricky issue...

I'd prefer to let the user decide whether to include GDBM or not.
Because when you're writing an OpenSource application under GPL
you'd have no trouble with including GDBM. Hence the configure output
could give an informational message like
"!!! You're now also working under GPL !!!" when your're building
apr-util with gdbm enabled.

By the way: is "supporting" an interface same as "using" that interface?
(thus, is supporting GPL'ed software same as using/incorporating that?)

Have a look at MySQL: there's a clause that applications with MySQL
support only need to be under GPL when they rely on MySQL; any 
application capable using another db system (e.g. postgresql)
doesn't need to be under GPL. (if I understood that correctly :-)

Klaus


> Joe Orton schrieb:
> Bringing this up in the appropriate forum.  IANAL, but...
> 
> gdbm is licensed under the GNU GPL.  apr_dbm_gdbm.c uses the GDBM
> interface, hence is a work based on GDBM, hence all of apr-util must be
> redistributed only under the terms of the GPL.
> 
> So I propose to remove apr_dbm_gdbm.c (and associated autofoo) from
> apr-util.  Objections?
> 
> apr-util has one other surprising licensing gotcha that I'm aware of:
> the Berkeley DB licence requires you to provide source to your
> application if you redistribute BDB with your app, but I don't know
> where the ASF stands on that.
> 
> joe

Re: gdbm licence issue

[Greg Stein <gs...@lyra.org>]

It isn't dragging on at all. The APR PMC has asked the FSF about it via
their licensing@ address. Awaiting a response now...

Cheers,
-g

On Thu, Feb 26, 2004 at 10:01:19AM +0100, Dirk-Willem van Gulik wrote:
> This is dragging on a bit - while it is important in my
> opinion. To resolve this you - perhaps give your PMC
> some input as what you would like them to do:
> 
> ->	Ask the board; my guess is that our answer will be;
> 	not a derived work if we are talking about #include <...
> 	and strict API use.
> 
> 	But I sure would like to know for sure that a ./configure && make
> 	for bin releases by our volunteers which we distribute from the
> 	ASF would pick this up by accident. So this may lead to a
> 	--dist-build flag or something; or a script like the build one
> 	on 1.3
> 
> ->	Ask the board to ask the FSF - which is clearly
> 	a double edged sword; as they have an oracle like
> 	expectation to have their answer taken on face value.
> 
> ->	Simply ignore it - it is not an issue.
> 
> ->	Simply sidestep the issue and ditch gdbm (I personally prefer
> 	Berkely DB et.al. anyway).
> 
> If you see some more possible paths going forward - add them - and
> I suggest to have a few +1/-1's to guide your PMC.
> 
> Dw

-- 
Greg Stein, http://www.lyra.org/

Re: gdbm licence issue

[Dirk-Willem van Gulik <di...@asemantics.com>]

This is dragging on a bit - while it is important in my
opinion. To resolve this you - perhaps give your PMC
some input as what you would like them to do:

->	Ask the board; my guess is that our answer will be;
	not a derived work if we are talking about #include <...
	and strict API use.

	But I sure would like to know for sure that a ./configure && make
	for bin releases by our volunteers which we distribute from the
	ASF would pick this up by accident. So this may lead to a
	--dist-build flag or something; or a script like the build one
	on 1.3

->	Ask the board to ask the FSF - which is clearly
	a double edged sword; as they have an oracle like
	expectation to have their answer taken on face value.

->	Simply ignore it - it is not an issue.

->	Simply sidestep the issue and ditch gdbm (I personally prefer
	Berkely DB et.al. anyway).

If you see some more possible paths going forward - add them - and
I suggest to have a few +1/-1's to guide your PMC.

Dw

Re: gdbm licence issue

["Roy T. Fielding" <fi...@gbiv.com>]

> Use of the API is usually interpreted as forming a derivative work 
> under
> copyright law, and I'm certain it's the FSF's interpretation, which is
> what counts here.

Actually, no, the FSF is the only legal entity known to mankind that
interprets copyright law in that fashion, and has so far avoided the
question coming up in litigation.  US copyright law is quite clear
that you cannot create a derivative work simply by using the work.
The API may be used if it is described anywhere under terms that allow
reuse without restriction, including if it is described in a classroom
or lecture environment.  However, other aspects of the API (such as
comments within the header files) cannot be copied without creating
a derivative work.

If you want to be sure, though, ask the copyright holder and be
prepared to delete the file if they say that it is derived.

BTW, this has nothing to do with the 2.0 compatibility issue, which
has not yet been resolved.

....Roy

Re: gdbm licence issue

[Joe Orton <jo...@manyfish.co.uk>]

On Mon, Feb 23, 2004 at 04:25:41PM -0500, Jim Jagielski wrote:
> Joe Orton wrote:
> > 
> > Bringing this up in the appropriate forum.  IANAL, but...
> > 
> > gdbm is licensed under the GNU GPL.  apr_dbm_gdbm.c uses the GDBM
> > interface, hence is a work based on GDBM, hence all of apr-util must be
> > redistributed only under the terms of the GPL.
> > 
> 
> We just use the gdbm API, don't we? As such, I don't think that
> GPL applies.

Use of the API is usually interpreted as forming a derivative work under
copyright law, and I'm certain it's the FSF's interpretation, which is 
what counts here.

C'mon, think about it: if you could link random bits of code against a
library licensed under the GPL without forming a derivative work, the
GPL would be fairly pointless and certainly not very "viral" as everyone
gets so upset about.

joe