Retour de POC21 : quelles licences pour l’Open Hardware ?

Ce week-end a vu la conclusion au Château de Millemont dans les Yvelines d’une expérience particulièrement intéressante associant la problématique environnementale à celle de l’Open Source. Durant 80 jours, le projet POC21 a rassemblé une centaine de participants au sein d’un camp d’innovation, visant à développer des solutions techniques pour la transition énergétique et la lutte contre le réchauffement climatique. Organisée par OuiShare et Open State, cette initiative s’inscrit en résonance avec la COP21, qui va s’ouvrir cet automne à Paris. L’idée est de démontrer que, sans attendre une action des Etats qui n’a que trop tardé, les citoyens peuvent se mobiliser concrètement sur la question du changement climatique, en innovant de manière collaborative.

[vimeo 132919309]

Pour apporter cette « preuve de concept » (POC), 12 projets ont été sélectionnés, visant à produire des appareils à la fois Open Source et durables. On retrouvait par exemple dans ce panel une éolienne « DIY » pouvant être mise en place avec des matériaux de récupération pour moins de 30 dollars ; une douche recyclant l’eau utilisée en temps réel pour diviser par dix son impact environnemental , un tracteur à pédales destiné à aider les cultivateurs de petites exploitations bio sans avoir à recourir à des machines coûteuses et polluantes ; un filtre à eau adaptable à n’importe quelle bouteille pouvant être produit pour moins d’un dollar avec une imprimante 3D, etc.

Un des intérêts majeurs de la démarche de POC21 a été de s’inscrire d’emblée dans les principes de l’Open Source, déjà appliqués dans le secteur du logiciel. L’objectif consiste en effet à l’issue du camp à publier l’ensemble de ces inventions et la documentation associée, afin que chacun puisse librement construire les objets et les améliorer. On appelle « Open Hardware » cette application de la philosophie de l’Open Source à la fabrication d’objets matériels et ce courant est en plein essor en ce moment, avec l’expansion du mouvement des « Makers » au sein des FabLabs et autres Hackers Spaces partout sur la planète.

IMG_20150919_112920
Les valeurs du projet POC21, affichées sur un « totem » à l’exposition de ce week-end, où étaient présentés les 12 projets.

 Il se trouve que j’ai eu la chance d’apporter ma pierre à cette aventure, par le biais d’un atelier sur la question des licences que Benjamin Tincq de OuiShare m’a demandé d’animer la semaine dernière à Millemont. Ce fut un moment extrêmement intéressant, notamment pour approfondir la question de l’adaptation des licences à la problématique de l’Open Hardware. La question est en effet plus complexe et moins bien balisée qu’en matière de logiciels, où les licences libres ont fait leurs preuves depuis longtemps.

De l’Open Source à l’Open Hardware

Les 12 équipes de porteurs de projets impliqués dans POC21 se sont engagés à publier leurs résultats en Open Source à l’issue des 6 semaines de développement. Ils l’ont fait par le biais des clauses de ce contrat que l’on peut lire ci-dessus :

Pour les logiciels, on voit que les participants sont incités à recourir à une licence libre comme la GNU-GPL ou des licences Open Source, comme la FreeBSD ou la MIT Licence. Pour les productions assimilables à des oeuvres de l’esprit (textes, photos, vidéos, etc.), on leur recommandait plutôt d’utiliser des licences Creative Commons (CC-BY ou CC-BY-SA). Mais pour les éléments spécifiquement liés au matériel (notamment les fichiers de conception des objets, les plans de fabrication et tout autre documentation associée), les porteurs de projets étaient invités à se tourner vers deux licences spécialement conçues pour l’Open Hardware : la TAPR Open Hardware Licence et la CERN Open Hardware Licence.

Pourquoi recourir à des licences spécifiques pour les projets liés à la fabrication d’objets ? Il a déjà existé dans le passé des initiatives remarquables en matière d’Open Hardware qui ont simplement fait le choix de réutiliser des licences déjà existantes. Par exemple, le projet emblématique Open Source Ecology, proposant des plans librement réutilisables de machines agricoles de base, a utilisé pour diffuser ceux-ci la licence GFDL, employée traditionnellement pour la documentation associée aux logiciels libres. De leur côté, les fameuses puces Arduino s’appuient simplement sur la licence Creative Commons CC-BY-SA.

