Bonnes pratiques de l’open source hardware 1.0

Comme indiqué par la déclaration de principes de l’open source hardware (version 1.0), le principe essentiel de l’open source hardware (OSHW) est le partage des documents de conception dans le but permettre à chacun de modifier ou de reproduire ces composants (y compris à fins commerciales). Mais au-delà de ce principe fondateur, il y de nombreuses autres choses que vous pouvez faire pour encourager le développement d’une communauté dynamique utilisant et améliorant votre projet open source hardware. Ce document a pour but de décrire ces bonnes pratiques.

Constituants d’un projet open source hardware

Ci-dessous sont évoqués quelque uns des documents que vous devriez considérer de partager lors de la publication de votre projet open source hardware. Il n’est pas obligatoire que vous les partagiez tous, mais plus vous mettrez de documents à disposition, plus cela apportera à la communauté et plus grande sera la chance que celle-ci s’appropriera votre projet.

Vue d’ensemble / introduction

Votre projet open source hardware devra inclure une description générale de l’identité et de la raison d’être de votre produit, écrit autant que possible pour un public de non spécialistes. C’est-à-dire, expliquez ce quels sont les objectifs de votre projet attendez avant de rentrer dans les détails techniques. Une bonne photo ou le rendu d’un modèle 2D/3D vous aideront dans ce but.

Documents de conception originaux

Les documents de conception originaux sont les documents que vous utilisez pour apporter des modifications à votre produit. Le fait de partager ces documents est la pratique essentielle de l’open source hardware.

Idéalement, vous concevrez votre produit open source hardware en utilisant des programmes libres ou open source afin de maximiser la capacité de toute personne intéressé à consulter ces documents et à les éditer. Cependant, les documents de conception sont souvent crées à travers l’utilisation de programmes propriétaires et enregistrés dans des formats également propriétaires. Il est alors essentiel de partager les fichiers originaux; ils constituent le “code source” original de votre produit hardware. Ce sont les documents essentiels permettant à toute personne intéressée d’apporter des modifications à votre design.

Les documents de conception originaux comprennent par exemple:

  • dessins 2D ou fichiers de conception assistée par ordinateur (CAO) tels que ceux utilisés pour décrire une pièce en deux dimensions fabriquée par découpe laser, vinyle ou jet-d’eau, dans leur formats originaux. Exemples : formats natifs de dessins 2D crées sous Corel Draw (.cdr), Inkscape (.svg), Adobe Illustrator (.ai) ou encore AutoCAD.
  • dessins 3D pouvant être imprimés en 3D, forgés, moulés par injection, extrudés, usinés, etc. Exemples: formats natifs de fichiers crées sous SolidWorks (.sdlprt, .sldasm) ou encore Rhino.
  • Fichiers de conception ECAD (Electrical Computer Aided Design) tels que saisies de schémas (schematic capture) ou schémas de montage (PCB layout). Exemples: fichiers natifs enregistrés par Eagle, Altium, KiCad ou encore gEDA.
  • Librairies de composants nécessaires pour la modification native des fichiers CAO (symboles, empreintes, systèmes de fixation, etc.)
  • Dessins techniques additionnels dans leurs formats originaux, si requis pour la fabrication de votre produit.
  • Illustrations (artwork) additionnelles pouvant être utilisées sur votre produit et incluses dans votre release OSHW, tel qu’un symbole ou une texture, dans leur format original.

Dans l’éventualité où un document de conception original ait été créé dans un format alternatif pouvant éventuellement être considéré comme un document annexe au sens défini dans la section suivante, ce document dans son format original pourra être considéré comme un document de conception original.

Exemples de formats alternatifs pouvant exceptionnellement constituer des documents de conception originaux :

  • G-code codé manuellement et définissant la coupe d’une pièce fraisée (G-CODE).
  • dessins de définition effectués à la main et digitalisés (JPEG).
  • scans 3D d’un moule façonné à la main. (STL)
  • Masque de gravage d’un circuit imprimé créé sous MS Paint (PNG)

