summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/es/udi.html
blob: a0f6d75b27d867937a7d37743380ec26491b9cf1 (plain)
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
<!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->

<!--#include virtual="/server/header.es.html" -->
<!-- Parent-Version: 1.77 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>El movimiento del software libre y el proyecto UDI - Proyecto GNU - Free
Software Foundation</title>

<!--#include virtual="/philosophy/po/udi.translist" -->
<!--#include virtual="/server/banner.es.html" -->
<h2>El movimiento del software libre y el proyecto UDI</h2>

<p>
El proyecto llamado UDI (<cite>Uniform Driver Interface</cite>) se propone
definir una interfaz única entre los núcleos de los sistemas operativos y
los controladores de dispositivos. ¿Qué es lo que debería hacer el
movimiento del software libre con respecto a esta idea?</p>
<p>
Si nos imaginamos un cierto número de desarrolladores de sistemas operativos
y hardware, todos cooperando sobre una misma base, UDI (si fuera
técnicamente posible) sería una muy buena idea. Nos permitiría desarrollar
un único controlador para cualquier dispositivo de hardware y compartirlo
entre todos. Posibilitaría un nivel más alto de cooperación.</p>
<p>
Cuando aplicamos esa idea al mundo real, donde encontramos programadores de
software libre que buscan cooperar y programadores de software privativo que
buscan dominar, las consecuencias son muy diferentes. De ninguna manera el
uso de UDI puede beneficiar al movimiento del software libre. Lo único que
haría sería dividirnos y debilitarnos.</p>
<p>
¿Cuáles serí­an las consecuencias si Linux soportara la interfaz UDI y
comenzáramos a diseñar nuevos controladores para interactuar con Linux a
través de ella?</p>

<ul>
<li> Se podrían ejecutar controladores de Linux libres, cubiertos por la GPL, en
sistemas Windows.
<p>
Esto beneficiaría solo a los usuarios de Windows; a nosotros, usuarios de
sistemas operativos libres, no nos ayudaría en nada. Tampoco nos lastimaría
directamente, pero los programadores de controladores libres cubiertos por
la GPL podrían quedar decepcionados al ver que se utilizan de esta manera,
lo que sería muy desfavorable. Enlazar los controladores con un núcleo
privativo también podría consituir una infracción a la licencia GPL de
GNU. Aumentar la tentación de hacerlo es ir en busca de problemas.</p></li>

<li> Se podrí­an ejecutar controladores de Windows que no son libres en los <a
href="/gnu/linux-and-gnu.html">sistemas GNU/Linux</a>.
<p>
Esto no afectaría directamente el abanico de hardware que funciona con
software libre, pero indirectamente tendería a disminuirlo, pues presentaría
una tentación a los millones de usuarios de GNU/Linux que no han aprendido a
insistir en la libertad por sí misma. En la medida en que la comunidad
empezara a ceder a la tentación, nos desplazaríamos hacia el uso de
controladores que no son libres en lugar de escribir nuestros propios
controladores libres.</p>
<p>
La interfaz UDI no destruiría de por sí­ el desarrollo de controladores
libres. Por lo tanto, si una buena parte de nosotros no cede a la tentación,
podríamos seguir desarrollando controladores libres a pesar de UDI, igual
que lo hacemos sin él.</p>
<p>
¿Por qué fomentar la reducción de la comunidad más de lo necesario? ¿Por qué
plantear dificultades innecesarias para el futuro del software libre? Ya que
UDI no hace nada bueno por nosotros, mejor rechazarlo.</p></li>
</ul>

