Retour sur une sympathique entrevue avec Eben Moglen, organisée à l'initiative de la communauté open-source OW2 (dont je suis membre actif)...

Pour ceux qui ne connaissent pas Eben, c'est tout simplement l'avocat de la FSF (Free Software Foundation), l'auteur des licences GNU (dont la fameuse GPL), et sans doute le premier juriste à avoir traduit en termes légaux la notion de "copyleft" (il n'a pas inventé le copyleft... mais lui a donné la validité juridique qui lui manquait !). Il enseigne aussi le droit à l'Université de Columbia (New York).
Eben est également un homme de conviction, et développe une analyse marxiste de l'évolution de la propriété intellectuelle (selon lui, une nouvelle "lutte des classes" oppose les travailleurs de la connaissance aux tenants de la propriété intellectuelle "classique", que le sens de l'histoire devra faire tomber, comme il a fait tomber la propriété féodale au moment de la Révolution française... La propriété intellectuelle étant perçue comme une des bases du système économique, son raisonnement prend alors une portée générale).

Bref, à mon sens, Eben est l'un des juristes les plus importants des 30 dernières années... Mais revenons à notre thème central : nous sommes ici pour questionner Eben sur la licence GPL (en particulier, la nouvelle GPL v3, mais plus globalement ce qu'implique l'utilisation de la famille de licences GPL).

