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 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.
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. A
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 the
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 it
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.
http://thread.gmane.org/gmane.comp.apache.apr.devel/12045/focus=12204
-tom-
