Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4827A6B6.20904@rowe-clan.net>
Date: Sun, 11 May 2008 21:08:54 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Tom Donovan <donovant@bellatlantic.net>
CC: APR Developer List <dev@apr.apache.org>
Subject: Re: DBD driver license issues (must default to --without-driver)
References: <20080510204359.D31A423889C3@eris.apache.org>
 <8EF26B15-50A2-46A6-BCC3-F10E61684FDD@gbiv.com>
 <4826F363.4030108@bellatlantic.net>
 <C50501CD-307D-4F7E-9557-08FD2AAED31A@gbiv.com>	<48274A92.8090900@apache.org>
 <1210548965.13657.11.camel@shrek.rexursive.com>
 <482790C7.6070309@bellatlantic.net>
In-Reply-To: <482790C7.6070309@bellatlantic.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Tom Donovan wrote:
> Roy T. Fielding wrote:
>>
>> The concern is that someone building a program like httpd, on a platform
>> that just happens to have a lot of databases installed, will 
>> automatically
>> 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.
> 
> Aha!  I see the point now.  Yes, a static build would have unexpected 
> dependencies.  Like the situation with dbm and bdb.  It makes sense that 
> all dbd drivers default to "not built", as there is nothing like sdbm 
> which can safely be bundled with apr as a default dbd driver.  ODBC on 
> Windows maybe - but nothing else seems guaranteed to be present.

Worse - not what's present, but also which version.  Which rev are we
looking at?  The headache is that unreferenced bundled code should not be
linked in, yet these dependencies remain.  Bizzare.

But -not- a regression, it has been this way in 1.2, if it was this way
in 1.3, the user can still perform the following tweak...

> Bojan Smojver wrote:
>> On Sun, 2008-05-11 at 21:35 +0200, Ruediger Pluem wrote:
>>
>>> This already works if you compile apr-util (trunk / 1.3) with
>>> --enable-dbd-dso

But I agree...

>> Maybe that should be the default, combined with disabling of
>> MySQL/Oracle drivers by default due to possible downstream licensing
>> issues?
> 
> I agree that --enable-dbd-dso should be the default (presuming the 
> platform supports dso), but not for licensing reasons.  The APR dso.c 
> code is already there, and apr_dbd.c adds very little additional code 
> for dso drivers; so is isn't a 'library bloat' issue.  Regardless of 
> whether the user has chosen any static dbd drivers, disabling the 
> ability to dynamically load drivers at runtime is restrictive.

Yes - drop any automatically detected dbd provider who's license is more
restrictive than APR's.  If someone such as a linux distro (GPL) wants
to turn back on the mysql dbd, this is their prerogative.

And enable dbd-dso by default even without one provider.

Bill