RE: [stellation-res] Stellation support for MySQL on Linux

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Fri, 2002-11-01 at 18:40, Jonathan Gossage wrote:
> > >-----Original Message-----
> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > >Chu-Carroll
> > >Sent: November 1, 2002 6:15 PM
> > >To: stellation-res@xxxxxxxxxxxxxxx
> > >Subject: RE: [stellation-res] Stellation support for MySQL on Linux
> > >
> > >
> > >On Fri, 2002-11-01 at 17:49, Jonathan Gossage wrote:
> > >> > >-----Original Message-----
> > >> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > >> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of
> > >Dave Shields
> > >> > >Sent: November 1, 2002 2:51 PM
> > >> > >To: stellation-res@xxxxxxxxxxxxxxx
> > >> > >Subject: Re: [stellation-res] Stellation support for MySQL on Linux
> > >> > >
> > >> > >
> > >> > >On Fri, Nov 01, 2002 at 01:25:12PM -0500, Jonathan Gossage wrote:
> > >> > >> Actually I am planning to install Linux from the current
> > >> > >Debian distribution
> > >> > >> but I will let you know how things go and will provide some
> > >> > >installation
> > >> > >> notes.
> > >> > >
> > >> > >By the way, be sure to use MySQL Connector/J 2.0.14 (the stable
> > >> > >version),
> > >> > >as it is licensed under LGPL.  I just noticed that Connector/J
> > >> > >3.0.1.Beta
> > >> > >(the development version) is licensed under GPL, so we can't use
> > >> > >it with code
> > >> > >licensed under the CPL. If J 2 doesn't have the desired
> > >functionality
> > >> > >then we won't be able to support the use of MySQL with Stellation.
> > >> > >
> > >> > >dave
> > >> > >
> > >>
> > >> We can't ship a GPL licensed driver as part of Stellation byt
> > >nothing stops
> > >> a user from using such a driver if the user obtains the driver
> > >> independently. We simply have to point potential users in the right
> > >> direction.
> > >
> > >No. It's worse than that. If we write *anything* which specifically uses
> > >something licensed under the GPL, then
> > >we fall under the GPL. So any code that we write that
> > >specifically works with the GPLed MySQL JDBC driver is
> > >automatically GPL, and anything which calls that, and so
> > >on.
> > >
> > >LGPL allows certain kinds of linking without automatically
> > >becoming GPL. Our lawyers have agreed that it's OK for
> > >us to use LGPLed JDBC components. Full GPL is another matter. If the
> > >MySQL database component is written to use the GPL JDBC driver, then
> > >it's got to be GPL. And then the generic AbstractDatabase class needs to
> > >be GPL, because it connects to the MySQL database component. And then
> > >the whole core needs to be GPL, because it uses the AbstractDatabase
> > >class.
> > >
> > >That's the way GPL works. So if the JDBC MySQL driver becomes
> > >GPL, then we're stuck: we can't support it.  (I can check with our
> > >lawyers to see what the dual-license nature of
> > >MySQL means... but I strongly suspect that the answer will
> > >be "no".)
> > >
> I don't see how that can be enforced. If a user downloads Stellation,
> decides that MySQL is a good database choice and downloads the GPL driver
> instead of the LPGL driver who is at fault. 

If we in any way suggest that we expect people to use the GPLed version,
then *we* are. If we change our code to reference the driver under the
name which works with the
GPLed driver, we're caught. We *might* still be responsible
in any case. GPL is a *very* viral license. It's designed
to be that way - to attach itself to other software as
broadly and aggressively as possible. 
	
> There is no programmatic way of
> determining, 5 years from now if a given driver is appropriately licensed.
> It would seem to me that if your lawyers are right than we must take
> explicit steps to prevent Stellation from working with any industry standard
> interfacce such as JDBC that might bring a GPL licensed component together
> with a CPL licensed component. Under that scenario would not Postgres also
> be disqualified?

This is my understanding, and I'm not a lawyer, so it might
not be correct. But it is my best understanding.

If you write code that *specifically* uses GPL code, then
you're trapped by the GPL license. End of story.

If you write code that *someone else* links against something
GPL, but which you wrote for something that wasn't GPL,
then you're not trapped by the GPL license. So for example,
if you write code under AIX which uses the standard C
libraries, then just because someone else compiles it on
an OS where the libraries are GPL, you aren't falling under
the GPL.  On the other hand, you *cannot* distribute a
port to the OS where the libraries are GPLed - not can
you include any code which provides *any* custom behavior
for the GPLed libraries. Even putting an ifdef that references a symbol
defined only in a GPL license *might*
be enough to trigger the GPL on you.

So, getting back to Stellation, if we use absolutely generic JDBC code,
and someone runs it against a JDBC driver that happens to be GPL, we
aren't affected. But if we write MySQL specific code, which specifically
references the GPLed version of the driver; or in our documentation even
*suggest* that you should (or perhaps even *could*) use the GPL version,
then we have to conform to the GPL. The only way
we can support MySQL is by making the documentation *perfectly* clear
that you must use the LGPL version of
the driver, and probably put in code to make sure that you
use the older driver version. 

The current PostgreSQL is the UC regents license - essentially the BSD
license. We're clear under that. Firebird
is basically the mozilla license. We're clear under that. 
DB2 and Oracle are both commercial products where the JDBC
libraries have non-viral licenses. All of those are
absolutely fine. If they change the license in the future,
then we might need to respond to those changes. 

Switching the MySQL driver to GPL makes it pretty close to
impossible for us to support MySQL. I really hate that,
because MySQL has significant performance benefits. But
unless we can either find an alternative JDBC driver that we
can safely use, or we can have the code verify that it's working with
the LGPLed version of the driver, I don't think we can safely, legally
use it.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx