Skip site navigation (1) Skip section navigation (2)

MySQL licensing, was Will Open Source be forced to go Proprietary

From: "Chris Travers" <chris(at)travelamericas(dot)com>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>,"Christopher Browne" <cbbrowne(at)acm(dot)org>
Cc: <pgsql-advocacy(at)postgresql(dot)org>
Subject: MySQL licensing, was Will Open Source be forced to go Proprietary
Date: 2004-01-11 09:22:59
Message-ID: 00cc01c3d824$b3086540$4044053d@winxp (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacy
To try to keep this marginally on topic-- MySQL is a good example of
"proprietary open source" as we have been discussing and their business
model demands that.  That is fine for them for now, but maybe this is not so
good in the future.  I think that the open source model and proprietary
models do not mix well.

Ok, I have been unable to find what I was looking for in the GPL.  However,
I did find the following language interesting:

"These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it."

Seems to undercut MySQL's claim regarding distribution of a proprietary app
which depends on MySQL.

IANAL, but I understand that the definition of derivative works varies from
juristiction to juristiction, and that only a few circuits in the US even
have a clear test.  IMHO, this leaves MySQL with a SCO-like dilemma-- sue or
not to sue in cases where there is disagreement about the nature of the
license.  (BTW< the Nusphere case was far more clear cut than the
hypotheticals I am discussing now).  If I distribute MySQL on the same media
as a web service that exposes the MySQL lib interfaces, and a proprietary
web client which uses those interfaces, then MySQL could either sue me and
risk their marketing platform if the court finds against them or they could
refrain from suing me and just badger me about licenses.  This is a
lose-lose situation for MySQL because the lack of clarity creates a problem
regarding their business model (licensing) which is not good.

Also, the "depends on" test might be a bad idea for another reason-- if held
up in court, any software written exclusively for MS Windows would therefore
be a derivative work and subject to royalties from Microsoft!  IANAL, but I
have a HARD time believing that such a precedent would be established.  The
only approach I can see them taking is that of direct linking, which is
similar to the approach of the FSF.  I don't think that targetting MySQL as
a development platform consitutes a derivative work, but linking might.
Furthermore a bridge might be allowed because a wrapper library would have
to be licensed under the GPL, but the library itself (and header) would
still be copyrighted by the author who could use it in a proprietary app.
If course, in circuits with no clear test of derivative works, I could
imagine courts ruling either way, so one is never safe, but MySQL isn't

PostgreSQL licensing avoides these problems by using the BSD license which
permits derivative works nearly without limitation.

Is there anybody out there interested in putting together some competitive
material regarding MySQL with regard to licensing and consistancy issues as
well as different features?

Best WIshes,
Chris Travers

In response to

pgsql-advocacy by date

Next:From: Dennis BjorklundDate: 2004-01-11 09:29:23
Subject: Re: psql \d option list overloaded
Previous:From: Chris TraversDate: 2004-01-11 09:21:32
Subject: Re: Will Open Source be forced to go Proprietary

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group