Il existe cependant deux problèmes principaux à réutiliser de telles licences n’ayant pas été conçues à la base pour du matériel. Le premier, c’est que ces licences sont principalement ancrées dans le droit d’auteur, dont relèvent aussi bien les logiciels que les oeuvres de l’esprit. Or en matière de fabrication d’objets matériels, d’autres questions juridiques peuvent se poser, relevant notamment de la propriété industrielle (droit des dessins et modèles, brevets liés aux inventions). Il y a donc un intérêt à utiliser des licences adaptées pour ne pas laisser ces problématiques dans un angle mort.

La seconde difficulté, c’est que des licences uniquement basées sur le droit d’auteur ne prennent pas en compte la question spécifique de la fabrication des objets à partir de la documentation placée sous licence libre. Si je reprends l’exemple du projet Open Source Ecology, la licence GFDL retenue s’applique aux plans des machines agricoles. Si quelqu’un republie ces plans ou en produit des versions modifiées, il sera bien soumis à des obligations découlant de la licence (notamment la clause de partage à l’identique – copyleft – l’obligeant à republier les versions dérivées sous la même licence). Mais une personne se contentant de fabriquer des objets à partir de ces plans ne sera pas liée par la licence, car cette opération n’entre tout simplement pas dans son champ d’application.

L’objectif des licences spécialement conçues pour l’Open Hardware est donc d’embrasser non seulement la documentation, mais également le processus de fabrication, en imposant certaines conditions à la production d’objets manufacturés à partir de la documentation partagée.

TAPR Licence et CERN Licence

POC21 recommande deux licences en particulier pour les aspects liés au matériel. La première est la TAPR Licence, créée en 2007 par une fédération de radio-amateurs aux Etats-Unis. La seconde est la CERN Licence, proposée par le Centre Européen de Recherche Nucléaire, la célèbre institution où le web fut inventé par Tim Berners-Lee. Le CERN a en effet mis en place un Open Hardware Repository où les chercheurs et ingénieurs qui y travaillent partagent des centaines de plans d’objets technologiques. Pour clarifier les conditions de réutilisation de ces ressources, une licence dédiée a été créée.

Ces deux licences sont très proches l’une de l’autre. Elles visent toutes les deux à reproduire les mécanismes des licences Copyleft (comme la GNU-GPL de Richard Stallman ou la licence CC-BY-SA sous laquelle est placée Wikipédia). Je dirais simplement que la CERN Licence est formulée de manière plus simple et qu’elle me paraît un peu moins compliquée à appliquer que la TAPR Licence.

Un premier apport de ces licences par rapport aux licences classiques de logiciels libres consiste à définir et lister précisément ce que l’on doit entendre par « documentation » dans le contexte d’un projet de fabrication, ainsi que d’ajouter une définition du « produit » réalisé à partir de cette documentation. Voyez par exemple ces définitions dans la TAPR Licence :

1.2 « Documentation » includes:
(a) schematic diagrams;
(b) circuit or circuit board layouts, including Gerber and other data files used for manufacture;
(c) mechanical drawings, including CAD, CAM, and other data files used for manufacture;
(d) flow charts and descriptive text; and
(e) other explanatory material.
Documentation may be in any tangible or intangible form of expression, including but not limited to computer files in open or proprietary, formats and representations on paper, film, or other media.

1.3 « Products » include:
(a) circuit boards, mechanical assemblies, and other physical parts and components;
(b) assembled or partially assembled units (including components and subassemblies); and
(c) parts and components combined into kits intended for assembly by others;
which are based in whole or in part on the Documentation.

La personne qui diffuse un design sous une de ces licences Open Hardware s’engage ainsi à rendre disponible toute la documentation associée à l’objet (et même à maintenir cet accès pendant 3 ans, en ce qui concerne la TAPR Licence). Elle doit aussi fournir un moyen d’accéder à la documentation lorsqu’elle distribue des objets.

