summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/fr/rms-patents.html
blob: f3790674849ac32d15e4402d7eab09af0ca87490 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
<!--#set var="ENGLISH_PAGE" value="/philosophy/rms-patents.en.html" -->

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

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Solutions du problème des brevets logiciels - Projet GNU - Free Software
Foundation</title>

<!--#include virtual="/philosophy/po/rms-patents.translist" -->
<!--#include virtual="/server/banner.fr.html" -->
<h2>Solutions du problème des brevets logiciels</h2>

<p>par <strong>Richard Stallman</strong></p>

<p><em>Conférence donnée au Locatelli Center, Université de Santa Clara, en
novembre 2012</em>&nbsp; (<a
href="//audio-video.gnu.org/video/keynote-what-is-the-problem.webm">vidéo</a>,
&nbsp;<a href="//audio-video.gnu.org/video/#2012">métadonnées</a>)</p>
<hr />

<p><b>Andrew Chen :</b> Merci, Eric.</p>

<p>Je m'appelle Andrew Chen. J'enseigne le droit des brevets à l'Université de
Caroline du Nord et dans une vie antérieure j'étais professeur
d'informatique théorique.</p>

<p>J'ai le rôle le plus facile aujourd'hui : présenter deux personnes qui n'ont
pas besoin de l'être. Richard Stallman, on le sait, est le fondateur du
mouvement du logiciel libre, le cofondateur de la <cite>League for
Programming Freedom</cite> (Ligue pour la liberté de programmer),
l'architecte logiciel en chef du projet GNU et l'auteur d'Emacs, qu'il a
défini comme un éditeur de texte mais aussi comme un mode de vie. Ce dont je
conviens volontiers puisque j'ai écrit ma thèse en utilisant son programme.</p>

<p>Dr Stallman a decidé de ne pas participer au streaming en direct
aujourdhui. Il explique que l'utilisation du streaming en ligne requiert
l'utilisation du plugin Silverlight de Microsoft, ce qui oblige les gens à
utiliser un logiciel privateur. Dr Stallman considère qu'inciter les gens à
faire ça n'est pas bien. Il voudrait que vous sachiez qu'il a l'intention,
plus tard, de rendre disponible un enregistrement de sa présentation au
format Ogg Theora ou WebM.</p>

<p>Dr Stallman.</p>

<p>[applaudissements]</p>

<p><b>Richard Stallman :</b> S'il vous plaît, est-ce que les techniciens
peuvent confirmer que la diffusion est coupée ?</p>

<p>OK, je pense que c'est une confirmation.</p>

<p>Pourquoi les brevets logiciels sont-ils mauvais ? Ou plutôt les « brevets
sur des idées informatiques », comme à mon avis nous devrions vraiment les
appeler. La plupart des gens, quand vous dites « brevets logiciels »,
pensent qu'il est question de breveter un programme spécifique. Vous savez
tous, j'en suis sûr, que ce n'est pas ce que font ces brevets, mais la
plupart des gens ne le savent pas. Donc, pour essayer d'éviter les
malentendus, je les appelle « brevets sur des idées informatiques ».</p>

<p>Quoi qu'il en soit, la raison pour laquelle ils sont mauvais est qu'ils
privent les gens de la liberté d'utiliser leurs ordinateurs comme ils
l'entendent et d'effectuer leurs tâches informatiques comme ils le
souhaitent, liberté que chacun doit posséder. Ces brevets sont un danger
pour tous les développeurs de logiciel comme pour leurs utilisateurs et nous
n'avons aucune raison de le tolérer. Aussi devons-nous protéger le logiciel
contre les brevets. Le logiciel a certes besoin d'être protégé, mais c'est
contre les brevets.</p>

<p>Cependant la plupart des gens n'en savent pas assez sur les effets des
brevets pour comprendre pourquoi les brevets qui restreignent les logiciels
sont nocifs. La plupart des gens pensent que les brevets sont comme les
copyrights, ce qui n'est pas vrai du tout. Tout ce qu'ils ont en commun
tient dans une phrase de la Constitution et cette similarité est si ténue et
si abstraite qu'elle n'a rien à voir avec leurs conséquences pratiques.</p>