Documents de conception annexes

Au-delà des documents de conception dans leurs formats originaux, il est souvent avantageux de partager vos documents dans d’autres formats plus accessibles. Par exemple, une bonne pratique de partage open source d’un fichier CAO est de partager ce document non seulement dans son format natif, mais également dans un panel de formats d’échanges et d’export pouvant être ouverts ou importés par d’autres programmes de CAO.

Il est également avantageux de fournir des rendus qui peuvent être aisément consultés par les utilisateurs finaux désireux de comprendre (mais pas nécessairement de modifier) comment votre produit est conçu. Par exemple, le PDF d’un circuit PCB ou la représentation STL d’un design 3D. Ces documents annexes permettent d’étudier votre hardware et éventuellement de le produire sans pour autant avoir besoin d’accéder aux logiciels propriétaires avec lesquels il a été conçu. Notez cependant que ces documents auxiliaires ne sauront se substituer aux documents de conception en format original.

Exemples de documents de conception annexes:

  • dessins 2D ou fichiers CAO exportés dans un format d’échange 2D. Exemples: DXF, SVG.
  • dessins 2D ou fichiers CAO exportés dans un format 2D aisément consultable. Exemples de formats: PDF, JPEG, PNG. (Dans la mesure du possible, les formats vectoriels seront préférés aux formats bitmap).
  • dessins 3D ou fichiers CAO exportés dans un format d’échange 3D. Exemples: de formats: STEP, IGES.
  • dessins 2D ou 3D exportés dans des formats prêts à fabriquer. Exemples de formats: G-code, STEP-NC, STL, AMF.
  • fichiers de conception de PCB exportés dans des formats d’échanges. Exemples de formats: EDIF, OpenJSON
  • fichiers de conception de PCB exportés dans des formats prêts à fabriquer. Exemples de formats: Gerber RS-274X, Excellon.
  • dessins techniques additionnels dans leurs formats originaux, et, si requis pour la fabrication de votre produit, également dans un format lisible par des outils conventionnels tels que le format PDF.
  • Illustrations (artwork) additionnelles, par exemple styles visuels (skins) de différentes couleurs pour un tableau de bord.

Liste de pièces, ou nomenclature

Bien qu’il soit possible de retrouver la liste des pièces à partir des documents de conception, il reste important de fournir une nomenclature dans un fichier séparé. Celle-ci peut être délivrée sous forme de tableur (p. ex. CSV, XLS, Googls Docs) ou simplement dans un document texte listant les pièces de votre produit ligne par ligne. Si le programme CAO que vous utilisez comprend un outil de gestion de nomenclature (per exemple inclus en standard dans SolidWorks ou en tant que package additionnel comme bom-ex pour Eagle), ceci pourra vous aider. Les informations utiles à intégrer dans la nomenclature sont le nombre de pièces requises, leur fournisseurs, leur coût ainsi qu’une courte description de chaque pièce. Faites en sorte qu’il soit facile de retrouver quelle pièce de la nomenclature correspond à quel composant dans vos documents de conception: utilisez des désinences communes, délivrez un schéma indiquant quelle pièce va où, ou sinon expliquez simplement les correspondances.

Software et firmware

Il est nécessaire de partager tout code source ou firmware nécessaire au fonctionnement de votre produit. Ceci permettra d’une part aux utilisateurs de l’utiliser avec leur hardware ou de le modifier au cours de leurs modifications de votre hardware. Documentez le procédé nécessaire à la compilation de votre software, ceci comprenant l’indication de liens et de dépendances envers, par exemple, toute librairie et outil tiers. De plus, il sera utile de fournir une vue d’ensemble de l’état de votre software (p. ex. “stable”, “beta” ou “pas encore vraiment fonctionnel”).

Photos

