Chouette, se disent mes lecteurs, encore un billet geek !

Aujourd'hui, je vais partager avec vous des problèmes de licences. Je me pose certaines questions concernant la contamination[1] de la GPL.

Tout ça a commencé avec l'utilisation d'un connecteur MySQL. Le connecteur MySQL, c'est ce bout de code qui permet à une application d'accéder à une base de données MySQL. Ce connecteur est sous licence GPL, avec une exception pour d'autres licences Open Source, le but étant qu'un logiciel Open Source peut utiliser le connecteur même si sa licence n'est pas compatible avec la GPL.

Évidemment, en entreprise, on ne veut pas forcément ouvrir son code en Open Source. Dans le cas de MySQL, généralement ça ne pose pas de problème, car ça reste côté serveur et il n'y a pas redistribution. Mais dès lors qu'il y a redistribution (vers des filiales par exemple), le problème se pose.

Le connecteur C

On va parler d'abord du connecteur C, car c'est le plus simple à aborder du point de vue des licences : si on l'utilise, on doit se lier avec, et donc la GPL doit s'appliquer. Dès lors, si on veut distribuer un logiciel en C (ou C++) qui a besoin d'une base de données, il y a peu de choix :

  • soit on achète une licence à MySQL[2],
  • soit on change de base de données, par exemple PostgreSQL[3], qui est sous une licence similaire à BSD.

Le connecteur Java

On va corser un peu et parler du connecteur Java.

En Java, on utilise une interface bien pratique qui s'appelle JDBC. Cette interface est implémentée par tous les connecteurs de base de données, ce qui permet très facilement de passer d'une base à une autre. Évidemment, il va exister des différences dans les implémentations, ne serait-ce que dans le SQL à utiliser, mais l'API est identique. JDBC permet un découplage entre la bibliothèque GPL et l'application qui l'utilise.

Il y a deux manières d'utiliser un connecteur JDBC : soit directement, soit, dans le cas d'une application JEE, par le conteneur JEE.

Utilisation directe

Dans ce cas, même s'il y a découplage par JDBC, je pense qu'on rentre dans le champ de la GPL. En effet, on va spécifiquement ajouter le connecteur dans le classpath de l'application, et généralement on va même l'embarquer avec les autres bibliothèques utilisées. Et on va même nommer directement le Driver spécifique à ce connecteur. Pour le connecteur MySQL, ça se fait ainsi :

Class.forName("com.mysql.jdbc.Driver");

On peut évidemment exporter cette chaîne de caractères dans un fichier de configuration, pour découpler un peu plus, mais j'ai l'impression que c'est noyer le poisson.

Utilisation dans le cadre du serveur d'application

Dans un serveur d'application, c'est le serveur qui va fournir la connexion à la base de données. En principe, l'application ne sait pas particulièrement où elle est connectée, et à qui. Ainsi, à mon sens, l'application peut utiliser le connecteur GPL dans ce cas... puisqu'elle ne sait même pas qu'elle l'utilise[4].

On est pourtant dans ce que j'appelle une zone grise, car c'est pas très clair tout ça. Dans une telle application, on va tout de même avoir des requêtes SQL spécifiques à MySQL. Ou bien on va configurer Hibernate en lui disant qu'on utilise un connecteur MySQL. Des trucs comme ça qui sont autant d'indices qu'on est bien adhérent à MySQL, que l'application ne fonctionnera pas sans connecteur, que donc la licence GPL s'applique, et qu'on a donc pas le droit d'utiliser la bibliothèque.

Et dans PHP ?

PHP, c'est commode, vient avec son client MySQL. Ce client MySQL est bien sûr implémenté en utilisant le connecteur C vu plus haut[5].

Dès lors, une application PHP qui n'est pas GPL ou dans une licence Open Source concernée par l'exception a-t-elle le droit d'utiliser directement le client MySQL de PHP ? Et si elle passe par une bibliothèque d'abstraction comme PDO ?

Conclusion

J'en n'ai pas vraiment. Je dirais juste que la GPL, c'est assez facile à appliquer dans le monde des programmes compilés (et encore, avec les chargements dynamiques de bibliothèques, ça peut devenir aussi compliqué). Mais dans le monde des langages interprétés (ou entre les deux, comme Java), c'est plus difficile.

Et vous, vous avez un avis ?

Notes

[1] Ou l'incompatibilité, pour éviter le terme de "contamination".

[2] C'est bien, car on participe ainsi à son développement.

[3] C'est bien aussi, car c'est à mon avis la meilleure base de données Open SOurce.

[4] Dans ce cas, quelqu'un est-il hors-la-loi ? Celui qui déploie l'application ?

[5] Je viens de lire que PHP a fait leur propre client MySQL. Dans ce cas, ça ne s'applique sans doute pas.