Plugins et CMS sous licence GPL
La question de la licence d'un plugin est assez récurrente au sein de la communauté Thelia. Cette même question se pose d'ailleurs pour les autres CMS.
Dans ce billet, je ne vais m'intéresser qu'aux CMS sous licence GPL dont Thelia fait partie.
Certains développeurs souhaiteraient simplement savoir si un plugin réalisé avec Thelia doit être GPL ou s'il peut passer sous licence propriétaire.
Cette question se pose en général lorsqu'ils souhaitent monétiser un module. En effet, un module sous licence GPL peut tout à fait être vendu mais rien empêche à l'acquéreur de le redistribuer lui-même gratuitement. Ceci explique pourquoi la vente d'un plugin GPL n'est pas forcément rentable sur le long terme.
Les développeurs de logiciels libres gagnent en général de l'argent sur du développement spécifique, de la formation, des services annexes.
Une licence propriétaire spécifique pour un plugin permettrait par exemple d'interdire la redistribution gratuite, la duplication sur plusieurs sites, etc.
Je ne traite pas ici de l'aspect éthique ni mon point de vue personnel. Il se trouve que cette demande existe.
Un plugin destiné à une solution GPL peut-il avoir une licence propriétaire ? La réponse se trouve ici.
A partir du moment où un plugin utilise du code contenu dans le CMS (inclusion, héritage, etc) ou partage des structures de données alors le module devra être sous licence GPL ou compatible.
Un plugin qui ne serait que l'appel d'un programme retournant une donnée ne serait pas soumis à une licence particulière. C'est rarement le cas surtout dans le cadre d'un CMS.
Les plugins Thelia doivent donc être sous licence GPL ou compatible. Ceci n'oblige pas de publier son travail bien entendu mais tout travail publié devra être sous licence GPL ou compatible. Il sera donc possible de réutiliser le code tant que la licence est respectée.
Les autre CMS sous licence GPL contenant la notion de plugin seront soumis aux mêmes obligations.
MAJ 07/02/13
Bien souvent, un plugin pour un CMS interagit fortement avec le moteur du CMS (appel de fonctions ou méthodes, héritage, structures de données). On est loin d'un simple script que l'on appellerait avec quelques arguments pour récupérer une donnée en retour.
Sans le moteur de base, le plugin n'est pas fonctionnel.
Commentaires
Salut Yoan,
Voici mon avis :)
La licence GPL s'applique sur ce qui est distribué.
Les plugins thelia sont distribués sous la forme d'un fichier zip contenant un ensemble de fichiers : fichiers php, images, css,..
Lorsque ces fichiers ne contiennent pas de code GPL, ce qui est le cas généralement des plugins thelia, leur distribution n'est pas regie par la licence GPL.
Il est alors possible de leur appliquer une autre licence, et sans mention particulière c'est le droit d'auteur qui s'applique.
Arnault
Ps : ceci n'est pas valable lorsque les programmes distribués sont compilés car le code peut contenir des librairies sous GPL. Ce n'est pas le cas des plugins thelia (langage interprété)
Oui sauf que les plugins contiennent des includes du code de THELIA donc ce code l'emporte.
C'est clairement écrit http://www.gnu.org/licenses/gpl-faq...
Rhalala, dure question sujette à polémique
Il me semble qu'un des meilleurs exemples à prendre en parallèle est celui des modules additionnels au noyau Linux. Certains de ces modules sont closed-source, par exemple les drivers NVidia.
Si l'on regarde la longue littérature à ce sujet, on peut en déduire :
- que l'existence de ces modules est une --tolérance-- dictée par Linus, et une entorse à la GPL strictement appliquée
- que le package ainsi fermé ne doit contenir aucun code libre (là, il y a une abondante jurisprudence sur le sujet)
- sur l'inclusion de code, c'est super tendancieux. Si on surcharge une classe GPL par exemple, la classe fille doit être GPL. Dans le cas des modules Linux closed-source, la tolérance provient du fait que le module compilé repose uniquement sur un .h, et pas un .c
- la jurisprudence Wordpress (à l'initiative de Wordpress) interdit tout module non ouvert
En résumé... c'est le bazar, et les cas que l'on trouve montrant la possibilité de fermer du code sont plus des tolérances que des applications automatiques de la GPL
Le cas du langage interprété n'est pas clairement défini dans la GPL et je crois que ce sera toujours sujet à interprétation justement ;)
En revanche, on a un exemple qui a déjà été tranché pour WordPress (http://www.lumieredelune.com/encrel...).
Le fameux "Linking" va plus loin que ça apparemment. Le fait d'utiliser l'ensemble dans le "même environnement PHP" suffit.
Il semble appuyer la version du plugin GPL.
En fait, si j'ai bien compris ton raisonnement Arnault, tu le vois comme ça :
Un plugin Thelia est un zip qui ne contient aucun code de Thelia.
Quand on le pose au sein du répertoire plugins d'un Thelia alors la liaison se fait grâce à l'include de la classe liée aux plugins.
C'est ici que se fait le "linking". Ce n'est pas un "liking" tel qu'on le verrait au sein d'une compilation système classique.
Pour toi, la licence GPL ne s'applique donc pas forcément.
Pour moi, ce linking a la même valeur et c'est sur ce point que nos avis divergent. La jurisprudence semble montrer que ce linking tend à avoir la même valeur que le linking plus traditionnel (cas WordPress).
De plus, ça me semble logique pour refléter les valeurs de la licence GPL. Un plugin Thelia sans Thelia ne fonctionne pas.
Je n'avais pas donné mon avis personnel mais je vais le donner ;) ça ne me dérangerait même pas que des gens proposent des plugins propriétaires pour Thelia (oui je sais, j'ai évolué sur ce sujet). Mais je pense qu'actuellement ils ne peuvent pas.
La question que je me pose là est purement légale.
L'histoire de la licence refroidi un peu, c'est vrai :(
j'avais regardé pour proposer un thème sous Thélia mais sans protection, j'avais renoncé :(
C'est peut être ce qu'il manque à Thélia, une place de marché où les dévs indépendants proposeraient leurs modules ou thèmes payants (et Gratuits).
Ce genre de plateforme attire les développeurs ( en bien ou en mal) mais cela augmente l'offre et la visibilité d'une solution.
C'est mon point de vue.
Moralement et légalement je n'ai rien à redire sur le choix de la licence GPL pour les plugins.
On est plutôt dans une zone grise de la GPL où les notions d'"invoquer" (autorisé) et de "faire appel à des fonctions" (interdit) sont subjectives.
Par exemple JQuery (license MIT compatible GPL) on peut faire un projet fermé et utiliser JQuery. Pourtant si je fais ça http://oziks.fr/2012/09/surcharge-d... l'interaction est forte avec la librairie.
C'est plutôt le côté commercial et pérennité des contributions qui m'embête :
Comme il est dit dans l'article, ça ne sert pas à grand chose de faire un plugin générique payant. L'idée étant plutôt de gagner sa vie sur le support et le dèv spécifique.
Du coup commercialement il vaut mieux faire un plugin accrocheur mais difficile à utiliser/paramétrer plutôt que de faire un truc fonctionnel avec une documentation complète. Ou bien 'oublier' une fonctionnalité que l'on vendra au cas par cas. Ou alors faire de petits plugins qui ne valent pas grand chose mais qui attirent le client pour lui proposer plus derrière.En tout cas je ne passerai pas 400h à faire un dev super complet si je ne suis pas sûr de m'y retrouver derrière.
Je me fais l'avocat du diable bien sûr mais il existe, faut en être conscient.
De même, on le voit sur Wordpress, il y a beaucoup d'extensions (c'est bien) mais la plupart sont faites par des particuliers sans support durable ou sans support du tout (après tout c'est gratuit tu va pas te plaindre si ça fonctionne pas). De plus la qualité du code est souvent 'discutable'. Les bons modules sont en général à compléter avec des options payantes (voir plus haut).
Sur un CMS comme Wordpress qui n'a pas pour vocation de faire gagner de l'argent c'est acceptable. Je passe 3 soirs à trouver un thème qui bug pas avec mon extension commentée en turc tout en regardant Game of Thrones ok. Mais un commerçant qui est là pour bosser ne peux pas l'accepter.
ça n'engage que moi mais ce choix risque de ne pas inciter les développeurs pro à contribuer à Thelia, ce qui est dommage car ils peuvent faire avancer la solution comme ça a été le cas pour Prestashop.
Je crois que JD a bien présenté la situation qui est peu clair et je crois que les exemples opposés Linux et Wordpress montrent bien que c'est finalement le propriétaire du code initial qui doit décider de l’interprétation de la licence. Dans l'esprit libre la GPL est faite pour être virale, c'est bien en cela qu'elle a été crée par opposition, autant aux licences propriétaires qu'aux BSD.
Je suis assez d'accord que le possibilité de faire du code payant et d'avoir une place de marché est bien une solution pour pérenniser son produit et les efforts faits par la contributeurs au moins sur le court terme. Sur le long terme c'est plus compliqué car un pluggins payant, fait par un particulier à un moment donné sera sans doute abandonné et les futures bonnes volontés ne pourrons le maintenir.
Je crois (peut etre par utopisme) que le mode de rémunération de type don paypal est une façon de vendre sans vendre et sans pour autant proposer du service et que cela peut aussi fonctionner pour la peine que l'on n'attende pas de grosses rémunérations.
Pour ce qui est des templates, je crois qu'il est possible d'en faire sans violer la GPL : proposer un template de code qui lui sera GLP car il intègre des balise et donc le code thélia, mais separer les images et le css qui peuvent ne pas être lié et contenir la majorité de la valeur ajouté du développeur de ce template.
De mon point de vue, vous allez trop loin dans l'interprétation de la licence.
Je suis désolé d'insister, mais il s'agit d'une licence couvrant des programmes informatiques sous licence GPL, copiés, distribués, ou modifiés. Si un programme ne contient pas de code GPL, elle ne s'applique pas.
Article 0 de la licence GPL v2 "Activities other than copying, distribution and modification are not covered by this License; "
Comme je l'indiquais, dans le cas d'un langage interprété, et compte tenu de la façon dont sont construits les plugins, il n'est pas requis d'y inclure du code de Thelia sous GPL. Hors sans code GPL dans un plugin pourquoi voulez-vous que la GPL s'applique ?
Comment expliques-tu le cas WordPress qui a été tranché ?
Sur la notion de lien dynamique et sur le fait que le plugin a besoin du programme principal pour fonctionner.
Arnault tu as utilisé le bon mot dans ton dernier commentaire : "interprétation".
Les deux cas "kernel Linux" et "Wordpress" montrent que l'on peut tirer des conclusions opposées d'un même texte
Et la FAQ pointée par Yoan commence par la phrase "Nous PENSONS que..."
Bref, tout est interprétable.
Et qu'on en soit obligé de faire appel à Stallman pour arbitrer est une aberration. Si je ne suis pas d'accord avec l'interprétation du droit américain, je demande à George Washington ? :-)
La leçon à tirer des deux cas Linux et Wordpress, c'est qu'il est impératif qu'à un moment donné, l'éditeur prenne publiquement position pour autoriser ou pas les plugins non libres :
- soit par un texte clair fourni en complément de la licence et intégré dans la version diffusée
- soit par un système de double-licence (bien plus complexe à mettre en place, et pas forcément en cohérente avec la déontologie du projet...)
Tout à fait. Ni la FAQ ni la licence n'a l'air de trancher clairement. J'ai précisé ma question à RMS. Si j'ai une réponse, je vous dirai ce qu'il en est.
Ceci dit même avec sa réponse (qu'elle penche d'un côté ou de l'autre), je crois que le doute et l'interprétation risque de rester.
"Comment expliques-tu le cas WordPress qui a été tranché ?"
En fait il n'a pas été tranché car il semble qu'il n'y ait pas eu de procès (http://www.wordpress-fr.net/2010/07... source à vérifier).
Toutefois, si un thème WordPress est une modification du template par defaut de Wordpress (ou tout autre template GPL) il doit être sous GPL (pour ce qui concerne les fichiers modifiés).
"Sur la notion de lien dynamique et sur le fait que le plugin a besoin du programme principal pour fonctionner."
C'est notre point principal de désaccord, comme soulevé également par JD "l'inclusion de code". Et je n'ai pas trouvé de jurisprudence. Toutefois rien n'oblige non plus un programme à être fonctionnel.
J'ai échangé quelques mails avec Richard Stallman entre hier et aujourd'hui.
Dans mon premier message, je lui expose mon questionnement sur la licence d'un plugin pour un CMS réalisé en PHP (j'ai Thelia en tête bien entendu).
Je lui explique qu'un plugin consiste en une classe qui hérite d'une classe du CMS GPL via un include().
Je lui demande si ce plugin doit être sous GPL (ce que je pense).
Il m'a confirmé ce que je pensais.
Puis, je me suis dit que je devais préciser ma question.
Je lui ai donc répondu que le terme "link" de la GPL pouvait porter à confusion par rapport à un langage interprété.
Je lui ai donc expliqué que ce plugin était stocké dans une archive à part et que celle-ci ne contenait pas de code GPL. Pour le rendre fonctionnel, il faut décompresser l'archive dans un répertoire spécifique du CMS. Ensuite, l'inclusion devient fonctionnel et le plugin avec.
Je souhaitais savoir si ça suffisait pour que la GPL l'emporte.
Il m'a répondu que le copyright couvrait le travail "combiné". S'il n'y a pas de lien statique alors ils utilisent un autre critère. Quand un programme A et B sont conçus pour échanger entre eux des données partagées alors c'est considéré comme un travail combiné.
Il utilise le terme "certainly a combined work". Certainly se traduit "assurément" mais on pourrait le voir comme "certainement". La force des deux termes sont donc différents en français. J'imagine que certains pourraient encore y voir une interprétation.
Bref pour RMS s'il y a travail combiné alors le plugin doit être sous GPL.
Il a ajouté qu'il y a un manque dans la FAQ de la GPL et que ceci devrait être ajouté.
Pour conclure, je dirai que JD a probablement raison. L'éditeur doit clairement exprimer son choix en ce qui concerne ces cas "borderline".
Du coup, ce serait intéressant d'avoir un positionnement d'Openstudio. Faut-il accepter ou non les plugins non GPL pour Thelia ?
Merci Yoan, et à RMS d'avoir répondu.
J'ai trouvé cette discussion juridique sur "les plugins sont-ils des programmes dérivés du programme principal".
C'est une position plus mesurée que le "passage en force" de la FSF sur cette question : http://www.law.washington.edu/lta/s...
Côté OpenStudio, nous allons préparer un communiqué sur le blog de thelia, pour indiquer notre position. Elle ira certainement dans le sens de garantir la liberté pour les développeurs de faire des plugins non libres. Mais ceux-ci devront être distribués sur des sites tiers et pas sur les sites de la communauté.
Parfait. Effectivement la position est plus mesurée.
Bonjour à tous,
Concernant la règle de Thelia, un article va être fait et une FAQ verra le jour.
Notre première réflexion est de vouloir que le plus de monde possible utilise Thelia.
Notre souhait serait que les modules développés par la communauté respectent la licence initiale de Thelia, c'est à dire la licence GPL ou une licence compatible GPL.
Cependant si une personne ne souhaite pas le faire, il n'a jamais été question, et ce depuis la création de Thelia, d'organiser une chasse aux sorcières pour poursuivre les personnes qui n'utilisent pas la licence GPL.
Quand on nous demande sous quelle licence doit être un plugin fraîchement réalisé, nous répondons naturellement qu'il doit être sous licence GPL. Cependant, comme expliqué au-dessus, nous n'obligeons personne à le faire.
Pour clarifier la situation, il a été décidé que les plugins proposés sur l'espace de contribution de Thelia (http://thelia.net/Plugins.html) devront être accompagnés d'une licence GPL. Si le plugin n'est pas sous licence GPL il devra être hébergé par la personne qui l'a développé.
Nous ne faisons que clarifier un point qui existe déjà, car oui il existe des plugins qui ne sont pas diffusés via le site thelia.net, oui il existe des plugins pour Thelia qui ne sont pas sous licence GPL.
Amis développeurs , développez des plugins et prenez du plaisir à le faire, c'est le plus important :)