apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: DBD driver license issues (must default to --without-driver)
Date Sun, 11 May 2008 18:39:52 GMT
On May 11, 2008, at 6:23 AM, Tom Donovan wrote:

> Roy T. Fielding wrote:
>> This is a showstopper.  It must be fixed in 1.3.x before release.
>> My fix is also incomplete: All of the other DBD drivers that do  
>> not have
>> redistributable client libraries must also default off.  Oracle is  
>> one
>> for sure -- I am unaware of the terms for the other drivers.
>> ....Roy
> Was it discovered that the MySQL exception doesn't work?  Or is the  
> concern about incorporating APR or httpd into commercial software?

The concern is that someone building a program like httpd, on a platform
that just happens to have a lot of databases installed, will  
compile into apr-util hard dependencies on all of those libraries even
though they have no intention of using them.  In particular, it makes it
difficult for our own developers to build binaries for our releases that
can actually be redistributed under our license.

In my case, compiling with --disable-shared caused the ab executable
to fail at runtime when it tried to load libmysqlclient_r.  ab doesn't
use a DB.  The fact that all this unnecessary crap is getting bundled
into what was supposed to be a portability library is another problem.

Actually, I don't understand how this is supposed to work at all.
Having these interfaces in a library means that anything we
pick as a DBD interface must be redistributed with the binaries.
An operating system distro may be able to pick and choose a suite
of databases to always have installed, but I don't see how we are
going to do that just distributing httpd.

I suggest that the way forward is to separate DBD from apr-util and
make it capable of finding and remapping the DB shared libraries at
initialization time, rather than compile time.


View raw message