<p>
Ante esta situación, no es de extrañar que Intel, que apoya el proyecto UDI,
haya comenzado a «buscar ayuda para UDI en la comunidad Linux». ¿Cómo hace
una compañía rica y egoísta para acercarse a una comunidad de gente que
coopera? Pidiendo una limosna, por supuesto. Ellos no pierden nada con
pedir, y nosotros, tomados por sorpresa, podríamos responder
afirmativamente.</p>
<p>
La cooperación con UDI no es imposible. No tenemos que demonizar el proyecto
UDI, ni Intel, ni a nadie. Pero, antes de aceptar cualquier trato que nos
propongan, debemos evaluarlo detenidamente para cerciorarnos de que sea
ventajoso también para la comunidad del software libre y no solamente para
los desarrolladores de sistemas privativos. En este asunto en particular,
significa que tenemos que poner como condición que la eventual cooperación
nos ayude a avanzar en el camino para alcanzar nuestro objetivo primordial
en lo que se refiere a los núcleos y controladores: que <em>todo</em> el
hardware importante soporte controladores libres.</p>
<p>
Una manera de hacer que la cooperación resultase provechosa sería modificar
el proyecto UDI. Eric Raymond ha propuesto que para cumplir con las normas
UDI se establezca como requisito que los controladores sean software
libre. Eso sería lo ideal, pero también existen otras alternativas que
podrían funcionar. Podría funcionar el solo hecho de requerir que se
publique el código fuente del controlador &mdash;en lugar de mantenerlo como
secreto industrial&mdash; porque de esa manera, aunque el controlador no
sería libre, al menos tendríamos acceso a la información que necesitamos
para escribir uno libre.­</p>
<p>
Intel también podrí­a hacer algo independientemente de UDI para ayudar a la
comunidad del software libre a resolver este problema. Por ejemplo, podría
haber algún tipo de certificación que los desarrolladores de hardware
solicitan y en cuya concesión Intel juegue un papel importante. En ese caso
Intel podría aceptar dificultar la obtención de la certificación en aquellos
casos en que las especificaciones del hardware fueran secretas. Puede que no
sea una solución perfecta, pero podría ayudar un poco.</p>
<p>
La dificultad de cualquier acuerdo con Intel sobre el tema de UDI es que
nosotros haríamos nuestra parte para Intel al principio, pero nuestra
recompensa se vería dilacionada por un largo período. De hecho, estaríamos
dando crédito a Intel. Pero, ¿continuará Intel a restituir el préstamo?
Probablemente sí, si lo hacemos todo por escrito y no dejamos vías de
escape; de otra manera, no podemos contar con ello. Las corporaciones son
notoriamente poco fiables; puede que las personas con las que tratemos sean
íntegras, pero podrían ser desautorizadas desde arriba, o reemplazadas en
cualquier momento por otras. Incluso un Funcionario Ejecutivo Principal que
posee la mayoría de las acciones puede ser sustituido como consecuencia de
una compra total. Cuando se hace un trato con una corporación, siempre es
aconsejable obtener un compromiso vinculante por escrito.</p>
<p>
No es muy probable que Intel nos ofrezca un trato que nos proporcione lo que
necesitamos. De hecho, UDI parece haber sido diseñado para que sea más fácil
mantener las especificaciones en secreto.</p>
<p>
Aún así, no hay ningún peligro en dejar la puerta abierta, siempre que
tengamos cuidado de no dejar entrar a cualquiera.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.es.html" -->
<div id="footer">
<div class="unprintable">

<p>Envíe sus consultas acerca de la FSF y GNU a <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
avisar de enlaces rotos y proponer otras correcciones o sugerencias,
diríjase a <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>. -->
El equipo de traductores al español se esfuerza por ofrecer traducciones
fieles al original y de buena calidad, pero no estamos libres de cometer
errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
<a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
</p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
para las traducciones</a> para obtener información sobre la coordinación y
el envío de traducciones de las páginas de este sitio web.</p>
</div>

<p>Copyright &copy; 1998 Richard M. Stallman</p>

<p>Esta página está bajo licencia <a rel="license"
href="http://creativecommons.org/licenses/by-nd/3.0/us/deed.es_ES">Creative
Commons Reconocimiento-SinObraDerivada 3.0 Estados Unidos de América</a>.</p>

<!--#include virtual="/server/bottom-notes.es.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 </div>

<p class="unprintable"><!-- timestamp start -->
Última actualización:

$Date: 2019/09/15 21:06:03 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>