fighting-software-patents.html (9409B)
1 <!--#set var="ENGLISH_PAGE" value="/philosophy/fighting-software-patents.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="essays laws patents" --> 7 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" --> 8 9 <!-- This file is automatically generated by GNUnited Nations! --> 10 <title>Combattre les brevets logiciels, individuellement et collectivement - Projet 11 GNU - Free Software Foundation</title> 12 13 <!--#include virtual="/philosophy/po/fighting-software-patents.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>Combattre les brevets logiciels, individuellement et collectivement</h2> 20 21 <address class="byline">par Richard Stallman</address> 22 23 <p> 24 Les brevets logiciels sont au projet logiciel l'équivalent d'un champ de 25 mines : chaque choix de conception comporte le risque de buter sur un 26 brevet, lequel peut détruire votre projet.</p> 27 <p> 28 Le développement d'un programme important et complexe implique de combiner 29 beaucoup d'idées, souvent des centaines ou des milliers. Dans un pays qui 30 autorise les brevets logiciels, il y a de fortes chances qu'une partie 31 substantielle des idées de votre programme soient déjà brevetées par 32 diverses sociétés. Il se peut que des centaines de brevets couvrent des 33 parties de votre programme. Une étude faite en 2004 a trouvé presque trois 34 cents brevets américains qui couvraient diverses parties d'un seul programme 35 important. Cela représente un tel travail de réaliser ce type d'étude, 36 qu'une seule a été réalisée.</p> 37 <p> 38 En pratique, si vous êtes développeur de logiciel, vous serez d'habitude 39 menacé par un brevet à la fois. Quand cela arrive, vous pouvez être en 40 mesure de vous en sortir indemne si vous trouvez des bases juridiques pour 41 invalider le brevet. Autant essayer ; si vous réussissez, cela signifiera 42 une mine de moins dans le champ de mines. Si ce brevet est particulièrement 43 menaçant pour le public, la <a 44 href="https://wiki.endsoftwarepatents.org/wiki/Public_Patent_Foundation">Public 45 Patent Foundation (pubpat.org)</a> peut prendre l'affaire en charge ; c'est 46 sa spécialité. Si vous demandez de l'aide à la communauté des utilisateurs 47 de l'informatique pour chercher une publication antérieure de la même idée à 48 utiliser comme preuve pour invalider un brevet, nous devons tous répondre 49 avec les informations utiles que nous pourrions avoir.</p> 50 <p> 51 Cependant, combattre les brevets un par un n'éliminera jamais le danger des 52 brevets logiciels, pas plus qu'écraser des moustiques n'éliminera la 53 malaria. Vous ne pouvez pas vous attendre à gagner contre chaque brevet que 54 vous rencontrerez, pas plus qu'à tuer tous les monstres dans un jeu vidéo : 55 tôt ou tard, un brevet aura raison de vous et dégradera votre 56 programme. L'Office américain des brevets et des marques (<abbr 57 title="United States Patent and Trademark Office">USPTO</abbr>) sort environ 58 cent mille brevets logiciels par an ; nos meilleurs efforts ne pourront 59 jamais désactiver ces mines aussi vite qu'ils les posent.</p> 60 <p> 61 Certaines d'entre elles sont impossibles à désactiver. Chaque brevet 62 logiciel est nuisible et chaque brevet logiciel restreint injustement la 63 façon dont vous utilisez votre ordinateur, mais tous les brevets ne sont pas 64 juridiquement invalides selon les critères du système de brevets. Les 65 brevets logiciels que nous pouvons invalider sont ceux qui résultent 66 d'« erreurs », où les règles de ce système n'ont pas été correctement 67 suivies. Il n'y a rien que nous puissions faire quand la seule erreur 68 significative a été de permettre l'attribution de brevets logiciels.</p> 69 <p> 70 Pour sécuriser une partie du château, vous devez faire plus que de tuer les 71 monstres lorsqu'ils apparaissent ; vous devez anéantir ce qui les 72 produit. Invalider les brevets existants un à un ne rendra pas la 73 programmation plus sûre. Pour cela, nous devons changer le système de 74 brevets de sorte que ces derniers ne puissent plus menacer les développeurs 75 de logiciels ni les utilisateurs.</p> 76 <p> 77 Il n'y a pas contradiction entre ces deux batailles : nous pouvons 78 travailler sur la correction à court terme et à long terme en même temps. Si 79 nous faisons attention, nous pouvons faire en sorte que nos efforts pour 80 invalider les brevets logiciels fassent double emploi, en fournissant de 81 l'aide aux efforts pour corriger tout le problème. Le point crucial est de 82 ne pas faire d'équivalence entre les « mauvais » brevets logiciels et les 83 brevets logiciels erronés ou invalides. Chaque fois que nous invalidons un 84 brevet logiciel, chaque fois que nous parlons de nos plans pour essayer, 85 nous devons dire en termes clairs : « Un brevet logiciel de moins, une 86 menace de moins pour les programmeurs ; l'objectif est zéro. »</p> 87 <p> 88 La bataille contre les brevets logiciels dans l'Union européenne atteint une 89 étape cruciale. Le Parlement européen a voté l'an dernier pour rejeter les 90 brevets logiciels de façon péremptoire. En mai, le Conseil des ministres 91 votait pour défaire les amendements du Parlement et rendre la directive 92 encore pire qu'elle ne l'était au départ. Cependant, au moins un des pays 93 qui ont soutenu cela a déjà changé son vote. Nous devons tous faire de notre 94 mieux dès à présent pour convaincre un autre pays de l'Union européenne de 95 changer son vote, et convaincre les nouveaux élus du Parlement européen de 96 soutenir le vote précédent. Veuillez consulter les sites <a 97 href="https://ffii.org/">ffii.org</a> et <a 98 href="https://www.ffii.fr">www.ffii.fr</a> pour plus de renseignements sur 99 la façon d'aider et pour être en contact avec les autres activistes.</p> 100 </div> 101 102 <div class="translators-notes"> 103 104 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> 105 </div> 106 </div> 107 108 <!-- for id="content", starts in the include above --> 109 <!--#include virtual="/server/footer.fr.html" --> 110 <div id="footer" role="contentinfo"> 111 <div class="unprintable"> 112 113 <p>Veuillez envoyer les requêtes concernant la FSF et GNU à <<a 114 href="mailto:gnu@gnu.org">gnu@gnu.org</a>>. Il existe aussi <a 115 href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens 116 orphelins et autres corrections ou suggestions peuvent être signalés à 117 <<a href="mailto:webmasters@gnu.org">webmasters@gnu.org</a>>.</p> 118 119 <p> 120 <!-- TRANSLATORS: Ignore the original text in this paragraph, 121 replace it with the translation of these two: 122 123 We work hard and do our best to provide accurate, good quality 124 translations. However, we are not exempt from imperfection. 125 Please send your comments and general suggestions in this regard 126 to <a href="mailto:web-translators@gnu.org"> 127 128 <web-translators@gnu.org></a>.</p> 129 130 <p>For information on coordinating and contributing translations of 131 our web pages, see <a 132 href="/server/standards/README.translations.html">Translations 133 README</a>. --> 134 Merci d'adresser vos commentaires sur les pages en français à <<a 135 href="mailto:trad-gnu@april.org">trad-gnu@april.org</a>>, et sur les 136 traductions en général à <<a 137 href="mailto:web-translators@gnu.org">web-translators@gnu.org</a>>. Si 138 vous souhaitez y contribuer, vous trouverez dans le <a 139 href="/server/standards/README.translations.html">guide de traduction</a> 140 les infos nécessaires.</p> 141 </div> 142 143 <!-- Regarding copyright, in general, standalone pages (as opposed to 144 files generated as part of manuals) on the GNU web server should 145 be under CC BY-ND 4.0. Please do NOT change or remove this 146 without talking with the webmasters or licensing team first. 147 Please make sure the copyright date is consistent with the 148 document. For web pages, it is ok to list just the latest year the 149 document was modified, or published. 150 151 If you wish to list earlier years, that is ok too. 152 Either "2001, 2002, 2003" or "2001-2003" are ok for specifying 153 years, as long as each year in the range is in fact a copyrightable 154 year, i.e., a year in which the document was published (including 155 being publicly visible on the web or in a revision control system). 156 157 There is more detail about copyright years in the GNU Maintainers 158 Information document, www.gnu.org/prep/maintain. --> 159 <p>Copyright © 2004, 2021 Richard Stallman</p> 160 161 <p>Cette page peut être utilisée suivant les conditions de la licence <a 162 rel="license" 163 href="http://creativecommons.org/licenses/by-nd/4.0/deed.fr">Creative 164 Commons attribution, pas de modification, 4.0 internationale (CC BY-ND 165 4.0)</a>.</p> 166 167 <!--#include virtual="/server/bottom-notes.fr.html" --> 168 <div class="translators-credits"> 169 170 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> 171 Traduction : Cédric Corazza.<br /> Révision : <a 172 href="mailto:trad-gnu@april.org">trad-gnu@april.org</a></div> 173 174 <p class="unprintable"><!-- timestamp start --> 175 Dernière mise à jour : 176 177 $Date: 2022/05/04 15:02:16 $ 178 179 <!-- timestamp end --> 180 </p> 181 </div> 182 </div> 183 <!-- for class="inner", starts in the banner include --> 184 </body> 185 </html>