<p>Donc, la dernière des choses à faire est d'utiliser le terme « propriété
intellectuelle », qui confond non seulement ces deux lois, mais un tas
d'autres lois disparates et non apparentées qui n'ont même pas en commun une
seule phrase de la Constitution avec les deux premières. Ce terme est source
de confusion chaque fois qu'il est utilisé et il y a huit ans j'ai décidé
que je ne devais plus l'employer ; je ne l'ai jamais utilisé depuis. Son
usage est étonnamment facile à éviter, car en général on l'utilise pour la
seule raison que c'est chic. Et une fois que vous avez appris à résister à
ça, c'est facile comme bonjour ; vous vous contentez de parler d'une loi en
particulier, vous l'appelez par son nom et vous faites une phrase cohérente
et claire.</p>

<p>Je dois expliquer aux gens les effets des brevets et leur montrer que ce ne
sont pas du tout les mêmes que ceux des copyrights. Un bon moyen est de
procéder par analogie. Qu'est-ce qu'on peut dire des programmes ? Eh bien,
que ce sont des œuvres de grande envergure, avec un grand nombre d'éléments
qui doivent tous interagir pour donner le résultat désiré. De quoi peut-on
aussi dire ça ? D'un roman, d'une symphonie.

Imaginez que les gouvernements européens du 18e siècle aient eu l'idée
farfelue de promouvoir le progrès de la musique symphonique par un système
de « brevets sur les idées musicales ». Toute idée musicale exprimable par
des mots aurait ainsi pu être brevetée. Un motif mélodique aurait pu être
breveté, ou bien une série d'accords, un schéma rythmique, un schéma de
répétitions dans un mouvement, l'utilisation de certains instruments alors
que le reste de l'orchestre ne joue pas et un tas d'autre idées musicales
qui ne me viennent pas à l'esprit, mais qui viendraient peut-être à celui
d'un compositeur.</p>

<p>Imaginez maintenant qu'on est en 1800, que vous êtes Beethoven et que vous
voulez écrire une symphonie. Vous vous rendez compte qu'il est plus
difficile d'écrire une symphonie en ne risquant pas un procès que d'écrire
une bonne symphonie. Vous vous en seriez sans doute plaint et les détenteurs
des brevets auraient dit « Oh, Beethoven, tu es simplement jaloux parce que
nous avons eu ces idées avant toi. Tu n'as qu'à chercher quelques idées bien
à toi. »
Beethoven est bien sûr considéré comme un grand compositeur parce qu'il a eu
beaucoup d'idées nouvelles. Mais pas seulement ; il savait aussi les mettre
en œuvre de manière effective, c'est-à-dire en les combinant avec beaucoup
d'idées connues, de sorte que ses morceaux ne choquaient qu'au début mais
qu'ensuite on s'y habituait. Ils n'étaient pas étranges et incompréhensibles
au point de susciter le rejet. Ils choquaient le public pendant quelque
temps, puis celui-ci s'y habituait et maintenant nous n'y voyons plus rien
de choquant parce que nous sommes habitués à ces idées. Cela prouve qu'il
les a bien utilisées.</p>

<p>Donc l'idée que n'importe qui pourrait, ou devrait, réinventer la musique à
partir de zéro est absurde. Même Beethoven ne pourrait le faire et il serait
idiot de demander à quelqu'un d'essayer. C'est pareil en informatique. C'est
comme une symphonie qui met en œuvre beaucoup d'idées musicales à la
fois. Mais la difficulté n'est pas de choisir un tas d'idées, c'est de les
mettre en œuvre toutes ensemble en utilisant des notes. C'est pareil avec le
logiciel. Un grand programme va mettre en œuvre des milliers d'idées à la
fois. Mais ce qui est difficile, ce n'est pas de choisir quelques idées,
c'est de toutes les combiner et que ça fonctionne correctement.</p>

<p>Les « brevets sur les idées informatiques » font obstacle à cette lourde et
difficile tâche en promouvant des ressources que nous avons à profusion de
toute manière. C'est donc un système mal conçu, qui prétend nous fournir une
aide dont nous ne voulons pas, au prix d'énormes problèmes.</p>

