apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: Licensing for apr_dbd and MySQL
Date Mon, 07 Feb 2005 22:00:32 GMT
On Monday 07 February 2005 20:46, Brian Aker wrote:
> Hi!
> On Feb 7, 2005, at 12:07 PM, Jim Jagielski wrote:
> > PHP has. APR itself is basically a library, used by HTTPD as well
> > as others. apr-dbd is very useful, but the most popular usage of
> > it would be within its MySQL support (think of it as an apr equiv
> On a different note, who coded this? I can have one of our connector
> writers go over it and see if we can do any improvement on the layer. I
> would be happy to dedicate some engineering resources to improve on
> this if need be.

I hacked up the original.  Part of the code comes from older work; parts are
new and untested.  Your attention to it will be most welcome, regardless of
the eventual decisions re: licensing and distribution.

> Quite frankly I don't like ODBC, and from the stand point of a C/C++
> developer I would like to see one common library interface to exist
> that everyone could use. A universal C API to databases in the open
> source world would be quite nice. I know that we would make use of it.

From my POV, I had a C++ base class for SQL with instantiations for the
individual databases, including MySQL.  Then I developed an Apache
frontend to the database, using the base class.  apr_dbd is distilled from
that, dumping C++ and project-specific functionality and expanding the
generic/reusable stuff after discussion on this list.

So I guess that's what apr_dbd is:-)

> > its API. Another way of looking at it would be if we had an
> > auth module that allowed auth info to be stored within a
> Sounds like what the libdbi guys were doing.

libdbi has been discussed in this context, and (like Perl's DBI/DBD) is
certainly "prior art" for  apr_dbd.  But apr_dbd comes straight from the 
Apache/APR architecture, where libdbi was not such a great fit.

> The act of distribution is the key here. As long as the closed source
> (which in really isn't closed source, is just undistributed) isn't
> distributed then everything is fine. If someone distributes closed
> source, even with the FLOSS exception, then there is an issue.

That is exactly the issue.  MySQL licensing imposes that restriction,
but Apache licensing disallows it.

I think it would be a good idea for your legal department to review the issue.

Nick Kew

View raw message