1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
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">↑</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"><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>
<p>Copyright © 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@april.org">trad-gnu@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>
|