Les deux licences font ensuite une distinction entre la réutilisation de la documentation décrivant un objet et la fabrication de ce dernier. Pour ce qui est de la réutilisation de la documentation, celle-ci peut être rediffusée à l’identique ou avec des modifications. Dans le premier cas, la documentation doit être maintenue sous la même licence, en l’attribuant clairement à ses créateurs originaux (condition de respect de paternité). Si la documentation est modifiée pour produire une nouvelle version (par exemple modification d’un fichier de CAO ou d’un plan), alors la personne qui opère ces modifications est obligée de les faire apparaître nettement dans une nouvelle documentation, en indiquant ce qui relève du design original et ce qui relève de ses propres apports. Par ailleurs, elle sera obligée de placer cette documentation modifiée sous la même licence (effet viral ou « contaminant » du Copyleft).

Par ailleurs, les deux licences envisagent aussi le processus de fabrication en lui-même des objets. Elles précisent notamment que celui qui manufacture un objet dont la documentation est placée sous une telle licence doit inscrire une mention spéciale sur l’objet lui-même (dans la mesure où c’est possible). Par ailleurs, les licences garantissent la possibilité pour les réutilisateurs de fabriquer les objets à partir de la documentation, de les modifier, ainsi que de les diffuser, y compris commercialement. On retrouve là les mêmes principes que dans les licences de logiciel libre (pas de restriction de l’usage commercial tant que l’on respecte les conditions de la licence). Par contre, si un réutilisateur produit un objet modifié et le distribue (commercialement ou non), alors il doit produire une documentation spécifiant en quoi consiste ces modifications, et la mettre à disposition en la plaçant sous la même licence.

Une puce produite par le CERN portant « physiquement » une mention selon laquelle ce matériel a été placé sous la CERN Licence.

En discutant avec les porteurs de projets de POC21, je me suis rendu compte que ces questions de viralité des licences étaient importantes pour eux. Notamment, certains craignaient que la modification de leurs appareils par d’autres produisent des versions moins performantes ou défectueuses. La TAPR Licence et la CERN Licence protègent le créateur initial, avec des clauses l’exonérant des dommages qui pourraient être causés par des versions modifiées. Par ailleurs, l’obligation de documenter précisément les modifications permet d’éviter les confusions entre des versions originales et des versions modifiées. Ce mécanisme de copyleft joue ainsi le rôle d’une « certification d’origine », d’autant plus important que l’on parle ici d’objets.

La TAPR Licence contient même un mécanisme supplémentaire, destiné à permettre au créateur original un suivi plus étroit des modifications apportées à son design initial. Il lui est possible en effet de laisser son adresse mail dans un fichier joint à la documentation, auquel cas les réutilisateurs produisant de nouvelles versions doivent le contacter pour lui signaler. Le problème, c’est qu’une telle obligation est elle aussi virale : tous les réutilisateurs successifs doivent signaler par mail leurs modifications à tous les créateurs antérieurs étant intervenus sur le design. Ce mécanisme a visiblement été jugé trop lourd, notamment pour les projets entraînant un grand nombre de modifications successives,  et il a été supprimé dans la dernière version de la CERN Licence, tandis qu’il est devenu seulement optionnel dans la TAPR Licence.

Quelle articulation avec le droit des brevets et le droit des marques ? 

Ni la TAPR Licence, ni la CERN Licence n’empêchent de déposer un brevet sur une invention relative à un objet décrit dans la documentation. Néanmoins, les deux licences contiennent une clause spécifique précisant que celui qui accorde la licence s’engage à ne pas faire valoir les prérogatives qu’il pourrait tirer du brevet à l’encontre d’un utilisateur pour tous les usages couverts par la licence. Cela signifie donc que celui qui accorde la licence peut conserver un brevet à des fins exclusivement défensives, pour se protéger par exemple de tiers qui viendraient revendiquer un brevet sur la même invention (Patent Trolls notamment). Mais en dehors de cette hypothèse, les deux licences Open Hardware « neutralisent » vis-à-vis des utilisateurs les brevets éventuels en relation avec le design libéré.

