diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/software-patents.html')
-rw-r--r-- | talermerchantdemos/blog/articles/fr/software-patents.html | 1344 |
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">↑</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">↑</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">↑</a></li> + + <li id="f4">Pour limiter la propagation de la fièvre aphteuse. <a href="#f4-rev" +class="nounderline">↑</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">↑</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">↑</a></li> +<li id="TransNote3">DMCA : loi sur le copyright du millénaire numérique. <a +href="#TransNote3-rev" class="nounderline">↑</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"><gnu@gnu.org></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"><webmasters@gnu.org></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"> + + <web-translators@gnu.org></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"> +<web-translators@gnu.org></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 © 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@april.org">trad-gnu@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> |