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
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/limit-patent-effect.en.html" -->
<!--#include virtual="/server/header.fr.html" -->
<!-- Parent-Version: 1.79 -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title>Protéger le secteur du logiciel des brevets - Projet GNU - Free Software
Foundation</title>
<!--#include virtual="/philosophy/po/limit-patent-effect.translist" -->
<!--#include virtual="/server/banner.fr.html" -->
<h2>Protéger le secteur du logiciel des brevets</h2>
<p>par <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
<p><em>Une première version de cet article a été publiée sur <a
href="http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/">Wired</a>
en novembre 2012.</em></p>
<p>Les brevets menacent chaque concepteur de logiciel, et les guerres de brevet
que nous avons longtemps craintes ont éclaté. Les développeurs et les
utilisateurs – soit, dans notre société, la plupart des gens – ont besoin de
logiciels libres de tout brevet.</p>
<p>Les brevets qui nous menacent sont souvent appelés « brevets logiciels »,
mais ce terme est trompeur. Ces brevets ne concernent aucun programme en
particulier. En fait, chaque brevet décrit une idée applicable en pratique,
et affirme que quiconque utilise cette idée peut être poursuivi en
justice. Il est donc plus clair de les appeler « brevets sur des idées
informatiques », ou « brevets sur des algorithmes ».</p>
<p>Le système de brevets américain ne différencie pas les « brevets logiciels »
des autres. Seuls les développeurs font la distinction entre les brevets qui
nous menacent – ceux qui concernent des idées pouvant être implémentées dans
des logiciels – et les autres. Par exemple : si l'idée brevetée est la forme
d'une structure physique ou une réaction chimique, aucun programme ne peut
implémenter cette idée ; ce brevet ne menace pas le secteur du logiciel. Si
par contre l'idée qui est brevetée est un algorithme, alors le canon de ce
brevet est braqué sur les développeurs et les utilisateurs.</p>
<p>Cela ne veut pas dire que les brevets couvrant des algorithmes concernent
seulement les logiciels. Ces idées peuvent être aussi implémentées dans du
matériel… et beaucoup d'entre elles l'ont été. Chaque brevet couvre
typiquement les implémentations matérielles <em>et</em> logicielles de
l'idée.</p>
<h3>Le problème particulier du logiciel</h3>
<p>Toujours est-il que c'est dans le domaine du logiciel que les brevets sur
des algorithmes posent un problème particulier. Il est facile de combiner
des milliers d'idées dans un seul programme. Si dix pour cent de ces idées
sont brevetées, cela signifie que des centaines de brevets le menacent.</p>
<p>Quand Dan Ravicher, de la <cite>Public Patent Foundation</cite> (Fondation
publique des brevets) a étudié en 2004 un programme de taille importante
(Linux, qui est le noyau du système d'exploitation <a
href="/gnu/gnu-linux-faq.html">GNU/Linux</a>), il a trouvé 283 brevets
américains qui semblaient couvrir des algorithmes implémentés dans son code
source. Cette année-là, on estimait la part de Linux dans le système
GNU/Linux complet à 0,25 pour cent. En multipliant 300 par 400, on peut
estimer que le nombre de brevets qui menacent le système dans son ensemble
est de l'ordre de 100 000.</p>
<p>Si la moitié de ces brevets était supprimée pour cause de « mauvaise
qualité » – c'est-à-dire pour cause de ratés du système de brevets – cela ne
changerait pas grand-chose. Que ce soit 100 000 ou 50 000 brevets, la
catastrophe est la même. C'est pourquoi c'est une erreur de limiter nos
critiques des brevets logiciels aux seuls <cite>patent trolls</cite> ou aux
brevets de « mauvaise qualité ». En ce sens Apple, qui n'est pas un
« troll » selon la définition habituelle, est actuellement l'entreprise la
plus dangereuse quand elle se sert de ses brevets pour attaquer les
autres. Je ne sais pas si les brevets d'Apple sont de « bonne qualité »,
mais plus la « qualité » du brevet est élevée, plus la menace est grande.</p>
<p>Nous devons corriger l'ensemble du problème, pas seulement une partie.</p>
<p>Pour corriger le problème sur le plan législatif, on suggère habituellement
de changer les critères d'octroi des brevets – par exemple, d'interdire la
délivrance de brevets sur les pratiques algorithmiques et les systèmes
nécessaires à leur mise en œuvre. Mais cette approche a deux inconvénients.</p>
<p>Premièrement, les avocats reformulent les brevets de manière astucieuse pour
qu'ils correspondent à toute règle applicable ; ils transforment toute
tentative de limiter un brevet sur le fond en une simple exigence de
forme. Par exemple, de nombreux brevets américains sur des algorithmes
décrivent un système qui comprend une unité de traitement arithmétique, un
séquenceur d'instruction, une mémoire ainsi que des contrôles pour mener à
bien un calcul précis. C'est une manière assez particulière de décrire un
programme tournant sur un ordinateur pour effectuer un certain calcul ; elle
a été élaborée pour que la demande de brevet se conforme aux critères que,
pendant quelque temps, l'on a cru être ceux du système américain de brevets.</p>
<p>Deuxièmement, les États-Unis ont déjà plusieurs milliers de brevets sur des
algorithmes, et changer les critères pour empêcher d'en créer d'autres ne
permettrait pas de se débarrasser de ceux qui existent. Il faudrait attendre
pratiquement 20 ans avant que le problème ne soit entièrement résolu du fait
de l'expiration des brevets. Et abolir les brevets existants par la loi est
probablement anticonstitutionnel (de manière assez perverse, la Cour suprême
a insisté pour que le Congrès puisse étendre les privilèges privés au
détriment des droits du public mais ne puisse pas aller dans l'autre
direction).</p>
<h3>Une approche différente : limiter l'effet des brevets, pas la brevetabilité</h3>
<p>Ma proposition est de changer <em>l'effet</em> des brevets. Il faut inscrire
dans la loi que développer, distribuer ou exécuter un programme sur du
matériel informatique de consommation courante ne constitue pas une
violation de brevet. Cette approche a plusieurs avantages :</p>
<ul>
<li>elle n'impose pas de classer les brevets selon qu'ils sont logiciels ou
non ;</li>
<li>elle apporte aux développeurs ainsi qu'aux utilisateurs une protection
contre les brevets sur des algorithmes, existants ou futurs ;</li>
<li>les avocats spécialistes des brevets ne peuvent plus trouver d'échappatoire
en changeant la formulation de leurs demandes.</li>
</ul>
<p>Cette approche n'invalide pas entièrement les brevets existants sur des
algorithmes, parce qu'ils continueront à s'appliquer aux implémentations
utilisant du matériel dédié. C'est un avantage dans le sens que cela
supprime un argument mettant en question la validité de cette proposition du
point de vue législatif. Les États-Unis ont légiféré il y a quelques années
afin d'immuniser les chirurgiens contre les procès en contrefaçon de brevet,
de sorte que même si des procédures chirurgicales sont brevetées, les
chirurgiens sont protégés. Cela fournit un précédent pour ce type de
solution.</p>
<p>Les développeurs et les utilisateurs de logiciels ont besoin de protection
contre les brevets. Cette proposition est la seule solution législative qui
apporte une protection totale à tous. Nous pourrions ensuite retourner à
notre monde de concurrence ou de coopération… sans craindre qu'un
inconnu ne vienne balayer notre travail.</p>
<p><em>Voir également : <a
href="/philosophy/patent-reform-is-not-enough.html">Une réforme des brevets
n'est pas suffisante</a></em></p>
<div class="translators-notes">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
</div>
</div>
<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.fr.html" -->
<div id="footer">
<div class="unprintable">
<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. Il existe aussi <a
href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
orphelins et autres corrections ou suggestions peuvent être signalés à <a
href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a>.</p>
<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
replace it with the translation of these two:
We work hard and do our best to provide accurate, good quality
translations. However, we are not exempt from imperfection.
Please send your comments and general suggestions in this regard
to <a href="mailto:web-translators@gnu.org">
<web-translators@gnu.org></a>.</p>
<p>For information on coordinating and submitting translations of
our web pages, see <a
href="/server/standards/README.translations.html">Translations
README</a>. -->
Nous faisons le maximum pour proposer des traductions fidèles et de bonne
qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
sur cette page, ainsi que vos suggestions d'ordre général sur les
traductions, à <a href="mailto:web-translators@gnu.org">
<web-translators@gnu.org></a>.</p>
<p>Pour tout renseignement sur la coordination et la soumission des
traductions de nos pages web, reportez-vous au <a
href="/server/standards/README.translations.html">guide de traduction</a>.</p>
</div>
<!-- Regarding copyright, in general, standalone pages (as opposed to
files generated as part of manuals) on the GNU web server should
be under CC BY-ND 4.0. Please do NOT change or remove this
without talking with the webmasters or licensing team first.
Please make sure the copyright date is consistent with the
document. For web pages, it is ok to list just the latest year the
document was modified, or published.
If you wish to list earlier years, that is ok too.
Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
years, as long as each year in the range is in fact a copyrightable
year, i.e., a year in which the document was published (including
being publicly visible on the web or in a revision control system).
There is more detail about copyright years in the GNU Maintainers
Information document, www.gnu.org/prep/maintain. -->
<p>Copyright © 2012, 2013, 2015, 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 : Framalang (satbadkd, Thérèse, DarthMickey, geecko, Marc, igor,
EEva, greygjhart)<br /> Révision : <a
href="mailto:trad-gnu@april.org">trad-gnu@april.org</a></div>
<p class="unprintable"><!-- timestamp start -->
Dernière mise à jour :
$Date: 2018/09/07 09:58:14 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>
|
