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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
<!--#include virtual="/server/header.fr.html" -->
<!-- Parent-Version: 1.96 -->
<!-- This page is derived from /server/standards/boilerplate.html -->
<!--#set var="TAGS" value="essays aboutfs free-nonfree" -->
<!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
<!-- 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" -->
<!--#include virtual="/philosophy/ph-breadcrumb.fr.html" -->
<!--GNUN: OUT-OF-DATE NOTICE-->
<!--#include virtual="/server/top-addendum.fr.html" -->
<div class="article reduced-width">
<h2>Le mouvement du logiciel libre et le projet UDI</h2>
<address class="byline">par Richard Stallman</address>
<p>
Un projet nommé UDI <i>(Uniform Driver Interface)</i> 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>
<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 <i>proprietary</i> :
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" role="contentinfo">
<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 contributing translations of
our web pages, see <a
href="/server/standards/README.translations.html">Translations
README</a>. -->
Merci d'adresser vos commentaires sur les pages en français à <<a
href="mailto:trad-gnu@april.org">trad-gnu@april.org</a>>, et sur les
traductions en général à <<a
href="mailto:web-translators@gnu.org">web-translators@gnu.org</a>>. Si
vous souhaitez y contribuer, vous trouverez dans le <a
href="/server/standards/README.translations.html">guide de traduction</a>
les infos nécessaires.</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 © 1998, 2021 Richard 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/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 : ?<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: 2021/10/01 18:33:21 $
<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>
|
