apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Re: DBD driver license issues (must default to --without-driver)
Date Mon, 12 May 2008 00:35:19 GMT
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 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
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.

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

That solves the runtime failure, but if an httpd build finds mysql.h on the system and silently

compiles and links apr_dbd_mysql - the user might be unaware that his/her binary has just
become a 
MySQL "derivitave work".  Even if the license is OK, this could add some disclosure requirements.
good argument for always requiring the -with-mysql switch. ditto for the other drivers.

> 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
user has chosen any static dbd drivers, disabling the ability to dynamically load drivers
at runtime 
is restrictive.

Specifying --enable-dbd-dso and choosing one dso driver (even if you don't need it, and delete
after building) enables dynamic dbd drivers.  This seems to be how the ability to load 3rd-party

drivers is currently handled in practice.

There was a discussion about a year ago about adding ABI versioning for out-of-tree dbd drivers.



View raw message