path: root/talermerchantdemos/blog/articles/fr/stallman-mec-india.html

<!--#set var="ENGLISH_PAGE" value="/philosophy/stallman-mec-india.en.html" -->

<!--#include virtual="/server/header.fr.html" -->
<!-- Parent-Version: 1.77 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Conférence de Stallman au Model Engineering College sur les dangers des
brevets logiciels - Projet GNU - Free Software Foundation</title>

<!--#include virtual="/philosophy/po/stallman-mec-india.translist" -->
<!--#include virtual="/server/banner.fr.html" -->
<h2>Le danger des brevets logiciels (2001)</h2> 
 
<p><strong>Richard Stallman</strong></p>
<p> <em>Conférence donnée au <cite>Model Engineering College</cite> du
Gouvernement du Kerala (Inde) en 2001</em> (<a
href="http://audio-video.gnu.org/audio/rms-mec-india.ogg">enregistrement
audio</a>)</p> 
<hr class="thin" />
 
<div><h3><a id="sommaire">Sommaire</a></h3> 
 
<p><a href="#intro">Présentation du conférencier</a></p> 
 
<p><a href="#conf">Conférence de Stallman</a></p> 
 
<ul>
  <li><a class="nounderline" href="#conf1">Il y a deux choses qui ne vont pas dans
l'expression « propriété intellectuelle ».</a></li> 
  <li><a class="nounderline" href="#conf2">Les copyrights et les brevets n'ont
rien à faire ensemble.</a></li> 
  <li><a class="nounderline" href="#conf3">Comment marche le système de
brevets.</a></li> 
  <li><a class="nounderline" href="#conf4">Vous devez travailler avec un
juriste.</a></li> 
  <li><a class="nounderline" href="#conf5">Contourner le brevet.</a></li> 
  <li><a class="nounderline" href="#conf6">Obtenir une licence d'exploitation.</a></li> 
  <li><a class="nounderline" href="#conf7">Contester la validité du brevet.</a></li> 
  <li><a class="nounderline" href="#conf8">Personne ne peut réinventer
complètement le domaine du logiciel.</a></li> 
  <li><a class="nounderline" href="#conf9">La relation entre brevets et produits
varie suivant les spécialités.</a></li> 
  <li><a class="nounderline" href="#conf10">Le développement de programmes est
freiné par les brevets logiciels.</a></li> 
  <li><a class="nounderline" href="#conf11">Que peut faire un pays pour éviter ce
problème ?</a></li> 
  <li><a class="nounderline" href="#conf12">C'est aux citoyens de l'Inde de
préserver leur pays des brevets logiciels.</a></li> 
  <li><a class="nounderline" href="#conf13">Les entreprises doivent exiger
l'opposition aux brevets logiciels.</a></li> 
  <li><a class="nounderline" href="#conf14">C'est important que les pays se
concertent pour agir contre cela.</a></li>
</ul> 
 
<p><a href="#questions">Questions de l'auditoire</a></p> 

<ul>
  <li><a class="nounderline" href="#questions1">Questions sur les brevets
logiciels</a></li> 
  <li><a class="nounderline" href="#questions2">Questions sur le logiciel
libre</a></li>
</ul>
</div> 
 
<!-- Summary -->
<div><h3 id="intro"><a href="#sommaire" class="nounderline">&#8593;</a> Présentation du
conférencier</h3> 
 
<p><strong>Le Professeur Jyothi John, responsable du département
d'informatique, présente Stallman :</strong></p> 
 
<p> C'est pour moi un privilège d'accueillir et un devoir de vous présenter
l'hôte le plus illustre qui ait jamais rendu visite à ce collège.</p> 
 
<p> M. Richard Matthew Stallman a lancé le développement du système
d'exploitation GNU en 1984, dans le but de créer un système d'exploitation
de type Unix qui soit complètement libre. L'organisation qui a été fondée en
1985 pour servir cet objectif est la <cite>Free Software
Foundation</cite>.<a id="TransNote1-rev" href="#TransNote1"><sup>a</sup></a></p> 
 
<p> Stallman est un visionnaire de l'informatique moderne. C'est le génie qui se
cache derrière des programmes comme Emacs, GCC, le débogueur GNU et bien
d'autres. Surtout, il est l'auteur de la licence publique générale GNU,
licence sous laquelle plus de la moitié du logiciel libre est distribué et
développé. L'association de GNU avec le noyau Linux, appelée « système
d'exploitation GNU/Linux », a maintenant vingt millions d'utilisateurs dans
le monde, selon les estimations.</p> 
 
<p> La manière dont Stallman conçoit le logiciel libre nous parle de liberté,
plutôt que de prix.<a id="TransNote2-rev"
href="#TransNote2"><sup>b</sup></a> Ses idées contribuent grandement à
garantir le développement de logiciels destinés au bien-être de la société,
par des programmeurs travaillant collectivement, sans « verrouiller » leur
travail, mais au contraire en le laissant à la disposition des autres pour
l'étudier, le modifier et le redistribuer.</p> 
 
<p> Stallman a reçu le prix Grace Hopper de l'<cite>Association for Computing
Machinery</cite><a id="TransNote3-rev" href="#TransNote3"><sup>c</sup></a>
en 1991, peu après s'être vu attribuer (en 1990) une bourse de la fondation
MacArthur – parmi les autres lauréats de cette bourse prestigieuse, on
trouve Noam Chomsky et Tim Berners-Lee. En 1996, il a reçu le titre de
docteur honoris causa en technologie de l'Institut royal de Suède. En 1998,
il a reçu le prix Pioneer de l'<cite>Electronic Frontier Foundation</cite>
en même temps que Linus Torvalds, et en 1999 le prix créé en mémoire de Yuri
Rubinski.</p> 
 
<p> Aujourd'hui, Stallman va nous parler du danger des brevets logiciels. De
fait, c'est l'un des aspects les plus importants de la liberté de
programmer, parce que les brevets logiciels font courir à tous les
programmeurs le risque d'enfreindre la loi. Ils pourraient en effet, sans le
savoir, être en train de violer quelques-uns des brevets détenus par une
autre société.</p> 
 
<h3 id="conf"><a href="#sommaire" class="nounderline">&#8593;</a> Conférence de Stallman</h3> 
 
<p> Après cette introduction, je suis sûr que beaucoup d'entre vous veulent en
savoir plus sur le logiciel libre. Mais malheureusement ce n'est pas de cela
que je suis censé parler. En fait, la question que je vais aborder, celle
des brevets logiciels, <em>n'est pas</em> liée très étroitement à celle du
logiciel libre : les brevets logiciels sont un danger pour tous les
programmeurs et pour tous les utilisateurs de l'informatique. Naturellement,
c'est mon travail sur le logiciel libre qui m'en a fait prendre conscience,
car les brevets logiciels sont un danger pour mon projet aussi bien que pour
chacun des autres projets de développement logiciel dans le monde.</p> 
 
<h4 id="conf1"><a href="#sommaire" class="nounderline">&#8593;</a> Il y a deux choses qui
ne vont pas dans l'expression « propriété intellectuelle ».</h4> 
 
<p> Il y a une expression très malencontreuse que vous avez probablement déjà
entendue : « propriété intellectuelle ». Il y a deux choses qui ne vont pas
dans cette expression.</p> 
 
<p> La première : elle préjuge d'une question politique primordiale, à savoir
comment traiter telle ou telle catégorie d'idées, de pratiques, d'œuvres, ou
de n'importe quoi d'autre. Elle suppose que toutes seront traitées comme une
propriété quelconque. Pourtant, c'est une décision de politique publique et
l'on doit pouvoir examiner les différentes alternatives pour choisir la
meilleure. Ce qui veut dire qu'il ne faut pas désigner l'ensemble de ce
sujet, désigner cette question, par un terme qui préjuge de quelle sorte de
réponse on va lui donner.</p> 
 
<p> Deuxième problème, encore plus fondamental, cette expression est en réalité
un fourre-tout pour des domaines du droit complètement différents comme les
copyrights, les brevets, les marques déposées, les secrets de
fabrication, etc. Pourtant, ils n'ont en réalité presque rien en commun. Le
contenu des lois change totalement quand on passe de l'un à l'autre. Leurs
origines sont complètement indépendantes et les questions de politique
publique qu'ils soulèvent sont complètement différentes. Aussi, la seule
manière intelligente d'y réfléchir est de les examiner une à une ; d'y
réfléchir séparément.</p> 
 
<p> La manière intelligente d'en parler est de ne jamais généraliser, mais au
contraire de parler d'un domaine spécifique. Vous savez, parler des
copyrights, ou bien parler des brevets, ou bien parler des marques déposées,
mais ne jamais les mettre dans le même sac sous le nom de « propriété
intellectuelle », parce que c'est la meilleure façon d'arriver à des
conclusions simplistes. Il est presque impossible de réfléchir
intelligemment à la propriété intellectuelle et je refuse de le faire. Je
dis seulement aux gens pourquoi je pense que cette expression est erronée,
et ensuite, s'ils me demandent mon opinion sur les copyrights ou mon opinion
sur les brevets, cela me prendra une heure pour la leur donner. Mais ce sera
deux opinions différentes, et mon opinion sur les marques déposées est
encore quelque chose de complètement différent.</p> 
 
<h4 id="conf2"><a href="#sommaire" class="nounderline">&#8593;</a> Les copyrights et les
brevets n'ont rien à faire ensemble.</h4> 
 
<p> Donc pour commencer, le plus important pour vous est de ne jamais mélanger
le sujet des copyrights avec le sujet des brevets. Ils n'ont rien à faire
ensemble. Permettez-moi de vous citer quelques-unes des différences
fondamentales entre les copyrights et les brevets :</p> 
 
<ul class="blurbs">
  <li> Un copyright s'applique à une œuvre particulière, la plupart du temps
écrite, et il concerne les détails de cette œuvre. Les idées en sont
complètement exclues. Les brevets, au contraire&hellip; Eh bien, un brevet
couvre une idée. C'est aussi simple que ça. Décrivez-moi n'importe quelle
idée, c'est une idée qu'un brevet pourrait vous empêcher de mettre en
application.</li>

  <li> Les copyrights ont à voir avec le plagiat ; si vous aviez écrit quelque
chose qui soit mot pour mot identique à un certain roman à succès et que
vous puissiez prouver que vous l'avez fait alors que vous étiez enfermé dans
une pièce, sans avoir jamais vu ce roman, ce ne serait pas une infraction au
copyright parce que ce n'est pas du plagiat. Mais un brevet est un monopole
absolu sur l'utilisation d'une idée particulière. Même si vous pouviez
démontrer que vous y avez pensé tout seul, ce serait considéré comme
absolument non pertinent. Cela ne vous aiderait pas.</li>

  <li> La mise sous copyright est automatique. Dès lors que l'on a écrit quelque
chose, c'est sous copyright. Les brevets, par contre, sont octroyés à la
suite d'un processus de demande qui coûte cher. Il y a des frais importants,
et encore des dépenses supplémentaires pour payer les avocats, ce qui
naturellement favorise les grosses sociétés. L'office des brevets dit qu'il
n'octroie de brevets que pour des choses <em>non évidentes</em>. Mais en
pratique, dans beaucoup d'offices de brevets, le critère est plutôt : « non
évident pour une personne ayant un QI de 50 ». Et ils donnent toutes sortes
d'excuses pour ignorer le fait qu'après avoir regardé le brevet, n'importe
quel programmeur s'écrie : « C'est absurde, c'est évident ! » Ils
répondent : « Bon, cela semble évident après coup. » Ainsi ils ont une
excuse facile pour ignorer complètement le jugement de tout vrai
programmeur.</li>

  <li> Le copyright dure extrêmement longtemps. Aux États-Unis de nos jours, les
copyrights peuvent durer près de 150 ans, ce qui est absurde. Les brevets,
eux, ne durent pas aussi longtemps ; ils durent seulement longtemps – vingt
ans, ce qui dans le monde du logiciel est long, vous l'imaginez bien.</li>
</ul> 
 
<p> Il y a encore beaucoup d'autres différences. En fait ils diffèrent dans tous
les détails. Aussi la pire chose que vous puissiez jamais faire si vous
apprenez quelque chose à propos des copyrights, c'est de supposer que c'est
vrai également pour les brevets. Non, il est plus probable que ce n'est pas
vrai pour les brevets. Si c'est vrai pour les copyrights, ce n'est pas vrai
pour les brevets ; voilà un meilleur principe, si vous ne savez pas.</p> 
 
<h4 id="conf3"><a href="#sommaire" class="nounderline">&#8593;</a> Comment marche le
système de brevets.</h4> 
 
<p> La plupart du temps, les personnes qui décrivent comment marche le système
de brevets sont des personnes qui ont un intérêt personnel dans le
système. Et ainsi elles le décrivent du point de vue de quelqu'un qui veut
obtenir un brevet, pour ensuite le braquer sur les programmeurs en leur
disant : « File-moi ton argent. » C'est naturel, vous savez. Quand on vend
des billets de loterie, on parle des gens qui gagnent, pas de ceux qui
perdent. Naturellement, la plupart des gens perdent, mais les vendeurs de
billets ne veulent pas que vous y pensiez, alors ils parlent des gens qui
gagnent. C'est la même chose avec les brevets. Le système de brevets est une
loterie très coûteuse pour les participants. Mais naturellement, les
personnes qui le gèrent veulent que vous pensiez à la petite chance que vous
avez de gagner.</p> 
 
<p> Aussi, pour rétablir l'équilibre, je vais vous expliquer à quoi ressemble le
système de brevets du point de vue d'une personne qui pourrait en être
victime, c'est-à-dire d'une personne qui veut développer du
logiciel. Supposons que vous vouliez développer un programme et que vous
soyez dans un pays qui a des brevets logiciels. Comment devez-vous aborder
ce système ? </p> 
 
<p> Eh bien, d'abord, vous devez chercher à savoir comment les brevets
pourraient éventuellement affecter votre champ d'activité. C'est impossible,
car les brevets en cours d'examen par l'office des brevets sont
confidentiels. D'accord, dans certains pays ils sont publiés dix-huit mois
plus tard, mais cela leur laisse encore un temps appréciable pour rester
secrets. Ainsi vous pourriez développer un programme cette année, qui serait
parfaitement licite et sans danger, cette année. Et puis l'année prochaine,
un brevet pourrait être accordé et tout d'un coup vous pourriez faire
l'objet de poursuites. Cela arrive. Ou bien vos utilisateurs pourraient être
poursuivis.</p> 
 
<p> Par exemple, en 1984 nous avons développé le programme Compress, et comme
c'était un logiciel libre, il a été distribué par beaucoup de sociétés avec
les systèmes Unix. Eh bien, en 1985, un brevet a été pris aux États-Unis sur
l'algorithme de compression LZW utilisé par Compress, et après quelques
années Unisys a commencé à soutirer de l'argent à diverses sociétés.</p> 
 
<p> Comme nous, au projet GNU, avions besoin d'un programme de compression de
données et que nous ne pouvions plus utiliser Compress, nous avons commencé
à chercher un autre programme de compression. Quelqu'un s'est présenté et a
dit : « J'ai travaillé sur cet algorithme pendant un an et maintenant j'ai
décidé de vous l'offrir. Voici le code. » Nous étions à une semaine de
sortir ce programme quand je suis tombé par hasard sur un exemplaire du
<cite>New-York Times</cite>, ce qui n'arrive pas très souvent. Il se trouve
qu'il contenait justement la rubrique hebdomadaire des brevets ; je l'ai
remarquée, et donc je l'ai lue. Elle disait que quelqu'un avait obtenu un
brevet pour l'invention d'une nouvelle méthode, d'une meilleure méthode de
compression. Bon, ce n'était pas vraiment le cas.  
Quand j'ai vu ça, j'ai pensé que nous ferions mieux de nous procurer une
copie de ce brevet pour voir s'il posait problème. Et il se trouve qu'il
couvrait exactement l'algorithme que nous étions sur le point de
publier. Ainsi ce programme a été tué une semaine avant sa sortie. Et en
fait, la méthode que cette personne (le titulaire de ce brevet) avait
inventée n'était pas meilleure, parce qu'elle n'était pas nouvelle. Mais
cela n'a pas d'importance, il avait un monopole.</p> 
 
<p> Finalement nous avons trouvé un autre algorithme de compression, qui est
maintenant utilisé dans le programme connu sous le nom de GZIP. Mais ceci
illustre le danger auquel vous êtes confrontés : même si vous aviez des
moyens illimités, vous ne pourriez pas découvrir tous les brevets
susceptibles de mettre en danger votre projet. Mais vous pouvez vous
renseigner sur les brevets existants parce qu'ils sont publiés par l'office
des brevets. Donc en principe vous pourriez tous les lire et voir ce qu'ils
restreignent, ce qu'ils vous empêchent de faire. En pratique, cependant, à
partir du moment où il existe des brevets logiciels, il y en a tant que vous
ne pouvez pas soutenir le rythme.  
Aux États-Unis il y en a plus de cent mille, peut-être deux cent mille à
l'heure actuelle. C'est juste une estimation. Je sais qu'il y a dix ans ils
en accordaient dix mille par an et je crois que le rythme s'est accéléré
depuis. C'est trop pour que vous puissiez vous tenir au courant, à moins que
ce ne soit votre travail à plein temps. Cela dit, vous pouvez rechercher
ceux qui ont rapport avec ce que vous faites ; cela marche parfois. Si vous
faites des recherches avec certains mots-clés ou suivez des liens, vous
trouverez des brevets qui se rapportent à ce que vous faites. Mais vous ne
les trouverez pas <em>tous</em>.</p> 
 