<p>Ce dont nous avons besoin est de nous débarrasser du problème. Quel est ce
problème ? C'est que les brevets constituent une menace pour les
développeurs et les utilisateurs. Ils les mettent en danger. Comment
l'empêcher ? Eh bien, l'un des moyens est de ne pas délivrer de brevets
portant sur les logiciels. Cela fonctionne si c'est appliqué dès le
début. Si un pays n'a jamais délivré de tels brevets, son système de brevets
ne menace pas le logiciel. OK, c'est une bonne solution. Mais elle n'est pas
applicable si le pays a déjà délivré des centaines de milliers de brevets
logiciels.</p>

<p>J'ai proposé que les constitutions disposent explicitement que les
privilèges des brevets puissent être réduits aussi bien qu'augmentés ;
qu'ils ne soient en aucune façon la propriété de quelqu'un, mais des
privilèges octroyés par le gouvernement et pouvant être modifiés à
volonté. Après tout, si la loi permet au gouvernement de les augmenter, il
est absurde d'en faire un cliquet à sens unique. Mais cela ne figure pas
dans la Constitution des États-Unis.</p>

<p>Alors, qu'est-ce qu'on peut faire ? On peut demander aux tribunaux de
décider que tout brevet restreignant le logiciel était invalide depuis
l'origine et l'a toujours été ; cela les élimine tous. Cependant, on ne peut
pas faire du lobbying pour ça. On ne peut pas dire aux fonctionnaires
« Faites ceci parce que nous voulons que vous le fassiez. »</p>

<p>Si nous voulons une solution que nous puissions faire appliquer, qu'est-ce
qu'il nous reste ? Eh bien, le seul moyen, à mon avis, est que le logiciel
soit reconnu par la loi comme une « sphère de sécurité ». Si c'est du
logiciel, on est en sécurité. Des circuits effectuant le même calcul
seraient couverts par un brevet, mais si c'est du logiciel, alors on est en
sécurité. Mais qu'est-ce que cela signifie « être du logiciel » ? Eh bien,
c'est ce qui fonctionne sur une machine polyvalente, universelle. Donc on
fait d'abord une machine universelle et ensuite on y insère le programme
pour qu'il lui dise quoi faire. Si la seule fonction de la machine est
d'être universelle, alors toute idée spécifique, brevetée, est implémentée
par le programme.</p>

<p>C'est à ça que je veux arriver et j'essaie de distinguer ce cas d'une
affaire comme <cite>Diamond vs. Diehr</cite> où il y avait un brevet pour un
système, une méthode de vulcanisation. Son application nécessitait un
ordinateur, mais également du matériel à usage spécifique, pas une machine
polyvalente, universelle, et ce matériel à usage spécifique était essentiel
à la mise en œuvre de la technique brevetée.
En fait, ce n'était pas une technique logicielle. Et j'ai lu un article de
Pamela Samuelson dont l'argument était que la <abbr title="Court of Appeals
for the Federal Circuit">CAFC</abbr><a id="TransNote1-rev"
href="#TransNote1"><sup>1</sup></a> avait détourné cette décision ; en gros,
qu'elle s'était trompée dans l'ordre des quantificateurs.<a
id="TransNote2-rev" href="#TransNote2"><sup>2</sup></a> La Cour suprême
avait dit « le fait qu'il y a un ordinateur là-dedans ne le rend pas
automatiquement non brevetable », et la CAFC avait déformé la phrase en
« l'ordinateur le rend brevetable ».</p>

