summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/fr/patent-practice-panel.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/patent-practice-panel.html')
-rw-r--r--talermerchantdemos/blog/articles/fr/patent-practice-panel.html274
1 files changed, 274 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/fr/patent-practice-panel.html b/talermerchantdemos/blog/articles/fr/patent-practice-panel.html
new file mode 100644
index 0000000..16e67a5
--- /dev/null
+++ b/talermerchantdemos/blog/articles/fr/patent-practice-panel.html
@@ -0,0 +1,274 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/patent-practice-panel.en.html" -->
+
+<!--#include virtual="/server/header.fr.html" -->
+<!-- Parent-Version: 1.77 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Présentation de Daniel Ravicher à la table ronde de la FFII - Projet GNU -
+Free Software Foundation</title>
+
+<!--#include virtual="/philosophy/po/patent-practice-panel.translist" -->
+<!--#include virtual="/server/banner.fr.html" -->
+<h2>Nouveaux développements dans la pratique des brevets : évaluer les risques
+et les coûts d'un portefeuille de licences et des hold-ups dont il fait
+l'objet</h2>
+
+<p>par <strong>Daniel B. Ravicher</strong></p>
+
+<p><em>Ceci est la transcription d'une présentation donnée par Daniel
+B. Ravicher en tant que directeur exécutif de la </em>Public Patent
+Foundation<em> (Fondation publique pour les brevets) le mercredi
+10 novembre 2004, à une conférence organisée par la </em>Foundation for a
+Free Information Infrastructure<em> (Fondation pour une Infrastructure
+d'Information Libre) à Bruxelles (Belgique). La transcription a été faite
+par Ændrew Rininsland.</em></p>
+
+<p>Merci. Je pense, en ce qui me concerne, que les deux journées de conférences
+reviennent en fait à une question, et que tout le débat se résume à une
+seule question : « Comment voulons-nous déterminer la réussite dans
+l'industrie du logiciel ? »
+</p>
+
+<p>
+Ou, autrement dit, qui voulons-nous pour déterminer ceux qui réussissent et
+ceux qui échouent dans l'industrie du logiciel ? Parce qu'il y a diverses
+personnes qui peuvent prendre cette décision. Nous pouvons faire prendre la
+décision de qui réussit et qui échoue par des bureaucrates, ou nous pouvons
+laisser les consommateurs prendre cette décision, de qui réussit et qui
+échoue. Si nous voulons qu'un logiciel réussisse parce que nous voulons
+qu'il ait du succès sur la base de ses mérites et soit le meilleur logiciel
+que le public puisse avoir, nous voulons très probablement un système qui
+laisse aux consommateurs et aux utilisateurs les décisions quant au choix
+des logiciels – pas aux bureaucrates.
+</p>
+
+<p> Alors, quel est le rapport avec les brevets ? Plus vous faites un système de
+brevets étendu, plus vous permettez au système de brevets d'avoir un impact
+sur le logiciel, et plus vous permettez que la réussite dans l'industrie du
+logiciel soit déterminée par des bureaucrates se basant sur les brevets,
+ceux-là même qui peuvent tirer profit de la bureaucratie qui accorde les
+brevets et résout les contestations qui les concernent. C'est une
+concurrence bureaucratique qui n'est pas basée sur la décision des
+consommateurs. Elle diminue la probabilité que les mérites soient
+déterminants dans le succès de tel ou tel logiciel.
+</p>
+
+<p>
+Nous devons reconnaître que même sans brevets logiciels, les grands
+développeurs ont des avantages intrinsèques sur les petits développeurs. Les
+grands développeurs ont les ressources, les grands développeurs ont les
+relations, les grands développeurs ont les canaux de distribution, les
+grands développeurs ont la marque. Alors, même sans brevets logiciels, les
+grands développeurs ont toujours un avantage : ils ont un avantage au
+départ. Bien, alors, la question qui me vient, c'est : « Si nous avons des
+brevets logiciels, est-ce que cela augmente l'avantage des grands
+développeurs ou est-ce que cela le diminue ? » Parce que le système de
+brevets pourrait bénéficier aux petits développeurs et donc pourrait éroder
+certains des avantages qu'ont naturellement les grandes sociétés.
+</p>
+
+<p>
+Je pense qu'on a déjà bien ausculté ce point. Nous savons que les petits
+développeurs ne profitent pas d'un système de brevets. En fait, un système
+de brevets leur nuit. Ainsi, étendre un système de brevets pour l'appliquer
+au développement logiciel ne fait qu'augmenter les désavantages que les
+petits développeurs ont déjà dans la concurrence. Et on ne revient toujours
+à ça : qui voulons-nous pour décider de la réussite des développeurs de
+logiciel, voulons-nous que ce soient les consommateurs, se basant sur les
+mérites, la fonctionnalité et le prix, ou des bureaucrates, se basant sur
+les sociétés à qui les brevets sont accordés et sur les gagnants dans les
+affaires de violation de brevets ?
+</p>
+
+<p>
+L'autre chose que nous devons reconnaître est que le système de brevets a
+une préférence pour les utilisateurs de certains types de logiciels. Un
+système de brevets comme celui que nous avons aux États-Unis bénéficie à
+ceux qui sont sous un régime de distribution de logiciel qui leur permet de
+faire payer des royalties. C'est parce que tous les logiciels doivent faire
+face au risque de violation de brevets. Les brevets ne font pas la
+distinction entre l'open source ou les logiciels sous licence libre, et les
+logiciels privateurs<a id="TransNote1-rev"
+href="#TransNote1"><sup>1</sup></a> : un brevet couvre une certaine
+technologie, il ne se soucie pas de la façon dont le logiciel est
+distribué. Mais les logiciels privateurs sont sous licence payante et donc
+le coût de ce risque peut être transmis aux consommateurs sans qu'ils ne
+s'en rendent compte. Ils ne le voient pas, c'est inclus dans le prix du
+logiciel qu'ils achètent, et si vous demandiez à un consommateur s'il s'est
+assuré contre des poursuites pour violation de brevets, il dirait qu'il ne
+pense pas l'avoir fait.
+Mais en fait, il l'a fait, parce que si quelqu'un poursuit un utilisateur de
+logiciel provenant de Microsoft, Microsoft a inclus dans le prix de la
+licence les frais de procédure pour le défendre. En revanche, si vous avez
+un logiciel distribué sans royalties tel que l'open source ou le logiciel
+libre, vous ne pouvez pas inclure le coût de ce risque, qui ainsi devient
+plus transparent. Et ceci incite les consommateurs ou les utilisateurs à
+penser que l'open source est en plus mauvaise position que le logiciel
+privateur alors qu'en réalité il ne l'est pas. C'est juste parce que le mode
+de distribution de l'open source ne permet pas à quelqu'un d'incorporer
+furtivement le coût de ce risque pour le rendre opaque au lieu de
+transparent. Ainsi, non seulement le système de brevets préfère les grands
+développeurs aux petits développeurs, mais il préfère également les
+utilisateurs de logiciels privateurs aux utilisateurs de logiciels open
+source.
+</p>
+
+<p>
+Si nous revenons à la question initiale qui, je pense, est la question
+fondamentale, comment voulons-nous que le succès dans le marché du logiciel
+soit déterminé ? Voulons-nous qu'il soit déterminé par ce type de facteurs,
+ou voulons-nous qu'il soit déterminé par l'obtention du meilleur logiciel au
+meilleur prix ?
+</p>
+
+<p>
+Avant cela, je pense qu'il est important d'admettre le point de vue que les
+gens auront de l'autre côté, qui est : est-ce qu'un système de brevets moins
+onéreux (ou « moins bénéfique » comme ils diraient, je dis moins onéreux)
+nuira à leurs affaires, parce que les gens pourraient les copier ? Eh bien,
+les grandes entreprises ne s'inquiètent pas d'être copiées. Elles ne s'en
+inquiètent vraiment pas. Du moins pas par d'autres grandes entreprises,
+c'est pourquoi elles font des licences croisées tout le temps.
+Si une grande entreprise ne voulait vraiment pas que ses logiciels soient
+copiés, pourquoi ferait-elle des concessions de son portefeuille de licences
+à toutes les autres grandes entreprises du monde, puisque ça ne peut pas les
+empêcher de copier une fois que cet accord est conclu ? Donc cet argument
+selon lequel « Eh bien, nous nous inquiétons que des personnes copient nos
+logiciels »&hellip; Les personnes les plus susceptibles de copier vos
+logiciels sont d'autres grandes entreprises, parce qu'elles ont les
+ressources, la capacité, les canaux de distribution, la marque et les
+relations. Pourquoi les laissez-vous les copier ? Ça ne doit pas vous
+inquiéter tant que ça.
+</p>
+
+<p>
+La question est donc : un système de brevets a-t-il un effet net bénéfique
+ou un effet net néfaste sur le développement logiciel ? Nous avons déjà vu,
+je pense, que son seul effet est de diminuer la capacité de l'open source ou
+du logiciel sous licence gratuite à concurrencer le logiciel privateur. Au
+final, vous devez vous demander : est-ce que moins de concurrence est
+bénéfique pour l'industrie du logiciel ? Je ne sais pas ce que les Européens
+en pensent, je pense que les Européens sont clairement pour la concurrence,
+et je sais que nous de l'autre côté de l'Atlantique sommes clairement pour
+la concurrence aussi, et donc la réponse n'est jamais que moins de
+concurrence soit meilleure pour les consommateurs. Je pense qu'il faut être
+extrêmement clair ; si nous avions deux secondes dans un ascenseur pour
+lancer cette idée à quelqu'un, les brevets logiciels ont un effet net
+négatif sur la concurrence dans l'industrie du logiciel.
+C'est vrai, ils peuvent augmenter la concurrence de certaines façons, mais
+l'effet net est anticoncurrentiel. Et c'est ce qui se passe quand on met la
+capacité à décider de la réussite dans l'industrie du logiciel entre les
+mains de l'office des brevets ou des tribunaux. Si vous avez besoin
+d'exemples, si les gens pensent que c'est juste de la rhétorique ou juste
+votre avis, citez l'exemple des États-Unis. Microsoft est une entreprise de
+logiciel couronnée de succès, je ne pense pas que quiconque remettrait cela
+en question. Ils ne se sont jamais retrouvés à poursuivre quelqu'un pour
+violation de brevet. Donc ils prétendent qu'ils ont besoin de brevets,
+cependant ils n'ont jamais eu à s'en servir. Ils font des licences croisées
+et c'est là que nous nous demandons : « Si vous vous inquiétez que des
+personnes copient, alors pourquoi faire des licences croisées avec elles ? »
+</p>
+
+<p>
+Ce qui nous amène au dernier point : à qui d'autre un système de brevets
+bénéficie-t-il ? S'il bénéficie aux grands développeurs plutôt qu'aux petits
+développeurs, y a-t-il d'autres personnes ? Un système de brevets bénéficie
+aux non-développeurs. Voulons-nous vraiment un système bureaucratique qui
+aide des gens qui n'apportent rien à la société ? Ce que j'entends par
+non-développeurs, ce sont les trolls – dont tout le monde ici est familier,
+les gens qui obtiennent un brevet, soit en en faisant la demande, soit en
+l'acquérant avec un certain achat de valeurs, et puis qui l'utilisent pour
+taxer d'autres développeurs, d'autres distributeurs d'un produit.
+</p>
+
+<p>
+Voulons-nous vraiment d'un système qui encourage les gens à ne pas ajouter
+de produits ni de services sur le marché mais à simplement amoindrir les
+bénéfices et les possibilités de ceux qui le font ?
+</p>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+<hr /><b>Note de traduction</b><ol>
+<li id="TransNote1">Autre traduction de <cite>proprietary</cite> :
+propriétaire. <a href="#TransNote1-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 3.0 US. 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; 2006 Daniel B. Ravicher</p>
+
+<p>La reproduction exacte et la distribution intégrale de cet article sont
+permises sur n'importe quel support d'archivage, pourvu que le présent avis
+soit conservé.</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 : EWENS.<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/09/20 13:58:34 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+</body>
+</html>