<p> Il y a quelques années, quelqu'un avait un brevet américain – peut-être
a-t-il expiré depuis – sur le « recalcul<a id="TransNote4-rev"
href="#TransNote4"><sup>d</sup></a> en ordre naturel » dans les
tableurs. Maintenant, qu'est-ce que ça veut dire ? Cela signifie que les
tableurs, à l'origine, recalculaient toujours de haut en bas. Ce qui veut
dire que si jamais une cellule dépendait d'une autre cellule placée plus
bas, elle n'était pas recalculée en une fois ; vous deviez faire un autre
recalcul pour l'obtenir. C'est clair qu'il vaut mieux recalculer dans le bon
sens, vous savez. Si A dépend de B, alors calculez B d'abord, puis calculez
A. De cette façon, un seul recalcul rendra l'ensemble cohérent. Eh bien,
c'est cela que le brevet couvrait.</p> 
 
<p> Si vous aviez fait une recherche sur le mot « tableur », vous n'auriez pas
trouvé ce brevet parce que ce mot n'y figurait pas. L'expression « recalcul
en ordre naturel » n'y figurait pas non plus. Cet algorithme (c'était bien
l'algorithme qui était breveté, à peu près tous les moyens imaginables de le
coder), cet algorithme est appelé « tri topologique », et cette expression
n'apparaissait pas non plus dans le brevet. Il était présenté comme se
rapportant à une technique de compilation. Ainsi une recherche raisonnable<a
id="TransNote5-rev" href="#TransNote5"><sup>e</sup></a> ne l'aurait pas
trouvé, mais malgré tout il aurait justifié des poursuites contre vous.</p> 
 
<p> En réalité vous ne pouvez pas savoir, même approximativement, ce qu'un
brevet logiciel recouvre, à moins de l'étudier soigneusement. C'est
différent des autres spécialités, parce que dans les autres spécialités
quelque chose de physique se produit et les détails de cette chose physique
vous donnent habituellement une sorte de point d'ancrage pour déterminer si
le brevet concerne votre projet, ou non. Mais dans le logiciel, il n'y a
rien de tel. Ainsi il arrive facilement que deux descriptions totalement
différentes recouvrent, en fait, le même calcul. Il faut les étudier en
détail pour s'en apercevoir. C'est pourquoi même l'office des brevets s'y
perd. Ainsi il n'y a pas un, mais deux brevets sur la compression de données
LZW. Le premier a été attribué en 1985 et le second, je pense, en 1989, mais
ce dernier avait été demandé encore plus tôt. Un de ces brevets appartient à
Unisys et l'autre à IBM.</p> 
 
<p> En réalité, ce type d'erreur n'est pas si rare. Celle-là n'est pas
unique. Voyez-vous, les examinateurs des brevets n'ont pas beaucoup de temps
à consacrer à chacun d'eux. Aux États-Unis, ils ont en moyenne 17 heures. Ce
n'est pas suffisant pour étudier en détail tous les autres brevets de la
même spécialité, pour voir si c'est vraiment la même chose. C'est pourquoi
ils répéteront cette sorte d'erreur indéfiniment.</p> 
 
<h4 id="conf4"><a href="#sommaire" class="nounderline">&#8593;</a> Vous devez travailler
avec un avocat.</h4> 
 
<p> Donc vous ne trouverez pas tous les brevets qui pourraient vous menacer,
mais vous en trouverez quelques-uns. Alors, qu'est-ce que vous faites ? Vous
devez essayer de déterminer précisément ce que ces brevets
interdisent. C'est très difficile parce que les brevets sont rédigés dans un
langage juridique tortueux qui est très difficile à comprendre pour un
ingénieur. Il va vous falloir y travailler avec un avocat.</p> 
 
<p> Dans les années 80, le gouvernement australien a commandité une étude sur le
système de brevets – le système de brevets en général, pas seulement les
brevets logiciels. Cette étude concluait que l'Australie ferait mieux
d'abolir ce système parce qu'il rendait très peu service à la société et
causait beaucoup d'ennuis. La seule raison pour laquelle ils ne
recommandaient pas de le faire était la pression internationale. Parmi les
arguments, il y avait le fait que les brevets, pourtant censés divulguer
l'information pour qu'elle ne reste pas secrète, ne servaient pas cet
objectif en pratique. Les ingénieurs ne regardaient jamais les brevets pour
essayer d'apprendre quoi que ce soit parce qu'ils sont trop difficiles à
lire. Par exemple ils citaient un ingénieur qui disait : « Je n'arrive pas
reconnaître mes propres inventions dans les brevets. » Et ce n'est pas
seulement théorique.</p> 
 
<p> Il y a quelques années aux États-Unis, un ingénieur nommé Paul Heckel a
poursuivi Apple. Il avait pris deux brevets à la fin des années 80 pour un
logiciel. Puis il a vu HyperCard, et après l'avoir examiné il s'est dit :
« Cela ne ressemble pas à mon programme. » Il n'y a plus pensé, mais plus
tard son avocat lui a expliqué qu'en lisant son brevet avec attention, on
constatait qu'HyperCard tombait dans le domaine interdit. Il a donc
poursuivi Apple, supputant que ce serait peut-être l'occasion de gagner un
peu d'argent. Eh bien, une fois, alors que je donnais une conférence comme
celle-ci, il était dans l'assistance et a dit : « Oh non, ce n'est pas vrai,
c'est seulement que je ne connaissais pas l'étendue de ma protection. » Et
j'ai répondu : « Oui, c'est ce que je viens de dire. »</p> 
 
<p> Ainsi, vous allez devoir passer beaucoup de temps à travailler avec un
avocat, à lui expliquer sur quels projets vous travaillez, pour que l'avocat
puisse vous expliquer ce que les brevets impliquent. Cela va coûter cher. Et
quand vous aurez fini, l'avocat vous dira à peu près ceci : « Si vous faites
quelque chose dans ce domaine-ci, vous êtes presque sûr de perdre un
procès. Si vous faites quelque chose dans ce domaine-là, vous êtes
considérablement en danger et si vous voulez vraiment être en sécurité vous
feriez mieux d'en rester à l'écart. Et naturellement il y a un facteur
chance considérable dans le résultat de toute procédure. » Alors, maintenant
que vous avez un terrain prévisible pour mener vos affaires, qu'est-ce que
vous allez faire ?</p> 
 
<p> Eh bien, vous devez envisager trois possibilités :</p> 

<ul>
  <li>essayer de <a href="#conf5">contourner le brevet</a>,</li> 
  <li>essayer d'en <a href="#conf6">obtenir une licence d'exploitation</a></li> 
  <li>ou bien essayer d'en <a href="#conf7">contester la validité</a> devant les
tribunaux.</li>
</ul> 
 
<p> Chacune des trois est quelquefois une alternative viable, quelquefois elle
ne l'est pas.</p> 
 
<h4 id="conf5"><a href="#sommaire" class="nounderline">&#8593;</a> Contourner le brevet.</h4> 
 
<p> Voyons d'abord comment contourner le brevet. Dans certains cas, c'est
facile. Unisys, rappelez-vous, menaçait de son brevet les gens qui se
servaient de la compression LZW. Eh bien, il nous a suffi de trouver un
autre algorithme de compression et nous avons pu contourner ce brevet. Cela
a été un peu difficile parce qu'il y avait beaucoup d'autres brevets
couvrant un tas d'autres algorithmes de compression de données. Mais
finalement nous en avons trouvé un qui n'était pas dans le domaine couvert
par les brevets des autres ; finalement nous y sommes arrivés. Puis ce
programme a été mis en œuvre. Il donnait en fait de meilleurs résultats de
compression, et maintenant nous avons GZIP, que beaucoup de gens
utilisent. Ainsi, dans ce cas précis, cela a demandé beaucoup de travail,
mais nous avons pu le faire ; nous avons contourné le brevet.</p> 
 
