[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The MySQL FOSS Exception v0.1



Greetings Andres,

Thanks for writing.

On Mar 16, 2004, at 01:01, Andres Salomon wrote:
(CC'ing debian-legal for any suggestions they may have, as well)

Excellent!

...

Congrats.  Hopefully we'll see v0.2 very soon.  :)

We have feedback from many people now to integrate, so there should be a new minor release soon.
I expect that a major release is about a week away.

...

When I get back to my home base in a few days, I will drop the
exception into something like CVS (perhaps with CVStrac support ;) so
that we can track every little change and the suggestions that led to
it.

The exception is now in cvstrac - see:
 * http://zak.greant.com/archives/000626.html
 * http://zak.greant.com/cvstrac/index.cgi/licensing/

You are free to distribute Derivative Works that are formed entirely
from works
licensed under under one or more of the licenses listed below without

Small typo; s/under under one/under one/.

Thanks. Already corrected in the CVS version.

affecting
the license terms of the works, as long as:

1. You obey the GNU General Public License in all respects for the
Program and the Derivative Work, except for identifiable sections of that work which are not derived from the Program, and which can reasonably be considered
independent and separate works in themselves,

Ok, so when merely using libmysqlclient via its standard API (the common
case being dynamically linking against it), GPL terms must be followed
for only libmysqlclient; the complete derived work is exempt (contingent upon further text, below). When including actual libmysqlclient code in
a module (or program) that isn't just calling libmysqlclient API calls,
GPL terms must be followed for the entire module (or program).  Using
terms like "reasonable" in licenses makes me nervous, but it seems
pretty clear in this case what is meant.

Please note - before we get into this, I am not a lawyer! I don't even play one on television.

I agree that this is tough language to work with. The positive thing here is that, if there were a court case, it is up to the court to decide what reasonable is (rather than the user or MySQL).

2. You distribute all identifiable sections of the Derivative Work
which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves, subject to one of the licenses listed
below,

Here, permission is granted to distribute with the licenses listed
below.  We'd need to make sure that everything PHP and Apache link with
use only the licenses below.

True enough. Added to the todo list - see http://zak.greant.com/cvstrac/index.cgi/licensing/tktview?tn=4

3. The Derivative Work does not include or aggregate any part of the
MySQL Server (SQL Engine) or any modifications, translations or other
derivatives thereof,


This clause seems very problematic.  The intention seems to be to allow
the license exception to apply only to client libs. Unfortunately, this could easily be violated. For example, some other random piece of GPL'd
software that includes a few files from mysqld (since both pieces of
software are GPL'd, that's fine to do), and then links against apache or
php would violate the exception.  Yikes.  It's not merely the licenses
we must be checking, now; it's also individual source files within all
projects linking against libmysqlclient (or apache, or php, or any
number of other things that may be using php or libmysqlclient).

Furthermore, the definition given for "include or aggregate" below
includes distribution on the same media.  This violates the DFSG
<http://www.debian.org/social_contract#guidelines>, making it
undistributable by Debian (if the clause is in place).  See point #9 of
the guidelines; this clause forces other software that is merely
distributed alongside a libmysqlclient that's linked with PHP (for
example) to not include mysqld. Not only that, but it goes so far as to
say that we cannot allow automated downloading of mysqld with a GPL'd
libmysqlclient and PHP.  That makes this entire exception useless to
most distributors, I'd imagine.

Personally, I agree and believe that we must expand the exception to cover the MySQL server as well. This will solve issues for Debian, Fedora and others. It will also make the exception simpler to understand.

Cheers!
--zak



Reply to: