path: root/talermerchantdemos/blog/articles/fr/patent-practice-panel.html

<!--#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>