taler-merchant-demos

software-patents.html (74622B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/software-patents.en.html" -->
 
 <!--#include virtual="/server/header.fr.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="speeches" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Les brevets logiciels - Projet GNU - Free Software Foundation</title>
 
 <!--#include virtual="/philosophy/po/software-patents.translist" -->
 <!--#include virtual="/server/banner.fr.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.fr.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.fr.html" -->
 <div class="article reduced-width">
 <h2>Les brevets logiciels, obstacles au développement logiciel</h2>
 
 <address class="byline">par Richard Stallman</address>
 
 <div class="infobox">
 <p>L'original de ce texte est la transcription d'une conférence de Richard
 M. Stallman, donnée le 25 mars 2002 au <a
 href="https://www.cl.cam.ac.uk/">Laboratoire d'informatique</a> de
 l'Université de Cambridge et organisée par la <a
 href="https://www.fipr.org/">Foundation for Information Policy Research</a>.</p>
 <p>Transcription  (<a
 href="https://www.cl.cam.ac.uk/~mgk25/stallman-patents.html">version
 originale</a>) et <a
 href="//audio-video.gnu.org/audio/#patent-cambridge-2002-03-25">enregistrement
 audio</a> de Nicholas Hill. Mise en page HTML et liens de Markus Kuhn.</p>
 </div>
 <hr class="thin" />
 
 <p>
 Vous êtes peut-être familiers avec mon travail sur les <a
 href="/philosophy/free-sw.html">logiciels libres</a>. Cette conférence ne
 parle pas de cela. Elle aborde le <a
 href="https://web.archive.org/web/20150329103351/http://www.progfree.org/Patents/against-software-patents.html">mauvais
 usage de la législation</a> qui fait du développement logiciel une activité
 dangereuse. Il s'agit de ce qui arrive lorsque la législation sur les
 brevets est appliquée au domaine du logiciel.
 </p>
 
 <p>
 Ce n'est pas de brevets sur des logiciels que je vais parler. C'est une très
 mauvaise manière de définir cette conférence, une manière qui induit les
 gens en erreur, car il n'y est pas question de brevets sur des programmes
 particuliers. Si c'était le cas, cela ne changerait rien, ce serait
 essentiellement inoffensif. Il s'agit plutôt de la prise de brevets sur des
 <em>idées</em>. Chaque brevet couvre une certaine idée. Les <a
 href="https://web.archive.org/web/20150329143651/http://progfree.org/Patents/patents.html">brevets
 logiciels</a> sont des brevets qui couvrent des idées concernant le
 logiciel, des idées que vous utiliseriez dans le développement de
 logiciels. C'est ce qui en fait un obstacle dangereux pour tout le
 développement logiciel.
 </p>
 
 <p>
 Vous avez peut-être entendu des gens utiliser le terme « <a
 href="https://www.wipo.org/about-ip/en/">propriété
 intellectuelle</a> ». Comme vous pouvez le voir, ce terme est partial. Il
 présuppose que tout ce dont vous parlez doit être traité comme une sorte de
 propriété. Pourtant ce n'est qu'une des nombreuses options. Ce terme de
 « propriété intellectuelle » implique un jugement préconçu sur le domaine où
 vous évoluez, quel qu'il soit. Cela ne favorise ni la clarté de la pensée,
 ni l'ouverture d'esprit.
 </p>
 
 <p>
 Il a un problème supplémentaire qui n'a rien à voir avec la promotion d'une
 quelconque opinion. Il fait obstacle à la compréhension même des faits. Le
 terme « propriété intellectuelle » est un fourre-tout. Il englobe des
 branches du droit absolument disparates tels que le copyright et les
 brevets, qui sont totalement différentes l'une de l'autre. Chaque détail
 diffère. Il met également dans le même panier les marques déposées qui en
 diffèrent encore plus, ainsi que diverses autres choses qu'on rencontre de
 temps en temps. Aucune n'a quoi que ce soit en commun avec les
 autres. Historiquement, elles ont des origines complètement distinctes.
 Les législations qui les régissent ont été conçues indépendamment. Elles
 couvrent des domaines de la vie et des activités différents. Les problèmes
 de politique publique qu'elles soulèvent n'ont aucun rapport entre
 eux. Aussi, si vous essayez de réfléchir à ces questions comme à un tout,
 vous êtes assuré d'en venir à des conclusions stupides. On ne peut
 littéralement pas avoir d'opinion intelligente et sensée sur la « propriété
 intellectuelle ». Si vous voulez réfléchir clairement, ne mélangez pas ces
 questions. Réfléchissez au copyright, puis aux brevets. Informez-vous sur le
 droit du copyright, puis, séparément, sur le droit des brevets.
 </p>
 
 <p>
 Voici quelques-unes des principales différences entre le copyright et les
 brevets. Le copyright couvre les détails de l'expression d'une œuvre, il ne
 couvre pas les idées ; les brevets au contraire ne concernent que les idées
 et l'utilisation des idées. Le copyright s'applique automatiquement alors
 que les brevets sont accordés par un office des brevets en réponse à une
 demande de brevet.
 </p>
 
 <p>
 Les brevets coûtent très cher. En fait, de payer les avocats qui rédigent la
 demande coûte encore plus cher que le dépôt lui-même. Cela prend typiquement
 quelques années pour qu'une demande soit prise en compte, bien que son
 examen par l'office des brevets soit extrêmement bâclé.
 </p>
 
 <p>
 Le copyright dure terriblement longtemps. Dans certains cas, il peut durer
 jusqu'à 150 ans, alors que les brevets ne s'appliquent que pendant 20 ans,
 ce qui est assez long pour qu'on leur survive, mais très long à l'échelle
 d'une spécialité telle que le logiciel.
 </p>
 
 <p>
 Reportez-vous 20 ans en arrière, lorsque le PC venait de naître. Imaginez en
 être réduit à développer des logiciels en utilisant seulement les idées qui
 étaient connues en 1982.
 </p>
 
 <p>
 Le copyright couvre le plagiat. Si vous écrivez un roman qui s'avère être
 mot pour mot identique à <cite>Autant en emporte le vent</cite> et que vous
 puissiez prouver que vous n'avez jamais vu le moindre exemplaire
 d'<cite>Autant en emporte le vent</cite>, cela pourrait être une défense
 contre une accusation d'infraction au copyright.
 </p>
 
 <p>
 Un brevet est un monopole absolu sur l'utilisation d'une idée. Même si vous
 pouviez prouver que vous avez eu l'idée par vous-même, cela serait
 totalement sans importance si l'idée était brevetée par quelqu'un d'autre.
 </p>
 
 <p>
 J'espère que vous oublierez le copyright pendant le reste de cette
 conférence, car elle traite des brevets. Ne mélangez jamais copyright et
 brevets. Il s'agit de votre compréhension de ces problèmes juridiques. Il
 lui arriverait la même chose qu'à votre compréhension de la chimie si vous
 confondiez l'eau et l'éthanol.
 </p>
 
 <p>
 Quand vous entendez quelqu'un décrire le système de brevets, il le décrit
 généralement du point de vue d'une personne qui espère obtenir un brevet
 – de ce que cela donnerait pour vous d'obtenir un brevet ; de ce que cela
 vous ferait de vous promener dans la rue avec un brevet en poche, de le
 sortir de temps en temps et de le brandir sous le nez de quelqu'un en
 disant : « Donnez-moi votre argent. » La raison de cette partialité, c'est
 que la plupart des gens qui vous parleront ainsi du système de brevets y ont
 un intérêt, c'est pourquoi ils veulent vous le faire apprécier.
 </p>
 
 <p>
 Il y a une autre raison : ce système ressemble beaucoup à une loterie, car
 seule une fraction ténue des brevets profite effectivement à leurs
 détenteurs. En fait, le journal <cite><a
 href="https://www.economist.com/leaders/2011/08/20/patent-medicine">The
 Economist</a></cite> l'a une fois comparé à une loterie chronophage. Si vous
 avez déjà vu des publicités pour des loteries, elles vous invitent toujours
 à penser que vous allez gagner. Elles ne vous suggèrent pas que vous aller
 perdre, même s'il est bien plus probable de perdre. Il en est de même avec
 les publicités pour le système de brevets. Elles vous invitent toujours à
 penser que vous gagnerez.
 </p>
 
 <p>
 Pour contrebalancer ce parti pris, je vais vous décrire le système de
 brevets du point de vue de ses victimes. C'est-à-dire du point de vue de
 quelqu'un qui veut développer un logiciel, mais qui est obligé d'affronter
 un système de brevets logiciels qui pourrait le conduire au procès.
 </p>
 
 <p>
 Alors, qu'est-ce que vous allez faire dès que vous aurez une idée du genre
 de programme que vous voulez écrire ? Ce que vous ferez d'abord, pour
 prendre en compte le système des brevets, c'est probablement d'essayer de
 découvrir les brevets qui pourraient s'appliquer à ce programme. C'est
 impossible, parce que les demandes de brevets en attente sont
 confidentielles. Après un certain temps, elles peuvent être publiées, disons
 18 mois. Mais cela vous donne largement le temps d'écrire un programme et
 même de le publier, sans savoir qu'il va y avoir un brevet et que vous allez
 être poursuivi.
 Ce n'est pas une hypothèse gratuite. En 1984, un programme de compression de
 données a été écrit : Compress. À l'époque, il n'y avait pas de brevet sur
 l'algorithme de compression LZW qu'il utilisait. Puis, en 1985, les
 États-Unis ont accordé un <a
 href="https://patents.justia.com/patent/4558302">brevet</a> sur cet
 algorithme et, quelques années plus tard, ceux qui distribuaient Compress
 ont commencé à recevoir des menaces. Il n'y avait aucun moyen pour son
 auteur de se rendre compte qu'il allait probablement être poursuivi. Tout ce
 qu'il avait fait était d'utiliser une idée trouvée dans une revue, comme les
 programmeurs l'ont toujours fait. Il n'avait pas réalisé qu'on ne pouvait
 plus utiliser les idées trouvées dans les revues en toute sécurité.
 </p>
 
 <p>
 Oublions ce problème. Les brevets accordés sont publiés par l'office des
 brevets de sorte que vous pouvez consulter leur longue liste pour voir
 exactement ce qu'ils disent. Bien sûr, vous ne pourriez pas vraiment lire
 tous les brevets listés, car il y en a beaucoup trop. Aux États-Unis, il y a
 des centaines de milliers de brevets logiciels.
 </p>
 
 <p>
 Il n'y a aucun moyen de se tenir au courant de ce dont ils traitent tous. Il
 faudrait donc essayer de rechercher les brevets pertinents. Certains disent
 que cela devrait être facile de nos jours avec les ordinateurs. Vous
 pourriez rechercher des mots-clés, etc. Cela marche jusqu'à un certain
 point. Vous trouverez quelques brevets dans votre spécialité. Cependant vous
 ne les trouverez pas nécessairement tous. Par exemple, il y avait un brevet
 logiciel qui doit avoir expiré maintenant, sur le « recalcul <a
 id="TransNote1-rev" href="#TransNote1"><sup>a</sup></a> dans l'ordre naturel
 dans les tableurs ».
 Ce qui signifie en gros que lorsque vous rendez certaines cellules
 dépendantes d'autres cellules, elles sont toutes recalculées  après les
 cellules dont elles dépendent, de sorte qu'un seul recalcul met tout à
 jour. Les premiers tableurs faisaient le recalcul du haut vers le bas ; donc
 si vous faisiez dépendre une cellule d'une autre située plus bas dans la
 feuille et que vous aviez plusieurs étapes similaires, vous deviez
 recalculer chaque cellule plusieurs fois pour que les nouvelles valeurs se
 propagent. Les cellules étaient censées dépendre de celles qui étaient
 situées au-dessus d'elles.
 Alors, quelqu'un s'est dit : « Pourquoi ne ferais-je pas le recalcul de
 sorte que tout soit recalculé en fonction des dépendances, quelle que soit
 la position dans la feuille ? » Cet algorithme est connu sous le nom de
 « tri topologique ». La première référence à cet algorithme que j'ai pu
 trouver date de 1963. Le brevet couvrait plusieurs dizaines de moyens
 différents de le mettre en œuvre, mais vous n'auriez pas pu trouver ce
 brevet en recherchant « tableur ». Vous n'auriez pas pu le trouver en
 recherchant « ordre naturel » ni « tri topologique ». Il ne contenait aucun
 de ces termes. En fait, il était décrit comme une méthode de compilation de
 formules en code objet. Quand je l'ai vu la première fois, j'ai pensé que ce
 n'était pas le bon brevet.
 </p>
 
 <p>
 Supposons que vous ayez une liste de brevets. Vous voulez donc savoir ce que
 vous n'êtes pas autorisé à faire. Quand vous essayez d'étudier ces brevets,
 vous découvrez qu'ils sont très difficiles à comprendre, car ils sont écrits
 dans un langage juridique tortueux, dont la signification est très dure à
 saisir. Ce que disent les offices de brevets ne veut souvent pas dire ce
 cela semble dire.
 </p>
 
 <p>
 Dans les années 80, le gouvernement australien a fait faire une étude sur le
 système de brevets. Elle concluait qu'à part la pression internationale il
 n'avait aucune raison d'être ; ce n'était pas bon pour le public et son
 abolition aurait été recommandée, n'était la pression internationale. L'un
 des arguments était que les ingénieurs n'essayent pas de lire les brevets
 pour apprendre quoi que ce soit, car ils sont trop difficiles à
 comprendre. L'étude citait un ingénieur qui disait : « Je ne reconnais pas
 mes propres inventions dans ce jargon. »
 </p>
 
 <p>
 Ce n'est pas seulement théorique. Aux environs de 1990, un programmeur du
 nom de <a
 href="https://www.atarimagazines.com/startv2n3/hypercard.html">Paul
 Heckel</a> a poursuivi Apple en revendiquant que HyperCard violait deux de
 ses <a href="https://patents.justia.com/patent/4486857">brevets</a>. Quand
 il avait vu HyperCard pour la première fois, il ne pensait pas que cela ait
 quoi que ce soit à voir avec ses brevets, avec ses « inventions ». Cela n'y
 ressemblait pas. Puis quand son avocat lui a dit que ses brevets pouvaient
 être interprétés comme couvrant une partie de HyperCard, il a décidé
 d'attaquer Apple.
 Lorsque j'ai fait une conférence à Stanford sur ce sujet, il était présent
 dans le public et a dit : « Ce n'est <a
 href="https://groups.csail.mit.edu/mac/classes/6.805/articles/int-prop/heckel-debunking.html">pas
 vrai</a>, je n'avais simplement pas compris l'étendue de ma protection ! »
 J'ai répondu : « Oui, c'est ce que j'ai dit ! » Donc, en fait, vous devrez
 passer beaucoup de temps à parler avec des avocats pour trouver ce que ces
 brevets vous interdisent de faire.
 Finalement, ils diront quelque chose de ce genre : « Si vous faites ceci,
 vous êtes sûr de perdre. Si vous faites cela, il y a de grandes chances que
 vous perdiez et, si vous voulez vraiment être tranquille, restez en dehors
 de ce domaine. Et à propos, il y a un facteur chance considérable dans
 l'issue de tout procès. »
 </p>
 
 <p>
 Maintenant que vous savez où vous mettez les pieds (!), qu'allez-vous
 faire ? Eh bien, il y a trois approches que vous pourriez essayer, dont
 chacune peut s'appliquer dans certains cas.
 </p>
 
 <p>Ce sont :</p>
 
 <ol>
 <li>éviter le brevet,</li>
 <li>obtenir une licence d'exploitation,</li>
 <li>faire invalider le brevet par un tribunal.</li>
 </ol>
 
 <p>
 Laissez-moi décrire ces trois approches et ce qui les rend réalisables ou
 irréalisables.
 </p>
 
 <h3>1) Éviter le brevet</h3>
 
 <p>
 Cela veut dire de ne pas utiliser l'idée couverte par le brevet. Cela peut
 être facile ou difficile, en fonction de ce sur quoi porte l'idée. Dans
 certains cas, c'est une fonctionnalité qui est brevetée. Alors, vous évitez
 le brevet en ne mettant pas en œuvre cette fonctionnalité. Ensuite, cela
 dépend seulement de l'importance de la fonctionnalité. Dans certains cas,
 vous pouvez vous en passer. Il y a quelque temps, les utilisateurs du
 logiciel de traitement de texte XyWrite ont reçu une mise à jour régressive
 par courrier. Cette mise à jour supprimait une fonctionnalité qui permettait
 de prédéfinir des abréviations. Cela veut dire que si vous tapiez une
 abréviation suivie d'un caractère de ponctuation, elle était immédiatement
 remplacée par une extension.
 Ainsi, vous pouvez définir une abréviation pour une phrase longue, taper
 l'abréviation, et alors la phrase longue s'insérait dans le document. Ils
 m'écrivirent à ce sujet, car ils savaient que l'éditeur <a
 href="/software/emacs/">Emacs</a> offrait une fonctionnalité similaire. En
 fait, c'était le cas depuis les années 70. C'était intéressant, car cela m'a
 montré que j'avais eu au moins une idée brevetable dans ma vie. Je sais
 qu'elle était brevetable parce que quelqu'un d'autre l'a brevetée plus
 tard !
 En fait, ils avaient essayé ces différentes approches. D'abord ils
 essayèrent de négocier avec le détenteur du brevet, qui fit preuve de
 mauvaise foi. Puis, ils cherchèrent à savoir s'ils avaient une chance de
 faire invalider le brevet. Ce qu'ils décidèrent de faire, c'est d'ôter la
 fonctionnalité. Vous pouvez vous en passer ; s'il ne manque que celle-là au
 traitement de texte, les gens continueront peut-être à l'utiliser. Mais au
 fur et à mesure que diverses fonctionnalités sont touchées, vous arrivez
 finalement à un programme dont les gens pensent qu'il n'est pas très bon et
 il est probable qu'ils le rejettent. Il s'agit d'un brevet de portée assez
 étroite, sur une fonctionnalité très spécifique.
 </p>
 
 <p>
 Que faites-vous du <a
 href="https://patents.justia.com/patent/4873662">brevet British Telecom</a>
 sur les liens hypertexte utilisés en conjonction avec un accès téléphonique
 commuté ? Les liens hypertexte sont absolument essentiels à la plupart des
 utilisations d'un ordinateur de nos jours. Et les accès par ligne commutée
 sont également essentiels. Comment feriez-vous sans cette fonctionnalité
 (qui, soit dit en passant, n'est même pas une fonctionnalité unique, mais
 seulement la combinaison de deux d'entre elles juxtaposées arbitrairement,
 un peu comme d'avoir un canapé et une télévision dans la même pièce) ?
 </p>
 
 <p>
 Quelquefois, l'idée qui est brevetée sera tellement large et basique qu'elle
 régira un domaine tout entier. Par exemple, l'idée de chiffrement à clé
 publique qui a été brevetée aux États-Unis. Le brevet a expiré en
 1997. Jusque-là, il bloquait presque entièrement l'utilisation du
 chiffrement à clé publique aux États-Unis. De nombreux programmes que les
 gens ont commencé à développer furent anéantis. Ils ne furent jamais
 vraiment disponibles, car les détenteurs du brevet les menaçaient.
 Puis, un programme y échappa : <a
 href="https://web.archive.org/web/20170315023711/http://www.pgpi.org/">PGP</a>,
 qui a été initialement publié comme logiciel libre. Il semble que les
 détenteurs du brevet, alors qu'ils se préparaient à attaquer, réalisèrent
 que cela leur ferait peut-être trop de mauvaise publicité. Ils imposèrent
 alors des restrictions pour que PGP soit à usage non commercial seulement,
 ce qui signifiait qu'il n'aurait pas un trop grand succès. Ils limitèrent
 ainsi grandement l'utilisation du chiffrement à clé publique pour une
 décennie ou plus. Il n'y avait pas moyen de contourner ce brevet. On ne
 pouvait rien faire d'autre.
 </p>
 
 <p>
 Quelquefois c'est un algorithme spécifique qui est breveté. Par exemple, il
 y a un brevet sur une version optimisée de la transformation rapide de
 Fourier (<abbr title="Fast Fourier Transform">FFT</abbr>). Elle s'exécute
 environ deux fois plus vite. Vous pouvez contourner cela en utilisant la FFT
 ordinaire dans votre programme. Cette partie du programme prendra deux fois
 plus de temps. Peut-être que cela n'a pas vraiment d'importance, peut-être
 est-ce une petite partie du temps d'exécution. Peut-être que si elle est
 deux fois plus lente, vous ne le remarquerez même pas. Mais cela peut aussi
 vouloir dire que votre programme ne fonctionnera pas, car il sera deux fois
 trop lent. Les effets sont variables.
 </p>
 
 <p>
 Dans certains cas, vous pouvez trouver un meilleur algorithme. Cela peut, ou
 non, être bénéfique pour vous. Puisque nous ne pouvions pas utiliser
 Compress dans le projet GNU, nous avons commencé à chercher d'autres
 algorithmes pour la compression de données. Quelqu'un nous écrivit en disant
 qu'il en avait un. Il avait écrit un programme et décidé de nous
 l'offrir. Nous étions sur le point de le publier quand, par hasard, je suis
 tombé sur un exemplaire du New York Times dans lequel il y avait la rubrique
 hebdomadaire des brevets – je regardais le Times moins d'une fois par
 mois. Je l'ai lue, et elle disait que quelqu'un avait obtenu un brevet pour
 « l'invention d'une nouvelle méthode de compression de données ».
 Je me suis dit qu'il valait mieux jeter un œil à ce brevet. J'en ai obtenu
 une copie et il s'avéra qu'il couvrait le programme que nous étions juste à
 une semaine de publier. Ce programme a été tué dans l'œuf. Plus tard, nous
 avons trouvé un autre algorithme qui n'était pas breveté. Cela devint le
 programme <a href="/software/gzip/">Gzip</a>, qui est à présent le standard
 de facto pour la compression de données. En tant qu'algorithme à utiliser
 dans un programme pour la compression de données, c'était un
 succès. Quiconque voulait faire de la compression de données pouvait
 utiliser Gzip plutôt que Compress. Mais ce même algorithme de compression
 breveté, LZW, était aussi utilisé dans des formats d'image comme <a
 href="/philosophy/gif.html">GIF</a>.
 Le but n'était pas simplement de compresser des données, mais de faire des
 images que les gens pourraient afficher dans leurs logiciels, il se révéla
 donc extrêmement difficile de passer à un algorithme différent. Nous n'avons
 pas été capables de le faire en 10 ans ! Oui, un <a
 href="https://www.w3.org/Graphics/PNG/">autre format d'image</a> a été
 défini à partir de l'algorithme Gzip lorsque les gens ont commencé à être
 menacés de poursuites judiciaires pour l'utilisation de fichiers GIF. Quand
 nous avons commencé à leur dire d'arrêter de les utiliser, de passer aux
 fichiers PNG, ils répondaient : « Nous ne pouvons pas changer. Les
 navigateurs ne gèrent pas encore le nouveau format. » Et les développeurs de
 navigateurs disaient de leur côté : « Il n'y a pas urgence. Après tout,
 personne n'utilise ce format de fichier. »
 </p>
 
 <p>
 Au final, il y avait tant d'inertie dans la société pour l'utilisation du
 format GIF que nous n'avons pas été capables d'obtenir des gens qu'ils
 changent. Pratiquement, l'utilisation dans la communauté du format GIF
 pousse encore les sites à utiliser ce format avec comme résultat qu'ils sont
 vulnérables à ces menaces de procès.
 </p>
 
 <p>
 En réalité, la situation est encore plus bizarre. Il y a en fait deux
 brevets couvrant l'algorithme de compression LZW. L'office des brevets ne
 pouvait même pas dire qu'il était en train d'accorder deux brevets sur la
 même chose. Il n'arrivait pas à suivre. Il y a une raison à cela : cela
 prend du temps d'étudier deux brevets pour voir s'ils couvrent réellement la
 même chose.
 </p>
 
 <p>
 S'il s'agissait de brevets sur un processus chimique, ce serait beaucoup
 plus facile. Vous pourriez voir quelles substances sont utilisées, ce qui
 est introduit dans le réacteur, ce qui en sort, quels procédés physiques
 sont employés. Peu importe la façon dont ils sont décrits, vous verriez ce
 qu'ils sont et vous verriez qu'ils sont similaires.
 </p>
 
 <p>
 Si une chose est purement mathématique, les diverses manières de la décrire
 diffèrent beaucoup plus entre elles. À première vue elles n'ont pas de
 similarité. Vous devez réellement les comprendre pour voir si cela parle de
 la même chose. L'office des brevets n'a pas le temps de le faire. L'Office
 américain des brevets et des marques (<abbr title="United States Patent and
 Trademark Office">USPTO</abbr>), il y a quelques années, passait en moyenne
 17 heures par brevet. Ce n'est pas assez pour faire un examen approfondi ;
 donc, bien sûr, ils commettent des erreurs comme celle-là. Je vous ai parlé
 du programme mort-né. En fait, cet algorithme est également couvert par deux
 brevets aux États-Unis. Apparemment, ce n'est pas inhabituel.
 </p>
 
 <p>
 Éviter les brevets peut être facile, ou impossible. Cela peut être facile
 mais cela rend votre programme inutile. C'est fonction de la situation.
 </p>
 
 <p>
 Voici un autre point que je dois mentionner : quelquefois une société ou un
 consortium peut faire d'un format ou d'un protocole le standard de
 facto. Alors, si ce format ou ce protocole est breveté, c'est un vrai
 désastre pour vous. Il y a même des standards officiels qui sont restreints
 par des brevets. Il y a eu un tollé en septembre dernier quand le <a
 href="https://www.w3.org/TR/patent-practice/">World Wide Web Consortium</a>
 a proposé l'adoption de standards qui étaient couverts par des brevets. La
 communauté a objecté et ils ont donc fait marche arrière.
 Ils en sont venus à insister sur le fait que tout brevet devait pouvoir être
 librement mis en œuvre par quiconque et que chacun devait être libre
 d'implémenter les standards. C'est une victoire intéressante. Je pense que
 c'est la première fois qu'un organisme de standardisation prend cette
 décision. Il est habituel pour les organismes de standardisation de vouloir
 mettre dans un standard une chose qui est restreinte par des brevets et que
 les gens ne sont pas autorisés à implémenter librement. Nous devons aller
 trouver les autres organismes de standardisation pour les appeler à changer
 leurs règles.
 </p>
 
 <h3>2) Obtenir une licence d'exploitation</h3>
 
 <p>
 La seconde possibilité, au lieu d'éviter le brevet, est d'obtenir une
 licence. Cette option ne vous est pas nécessairement ouverte. Le détenteur
 du brevet n'est pas obligé de vous offrir une licence, ce n'est pas
 requis. Il y a 10 ans, la <i>League for Programming Freedom</i> (Ligue pour
 la liberté de programmer) a reçu une lettre demandant de l'aide, provenant
 de quelqu'un dont la société familiale fabriquait des machines à sous pour
 les casinos – machines qui, à l'époque, fonctionnaient à l'aide
 d'ordinateurs. Il avait reçu une menace d'une autre société qui disait :
 « Nous avons les brevets pour ces trucs. Vous n'êtes pas autorisés à les
 fabriquer. Fermez boutique. »
 </p>
 
 <p>
 J'ai regardé le brevet. Il couvrait : « mettre des ordinateurs en réseau
 pour des jeux, de telle sorte que chaque ordinateur gère plus d'un jeu et
 permette de jouer à plus d'un jeu à la fois ».
 </p>
 
 <p>
 Vous vous apercevrez que l'office des brevets considère vraiment comme
 génial de faire plus d'une chose à la fois. Ils ne réalisent pas qu'en
 informatique, c'est la façon la plus évidente de généraliser quoi que ce
 soit. Si vous l'avez fait une fois, vous pouvez le faire autant de fois que
 vous le voulez en écrivant un sous-programme. Ils pensent que si vous faites
 quelque chose plus d'une fois, cela signifie que vous devez être génial et
 que vraiment personne ne peut vous contredire, que vous avez le droit de
 donner des ordres à tout le monde. En fin de compte, on ne lui a pas proposé
 de licence. Il devait fermer, il ne pouvait vraiment pas se permettre
 d'aller en justice. Je dirais que ce brevet particulier était une idée
 évidente. Il est possible qu'un juge ait pu en être d'accord, mais nous ne
 le saurons jamais, car il ne pouvait pas se permettre d'aller au procès.
 </p>
 
 <p>
 Cependant, beaucoup de détenteurs de brevets proposent des licences. Ils
 demandent souvent beaucoup d'argent en échange. La société qui détenait le
 brevet du recalcul en ordre naturel exigeait 5% des ventes brutes de chaque
 tableur aux États-Unis. On m'a dit que c'était le tarif réduit d'avant le
 procès. Si vous alliez au procès et qu'ils gagnent, ils exigeaient
 plus. Vous pourriez vous permettre de donner 5% pour la licence de ce
 brevet-là, mais que faire si, pour votre programme, vous aviez besoin de
 licences pour 20 brevets différents ? Alors, tout ce que vous gagneriez
 irait dans les brevets. Et si vous aviez besoin de licences pour
 21 brevets ?
 </p>
 
 <p>
 Des chefs d'entreprise m'ont dit qu'en pratique, deux ou trois rendraient
 une affaire non viable.
 </p>
 
 <p>
 Il y a une situation où les licences de brevets sont une très bonne
 solution : si vous êtes une très grosse multinationale. Car ces sociétés
 possèdent beaucoup de brevets et font des licences croisées entre elles. De
 cette façon, elles échappent à la plupart des dommages occasionnés par le
 système de brevets et n'en prennent que le bon côté. IBM a publié un <a
 href="https://web.archive.org/web/20150329104135/http://progfree.org/Links/prep.ai.mit.edu/ibm.think.article">article</a>
 sur son portefeuille de brevets dans le magazine <cite>Think</cite> (je
 crois que c'était le numéro 5 de l'année 1990). L'article disait qu'IBM
 obtenait deux sortes de profits de ses 9 000 brevets américains (je pense
 que le nombre est plus important aujourd'hui) ; le premier était de
 percevoir des royalties, et le second d'avoir accès aux brevets des
 autres. Il disait aussi que le second était supérieur d'un ordre de grandeur
 au premier. En d'autres termes, le bénéfice qu'IBM retirait d'être autorisée
 à utiliser les idées brevetées par d'autres était 10 fois supérieur au
 profit direct qu'elle tirait des licences qu'elle accordait sur ses propres
 brevets. Qu'est-ce que cela signifie réellement ?
 </p>
 
 <p>
 Quel est le bénéfice pour IBM d'avoir accès aux brevets des autres ? C'est
 en fait le bénéfice d'échapper aux ennuis que peut causer le système de
 brevets. Ce système ressemble à une loterie. Prenons un brevet
 particulier. Qu'est-ce qui peut en sortir ? Peut-être rien, peut-être une
 aubaine pour le détenteur du brevet ou un désastre pour quelqu'un
 d'autre. Mais IBM est si grande que pour elle, cela s'équilibre. Elle donne
 une idée de la moyenne entre les dommages et les bénéfices qui découlent du
 système de brevets.
 Pour elle, les ennuis auraient été 10 fois supérieurs aux bénéfices. Je dis
 <em>auraient été</em>, car IBM, en négociant des licences croisées, évite
 d'avoir à affronter les ennuis. Ces ennuis sont seulement potentiels. Ils ne
 se produisent pas vraiment. Mais IBM estime le bénéfice d'avoir évité ces
 ennuis à 10 fois la valeur de l'argent qu'elle retire de ses propres
 brevets.
 </p>
 
 <p>
 Ce phénomène des licences croisées réfute une légende répandue, la légende
 du génie-qui-meurt-de-faim, celle qui dit que les brevets « protègent » le
 « petit inventeur ». Ces termes sont des termes de propagande. Vous ne
 devriez pas les utiliser. Le scénario se présente comme ceci : supposez
 qu'il y ait un brillant inventeur de quelque chose. Supposez qu'il ait passé
 des années à mourir de faim dans son grenier pour concevoir un
 truc-formidable d'un nouveau genre et qu'il veuille maintenant le
 fabriquer ; n'est-ce pas une honte que les grosses sociétés entrent en
 concurrence avec lui, le privant de son marché, et qu'il « meure de faim » ?
 Je voudrais faire remarquer que, dans le domaine des hautes technologies,
 les gens ne travaillent généralement pas seuls dans leur coin et les idées
 ne viennent pas du néant ; elles sont basées sur les idées d'autres
 personnes. De nos jours, ces inventeurs ont de très fortes chances d'obtenir
 un travail s'ils en ont besoin. Aussi, ce scénario, la notion qu'une idée
 géniale vienne à l'esprit de cette personne brillante travaillant seule est
 irréaliste, tout comme la notion qu'elle serait en danger de mourir de
 faim. Mais il est concevable que quelqu'un puisse avoir une idée, que cette
 idée, combinée avec 100 ou 200 autres, puisse servir à faire un produit, et
 que de grosses sociétés puissent vouloir lui faire concurrence.
 Alors voyons ce qui arrive s'il essaie d'utiliser un brevet pour les
 arrêter. Il dit : « Oh non, IBM. Vous ne pouvez pas me concurrencer. J'ai ce
 brevet. » Et IBM répond : « Voyons cela. Regardons votre produit. Humm, j'ai
 ce brevet-ci et celui-ci, et celui-ci et celui-ci et celui-ci et celui-ci et
 encore celui-ci, que certaines parties de votre produit enfreignent. Si vous
 pensez que vous pouvez vous battre contre tous ces brevets au tribunal,
 j'irai en chercher d'autres. Alors, pourquoi ne pas négocier des licences
 croisées ? » Et ensuite, ce brillant petit inventeur dit : « Bien, d'accord,
 nous croiserons nos licences. » Alors il peut rentrer et faire son
 truc-formidable, mais IBM aussi. IBM a accès à son brevet et a le droit de
 le concurrencer, ce qui signifie que ce brevet n'a pas du tout « protégé »
 l'inventeur. Le système de brevets ne fait pas vraiment ça.
 </p>
 
 <p>
 Les très grosses sociétés évitent la plupart des dégâts provoqués par le
 système de brevets. Elles en voient surtout le bon côté. C'est pourquoi
 elles veulent avoir des brevets logiciels. Ce sont celles qui en
 bénéficient. Mais si vous êtes un petit inventeur ou que vous travaillez
 pour une petite société, la petite société ne sera pas capable de faire
 cela. Elles essaient. Le problème est qu'elles ne peuvent pas obtenir assez
 de brevets pour que ça marche. Chaque brevet pointe dans une certaine
 direction. Donc, si une petite société a des brevets qui pointent ici, là et
 là et que quelqu'un les menace de par là-bas avec un de ses brevets en
 disant « Donnez-moi votre argent », ils sont impuissants.
 IBM peut le faire grâce à ses 9 000 brevets ; ils pointent de tous les
 côtés ; peu importe où vous vous situez, il y a probablement un brevet IBM
 pointé vers vous. C'est pourquoi IBM peut presque toujours faire des
 licences croisées. Les petites sociétés ne peuvent faire cela
 qu'occasionnellement. Elles diront qu'elles veulent des brevets pour se
 défendre, mais elles ne pourront pas en obtenir suffisamment pour le faire.
 </p>
 
 <p>
 Il y a un cas où même IBM ne peut pas faire de licences croisées : quand il
 y a une société dont le seul commerce est de prendre un brevet pour
 extorquer de l'argent aux gens. La société qui possédait le brevet du
 recalcul en ordre naturel est exactement ce genre de société. Son seul
 commerce est de menacer les gens de procès et de faire payer les gens qui
 font réellement du développement.
 </p>
 
 <p>
 Il n'y a pas de brevet sur les procédures juridiques. Je pense que les
 avocats savent la difficulté que ce serait d'avoir à traiter avec le système
 de brevets eux-mêmes. Il n'y a donc aucun moyen d'obtenir un brevet pour
 forcer cette société à faire des licences croisées. Alors, elle extorque
 tout le monde alentour. Mais je pense que des sociétés comme IBM se disent
 que c'est le prix à payer et s'en accommodent.
 </p>
 
 <p>
 Voilà pour la possibilité d'obtenir une licence de brevet. C'est faisable ou
 ça ne l'est pas, et vous pouvez, ou non, vous le permettre.
 </p>
 
 <h3>3) Faire invalider le brevet par un tribunal</h3>
 
 <p>
 Afin d'obtenir un brevet, l'invention proposée est censée être « nouvelle,
 utile et non évidente ». C'est la formulation utilisée aux États-Unis. Je
 pense que les autres pays utilisent une formulation différente, mais qui en
 est très proche. Bien sûr, quand l'office des brevets entre en jeu, ils
 commencent par interpréter « nouveau » et « non évident ». « Nouveau »
 signifie concrètement « nous ne l'avons pas dans nos fichiers » et « non
 évident » a tendance à signifier « non évident pour quelqu'un avec un
 Q.I. de 50 ».
 </p>
 
 <p>
 Une personne qui étudie la plupart des brevets accordés aux États-Unis, ou
 du moins, qui le faisait – je ne sais pas si elle arrive toujours à les
 suivre – a dit que 90% d'entre eux se feraient coller au « test de Crystal
 City », ce qui voulait dire que si quelqu'un de l'office des brevets sortait
 et allait chez le marchand de journaux acheter quelques magazines
 d'informatique, il verrait que ces idées sont déjà connues.
 </p>
 
 <p>
 L'office des brevets fait des choses si manifestement stupides que vous
 n'avez pas besoin de connaître l'état de la technique pour voir que c'est
 stupide. Ce n'est pas limité au logiciel. J'ai vu une fois le fameux brevet
 sur la souris de Harvard qui a été obtenu après que des chercheurs de
 Harvard aient génétiquement modifié une lignée de souris avec un gène
 provoquant le cancer. Le gène en question était déjà connu et était inséré
 selon des méthodes connues sur une lignée de souris existante. Le brevet
 qu'ils ont obtenu couvrait l'introduction d'un gène provoquant le cancer
 chez n'importe quel type de mammifère, quelle que soit la méthode
 utilisée. Vous n'avez pas besoin de connaître quoi que ce soit en
 manipulation génétique pour réaliser que c'est ridicule.
 </p>
 
 <p>
 On m'a dit que cette surenchère de revendication est une pratique normale et
 que l'USPTO invite parfois les demandeurs à étendre leur revendication – ce
 qui veut dire étendre leur revendication jusqu'à ce qu'ils pensent qu'elle
 empiète sur quelque chose qui représente sans ambiguïté l'état antérieur de
 la technique, voir combien de terre on leur laissera confisquer dans
 l'espace mental.
 </p>
 
 <p>
 Quand des programmeurs regardent des brevets, ils disent pour beaucoup
 d'entre eux : « Mais c'est ridiculement <a
 href="https://web.archive.org/web/20040604051644/http://people.qualcomm.com/karn/patents/patent-comments.html">évident</a> ! »
 Les bureaucrates des brevets ont toutes sortes d'excuses pour justifier leur
 dédain de ce que pensent les programmeurs. Ils disent : « Oh ! Mais vous
 devez considérer cela en vous plaçant 10 ou 20 ans en arrière. » Ils ont
 découvert qu'à force de disséquer les choses vous pouviez finalement perdre
 vos repères. N'importe quoi peut paraître non évident si vous le décortiquez
 ou si vous l'analysez suffisamment. Vous perdez tout simplement votre bon
 sens ou du moins votre capacité à décider de ce qui est évident et de ce qui
 ne l'est pas. Ensuite, bien sûr, ils décrivent les détenteurs de brevets
 comme de brillants inventeurs, tous. Par conséquent, nous ne pouvons pas
 remettre en question leur droit à exercer leur pouvoir sur ce que nous
 pouvons faire.
 </p>
 
 <p>
 Si vous allez en justice, les juges seront probablement un peu plus
 rigoureux sur la notion de non-évidence. Mais le problème, c'est que cela
 coûte des millions de dollars. J'ai entendu parler d'une affaire de brevet,
 je me rappelle que le défendeur était Qualcomm, et je crois que la décision
 de la cour fut 13 millions dollars dont la plus grande partie pour payer les
 honoraires des avocats des deux côtés. Il restait quelques millions de
 dollars pour le plaignant, car ils avaient perdu.
 </p>
 
 <p>
 Dans une large mesure, la question de la validité d'un brevet dépendra
 d'aléas historiques. Des hasards historiques tels que : ce qui a été publié
 précisément, et quand ; quelles publications on réussit à retrouver ;
 lesquelles n'ont pas été perdues ; les dates précises, etc. Beaucoup d'aléas
 historiques définissent si un brevet est valide.
 
 En fait, c'est bizarre que le <a
 href="https://patents.justia.com/patent/4873662">brevet de British Telecom
 pour suivre les hyperliens avec un accès téléphonique</a> ait été demandé,
 en 1975 je crois. Je pense que c'est en 1974 que j'ai commencé à développer
 le paquet Info. Il permet de traverser les hyperliens, et les gens
 utilisaient effectivement des téléphones pour se connecter au système. Donc
 en fait, cela faisait partie de l'état antérieur de la technique pour ce
 brevet. C'est donc la deuxième idée brevetable que j'ai eue dans ma vie,
 mais je ne crois pas en avoir la preuve. Je ne pensais pas que c'était
 suffisamment intéressant pour la publier. Après tout, j'ai eu l'idée de
 suivre les hyperliens suite à une démo de l'éditeur d'Engelbart. C'était lui
 qui avait une idée intéressante à publier.
 J'ai appelé ce que j'ai fait « l'hypertexte du pauvre », car j'avais à
 l'implémenter dans le contexte de TECO.<a id="TransNote2-rev"
 href="#TransNote2"><sup>b</sup></a> Ce n'était pas aussi puissant que son
 hypertexte, mais c'était au moins utile pour naviguer dans la documentation,
 ce qui était le but ; et pour ce qui est des accès téléphoniques, eh bien,
 il y en avait, mais il ne m'est pas venu à l'esprit que cela avait quelque
 chose à voir avec le reste. Je n'allais pas publier un papier disant :
 « Oh ! J'ai implémenté cet hypertexte du pauvre, et devinez quoi ! Il y a
 aussi des lignes téléphoniques sur l'ordinateur ! » Je suppose que je n'ai
 aucun moyen de dire précisément à quelle date je l'ai fait. Était-ce publié
 d'une manière ou d'une autre ? En fait, nous avons invité des gens à se
 connecter sur notre machine par ARPAnet, pour qu'ils puissent naviguer dans
 la documentation avec la commande <code>info</code> et voir ce qu'il y avait
 là. S'ils nous l'avaient demandé, ils auraient constaté que nous avions un
 accès téléphonique. Donc, comme vous pouvez le voir, c'est le hasard
 historique qui détermine si vous avez l'antériorité sur l'invention.
 </p>
 
 <p>
 Maintenant, bien sûr, il y a une publication faite par Engelbart sur
 l'hypertexte, qu'ils vont produire au tribunal. Je ne pense pas que cela
 dise quoi que ce soit sur le fait d'avoir une connexion téléphonique sur
 l'ordinateur, cependant. Cela suffira-t-il ? On n'en sait rien. Ainsi, aller
 en justice pour faire invalider le brevet est une option.
 </p>
 
 <p>
 À cause de la dépense, c'est souvent hors de question même si vous pouvez
 trouver une preuve indiscutable de réalisation antérieure qui serait
 suffisante pour faire invalider le brevet. En conséquence, un brevet
 invalide, c'est-à-dire un brevet qui n'aurait pas dû exister (mais en fait
 c'est le cas pour beaucoup d'entre eux) est une arme dangereuse. Si
 quelqu'un vous attaque avec un brevet invalide, cela peut vraiment vous
 causer beaucoup de problèmes. Vous pourriez les bluffer en leur montrant une
 réalisation antérieure et peut-être qu'ils vous laisseraient tranquille. Ça
 dépend si ce serait capable de les effrayer ou s'ils penseraient : « Bien,
 vous bluffez, nous pensons que vous ne pouvez pas vraiment vous permettre
 d'aller en justice, donc nous vous poursuivrons de toute façon. »
 </p>
 
 <p>
 Vous pouvez quelquefois réussir à utiliser ces trois possibilités, mais
 souvent ce n'est pas le cas. Alors vous devez affronter brevet après brevet
 après brevet. Chaque fois, vous pouvez être en mesure d'utiliser une des
 trois possibilités, mais alors il y a un autre brevet puis un autre et un
 autre. C'est comme traverser un champ de mines. Chaque pas que vous faites,
 chaque décision de conception, ne tombera probablement pas sur un brevet ;
 vous pouvez alors avancer de quelques pas et il n'y aura probablement pas
 d'explosion. Mais la probabilité que vous avez de traverser le champ de
 mines pour développer le programme que vous voulez sans marcher sur un
 brevet s'amenuisera à mesure que le programme grossit.
 </p>
 
 <p>
 Les gens me disent souvent : « Bon, il y a des brevets dans d'autres
 domaines, pourquoi le logiciel devrait-il en être exempté ? » Remarquez la
 bizarre supposition qui dit que, d'une manière ou d'une autre, nous sommes
 tous censés souffrir du système de brevets. C'est comme de dire :
 « Certaines personnes ont le cancer. Pourquoi ne l'auriez-vous pas ? » De
 mon point de vue, c'est une bonne chose que quelqu'un n'ait pas le
 cancer. Mais il y a derrière cela une question moins partiale, une question
 importante : « Le logiciel est-il différent des autres spécialités ? La
 politique des brevets devrait-elle être différente pour différentes
 spécialités ? Si oui, pourquoi ? »
 </p>
 
 <p>
 Permettez-moi de répondre à cette question. Les brevets affectent les
 diverses spécialités différemment, car dans ces diverses spécialités le
 rapport des brevets aux produits est différent.
 </p>
 
 <p>
 D'un côté nous avons des produits pharmaceutiques où une formule chimique
 donnée est brevetée et donc le brevet ne couvre qu'un seul produit. Un autre
 produit ne serait pas couvert par le brevet existant. S'il devait y avoir un
 brevet pour ce nouveau produit, le détenteur du brevet serait celui qui l'a
 développé.
 </p>
 
 <p>
 Cela cadre avec la notion naïve que, dans le système de brevets que nous
 avons, si vous développez un nouveau produit, vous obtiendrez « Le Brevet »
 – la notion qu'il y a un brevet par produit et qu'il couvre l'idée de ce
 produit. Dans certaines spécialités, c'est presque vrai. Dans d'autres,
 comme le logiciel, on en est loin. C'est parce que les paquets logiciels
 sont habituellement très gros. Ils utilisent des combinaisons originales de
 nombreuses idées différentes. Si le programme est nouveau, pas seulement la
 copie d'un autre, alors il est probable qu'il utilise une combinaison
 différente d'idées, associées, bien sûr, à du code nouvellement écrit, parce
 qu'on ne peut pas lancer comme ça des idées et comme par magie les voir
 fonctionner. Il faut toutes les implémenter.
 Vous devrez toutes les mettre en œuvre dans cette combinaison. Il en résulte
 qu'au cours de l'écriture d'un programme, vous utilisez beaucoup d'idées
 différentes dont n'importe laquelle pourrait être brevetée par quelqu'un. La
 combinaison de deux idées pourrait être brevetée par quelqu'un. Il pourrait
 y avoir plusieurs façons différentes de décrire une idée qui pourraient être
 brevetées par diverses personnes. Donc il y a probablement des milliers de
 choses – des milliers de points de vulnérabilité dans votre programme – qui
 pourraient être déjà brevetées par quelqu'un d'autre. C'est pourquoi les
 brevets logiciels tendent à empêcher le progrès du logiciel – le travail de
 développement logiciel.
 </p>
 
 <p>
 S'il y avait un brevet par produit, alors ces brevets n'empêcheraient pas le
 développement de produits car, si vous développez un nouveau produit, il
 n'est pas déjà breveté par quelqu'un d'autre. Mais quand un produit
 correspond à l'association de beaucoup d'idées différentes, il est très
 probable que votre nouveau produit soit déjà breveté par quelqu'un
 d'autre. En fait, il y a une étude économique qui montre que d'imposer un
 système de brevets à une spécialité où l'innovation est incrémentale peut
 retarder le progrès.
 Les partisans des brevets logiciels disent : « Oui, il peut y avoir des
 problèmes, mais le plus important, c'est que les brevets doivent promouvoir
 l'innovation, et c'est si important que peu importe les problèmes qu'ils
 causent. » Bien sûr, ils ne disent pas ça très fort, car c'est ridicule,
 mais implicitement ils veulent vous faire croire que, tant que les brevets
 promeuvent le progrès, cela surpasse tous les coûts. Mais en fait, il n'y a
 aucune raison de croire que les brevets participent au progrès. Nous avons
 maintenant un modèle qui montre précisément comment les brevets peuvent
 retarder le progrès. Le cas où ce modèle peut s'appliquer correspond très
 bien au domaine du logiciel : l'innovation incrémentale.
 </p>
 
 <p>
 Pourquoi le logiciel est-il à cette extrémité du spectre ? C'est parce que
 dans le logiciel nous développons des objets mathématiques idéalisés. Vous
 pouvez bâtir un château compliqué et le faire reposer sur une ligne ténue et
 il restera debout, car il ne pèse rien. Dans d'autres spécialités, les gens
 doivent composer avec la perversité de la matière – des objets physiques. La
 matière fait ce qu'elle doit faire. Vous pouvez essayer de la modéliser et
 si son comportement réel ne s'ajuste pas au modèle, alors c'est dur pour
 vous, car votre défi est de réaliser des objets physiques qui fonctionnent
 vraiment.
 </p>
 
 <p>
 Si je veux mettre une condition <code>if</code> dans une boucle
 <code>while</code>, je n'ai pas à me soucier de savoir si <code>if</code>
 oscillera à une certaine fréquence, frottera contre <code>while</code> et si
 finalement les deux se briseront. Je n'ai pas à me soucier de savoir si elle
 oscillera à une haute fréquence particulière et induira un signal dans la
 valeur d'une autre variable. Je n'ai pas besoin de savoir combien de courant
 la condition <code>if</code> consommera et si elle peut dissiper la chaleur
 à l'intérieur de la boucle <code>while</code> ; ou s'il y aura une chute de
 tension dans la boucle <code>while</code> qui fera que la condition
 <code>if</code> ne fonctionnera pas.
 Si j'exécute ce programme dans un environnement d'eau salée, je n'ai pas à
 avoir peur que l'eau salée s'infiltre entre <code>if</code> et
 <code>while</code> et provoque une corrosion. Quand j'appelle une variable
 20 fois, je n'ai pas à avoir peur d'excéder sa limite de sortance
 <i>[fan-out]</i>. Quand j'appelle cette variable, je n'ai pas besoin de me
 soucier de sa capacitance ni de savoir si elle a eu suffisamment de temps
 pour charger sa valeur. Quand j'écris un programme, je n'ai pas à me soucier
 de savoir comment je vais assembler physiquement chaque copie et si j'ai
 accès à l'intérieur de la boucle <code>while</code> pour y introduire cette
 condition <code>if</code>. Je n'ai pas à me soucier de la manière de
 démonter <code>if</code> pour la remplacer au cas où elle casserait.
 </p>
 
 <p>
 Il y a tant de problèmes dont nous n'avons pas à nous soucier dans le
 logiciel ! Cela rend le développement logiciel fondamentalement plus
 facile. Il est beaucoup plus facile d'écrire un programme que de concevoir
 un objet physique qui fonctionne. Cela peut sembler étrange, car vous avez
 probablement entendu des gens dire combien il était difficile de concevoir
 un logiciel, quel gros problème c'était, et décrire la manière dont ils
 allaient le résoudre. Ils ne parlent pas vraiment de la même chose que
 moi. Je compare des systèmes physiques et logiciels de même complexité, de
 même nombre d'éléments. Je dis qu'un système logiciel est bien plus facile à
 concevoir qu'un système physique. Mais l'intelligence des gens dans ces
 divers domaines est la même, alors que faisons-nous quand nous sommes
 confrontés à un domaine facile ? Nous allons encore plus loin ! Nous
 poussons nos capacités à leurs limites.
 Si des systèmes de même taille sont faciles à concevoir, faisons alors des
 systèmes dix fois plus gros, alors ce sera difficile ! C'est ce que nous
 faisons ! Nous faisons des systèmes logiciels qui sont bien plus grands, en
 termes de nombre d'éléments, que les systèmes physiques. Un système physique
 dont la conception recèle un million d'éléments différents est un
 mégaprojet. Un programme d'ordinateur dont la conception recèle un million
 d'éléments fait peut-être 300 000 lignes ; quelques personnes écriront cela
 en deux ans. Ce n'est pas un programme particulièrement imposant. Je pense
 que GNU Emacs a maintenant quelques millions d'éléments. Il a un million de
 lignes de code. C'est un projet réalisé pour l'essentiel sans financement,
 par des personnes travaillant surtout pendant leur temps libre.
 </p>
 
 <p>
 Il y a une autre grosse source d'économie. Si vous avez conçu un produit
 matériel, ce que vous devez faire ensuite est de concevoir l'usine pour le
 fabriquer. Construire cette usine peut coûter des millions ou des dizaines
 de millions là où la copie du programme ne coûte que de taper
 <kbd>copy</kbd>. La même commande copiera n'importe quel programme. Vous
 voulez des copies sur CD ? Très bien. Vous gravez un CD master et vous
 l'envoyez à une usine de gravure de CD. Ils utiliseront le même équipement
 qui copiera n'importe quel contenu sur un CD. Vous n'avez pas besoin de
 bâtir une usine pour fabriquer ce produit. Il y a une énorme simplification
 et une énorme réduction des coûts.
 
 Prenons par exemple un constructeur automobile : il dépensera 50 millions de
 dollars pour bâtir l'usine, pour fabriquer un nouveau modèle de voiture,
 pour engager des avocats qui s'occuperont des négociations sur les licences
 de brevets. Ils pourraient même faire face à un procès s'ils le
 voulaient. Concevoir un programme de même complexité peut coûter 50 000 ou
 100 000 dollars. En comparaison, le traiter avec le système de brevets a un
 coût monumental. En fait, concevoir un programme de la même complexité que
 la conception mécanique d'une voiture prend probablement un mois. Combien
 d'éléments contient une voiture qui n'a pas d'ordinateur ? <a class="ftn"
 id="f1-rev" href="#f1">[1]</a>. Il n'y en a pas tant que ça. Cela ne veut
 pas dire qu'il soit facile de concevoir une bonne voiture, mais juste
 qu'elle ne contient pas tant que ça d'éléments différents.
 </p>
 
 <p>
 Le logiciel est vraiment différent des autres spécialités, car nous
 travaillons sur des objets mathématiques dont la conception est bien, bien
 plus facile, ce qui a pour résultat que nous faisons des systèmes qui sont
 bien, bien plus grands, et ceci avec seulement quelques personnes. Il en
 résulte qu'au lieu d'avoir quelque chose d'approchant un brevet par produit,
 nous sommes dans un système où un seul produit met en jeu une multitude
 d'idées qui pourraient déjà être brevetées.
 </p>
 
 <p>
 La meilleure façon de l'expliquer est par analogie avec les symphonies. Une
 symphonie est aussi une œuvre longue ; elle contient beaucoup de notes et
 utilise probablement beaucoup d'idées musicales. Imaginez si, au
 XVIIIe siècle, les gouvernements d'Europe avaient décidé de promouvoir la
 musique symphonique en établissant un Office européen des brevets musicaux
 qui aurait octroyé un brevet pour n'importe quelle idée musicale qui aurait
 pu se décliner en mots. Imaginez-vous alors aux environs de 1800, vous êtes
 Beethoven et vous voulez écrire une symphonie. Vous trouverez alors
 qu'écrire votre symphonie de sorte qu'elle ne viole pas de brevet va être
 plus difficile que d'écrire une bonne symphonie.
 
 Quand vous vous en plaindrez, les détenteurs de brevets vous diront : « Ah
 Beethoven, vous rouspétez car vous n'avez pas d'idées personnelles. Tout ce
 que vous voulez, c'est piquer nos inventions. » Beethoven avait beaucoup de
 nouvelles idées musicales, mais il a dû utiliser beaucoup d'idées existantes
 pour faire une musique reconnaissable, pour faire de la musique que les
 auditeurs puissent apprécier et qu'ils reconnaissent comme de la
 musique. Personne n'est assez génial pour réinventer la musique et faire
 quelque chose que les gens voudraient écouter. <a
 href="https://fr.wikipedia.org/wiki/Pierre_Boulez">Pierre Boulez</a> disait
 qu'il essaierait de le faire, mais qui écoute du Boulez ?
 </p>
 
 <p>
 Personne n'est assez génial pour réinventer l'informatique totalement. S'il
 le faisait, il ferait quelque chose que les utilisateurs trouveraient si
 étrange qu'ils ne voudraient pas l'utiliser. Si vous regardez un logiciel de
 traitement de texte aujourd'hui, vous trouverez, je pense, des centaines de
 fonctionnalités différentes. Si vous développez un joli traitement de texte
 innovant, cela signifie qu'il y a de nouvelles idées dedans, mais faut qu'il
 y ait aussi des centaines d'idées anciennes. Si vous n'avez pas le droit de
 les utiliser, vous ne pouvez pas faire de traitement de texte innovant.
 </p>
 
 <p>
 Il y a tant de travail de développement logiciel que nous n'avons pas besoin
 de système artificiel pour favoriser l'éclosion de nouvelles idées. Il y a
 juste des gens qui écrivent des logiciels et qui auront de nouvelles
 idées. Si vous voulez écrire un programme et que vous voulez qu'il soit bon,
 alors des idées vous viendront et vous trouverez un moyen de les
 utiliser. Ce qui se passait autrefois – car j'étais dans le domaine logiciel
 avant qu'il y ait des brevets logiciels – c'était que la plupart des
 développeurs publiaient toute nouvelle idée qu'ils jugeaient importante,
 dont ils pensaient qu'elle leur apporterait reconnaissance et respect.
 
 Les idées mineures ou pas assez importantes n'étaient pas publiées, car cela
 aurait été stupide. Le système de brevets est censé encourager la
 divulgation des idées. Mais en fait, autrefois, personne ne gardait les
 idées secrètes. On gardait le code secret, c'est vrai. Le code, après tout,
 représentait la majeure partie du travail. On gardait le code secret et on
 publiait les idées, pour que les salariés en aient le crédit et soient
 satisfaits. Depuis l'apparition des brevets logiciels, on garde toujours le
 code secret, mais on prend des brevets sur les idées ; en fait, rien de
 pertinent n'a été fait pour encourager leur divulgation. Les mêmes choses
 sont gardées secrètes maintenant qu'auparavant, mais les idées qui étaient
 publiées de sorte que l'on puisse les utiliser sont maintenant brevetées et
 hors d'atteinte pendant 20 ans. 
 </p>
 
 <p>
 Que peut faire un pays pour changer cela ? Comment doit-on modifier les
 règles pour résoudre ce problème ? On peut s'y attaquer à deux niveaux. Le
 premier est l'endroit où sont demandés et accordés les brevets, l'office des
 brevets. Le second est le champ d'application des brevets, c'est-à-dire la
 question de ce que peut couvrir un brevet.
 </p>
 
 <p>
 Changer les critères de délivrance des brevets, ou simplement conserver de
 bons critères, peut fonctionner dans un pays qui n'a pas autorisé les
 brevets logiciels auparavant, par exemple dans la plus grande partie de
 l'Europe. Se contenter de renforcer nettement les règles de l'Office
 européen des brevets qui disent que le logiciel n'est pas brevetable, ce
 serait une bonne solution pour l'Europe. L'Europe est en train d'examiner
 une directive sur les brevets logiciels. Je suppose que la directive est
 peut-être plus étendue que cela, mais l'une de ses implications importantes
 concerne les brevets logiciels. Modifier simplement la directive pour dire
 que les idées logicielles ne peuvent pas être brevetables préservera une
 grande partie de l'Europe de ce problème, exception faite de quelques pays
 qui peuvent avoir importé ce problème de leur côté. Malheureusement, l'un
 d'eux est le Royaume-Uni. Malheureusement pour vous.
 </p>
 
 <p>
 Cette approche ne fonctionnerait pas aux États-Unis, parce que les
 États-Unis ont déjà un grand nombre de brevets logiciels et que tout
 changement dans les critères de délivrance des brevets n'éliminera pas les
 brevets existants <a class="ftn" id="f2-rev" href="#f2">[2]</a>. En fait ces
 brevets ne sont pas officiellement étiquetés comme brevets logiciels. Je dis
 brevets logiciels, mais qu'est-ce que je veux vraiment dire ? Des brevets
 qui peuvent potentiellement s'appliquer aux logiciels ; des brevets qui
 pourraient potentiellement vous faire poursuivre en justice pour avoir écrit
 un logiciel.
 
 L'office des brevets ne les classe pas en brevets logiciels et autres
 brevets. Donc, il est concevable que tout brevet pourrait vous amener devant
 le tribunal pour avoir écrit du logiciel s'il pouvait s'appliquer à un
 logiciel. Aussi, aux États-Unis, la solution passerait par un changement des
 critères d'applicabilité, du champ d'application des brevets. On devrait
 dire qu'une pure mise en œuvre logicielle exécutée sur un ordinateur
 universel, qui n'enfreint pas lui-même de brevet, n'est pas couverte par un
 brevet et ne peut entraîner de poursuites. C'est l'autre type de solution.
 </p>
 
 <p>
 Le premier type de solution, la solution qui opère sur les types de brevets
 qui sont valides est une bonne solution à utiliser pour l'Europe.
 </p>
 
 <p>
 Quand les États-Unis ont commencé à avoir des brevets logiciels, il n'y a
 pas eu de débat politique. En fait, personne ne l'a remarqué. Même les gens
 travaillant dans le logiciel ne l'ont pas remarqué, pour la plupart. Il y a
 eu une décision de la Cour suprême en 1981 qui traitait d'un brevet sur un
 procédé de vulcanisation du caoutchouc. Le jugement disait que le fait que
 l'appareillage comprenait un ordinateur et un programme comme partie
 intégrante du procédé de vulcanisation ne le rendait pas non brevetable.
 L'année suivante, la Cour d'appel spécialisée dans les brevets inversa les
 qualificatifs : elle dit que le fait qu'il comprenait un ordinateur et un
 programme le rendait brevetable. Le fait qu'il y ait un ordinateur et un
 programme dans n'importe quoi le rendait brevetable. C'est pourquoi les
 États-Unis ont commencé à avoir des brevets sur les procédures d'entreprise
 <i>[business procedures]</i>. C'est parce que les procédures d'entreprise
 étaient exécutées sur ordinateur qu'elles étaient brevetables. Donc, cette
 décision a été rendue et je pense que le brevet sur le recalcul en ordre
 naturel a été l'un des premiers, ou peut-être le premier. Pendant les années
 1980, nous ne savions pas cela.
 </p>
 
 <p>
 C'est aux environs de 1990 qu'aux États-Unis les développeurs ont pris
 conscience du danger que les brevets logiciels représentaient pour eux. J'ai
 donc vu comment fonctionnait l'informatique avant et après, et je n'ai pas
 vu d'accélération particulière après 1990. Aux États-Unis il n'y a pas eu de
 débat politique, par contre un débat important a eu lieu en Europe. Il y a
 plusieurs années, des pressions ont été exercées pour amender le traité de
 Munich qui avait mis en place l'<a href="https://www.epo.org/">Office
 européen des brevets</a>. Ce traité a une <a
 href="https://www.epo.org/law-practice/legal-texts/html/epc/1973/e/ar52.html">clause
 disant que le logiciel n'est pas brevetable</a>. Ces pressions visaient à
 l'amender pour autoriser les brevets logiciels. Mais la communauté s'en
 aperçut. Ce furent en fait les développeurs et les utilisateurs de logiciel
 libres qui prirent la tête de l'opposition.
 </p>
 
 <p>
 Nous ne sommes pas les seuls que les brevets logiciels menacent. Tous les
 développeurs de logiciels sont menacés, et même les utilisateurs. Par
 exemple, Paul Heckel, quand Apple n'avait pas très peur de ses menaces,
 menaça de commencer à poursuivre les clients d'Apple. Alors Apple eut très
 peur. Ils ont estimé qu'ils ne pouvaient pas se permettre de voir leurs
 clients poursuivis de cette façon, même si en fin de compte ils devaient
 gagner. Donc les utilisateurs peuvent être poursuivis aussi, soit comme
 moyen d'attaquer un développeur, soit comme moyen de lui extorquer de
 l'argent, soit pour semer la pagaille.
 </p>
 
 <p>
 Tous les développeurs et les utilisateurs de logiciels sont
 vulnérables. Mais ce fut la communauté du logiciel libre en Europe qui prit
 la tête de l'opposition et l'organisa. En fait, par deux fois maintenant,
 les pays qui dirigent l'Office européen des brevets ont voté pour ne pas
 amender le traité. Alors la Commission européenne s'en mêla ; les Directions
 générales étaient divisées sur ce problème.
 </p>
 
 <p> Celle dont le travail est de promouvoir le logiciel est contre les brevets
 logiciels, semble-t-il, mais elle n'est pas en charge de ce problème. C'est
 la Direction générale du marché intérieur et des services qui en est
 chargée, et elle est dirigée par une personne qui est en faveur des brevets
 logiciels. Ils ont essentiellement ignoré l'opinion publique qui s'était
 exprimée, et proposé une directive qui autorise les brevets logiciels <a
 class="ftn" id="f3-rev" href="#f3">[3]</a>. Le gouvernement français a déjà
 dit qu'il était contre. Des gens qui travaillent dans divers autres
 gouvernements en Europe s'opposent aux brevets logiciels et il est vital de
 commencer à faire la même chose ici.  </p>
 
 <p>
 Selon Hartmut Pilch, qui est un des leaders dans la bataille européenne
 contre les brevets logiciels, l'élan principal provient de l'<a
 href="https://www.gov.uk/topic/intellectual-property/patents">Office
 britannique de la « propriété intellectuelle »</a>. Ce dernier a clairement
 un parti pris en faveur des brevets logiciels. Il a fait une consultation
 publique, et la plupart des réponses y étaient opposées. Puis il a sorti un
 rapport disant que les gens semblaient en être satisfaits, ignorant
 complètement les réponses. Voyez-vous, la communauté du logiciel libre a dit
 aux gens : « Merci de leur envoyer votre réponse et, s'il vous plaît,
 envoyez-la-nous également, ainsi nous la publierons. » Ils ont donc publié
 ces réponses, qui étaient généralement opposées aux brevets logiciels. Vous
 n'auriez jamais pu deviner que le rapport publié par l'Office britannique
 des brevets en était tiré.
 </p>
 
 <p>
 Ils (l'Office britannique des brevets et des marques) utilisent le terme
 « effet technique », mais le sens de ce terme peut être considérablement
 élargi. On est censé en conclure qu'une idée de programme est brevetable
 <em>uniquement</em> si elle se rapporte étroitement à des activités
 physiques spécifiques. Si cette l'interprétation était la bonne, cela
 résoudrait une grande partie du problème. Si les seules idées logicielles
 qui pouvaient être brevetées étaient celles qui sont vraiment associées à
 une technique particulière, un résultat physique spécifique que vous auriez
 pu breveter si vous n'aviez pas utilisé de programme, ce serait OK. Le
 problème, c'est que vous pouvez élargir le sens de ce terme. Vous pouvez
 décrire le résultat que vous obtenez en exécutant un programme comme
 résultat physique. En quoi ce résultat physique diffère-t-il de tout autre ?
 Eh bien, c'est le résultat de ce calcul. Le résultat, c'est que l'Office
 britannique des brevets propose quelque chose qui semble capable de résoudre
 presque tout le problème alors qu'en fait il donne carte blanche pour
 breveter à peu près tout.
 </p>
 
 <p>
 Des gens du même ministère sont également impliqués dans le problème du
 droit d'auteur, qui n'a vraiment rien à voir avec les brevets logiciels
 excepté qu'il est traité par les mêmes personnes. Il s'agit de
 l'interprétation d'une récente directive européenne sur le copyright, une
 loi horrible semblable à la <a
 href="https://www.eff.org/issues/dmca">Digital Millennium Copyright Act aux
 États-Unis</a> <a id="TransNote3-rev"
 href="#TransNote3"><sup>c</sup></a>. Mais les pays ont une certaine latitude
 pour décider comment la transposer. Le Royaume-Uni propose le moyen le plus
 draconien possible de le faire. Vous pourriez grandement réduire son pouvoir
 de nuisance en la transposant correctement. Le Royaume-Uni veut maximiser
 l'effet tyrannique de cette directive. Il semble qu'un certain groupe, le <a
 href="https://webarchive.nationalarchives.gov.uk/ukgwa/20070603164510/http://www.dti.gov.uk/">Ministère
 du commerce et de l'industrie</a> [page archivée], ait besoin d'être
 recadré. Il est nécessaire de poser des limites à son activité, de
 l'empêcher de créer de nouvelles formes de pouvoir.
 </p>
 
 <p>
 Les brevets logiciels enferment chaque développeur et chaque utilisateur de
 logiciel dans une nouvelle forme de bureaucratie. Si les entreprises qui
 utilisent l'informatique réalisaient tous les ennuis que cela peut leur
 causer, elles partiraient en guerre et je suis sûr qu'elles pourraient
 l'arrêter. Les entreprises n'aiment pas être enfermées dans la bureaucratie.
 </p>
 
 <p>
 Quelquefois, bien sûr, la bureaucratie sert une cause importante. Il y a des
 secteurs où nous souhaitons que le gouvernement britannique contrôle
 certaines entreprises de plus près par la bureaucratie, par exemple
 lorsqu'il s'agit de l'importation d'animaux <a class="ftn" id="f4-rev"
 href="#f4">[4]</a>. Mais dans certains cas, lorsqu'elle n'a d'autre but que
 de créer des monopoles artificiels pour que quelqu'un puisse interférer dans
 le développement logiciel, extorquer de l'argent aux développeurs et aux
 utilisateurs, alors nous devons la rejeter.
 </p>
 
 <p>
 Nous devons faire prendre conscience aux dirigeants d'entreprises de ce que
 peuvent leur faire les brevets logiciels. Obtenez leur soutien en <a
 href="https://ffii.org/">combattant les brevets logiciels en Europe</a>.
 </p>
 
 <p>
 La bataille n'est pas terminée. Elle peut encore être gagnée.
 </p>
 <div class="column-limit"></div>
 
 <h3 class="footnote">Notes</h3>
 <ol>
   <li id="f1"><a href="#f1-rev" class="nounderline">&#8593;</a>
 Il y a approximativement 300 à 400 pièces uniques dans une transmission
 automatique et la transmission est généralement le composant le plus
 compliqué d'une voiture. Concevoir une transmission peut prendre de six mois
 à un an et cela peut même être encore plus long de la faire construire et
 fonctionner. Cependant, un programme avec 500 à 600 parties fonctionnelles a
 environ 200 à 300 lignes de code et cela ne prendrait à un bon programmeur
 qu'un jour à une semaine pour l'écrire, le tester et le déboguer.</li>
   
   <li id="f2"><a href="#f2-rev" class="nounderline">&#8593;</a>
 Je dis « brevets logiciels » mais qu'est-ce que je veux réellement dire ?
 L'Office américain des brevets ne sépare pas officiellement les brevets
 logiciels des autres brevets. Donc en fait, tout brevet pourrait vous valoir
 des poursuites pour avoir écrit du logiciel s'il pouvait s'appliquer à un
 logiciel. Les brevets logiciels sont des brevets qui peuvent s'appliquer
 potentiellement à du logiciel, des brevets qui peuvent potentiellement vous
 valoir des poursuites pour avoir écrit du logiciel.</li>
 
   <li id="f3"><a href="#f3-rev" class="nounderline">&#8593;</a>
 Le 6 juillet 2005, le Parlement européen a rejeté la directive sur les
 brevets logiciels par 648 voix sur 680. Cependant, nous ne devons pas
 oublier le problème des brevets logiciels, car ceux qui avaient fait
 pression pour les autoriser essaient de ressusciter la directive qui a été
 rejetée récemment. Nous devons aussi nous assurer que l'Office européen des
 brevets, ainsi que les divers offices nationaux des différents pays
 européens, arrêtent d'accorder des brevets pour des logiciels intégrés dans
 d'autres sortes d'inventions.</li>
 
   <li id="f4"><a href="#f4-rev" class="nounderline">&#8593;</a>
 Pour limiter la propagation de la fièvre aphteuse.</li>
 </ol>
 
 <hr class="no-display" />
 <div class="edu-note c"><p id="fsfs">Cet essai est publié dans <a
 href="https://shop.fsf.org/product/free-software-free-society/"><cite>Free
 Software, Free Society: The Selected Essays of Richard
 M. Stallman</cite></a>.</p></div>
 </div>
 
 <div class="translators-notes">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 <b>Notes de traduction</b><ol id="translator-notes-alpha">
 <li><a id="TransNote1" href="#TransNote1-rev"
 class="nounderline">&#8593;</a>
 Recalcul : ensemble des calculs effectués par le tableur sur une feuille de
 calcul au cours d'une opération.</li>
 <li><a id="TransNote2" href="#TransNote2-rev"
 class="nounderline">&#8593;</a>
 <i>Text Editor and COrrector</i>, éditeur de texte développé au MIT dans les
 années 60.</li>
 <li><a id="TransNote3" href="#TransNote3-rev"
 class="nounderline">&#8593;</a>
 DMCA : loi sur le copyright du millénaire numérique.</li></ol></div>
 </div>
 
 <!-- for id="content", starts in the include above -->
 <!--#include virtual="/server/footer.fr.html" -->
 <div id="footer" role="contentinfo">
 <div class="unprintable">
 
 <p>Veuillez envoyer les requêtes concernant la FSF et GNU à &lt;<a
 href="mailto:gnu@gnu.org">gnu@gnu.org</a>&gt;. Il existe aussi <a
 href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
 orphelins et autres corrections ou suggestions peuvent être signalés à
 &lt;<a href="mailto:webmasters@gnu.org">webmasters@gnu.org</a>&gt;.</p>
 
 <p>
 <!-- TRANSLATORS: Ignore the original text in this paragraph,
         replace it with the translation of these two:
 
         We work hard and do our best to provide accurate, good quality
         translations.  However, we are not exempt from imperfection.
         Please send your comments and general suggestions in this regard
         to <a href="mailto:web-translators@gnu.org">
 
         &lt;web-translators@gnu.org&gt;</a>.</p>
 
         <p>For information on coordinating and contributing translations of
         our web pages, see <a
         href="/server/standards/README.translations.html">Translations
         README</a>. -->
 Merci d'adresser vos commentaires sur les pages en français à &lt;<a
 href="mailto:trad-gnu@april.org">trad-gnu@april.org</a>&gt;, et sur les
 traductions en général à &lt;<a
 href="mailto:web-translators@gnu.org">web-translators@gnu.org</a>&gt;. Si
 vous souhaitez y contribuer, vous trouverez dans le <a
 href="/server/standards/README.translations.html">guide de traduction</a>
 les infos nécessaires.</p>
 </div>
 
 <!-- Regarding copyright, in general, standalone pages (as opposed to
      files generated as part of manuals) on the GNU web server should
      be under CC BY-ND 4.0.  Please do NOT change or remove this
      without talking with the webmasters or licensing team first.
      Please make sure the copyright date is consistent with the
      document.  For web pages, it is ok to list just the latest year the
      document was modified, or published.
      
      If you wish to list earlier years, that is ok too.
      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
      years, as long as each year in the range is in fact a copyrightable
      year, i.e., a year in which the document was published (including
      being publicly visible on the web or in a revision control system).
      
      There is more detail about copyright years in the GNU Maintainers
      Information document, www.gnu.org/prep/maintain. -->
 <p>Copyright &copy; 2002, 2006, 2021 Richard Stallman.</p>
 
 <p>Cette page peut être utilisée suivant les conditions de la licence <a
 rel="license"
 href="http://creativecommons.org/licenses/by-nd/4.0/deed.fr">Creative
 Commons attribution, pas de modification, 4.0 internationale (CC BY-ND
 4.0)</a>.</p>
 
 <!--#include virtual="/server/bottom-notes.fr.html" -->
 <div class="translators-credits">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 Traduction : Cédric Corazza<br /> Révision : <a
 href="mailto:trad-gnu&#64;april.org">trad-gnu&#64;april.org</a></div>
 
 <p class="unprintable"><!-- timestamp start -->
 Dernière mise à jour :
 
 $Date: 2022/07/13 11:36:42 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>