Re: How i can use MySQL connector/J with GPL compliance?
Jos Visser (OSP <josv <at> osp.nl>
2011-10-22 03:37:45 GMT
Thanks for your answer and the references. Some more thoughts around this topic:
I like the viewpoint that in the end of the day it is not the actual
mechanics of the linking process which defines whether there is a
"derivative work", but rather the intention of the author(s). In RMS'
words: "If there are two modules that are designed to be run linked
together and it's clear from the design from one or the other that
they are meant to be linked together then we say they are treated as
In this view the actual mechanics of the linking might be an
indication of whether there is a derived work, as the GPL FAQ
(http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF) says: "If
the program uses fork and exec to invoke plug-ins, then the plug-ins
are separate programs, so the license for the main program makes no
requirements for them. So you can use the GPL for a plug-in, and there
are no special requirements." I think that this statement is too
general because I can easily envision a situation where a non-free
program starts a plug-in through fork/exec but then communicate so
intimately over the process barrier (using pipes, shared memory or
whatever) that they are essentially part of one program.
In the next entry the FAQ says: "If the program dynamically links
plug-ins, and they make function calls to each other and share data
structures, we believe they form a single program, which must be
treated as an extension of both the main program and the plug-ins. In
order to use the GPL-covered plug-ins, the main program must be
released under the GPL or a GPL-compatible free software license, and
that the terms of the GPL must be followed when the main program is
distributed for use with these plug-ins."
Applying this to the original question (the MySQL Connector/J plug-in)
leads to an interesting situation. That plug-in is a Java Database
Connector to access the MySQL database. JDBC (the Java Database
Connectivity standard) provides a standard API to let Java programs
connect to and access databases. It needs drivers (implemented as
plug-ins) to actually do this so it provides an external API (to the
Java programs) and an internal API (to the plug-ins) to hook all of
this up. A lot of drivers provide extra features (on top of the JDBC
standard), but it is possible to develop Java programs in a way that
they work with all standard JDBC plug-ins. In that latter case a user
can easily use another plug-in to talk to another database (Postgres,
I would venture that if a Java program is written in such a way that
it is completely independent of the actual JDBC plug-in used that then
means that it is possible to use a GPL'ed plug-in with the Java
program without requiring the Java program to be under the GPL too.
The reasoning behind this opinion is because in that case it is not
clear from the design that these two programs are meant to be working
together since the non-free program could work with any other plug-in
as well. The non-free Java program could be distributed without any
plug-in and with instructions for the user to download the GPL plug-in
separately and to combine the two (though a configuration file and a
JVM flag for instance). If the author of the non-free program chooses
to do the latter there is definitely no breach of the GPL I would say
(because the GPL hooks into the distribution of the software).
If on the other hand the non-free Java program is written in such a
way that it *requires* the Connector/J plug-in (e.g. because it uses
features from that plug-in which are not exposed through the standard
APIs) then there is a potential GPL violation. It would be interesting
to know whether the separate distribution "trick" referred to in the
previous paragraph could be used to circumvent the violation.
Memory and regret are, when taken together, the set of necessary and
sufficient elements required to produce a time machine.