/[www]/www/philosophy/udi.es.html
ViewVC logotype

Contents of /www/philosophy/udi.es.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.18 - (show annotations) (download) (as text)
Tue Oct 5 10:03:05 2021 UTC (3 years ago) by gnun
Branch: MAIN
CVS Tags: HEAD
Changes since 1.17: +18 -2 lines
File MIME type: text/html
Automatic update by GNUnited Nations.

1 <!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
2
3 <!--#include virtual="/server/header.es.html" -->
4 <!-- Parent-Version: 1.96 -->
5 <!-- This page is derived from /server/standards/boilerplate.html -->
6 <!--#set var="TAGS" value="essays aboutfs free-nonfree" -->
7 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
8
9 <!-- This file is automatically generated by GNUnited Nations! -->
10 <title>El movimiento del software libre y el proyecto UDI - Proyecto GNU - Free
11 Software Foundation</title>
12
13 <!--#include virtual="/philosophy/po/udi.translist" -->
14 <!--#include virtual="/server/banner.es.html" -->
15 <!--#include virtual="/philosophy/ph-breadcrumb.es.html" -->
16 <!--GNUN: OUT-OF-DATE NOTICE-->
17 <!--#include virtual="/server/top-addendum.es.html" -->
18 <div class="article reduced-width">
19 <h2>El movimiento del software libre y el proyecto UDI</h2>
20
21 <address class="byline">por Richard Stallman</address>
22
23 <p>
24 El proyecto llamado UDI (<cite>Uniform Driver Interface</cite>) se propone
25 definir una interfaz única entre los núcleos de los sistemas operativos y
26 los controladores de dispositivos. ¿Qué es lo que debería hacer el
27 movimiento del software libre con respecto a esta idea?</p>
28 <p>
29 Si nos imaginamos un cierto número de desarrolladores de sistemas operativos
30 y hardware, todos cooperando sobre una misma base, UDI (si fuera
31 técnicamente posible) sería una muy buena idea. Nos permitiría desarrollar
32 un único controlador para cualquier dispositivo de hardware y compartirlo
33 entre todos. Posibilitaría un nivel más alto de cooperación.</p>
34 <p>
35 Cuando aplicamos esa idea al mundo real, donde encontramos programadores de
36 software libre que buscan cooperar y programadores de software privativo que
37 buscan dominar, las consecuencias son muy diferentes. De ninguna manera el
38 uso de UDI puede beneficiar al movimiento del software libre. Lo único que
39 haría sería dividirnos y debilitarnos.</p>
40 <p>
41 ¿Cuáles serí­an las consecuencias si Linux soportara la interfaz UDI y
42 comenzáramos a diseñar nuevos controladores para interactuar con Linux a
43 través de ella?</p>
44
45 <ul>
46 <li> Se podrían ejecutar controladores de Linux libres, cubiertos por la GPL, en
47 sistemas Windows.
48 <p>
49 Esto beneficiaría solo a los usuarios de Windows; a nosotros, usuarios de
50 sistemas operativos libres, no nos ayudaría en nada. Tampoco nos lastimaría
51 directamente, pero los programadores de controladores libres cubiertos por
52 la GPL podrían quedar decepcionados al ver que se utilizan de esta manera,
53 lo que sería muy desfavorable. Enlazar los controladores con un núcleo
54 privativo también podría consituir una infracción a la licencia GPL de
55 GNU. Aumentar la tentación de hacerlo es ir en busca de problemas.</p></li>
56
57 <li> Se podrí­an ejecutar controladores de Windows que no son libres en los <a
58 href="/gnu/linux-and-gnu.html">sistemas GNU/Linux</a>.
59 <p>
60 Esto no afectaría directamente el abanico de hardware que funciona con
61 software libre, pero indirectamente tendería a disminuirlo, pues presentaría
62 una tentación a los millones de usuarios de GNU/Linux que no han aprendido a
63 insistir en la libertad por sí misma. En la medida en que la comunidad
64 empezara a ceder a la tentación, nos desplazaríamos hacia el uso de
65 controladores que no son libres en lugar de escribir nuestros propios
66 controladores libres.</p>
67 <p>
68 La interfaz UDI no destruiría de por sí­ el desarrollo de controladores
69 libres. Por lo tanto, si una buena parte de nosotros no cede a la tentación,
70 podríamos seguir desarrollando controladores libres a pesar de UDI, igual
71 que lo hacemos sin él.</p>
72 <p>
73 ¿Por qué fomentar la reducción de la comunidad más de lo necesario? ¿Por qué
74 plantear dificultades innecesarias para el futuro del software libre? Ya que
75 UDI no hace nada bueno por nosotros, mejor rechazarlo.</p></li>
76 </ul>
77
78 <p>
79 Ante esta situación, no es de extrañar que Intel, que apoya el proyecto UDI,
80 haya comenzado a «buscar ayuda para UDI en la comunidad Linux». ¿Cómo hace
81 una compañía rica y egoísta para acercarse a una comunidad de gente que
82 coopera? Pidiendo una limosna, por supuesto. Ellos no pierden nada con
83 pedir, y nosotros, tomados por sorpresa, podríamos responder
84 afirmativamente.</p>
85 <p>
86 La cooperación con UDI no es imposible. No tenemos que demonizar el proyecto
87 UDI, ni Intel, ni a nadie. Pero, antes de aceptar cualquier trato que nos
88 propongan, debemos evaluarlo detenidamente para cerciorarnos de que sea
89 ventajoso también para la comunidad del software libre y no solamente para
90 los desarrolladores de sistemas privativos. En este asunto en particular,
91 significa que tenemos que poner como condición que la eventual cooperación
92 nos ayude a avanzar en el camino para alcanzar nuestro objetivo primordial
93 en lo que se refiere a los núcleos y controladores: que <em>todo</em> el
94 hardware importante soporte controladores libres.</p>
95 <p>
96 Una manera de hacer que la cooperación resultase provechosa sería modificar
97 el proyecto UDI. Eric Raymond ha propuesto que para cumplir con las normas
98 UDI se establezca como requisito que los controladores sean software
99 libre. Eso sería lo ideal, pero también existen otras alternativas que
100 podrían funcionar. Podría funcionar el solo hecho de requerir que se
101 publique el código fuente del controlador &mdash;en lugar de mantenerlo como
102 secreto industrial&mdash; porque de esa manera, aunque el controlador no
103 sería libre, al menos tendríamos acceso a la información que necesitamos
104 para escribir uno libre.­</p>
105 <p>
106 Intel también podrí­a hacer algo independientemente de UDI para ayudar a la
107 comunidad del software libre a resolver este problema. Por ejemplo, podría
108 haber algún tipo de certificación que los desarrolladores de hardware
109 solicitan y en cuya concesión Intel juegue un papel importante. En ese caso
110 Intel podría aceptar dificultar la obtención de la certificación en aquellos
111 casos en que las especificaciones del hardware fueran secretas. Puede que no
112 sea una solución perfecta, pero podría ayudar un poco.</p>
113 <p>
114 La dificultad de cualquier acuerdo con Intel sobre el tema de UDI es que
115 nosotros haríamos nuestra parte para Intel al principio, pero nuestra
116 recompensa se vería dilacionada por un largo período. De hecho, estaríamos
117 dando crédito a Intel. Pero, ¿continuará Intel a restituir el préstamo?
118 Probablemente sí, si lo hacemos todo por escrito y no dejamos vías de
119 escape; de otra manera, no podemos contar con ello. Las corporaciones son
120 notoriamente poco fiables; puede que las personas con las que tratemos sean
121 íntegras, pero podrían ser desautorizadas desde arriba, o reemplazadas en
122 cualquier momento por otras. Incluso un Funcionario Ejecutivo Principal que
123 posee la mayoría de las acciones puede ser sustituido como consecuencia de
124 una compra total. Cuando se hace un trato con una corporación, siempre es
125 aconsejable obtener un compromiso vinculante por escrito.</p>
126 <p>
127 No es muy probable que Intel nos ofrezca un trato que nos proporcione lo que
128 necesitamos. De hecho, UDI parece haber sido diseñado para que sea más fácil
129 mantener las especificaciones en secreto.</p>
130 <p>
131 Aún así, no hay ningún peligro en dejar la puerta abierta, siempre que
132 tengamos cuidado de no dejar entrar a cualquiera.</p>
133 </div>
134
135 <div class="translators-notes">
136
137 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
138 </div>
139 </div>
140
141 <!-- for id="content", starts in the include above -->
142 <!--#include virtual="/server/footer.es.html" -->
143 <div id="footer" role="contentinfo">
144 <div class="unprintable">
145
146 <p>Envíe sus consultas acerca de la FSF y GNU a <a
147 href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
148 href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
149 avisar de enlaces rotos y proponer otras correcciones o sugerencias,
150 diríjase a <a
151 href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
152
153 <p>
154 <!-- TRANSLATORS: Ignore the original text in this paragraph,
155 replace it with the translation of these two:
156
157 We work hard and do our best to provide accurate, good quality
158 translations. However, we are not exempt from imperfection.
159 Please send your comments and general suggestions in this regard
160 to <a href="mailto:web-translators@gnu.org">
161
162 &lt;web-translators@gnu.org&gt;</a>.</p>
163
164 <p>For information on coordinating and contributing translations of
165 our web pages, see <a
166 href="/server/standards/README.translations.html">Translations
167 README</a>. -->
168 El equipo de traductores al español se esfuerza por ofrecer traducciones
169 fieles al original y de buena calidad, pero no estamos libres de cometer
170 errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
171 <a
172 href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
173 </p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
174 para las traducciones</a> para obtener información sobre la coordinación y
175 el envío de traducciones de las páginas de este sitio web.</p>
176 </div>
177
178 <!-- Regarding copyright, in general, standalone pages (as opposed to
179 files generated as part of manuals) on the GNU web server should
180 be under CC BY-ND 4.0. Please do NOT change or remove this
181 without talking with the webmasters or licensing team first.
182 Please make sure the copyright date is consistent with the
183 document. For web pages, it is ok to list just the latest year the
184 document was modified, or published.
185
186 If you wish to list earlier years, that is ok too.
187 Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
188 years, as long as each year in the range is in fact a copyrightable
189 year, i.e., a year in which the document was published (including
190 being publicly visible on the web or in a revision control system).
191
192 There is more detail about copyright years in the GNU Maintainers
193 Information document, www.gnu.org/prep/maintain. -->
194 <p>Copyright &copy; 1998, 2021 Richard Stallman</p>
195
196 <p>Esta página está bajo licencia <a rel="license"
197 href="http://creativecommons.org/licenses/by-nd/4.0/deed.es_ES">Creative
198 Commons Reconocimiento-SinObraDerivada 4.0 Internacional</a>.</p>
199
200 <!--#include virtual="/server/bottom-notes.es.html" -->
201 <div class="translators-credits">
202
203 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
204 </div>
205
206 <p class="unprintable"><!-- timestamp start -->
207 Última actualización:
208
209 $Date: 2021/10/01 17:02:54 $
210
211 <!-- timestamp end -->
212 </p>
213 </div>
214 </div>
215 <!-- for class="inner", starts in the banner include -->
216 </body>
217 </html>

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26