Il en résulte donc que les porteurs de projet n’ont que peu intérêt à déposer des brevets lorsqu’ils ont l’intention de placer leurs productions sous licence CERN ou TAPR. Parmi les participants au projet POC21, aucun n’avait d’ailleurs a priori une telle volonté de recourir au brevet et beaucoup jugeaient même une telle démarche comme contraire aux principes de l’Open Source. Leurs interrogations était plutôt d’un autre ordre. Un certain nombre se demandaient comment être certains de ne pas mettre en Open Hardware des inventions faisant déjà l’objet d’un brevet. La question est en effet délicate, car à moins de mener de longues recherches dans les bases de brevets, il paraît assez difficile d’être certain à 100% de ne pas enfreindre de brevet préexistant. Par ailleurs, certains craignaient que des tiers hostiles ne cherchent à déposer des brevets sur leurs productions pour se les approprier, une fois qu’ils auraient publié en ligne leur projet. Normalement, la publication d’une invention « bloque » la possibilité pour des tiers de déposer un brevet, car seules les solutions techniques « nouvelles » sont protégeables. Mais encore faut-il pour cela documenter soigneusement la date de publication pour être en mesure de produire des preuves en cas de difficultés. On sait aussi que le système des brevets, notamment aux Etats-Unis, est profondément gangrené par les pratiques prédatrices des Patent Trolls et il est difficile d’exclure complètement le risque qu’une entité malveillante cherche à s’approprier des technologies libérées. De ce point de vue, les projets Open Hardware me paraissent plus vulnérables que des projets industriels classiques, pouvant recourir aux services coûteux d’avocats spécialisés.

Concernant les marques, les deux licences Open Hardware les excluent explicitement de leur champ d’application. Cela signifie que contrairement aux brevets, rien n’empêche celui qui accorde une telle licence de continuer à faire valoir une marque déposée par ailleurs en relation avec le produit. Nombreux étaient d’ailleurs les porteurs de projets à POC21 qui envisageaient de déposer des marques, en lien avec un futur modèle économique. C’est une stratégie souvent employée par les entreprises œuvrant dans le secteur du logiciel libre et il existe également des exemples probants dans le champ de l’Open Hardware (comme celui des puces Arduino, couvertes par une marque alors que les matériels sont libres). La marque a l’avantage de jouer comme un certificat d’origine (ce qui est sa fonction première) ; elle permet aussi de protéger une identité autour de laquelle une communauté peut s’agréger. A propos de l’usage des marques par les communautés collaboratives, Yana Welinder, juriste de la Wikimedia Foundation, a écrit récemment un guide pratique donnant des pistes intéressantes pour concilier protection et ouverture.

Arduino TM, un projet Open Hardware articulé avec une marque de commerce protégée.

Interrogations sur la validité des licences Open Hardware

On voit donc que les licences Open Hardware permettent de prolonger la logique des licences libres dans la sphère de la fabrication matérielle. Il existe néanmoins des débats pour savoir dans quelle mesure elles sont bien valides, au même titre que la GNU-GPL ou les licences Creative Commons. Le problème principal réside dans le fait que ces licences restent tout de même principalement ancrées dans le copyright, alors même qu’elles entendent produire des effets sur le processus de fabrication d’objets. La documentation d’un projet est sans aucun doute dans la majorité des cas couverte par le droit d’auteur et comme le bénéfice du droit d’auteur est automatique, l’application d’une licence Open Hardware à la documentation ne soulève pas de problèmes particuliers : les obligations se déclenchant lorsque ces documents sont rediffusés et/ou modifiés sont sans conteste opposables.

Les licences Open Hardware ont un fort potentiel, mais elles soulèvent encore aussi des questions juridiques complexes.

En revanche, la forme des objets en elle-même ne sera pas nécessairement toujours protégée par le droit d’auteur : il faudra pour cela qu’elle soit considérée comme originale. En France, certains juges ont déjà estimé qu’un panier à salade constituait bien à raison de sa forme particulière une oeuvre de l’esprit originale protégeable par le droit d’auteur. Mais il est clair qu’à moins de présenter des caractéristiques esthétiques affirmées, beaucoup d’objets Open Hardware ne pourront pas être protégés par le droit d’auteur et c’était manifestement le cas de la plupart des projets de POC21.

Dans une telle hypothèse, seul le droit des brevets est alors susceptible de s’appliquer au processus de fabrication en lui-même des objets. Or dans la mesure où celui qui octroie une licence Open Hardware n’a pas déposé de brevet sur une invention lié à l’objet libéré, la licence paraît manquer de base légale sur laquelle s’appuyer. Cette difficulté a déjà été pointée par plusieurs observateurs, comme le fait ici Jonathan Kuniholm :