Fournissez des images permettant de comprendre ce qu’est votre projet et comment assembler votre produit. C’est généralement une bonne pratique que de publier des photos présentant votre produit selon différentes perspectives et dans ses différentes étapes d’assemblage. Si vous n’avez pas de photos, poster des rendus 3D de votre design peut être une bonne alternative. Dans un cas comme dans l’autre, il est nécessaire de délivrer pour chaque image une légende ou un texte expliquant ce que celle-ci représente et pourquoi elle est utile.

Instructions et explications annexes

Au-delà des documents de conception en tant que tels, de nombreuses explications pourront venir en aide à celui ou celle qui voudra copier ou modifier votre hardware:

Assemblage. Afin d’aider à la copie de votre hardware, vous devrez fournir des instructions permettant de passer de vos documents de conception à un produit physique fonctionnel. Parmi ces instructions, il est utile de faire référence aux fiches techniques (datasheets) des composants et pièces de votre nomenclature et de lister les outils nécessaires à leur assemblage. Si l’assemblage de votre produit requiert des outils spécifiques, expliquez où il sera possible de se les procurer.

Utilisation. Une fois que quelqu’un aura répliqué votre hardware, il ou elle devra savoir comment l’utiliser. Publiez des explications relatives aux fonctions de votre produit, à son initialisation et à son usage.

Logique du design. Si quelqu’un veut modifier votre design, il ou elle voudra savoir pourquoi il est conçu tel qu’il est conçu. Expliquez la logique générale de votre design et pourquoi vous avez fait les choix de conception que vous avez faits.

Gardez en tête que ces instructions vont potentiellement être lues par quelqu’un dont l’expertise et l’expérience est différente de la vôtre. Autant que faire se peut, essayez d’écrire ces explications pour une large audience, veillez à éviter un jargon trop technique et soyez explicite quant aux prérequis que le lecteur devra avoir pour comprendre vos explications.

Des instructions peuvent être données dans une large gamme de formats: wiki, fichier texte, Google Doc ou PDF, pour ne citer que quelques exemples. Gardez cependant en tête que d’autres voudront peut être modifier vos instructions (par exemple après avoir modifié votre hardware). Il est ainsi utile de partager les fichiers originaux et éditables avec lesquels vous les avez générées en plus des formats d’exports tels que PDF.

Bonnes pratiques de conception open source

Si vous prévoyez de publier un produit en open source, certaines bonnes pratiques de conception vous permettront de simplifier la tâche à ceux qui voudront répliquer ou modifier votre hardware:

  • Préférez l’utilisation de logiciels de CAO open source. Si impossible, préférez l’usage d’outils à faible coût et/ou largement répandus.
  • Utilisez des composants, matériaux et procédés de production largement répandus. Évitez d’utiliser des composants qui ne sauraient être accessibles à l’achat pour un utilisateur individuel et des procédés nécessitant de larges  investissements.

Hébergement de vos documents de conception

Un moyen simple de partager vos documents est de déposer un fichier zip sur votre site web. Si c’est un bon début, ceci ne permettra cependant pas vraiment aux autres de suivre vos progrès ou d’y contribuer.

Nous recommandons l’usage de dépôts spécialisés  (tels que GitHub, Gitorious ou Google Code) afin de gérer la documentation de votre projet open source hardware. Tous les fichiers (qu’il s’agisse des documents de conception, de la nomenclature, des instructions d’assemblage ou du code source) doivent être si possible versionnés. Si vous voulez développer votre hardware publiquement, ces dépôts spécialisés  vous aideront à publier les changements apportés à vos fichiers en temps réel.

La plupart des dépôts permettent également la gestion des incidents (issue tracking), ce qui est une bonne manière d’identifier et de suivre les bugs ainsi que les évolutions futures de votre software, de telle manière que d’autres pourront les voir et les commenter. Certaines plateformes permettent de maintenir un wiki, ce qui peut être un bon outil pour documenter votre projet.

Une solution alternative est de développer votre projet à l’aider d’un outil CAO en ligne (tel que Upwerter) ou de partager vos fichiers sur un site tel que Thingiverse.

Choisir et appliquer une licence

