GPL issue at my work place

[Philippe Verdy]

Rasmus Lerdorf [mailto:rasmus at lerdorf.com]
> Envoyé : jeudi 17 janvier 2008 22:16
> À : Dirk Dierickx
> Cc : license-discuss at opensource.org
> Objet : Re: GPL issue at my work place
> 
> Dirk Dierickx wrote:
> > On Thu, 2008-01-17 at 16:04 +0100, Arnoud Engelfriet wrote:
> >> However the MySQL client libraries are GPL, and if he links those
> >> to proprietary code and then gives the result to a contractor,
> >> arguably MySQL can force them to also give the source code of
> >> the proprietary code to the contractor, under the terms of the GPL.
> >
> > In case of a LAMP stack, where you're using MySQL, the actual MySQL libs
> > are linked with PHP rather then with your own written webapp. Is that
> > still considered to be 'linking' in view of your own code?
> 
> http://www.mysql.com/company/legal/licensing/foss-exception.html

And PHP itself is often linked as a module of Apache or a FastCGI slave
server that communicated with Apache through a network interface but is
launched as a separate process.

In terms of linking, the connection between PHP and MySQL is only in the
MySQL client library, which is not necessarily written by MySQL, given that
it just connects to the server via a network interface and the server may
run on another machine.

So one solution would be to use a non-GPL library compatible with the MySQL
client library, for example a LGPL implementation or Apache or MIT or a
proprietary client (I think that Oracle or Sybase provide a client library
allowing connection to a MySQL server; Oracle itself is not GPL'ed)...

Regarding Sybase, it also provides the tools to build a gateway in two
parts: one part is open-sourced and can be linked with MySQL under its
licencing terms, and it will implement a network interface compatible with
the Sybase networking protocol, so you can use a Sybase client in your PHP
installation.

This cuts the dependency on MySQL within PHP.

The development of the ASP in PHP will not directly depend on the choice of
SQL dialect, after all with the existing ASP development tools, there's
already a lot of abstraction on the SQL side, and you'll focus your
application on the data model... I know by experience that this works, we
could get complete independency from a large CRM my company developed and
sold to large medias, with the actual SQL engine used: initially developed
for Sybase, it was fully ported to Oracle, Informix, MS SQL server, and
finally MySQL too, without having to rewrite the applications, and using the
same data model.

All was ported, including stored procedures, using porting tools developed
by us, and by defining portability rules (this did not forbid specific
development for each client on its own chosen SQL platform, and for which
portability was not an issue). The applications were working without having
to recompile and relink them specifically for each platform, and could be
tested (most of the time) only once (testing was still performed on other
SQL platforms just to ensure that there was no performance bottleneck, but
experience on portability avoided the issues most of the time).