Plugins et GPL (suite…et débat sans fin ?)

J’avais il y a déjà quelques temps évoqué le problème dans un précédent article : si une application GPL permet l’écriture de modules, de plugins, ceux-ci sont ils concernés par la propagation de la licence GPL ? En d’autres termes, peut on écrire un plugin propriétaire pour une solution GPL ?

Yoan, l’auteur d’origine de Thelia, s’est également posé la même question, suite à diverses discussions que nous avions pu avoir sur le sujet.

La seule solution permettant de clarifier à 100% le débat serait, à l’instar d’autres logiciels comme MySQL, d’utiliser un principe de double licence :

  • La licence d’origine (il n’est pas possible de « perdre » l’étiquette GPL en cours de route, pour des raisons évidentes de protection sur la liberté du code)
  • Une autre licence, plus restrictive, qui serait celle à choisir pour pouvoir ensuite faire ce qu’on veut côté plugins.

Concrètement, cela ferait distribuer le logiciel sous deux formes différentes, mais où seul l’entête de chacun des fichiers changerait.

Note : il est parfaitement possible de faire en sorte qu’une application GPL soit convertie en double-licence à un instant T. Les seules conditions sont de garder la GPL comme une des licences disponibles, et de ne pas faire de rétro-compatibilité (les versions précédentes resteraient 100% GPL et ne seraient pas concernées).

Cette solution de double-licence est quand même perturbante : si je diffuse un plugin propriétaire pour Thelia par ex, je devrais spécifier que ce plugin n’est conçu que pour la version « propriétaire » de Thelia. Or, techniquement, absolument rien n’empêcherait de le faire tourner avec la version GPL, puisque seules quelques textes écrits en commentaires changent entre les deux versions ! La compatibilité n’est bien donc que juridique.

Restons maintenant pour l’hypothèse d’une licence unique GPL. Un plugin fait « partie intégrante » du code d’origine, ne serait ce que parce qu’il utile des mécanismes tels que la surcharge de méthodes étiquetées « GPL », ou du moins une cohabitation très intime des deux codes. Donc, en théorie, ya quasiment pas débat, on « hérite » de la licence GPL en même temps que l’on hérite des propriétés du code.

Dans la pratique, on se rend compte que cette notion « d’intimité » entre le noyau et le plugin est quand même très polémique. La licence GPL parle elle-même de « cas limites » dans sa FAQ : « Si le programme fait une édition de liens dynamique avec des plug-ins, mais que la communication entre eux est limitée à l’invocation de la fonction main du plug-in avec quelques options et l’attente du résultat de l’exécution du plug-in, nous nous trouvons dans un cas limite »

OK, soit, un plugin est GPL. Mais dans ce cas, quid par exemple des modules du noyau Linux ? Linux est GPL, les modules du noyau sont certes dynamiques mais quand même très intimement liés au noyau lui-même (un driver de carte graphique, par exemple, est indispensable à son bon fonctionnement). Et pourtant, il existe des modules propriétaires ! (les drivers Intel, par exemple).

J’ai pu trouver une réponse plausible dans une vieille discussion menée par Linus Torvalds himself :

The reason I accept binary-only modules at all is that, in many cases, you have, for example, a device driver that is not written for Linux at all, but, for example, works on SCO Unix or other operating systems, and the manufacturer suddenly wakes up and notices that Linux has a larger audience than the other groups. And as a result he wants to port that driver to Linux.

But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn’t feel that I had the moral right to require that it be put under the GPL, so the binary-only module interface allows those kinds of modules to exist and work with Linux.

En d’autres termes : OK ya la GPL. Mais ya aussi une « règle » que donne la personne ayant amorcé le projet, et qui tolère ces modules fermés sous certaines conditions qu’il définit lui-même (ici, le fait que le module intègre du code qui n’a pas été conçu spécifiquement pour Linux, mais qui a été adapté à partir d’autres drivers déjà développés).

On aurait donc une « position » à prendre par le mainteneur du projet, officielle, qui permettrait d’amener, non pas des amendements, mais plutôt des « tolérances » vis à vis de certaines pratiques (cette tolérance est d’ailleurs régulièrement sujette à polémique). Les maintainers du kernel Linux se basent sur une interprétation de cette notion de lien entre le kernel et son module :

In the opinion of Linux maintainers, LKM are derived works of the kernel. The Linux maintainers tolerate the distribution of proprietary modules, but allow symbols to be marked as only available to GPL modules. (source : Wikipedia EN)

Encore une piste donc, la notion de « derived works » qui permettrait de « contourner » ce lien noyau/plugin impliquant la transmission de la GPL. Mais là, on rentre dans du carrément tordu puisque cette notion est typiquement américaine…

Autre exemple, mais cette fois-ci plus restrictif : celui de WordPress. Là, pas de tolérance, le mainteneur du projet annonce un respect strict de la GPL. Avec toutes les discussions et nuances d’interprétation de la notion de « qu’est ce qu’un plugin » que ça amène.

Je rajouterai une info de @chessman2212 que l’on vient d’avoir sur Twitter au moment de la rédaction de cet article : le projet #joomla a justement viré des centaines d’extensions non GPL il y a peu de son referencement pour être conforme.

Compliqué tout ça… Bien entendu, je suis preneur de toutes vos contributions et expériences…