Bien que choix et l’application de licences appropriées peuvent se révéler complexes, l’usage de licences est un moyen important de signaliser comment d’autres pourront et devront utiliser vos travaux. En appliquant explicitement une licence open source à vos fichiers de conception et à votre documentation en général, vous signalisez clairement que d’autres pourront les copier et les modifier. Ce faisant, gardez en tête que quelqu’un créant un dérivé de votre hardware voudra probablement également s’inspirer de votre code source, de vos instructions et autres documents. Ainsi, vous ne devrez pas seulement appliquer une licence à vos documents de conception, mais également à l’ensemble des éléments de documentation de votre projet.

Notez que le copyright (sue lequel la plupart des licences sont basées) ne s’applique pas au hardware en tant que tel, mais seulement aux documents de conception correspondants et, plus précisément, seulement aux éléments constituant des “œuvres originales au sens du code de la propriété intellectuelle” (“original works of authorship” dans la loi étasunienne) et non aux idées et fonctionnalités sous-jacentes. Ainsi, il n’est pas exactement clair quelles protections légales sont ou ne sont pas accessibles au travers l’usage de licences basées sur le copyright pour la protection des documents de conception. Cependant, l’usage de licences reste un moyen important de clarifier la manière dont vous voulez que les autres utilisent votre design.

Il y a deux types de licences libres ou open source: les licences copyleft (ou virales), qui exigent que les dérivés soient publiés sous les mêmes conditions, et les licences permissives, qui autorisent des modifications sans que celles-ci soient publiées en tant que open source hardware. Notez que la définition de l’open source hardware spécifie que toute modification et réusage à des fins commerciales doit être autorisée. Ainsi, n’utilisez pas de licence portant des clauses de non-modification ou d’interdiction d’usage commercial.

Exemples de licences copyleft largement répandues:

Exemples de licences permissives:

Il est une bonne pratique que d’inclure une copie de la licence de votre choix dans votre dépôt ou système de gestion de versions ainsi qu’une déclaration dans chaque fichier partagé (ou au moins dans le fichier README) spécifiant a minima l’auteur et l’année des dernières modifications non triviales ainsi que la licence applicable.

Publication

  • Fournissez un lien vers les documents de conception originaux de votre hardware sur le produit lui-même, son emballage ou sa notice d’utilisation.
  • Faites en sorte que vos documents de conception originaux soient simples à trouver.
  • Indiquez sur le produit un numéro de version ou une date de parution afin qu’il soit possible de faire le lien entre le produit physique et la documentation produit correspondante.
  • Appliquez le logo de l’open source hardware sur votre produit. Ce faisant, prêtez attention à ce qu’il soit clair à quels composants de votre produit ce logo fait référence (c’est-à-dire quels composants sont open source).
  • En général, indiquez clairement quels composants de votre produit sont open source et lesquels ne le sont pas.
  • Ne communiquez pas sur le fait que votre produit est open source tant que vos documents de conception originaux ne sont pas accessibles.

S’appuyer sur un hardware open source existant

  • Respectez les marques déposées.
  • Lorsque l’usage commercial d’un produit/matériel open source est explicitement autorisé, et si vous apportez des améliorations à ce produit, soyez encouragés à publier ces améliorations également en open source.
  • Partagez vos modifications et améliorations avec le créateur du produit auquel vous apportez ces modifications.
  • Soyez émotionnellement prêts à accepter que votre projet soit copié (à moins que votre marque déposée soit contrefaite, dans ce cas réagissez conformément à la législation sur la protection des marques déposées).

Dernière modification de la version originale (anglais): 18 avril 2013, liste de diffusion OSHWA, coordonné par David A. Mellis.

Version originale (anglais): 21 novembre 2013, Nathan Seidle et liste de diffusion OSHWA.

Version française (traduction de l’anglais): 13 avril 2015, Jérémy Bonvoisin.

Creative Commons License
Ces travaux sont publiés sous licence Creative Commons avec paternité et partage des conditions initiales à l’identique (BY-SA).