summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/fr/udi.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/udi.html')
-rw-r--r--talermerchantdemos/blog/articles/fr/udi.html197
1 files changed, 197 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/fr/udi.html b/talermerchantdemos/blog/articles/fr/udi.html
new file mode 100644
index 0000000..769b3fc
--- /dev/null
+++ b/talermerchantdemos/blog/articles/fr/udi.html
@@ -0,0 +1,197 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
+
+<!--#include virtual="/server/header.fr.html" -->
+<!-- Parent-Version: 1.77 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Le mouvement du logiciel libre et le projet UDI - Projet GNU - Free Software
+Foundation</title>
+
+<!--#include virtual="/philosophy/po/udi.translist" -->
+<!--#include virtual="/server/banner.fr.html" -->
+<h2>Le mouvement du logiciel libre et le projet UDI</h2>
+
+<p>
+Un projet nommé UDI <cite>(Uniform Driver Interface)</cite> vise à définir
+une interface normalisée entre les noyaux des systèmes d'exploitation et les
+pilotes de périphériques. Que doit faire notre communauté de cette idée ?</p>
+<p>
+Le projet UDI serait vraiment une bonne idée à condition, d'une part, qu'il
+soit techniquement réalisable, et d'autre part que suffisamment de
+développeurs de systèmes d'exploitation coopèrent sur un pied d'égalité avec
+les fabricants de matériel informatique. Cela permettrait de ne développer
+qu'un pilote pour chaque périphérique et d'en faire profiter tout le
+monde. Un plus haut niveau de coopération serait alors possible.</p>
+<p>
+Malheureusement, dans le monde réel nous avons à la fois des développeurs de
+logiciels libres qui cherchent la coopération et des développeurs de
+logiciels privateurs<a id="TransNote1-rev"
+href="#TransNote1"><sup>1</sup></a> qui cherchent la domination, avec des
+conséquences très différentes. En aucun cas l'utilisation d'UDI ne peut
+avoir d'avantage pour le mouvement du logiciel libre. Son seul effet
+éventuel serait de nous diviser et nous affaiblir.</p>
+<p>
+Quelles seraient les conséquences pour nous si Linux gérait UDI et si nous
+commencions à concevoir de nouveaux pilotes pour communiquer avec Linux à
+travers UDI ?</p>
+
+<ul>
+<li> Il serait possible d'utiliser avec des systèmes Windows des pilotes Linux
+libres couverts par la GPL.
+<p>
+Seuls les utilisateurs de Windows en tireraient avantage. Les utilisateurs
+de systèmes libres que nous sommes ne pourraient rien en attendre de
+positif. Il est vrai qu'UDI ne nous causerait pas directement de tort ; les
+développeurs de pilotes libres couverts par la GPL pourraient toutefois être
+découragés de voir leur travail utilisé de cette manière, ce découragement
+constituant une grande perte. Il est également possible que l'association
+des pilotes à un noyau privateur constitue une violation de la GNU
+GPL. C'est chercher les ennuis que d'alimenter une telle tentation.</p></li>
+
+<li> Il serait possible d'utiliser des pilotes Windows privateurs avec des
+systèmes <a href="/gnu/linux-and-gnu.html">GNU/Linux</a>.
+<p>
+La gamme de matériels gérés par les logiciels libres n'en serait pas
+directement affectée, mais cette facilité représenterait une tentation pour
+les millions d'utilisateurs de GNU/Linux qui n'ont pas compris l'importance
+de revendiquer la liberté pour elle-même. À terme, une baisse indirecte de
+l'étendue de cette gamme serait donc à craindre. On en arriverait à une
+situation où la communauté, commençant à accepter cette tentation,
+utiliserait des pilotes privateurs plutôt que d'en écrire des libres.</p>
+<p>
+Le projet UDI, en lui-même, n'entraverait pas le développement de pilotes
+libres. Nous pourrions continuer à développer des pilotes libres malgré ce
+projet, comme nous le faisons actuellement, à condition toutefois qu'un
+nombre suffisant d'entre nous résiste à la tentation.</p>
+<p>
+Pourquoi rendre la communauté plus faible que nécessaire ? Pourquoi ajouter
+des obstacles inutiles au futur du logiciel libre ? Puisque le projet UDI ne
+nous est pas bénéfique, il est préférable de le rejeter.</p></li>
+</ul>
+
+<p>
+Dans ces conditions, il n'est pas surprenant qu'Intel, un partisan d'UDI,
+ait commencé à « chercher de l'aide dans la communauté Linux pour ce
+projet ». Quelle est l'approche d'une société riche et égoïste vis-à-vis
+d'une communauté basée sur la coopération ? Demander l'aumône, bien sûr. Ils
+ne risquent rien à demander et, pris par surprise, nous serions bien
+capables de répondre oui.</p>
+<p>
+Une coopération avec UDI n'est pas hors de question. Nous ne devons pas
+considérer UDI, Intel ou qui que ce soit comme un Grand Satan. Mais toute
+proposition devra être soigneusement étudiée afin de nous assurer que notre
+participation ne profitera pas uniquement aux développeurs de systèmes
+privateurs, mais également à la communauté du logiciel libre. Cela signifie,
+dans ce cas précis, d'exiger que la coopération nous fasse faire un pas de
+plus vers le but ultime dans le domaine des noyaux et pilotes libres : gérer
+<em>tous</em> les principaux matériels informatiques avec des pilotes
+libres.</p>
+<p>
+Modifier le projet UDI lui-même serait une manière de rendre profitable
+cette coopération. Éric Raymond a ainsi suggéré que la norme UDI exige de
+transformer tous les pilotes en logiciels libres. Cette solution serait
+idéale, mais d'autres sont également satisfaisantes. Par exemple, on peut
+simplement exiger que le code source soit publié au lieu d'être couvert par
+le secret industriel, car même si le pilote en question n'était pas libre,
+cela nous dirait au moins ce que nous aurions besoin de savoir pour écrire
+un pilote qui le soit.</p>
+<p>
+Intel pourrait aussi, indépendamment d'UDI, aider la communauté du logiciel
+libre à résoudre ce problème. Par exemple, il pourrait y avoir une sorte de
+certification recherchée par les développeurs de matériel, qu'Intel
+contribuerait à délivrer. Si c'était le cas, Intel pourrait accepter de
+rendre cette certification plus difficile si les caractéristiques du
+matériel étaient gardées secrètes. Ce ne serait pas une solution parfaite du
+problème mais cela pourrait aider considérablement.</p>
+<p>
+Le problème de tout accord avec Intel sur UDI est que nous devrions faire
+notre part de travail dès le commencement, alors que le rôle d'Intel se
+prolongerait dans le temps. En clair, nous ferions crédit à
+Intel. Continuerait-elle à rembourser sa dette ? Probablement oui si nous
+mettons tout par écrit et qu'il n'existe aucun échappatoire ; sans cela,
+nous ne pouvons compter dessus. Il est de notoriété publique qu'on ne peut
+pas faire confiance à une société commerciale ; il est possible que les gens
+avec qui nous négocions soient intègres, mais ils peuvent être désavoués par
+leur hiérarchie ou même remplacés n'importe quand. Même un PDG qui possède
+la majeure partie du capital peut être remplacé à la suite d'une OPA. Il
+faut toujours signer un engagement contraignant quand on passe un accord
+avec une société commerciale.</p>
+<p>
+Il semble improbable qu'Intel nous propose un accord qui satisfasse à nos
+besoins. En fait, UDI semble avoir été conçu pour garder plus facilement les
+spécifications secrètes.</p>
+<p>
+Néanmoins, il n'y a aucun mal à ne pas fermer notre porte à clef tant que
+nous faisons attention de ne pas laisser entrer n'importe qui.</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>
+
+<p>Copyright &copy; 1998 Richard M. Stallman</p>
+
+<p>Cette page peut être utilisée suivant les conditions de la licence <a
+rel="license"
+href="http://creativecommons.org/licenses/by-nd/3.0/us/deed.fr">Creative
+Commons attribution de paternité, pas de modification, 3.0 États-Unis
+(CC BY-ND 3.0 US)</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 : ?<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/10/30 17:27:48 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+</body>
+</html>