diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/limit-patent-effect.html')
| -rw-r--r-- | talermerchantdemos/blog/articles/fr/limit-patent-effect.html | 223 |
1 files changed, 223 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/fr/limit-patent-effect.html b/talermerchantdemos/blog/articles/fr/limit-patent-effect.html new file mode 100644 index 0000000..1a32554 --- /dev/null +++ b/talermerchantdemos/blog/articles/fr/limit-patent-effect.html @@ -0,0 +1,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> |