Rappel pour les non initiés : la GPL (General Public License) met en oeuvre le principe du "copyleft" (jeu de mot intraduisible, qui suggère le contraire du droit d'auteur - "left" signifie "gauche" alors que le "right" de "copyright" signifie "droite" - mais aussi le fait de laisser le droit à quiconque de copier : "copy left" signifie, en gros, "je laisse copier qui veut").

Le copyright permettait à un auteur de restreindre les droits sur son oeuvre (droits d'utilisation, de distribution, de modification...). Le copyleft, c'est l'inverse : l'auteur interdit à quiconque toute restriction des droits (et laisse généralement, au départ, toute liberté de copie, distribution ou modification).

La GPL met en oeuvre le "copyleft" de façon virale : non seulement les droits ne peuvent être restreints sur l'oeuvre originale, mais également sur toute oeuvre dérivée (forcément couverte par la même GPL). Elle garantit que toute oeuvre libre, même modifiée, le restera...

Et notre réunion ? Eh bien, elle se déroule à Paris (le 5 juin dernier), en présence d'une dizaine de personnes, dont j'ai la joie de faire partie. Je me suis spécialement déplacé pour l'occasion : 2 heures de questions libres à Eben Moglen, comment résister ?

Compte-rendu, dans la limite de ce que je peux comprendre (je ne suis pas juriste, et dispose d'un anglais acceptable... sans plus !) :

Tout d'abord, Eben a fait quelques rappels simples sur la GPL : en ce qui concerne les oeuvres dérivées, il est clair que les modifications privées peuvent rester privées (usage interne, par exemple - ou toute modification qui n'est pas diffusée)... mais toute version distribuée doit être couverte par la GPL, qui est bien en ce sens une licence virale.

La GPL v3 définit plus clairement ce qu'est une copie "privée" (non couverte par la GPL car non redistribuée) : il est maintenant clair que la sous-traitance reste dans le cadre privé. Exemple : si une SSII travaille pour vous, sous contrat, sur du code GPL que vous ne redistribuez pas... le fait de le transmettre à cette SSII n'est pas une distribution, donc ce n'est pas couvert par la GPL !

J'ai pu poser à Eben une question qui me taraude depuis longtemps : à savoir, quel est le périmètre exact d'une "oeuvre dérivée" ? Par exemple, une application de gestion qui utilise la base de données MySQL (couverte par la GPL) ne saurait être considérée comme une "oeuvre dérivée" de MySQL... mais où est la limite ?

J'ai pris un exemple plus tangent : une servlet déployée dans un conteneur couvert par la GPL... Réponse d'Eben : dans la mesure où les 2 programmes peuvent fonctionner indépendamment (dans le cas de ma servlet, çà implique qu'il existe au moins un second conteneur compatible dans lequel je puisse la déployer), ET à condition qu'une interface publique d'échange soit utilisée (ma servlet utilise l'API servlet, qui est publique), alors on n'est pas en présence d'une oeuvre dérivée.
Donc, même si l'interface d'un composant GPL est publique, encore faut-il que le composant qui fournit cette interface soit interchangeable... sinon, tout programme qui l'utilise est une oeuvre dérivée !
A noter que la GPL v3 éclaircit les choses, dans ce domaine (sous GPL v2, toute distribution commune de 2 oeuvres était considérée comme une seule oeuvre composite, même si l'oeuvre n'était pas à proprement parler "dérivée" - ce n'est heureusement plus le cas). Pour les servlets, on est donc tranquilles... mais il faut quand même se méfier !

Eben a ensuite tempéré ce propos en rappelant que, si je suis l'auteur d'un programme, c'est moi qui fixe les droits : je peux très bien fournir une interface publique, et décréter que les programmes qui utilisent cette interface ne sont pas des oeuvres dérivées du programme initial. Il parait même que Linus Torvalds a utilisé ce moyen pour certaines interfaces du noyau Linux !

Sinon, retour sur quelques caractéristiques spécifiques à la GPL v3, d'après ce que j'ai pu comprendre...

La GPL v3 se veut "transnationale", c'est-à-dire détachée de tout contexte juridique local (entendez "moins liée au droit américain que la v2"). Pour celà, elle utilise un vocabulaire le moins connoté possible (décorrélé du domaine juridique).

Le droit central qu'octroie la GPL, c'est le droit de distribuer une oeuvre dérivée : la GPL v3 établit clairement que des oeuvres dérivées peuvent être librement redistribuées, et que ce ne sera pas criminel quelle que soit la juridiction.

La GPL v3 offre aussi des garanties nouvelles, au moins dans 2 domaines :
- La "tivoization" (= le fait de faire en sorte qu'un logiciel ne puisse fonctionner que sur une plateforme hardware donnée) : sous GPL v3, toute oeuvre dérivée adaptée à un hardware spécifique doit être distribuée avec le mode d'emploi pour l'installer.
- Les brevets : l'auteur ne peut défendre aucun brevet sur le code original (et le principe vaut aussi pour les contributeurs, concernant les oeuvres dérivées). Si brevet il y a, les utilisateurs / distributeurs / contributeurs du code ne peuvent être inquiétés à ce titre.

Enfin, questionné sur la validité éventuelle de "restrictions à l'exportation" pour un programme couvert par la GPL, Eben est catégorique : c'est impossible. Raison invoquée à titre d'exemple : "Microsoft est assez riche pour s'acheter un petit état" ! CQFD...

Si, globalement, la discussion est restée assez technique (quoique rendue vivante par quelques exemples et anecdotes), Eben n'a pu totalement s'empêcher d'aborder le volet "idéologique" :
Lorsqu'une communauté publie du code sous GPL, il devient très difficile de prendre le contrôle de cette communauté (de la racheter, par exemple...). L'utilisateur se trouve alors en présence d'une chaîne d'approvisionnement "sans but lucratif" (littéralement "non profit supply chain"), qu'il est nécessaire de protéger comme tout bien commun devrait l'être : Eben a pris pour exemple la forêt, ou, avec malice, nos marins-pêcheurs...

Voilà, j'arrête là... en espérant que ce compte-rendu puisse être utile, et que je n'ai pas trop déformé les propos d'Eben (en les comprenant mal ou en les traduisant). En tout cas, j'ai maintenant les idées plus claires, et j'espère que vous aussi !

Un grand merci, bien sûr, à Eben Moglen pour sa patience et sa disponibilité.