<p>Quoi qu'il en soit, on pourrait peut-être fonder quelque espoir sur les
tribunaux, mais je propose une méthode qui distinguera d'une part les cas
que nous devons protéger, et d'autre part les brevets sur des idées non
informatiques affectant des systèmes qui pourraient être mis en œuvre au
moyen d'un ordinateur quelque part à l'intérieur. Quels mots précis
utiliser ? Eh bien, ce que j'ai pu trouver de mieux était : « logiciel
fonctionnant sur du matériel informatique d'usage général ». Nous voulons
certainement que cela couvre des choses comme les smartphones ; nous ne
voulons rien exclure qui contienne un quelconque matériel à usage
spécifique.
Le téléphone portable contient évidemment du matériel spécialisé permettant
de parler au réseau téléphonique, mais cela ne doit pas signifier
automatiquement que tout ce qui fonctionne sur un téléphone portable est
vulnérable aux brevets, parce que le téléphone est un ordinateur polyvalent
que les gens utilisent pour toutes sortes de choses. Mais ma formulation
« matériel informatique d'usage général » n'est peut-être pas la
meilleure. Cela à mon avis demande à être étudié, parce que nous devons
examiner chaque formulation possible et voir quels cas seraient protégés
contre les brevets et lesquels seraient exposés, pour arriver à la bonne
méthode.</p>

<p>Chaque fois que je suggère une méthode pour résoudre ce problème, la
première chose que les gens essaient de chercher, c'est plutôt comment le
résoudre à moitié. L'idée de résoudre le problème une fois pour toutes les
choque parce qu'elle leur apparaît comme radicale. Ils pensent « Je ne peux
pas militer pour quelque chose d'aussi radical qu'une solution vraiment
complète de ce problème. Il faut que je cherche une solution partielle qui
protégera seulement certains développeurs de logiciel. »
Eh bien, c'est une erreur. C'est une erreur a) parce que cela ne ferait pas
le travail complètement et b) parce que ce serait plus difficile à faire
passer. Il y a beaucoup de développeurs de logiciel et ils sont tous
menacés. Si nous proposons de les protéger tous, ils auront tous une raison
de donner leur appui. Mais si nous proposons d'en protéger seulement
quelques-uns, les autres diront « Cela ne me sert à rien, pourquoi m'y
intéresser ? »</p>

<p>Donc proposons une vraie solution. D'autant plus que les solutions
partielles tendent à être vulnérables au problème que Boldrin et Levine ont
très bien décrit, à savoir qu'il est facile aux groupes de pression
favorables aux brevets de repousser la limite si vous leur donnez une limite
quelconque à repousser. Ceci, incidemment, est un avantage supplémentaire en
faveur d'un changement dans les procédures judiciaires contre les gens
plutôt que dans ce qui est brevetable. Parce que là, le critère est
seulement « Quel genre de situation a-t-on ici ? »

C'est plus difficile d'élargir ce critère, et s'ils essayaient, ce serait
toujours dans un litige contre quelqu'un qui se battra pour ne pas
l'élargir. Il est ainsi moins vulnérable à une distorsion qui le ferait
passer de la restriction de substance qui était visée à l'origine à une
exigence de fait portant sur la forme des demandes de brevets, ce qui tend à
se produire quel que soit le type d'exigence concernant ce qui doit figurer
dans ces demandes.</p>

<p>Bon, voilà.</p>

<p>[applaudissements]</p>

<p><b>Andrew Chen :</b> Merci, Dr Stallman.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<hr /><b>Notes de traduction</b><ol>
<li id="TransNote1">Cour d'appel pour le circuit fédéral <a
href="#TransNote1-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote2">Voir le <a
href="https://fr.wikipedia.org/wiki/Calcul_des_pr%C3%A9dicats">calcul des
prédicats</a> <a href="#TransNote2-rev" class="nounderline">&#8593;</a></li>
</ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.fr.html" -->
<div id="footer">
<div class="unprintable">

<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Il existe aussi <a
href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
orphelins et autres corrections ou suggestions peuvent être signalés à <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Nous faisons le maximum pour proposer des traductions fidèles et de bonne
qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
sur cette page, ainsi que vos suggestions d'ordre général sur les
traductions, à <a href="mailto:web-translators@gnu.org">
&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Pour tout renseignement sur la coordination et la soumission des
traductions de nos pages web, reportez-vous au <a
href="/server/standards/README.translations.html">guide de traduction</a>.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 2016 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, Élodie, Thibaut et Mangeur de nuages<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: 2018/10/17 15:58:34 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>