VVL :: Le Blog sur les Licences Libres, Open Source, et leur diffusion

Un court billet pour présenter une expérience, une expérimentation, un « pavé dans la mare » à laquelle j’ai modestement contribué et qui pourrait changer, modifier notre vision de la propriété intellectuelle et la place qu’elle occupe dans notre société^[1].

Tout le monde connaît, même vaguement la Propriété Intellectuelle^[2] et les utilisations qui peuvent en être faites (pour prendre les deux extrêmes : le contrôle absolu représenté par la SACEM ou les éditeurs de logiciels traditionnels, et le partage par les licences libres).

• (En bref,) la propriété intellectuelle repose sur un équilibre entre l’intérêt du public (A)^[3] et l’intérêt des créateurs/auteurs/inventeurs/etc. (B).

• Ses objectifs (qui justifie le monopole accordé aux ayants-droits (B)) sont : -1- de faciliter et favoriser l’innovation (au bénéfice de la société et donc du public (A)), -2- donner à l’auteur un contrôle sur son oeuvre en raison du lien qui les unit^[4].

• Ainsi, ce système repose enfin sur un postulat (on estime que cela marche)/une autojustification du point -1- : « puisqu’il existe et “qu’il marche” (des gens continuent à créer et innover), c’est bien que le système actuel favorise la création et sa diffusion. »

La SARD serait donc une remise en question de ce dernier postulat : « un changement de paradigme », de mentalité, un système différent qui, s’il fonctionne, montrerait que le système actuel de PI n’est pas la seule (et/ou la meilleure) façon de favoriser la création et l’innovation. Attention, il ne s’agit pas forcément d’une alternative, mais plus d’un système parallèle qui, s’il marche, délégitimerait celui que l’on connaît aujourd’hui.

Ainsi, ces artistes pourraient éventuellement toucher de l’argent/un financement sans user de leurs droits de propriété intellectuelle, à eux de voir ensuite s’ils désirent jouer dans les deux camps (qui sont néanmoins contradictoire puisqu’il me semble légitime de penser que celui qui diffuse gratuitement et massivement sa musique aura plus de facilité à recevoir des dons que celui qui ne vend que quelques exemplaires dans quelques boutiques spécialisées).

Voici, rapidement, mes réflexions : rien d’exhaustif et de parfaitement abouti, mais suffisamment pour estimer que ce projet vaut le temps qu’on lui accorde…

Dans la diversité de comportement qui caractérise les sociétés qui font du libre/de l’open source, il est intéressant de constater le rejet unanime des brevets logiciels : au sein des licences^[1] comme des engagements annexes. Celles-ci n’hésitent plus à opérer des regroupements des brevets à titre défensif : initiatives individuelles^[2] ou collectives^[3], elles contribuent ainsi à mutualiser les efforts défensifs dans l’objectif d’immobiliser toute action tierce en contrefaçon de brevet (notamment du fait des patents trolls^[4]). Deux comportements sont généralement associés : d’une part une promesse de ne pas opposer les brevets aux communautés open source et, d’autre part, l’engagement d’une protection des communautés grâce à ce pool de brevets.

En effet, l’une des difficultés principales que l’on associe au régime des brevets logiciels est l’insécurité juridique qui en découle – liée à l’impossibilité de contourner un brevet en cas de doute (comme on peut le faire aujourd’hui en réécrivant le passage litigieux). Je ne vais pas réecrire un billet sur ce sujet, mais plutôt vous inviter à relire l’article et les documents que j’avais publiés suite à une intervention à l’APEB.

S’il est une initiative qui réunit le plus de communautés, d’industries et de ressources variées, c’est l’Open Invention Network. Ceci d’autant plus autant qu’elle conduit une nouvelle initiative, Linux Defenders, de façon à étendre son action.

Le billet ci-après s’inspire fortement de celui plus copieux rédigé sur LegalPad.

Un petit mot rapide pour vous présenter les travaux d'Armijn Hemel (Loohuis Consulting^[1]), eux-mêmes issus de recherches opérées dans le cadre de gpl-violations^[2].

Ce guide, que l'on pourrait qualifier de « livre blanc », a pour objectif de permettre aux techniciens de vérifier la présence de code sous licence GNU GPL/LGPL (mais ce serait la même chose pour toute licence similaire) — versant technique indispensable à des actions en contre-façon comme celles opérées par gpl-violation ou à la SFLC.

