apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Looking for final determination on shipping binary dbd/dbm stubs
Date Thu, 30 Jul 2009 18:52:54 GMT
Guenter Knauf wrote:
> Nick,
> Nick Kew schrieb:
>> On 30 Jul 2009, at 06:13, William A. Rowe, Jr. wrote:
>>
>>> In between are mysql and db which both have copy-left viral terms
>>> but are not GPL per say.  I thought we had worked out that apr_dbd_mysql
>>> is ok, but I can't find the notes :(
>> re: MySQL
>>
>> If it helps, I just checked back in my blog:
>> http://bahumbug.wordpress.com/2007/08/08/apacheapr-mysql-driver/
>>
>> It's clear the date of that blog article follows  discussion on-list
>> that led to the decision to include it, and it sets out the terms on
>> which we distribute it as I see it:
>>
>> "Suppose we were distributing a non-free product that was arguably a
>> MySQL “derivative work” under the terms of the GPL. We could negotiate
>> terms with MySQL. For a commercial product, that would probably mean
>> paying them money, but that’s beside the point. Under our agreement with
>> MySQL, we can distribute our product on our agreed terms, without
>> reference to the GPL. No problem.
>>
>> But that’s exactly what the FOSS Exception gives us. Explicit permission
>> to distribute our product under the ASL. We didn’t pay for it, but we
>> got it anyway. End of problem."

> but does this also cover distributign binaries which link against
> libmysql.[so|dll|nlm] ?

That is my concern.  The "source code" is not bound (linked) to the driver
dll (which we will never ship for a multitude of reasons).  The act of
creating libmysql.[so|dll|nlm] is an explicit linkage, which we then break
by omitting the linked libmysql module.

A strict reading of mysql and berkeleydb terms says that these modules which
are linked (the stubs) are clearly copy-left'ed.  The gdbm terms further
pollute that stub as GPL, once linked.

We can take the position that the binaries we ship are under the AL v2.0
license with the caviat that you can modify it or incorporate it into
another binary in a way that is not AL v2.0, and that this is not our
actual concern.  Our sources *are* published.

So Win32 or Netware or other binary distribution include apr_dbd_mysql and
apr_dbm_berkeleydb comply with the terms, because they *are* built from
our published source code, and the boundries on both appear to be the
executable, and both stubs are executable code.  The only way to violate
either license from the binary distribution would be to conceal the origin
of the modules, which I believe is an absurd prospect.

It's easy to violate either license/exception by modifying the sources and
then not publishing the modified source, but this is simply impossible with
respect to *our binary distribution*.  Once modified, it's not our distro,
and goes back to the question of the packager combining with mysql or
berkeleydb, not the ASF combining with mysql or berkeleydb.

Is there *anyone* who objects to this interpretation?  If not, I believe
I'm satisifed now in shipping mysql and berkeleydb bindings.

I'm still unable to reconcile shipping the gdbm binding due to the many
ways the GPL v2 pollution can read on the binary distribution.

> And while on this topic: how about PgSQL?

See my evaluation of sqlite, PosgreSQL, and Oracle stubs from last year.

FreeTDS and a unix/netware deployment of ODBC were not considered since on
win32, apr_dbd_odbc binds with no issues to the MS system library.

Don't ship the clients (excepting sqlite, or PostgreSQL if desired, but
note you need to consider crypto export implications if we did).  These
should be easy to obtain and ensure we aren't shipping to cover the
security bulletins issued against the clients themselves.



Mime
View raw message