patent-practice-panel.html (15068B)
1 <!--#set var="ENGLISH_PAGE" value="/philosophy/patent-practice-panel.en.html" --> 2 3 <!--#include virtual="/server/header.fr.html" --> 4 <!-- Parent-Version: 1.96 --> 5 <!-- This page is derived from /server/standards/boilerplate.html --> 6 <!--#set var="TAGS" value="thirdparty" --> 7 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" --> 8 9 <!-- This file is automatically generated by GNUnited Nations! --> 10 <title>Présentation de Daniel Ravicher à la table ronde de la FFII - Projet GNU - 11 Free Software Foundation</title> 12 13 <!--#include virtual="/philosophy/po/patent-practice-panel.translist" --> 14 <!--#include virtual="/server/banner.fr.html" --> 15 <!--#include virtual="/philosophy/ph-breadcrumb.fr.html" --> 16 <!--GNUN: OUT-OF-DATE NOTICE--> 17 <!--#include virtual="/server/top-addendum.fr.html" --> 18 <div class="article reduced-width"> 19 <h2>Nouveaux développements dans la pratique des brevets : évaluer les risques 20 et les coûts d'un portefeuille de licences et des hold-ups dont il fait 21 l'objet</h2> 22 23 <address class="byline">par Daniel B. Ravicher</address> 24 25 <div class="infobox"> 26 <p>Ceci est la transcription d'une présentation donnée par Daniel B. Ravicher 27 en tant que directeur exécutif de la <i>Public Patent Foundation</i> 28 (Fondation publique pour les brevets) le mercredi 10 novembre 2004, à une 29 conférence organisée par la <i>Foundation for a Free Information 30 Infrastructure</i> (Fondation pour une Infrastructure d'Information Libre) à 31 Bruxelles (Belgique). La transcription a été faite par Ændrew Rininsland.</p> 32 33 <p>Le projet GNU est d'accord avec le principe que <a 34 href="/philosophy/limit-patent-effect.html">les brevets sur les idées 35 informatiques sont à proscrire</a>, mais rejette le présupposé que les 36 programmes non libres seraient des concurrents moralement légitimes.</p> 37 </div> 38 <hr class="thin" /> 39 40 <p>Merci. Je pense, en ce qui me concerne, que ces deux journées de conférences 41 reviennent en fait à une question, que tout le débat se résume à une seule 42 question : « Comment voulons-nous déterminer la réussite dans l'industrie du 43 logiciel ? » 44 </p> 45 46 <p> 47 Ou, autrement dit, qui préférons-nous pour déterminer ceux qui réussissent 48 et ceux qui échouent dans l'industrie du logiciel ? Parce qu'il y a diverses 49 personnes qui peuvent prendre cette décision. Nous pouvons faire prendre la 50 décision de qui réussit et qui échoue par des bureaucrates, ou nous pouvons 51 laisser les consommateurs prendre cette décision, de qui réussit et qui 52 échoue. Si nous voulons qu'un logiciel réussisse parce que nous voulons 53 qu'il ait du succès sur la base de ses mérites et soit le meilleur logiciel 54 que le public puisse avoir, nous voulons très probablement un système qui 55 laisse aux consommateurs et aux utilisateurs le soin de décider quels 56 logiciels choisir – pas aux bureaucrates. 57 </p> 58 59 <p> Alors, quel est le rapport avec les brevets ? Plus vous faites un système de 60 brevets étendu, plus vous permettez au système de brevets d'avoir un impact 61 sur le logiciel et plus vous permettez que la réussite dans l'industrie du 62 logiciel soit déterminée par des bureaucrates se basant sur les brevets, 63 ceux-là même qui peuvent tirer profit de la bureaucratie qui accorde les 64 brevets et résout les contestations qui les concernent. C'est une 65 concurrence bureaucratique qui n'est pas basée sur la décision des 66 consommateurs. Elle diminue la probabilité que les mérites soient 67 déterminants dans le succès de tel ou tel logiciel. 68 </p> 69 70 <p> 71 Nous devons reconnaître que même sans brevets logiciels, les grands 72 développeurs ont des avantages intrinsèques sur les petits développeurs. Les 73 grands développeurs ont les ressources, les grands développeurs ont les 74 relations, les grands développeurs ont les canaux de distribution, les 75 grands développeurs ont la marque. Alors, même sans brevets logiciels, les 76 grands développeurs ont toujours un avantage ; ils ont un avantage au 77 départ. Alors, la question qui me vient, c'est : « Si nous avons des brevets 78 logiciels, est-ce que cela augmente l'avantage des grands développeurs ou 79 est-ce que cela le diminue ? » Parce que le système de brevets pourrait 80 bénéficier aux petits développeurs et donc pourrait éroder certains des 81 avantages qu'ont naturellement les grandes sociétés. 82 </p> 83 84 <p> 85 Je pense qu'on a déjà fait le tour de cette question. Nous savons que les 86 petits développeurs ne profitent pas d'un système de brevets. En fait, un 87 système de brevets leur nuit. Ainsi, étendre un système de brevets pour 88 l'appliquer au développement logiciel ne fait qu'augmenter les désavantages 89 que les petits développeurs ont déjà dans la concurrence. Et on en revient 90 toujours à ça : qui voulons-nous pour décider de la réussite des 91 développeurs de logiciel ? Voulons-nous que ce soient les consommateurs, en 92 se basant sur les mérites, la fonctionnalité et le prix, ou des 93 bureaucrates, en se basant sur les sociétés à qui les brevets sont accordés 94 et sur les gagnants dans les affaires de violation de brevets ? 95 </p> 96 97 <p> 98 L'autre chose que nous devons reconnaître est que le système de brevets a 99 une préférence pour les utilisateurs de certains types de logiciels. Un 100 système de brevets comme celui que nous avons aux États-Unis bénéficie à 101 ceux qui sont sous un régime de distribution de logiciel qui leur permet de 102 faire payer des royalties. C'est parce que tous les logiciels doivent faire 103 face au risque de violation de brevets. Les brevets ne font pas la 104 distinction entre open source ou logiciels sous licence libre, et logiciels 105 privateurs<a id="TransNote1-rev" href="#TransNote1"><sup>1</sup></a> : un 106 brevet couvre une certaine technologie, il ne se soucie pas de la façon dont 107 le logiciel est distribué. Mais les logiciels privateurs sont sous licence 108 payante et donc le coût de ce risque peut être transmis aux consommateurs 109 sans qu'ils s'en rendent compte. Ils ne le voient pas, c'est inclus dans le 110 prix du logiciel qu'ils achètent, et si vous demandiez à un consommateur 111 s'il s'est assuré contre des poursuites pour violation de brevets, il dirait 112 qu'il ne pense pas l'avoir fait. 113 Mais en fait, il l'a fait, parce que si quelqu'un poursuit un utilisateur de 114 logiciel provenant de Microsoft, Microsoft a inclus dans le prix de la 115 licence les frais de procédure pour le défendre. En revanche, si vous avez 116 un logiciel distribué sans royalties tel que l'open source ou le logiciel 117 libre, vous ne pouvez pas inclure le coût de ce risque, qui ainsi devient 118 plus transparent. Et ceci incite les consommateurs ou les utilisateurs à 119 penser que l'open source est en plus mauvaise position que le logiciel 120 privateur alors qu'en réalité il ne l'est pas. C'est juste parce que le mode 121 de distribution de l'open source ne permet pas à quelqu'un d'incorporer 122 furtivement le coût de ce risque pour le rendre opaque plutôt que 123 transparent. Ainsi, non seulement le système de brevets préfère les grands 124 développeurs aux petits développeurs, mais il préfère également les 125 utilisateurs de logiciels privateurs aux utilisateurs de logiciels open 126 source. 127 </p> 128 129 <p> 130 Si nous revenons à la question initiale qui, je pense, est la question 131 fondamentale, comment voulons-nous que le succès dans le marché du logiciel 132 soit déterminé ? Voulons-nous qu'il soit déterminé par ce type de facteurs, 133 ou voulons-nous qu'il soit déterminé par l'obtention du meilleur logiciel au 134 meilleur prix ? 135 </p> 136 137 <p> 138 Avant cela, je pense qu'il est important d'admettre le point de vue que les 139 gens auront de l'autre côté, qui est : est-ce qu'un système de brevets moins 140 onéreux (ou « moins bénéfique » comme ils diraient – je dis moins onéreux) 141 nuira à leurs affaires, parce que les gens pourraient les copier ? Eh bien, 142 les grandes entreprises ne s'inquiètent pas d'être copiées. Elles ne s'en 143 inquiètent vraiment pas. Du moins pas par d'autres grandes entreprises, 144 c'est pourquoi elles font des licences croisées tout le temps. 145 Si une grande entreprise ne voulait vraiment pas que ses logiciels soient 146 copiés, pourquoi ferait-elle des concessions de son portefeuille de licences 147 à toutes les autres grandes entreprises du monde, puisque ça ne peut pas les 148 empêcher de copier une fois que cet accord est conclu ? Donc cet argument 149 selon lequel « Mais si, cela nous préoccupe qu'on copie nos 150 logiciels »… Les personnes les plus susceptibles de copier vos 151 logiciels sont d'autres grandes entreprises, parce qu'elles ont les 152 ressources, la capacité, les canaux de distribution, la marque et les 153 relations. Pourquoi les laissez-vous les copier ? Ça ne doit pas vous 154 préoccuper tant que ça. 155 </p> 156 157 <p> 158 La question est donc : un système de brevets a-t-il un effet net bénéfique 159 ou un effet net néfaste sur le développement logiciel ? Nous avons déjà vu, 160 je pense, que son seul effet est de diminuer la capacité de l'open source ou 161 du logiciel sous licence gratuite à concurrencer le logiciel privateur. Au 162 final, vous devez vous demander : est-ce que moins de concurrence est 163 bénéfique pour l'industrie du logiciel ? Je ne sais pas ce que les Européens 164 en pensent, je pense que les Européens sont clairement pour la concurrence, 165 et je sais que nous de l'autre côté de l'Atlantique sommes clairement pour 166 la concurrence aussi, et donc la réponse n'est jamais que moins de 167 concurrence soit meilleure pour les consommateurs. Je pense qu'il faut être 168 extrêmement clair ; si nous avions deux secondes dans un ascenseur pour 169 vendre cette idée à quelqu'un, les brevets logiciels ont un effet net 170 négatif sur la concurrence dans l'industrie du logiciel. 171 C'est vrai, ils peuvent à certains égards augmenter la concurrence, mais 172 l'effet net est anticoncurrentiel. Et c'est ce qui se passe quand on met la 173 capacité à décider de la réussite dans l'industrie du logiciel entre les 174 mains de l'office des brevets ou des tribunaux. Si vous avez besoin 175 d'exemples, si les gens pensent que c'est juste de la rhétorique ou juste 176 votre avis personnel, citez l'exemple des États-Unis. Microsoft est une 177 entreprise de logiciel couronnée de succès, je ne pense pas que quiconque 178 remettrait cela en question. Ils ne se sont jamais retrouvés à poursuivre 179 quelqu'un pour violation de brevet. Donc ils prétendent qu'ils ont besoin de 180 brevets, cependant ils n'ont jamais eu à s'en servir. Ils font des licences 181 croisées et c'est là que nous nous demandons : « Si cela vous préoccupe que 182 des gens copient, alors pourquoi faire des licences croisées avec eux ? » 183 </p> 184 185 <p> 186 Ce qui nous amène au dernier point : à qui d'autre un système de brevets 187 bénéficie-t-il ? S'il bénéficie aux grands développeurs plutôt qu'aux petits 188 développeurs, y en a-t-il d'autres ? Un système de brevets bénéficie aux 189 non-développeurs. Voulons-nous vraiment un système bureaucratique qui aide 190 des gens qui n'apportent rien à la société ? Ce que j'entends par 191 non-développeurs, ce sont les trolls, dont tout le monde ici est familier ; 192 des gens qui obtiennent un brevet, soit en en faisant la demande, soit en 193 l'acquérant avec un certain achat de valeurs, et puis qui l'utilisent pour 194 taxer d'autres développeurs, d'autres distributeurs d'un produit. 195 </p> 196 197 <p> 198 Voulons-nous vraiment d'un système qui encourage les gens à ne pas ajouter 199 de produits ni de services sur le marché mais à simplement amoindrir les 200 bénéfices et les possibilités de ceux qui le font ? 201 </p> 202 </div> 203 204 <div class="translators-notes"> 205 206 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> 207 <hr /><b>Note de traduction</b><ol> 208 <li><a id="TransNote1" href="#TransNote1-rev" 209 class="nounderline">↑</a> 210 Autre traduction de <i>proprietary</i> : propriétaire.</li></ol></div> 211 </div> 212 213 <!-- for id="content", starts in the include above --> 214 <!--#include virtual="/server/footer.fr.html" --> 215 <div id="footer" role="contentinfo"> 216 <div class="unprintable"> 217 218 <p>Veuillez envoyer les requêtes concernant la FSF et GNU à <<a 219 href="mailto:gnu@gnu.org">gnu@gnu.org</a>>. Il existe aussi <a 220 href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens 221 orphelins et autres corrections ou suggestions peuvent être signalés à 222 <<a href="mailto:webmasters@gnu.org">webmasters@gnu.org</a>>.</p> 223 224 <p> 225 <!-- TRANSLATORS: Ignore the original text in this paragraph, 226 replace it with the translation of these two: 227 228 We work hard and do our best to provide accurate, good quality 229 translations. However, we are not exempt from imperfection. 230 Please send your comments and general suggestions in this regard 231 to <a href="mailto:web-translators@gnu.org"> 232 233 <web-translators@gnu.org></a>.</p> 234 235 <p>For information on coordinating and contributing translations of 236 our web pages, see <a 237 href="/server/standards/README.translations.html">Translations 238 README</a>. --> 239 Merci d'adresser vos commentaires sur les pages en français à <<a 240 href="mailto:trad-gnu@april.org">trad-gnu@april.org</a>>, et sur les 241 traductions en général à <<a 242 href="mailto:web-translators@gnu.org">web-translators@gnu.org</a>>. Si 243 vous souhaitez y contribuer, vous trouverez dans le <a 244 href="/server/standards/README.translations.html">guide de traduction</a> 245 les infos nécessaires.</p> 246 </div> 247 248 <!-- Regarding copyright, in general, standalone pages (as opposed to 249 files generated as part of manuals) on the GNU web server should 250 be under CC BY-ND 4.0. Please do NOT change or remove this 251 without talking with the webmasters or licensing team first. 252 Please make sure the copyright date is consistent with the 253 document. For web pages, it is ok to list just the latest year the 254 document was modified, or published. 255 256 If you wish to list earlier years, that is ok too. 257 Either "2001, 2002, 2003" or "2001-2003" are ok for specifying 258 years, as long as each year in the range is in fact a copyrightable 259 year, i.e., a year in which the document was published (including 260 being publicly visible on the web or in a revision control system). 261 262 There is more detail about copyright years in the GNU Maintainers 263 Information document, www.gnu.org/prep/maintain. --> 264 <p>Copyright © 2006 Daniel B. Ravicher</p> 265 266 <p>La reproduction exacte et la distribution intégrale de cet article sont 267 permises sur n'importe quel support d'archivage, pourvu que le présent avis 268 soit conservé.</p> 269 270 <!--#include virtual="/server/bottom-notes.fr.html" --> 271 <div class="translators-credits"> 272 273 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> 274 Traduction : Ewens<br /> Révision : <a 275 href="mailto:trad-gnu@april.org">trad-gnu@april.org</a></div> 276 277 <p class="unprintable"><!-- timestamp start --> 278 Dernière mise à jour : 279 280 $Date: 2022/05/31 15:30:56 $ 281 282 <!-- timestamp end --> 283 </p> 284 </div> 285 </div> 286 <!-- for class="inner", starts in the banner include --> 287 </body> 288 </html>