Journal : VMware et la GPL
Posté par OAUDRY () le 16 avril 2008
Hello,
depuis 1 mois je découvre vmware esx, je ne donnerais pas mon avis sur ce produit, sachant que au bout d'un mois il est difficile d'en avoir un objectif. Surtout quand on utilise Xen depuis 2ans.
Mon interrogation vient plutôt de la relation entre l'esx et linux. Je n'ai malheureusement trouvé pour le moment qu'un seul article qui en parle.
http://www.venturecake.com/the-vmware-house-of-cards/
Et d'apres cet article vmware violerait la GPL
depuis 1 mois je découvre vmware esx, je ne donnerais pas mon avis sur ce produit, sachant que au bout d'un mois il est difficile d'en avoir un objectif. Surtout quand on utilise Xen depuis 2ans.
Mon interrogation vient plutôt de la relation entre l'esx et linux. Je n'ai malheureusement trouvé pour le moment qu'un seul article qui en parle.
http://www.venturecake.com/the-vmware-house-of-cards/
Et d'apres cet article vmware violerait la GPL
> Lire le journal (50 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #923364.
Run by 
Cette page a été générée par Templeet en 0.0708s (dont 0.0066 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Explication dans les commentaires
Cet article date un peu, je ne l'ai pas relu en entier, mais de ce que je me souviens : VMWare utilise Linux pour booter, et après charge un module proprio qui est chargé de la virtualisation. Le truc, c'est qu'à priori, ce module est du code qui existait déjà avant de manière "séparée" du kernel, et qu'il a été "adapté" en tant que module. A priori, Linus ne considère pas ça comme une violation de la GPL (j'avais vu ça dans les commentaires de l'article). Et c'est souvent la défense qu'ont des constructeurs qui "adaptent" des drivers utilisés dans d'autres OS à Linux (genre Broadcom qui porte ses drivers depuis VxWorks).
En gros, c'est "si ce code fonctionne aussi avec autre chose que Linux, ce n'est pas une violation". J'avoue que ça fait quand même une brèche énorme dans la GPL, mais c'est pas complètement idiot non plus, dans le sens où si je crée un logiciel proprio qui a la même interface (API) qu'un logiciel libre, mais que je crée aussi la lib proprio qui va avec, et que je reste dans mon coin sans utiliser de libre du tout, peut-on m'attaquer parce que mon logiciel "pourrait" fonctionner avec la lib GPL (puisqu'ils ont la même interface) mais que je ne fourni pas le code sous GPL ?
Et on en arrive donc aussi au problème de licence d'un format ou d'une API : peut-on mettre une licence sur un format/protocole/API ? A première vue, ça parait débile, et c'est ce que fait MS avec OOXML, .Net et compagnie avec son "Open Specification Promise", même si là il se protège par ses brevets plutôt que par une licence . Mais quand on y pense, c'est un peu ce qui arrive avec cette histoire de VMWare : si on adapte son logiciel à une "interface sous GPL" (i.e. on s'interface en tant que module noyau), cela nous oblige-t-il à quelque chose, c'est à dire, est-on soumis à une licence ?
J'avoue que je n'apporte que peu de réponses et beaucoup de question, mais c'est important d'y réfléchir alors qu'aujourd'hui les problèmes de licence et d'interopérabilité, en particulier avec la GPL, sont de plus en plus discutés.
[^]Re: Explication dans les commentaires
Ce n'est pas une faille de la GPLv2, c'est l'interprétation de celle-ci par les constructeurs parce qu'elle leur convient.
La GPL dit clairement que tout logiciel lié à du code GPL (statiquement ou dynamiquement contrairement à la légende urbaine) doit être mis sous GPL, point barre. Le fait que le module ne soit pas un travail "directement" dérivé du noyau Linux ne constitue pas une excuse valable.
La GPL par contre ne t'interdit pas de concevoir ou d'utiliser un module propriétaire pour le noyau Linux mais t'interdit de redistribuer l'ensemble.
Les distributions fournissant dans un même ensemble un noyau Linux "teinté" sont dans l'illégalité -quoique contournable par une EULA mais dès lors la distribution n'est plus libre-, quant à ceux qui fournissent des modules précompilés, c'est borderline.
[^]Re: Explication dans les commentaires
>La GPL dit clairement que tout logiciel lié à du code GPL (statiquement
> ou dynamiquement contrairement à la légende urbaine) doit être mis
>sous GPL, point barre.
Tu peux citer le passage concerné ?
[^]Re: Explication dans les commentaires
Extrait du texte de la GPLv2
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
La même en Français:
La Licence Publique Générale ne vous permet pas d'incorporer votre programme dans des programmes propriétaires. Si votre programme est une bibliothèque logicielle, vous pourriez considérer comme plus utile de permettre de lier des applications propriétaires avec la bibliothèque. Si c'est ce que vous voulez, utiliser la Licence Publique Générale Moindre (LGPL) en lieu et place de cette licence.
C'est plus clair maintenant ?
[^]Re: Explication dans les commentaires
>C'est plus clair maintenant ?
Le texte que tu cites est après "END OF TERMS AND CONDITIONS". Il se situe d'ailleurs après un sous-titre nommé "How to Apply These Terms to Your New Programs". Ca semble être une interprétation des gens de la FSF sur la licence GPL, mais le texte contractuel parle plutôt de "derivative work". Et cette notion fait plus appel au bon sens que la terme technique "lien".
Petit exemple : tu fais un programme qui utilise JDBC pour accéder à une base de données oracle. Si tu fais un programme simple et que tu codes pas comme un cochon, l'utilisateur à qui tu livres ton programme peut le faire fonctionner avec les drivers JDBC MySQL alors que tu n'as jamais vu de prêt ou de loin le code de MySQL. Avec ton interprétation, je dois livrer mes sources vu que je lie dynamiquement avec MySQL ( un debugger montrerai que je me trimballe une MySQLConnection ). Avec la notion de "derivative work", on peut affirmer sans mal que ton soft n'est pas un derivative work de MySQL.
Deuxième exemple dans l'autre sens : il y'a un gros soft GPL en ligne de commande qui fait tout un tas de traitement. Toi tu fais un soft qui appelle cet exe et qui récupère la sortie pour l'afficher joliment pour l'utilisateur. Ton soft ne lie pas avec l'exe GPL ni statiquement ni dynamiquement et pourtant il ne fait rien sans cet exe. Avec la notion de "derivative work" tu peux tenter de demander des comptes au créateur du front-end. Avec l'approche "lien", tu peux pas.
http://www.gnu.org/licenses/gpl-2.0.html
[^]Re: Explication dans les commentaires
> Ca semble être une interprétation des gens de la FSF sur la licence GPL
En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL. Sinon, le bout de texte en question fait partie de la licence, c'est la notice d'utilisation, même l'OSI l'a reprise ...
http://www.opensource.org/licenses/gpl-2.0.php
Tes exemples sont faux.
1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci. Par contre, tu n'as pas le droit de distribuer ton pilote JDBC sous GPL avec ton programme mais l'utilisateur final peut les associer si il le souhaite.
Pour montrer que ton exemple est daubé, prenons le cas du pilote JDBC MySQL® Connector/J sous licence GPL. MySQL Labs précise que si tu ne veux pas être soumis à la GPL, tu dois leur acheter une licence.
Commercial licenses for either version can also be purchased from MySQL AB, for those who don't wish to be bound by the GPL.
http://www.mysql.com/products/connector/j/
2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme (http://fr.wikipedia.org/wiki/%C3%89dition_de_liens). Là, aucun lien n'est réalisé, tu récupéres la sortie d'un autre programme et tu l'introduit dans l'entrée d'un autre programme, c'est le principes des pipes.
Si je fais cat mon_fichier.txt | mon_programme_proprio_ala_con, si j'utilise GNU cat, mon_programme_proprio_ala_con n'a pas à passer sous GPL !
Pour te prouver que les notions de "travaux dérivés" et de "lien" ne sont pas opposé, un extrait de la FAQ GPL.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
---------
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.
http://www.fsf.org/licensing/licenses/gpl-faq.html
En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée" et doit être licencié sous une licence compatible GPL.
[^]Re: Explication dans les commentaires
>En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL.
Il n'y a pas de lien entre être l'auteur d'un contrat et connaitre avec certitude l'interprétation qu'en fera un juge si on lui demandait de trancher ; Par exemple, il y'a beaucoup d'exemples de contrats comportant des clauses qui sont considérées comme abusives lorsque l'on demande à un juge de trancher : avec ton raisonnement, je devrais prendre pour argent comptant ce que me dit mon opérateur de téléphonie sous pretexte que c'est lui qui à écrit le contrat !
>1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci.
De la même manière je peux faire un soft qui ne fonctionne qu'avec MySQL ( clauses SQL spécifiques ) en ne me liant qu'avec JDBC. Dans un cas, je suis un travail dérivé de MySQL : je n'existe pas sans MySQL et dans l'autre je ne suis pas un travail dérivé.
>2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme. [...] c'est le principes des pipes.
Là encore tu as une approche technique du problème alors que j'ai une approche juridique. Si ton programme n'existe pas sans le composant GPL, alors tu es un travail dérivé.
J'aime assez l'analogie de Linus à propos des livres et des chapitres sur ce sujet ( voir les liens d'IsNotGoog un peu plus bas ).
>En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée"
Encore approche technique. Avec ces critères, tu prouves que l'appel JDBC MySQL est un travail dérivé alors que tu prétends le contraire quelques lignes avant : le code du driver mysql sous gpl est executé dans le meme processus et il alimente des structures que je lis.
[^]Re: Explication dans les commentaires
ce troll a déja eu place il y a peu de temps (sur une news en première page).
Ce qu'on en a conclu c'est "C'est pas clair" XD
des interprétations et arguments peuvent expliquer le pourquoi considérer lié en dynamique peut etre considérer comme un "derivative" ... ou pourquoi lié en dynamique ne peut pas être considéré comme un "derivative".
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Explication dans les commentaires
Le contrat est censé transposer l'aspect technique dans un cadre juridique. Distinguer l'aspect juridique de l'aspect technique est un non-sens.
Ton juge pour déterminer si ton logiciel est un travail dérivé, s'appuiera sur le texte de la licence (qui est suffisamment explicite à ce sujet), l'avis des experts techniques et probablement de la position des auteurs de la GPL.
La GPL n'a pas été écrite à l'arrache sur un bout de nappe par RMS, des juristes (notamment Eben Moglen) ont participé au processus et ils ont tenu compte de l'aspect technique.
Une clause abusive, c'est une clause entrainant un déséquilibre significatif entre les droits et obligations des parties au contrat imposé par la partie la plus forte économiquement parlant.
Difficile dès lors de parler de clause abusive dans le cadre de la GPL ...
1. Ton exemple est encore faux.
Tu a le droit décrire un logiciel propriétaire spécifique à MySQL en utilisant JDBC, mais tu n'as le droit de distribuer les deux ensemble (que ce soit d'une façon ou d'une autre).
Si tu veux le faire, comme je l'ai dit précédemment, tu dois acheter une licence auprès de MySQL Labs.
C'est exactement la même chose qu'avec les pilotes binaires.
2. Tu as une définition abusive du terme "travail dérivé", si on prends ta définition, tu n'as pas le droit par exemple de fournir un IDE proprio avec GCC, ce qui est évidemment faux.
Même si en pratique, ta "coquille vide" ne tourne pas sans le composant GPL, tant qu'ils ne sont pas "intimes", c'est OK vis à vis de la GPl (Cf la faq GPL posté précédemment)
3. Elle est ou la contradiction ? Je t'ai dis que si tu veux redistribuer ton logiciel proprio + pilote JDBC ensemble, soit tu achètes une licence soit tu changes la licence de ton logiciel ?
Par contre, la GPL ne t'interdit pas de les associer dans le cadre d'une utilisation privée mais dès lors tu n'as plus le droit de le diffuser.
La GPL explique explicitement ce qu'est ou ce que n'est pas un "travail dérivé". Introduire la sortie d'un programme dans l'entrée d'un autre ne suffit pas à en faire un "travail dérivé".
Avec ta définition déformée de ce qu'est un travail dérivé, ce serait un bordel. Pour reprendre ton exemple avec JDBC, supposons que j'écrive un programme proprio utilisant JDBC que je vends avec MS SQL Server mais qui marche très bien également avec MySQL mais sans que je le distribue avec, donc mon programme devrait être sous GPL puisque c'est un travail dérivé.
Tu vois le problème ?
[^]Re: Explication dans les commentaires
> La GPL dit clairement que tout logiciel lié à du code GPL doit être mis sous GPL
Non, la GPL dit que si tu distribues l'ensemble, l'ensemble doit être distribué sous licence GPL (ce qui n'impose /rien/ sur les licences des parties de l'ensemble. La preuve, certain drivers Linux sont sous licence BSD)
[^]Re: Explication dans les commentaires
> La preuve, certain drivers Linux sont sous licence BSD
Au dernières nouvelles, la BSD (sans clause de publicité) est compatible GPL.
Prend une licence incompatible avec la GPL et hop, ça ne fonctionne plus. Au mieux, t'as prouvé que le code lié doit être sous GPL ou une licence compatible, au pire, c'est un mauvais exemple.
[^]Re: Explication dans les commentaires
Tu as débranché tes neurones dédiées à la compréhension écrite pour les brancher sur le mode troll dès que tu as lu le mot "BSD", ou tu as juste considéré que lire mon message avant d'y répondre était une perte de temps ?
> Au dernières nouvelles, la BSD est compatible GPL.
J'ai dit le contraire ?
On reprend: dans le noyau Linux, il y a des bouts sous GPL et des bouts sous BSD. La GPL précise qu'il faut alors distribuer le tout (linux-2.6.24.tar.bz2, ton .rpm, le binaire vmlinuz,...) sous GPL. Mais elle ne précise rien sur la licence des parties. Simplement, les licences des parties doivent être compatibles (cad grosso modo doivent être un sous ensemble) avec la licence GPL pour que cela soit possible, ce qui est la cas de la BSD, mais les parties n'ont pas à être sous licence GPL, elles peuvent garder leur licence originale.
D'où ma correction: un logiciel lié à un logiciel sous licence GPL n'a pas à être sous licence GPL, mais doit être sous une licence compatible GPL (les licences BSD sans clause de publicité le sont) afin que l'ensemble puise être redistribué sous les termes de la licence GPL.
Ça suffit, ou je dois être encore plus explicite pour te montrer qu'à priori, on est d'accord ?
[^]Re: Explication dans les commentaires
je vais mettre un énorme bémol à tout ceci :
les couillons de la FSF ont montré qu'ils sont capables de modifier la GPL (c'est à dire changer la règle du jeu) au fur et à mesure qu'ils en éprouvent le besoin mystique.
pour le noyau, c'est (assez heureusement) bloqué en "v2 only". pour tous les projets en GPL "v2 or any later version", rien n'empêchera de se prendre plus tard une clause "se peindre le visage en bleu".
Windows has no users. It has hostages.
[^]Re: Explication dans les commentaires
[je passe sur tes propos acerbes et non démontrés]
v2 or any later permet de pouvoir migrer un projet facilement, et donc de faire cohabiter sans problème du code gplv{3,4..} avec du code conçu lors de la gplv2.
Si tu n'utilise que le code "gplv2 or any later version", tu peux n'être soumis qu'aux obligations de la gplv2 (et pas de la gplv3).
Si tu utilise un projet avec du gplv2 or any later version _et_ gplv3, tu sera soumis à la gplv3.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Explication dans les commentaires
Heu, je voudrais pas dire, mais tu as quand même omis de préciser que les "parties" devaient être compatibles GPL dans ton premier commentaire, d'ailleurs tu as même précisé :
ce qui n'impose /rien/ sur les licences des parties de l'ensemble
Alors que justement, la GPL impose que les "parties" soient compatibles GPL. Je te trouve un peu dur avec GeneralZod sur ce commentaire ...
[^]Re: Explication dans les commentaires
Supaire !
Si je compile un logiciel libre pour un système propriétaire ça veut dire qu'il devient libre ?
Je file compiler et lier la libcaca sous Windows pour libérer l'OS de Microsoft alors !
Heureusement, la GPL permet de le lier du logiciel propriétaire à du code GPL. Enfin seulement si le dit logiciel est une librairie système :
Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
[^]Re: Explication dans les commentaires
D'ailleurs la licence de Linux précise que la "vaccination GPL" ne concerne pas les programmes propriétaire utilisant les appels systèmes.
Le but de la GPL n'est évidemment pas de conquérir le monde mais de coexister avec le propriétaire (à armes égales).
[^]Re: Explication dans les commentaires
Puisqu'on est toujours dans les précisions, il y a quand même une chose qui me gène, c'est que même si VMWare est "autorisé" à produire son module proprio, normalement, il n'a pas le droit de distribuer l'ensemble.
Hors, corrigez moi si je me trompe, mais VMWare ESX est un ensemble distribué par VMWare, contenant le noyau _et_ le module proprio ?! Donc c'est illégal. Non ?