summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/fr/software-patents.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/software-patents.html')
-rw-r--r--talermerchantdemos/blog/articles/fr/software-patents.html1344
1 files changed, 1344 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/fr/software-patents.html b/talermerchantdemos/blog/articles/fr/software-patents.html
new file mode 100644
index 0000000..f82c0ec
--- /dev/null
+++ b/talermerchantdemos/blog/articles/fr/software-patents.html
@@ -0,0 +1,1344 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/software-patents.en.html" -->
+
+<!--#include virtual="/server/header.fr.html" -->
+<!-- Parent-Version: 1.90 -->
+
+<!-- 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" -->
+<h2>Les brevets logiciels, obstacles au développement logiciel</h2>
+
+<p>par <strong>Richard Stallman</strong></p>
+
+<p>
+<i>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="http://www.cl.cam.ac.uk/">Laboratoire d'informatique</a> de
+l'Université de Cambridge et organisée par la <a
+href="http://www.fipr.org/">Foundation for Information Policy
+Research</a>. Cette transcription et son <a
+href="http://audio-video.gnu.org/audio/#patent-cambridge-2002-03-25">enregistrement
+audio</a> ont été effectués par Nicholas Hill. La mise en page HTML et les
+liens sont de Markus Kuhn. La version originale est hébergée sur <a
+href="http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html">http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html</a>.</i>
+</p>
+
+
+<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="http://www.wipo.org/about-ip/fr/">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 ces brevets. »
+</p>
+
+<p>
+Ce n'est pas seulement théorique. Aux environs de 1990, un programmeur du
+nom de <a href="http://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="http://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="http://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 <cite>League for Programming Freedom</cite> (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
+<cite>[fan-out]</cite>. 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
+<code>copy</code>. La même commande <code>copy</code> 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 gravage 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 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="http://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 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
+<cite>[business procedures]</cite>. 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="http://www.epo.org/">Office
+européen des brevets</a>. Ce traité a une <a
+href="http://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
+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="http://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="http://webarchive.nationalarchives.gov.uk/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 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="http://www.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>
+
+<h3>Notes</h3>
+<ol>
+ <li id="f1">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. <a
+href="#f1-rev" class="nounderline">&#8593;</a></li>
+
+ <li id="f2">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. <a href="#f2-rev"
+class="nounderline">&#8593;</a></li>
+
+ <li id="f3">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. <a href="#f3-rev"
+class="nounderline">&#8593;</a></li>
+
+ <li id="f4">Pour limiter la propagation de la fièvre aphteuse. <a href="#f4-rev"
+class="nounderline">&#8593;</a></li>
+</ol>
+
+<hr />
+<blockquote id="fsfs"><p class="big">Cet essai est publié dans <a
+href="http://shop.fsf.org/product/free-software-free-society/"><cite>Free
+Software, Free Society: The Selected Essays of Richard
+M. Stallman</cite></a>.</p></blockquote>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+<hr /><b>Notes de relecture</b><ol id="translator-notes-alpha">
+<li id="TransNote1">Recalcul : ensemble des calculs effectués par le tableur
+sur une feuille de calcul au cours d'une opération. <a
+href="#TransNote1-rev" class="nounderline">&#8593;</a></li>
+<li id="TransNote2">TECO : <cite>Text Editor and COrrector</cite>, éditeur
+de texte développé au MIT dans les années 60. <a href="#TransNote2-rev"
+class="nounderline">&#8593;</a></li>
+<li id="TransNote3">DMCA : loi sur le copyright du millénaire numérique. <a
+href="#TransNote3-rev" class="nounderline">&#8593;</a></li></ol></div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.fr.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. 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 à <a
+href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</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 submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+Nous faisons le maximum pour proposer des traductions fidèles et de bonne
+qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
+sur cette page, ainsi que vos suggestions d'ordre général sur les
+traductions, à <a href="mailto:web-translators@gnu.org">
+&lt;web-translators@gnu.org&gt;</a>.</p>
+<p>Pour tout renseignement sur la coordination et la soumission des
+traductions de nos pages web, reportez-vous au <a
+href="/server/standards/README.translations.html">guide de traduction</a>.</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, 2015-2020 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: 2020/06/19 14:30:49 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>