[Qt-interest] Qt Mysql Plugin and LGPL

[Vincent L. Damewood]

On Fri, Jul 10, 2009 at 10:14 AM, Kendall
Bennett<KendallB at amainhobbies.com> wrote:
> This is still terribly confusing. If Sun went to the trouble to have this
> FOSS exception clause in there, and they INCLUDE the LGPL as a license that
> is compatible with the FOSS exception, it seems to me it would be a whole
> lot simpler if the MySQL client libraries were simply licensed under the
> LGPL also.

If they did that, then proprietary software could link against the
MySQL libraries without paying. Under this setup, the only ones who
get an exception are people who are releasing their code under some
other open-source license.

> So consider this. Given the FOSS exception, it allows the QSqlMysql module
> to be licensed under the LGPL, since it is compatible. So then a developer
> building a proprietary application is using Qt under the LGPL license. Does
> that mean the proprietary program is allowed to use the MySQL client
> libraries via the LGPL’ed QSqlMysql module using the Open Source MySQL
> client libraries? Or does the developer have to spring for a proprietary
> license for MySQL (and I won’t touch on how confusing getting one of those
> is, or used to be).

The FOSS exception allows only a specific set of open-source licenses
to be used in programs that use the MySQL libraries. The LGPL allows
any license to be used subject to a few requirements. This includes
proprietary licenses. The FOSS exception is still "Show Code or Pay".
The LGPL, however, isn't. If Sun licensed MySQL under the LGPL, there
would be less incentive to buy the for-pay version.

Under your scenario, a proprietary application would not be allowed to
link against the MySQL client library. The FSF explains how it works
in a similar scenario in one of the links I posted in my previous
message.

http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper

> I think it is clear that Qt licensed under a proprietary license is not
> compatible with the GPL licensed MySQL client libraries, so if you use a
> proprietary license for Qt, the only option would be a proprietary license
> for the MySQL client libraries. At least that is how I read it.

More or less, this is correct.

> Things get even more murky when you consider projects like PHP. PHP is
> completely open source, so it can use the MySQL client libraries under the
> GPL license I think (or the FOSS exception anyway). Then if you write PHP
> code that uses the MySQL client libaries via the PHP scripting language, is
> the PHP program itself infected by the GPL MySQL client libraries, because
> the PHP MySQL API’s are kind of like a library interface to the PHP scripts?

The PHP license is incompatible with the GPL. It is allowed under the
FOSS exception. I don't like the term 'infected' as used here, since
the word infected implies a lasting effect. Consider this scenario: I
develop an application with QsqlMysql. I later decide I want to make a
proprietary version, so I change to QsqPostgreql. This is entire
allowed (as long as I remain the sole copyright holder of the
project), since I'm only using a BSD-licensed library, and an
LGPL-licensed library. So, the GPL didn't infect my code at all.
However, as long as you use a library licensed under the GPL, your own
programs or scripts must be under a license compatible with the GPL
(or a license allowed under the FOSS exception in this case). PHP
doesn't create any sort of barrier. So in the PHP scenario, yes the
GPL would affect your licensing options. The FSF explains this in a
similar scenario:

http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

> In the case of PHP programs it gets even more complicated because most PHP
> scripts run on a web server. So who is the user of a PHP script anyway? Is
> the user the sys admin who installed the script on the web server, or is the
> user someone who connects via an HTTP socket to the web server via a
> browser? Where do you draw the line?

The user is the system administrator who installed it on the system,
or the company he works for who's running the site. Not the person who
makes a TCP connection to the server. For this reason, the GNU Affero
General Public License exists.

http://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
http://www.gnu.org/licenses/agpl.html

> For this reason I never use the MySQL client libraries in our non-Open
> Source code at all (except via PHP). Instead I use XML-RPC or some other
> transport layer to connect to the database, which insulates the client
> desktop programs from these licensing issues.

I wouldn't even advise you use it in proprietary PHP source code,
since, like I mentioned above, PHP doesn't create a barrier against
the GPL, and the GPL still affects your licensing options.

> Personally I think these FOSS exceptions just complicate everything, and
> stuff should either be GPL, and not allow for proprietary development, or
> LGPL, and allowed (assuming you meet the requirements of the LGPL).

The FOSS exceptions don't add any additional restrictions on the
licenses. It's perfectly fine to use just the basic GPL terms as if
there wasn't an exception. The GPLv3 even allows you to remove
exceptions. All the FOSS exceptions allow is for other open-source
licenses--licenses that are perfectly acceptable to the open-source
community, but perhaps GPL incompatible--to be used as the license for
programs that link with the libraries.

Vincent Damewood