Pour le coup, je ne suis pas suffisamment au fait de toutes les techniques décrites pour réaliser une analyse pertinente et utile du guide. Je vais ainsi me contenter de reprendre les points clés^[3]..

L'auteur sera de surcroît à la NLUUG autumn conference et à l'Embedded Linux Conference Europe (le mois prochain à Ede, en Hollande)

Nous en avions, à l’époque de sa sortie, publié une courte analyse. Nous précisions alors qu’il ne s’agissait, ni plus ni moins, que d’une simple (?) GNU GPL v3 à laquelle venait se substituer une clause spécifique^[1] (remplaçant logiquement l’article 13 de la GNU GPL v3 qui permet expressement l’integration de briques sous GNU AGPL dans un tout sous GNU GPL) venant encadrer l’usage qui pouvait être fait du logiciel par le réseau.

Cette licence, réclamée par beaucoup, venait combler l’ « ASP Loophole » (faille des logiciels utilisés en SaaS : Software as a Service^[2]) en faisant en sorte que le licencié qui utilise un logiciel pour fournir un service à des utilisateurs via le réseau ne puisse le faire sans redistribuer les modifications qu’il aurait lui-même apportées à ce dernier. Lors de sa sortie, la FSF n’hésita pas à la présenter comme une ouverture plus large de la communauté du logiciel libre, permettant une libération des logiciels à une autre échelle pour créer un « nouveau pot commun » autour de ces programmes utilisés comme services :

La FSF recommande aux développeurs de songer à utiliser la GNU AGPL pour tout logiciel qui fonctionne habituellement au travers d’un réseau.^[3]

[…]

Benjamin Mako Hill, membre du conseil d’administration de la FSF, déclara « la GNU GPL a été la licence libre la plus prospère parce qu’elle rend les sources d’un programme disponible pour tous ses utilisateurs. Ceci permet une collaboration massive entre les développeurs, puisque chacun retire un même bénéfice de cette règle. La GNU AGPL permettra le même type de coopération autour des logiciels utilisés pour le service web ou réseau »^[4].

[…]

« La GNU AGPL est véritablement une licence communautaire » indiqua Peter Brown, Directeur Exécutif de la FSF. « Les commentaires que nous avons reçu lorsque nous travaillions sur la GPLv3 démontrèrent un désir clair pour ce type de licence. Et grâce à l’aide de la communauté durant la rédaction, nous sommes ravis que l’AGPL remplisse ces besoins ».^[5]

Pour un avis contraire, voir cet article sur la position de Google et cet autre sur celle de Microsoft à propose de l’AGPL.

Les réactions furent par ailleurs extrêmes : les uns déclarant qu’il fallait dès lors utiliser systématiquement cette licence (puisque tout logiciel pouvait bien, un jour ou l’autre, être utilisé comme service) ; les autres hurlant à la mort du Libre du fait de son immixtion dans la sphère privée.

Trouvant que cette licence ajoutait une couche de complexité à une GPL déjà bien trop obscure, je ne la conseillais jusqu’à maintenant que rarement, attendant qu’elle se révèle pleinement, dans le bon comme dans le mauvais. La certification récente de la licence par l’OSI oblige néanmoins à prendre une position plus réfléchie sur cette licence. Je dois avouer avoir été assez étonné par celle-ci : seuls quelques mails avaient amorcé la discussion sur la mailing liste de l’OSI dédiée à l’étude des nouvelles licences (voir ce billet pour plus de détails sur la procédure), alors que des licences parfois bien plus simples et sans grand intérêt engendraient des échanges de plusieurs dizaines de mails (pour exemple, les fils dédiés aux licences de Microsoft ou à la GNU GPL ne sont toujours pas terminés après de longs mois).

Initialement plutôt favorable à cette licence qui ajoutait à la famille des licences GNU une particularité que n’abordait avec satisfaction que l’Open Software License (de Lawrence Rosen), je conseille aujourd’hui une assez grande vigilance dans son application. En effet, piqué par la curiosité, j’ai décidé de reprendre l’ensemble des échanges (principalement issus des quelques mailing-lists que je parcours habituellement : debian-legal ; open source –discute et review– ; et free software business) afin de dresser un tableau plus complet de la situation.

Force est de constater que le bilan n’est pas si rose, et l’historique instructif. Le résumé qui suit cherche à présenter le plus fidèlement possible les informations glanées en les regroupant en quelques points : l’historique de cette licence et de ses péripéties, la façon dont elle fut perçue par la communauté et les sociétés, sa portée et les diverses analyses qui complètent son appréhension.