Every single effort to tackle the problem of open hardware licensing has failed to acknowledge that it is unclear what we are licensing (TAPR, CERN, OHANDA, OSHW, you name it), and if any license will withstand a legal challenge. Open source software has a legal basis in the copyright of source code AND the executable–perhaps most importantly in the copy of the executable made in RAM at startup. Without a legal basis for ownership rights, there is nothing to license, and it is pointless to discuss the fine points of a particular license. This is like talking about the architecture of a building without a foundation, land on which to build, or funding. Choose your metaphor.

Open (source) hardware is completely different than software, precisely because there is no clear analogue to software source code and the copyright basis for its protection (I prefer to leave out « source » exactly because of the issue that I am raising, although I appreciate others’ fondness for it based on the ease and most useful form to modify).

Il est donc difficile de savoir jusqu’à quel point les licences Open Hardware seraient reconnues comme valables devant un juge. La valeur contractuelle des obligations portant sur le processus de fabrication lui-même serait-elle jugée suffisante pour être reconnue opposable en justice ? C’est une question difficile à trancher.

***

On le voit, les porteurs de projets de POC21 vont à présent être confrontés à un certain nombre de choix concernant les licences, qui s’avéreront importants pour la suite. Le champ des licences Open Hardware n’est pas encore complètement stabilisé et il est sans doute plus compliqué de libérer le design d’un objet que le code source d’un logiciel. Confrontés à ces difficultés, certains des porteurs de projets étaient d’ailleurs tentés par une approche plus directe, consistant à placer toute la documentation de leur projet directement dans le domaine public en utilisant la licence CC0 (Creative Commons Zéro). Un tel choix a le mérite de la simplicité et il peut embrasser d’un coup toutes les composantes d’un projet (logiciel, design, documentation, etc). Mais cette démarche a paru dangereuse à d’autres. La publication sous CC0 constitue certes une divulgation, qui permet en théorie de bloquer le dépôt de brevet par des tiers hostiles, mais elle laisse la possibilité à des réutilisateurs de « refermer » des versions modifiées qu’ils auraient pu produire à partir de la documentation initiale, en les plaçant sous « Copyright : tous droits réservés ». Pour certains, ce risque paraissait négligeable, mais pour d’autres, il importait de protéger la communauté contre ce type de tentatives d’appropriation abusive. On retrouve ici alors des débats qui ont déjà eu lieu dans le champ du logiciel entre les partisans du « Libre » et ceux de « l’Open Source ».

Plusieurs autres porteurs de projets de POC21 se sont aussi montrés intéressés par les licences dites « à réciprocité » (Peer Production Licence, Commons Reciprocity Licence, etc.) Ces nouvelles licences – qui restent pour l’instant seulement à l’état de prototypes – n’autorisent l’usage commercial d’une ressource par une entité que dans la mesure où celle-ci « contribue » en retour aux communs. On s’éloigne alors de la logique originelle du « Libre » ou de l’Open Source, puisqu’on pose des restrictions à l’usage commercial, mais on garantit que des ressources mises en commun ne pourront pas être réutilisées par des entreprises sans qu’elles ne contribuent elles aussi en retour à la sphère des communs. Pour l’instant, les premières licences à réciprocité qui ont été écrites, comme la Peer production Licence de Dmitry Kleiner, ne sont pas spécialement adaptées à l’Open Hardware, car elles sont encore trop ancrées dans le droit d’auteur. Mais il semblerait qu’un projet d’écriture d’une licence FabLib dérivée de la licence Art Libre et spécialement dédiée au Hardware soit en cours, qui comportera en option une clause de réciprocité.

Il sera intéressant de voir les choix qui seront fait par les participants à POC21 et il faut également espérer que ce type d’initiatives se multiplient pour favoriser le développement de l’Open Hardware.

3 réflexions sur “Retour de POC21 : quelles licences pour l’Open Hardware ?

  1. Nicolas

    On a eu les mêmes discussions, il y a 10 ans concernant le f-cpu. La conclusion était que la GPL n’était pas si mal pour la protection des plans. Par contre, impossible de considérer les objets comme des produits dérivés des plans, comme peuvent l’être les binaires, issues des sources. J’imagine qu’il faudrait plus une forme de contrat, que de licence.

  2. Ping : Revue des sciences octobre 2015 | Jean Zin

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s