<p> Mais dans les années 80, CompuServe avait défini un format d'image appelé
GIF qui utilisait l'algorithme de compression LZW. Naturellement, lorsqu'ils
ont eu vent du tumulte entourant ce brevet, des gens ont défini un autre
format d'image utilisant un algorithme de compression différent. Ils se sont
servi de l'algorithme GZIP. Ce format est appelé PNG, ce qui, je suppose,
veut dire <cite>PNG is Not GIF</cite> (PNG N'est pas GIF).</p> 
 
<p> Mais il y avait un problème : beaucoup de gens avaient déjà commencé à se
servir du format GIF et beaucoup de programmes pouvaient afficher le format
GIF et produire du format GIF, mais ils ne pouvaient pas afficher le format
PNG. Le résultat, c'est que les gens trouvaient trop difficile de changer de
format. Vous voyez, quand vous avez un programme de compression utilisé par
quelqu'un qui veut comprimer des données, si cette personne peut être
poursuivie pour avoir utilisé un programme et que vous lui en donnez un
autre, alors elle va migrer ; mais si ce qu'elle veut faire, c'est des
images qui puissent être affichées par Netscape, alors elle ne peut pas
migrer, à moins que Netscape ne commence à gérer le nouveau format&hellip;
et ce n'était pas le cas. 

Il s'est passé des années, je pense, avant que Netscape gère le format
PNG. Pour l'essentiel, les gens disaient : « Je ne peux pas changer, il faut
que je&hellip; » Au final, la société avait tant investi dans ce seul format
que l'inertie rendait le changement impossible, alors même qu'un autre
format, supérieur, était disponible.</p> 
 
<p> Même quand un brevet couvre un domaine assez étroit, le contourner peut être
très difficile. Les spécifications de PostScript incluent la compression LZW
que nous ne pouvons pas utiliser dans notre implémentation de
PostScript. Nous employons une autre sorte de compression, d'une manière peu
orthodoxe bien qu'elle donne un résultat utilisable. Ainsi, même un brevet
couvrant un domaine étroit n'est pas toujours possible à contourner en
pratique.</p> 
 
<p> Quelquefois, c'est une fonctionnalité qui est brevetée. Dans ce cas, on peut
contourner le brevet en enlevant cette fonctionnalité. Vers la fin des
années 80, les utilisateurs du logiciel de traitement de texte XyWrite ont
reçu par la poste une mise à jour dégradant le programme au lieu de
l'améliorer. Ce logiciel avait une fonctionnalité qui permettait de définir
un mot court, une suite de quelques lettres, comme abréviation. Quand on
tapait ces quelques lettres, puis un espace, on obtenait le mot complet. On
pouvait définir cette abréviation comme on voulait. Puis quelqu'un prit un
brevet sur cette fonctionnalité et XyWrite décida de traiter le problème en
l'enlevant. Ils m'ont contacté parce qu'en fait j'avais mis une
fonctionnalité similaire dans la version originale de l'éditeur Emacs, dans
les années 70 – de nombreuses années avant ce brevet. Ainsi il y avait une
chance que je puisse leur donner des arguments qui leur auraient permis de
lutter contre le brevet.</p> 
 
<p> Bon. Au moins, cela m'a montré que j'avais eu au moins une idée brevetable
dans ma vie. Je le sais parce que quelqu'un d'autre a pris le
brevet. Naturellement, vous pouvez réagir aux brevets qui couvrent des
fonctionnalités en enlevant ces dernières. Mais quand plusieurs des
fonctions que les utilisateurs recherchent commenceront à manquer dans votre
programme, il pourrait ne plus être d'aucune utilité en tant que programme.</p> 
 
<p> Vous avez peut-être entendu parler de Photoshop. Nous avons un programme
appelé « le Gimp » qui est plus puissant et d'application plus générale que
Photoshop. Mais il y a une fonctionnalité importante dont il est dépourvu,
c'est le système Pantone de correspondance des couleurs, très important
lorsqu'on veut effectivement imprimer des images sur papier avec des
résultats reproductibles. Cette fonctionnalité a été omise parce qu'elle est
brevetée. Il s'ensuit que le programme est déficient pour un groupe
important d'utilisateurs.</p> 
 
<p> Si vous regardez les programmes actuels, vous verrez que souvent ils ont de
nombreuses fonctionnalités ; les utilisateurs les réclament. Si l'une des
fonctions importantes manque, eh bien, on peut facilement la laisser de
côté, mais les résultats sont parfois très mauvais.</p> 
 
<p> Bien sûr, il arrive qu'un brevet couvre un domaine si étendu qu'il est
impossible de le contourner. Le chiffrement à clé publique est essentiel
pour préserver la vie privée des utilisateurs de l'informatique. L'ensemble
de ce domaine était breveté. Ce brevet a expiré il y a juste quatre ans ;
jusque-là, il ne pouvait pas y avoir de logiciel libre aux États-Unis pour
le chiffrement à clé publique : plusieurs programmes libres et non libres
avaient été anéantis par les titulaires du brevet. Et de fait tout ce
domaine de l'informatique a été retardé pendant plus d'une décennie malgré
le grand intérêt qu'il suscite.</p> 
 
<h4 id="conf6"><a href="#sommaire" class="nounderline">&#8593;</a> Obtenir une licence
d'exploitation.</h4> 
 
<p> Voilà donc la possibilité de contourner le brevet. Une autre option
quelquefois disponible est d'obtenir une licence d'exploitation. Cependant
le titulaire n'est pas obligé de vous offrir une licence. Cela dépend de son
caprice ; le titulaire du brevet peut dire : « Je ne donne pas de licence
pour ceci, votre boîte est coulée, point final ! »</p> 
 
<p> À la <cite>League for Programming Freedom</cite><a id="TransNote6-rev"
href="#TransNote6"><sup>f</sup></a>, nous avons entendu parler au début des
années 90 d'une personne dont l'entreprise familiale fabriquait des jeux de
casino, informatisés naturellement. Cette personne avait été menacée par
quelqu'un qui avait un brevet sur une catégorie très large de jeux de casino
sur ordinateur. Le brevet couvrait un réseau dans lequel il y a plus d'une
machine, chaque machine permettant de jouer à plus d'un type de jeu et
d'afficher le déroulement de plus d'un jeu simultanément.</p> 
 
<p> Maintenant, il y a une chose dont vous devez vous rendre compte : l'office
des brevets pense que c'est vraiment génial. Si vous voyez que d'autres ont
mis en œuvre une opération et que vous décidez de mettre en œuvre deux
opérations ou plus – vous savez, s'ils ont construit un système qui permet
de jouer à un jeu et que vous le rendez capable de jouer à plus d'un jeu –
c'est une invention. Si le système peut afficher un jeu et que vous faites
en sorte d'afficher deux jeux à la fois, c'est une invention. S'il le fait
avec un ordinateur et que vous le faites avec un réseau de plusieurs
ordinateurs, c'est une invention, de leur point de vue. Ils pensent que ces
étapes sont vraiment géniales.</p> 
 
<p> Naturellement nous savons, nous qui sommes dans l'informatique, qu'il y a
une règle de base : si l'on fait une opération quelconque une fois, on peut
généraliser et la faire plus d'une fois. Il n'y a pas de principe plus
évident. Chaque fois que vous écrivez un sous-programme, c'est ce que vous
faites. Voilà donc une des raisons récurrentes pour lesquelles le système de
brevets produit, puis confirme, des brevets dont nous dirions tous qu'ils
sont ridiculement évidents. On ne peut pas partir du principe qu'ils ne
tiendraient pas devant un tribunal pour la simple raison qu'ils sont
ridiculement évidents. Ils peuvent être valides juridiquement bien que
totalement stupides.</p> 
 
<p> Ainsi, cette personne était confrontée à ce brevet, et son titulaire ne lui
a même pas donné la possibilité d'acheter une licence. « Ferme boutique ! »
Voilà ce qu'a dit le titulaire du brevet, et c'est ce qu'elle a fait en fin
de compte. Elle n'avait pas les moyens de se battre.</p> 
 
<p> Cependant, beaucoup de titulaires de brevets vous permettront d'obtenir une
licence, mais cela vous coûtera cher. Les propriétaires du brevet sur le
recalcul en ordre naturel exigeaient cinq pour cent des ventes brutes de
chaque tableur, et l'on m'a dit que c'était le tarif réduit d'avant le
procès. Si vous alliez jusqu'à la bataille judiciaire, le tarif
augmentait. Vous pourriez, je suppose, acheter une licence comme celle-là
pour un brevet, vous pourriez le faire pour deux, vous pourriez le faire
pour trois. Mais supposez que votre programme utilise, disons, vingt
brevets, et que chaque titulaire de brevet demande cinq pour cent des ventes
brutes ? Et s'il y en a vingt-et-un ? Alors vous êtes sacrément dans la
mouise. Mais de fait, les chefs d'entreprise me disent que deux ou trois de
ces brevets seraient une charge si lourde que pratiquement ils conduiraient
la société à la faillite, même si théoriquement elle aurait pu s'en tirer.</p> 
 
<p> Donc, une licence d'exploitation n'est pas nécessairement praticable, et
pour nous, développeurs de logiciel libre, c'est encore pire parce que nous
ne pouvons même pas compter les exemplaires d'un programme. Comme la plupart
des licences exigent une redevance par poste, cela nous est absolument
impossible d'utiliser une de ces licences. Vous savez, si une licence
coûtait un millionième de roupie par exemplaire, il nous serait impossible
de nous y conformer parce que nous ne pouvons pas les compter. Peut-être que
j'ai assez d'argent dans ma poche, mais je ne peux pas compter ce que
j'achète, donc je ne peux pas le payer. C'est pourquoi c'est
particulièrement difficile pour nous par moment.</p> 
 
<p> Pourtant il existe une catégorie d'organisations pour lesquelles les
licences de brevets marchent très bien, ce sont les grandes
multinationales ; en effet elles possèdent elles-mêmes de nombreux brevets
qui leur servent à forcer la négociation de licences croisées. Qu'est-ce que
cela veut dire ? Eh bien, la dissuasion est pour ainsi dire la seule défense
contre les brevets : vous devez posséder des brevets à vous, ensuite vous
espérez que si quelqu'un vous vise avec un brevet, vous pourrez le viser en
retour avec un des vôtres en disant : « Ne me fais pas de procès, parce
qu'alors je t'en fais un. »</p> 
 
<p> Cependant, la dissuasion ne marche pas aussi bien avec les brevets qu'avec
les armes nucléaires, parce que chaque brevet pointe dans une direction
fixe. Il interdit certaines activités spécifiques. Le résultat, c'est que la
plupart des sociétés qui essaient d'obtenir des brevets pour se défendre
n'ont aucune chance d'y arriver. Peut-être qu'elles en obtiendront
quelques-uns, vous savez. Elles pourraient obtenir un brevet qui pointe par
ici, un qui pointe par là. OK, alors si quelqu'un là-bas menace cette
société, que va-t-elle faire ? Elle n'a pas de brevet pointant de ce
côté-là, donc elle est sans défense.</p> 
 
<p> Entre-temps, un jour ou l'autre, quelqu'un d'autre va venir se promener dans
les parages et le dirigeant de la société va penser : « Ho, ho, nous ne
sommes pas aussi profitables que je le souhaiterais, pourquoi ne pas lui
soutirer un peu d'argent ? » Donc ils commencent par dire qu'ils prennent ce
brevet pour leur défense, mais souvent ils changent d'avis par la suite
quand une victime alléchante passe à proximité.</p> 
 
<p> Ceci, incidemment, montre à quel point est fallacieuse la légende que le
système de brevets « protège » le « petit inventeur ». Permettez-moi de vous
raconter cette légende, celle du génie affamé. Prenez quelqu'un qui a
travaillé dans l'isolement pendant des années en crevant de faim, et qui a
une idée novatrice brillante pour faire une chose ou l'autre. Alors il crée
son entreprise et il a peur qu'une grande société comme IBM lui fasse
concurrence. Il prend donc un brevet qui va le « protéger ».</p> 
 
<p> Naturellement, ce n'est pas comme cela que ça se passe dans notre
spécialité. Les gens ne font pas ce genre d'innovation dans l'isolement. Ils
travaillent avec d'autres, ils parlent avec les autres, d'habitude pour
développer un logiciel. Donc ce scénario ne tient pas la route, et de plus,
s'il était si bon informaticien, il n'aurait pas eu besoin de crever de
faim. Il aurait pu trouver un travail n'importe quand s'il avait voulu.</p> 
 
<p> Mais admettons que cela se soit vraiment produit, et admettons qu'il ait
obtenu son brevet et qu'il dise : « IBM, tu ne peux pas me faire concurrence
parce que j'ai obtenu ce brevet. » Mais voici ce que répond IBM : « Bon,
super, voyons un peu ton produit. Hum, je possède ce brevet-ci, ce brevet-là
et encore celui-là, et celui-là, et celui-là, que ton produit est en train
de violer. Pourquoi ne ferions-nous pas pas un accord de licences
croisées ? » Et le génie affamé répond : « Hum, je n'ai pas assez de
nourriture dans l'estomac pour lutter contre ces choses-là, je ferais mieux
de céder. » Et donc ils signent un accord de licences croisées. Maintenant,
devinez quoi&hellip; IBM peut lui faire concurrence. Il n'est pas du tout
protégé !</p> 
 
<p> IBM peut faire cela parce qu'elle a un tas de brevets. Elle a des brevets
pointant par ici, par là, par là, dans toutes les directions. Ainsi,
quiconque attaque IBM, de n'importe où ou presque, s'expose à une
confrontation. Une petite société ne peut pas faire cela, mais une grande
peut le faire.</p> 
 
<p> IBM a écrit un article. C'était dans la revue <cite>Think</cite> – c'est la
revue interne d'IBM – numéro cinq de 1990 je crois, un article sur son
portefeuille de brevets. La société disait qu'elle avait deux manières de
tirer profit de ses 9 000 brevets américains en état de validité. La
première était de collecter des royalties. Mais la deuxième, la plus
rentable, était d'avoir accès à des choses brevetées par d'autres – la
permission, par le biais de licences croisées, de ne pas être attaquée par
d'autres au moyen de leurs brevets. Et l'article disait que le second profit
était supérieur au premier d'un ordre de grandeur. Autrement dit, l'avantage
que tire IBM de travailler librement, sans être poursuivie, est dix fois
supérieur à ce qu'elle gagne avec tous ses brevets.</p> 
 
<p> Cela dit, le système de brevets ressemble beaucoup à une loterie, dans le
sens que ce qu'il advient d'un brevet particulier est essentiellement le
fruit du hasard ; la plupart ne rapportent rien à leurs titulaires. Mais IBM
est si grande que, sur l'ensemble de cette société, les choses s'équilibrent
en moyenne. Donc on peut dire qu'IBM donne une bonne idée de la moyenne. Ce
qu'on observe – et ceci est un peu subtil – c'est que l'avantage pour IBM de
pouvoir utiliser les idées brevetées par d'autres contrebalance le mal que
le système de brevets lui aurait fait s'il n'y avait pas de licences
croisées – s'il lui était vraiment interdit d'utiliser les idées brevetées
par d'autres.</p> 
 
<p> Autrement dit, les dommages que causerait le système de brevets sont dix
fois supérieurs, en moyenne, aux bénéfices qu'il procure. Dans le cas d'IBM,
cependant, ces dommages n'existent pas, parce qu'elle possède effectivement
9 000 brevets et ainsi peut forcer des accords de licences croisées pour
éviter le problème. Mais si vous êtes petit, alors vous ne pouvez pas éviter
le problème de cette façon et vous serez vraiment confronté à dix fois plus
d'ennuis que de profits. En tout cas, c'est la raison pour laquelle les
grosses multinationales sont en faveur des brevets logiciels et font du
lobbying auprès des gouvernements tout autour de la planète pour qu'ils les
adoptent, en disant des choses naïves comme : « C'est une nouvelle sorte de
monopole pour les développeurs de logiciel et ce doit être bon pour eux,
n'est-ce pas ? »</p> 
 
<p> Bon. Aujourd'hui, après avoir écouté ma conférence, j'espère que vous
comprenez pourquoi ce n'est pas vrai. Pour voir si les brevets logiciels
sont bons ou mauvais, on doit regarder en détail comment ils affectent les
développeurs. Mon but est de vous l'expliquer.</p> 
 
<h4 id="conf7"><a href="#sommaire" class="nounderline">&#8593;</a> Contester la validité du
brevet.</h4> 
 
<p> Voilà donc la possibilité d'obtenir une licence d'exploitation. La troisième
option possible est d'aller au tribunal pour contester la validité du
brevet.</p> 
 
<p> Le résultat de cette procédure va dépendre pour une large part de détails
techniques, c'est-à-dire essentiellement de données aléatoires, vous
savez. Les dés ont été jetés il y a plusieurs années ; vous pouvez chercher
à savoir ce que les dés ont décidé, et alors vous découvrirez si vous avez
une chance, ou non. Ainsi, c'est essentiellement un accident historique qui
détermine si un brevet est valide ; l'accident historique qui détermine si
des gens ont publié des choses, ou plus précisément quelles choses ils ont
publiées, et quand.</p> 
 
<p> Il y a donc quelquefois une possibilité de faire invalider un
brevet. Cependant, même s'il est ridiculement trivial, on a parfois une
bonne chance de le faire invalider, parfois non.</p> 
 
<p> On ne peut pas compter sur les tribunaux pour reconnaître qu'un brevet est
trivial, parce que leurs standards sont généralement bien inférieurs à ce
que nous considérerions comme raisonnable. De fait, c'est une tendance
persistante aux États-Unis. J'ai vu une décision de la Cour suprême rendue
aux alentours de 1954, qui donnait une longue liste de brevets qu'elle avait
invalidés depuis le XIXe siècle. Et ils étaient totalement ridicules, comme
de faire des poignées de porte d'une certaine forme en caoutchouc, alors que
jusque-là on les avait faites en bois. Cette décision reprochait au système
de brevets d'avoir dérivé loin, très loin des standards adéquats. Et ils
continuent.</p> 
 
<p> Ainsi vous ne pouvez pas vous attendre à des résultats sensés, mais il
existe des situations où, si vous regardez l'historique, vous verrez qu'il y
a une chance d'invalider un brevet particulier. Cela vaut la peine
d'essayer, au moins de se renseigner. Mais la procédure elle-même risque de
coûter extrêmement cher.</p> 
 
<p> Il y a quelques années, un défendeur a perdu son procès et a dû payer
13 millions de dollars qui, en majorité, allèrent aux avocats des deux
parties. Je pense que le titulaire du brevet a remporté 5 millions de
dollars seulement ; les avocats ont donc empoché 8 millions.</p> 
 
<h4 id="conf8"><a href="#sommaire" class="nounderline">&#8593;</a> Personne ne peut
réinventer complètement le domaine du logiciel.</h4> 
 
<p> Voilà donc vos options. À ce stade, naturellement, vous devez écrire le
programme. Et là, le problème, c'est que vous n'êtes pas confronté à cette
situation une seule fois, mais qu'elle se répète, encore et encore, parce
que de nos jours les programmes sont compliqués. Regardez un logiciel de
traitement de texte ; vous y verrez un tas de fonctionnalités, beaucoup de
choses différentes dont chacune peut être brevetée par quelqu'un, ou dont
chaque combinaison de deux d'entre elles peut être brevetée par
quelqu'un. British Telecom a un brevet aux États-Unis sur la combinaison de
deux techniques : suivre des liens hypertexte et permettre à un utilisateur
d'appeler le serveur par un accès téléphonique. Ces deux choses sont bien
distinctes, mais la combinaison des deux est brevetée.</p> 
 
<p> Cela veut dire que si vous avez cent éléments dans votre programme, il y a,
potentiellement, à peu près cinq mille paires d'éléments qui pourraient déjà
être brevetées par quelqu'un. Et il n'y a pas non plus de loi interdisant de
breveter une combinaison de trois d'entre eux. Il ne s'agit que des
fonctionnalités, vous savez. Vous allez vous servir de beaucoup de
techniques en écrivant un programme, beaucoup d'algorithmes qui pourrait
être brevetés également. Donc il y a des tas et des tas de choses qui
pourraient être brevetées. Le résultat, c'est que le développement d'un
programme devient comme la traversée d'un champ de mines. Bien sûr, vous
n'allez pas marcher sur un brevet à chaque pas, à chaque étape de la
conception du programme. Il y a des chances que ce soit sans danger. Mais
traverser tout le champ devient dangereux.</p> 
 
<p> La meilleure manière pour un non-programmeur de comprendre à quoi ça
ressemble est de comparer l'écriture de ces grands programmes à un autre
domaine dans lequel les gens écrivent quelque chose de très grand : les
symphonies. Imaginez que les gouvernements européens du XVIIIe siècle aient
voulu promouvoir le progrès de la musique symphonique en adoptant un système
de brevets musicaux, de sorte que toute idée descriptible par des mots
puisse être brevetée si elle semblait nouvelle et originale. Ainsi on aurait
pu breveter, disons, un motif mélodique de trois notes, trop court pour être
placé sous copyright mais néanmoins brevetable. Ou peut-être on aurait pu
breveter une certaine progression d'accords, ou encore une certaine
combinaison d'instruments jouant en même temps, ou n'importe quelle autre
idée pouvant être décrite par quelqu'un.</p> 
 
<p> Eh bien, vers 1800 il y aurait eu des milliers de ces brevets sur les idées
musicales. Et alors imaginez que vous êtes Beethoven et que vous voulez
écrire une symphonie. Pour écrire une symphonie complète, vous allez devoir
faire un tas de choses différentes, et à n'importe quelle étape vous
pourriez être en train d'utiliser une idée brevetée par quelqu'un
d'autre. Bien sûr, si vous faites cela, il dira : « Oh ! Tu es juste un
voleur, pourquoi ne peux-tu pas écrire quelque chose d'original ? »
Beethoven avait plus que sa part d'idées musicales originales, mais il a
utilisé beaucoup d'idées existantes dans sa musique. Il fallait qu'il le
fasse, car c'était le seul moyen de la rendre reconnaissable. Si l'on ne
fait pas ça, les gens refusent d'écouter. Pierre Boulez pensait qu'il allait
réinventer complètement le langage musical. Il a essayé, mais les gens ne
l'écoutent pas car toutes ces idées qui leur sont familières, il ne les
utilise pas.</p> 
 
<p> Donc vous devez utiliser les vieilles idées inventées par d'autres. Personne
n'est assez génial pour réinventer complètement le domaine du logiciel, pour
faire des choses utiles sans rien apprendre de qui que ce soit. Si ces
personnes – les titulaires de brevets et leurs avocats – nous accusent de
tricher, c'est en fait parce que nous ne réinventons pas ce domaine
complètement à partir de rien. Pour progresser, nous devons construire sur
la base des travaux précédents, et c'est exactement ce que le système de
brevets nous interdit de faire. Et nous devons fournir aux utilisateurs les
fonctionnalités dont ils ont l'habitude et qu'ils peuvent reconnaître,
autrement ils trouveront nos logiciels trop difficiles à utiliser, quelle
que soit leur qualité.</p> 
 
<h4 id="conf9"><a href="#sommaire" class="nounderline">&#8593;</a> La relation entre
brevets et produits varie suivant les spécialités.</h4> 
 
<p> Les gens me demandent quelquefois pourquoi le logiciel est différent des
autres spécialités. Parfois, bien sûr, ils le demandent de manière assez
méchante. « Les autres spécialités peuvent composer avec les brevets,
pourquoi le logiciel ferait-il exception ? » disent-ils. C'est une manière
méchante de poser la question, car elle suppose que c'est mal de vouloir
échapper à un problème. J'imagine que je pourrais répondre : « Eh bien,
d'autres personnes peuvent avoir un cancer, pourquoi pas vous ? » Il est
évident que, si c'est un problème, permettre à une spécialité d'y échapper
est une bonne chose, quelle que soit cette spécialité. Mais voici une bonne
question, une question importante : est-ce que ces autres spécialités sont
dans la même situation que le logiciel ? Est-ce que les brevets les
affectent toutes de la même façon ? Est-ce qu'une règle qui est bonne pour
le logiciel est bonne également pour les moteurs d'automobiles, ou pour les
médicaments, ou pour les procédés chimiques ? Vous savez, c'est une question
importante et cela vaut la peine de s'y intéresser.</p> 
 
<p> Quand on l'examine, on se rend compte que la relation entre les brevets et
les produits varie suivant les spécialités. À l'un des extrêmes, il y a les
médicaments où, typiquement, un brevet couvre une formule chimique
complète. Alors, si vous sortez un nouveau médicament, il ne peut pas être
breveté par quelqu'un d'autre. À l'autre extrême, il y a le logiciel où,
lorsque vous écrivez un nouveau programme, vous combinez des dizaines ou des
centaines d'idées dont on ne peut pas attendre qu'elles soient toutes
nouvelles. Même un programme innovant, qui comporte quelques idées
nouvelles, utilise aussi des tas et des tas d'idées anciennes. Et entre les
deux on trouve les autres spécialités. Même dans ces dernières, les brevets
peuvent conduire à des impasses.</p> 
 
<p> Quand les États-Unis sont entrés dans la première guerre mondiale, personne
aux États-Unis ne pouvait construire d'avion moderne. Les avions modernes
utilisaient en effet plusieurs techniques différentes qui étaient brevetées
par diverses sociétés dont les propriétaires se détestaient. Ainsi personne
ne pouvait obtenir de licence pour utiliser tous ces brevets. Eh bien, le
gouvernement américain a décidé que cet état de choses était
inacceptable. En gros, il a payé une somme forfaitaire aux titulaires des
brevets, puis il a dit : « Nous avons nationalisé ces brevets. Et
maintenant, tous tant que vous êtes, allez construire des avions pour
nous ! »</p> 
 
<p> Mais le nombre de fois où cela se produit, la fréquence et la gravité de ces
impasses, dépendent du nombre d'idées différentes utilisées dans la
fabrication d'un produit. Cela dépend du nombre de points de vulnérabilité
aux brevets qui existent dans ce produit. Et sous ce rapport, le logiciel
est un cas extrême.</p> 
 
<p> Il n'est pas rare de voir quelques personnes écrire en deux ou trois ans un
programme contenant des millions de parties, de parties différentes, ce qui
représente peut-être, disons 300 000 lignes de code. Concevoir un système
physique qui contient des millions de pièces différentes est un projet
énorme, c'est très rare. Cela dit, il arrive souvent que des gens fabriquent
un objet physique avec des millions de pièces, mais typiquement ce sont de
nombreuses copies de la même sous-unité, et la conception en est beaucoup
plus facile – il n'y a pas des millions de pièces à concevoir.</p> 
 
<p> Pourquoi est-ce comme cela ? C'est parce que dans les autres spécialités les
gens doivent composer avec la perversité de la matière. Quand on conçoit des
circuits, des voitures ou des produits chimiques, on est confronté au fait
que ces substances physiques feront toujours ce qu'elles font, pas ce
qu'elles devraient faire. Dans le logiciel, nous n'avons pas ce problème, ce
qui rend les choses immensément plus faciles. Nous concevons une collection
de pièces mathématiques idéales qui ont des définitions. Leur comportement
est exactement celui qui est prévu par leur définition.</p> 
 
<p> Ainsi, il y a beaucoup de problèmes que nous n'avons pas. Par exemple, si
nous mettons une condition <code>if</code> à l'intérieur d'une boucle
<code>while</code>, nous n'avons pas à nous inquiéter de savoir si
<code>if</code> va recevoir assez d'énergie pour fonctionner à la vitesse
voulue. Nous n'avons pas à craindre que la boucle tourne à une vitesse
pouvant générer des interférences d'ondes radioélectriques qui induiraient
des valeurs erronées dans d'autres parties des données. Nous n'avons pas à
craindre qu'elle tourne à une vitesse susceptible de la faire entrer en
résonance, et que finalement la condition <code>if</code> vibre contre la
boucle <code>while</code> au point que l'une d'elles se casse.  
Nous n'avons pas à craindre que les produits chimiques de l'environnement
pénètrent dans l'interface entre <code>if</code> et <code>while</code>,
causant de la corrosion, puis un mauvais contact. Nous n'avons pas à
craindre que d'autres produits chimiques les contaminent et produisent un
court-circuit. Nous n'avons pas à nous demander si la chaleur dégagée par la
condition <code>if</code> peut se dissiper à travers la boucle
<code>while</code> qui l'entoure. Nous n'avons pas à nous demander si la
boucle <code>while</code> causerait une chute de tension telle que la
condition <code>if</code> ne fonctionnerait plus correctement. Quand vous
testez la valeur d'une variable, vous n'avez pas à vous demander si vous
avez référencé cette variable de si nombreuses fois que sa limite de
sortance <cite>[fan-out]</cite> est dépassée. Vous n'avez pas à vous
demander quelle est la capacité électrique d'une certaine variable et
combien de temps il faudra pour l'amener à sa valeur.</p> 
 
<p> Toutes ces choses sont définies, le système est défini pour fonctionner
d'une certaine façon et c'est ce qu'il fait toujours. L'ordinateur physique
peut être en panne, mais ce n'est pas la faute du programme. Aussi, du fait
que nous n'avons pas à traiter tous ces problèmes, notre spécialité est
immensément plus facile.</p> 
 
<p> Supposons que l'intelligence des programmeurs soit la même que
l'intelligence des ingénieurs mécaniciens, des ingénieurs électriciens, des
ingénieurs chimistes, etc. Qu'est ce qui va se passer ? Ceux d'entre nous
qui sont dans une spécialité en principe plus facile vont la pousser plus
loin. Nous construisons des choses de plus en plus grandes, et finalement
cela redevient difficile. Voilà pourquoi nous pouvons développer des
systèmes beaucoup plus grands que les gens travaillant dans d'autres
spécialités. C'est seulement qu'ils ont en permanence ces problèmes
difficiles à traiter. Dans les autres spécialités, il peut être nécessaire
de « développer » une idée : on a une idée, mais ensuite il arrive qu'on
doive l'essayer de nombreuses manières différentes avant qu'elle ne commence
à fonctionner. Dans le logiciel, ce n'est pas comme ça ; on a une idée, puis
on écrit un programme qui la met en application. Ensuite les utilisateurs
peuvent l'apprécier ou non. Et s'ils ne l'apprécient pas, on peut
probablement se contenter de corriger quelques détails et ça marche.</p> 
 
<p> Il y a un autre problème dont nous n'avons pas à nous occuper : la
fabrication de copies. Quand nous mettons cette condition <code>if</code>
dans la boucle <code>while</code>, nous n'avons pas à nous demander comment
<code>if</code> va être insérée dans <code>while</code> lorsqu'une copie
sera fabriquée. Nous n'avons pas non plus à faire en sorte que la condition
<code>if</code> soit accessible, au cas où elle grillerait et qu'on devrait
la remplacer. Tout ce que nous avons à faire, c'est de taper
<code>copy</code> ; et il s'agit d'une commande universelle pouvant copier
n'importe quoi. Les gens qui fabriquent des appareils et des produits
physiques ne peuvent pas faire ça, ils doivent les fabriquer un par un à
chaque fois.</p> 
 
<p> Pour eux, au final, la conception d'un ensemble d'une certaine complexité
peut coûter cette somme (geste), et l'installation de l'usine, cette
somme. Les coûts additionnels qu'entraîne le système de brevets, ils peuvent
s'en accommoder. Pour nous, la conception coûte ceci (geste) et la
fabrication, ceci ; en comparaison, les frais additionnels qu'entraîne ce
système sont écrasants.</p> 
 
<p> Voici une autre façon de voir les choses : puisque nous pouvons
(quelques-uns d'entre nous le peuvent) créer un ensemble beaucoup plus
grand, il y a beaucoup plus de points de vulnérabilité où quelqu'un pourrait
avoir déjà breveté quelque chose. Nous devons parcourir une longue distance
à travers le champ de mine alors qu'ils n'ont que quelques mètres à
faire. Ainsi le système est beaucoup plus dangereux pour nous que pour eux.</p> 
 
<h4 id="conf10"><a href="#sommaire" class="nounderline">&#8593;</a> Le développement de
programmes est freiné par les brevets logiciels</h4> 
 
<p> Vous devez comprendre que l'objectif affiché du système de brevets est de
promouvoir le progrès. On l'oublie souvent parce que les sociétés qui tirent
profit des brevets aimeraient détourner votre attention de ce détail. Elles
aimeraient vous convaincre que les brevets ont été créés parce qu'elles
méritent un traitement spécial. Mais ce n'est pas ce que dit le système de
brevets. Le système de brevets dit : mon but est de promouvoir le progrès au
bénéfice de la société en encourageant certains comportements comme de
publier les idées nouvelles, pour qu'après un certain temps – à l'origine,
c'était un temps assez court – tout le monde puisse les utiliser.</p> 
 
<p> Naturellement la société, de son côté, paie un certain prix, et nous devons
nous poser la question : quel est le plus grand, le bénéfice ou le
prix. Bon, dans les autres spécialités, je ne suis pas sûr. Je ne suis pas
expert dans les autres spécialités de l'ingénierie, je ne les ai jamais
étudiées et je ne sais pas si les brevets sont bons pour le progrès dans ces
spécialités.</p> 
 
<p> J'ai commencé à travailler dans le logiciel avant que les brevets logiciels
n'existent, et je sais qu'ils font beaucoup de mal et presque pas de
bien. Autrefois, les idées allaient et venaient. Ou bien des personnes
travaillant à l'université avaient une idée, ou bien quelqu'un avait une
idée alors qu'il travaillait au développement d'un logiciel. Dans les deux
cas, ces idées étaient publiées et ensuite tout le monde pouvait les
utiliser. Cela dit, pourquoi les éditeurs de logiciels publiaient-ils ces
idées ? Parce qu'ils savaient que le gros du travail était d'écrire le
programme.</p> 
 
<p> Ils savaient qu'en publiant les idées ils obtiendraient la reconnaissance de
la communauté, et que pendant ce temps-là quiconque voudrait leur faire de
la concurrence devrait de toute façon écrire un programme, ce qui représente
le gros du travail. Aussi, typiquement, ils gardaient secrets les détails du
programme (naturellement, quelques-uns d'entre nous pensent que c'est mal,
mais c'est une autre question), ils gardaient secrets les détails du
programme et publiaient les idées. En même temps, le développement logiciel
(parce que le développement logiciel suivait son cours) alimentait ce
domaine avec un flot continu d'idées, de sorte que les idées n'étaient pas
le facteur limitant. Le facteur limitant était l'écriture de programmes qui
fonctionnent et que les gens apprécient.</p> 
 
<p> Donc en réalité, l'application du système de brevets au logiciel s'efforce
de faciliter une étape qui n'est pas le facteur limitant, tout en créant des
difficultés à une étape qui est le facteur limitant. Vous voyez, les brevets
logiciels encouragent quelqu'un à avoir une idée, et en même temps ils
encouragent les gens à restreindre son utilisation. De fait, nous sommes
plus mal lotis maintenant en termes d'idées utilisables : autrefois les gens
publiaient leurs idées, ainsi nous pouvions nous en servir, alors que
maintenant ils prennent des brevets dessus, et nous ne pouvons pas nous en
servir pendant vingt ans. En attendant, le vrai facteur limitant – qui est
de développer les programmes – est gêné par les brevets logiciels à cause
d'autres dangers que je vous ai expliqués dans la première moitié de cette
conférence.</p> 
 
<p> En fin de compte, alors que ce système était censé faciliter le progrès du
logiciel, il est si mal fichu qu'il a pour seul résultat de faire
obstruction au progrès.</p> 
 
<p> Nous avons aujourd'hui une étude économique qui montre mathématiquement
comment cela peut se produire. Vous la trouverez à <a
href="http://www.researchoninnovation.org">www.researchoninnovation.org</a>.
Je ne suis pas tout à fait sûr du titre de l'article, mais il montre que,
dans une spécialité où l'innovation par sauts discontinus est la règle,
avoir un système de brevets peut aboutir à ralentir le progrès. En d'autres
termes, le système produit des effets contre-intuitifs, à opposé de ceux
qu'il était censé produire. Ceci conforte la conclusion intuitive de chaque
programmeur, qui constate l'absurdité des brevets logiciels.</p> 
 
<h4 id="conf11"><a href="#sommaire" class="nounderline">&#8593;</a> Que peut faire un pays
pour éviter ce problème ?</h4> 
 
<p> Que peut donc faire un pays pour éviter ce problème ? Eh bien, il y a deux
approches : l'une est d'attaquer le problème au niveau de l'attribution des
brevets, l'autre est de l'attaquer au niveau de l'application des brevets.</p> 
 
<p> Le faire au niveau de l'attribution des brevets n'est pas tout à fait aussi
facile que vous pourriez le croire. En effet j'ai parlé des brevets
logiciels, mais en toute rigueur on ne peut pas classer les brevets en
brevets matériels et brevets logiciels, parce qu'un même brevet peut couvrir
à la fois du matériel et du logiciel. En fait, selon ma propre définition,
un brevet logiciel est un brevet qui peut freiner le développement logiciel.</p> 
 
<p> Si vous examinez beaucoup de brevets logiciels, vous verrez que, souvent, le
système qu'ils décrivent comporte une partie importante à propos de
l'ordinateur lui-même, dans la description de ce qui se passe. C'est une
très bonne façon de faire paraître l'ensemble compliqué alors qu'en fait
c'est trivial. C'est une des manières qu'ils ont de convaincre l'office des
brevets que c'est non évident.</p> 
 
<p> Mais on peut prendre un critère différent, un endroit un peu différent où
tracer la limite, qui produise tout de même un résultat acceptable. On peut
la mettre entre les processus qui transforment la matière d'une manière
spécifique, et ceux dont le résultat est seulement le calcul et l'affichage
d'information, ou bien une combinaison d'étapes de traitement de données et
d'affichage. D'autres ont formulé ceci comme « des étapes mentales
concrétisés par l'équipement ». Il y a diverses façons de formuler ceci,
plus ou moins équivalentes.</p> 
 
<p> Ce n'est pas exactement la même chose que d'interdire les brevets logiciels,
parce que dans certains cas les ordinateurs font partie d'un équipement
physique particulier et lui permettent de faire une tâche particulière. On
pourrait donc autoriser les brevets logiciels s'ils font partie d'une tâche
physique particulière, mais ce ne serait pas vraiment catastrophique. Après
tout, à partir du moment où des gens sont impliqués dans une tâche physique
particulière ou dans un produit physique particulier, ils introduisent dans
l'ensemble de leur entreprise toute la complexité du travail avec la
matière. Cela se rapproche des autres spécialités de l'ingénierie. Peut-être
que c'est une bonne chose d'avoir des brevets sur ces logiciels à objectif
restreint. Tant que nous pouvons garder les domaines fondamentaux du
logiciel, les tâches purement logicielles, à l'abri des brevets, nous avons
résolu l'essentiel du problème.</p> 
 
<p> Donc c'est une approche réaliste, et c'est ce à quoi les gens travaillent en
Europe. Cependant cela ne servira à rien aux États-Unis, parce que les
États-Unis ont déjà des dizaines, et probablement des centaines de milliers
de brevets logiciels. Un changement quelconque dans les critères
d'attribution des brevets ne serait d'aucune utilité pour les brevets qui
existent déjà.</p> 
 
<p> Ce que je propose donc pour les États-Unis, c'est de changer les critères
d'application des brevets, comme ceci : les systèmes purement logiciels
fonctionnant sur du matériel informatique généraliste sont immunisés contre
les brevets. Par définition, ils ne peuvent pas enfreindre de brevet. De
cette façon, les brevets peuvent continuer à être attribués exactement comme
ils le sont actuellement et, d'un point de vue formel, ils peuvent toujours
couvrir à la fois la mise en œuvre de matériel et la mise en œuvre de
logiciel comme ils le font actuellement. Mais le logiciel sera en sécurité.</p> 
 
<h4 id="conf12"><a href="#sommaire" class="nounderline">&#8593;</a> C'est aux citoyens de
l'Inde de préserver leur pays des brevets logiciels.</h4> 
 
<p> C'est la solution que je propose pour les États-Unis, mais elle peut aussi
s'appliquer à d'autres pays.</p> 
 
<p> Cela dit, la plupart des pays sont actuellement confrontés à un immense
danger, l'Organisation mondiale du commerce, qui établit un système
commercial régulé par les grandes sociétés – pas un commerce libre, comme
ses partisans aiment à l'appeler, mais un commerce régulé par les grandes
sociétés. Elle transfère la régulation du commerce, opérée actuellement par
des États quelque peu démocratiques pouvant prêter l'oreille à l'intérêt de
leurs citoyens, au monde des affaires qui, lui, ne prétend pas écouter les
citoyens. Elle est donc fondamentalement antidémocratique et devrait être
abolie.</p> 
 
<p> Mais il est essentiel de noter que la partie du GATT<a id="TransNote7-rev"
href="#TransNote7"><sup>g</sup></a> qui traite des brevets n'exige pas les
brevets logiciels. C'est ce qu'affirment de nombreux experts qui ont étudié
la question, par exemple en Europe, car ils interprètent « effet technique »
<cite>[technical effect]</cite> comme le fait que [le fonctionnement du
logiciel] doit avoir une conséquence physique ou actionner un système
physique particulier. Et donc un logiciel qui ne fait pas cela ne doit pas
appartenir à la catégorie que les brevets peuvent couvrir.</p> 
 
<p> Cela veut dire qu'au moins vous n'avez pas à vous inquiéter des problèmes
causés par l'Organisation mondiale du commerce, malgré les problèmes énormes
qu'elle cause dans d'autres sphères de la vie.</p> 
 
<p> Préserver l'Inde des brevets logiciels sera votre affaire, l'affaire des
citoyens de l'Inde. Je suis un étranger, je n'ai aucune influence sauf quand
j'arrive à convaincre d'autres personnes par la logique de ce que je dis. Il
y a une chance que vous y arriviez. Quand les États-Unis ont commencé à
avoir des brevets logiciels, la question de politique publique n'a pas du
tout été prise en compte. Personne ne s'est même demandé si les brevets
logiciels étaient une bonne idée. La Cour suprême a rendu une décision qui a
été ensuite détournée par une cour d'appel, et depuis il y a des brevets
logiciels.</p> 
 
<p> Mais lorsqu'il y a quelques années l'Europe a envisagé officiellement
d'autoriser les brevets logiciels, l'opposition publique s'est manifestée et
a pris une telle ampleur que les politiciens et les partis ont commencé à y
prêter attention et ont commencé à dire qu'ils étaient contre. En fait, deux
tentatives d'autoriser les brevets logiciels ont déjà été bloquées en
Europe. Le ministre français de l'Industrie dit que les brevets logiciels
seraient un désastre et en aucune circonstance ne devraient être permis en
France. En Allemagne, tous les partis politiques ont pris position contre
les brevets logiciels.</p> 
 
<p> La bataille n'est pas encore terminée, vous savez. Nous n'avons pas bloqué
définitivement les brevets logiciels en Europe, parce que les sociétés
multinationales et leur serviteur, le gouvernement des États-Unis, font un
lobbying effréné, et qu'ils ont l'ignorance de leur côté. Il est si facile
de persuader une personne ayant une vue naïve néolibérale de la question que
ce monopole d'un nouveau genre doit être une bonne chose !</p> 
 
<p> Il faut examiner en détail comment les brevets logiciels affectent le
développement logiciel pour voir qu'ils posent problème. Il faut étudier la
recherche économique dont je vous ai parlée dans tous ses détails
mathématiques pour voir pourquoi on ne doit pas poser en principe qu'ils
sont toujours facteurs de progrès. Il est facile pour IBM d'envoyer un
lobbyiste dire à quelqu'un : « Vous devriez vraiment adopter les brevets
logiciels, ils sont formidables pour la programmation. Regardez les
États-Unis, ils sont en avance et ils ont les brevets logiciels. Si vous
aviez les brevets logiciels vous aussi, vous pourriez les rattraper. » Bon,
on ne peut pas aller plus loin dans la domination, et les États-Unis étaient
en tête en informatique avant d'avoir des brevets logiciels. Ce ne peut donc
pas être à cause des brevets logiciels.</p> 
 
<p> Il est important de comprendre que chaque pays a son propre système de
brevets et sa propre législation sur les brevets. Ce que vous faites dans un
pays donné est placé sous la juridiction de ce pays. Par conséquent, du fait
que les États-Unis ont des brevets logiciels, ils deviennent une sorte de
champ de bataille où toute personne qui utilise un ordinateur peut faire
l'objet d'une procédure. Si l'Inde évite les brevets logiciels, l'Inde ne
sera pas un champ de bataille et les utilisateurs d'ordinateurs en Inde ne
risqueront pas d'être poursuivis.</p> 
 
<p> Il se trouve que chaque pays accorde des brevets à des étrangers aussi bien
qu'à ses propres citoyens. Donc en fait, dans un endroit qui a ce fléau des
brevets logiciels, les étrangers peuvent en détenir. Il y a des tas de
sociétés non américaines qui possèdent des brevets logiciels aux États-Unis,
et elles sont toutes invitées à prendre part à la bataille aux
États-Unis. Naturellement c'est nous, les Américains, qui en sommes les
victimes. Pendant ce temps-là, si l'Inde ne reconnaît pas les brevets
logiciels, cela veut dire que ni les sociétés indiennes, ni les sociétés
étrangères ne peuvent venir en Inde attaquer les gens avec des brevets
logiciels.</p> 
 
<p> Donc oui, il est important que chaque pays ait son propre droit des
brevets. Cela fait une grande différence, mais vous devez comprendre quelle
différence ça fait. L'adoption des brevets logiciels par un pays donné
n'avantage pas les développeurs de ce pays. C'est un problème pour quiconque
y distribue et y utilise des logiciels.</p> 
 
<p> Si vous, en Inde, développez un programme qui sera utilisé aux États-Unis,
vous pouvez vous heurter, ou du moins votre client se heurtera, au problème
des brevets logiciels américains. Au moins, il est probable que vous ne
pouvez pas être poursuivi ici. Le client qui a passé commande du programme
et essayé de l'utiliser peut être poursuivi aux États-Unis, et effectivement
vous allez devoir traiter le problème – les problèmes des États-Unis – quand
vous essayez de faire des affaires là-bas. Mais au moins, ici vous serez en
sécurité. Il y a une grande différence, voyez-vous, entre une procédure
contre votre client parce qu'il vous a dit de faire un produit et que ce
produit est breveté, et une procédure contre vous pour avoir fabriqué ce
produit.</p> 
 
<p> S'il y a des brevets logiciels en Inde, alors vous ferez l'objet de
poursuites. Tandis que dans le contexte actuel, au moins vous pouvez dire à
votre client : « Vous nous avez demandé de faire ceci et nous l'avons
fait. Je suis désolé de ce qui vous arrive mais ce n'est pas notre faute. »
Tandis que s'il y a des brevets logiciels en Inde, vous serez vous-mêmes
poursuivi et vous ne pourrez rien dire.</p> 
 
<h4 id="conf13"><a href="#sommaire" class="nounderline">&#8593;</a> Les entreprises doivent
exiger l'opposition aux brevets logiciels.</h4> 
 
<p> En fin de compte, les brevets logiciels enferment tous les développeurs,
tous les utilisateurs de l'informatique et pratiquement toutes les
entreprises dans une nouvelle sorte de bureaucratie qui n'a aucune utilité
sociale. Donc c'est un mauvais choix politique, qui doit être rejeté.</p> 
 
<p> Les entreprises n'aiment pas la bureaucratie. Si elles avaient su qu'elles
étaient menacées de cette bureaucratie d'un nouveau genre, elles se seraient
opposées très fermement aux brevets logiciels. Mais la plupart n'en ont pas
conscience.</p> 
 
<p> Aux États-Unis, les brevets logiciels ont conduit directement à des brevets
sur les « méthodes économiques » <cite>[business methods]</cite><a
id="TransNote8-rev" href="#TransNote8"><sup>h</sup></a>. Qu'est-ce que ça
signifie ? Une méthode économique est essentiellement la manière dont on
prend les décisions sur ce qui doit être fait dans l'entreprise. Par le
passé, ces décisions étaient prises par des humains, mais maintenant elles
sont quelquefois prises par des ordinateurs ; ça veut dire qu'elles sont
prises par des logiciels, donc ça veut dire que les politiques
décisionnelles peuvent être brevetés. Les brevets logiciels impliquent les
brevets sur les méthodes économiques et sur les procédures d'entreprise. Le
résultat, c'est que n'importe quelle entreprise qui déciderait d'automatiser
la réalisation de ses procédures pourrait être poursuivie à cause d'un
brevet logiciel.</p> 
 
<p> Si seulement les entreprises savaient cela, elles s'organiseraient, par
l'intermédiaire des chambres de commerce par exemple, pour exiger
l'opposition aux brevets logiciels. Mais la plupart ne le savent pas et par
conséquent cela va être votre travail de les informer. Assurez-vous qu'elles
comprennent le danger auquel elles sont confrontées.</p> 
 
<h4 id="conf14"><a href="#sommaire" class="nounderline">&#8593;</a> C'est important que les
pays se concertent pour agir contre cela.</h4> 
 
<p> Alors l'Inde pourra peut-être, avec l'aide d'autres pays comme la France et
l'Allemagne, rejeter les brevets logiciels. C'est important que les gens du
gouvernement indien prennent contact avec les officiels des pays européens
pour que cette bataille contre les brevets logiciels n'ait pas à être menée
par un pays à la fois, pour que les pays puissent coopérer pour adopter une
politique intelligente. Peut-être devrait-il y avoir un « traité contre les
brevets logiciels » <cite>[no-software patent treaty]</cite> que divers pays
pourraient signer pour se promettre mutuellement de l'aide quand ils sont
menacés par la pression économique des États-Unis, manifestation de leur
impérialisme économique.</p> 
 
<p> Parce que les États-Unis aiment bien faire cela, vous savez. Une des clauses
du GATT est que les pays ont le droit d'établir des licences obligatoires
pour fabriquer des médicaments, afin de répondre à une crise de santé
publique. Le gouvernement d'Afrique du Sud s'est proposé de le faire pour
les médicaments contre le SIDA. L'Afrique du Sud a un problème très grave
avec le SIDA ; j'ai entendu dire qu'un quart de la population adulte est
infectée. Et naturellement la plupart des gens ne peuvent pas se permettre
d'acheter ces médicaments au prix demandé par les sociétés américaines.</p> 
 
<p> Ainsi le gouvernement d'Afrique du Sud était sur le point d'établir des
licences obligatoires que même le GATT autorise, mais le gouvernement des
États-Unis l'a menacé de sanctions économiques. Le vice-président Gore était
directement impliqué. Et puis, un an avant l'élection présidentielle à peu
près, il a réalisé que cela ferait mauvais effet et il s'est retiré de cette
action.</p> 
 
<p> Mais c'est le genre de chose que le gouvernement des États-Unis fait tout le
temps, à propos de brevets et de copyrights. Cela ne les dérange même pas si
les gens sont brevetés à mort.</p> 
 
<p> Donc c'est important que les pays se concertent pour agir contre cela.</p> 
 
<p> Pour des informations supplémentaires à propos des problèmes de brevets
logiciels, voir <a
href="https://web.archive.org/web/20150329202214/http://www.progfree.org/Patents/Gif/Gif.html">www.progfree.org</a>
[archivé] et <a href="http://www.ffii.org">www.ffii.org</a>. Et il y a aussi
une pétition à signer sur www.noepatents.org <a href="#Note1"
id="Note1-rev">[1]</a> 
</p> 
 
<p> S'il vous plaît, parlez à tous les dirigeants d'entreprises – toutes sortes
d'entreprises – de cette question. Assurez-vous qu'ils comprennent l'étendue
des problèmes auxquels ils sont confrontés, et donnez-leur l'idée de se
rapprocher de leurs organisations professionnelles pour qu'elles fassent du
lobbying contre les brevets logiciels.</p> 
 
<h3 id="questions"><a href="#sommaire" class="nounderline">&#8593;</a> Questions de l'auditoire</h3> 
 
<p>Maintenant, je vais répondre aux questions.</p> 
 
<p> Au fait, à tous les journalistes qui sont ici, je recommande d'écrire des
articles séparés sur les brevets logiciels et sur le logiciel libre. Si vous
couvrez tout dans un seul article, les gens resteront sur l'idée que les
brevets logiciels ne sont mauvais que pour les développeurs de logiciel
libre et sont OK pour les autres développeurs de logiciel. Ce n'est pas
vrai. Si vous repensez à ce que vous ai dit, presque rien ne se rapporte à
la question de savoir si les programmes sont libres ou non ; les dangers
sont les mêmes pour tous les développeurs. Donc, s'il vous plaît, ne prenez
pas de risque, les gens s'embrouilleraient les idées. Écrivez des articles
séparés.</p> 
 
<h4 id="questions1"><a href="#sommaire" class="nounderline">&#8593;</a> Questions sur les
brevets logiciels</h4> 
 
<dl> 
<dt><b>Q</b> : Monsieur, vous avez dit que, pour des sociétés comme IBM, le
dommage est dix fois le profit ?</dt> 
 
  <dd><b>R</b> : Non. Ce que j'ai dit, c'est que le dommage qu'elles auraient subi
est dix fois le profit. Mais ce dommage est purement théorique, il ne se
produit pas. Vous voyez, elles l'évitent par des licences croisées. Donc en
fait ce dommage ne se produit pas.</dd> 
 
<dt><b>Q</b> : Mais il est simplement neutralisé. Ils ne font pas vraiment de
profit ?</dt> 
 
  <dd><b>R</b> : Si, ils en font, voyez-vous, parce que les inconvénients, ils les
évitent par des licences croisées, et en même temps ils collectent
effectivement de l'argent avec quelques autres licences. Donc au final ils
font du profit. Il y a le petit profit, qui est réel, et le gros dommage
potentiel, qui ne se produit pas. Donc, comme profit, vous avez zéro plus
quelque chose.</dd> 
 
<dt><b>Q</b> : Mais pour ce quelque chose, ils vont s'opposer à ce mouvement
contre les brevets ?</dt> 
 
  <dd><b>R</b> : Exact. IBM est en faveur des brevets logiciels. J'ai eu du mal,
je n'ai pas entendu tous les mots de votre phrase. Je ne sais pas s'il y
avait une négation dedans, je ne pouvais pas distinguer ; il y a deux sens
possibles diamétralement opposés à ce que vous venez de dire. Donc veuillez
vous assurer que c'est clair dans votre esprit. IBM est en faveur des
brevets logiciels, IBM pense qu'elle a beaucoup à gagner avec les brevets
logiciels. Ce qu'elle a à gagner, c'est qu'IBM et les autres très grandes
sociétés finissent par contrôler en pratique le développement logiciel,
parce qu'il sera très difficile de faire du développement indépendant. 
 
  <p> Pour développer des programmes non triviaux, vous allez être obligés
d'enfreindre des brevets d'IBM. Cela dit, si vous êtes gros et que vous avez
souvent de la chance, vous pourriez avoir quelques brevets à vous et amener
IBM à négocier des licences croisées avec vous. Autrement, vous êtes
complètement à sa merci ; votre seul espoir est qu'elle se contente de vous
laisser payer.</p> 
 
  <p> Une autre question ?</p></dd> 
 
<dt><b>Q</b> : Monsieur, pourquoi les brevets logiciels ont-ils été développés ?</dt> 
 
  <dd><b>R</b> : Eh bien, aux États-Unis, il n'y avait pas de raison. Quelqu'un a
essayé d'obtenir un brevet qui était un brevet logiciel. Je pense que
l'office des brevets a dit non, alors il est allé au tribunal et finalement
devant la Cour suprême. Ils n'ont pas envisagé le cas comme une question de
politique publique, ils l'ont jugé selon ce qui est écrit dans la loi.</dd> 
 
<dt><b>Q</b> : Donc, ce n'était pas parce qu'ils se sont rendu compte
que&hellip;</dt> 
 
  <dd><b>R</b> : Désolé, je ne peux pas&hellip; Pourriez-vous essayer de prononcer
les consonnes plus distinctement, j'ai du mal à comprendre les mots.</dd> 
 
<dt><b>Q</b> : Donc, ce n'était pas parce qu'ils se sont rendu compte que le
copyright est manifestement faible pour protéger le logiciel ?</dt> 
 
  <dd><b>R</b> : Le copyright n'est pas seulement quoi ?</dd> 
 
<dt><b>Q</b> : Manifestement faible&hellip;</dt> 
 
  <dd><b>R</b> : Eh bien, je pense que toute cette phrase n'a aucun sens. Je ne
comprends pas l'expression « protéger le logiciel » et je ne suis pas
d'accord avec vous. 
 
  <p> La plupart des programmeurs ne sont pas d'accord avec vous.</p></dd> 
 
<dt><b>Q</b> : Quand vous dites que vous n'êtes pas en faveur de la protection
du logiciel et que vous-même proposez la licence publique générale, d'où
tirez-vous ce pouvoir d'attribuer la licence publique générale ?</dt> 
 
  <dd><b>R</b> : OK, vous posez une question sur le copyright et le logiciel
libre, ce qui n'est pas le sujet maintenant. J'accepterai les questions à
propos de cela plus tard. J'ai donné une conférence sur les brevets
logiciels et je veux répondre à des questions sur les brevets logiciels.</dd> 
 
<dt><b>Q</b> : Monsieur, j'ai une question sur les brevets logiciels. La
question est : comment peut-on protéger quand il y a un élément
fonctionnel&hellip;</dt> 
 
  <dd><b>R</b> : Protéger quoi ?</dd> 
 
<dt><b>Q</b> : L'élément fonctionnel&hellip;</dt> 
 
  <dd><b>R</b> : Qu'est-ce qui va leur arriver ?</dd> 
 
<dt><b>Q</b> : Monsieur, comment pouvons-nous obtenir une protection quand il y
a un&hellip;</dt> 
 
  <dd><b>R</b> : Protection contre quoi ? Quelqu'un va venir avec un fusil ?</dd> 
 
<dt><b>Q</b> : Non monsieur&hellip;</dt> 
 
  <dd><b>R</b> : La protection dont vous avez besoin, en gros, c'est une
protection contre des poursuites à cause du programme que vous avez
écrit. Les programmeurs ont besoin d'une protection contre les brevets
logiciels.</dd> 
 
<dt><b>Q</b> : Non, ce ne sont pas les programmeurs eux-mêmes, il y a des
sociétés qui ont investi dans quelque chose ?</dt> 
 
  <dd><b>R</b> : Et vous voulez que la société soit poursuivie parce que dans
votre grand programme il y a cinq choses différentes que quelqu'un, que cinq
personnes différentes, ont déjà brevetées ? Maintenant on voit clairement la
légende qui est à la base de votre raisonnement. C'est l'idée naïve que
lorsque <em>vous</em> développez un programme, <em>vous</em> obtiendrez le
brevet. Eh bien, cette idée, sa formulation-même, contient une erreur parce
qu'il n'existe rien de tel que <em>le brevet</em>. Quand vous développez un
programme avec beaucoup de choses différentes dedans, il y en a un grand
nombre qui, chacune, peuvent déjà être brevetées par quelqu'un d'autre. Vous
les découvrez l'une après l'autre quand ils viennent vous voir et vous
disent : « Donne-nous beaucoup d'argent, ou bien ferme boutique. » Et quand
vous avez traité avec cinq d'entre eux, vous ne savez jamais quand le numéro
six va arriver. C'est beaucoup plus sûr de travailler dans le logiciel si
vous savez que vous n'allez pas êtes poursuivi tant que c'est vous qui avez
écrit le programme. 
 
  <p> C'était comme ça avant les brevets logiciels. Si vous écriviez le programme
vous-même, il n'y avait aucune raison de vous poursuivre. Aujourd'hui, vous
pouvez écrire le programme vous-même, il peut même être utile et innovant,
mais parce que vous n'avez pas réinventé l'ensemble de la spécialité, que
vous avez utilisé des idées qui étaient déjà connues, d'autres personnes
vous poursuivront. Naturellement, ces autres personnes qui cherchent une
occasion de vous poursuivre, elles vont prétendre que cette extorsion
représente pour elles une protection. Protection de quoi ? Protection de la
concurrence, je parie. Ils ne croient pas à la concurrence, ils veulent des
monopoles.</p> 
 
  <p> Eh bien, qu'ils aillent au diable. Ce n'est pas bon pour le public qu'ils
obtiennent ce qu'ils veulent. C'est une question de politique
publique. C'est à nous de décider ce qui est bon pour les citoyens <em>dans
leur ensemble</em>.</p>
 
  <p><b>Auditoire</b> : [applaudissements]</p> 
 
  <p>Ne laissons pas quelqu'un nous dire : « Je veux un monopole parce que je
suis si important que j'y ai droit, donc interdisez à tous les autres de
développer du logiciel. »</p></dd> 
 
<dt><b>Q</b> : Vous suggérez que nous devrions éviter de créer un champ de
bataille pour les brevets. Mais n'avons-nous pas aussi à considérer le
problème des nombreux produits américains qui sont vendus ici, et&hellip;</dt> 
 
  <dd><b>R</b> : Et alors&hellip;</dd> 
 
<dt><b>Q</b> : &hellip; et nous allons continuer à être pris pour&hellip; ?</dt> 
 
  <dd><b>R</b> : Non ! Non, vous avez mal compris. Les développeurs américains
peuvent avoir des ennuis à cause du système de brevets. Quel effet cela
peut-il avoir ? Il y a certains produits qui ne viendront pas des
États-Unis. Par conséquent ils ne seront pas vendus aux États-Unis, ni
ici. Vous voyez, si un développeur est aux États-Unis et qu'il y a un brevet
américain, il va être poursuivi là-bas ; qu'il essaie ou non de faire des
affaires avec quelqu'un en Inde, il va être poursuivi. Mais le fait qu'il
distribue le programme en Inde ne va pas lui causer de problème
supplémentaire, parce que c'est sous la juridiction de l'Inde. C'est au
moins une chose pour laquelle on ne va <em>pas</em> le poursuivre. Donc,
cela veut dire essentiellement que tout ce qui existe peut être distribué en
Inde, sans danger, et que les développeurs qui ont la chance d'être en Inde
seront à l'abri de cette sorte de guerre de gangs, tandis que ceux qui ont
la malchance d'être aux États-Unis ne seront pas à l'abri.</dd> 
 
<dt><b>Q</b> : Monsieur, êtes-vous fondamentalement contre le concept même de
droits de propriété intellectuelle ?</dt> 
 
  <dd><b>R</b> : Comme je l'ai dit au début, le seul fait de réfléchir sur ce
thème est une sottise. C'est une généralisation abusive qui mélange des
choses totalement différentes comme les copyrights et les brevets. Aussi,
toute opinion sur la « propriété intellectuelle » est une sottise. Je n'ai
pas d'opinion sur la propriété intellectuelle. J'ai des opinions sur les
copyrights, et j'ai des opinions complètement différentes sur les brevets,
et même en ce qui concerne les brevets, j'ai des opinions différentes dans
les diverses spécialités. Les brevets eux-mêmes sont un large domaine. Et
ensuite il y a les marques déposées qu'on appelle aussi « propriété
intellectuelle ». Je pense qu'à la base, les marques déposées sont une bonne
idée. Les États-Unis sont allés un peu trop loin avec les marques, mais
c'est un principe raisonnable que d'avoir des étiquettes sur lesquelles on
peut compter. 
 
  <p> Donc n'essayer pas d'avoir une opinion sur la propriété
intellectuelle. Quand vous réfléchissez à la propriété intellectuelle, vous
réfléchissez à un niveau simpliste. Faites donc comme moi, vous savez,
prenez un sujet à la fois et concentrez-vous dessus, découvrez les détails
de ce sujet, et ensuite vous pourrez y réfléchir intelligemment. Plus tard,
vous réfléchirez aussi de manière intelligente sur les autres sujets.</p></dd> 
 
<dt><b>Q</b> : On peut argumenter que si un droit de propriété intellectuelle
particulier n'est pas protégé&hellip;</dt> 
 
  <dd><b>R</b> : Je suis désolé, ce que vous dites n'a pas le moindre sens, vous
vous placez à ce niveau général idiot&hellip;</dd> 
 
<dt><b>Q</b> : Laissez-moi finir, monsieur. Si ce droit de propriété
intellectuelle particulier n'est pas protégé, cela peut faire obstacle à
l'investissement, et cet obstacle&hellip;</dt> 
 
  <dd><b>R</b> : Cette manière de penser généralisatrice est si simpliste qu'elle
est totalement stupide. Elle n'a aucun sens. Il n'existe pas de principe de
propriété intellectuelle. Les copyrights, les brevets et les marques
déposées ont des origines complètement distinctes. Ils n'ont rien en commun,
à part le fait que, plus tard, quelqu'un a inventé ce terme « propriété
intellectuelle » pour les désigner en bloc.</dd> 
 
<dt><b>Q</b> : Monsieur, est-ce que vous généralisez ce concept à la propriété
physique ?</dt> 
 
  <dd><b>R</b> : Non, je suis désolé, rien de tout cela n'a à voir avec les droits
de propriété physique ; ils sont totalement différents. Que voulez-vous dire
par généraliser « ce concept ». Quel est « ce concept » ? L'idée que
l'expression « propriété intellectuelle » est une généralisation qui conduit
à une réflexion simpliste, est-ce qu'il faut appliquer cette idée à la
propriété physique ? Non, elles sont totalement différentes. Elles n'ont
rien en commun.</dd> 
 
<dt><b>Q</b> : La base sur laquelle repose la protection de la propriété
intellectuelle n'est-elle pas la « protection des travailleurs », des
« travailleurs intellectuels » ?</dt> 
 
  <dd><b>R</b> : Non ! Non, vous avez complètement tort, vous avez complètement
tort. Le but de&hellip; Vous avez été endoctriné. Vous avez écouté la
propagande des sociétés qui veulent avoir ces monopoles. Si vous demandez à
des chercheurs en droit quelle est la base de ces systèmes, ils vous diront
que ce sont des tentatives – je parle des copyrights et les brevets – des
tentatives de manipulation du comportement des gens pour procurer un
avantage au public. Les marques déposées sont un sujet différent. Je pense
que le sujet des marques est complètement différent. Donc, vous faites là
encore une généralisation abusive.</dd> 
 
<dt><b>Q</b> : Pourquoi ne pouvons-nous pas étendre exactement le même
principe&hellip;</dt> 
 
  <dd><b>R</b> : Mais de toute façon votre principe est <em>faux</em>. Si vous
jetez un coup d'œil aux études économiques publiées sur
<cite>www.researchoninnovation.org</cite>, vous verrez que vous faites des
affirmations naïves, des affirmations généralisatrices et naïves qui ne sont
tout simplement pas vraies. Vous partez de l'idée ridicule que créer un
monopole sur un des aspects de la vie le fera <em>toujours</em>,
<em>invariablement</em> prospérer. Eh bien, c'est stupide. Parfois cela peut
marcher, mais d'autres fois cela cause un tas d'ennuis.</dd> 
 
<dt><b>Q</b> : Ne pensez-vous pas que l'on crée le même genre de monopole en
faveur d'une partie quand elle possède une propriété physique ?</dt> 
 
  <dd><b>A</b>: Je suis désolé, je ne peux pas vous entendre.</dd> 
 
<dt><b>Q</b> : Monsieur, ne pensez-vous pas qu'on crée le même genre de droits
de monopole si l'on permet à une personne de posséder une propriété physique
particulière, exactement comme une propriété intellectuelle ?</dt> 
 
  <dd><b>R</b> : La propriété physique ne peut être qu'à un endroit à la
fois. Vous savez, il ne peut y avoir qu'une seule personne assise sur une
chaise de manière normale. [applaudissements] Vous savez que ce sont des
questions complètement différentes. Vous savez qu'essayer de généraliser à
outrance est une démarche idiote. Nous avons affaire à des lois compliquées
qui ont beaucoup, beaucoup, beaucoup de détails compliqués et vous nous
demandez d'ignorer tous ces détails. Nous avons affaire à des lois qui ont
des effets compliqués dans divers domaines, et vous nous demandez d'ignorer
les détails de leurs effets. Je pense que si nous parlons d'une question de
politique publique, nous devons nous intéresser aux résultats concrets de
cette politique, pas à une quelconque théorie décrivant les résultats
prédits par une certaine idéologie. Je vous parle de résultats concrets. Je
vous décris ce que j'ai vu et ce que d'autres programmeurs ont vu.</dd> 
 
<dt><b>Q</b> : Monsieur, qu'en est-il du brevet LZW ? Est-il&hellip;</dt> 
 
  <dd><b>R</b> : Qu'en est-il du <em>quoi</em> ?</dd> 
 
<dt><b>Q</b> : Brevet LZW ?</dt> 
 
  <dd><b>R</b> : Le brevet LZW ?</dd> 
 
<dt><b>Q</b> : Oui. Est-il encore effectif ?</dt> 
 
  <dd><b>R</b> : Oui, il l'est. Il y a deux brevets LZW comme je vous l'ai
expliqué, et ils sont tous deux encore valides.</dd> 
 
<dt><b>Q</b> : Monsieur, ainsi c'est pour vingt ans ?</dt> 
 
  <dd><b>R</b> : Oui, cela ne fait pas encore vingt ans.</dd> 
 
<dt><b>Q</b> : Monsieur, pourrions-nous réduire l'étendue du problème en
réduisant la période du brevet ?</dt> 
 
  <dd><b>R</b> : Tout à fait, on pourrait. S'il y avait des brevets logiciels et
qu'ils ne duraient que, disons, cinq ans, ou trois ans, cela résoudrait
l'essentiel du problème. Oui, c'est pénible d'avoir à attendre trois ou cinq
ans, mais c'est beaucoup, beaucoup moins pénible. Mais&hellip; mais il y a
là une difficulté : l'accord du GATT dit que les brevets doivent durer vingt
ans. Donc, le seul moyen par lequel vous pourriez avoir quelque chose comme
un brevet logiciel qui dure trois ou cinq ans est le suivant. 
 
  <p> Premièrement, affirmez clairement que les brevets ordinaires ne s'appliquent
pas et, deuxièmement, si vous voulez, vous pouvez créer un système différent
établissant un monopole de cinq ans sur les idées logicielles. Bon, il n'est
pas évident que ces monopoles de cinq ans aient un avantage particulier,
mais ce serait bien mieux que la situation actuelle. Donc si vous estimez
que le gouvernement est prêt à faire cette transaction, je dirais,
allez-y. Mais il faut bien comprendre, toutefois, que la première étape est
d'abolir les brevets logiciels proprement dits, et que cela doit faire
partie de la transaction.</p></dd> 
 
<dt><b>Q</b> : Et les brevets sont maintenant aussi victimes de&hellip;</dt> 
 
  <dd><b>R</b> : Je suis désolé, je n'ai pas pu vous entendre. Pourriez-vous
parler plus fort ?</dd> 
 
<dt><b>Q</b> : Monsieur, les brevets sont maintenant devenus une manière de
faire gagner de l'argent aux entreprises, plutôt que de promouvoir
l'innovation ?</dt> 
 
  <dd><b>R</b> : Oui, c'est comme cela que beaucoup d'entre elles les utilisent.</dd> 
 
<dt><b>Q</b> : Donc, Monsieur, pouvons-nous encore réduire ce problème en
attribuant le brevet à l'inventeur effectif, plutôt qu'à une entreprise ?</dt> 
 
  <dd><b>R</b> : Pas vraiment. Ce que l'on observe, c'est que la relation entre le
salarié et l'entreprise est négociée, et que l'entreprise a un poids
déterminant. Donc à la fin ils s'arrangeront toujours pour que le salarié
cède le brevet à la société. D'autre part, cela ne fait pas grande
différence qui possède le brevet. Le fait est qu'il vous empêche de
développer un programme utilisant cette idée. Qui précisément a la faculté
de vous poursuivre, cela peut faire une différence, mais ce que vous voulez
vraiment, c'est ne pas être poursuivi du tout. Alors, pourquoi envisager une
demi-mesure comme celle-ci ? C'est beaucoup mieux de dire simplement que le
logiciel ne doit pas avoir de brevets. 
 
  <p> OK, si vous voulez faire passer une note, vous feriez mieux de la lire tout
haut. Une autre question ?</p></dd> 
 
<dt><b>Q</b> : Les gens qui sont allés en Malaisie disent que si nous achetons
un PC là-bas, le prix de tous les logiciels standards est à peu près le
dixième de ce que nous paierions dans notre pays. Est-ce qu'en Malaisie ils
sont un peu plus laxistes à propos des brevets et des copyrights ?</dt> 
 
  <dd><b>R</b> : Êtes-vous sûr de ce dont vous parlez ? Parce que vous semblez
mélanger les copyrights et les brevets. Je ne suis pas sûr que ce dont vous
parlez ait quoi que ce soit à voir avec le sujet des brevets logiciels.</dd> 
 
<dt><b>Q</b> : Voilà précisément ce que je voudrais savoir : est-ce que c'est en
rapport avec les brevets ?</dt> 
 
  <dd><b>R</b> : Probablement pas.</dd> 
 
<dt><b>Q</b> : Différents pays, selon qu'ils font partie de l'OMC ou non&hellip;</dt> 
 
  <dd><b>R</b> : Non, non.</dd> 
 
<dt><b>Q</b> : &hellip; je pense que ça importe&hellip;</dt> 
 
  <dd><b>R</b> : Voyez-vous, je ne suis pas certain parce que je ne sais pas ce
qui se passe là-bas. Je n'y suis jamais allé. Mais je soupçonne que c'est un
problème de copyright qui n'a rien à voir avec les brevets, parce que si
vous parlez des mêmes programmes&hellip; Rappelez-vous, les brevets
logiciels sont avant tout une restriction pour les développeurs. Donc, si
ces programmes ont été développés, disons, aux États-Unis, c'est là-bas que
les problèmes de brevets sont les plus graves, pas en Malaisie, ni en
Inde. Donc c'est probablement en rapport avec le copyright, pas avec les
brevets, ce qui est une question complètement différente. Nous ne devons pas
mélanger ces questions.</dd> 
 
<dt><b>Q</b> : Monsieur, vous avez dit plus tôt que&hellip;</dt> 
 
 <dd><b>R</b> : Je suis désolé, je ne vous entends pas.</dd> 
 
<dt><b>Q</b> : Plus tôt dans votre conférence, vous avez dit que le logiciel qui
devrait relever de la compétence des brevets est ce que vous avez défini
comme ce qui peut tourner sur une machine généraliste.</dt> 
 
  <dd><b>R</b> : J'ai peur de ne pas pouvoir&hellip; Est-ce que quelqu'un comprend
ce qu'il dit ? je ne peux pas comprendre les mots. Si vous essayez de les
prononcer plus distinctement, je comprendrai peut-être.</dd> 
 
<dt><b>Q</b> : Vous avez dit plus tôt que le logiciel qui devait être breveté
est, d'après votre définition, du logiciel pouvant tourner sur une machine
généraliste&hellip;</dt> 
 
  <dd><b>R</b> : Je suis désolé. Je n'ai pas dit que le logiciel <em>devait</em>
être breveté, donc je ne comprends pas cette formulation. Peut-être que si
vous expliquez cela à quelqu'un d'autre, l'autre personne pourrait le dire
de manière que je comprenne.</dd> 
 
<dt><b>Q</b> : Les brevets logiciels, quoi que ce soit que vous appeliez brevets
logiciels, ce sont ceux qui peuvent tourner sur une machine
généraliste. Donc si un algorithme ou une partie de logiciel peut être
exécuté sur une telle machine, alors il ne doit pas être breveté.</dt> 
 
  <dd><b>R</b> : Oui. Maintenant je peux vous entendre, oui. Une des choses que
j'ai proposées, c'est que les brevets ne s'appliquent pas aux logiciels
destinés aux machines généralistes, ni à leurs utilisations sur ces
machines. Alors, si vous développez un tel programme ou si vous l'utilisez,
vous ne pouvez pas être poursuivi.</dd> 
 
<dt><b>Q</b> : Nous avons de plus en plus de logiciels actuellement qui ne
tournent pas sur des machines généralistes.</dt> 
 
  <dd><b>R</b> : Eh bien, alors ceux-là resteraient couverts par des brevets
logiciels ; ainsi la solution du problème ne serait pas complète, mais au
moins elle serait partielle.</dd> 
 
<dt><b>Q</b> : Donc si on place la limite aux machines généralistes, ne
voyez-vous pas qu'il y a une possibilité que des gens trouvent des failles,
comme des contournements pour&hellip;</dt> 
 
  <dd><b>R</b> : Je suis désolé. Est-ce que je vois la possibilité que les gens
fassent quoi ?</dd> 
 
<dt><b>Q</b> : &hellip; trouvent des failles ou des contournements pour
convertir ce que vous appelez brevets logiciels et les breveter
effectivement.</dt> 
 
  <dd><b>R</b> : Je suis désolé, je ne comprends pas. Des failles pour&hellip; Je
suis désolé. Ce que les gens feraient, ce que les développeurs de logiciel
feraient dans ce cas, c'est d'utiliser plus souvent les machines
généralistes.</dd> 
 
<dt><b>Q</b> : Un certain algorithme peut tourner sur une machine
généraliste. Ce que j'ai dit, c'est que cet algorithme, je peux l'utiliser
pour un dispositif embarqué <cite>[embedded device]</cite> et le faire
breveter.</dt> 
 
  <dd><b>R</b> : Pourquoi pas ? Vous pourriez essayer, vous avez mal compris. Le
fait est que vous avez mal compris quelle est la solution. La solution est
que, si je développe et que j'utilise le logiciel sur une machine
généraliste, alors personne ne peut me poursuivre pour avoir enfreint un
brevet. Donc oui, quelqu'un pourrait prendre un brevet,) et, peut-être,
poursuivre d'autres personnes qui font des choses spécialisées demandant un
équipement particulier. Mais ils ne pourraient pas me poursuivre, moi.</dd> 
 
<dt><b>Q</b> : Excusez-moi monsieur, est-ce que je peux poser une question ?</dt> 
 
  <dd><b>R</b> : Oui.</dd> 
 
<dt><b>Q</b> : Monsieur, vous avez parlé des machines généralistes. Dans ce
sens, comment définiriez-vous ces machines, parce que de nos jours il y a
beaucoup d'ordinateurs de poche faits sur mesure, etc. Maintenant une
façon&hellip;</dt> 
 
  <dd><b>R</b> : Non, les ordinateurs de poche sont généralistes quand ils n'ont
pas été conçus pour un calcul spécifique ou pour un processus physique
spécifique. Ce sont des ordinateurs généralistes. Ils contiennent des puces
généralistes.</dd> 
 
<dt><b>Q</b> : Donc la question de savoir si la machine est généraliste serait
contestable devant le tribunal&hellip;</dt> 
 
  <dd><b>R</b> : Je suppose, ce sera sûrement le cas, oui. En fin de compte, on
doit laisser aux juges le soin de définir précisément la limite.</dd> 
 
<dt><b>Q</b> : Merci, monsieur.</dt> 
 
<dt><b>Q</b> : Est-ce que l'Allemagne et la France sont les seuls pays européens
qui ont dit non aux brevets logiciels ?</dt> 
 
  <dd><b>R</b> : Eh bien, je ne connais pas complètement la situation. Ce sont les
seuls dont j'aie entendu parler. La dernière fois qu'il y a eu un vote, on
prévoyait qu'il y aurait une majorité pour le « non », alors ils ont laissé
tomber. Et pour les autres pays, je ne me rappelle pas.</dd> 
 
<dt><b>Q</b> : Il n'y a pas de décision de la Communauté européenne à ce
sujet&hellip;</dt> 
 
  <dd><b>R</b> : Pas encore. En fait, la Commission européenne elle-même est
divisée. Une des directions générales (DG) – malheureusement celle qui
conduit la négociation sur cette question – s'est laissé convaincre par les
multinationales, et elle est en faveur des brevets logiciels. Celle qui a
pour mission d'encourager le développement logiciel est contre, et donc
essaie de contrecarrer l'action de la première. S'il y a ici une personne
qui veut contacter le responsable de la DG opposée aux brevets logiciels, je
peux les mettre en relation.</dd> 
 
<dt><b>Q</b> : Est-ce qu'il y a un pays qui a dit « non » aux brevets
logiciels ?</dt> 
 
  <dd><b>R</b> : Eh bien, il y a des pays qui ne les ont pas, mais il n'est pas
certain qu'un pays ait affirmé son refus récemment.</dd> 
 
<dt><b>Q</b> : Monsieur, pourriez-vous s'il vous plaît nous donner des détails
sur les bénéfices que cette politique a apportés à la communauté du
développement logiciel dans les pays européens ?</dt> 
 
  <dd><b>R</b> : Eh bien, le bénéfice est que vous n'avez pas à craindre d'être
poursuivi à cause d'une des idées, ou combinaison d'idées, que vous avez
utilisée pour écrire un programme. Essentiellement, les brevets logiciels
signifient que si vous écrivez un programme, quelqu'un d'autre pourrait vous
poursuivre et dire : « Vous n'êtes pas autorisés à écrire ce programme. » Le
bénéfice de ne pas avoir de brevets logiciels est que vous êtes préservés de
cela. 
 
  <p> En Inde, vous prenez sans doute pour acquis que vous en êtes préservés. Mais
cela durera seulement tant que l'Inde n'aura pas de brevets logiciels.</p></dd> 
 
<dt><b>Q</b> : Est-ce qu'il y a un danger que l'Inde n'accède pas au régime du
logiciel ?</dt> 
 
  <dd><b>R</b> : Il n'y a pas de régime du logiciel. Les accords du GATT n'exigent
pas les brevets logiciels. Il n'y a aucun traité qui exige les brevets
logiciels.</dd> 
 
<dt><b>Q</b> : La plupart des gens, s'ils avaient une chance d'obtenir un brevet
et d'en tirer beaucoup d'argent, ils ne s'en priveraient pas&hellip;</dt> 
 
  <dd><b>R</b> : Eh bien, beaucoup de gens, s'ils avaient une chance d'obtenir un
fusil et d'en tirer beaucoup d'argent, ils ne s'en priveraient pas. 
 
  <p>L'important donc, c'est que nous ne leur en donnions pas l'occasion. Par
exemple, nous n'avons pas d'agence gouvernementale qui distribue des fusils
aux gens dans la rue ; de même, il ne faut pas avoir d'agence
gouvernementale qui distribue des brevets logiciels aux gens dans la rue.</p></dd> 
 
<dt><b>Q</b> : En tant que porte-parole de l'opposition aux brevets, est-ce que
vous avez déjà rencontré&hellip;</dt> 
 
  <dd><b>R</b> : J'ai du mal à vous entendre. S'il vous plaît, essayez de faire un
effort pour prononcer chaque son distinctement, pour que je puisse
comprendre.</dd> 
 
<dt><b>Q</b> : En tant que porte-parole de l'opposition aux brevets, est-ce que
vous avez déjà eu des problèmes avec les multinationales ou autres ?</dt> 
 
  <dd><b>R</b> : Est-ce que j'ai eu des problèmes&hellip;</dd> 
 
<dt><b>R</b> : Est-ce que j'ai eu des problèmes&hellip;</dt> 
 
  <dd><b>R</b> : Je suis désolé. Qu'est-ce qu'il a dit ?</dd> 
 
<dt><b>Q</b> : Est-ce que vous avez déjà eu des problèmes avec les
multinationales, dans votre vie ?</dt> 
 
  <dd><b>R</b> : Eh bien, il y en a beaucoup. Dans la communauté où je développe
du logiciel, il y a beaucoup d'exemples de programmes dont des
fonctionnalités ont été retirées, de programmes dans lesquels, au départ, on
n'a pas mis ces fonctionnalités, de programmes qui n'ont pas même été écrits
pendant des années. Il y a beaucoup d'exemples de travaux que nous ne
pouvons pas faire, parce que nous ne sommes pas autorisés à les faire. 
 
  <p> Nous avons rassemblé des exemples de cela et cherchons des gens pour en
rédiger un compte-rendu – vous savez, examiner chaque exemple, faire une
recherche complète à son sujet et rédiger une description claire de ce qui
est arrivé, quels dommages ont été causés, etc. Nous avons du mal à trouver
des gens pour le faire. Nous cherchons plus de monde. Une personne qui
aurait de très bonnes compétences en anglais écrit pourrait vouloir nous
offrir son aide.</p></dd> 
 
<dt><b>Q</b> : Je pense qu'il demandait si une multinationale vous avait déjà
menacé&hellip;</dt> 
 
  <dd><b>R</b> : Eh bien, elles n'ont jamais menacé ma vie !</dd> 
 
<dt><b>Q</b> : Oui, c'était la question !</dt> 
 
  <dd><b>R</b> : Non, mais elles menacent notre travail. Vous savez, elles
menacent effectivement de nous poursuivre.</dd>
</dl> 
 
<h4 id="questions2"><a href="#sommaire" class="nounderline">&#8593;</a> Questions sur le
logiciel libre</h4> 
 
<dl><dt><b>Un bénévole</b> : Voici une question d'un monsieur dans le fond : « Si
les sociétés multinationales qui produisent le matériel, comme Intel,
négocient un contrat avec les grandes sociétés de logiciel pour freiner le
logiciel libre en changeant les brevets des microprocesseurs, comment
allez-vous surmonter un tel risque ? »</dt> 
 
  <dd><b>R</b> : Je vois très peu de danger que cela arrive. Intel a récemment
développé une nouvelle architecture d'ordinateurs. Loin d'essayer de nous
empêcher de la gérer, ils ont recruté des gens pour la mettre en œuvre. 
 
  <p> Donc il semble que nous soyons maintenant arrivés aux questions sur le
logiciel libre. Je voudrais vous rappeler que jusqu'à cette dernière
réponse, je ne parlais pas pour le mouvement du logiciel libre. Je parlais
d'une question vitale pour chaque programmeur : être libre d'écrire des
programmes et de ne pas être poursuivi pour les avoir écrits, tant qu'on les
a écrits soi-même. C'est cette liberté que vous avez toujours tenue pour
acquise jusqu'à présent, et c'est cette liberté que vous perdrez si vous
avez des brevets logiciels.</p> 
 
  <p> Maintenant cependant, nous en arrivons au sujet du logiciel libre, sur
lequel j'ai passé la plus grande partie de mon temps, et du projet de
développement logiciel particulier que je conduis effectivement ; il s'agit
du développement du système d'exploitation GNU, qui est un système de type
Unix, constitué de logiciel libre et utilisé, d'après les estimations, par
environ vingt millions de personnes dans le monde. Je vais donc répondre aux
questions sur le logiciel libre et GNU.</p></dd> 
 
<dt><b>Q</b> : Le logiciel libre n'ayant pas de modèle économique concret,
est-ce qu'il va aussi exploser comme les sociétés de la bulle internet ?</dt> 
 
  <dd><b>R</b> : Je ne peux pas prédire l'avenir, mais je voudrais vous rappeler
que les sociétés de la bulle internet étaient des entreprises. Et le
logiciel libre n'est pas principalement une entreprise. Il existe quelques
entreprises du logiciel libre. Est-ce qu'elles vont réussir ou finalement
faire faillite ? Je ne sais pas. Ces entreprises contribuent à notre
communauté, mais elles n'en constituent pas la raison d'être. La raison
d'être de notre communauté, c'est la liberté de redistribuer, étudier et
modifier le logiciel. Une grande quantité de logiciel libre est développée
par des bénévoles et cette quantité est en augmentation. Quel que soit le
sort des entreprises, cela ne disparaîtra pas.</dd> 
 
<dt><b>Q</b> : Je crois que des sociétés comme IBM investissent aussi des sommes
considérables pour rendre leurs systèmes et leurs logiciels compatibles avec
du code source libre comme Linux&hellip;</dt> 
 
 <dd><b>R</b> : Vous voulez dire GNU ?</dd> 
 
<dt><b>Q</b> : D'accord&hellip;</dt> 
 
  <dd><b>R</b> : Oui, ils l'appellent Linux. En fait, le système est
essentiellement GNU et Linux est l'un de ses composants.</dd> 
 
<dt><b>[De l'auditoire]</b> Le noyau représente à peine dix-huit pour cent.</dt> 
 
  <dd><b>R</b> : Ah bon, vraiment, tant que ça ? Je le voyais à trois pour cent.</dd> 
 
<dt><b>[De l'auditoire]</b> Vous pouvez voir à travers le chas d'une
aiguille. Très peu significatif.</dt> 
 
<dt><b>Q</b> : Mais je crois aussi qu'ils ont investi pas loin d'un milliard de
dollars pour le faire. Maintenant, ma question est&hellip;</dt> 
 
  <dd><b>R</b> : Eh bien, ce n'est pas vrai.</dd> 
 
<dt><b>Q</b> : Ma question est : un service qui n'a pas de modèle économique
sera-t-il viable sur la durée ? Si je change mon entreprise en&hellip;</dt> 
 
  <dd><b>R</b> : Désolé, je ne peux pas prédire l'avenir. Personne ne le peut.</dd> 
 
<dt><b>Q</b> : Comment puis-je&hellip;</dt> 
 
  <dd><b>R</b> : Certains hommes de Dieu prétendent qu'ils peuvent prédire
l'avenir. Je n'en suis pas un. Je suis un rationaliste. 
 
  <p> Je ne peux pas vous dire ce qui va arriver. Ce que je peux vous dire, c'est
que, lorsqu'IBM prétend avoir mis un milliard de dollars dans le système
d'exploitation GNU plus Linux, ce n'est pas tout à fait vrai. Regardez
soigneusement à quoi ils dépensent cet argent, et vous verrez qu'ils le
dépensent dans plusieurs choses différentes, dont certaines sont une
contribution et d'autres non.</p> 
 
  <p> Par exemple, ils financent un travail sur le développement du système
GNU/Linux. C'est bien, c'est une contribution. Ils développent même quelques
autres paquets de logiciels libres qu'ils ont donnés à la communauté. C'est
une vraie contribution.</p> 
 
  <p> Ils développent aussi beaucoup de programmes non libres pour les faire
tourner avec le système GNU/Linux, et cela n'est pas une contribution. Et
ils font de la publicité pour ce système. Bon, ce n'est pas une contribution
essentielle, mais cela aide, vous savez. Notre objectif principal n'est pas
d'avoir plus d'utilisateurs, mais c'est une bonne chose que plus de gens
essaient nos logiciels. Donc oui, cela aide. Mais ils commettent une erreur
en appelant ceci Linux, ce qui n'est pas tout à fait exact. Par ailleurs,
ils font du lobbying en Europe en faveur des brevets logiciels, ce qui est
mauvais. Donc, vous savez, IBM fait beaucoup de choses différentes,
quelques-unes bonnes, d'autres mauvaises, et pour avoir un avis réfléchi, il
est important d'examiner chaque action individuellement. N'essayez pas de
les additionner, car cela voudrait simplement dire que vous passez à côté
des aspects importants de la situation.</p> 
 
  <p> Est-ce qu'il y a encore des questions ?</p></dd> 
 
<dt><b>Q</b> : [...]</dt> 
 
  <dd><b>A</b> : Je ne peux pas du tout vous entendre, je suis désolé [...]
murmurer. Je suis un peu dur d'oreille, et quand on combine ça avec le bruit
des ventilateurs et avec l'accent inhabituel, au final c'est très difficile
pour moi de distinguer les mots.</dd>
 
<dt><b>Q</b> : Cette question n'est pas à propos des brevets, des copyrights ou
de ce genre de choses, mais c'est à propos de votre exemple sur la condition
<code>if</code> et la boucle <code>while</code>. Vous avez dit quelque chose
à propos des différences entre l'informatique et les autres sciences, je
veux dire les autres sciences de l'ingénieur. Vous avez dit que si je change
quelque chose dans la condition <code>if</code>, il n'y aura aucun
effet. C'est ce que vous avez dit&hellip;</dt> 
 
  <dd><b>R</b> : Non, je n'ai pas dit cela.</dd> 
 
<dt><b>Q</b> : Vous avez dit cela ! Vous avez dit qu'il n'y avait pas d'effet
d'échauffement. Je m'en souviens&hellip;</dt> 
 
  <dd><b>R</b> : Je suis désolé, je sais ce que j'ai dit. J'ai dit quelque chose
qui ressemble un peu à cela&hellip;</dd> 
 
<dt><b>Q</b> : Je vais répéter la phrase exacte : vous avez dit qu'il n'y aura
pas d'effet d'échauffement.</dt> 
 
  <dd><b>R</b> : Pas d'effet de quoi ?</dd> 
 
<dt><b>Q</b> : D'échauffement. Pas de chaleur&hellip;</dt> 
 
  <dd><b>R</b> : Oh oui, nous n'avons pas à nous préoccuper de la quantité de
chaleur que la condition <code>if</code>&hellip;</dd> 
 
<dt><b>Q</b> : Oui, oui, exactement. Alors, qu'est-ce que c'est que l'effet de
cascade ? Si je change la structure de la boucle, il y aura un effet.</dt> 
 
  <dd><b>R</b> : Bien sûr. Le programme va se comporter différemment si vous le
modifiez. Je ne dis pas qu'il est facile d'écrire chaque programme, ou que
nous ne faisons jamais d'erreurs. J'ai fait la liste de pas mal de problèmes
spécifiques qui sont une plaie pour les ingénieurs mécaniciens ou
électriciens à chaque petit détail. Chacun de ces petits détails peut même
devenir très compliqué pour eux. Par contre pour nous, les problèmes
viennent de ce que nous travaillons tant, et si vite, que nous ne
réfléchissons pas assez à chaque détail. C'est pourquoi nous faisons des
erreurs.</dd> 
 
<dt><b>Q</b> : Donc vous admettez qu'il y a un effet.</dt> 
 
  <dd><b>R</b> : Naturellement. Je n'ai jamais dit autre chose. Je suis désolé que
vous l'ayez pensé. C'est sûr que si vous modifiez un programme il va se
comporter différemment.</dd> 
 
<dt><b>Q</b> : Monsieur, quelle est votre opinion sur les distributions
commerciales ?</dt> 
 
  <dd><b>R</b> : Vous m'avez demandé mon opinion sur la distribution commerciale
de systèmes GNU/Linux ? Eh bien, je pense que c'est une bonne chose. C'est
une des libertés que vous donne le logiciel libre – la liberté de l'utiliser
dans l'entreprise, la liberté de le distribuer dans le cadre de
l'entreprise, la liberté d'en vendre des copies pour de l'argent. Ces
libertés sont toutes légitimes. 
 
  <p> Pourtant, il y a une chose que je n'aime pas, c'est quand les sociétés qui
le font lui ajoutent du logiciel non libre.</p></dd> 
 
<dt><b>Q</b> : C'est le programme d'installation ?</dt> 
 
  <dd><b>R</b> : Oui, n'importe quel logiciel non libre. Parce que l'objectif
était que vous deviez pouvoir vous procurer un système d'exploitation
complètement libre. Eh bien, s'il y a quelque chose dans un magasin qui dit
« je suis le système GNU/Linux » – naturellement cela dit « Linux » – mais
qu'à l'intérieur il y a des programmes non libres, vous n'avez plus quelque
chose d'entièrement libre. Cela ne respecte pas complètement votre
liberté. Donc le véritable objectif qui nous a fait écrire ce système est
perdu de vue. 
 
  <p> Voilà le principal problème auquel notre communauté est confrontée
actuellement, la tendance à mélanger le logiciel libre avec le logiciel non
libre pour produire ces systèmes globaux non libres. Et puis, vous savez, il
peut sembler que nos logiciels aient du succès parce que beaucoup de gens
les utilisent. Mais notre véritable objectif, ce n'est pas d'être
populaires, c'est de développer une communauté de liberté. Nous ne
réussirons pas à atteindre cet objectif si les gens continuent à utiliser
des logiciels non libres.</p> 
 
  <p> Malheureusement, je ne pouvais pas faire les deux conférences. Je pouvais
soit donner la conférence sur les brevets logiciels, soit donner celle sur
le logiciel libre. Elles sont très différentes et chacune est très
longue. Donc malheureusement, cela veut dire que je ne peux pas vous donner
toutes les explications sur le logiciel libre et le projet GNU ici. Est-ce
que je dois donner une autre conférence à Kochi ? Est-ce que je dois donner
la conférence sur le logiciel libre à Kochi ?</p></dd> 
 
<dt><b>Q</b> : Non.</dt> 
 
  <dd><b>R</b> : Ah bon. J'ai donné cette conférence à Trivandrum. 
 
  <p> Alors je vais répondre à cinq questions supplémentaires et ce sera tout,
parce que cela devient épuisant de répondre à tant de questions.</p></dd> 
 
<dt><b>Q</b> : Excusez-moi monsieur, je pose encore une question. Monsieur,
c'est une question personnelle. Moi, en ce qui me concerne, j'adore
programmer. Je passe beaucoup de temps devant mon système. Et j'ai suivi
quelques-unes de vos précédentes conférences où vous avez dit que, dans les
années 70, la bienveillance animait la communauté des programmeurs. Ils
avaient l'habitude de partager du code, pour le développer.</dt> 
 
  <dd><b>R</b> : Une communauté particulière de programmeurs à laquelle
j'appartenais. Il ne s'agissait pas de tous les programmeurs. C'était une
communauté particulière. Continuez.</dd> 
 
<dt><b>Q</b> : Oui monsieur. Dans ce contexte, je me sens particulièrement, en
ce qui me concerne, je me sens très peiné quand je vois la soi-disant
interaction parmi les programmeurs aujourd'hui. Parce que beaucoup d'entre
nous sont de très bons programmeurs, mais nous nous regardons mutuellement à
travers des filtres de différentes couleurs, selon les outils que nous
utilisons – « tiens, voici un gars de Windows », « tiens, voilà un gars de
GNU/Linux », « tiens, il est dans le système Solaris », « lui, il est dans
la programmation réseau ». Et malheureusement cette discrimination vient
pour une bonne part d'une mauvaise interprétation de choses comme
celle-là. Aucune de ces personnes ne fait la promotion du logiciel libre en
tant que tel et j'en suis peiné en tant que programmeur, ainsi que beaucoup
de mes collègues, et je travaille dans un environnement&hellip;</dt> 
 
  <dd><b>R</b> : Pourriez-vous parler un peu plus lentement. J'ai entendu presque
tout ce que vous avez dit mais un détail m'a échappé, alors si vous parlez
lentement, je&hellip;</dd> 
 
<dt><b>Q</b> : Oui. Ici nous travaillons dans un environnement où nous sommes
jugés d'après les outils que nous utilisons, plutôt que d'après la qualité
de notre travail.</dt> 
 
  <dd><b>R</b> : Pour moi, ceci, eh bien en un sens, c'est une situation qui dans
une certaine mesure est logique. S'il existe un outil qu'on utilise
normalement pour faire les tâches assez faciles, devant être faites par un
grand nombre de personnes, alors, j'imagine, je ne voudrais pas, je pourrais
ne pas leur porter autant [d'attention] qu'à une personne qui fait des
travaux très difficiles avec un outil différent, adapté à ces travaux
difficiles. Mais c'est vrai, si vous parlez des travaux difficiles, cela n'a
aucun sens de discriminer les gens selon les outils qu'ils utilisent. Les
bons programmeurs peuvent se servir de n'importe quels outils.</dd> 
 
<dt><b>Q</b> : Ce n'est pas là-dessus que je mettais l'accent. Je mettais
l'accent sur le fait que c'est une question de bienveillance. La
bienveillance entre programmeurs semble fondre de nos jours dans les, vous
savez, les petites cases de tel ou tel système, et cela me fait mal.</dt> 
 
  <dd><b>R</b> : Je suis d'accord qu'on doit encourager les gens à apprendre plus
de choses différentes et qu'il ne faut jamais avoir de préjugé contre les
gens à cause de quelque détail, vous savez, le fait que telle personne
préfère Perl, telle autre préfère le langage C ; pourquoi devraient-elles se
détester&hellip;</dd> 
 
<dt><b>Q</b> : Ce n'est même pas si clair. C'est plutôt : telle personne
travaille sous GNU/Linux et telle personne travaille sous Windows, qui sont
les systèmes d'exploitation principaux aujourd'hui, du moins en Inde.</dt> 
 
  <dd><b>R</b> : Eh bien, dans ce cas, alors ce n'est pas un préjugé, vous
voyez. Windows est un système, un système social, qui maintient les gens
dans un état d'impuissance et de division [applaudissements], tandis que
GNU/Linux est une alternative qui a été créée spécifiquement pour libérer
les gens et les encourager à coopérer. Donc dans une certaine mesure, ce
n'est pas comme : « Est-ce que vous êtes né dans tel ou tel pays ? » Non,
c'est comme un choix politique. Et il est raisonnable de critiquer les gens
sur les choix qu'ils font, s'agissant de questions importantes. 
 
  <p> Ainsi, je dirais, une personne qui utilise Windows, eh bien, elle soutient
activement cette structure de pouvoir, ou du moins elle en est prisonnière
et n'a pas le courage de s'en échapper. Dans ce cas-là on peut lui
pardonner, je suppose, et l'encourager. Vous savez, il existe une variété de
situations en chaque lieu où il y a des gens différents. Certaines personne
font plus ou moins d'efforts pour essayer d'améliorer les choses. Je crois
qu'il faut juger les gens sur le plan individuel, pas en bloc suivant le
groupe auquel ils appartiennent.</p> 
 
  <p> Mais dans ce cas précis, c'est un peu comme un choix politique qui a des
conséquences sur la société, et c'est exactement pour cela qu'il est
raisonnable de critiquer les gens.</p></dd> 
 
<dt><b>Q</b> : Désolé de continuer là-dessus, Je suis un peu obstiné. Il
est&hellip;</dt> 
 
  <dd><b>R</b> : C'est votre dernière chance.</dd> 
 
<dt><b>Q</b> : Oui monsieur, merci. Généralement, quand des affirmations comme
celles-ci sont faites, les gens qui ne sont pas si, vous savez, au courant
de ces choses tendent à supposer que les communautés coopératives, le
partage de code source, le partage d'idées et autres choses de ce genre
n'existent pas dans les autres environnements. Mais si, ils existent, et
c'est très dommage qu'ils pensent cela.</dt> 
 
  <dd><b>R</b> : Je suis désolé. <em>Quoi</em> n'existe pas dans d'autres
environnements ? Je ne sais pas de quels autres environnements vous
parlez. Je ne comprends pas.</dd> 
 
<dt><b>Q</b> : Des autres environnements de programmation, des autres systèmes
d'exploitation.</dt> 
 
  <dd><b>R</b> : Eh bien, peut-être qu'il existe des utilisateurs qui développent
du logiciel libre qui fonctionne sous Windows. En fait, je suis sûr qu'il y
en a&hellip; 
 
<p><em>Note: A cet endroit, il y a eu une courte panne de
courant. L'enregistrement et la transcription sont donc incomplets.</em></p></dd> 
 
  <dd><b>R</b> : Peut-être là, y a-t-il d'autres questions ? Pourriez-vous parler
plus fort ? Je ne vous entends pas du tout.</dd> 
 
<dt><b>Q</b> : Monsieur, puis-je vous poser une question ?</dt> 
 
  <dd><b>R</b> : OK vous pouvez, bien sûr.</dd> 
 
<dt><b>Q</b> : Dans le système du logiciel libre, nous distribuons le code
source avec le logiciel. Ainsi une personne a le droit de modifier ce
qu'elle peut dans le code source. Ne pensez-vous pas qu'il y aura trop de
versions d'un même logiciel et que le non-spécialiste aura du mal à
déterminer laquelle lui convient le mieux ?</dt> 
 
  <dd><b>R</b> : En pratique, ce n'est pas un problème. Cela arrive quelquefois,
mais pas très souvent. La raison, voyez-vous, est que les utilisateurs
veulent de l'interopérabilité et qu'avec le logiciel libre, ce sont les
utilisateurs qui décident en dernier ressort. Ce qu'ils veulent, ils ont
tendance à l'obtenir. Les développeurs de logiciel libre se rendent compte
qu'ils feraient mieux&hellip; s'ils sont sur le point de faire des
changements incompatibles, cela va probablement mécontenter les utilisateurs
et leurs versions ne vont pas être utilisées. Alors, en général, ils tirent
les conclusions évidentes et font très attention à l'interopérabilité.</dd> 
 
<dt><b>Q</b> : J'ai le sentiment que si j'installe un logiciel sur mon
ordinateur, le lendemain matin je vais trouver une meilleure version et
alors je devrai changer. Le surlendemain, le code source aura encore été
modifié et ce sera une meilleure version. Donc est-ce que vous&hellip;</dt> 
 
  <dd><b>R</b> : En général vous n'allez pas trouver une meilleure version chaque
jour, parce que pour un programme donné il n'y a d'habitude qu'une version
largement utilisée. Il y en aura peut-être deux, une fois de temps en temps
il y en aura trois – s'il n'y a pas de bon mainteneur, cela peut se
produire. Donc il ne vous arrivera pas de trouver chaque jour une nouvelle
version qui soit bonne ; il n'y en a pas tant que ça. Il n'y aura pas
tellement de versions populaires. Il y a un cas où vous pouvez avoir une
nouvelle version tous les jours, c'est lorsqu'il y a une équipe très active
qui fait un gros travail de développement. Alors, chaque jour vous pouvez
vous procurer leur dernière version. Cela, vous pouvez le faire. Mais il n'y
a qu'une version à un moment donné.</dd> 
 
<dt><b>Q</b> : Monsieur, ne pensez-vous pas que nous devrions mettre sur pied
une organisation qui prendrait en compte toutes ces mises à jour et qui
fournirait un ensemble logiciel unique avec toutes les mises à jour
correctes ?</dt> 
 
  <dd><b>R</b> : Je suis désolé, je n'ai pas entendu. Ne devrions-nous pas avoir
une organisation qui ferait quelque chose avec toutes ces versions, mais je
ne sais pas quoi.</dd> 
 
<dt><b>Q</b> : Par exemple, supposons que j'aie développé une version de&hellip;</dt> 
 
  <dd><b>R</b> : Quelqu'un d'autre a-t-il entendu ce qu'elle a dit ? Quelqu'un
d'autre pourrait-il me répéter ce qu'elle a dit ?</dd> 
 
<dt><b>Q</b> : La question est que&hellip;</dt> 
 
  <dd><b>R</b> : C'est une compétence très appréciable que de savoir parler
lentement et distinctement. Si jamais vous voulez parler en public, ce qui
vous arrivera au cours de votre carrière, il vous sera très utile de savoir
articuler distinctement et lentement.</dd> 
 
<dt><b>Q</b> : Merci monsieur. Monsieur, ne pensez-vous pas que nous avons
besoin d'une organisation qui effectuerait simplement plusieurs mises à
jours à la fois et rendrait disponible du logiciel qui cumulerait toutes les
mises à jour jusqu'à une certaine date ?</dt> 
 
  <dd><b>R</b> : Vous voulez dire, qui prendrait les différentes applications et
les mettrait ensemble ?</dd> 
 
<dt><b>Q</b> : Oui monsieur.</dt> 
 
  <dd><b>R</b> : Je vais vous dire. Il y a beaucoup d'organisations qui font
cela ; en fait, chacune des distributions GNU/Linux fait exactement
cela. Debian le fait, Red Hat le fait&hellip; Nous le faisons dans une
certaine mesure avec les paquets GNU. Nous faisons en sorte qu'ils
fonctionnent ensemble.</dd> 
 
<dt><b>Q</b> : Excusez-moi monsieur, nous avons beaucoup parlé contre les
brevets. Est-ce qu'aux États-Unis vous avez jamais été forcé de déposer une
demande de brevet ?</dt> 
 
  <dd><b>R</b> : Non. Mais personne ne peut me forcer à faire une demande de
brevet.</dd> 
 
<dt><b>Q</b> : Aussi, est-ce que vous possédez des brevets ?</dt> 
 
  <dd><b>R</b> : Je ne possède aucun brevet. Cela dit, j'ai envisagé la
possibilité de demander des brevets dans le cadre d'une <em>alliance de
défense mutuelle stratégique</em>.</dd> 
 
<dt><b>Q</b> : Vous voulez dire que si j'ai vingt brevets, je peux en faire don
à la FSF qui les maintiendra pour moi ?</dt> 
 
  <dd><b>R</b> : Eh bien, pas à la FSF. Ce serait une organisation séparée,
spécialisée, qui aurait été créée spécialement pour que nous puissions tous
faire don de nos brevets, et que l'organisation utilise tous ces brevets
pour protéger quiconque souhaite être protégé. Ainsi n'importe qui pourrait
rejoindre l'organisation, même s'il ne possède pas de brevet, et cette
personne serait protégée par l'organisation. Mais alors nous essaierions
tous d'obtenir des brevets pour renforcer l'organisation, de manière qu'elle
puisse mieux nous protéger. Voilà l'idée, mais personne n'a réussi jusqu'à
présent à mettre ce projet en route. Ce n'est pas facile, l'une des raisons
étant que cela coûte très cher de demander un brevet – et c'est aussi
beaucoup de travail. 
 
  <p>Ce sera la dernière question.</p></dd> 
 
<dt><b>Q</b> : Pourquoi la Fondation pour le logiciel libre ne se met-elle pas à
faire sa propre distribution ?</dt> 
 
  <dd><b>R</b> : Eh bien, la raison, c'est que Debian répond presque à nos
désirs. Il semble préférable d'être amis avec Debian et d'essayer de les
convaincre de la changer un peu, plutôt que de leur dire : « Nous n'allons
pas l'utiliser, nous allons faire la nôtre. » Et aussi, Debian semble avoir
une meilleure chance de succès parce qu'après tout il y a déjà beaucoup de
gens qui travaillent dessus. Pourquoi essayer de créer une alternative à
cette grande communauté ? Il est bien préférable de travailler avec eux et
de les convaincre de soutenir encore mieux nos objectifs&hellip; si cela
marche, évidemment. Et nous avons nos moyens d'y arriver.</dd> 
</dl> 
 
<p> C'était donc la dernière question. Je ne peux pas rester toute la journée à
répondre aux questions, j'en suis désolé. Maintenant, je vais devoir mettre
fin au débat et aller déjeuner. Merci de m'avoir écouté.</p> 
 
<p>[Applaudissements]</p> 
 
 
<h3>Note</h3>

<p> <!-- [Dead as of 2019-03-23], and a more recent one (now closed) can be found at <a
href="http://stopsoftwarepatents.eu/">
stopsoftwarepatents.eu</a> -->
<a href="#Note1-rev" id="Note1">[1]</a> En 2012, la pétition contre les
brevets logiciels dont il est question ici est <a
href="http://web.archive.org/web/20061205023601/http://noepatents.org/index_html?NO_COOKIE=true">archivée</a>.
</p> 
<p>Voir également notre campagne <a href="http://endsoftpatents.org">pour la
disparition des brevets logiciels</a> pour plus d'information sur ce sujet.</p>
</div> 

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<hr /><b>Notes de traduction</b><ol id="translator-notes-alpha">
<li id="TransNote1">Fondation pour le logiciel libre. <a
href="#TransNote1-rev" class="nounderline">↑</a></li>
<li id="TransNote2">L'expression <cite>free software</cite> (logiciel libre)
est ambiguë, car <cite>free</cite> a deux significations : « libre » et
« gratuit ». <a href="#TransNote2-rev" class="nounderline">↑</a></li>
<li id="TransNote3">Association pour le développement des outils
informatiques. <a href="#TransNote3-rev" class="nounderline">↑</a></li>
<li id="TransNote4">Recalcul : ensemble des calculs effectués par le tableur
sur une feuille de calcul au cours d'une opération. <a
href="#TransNote4-rev" class="nounderline">↑</a></li>
<li id="TransNote5"><cite>Reasonable searching</cite> : dans un procès en
contrefaçon de brevet, le tribunal essaie entre autres de déterminer si la
contrefaçon était intentionnelle, c'est-à-dire si le défendeur connaissait
l'existence du brevet ou aurait pu la découvrir par une « recherche
raisonnable ». <a href="#TransNote5-rev" class="nounderline">↑</a></li>
<li id="TransNote6">Ligue pour la liberté de programmer. <a
href="#TransNote6-rev" class="nounderline">↑</a></li>
<li id="TransNote7"><cite>General Agreement on Tariffs and Trade</cite> :
Accord général sur les tarifs douaniers et le commerce. <a
href="#TransNote7-rev" class="nounderline">↑</a></li>
<li id="TransNote8">Plus précisément : méthodes pour l'exercice d'activités
économiques. Autre traduction : méthodes commerciales. <a
href="#TransNote8-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">&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; 2001, 2008, 2009, 2012, 2013, 2015, 2018, 2019 Free
Software Foundation, Inc.</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 : Thérèse Godefroy<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: 2019/03/23 20:00:27 $ 
 
<!-- timestamp end -->
</p> 
</div> 
</div>
</body> 
</html>