![[imagen de la Cabeza de un GNU]](/graphics/gnu-head-sm.jpg)
[ Ruso ]
El proyecto llamado UDI (Uniform Driver Interface [Interface Uniforme para Controladores de Dispositivos]), se propone definir una interface única entre núcleos de sistemas operativos y controladores de dispositivos. ¿Qué es lo que el movimiento para el software libre debería hacer sobre esta idea?
Si nos imaginamos a un número de programadores de sistemas operativos y hardware, todos cooperando en un mismo fundamento, UDI (si es técnicamente posible) sería una idea muy buena. Nos permitiría desarrollar un solo controlador para un dispositivo dado de hardware, y compartirlo entre todos. Permitiría un nivel más alto de cooperación.
Cuando aplicamos la idea al mundo real, que contiene ambos, programadores de software libre buscando cooperación, y de software privativo buscando dominación, las consecuencias son muy diferentes. De ninguna manera el uso de UDI puede beneficiar al movimiento del software libre. Si hace algo, nos dividirá y nos debilitará.
Si Linux apoya UDI, y si nosotros empezamos a diseñar nuevos controladores para comunicarnos con Linux mediante UDI, ¿cuáles serían las consecuencias?
Esto ayudará sólo a los usuarios de Windows; no hará nada para nosotros usuarios de sistemas operativos libres. No nos lastimaría directamente, tampoco; pero los programadores de los controladores libres [free drivers] cubiertos por la licencia GPL, podrían quedar desalentados al ver que son utilizados de esta manera, lo que sería muy desfavorable. Podría ser también una infracción de la licencia GPL de GNU, al enlazar los controladores dentro de un núcleo («kernel») privativo. Aumentar la tentación de hacer esto es buscar problemas.
Esto no afectaría directamente el ámbito de hardware sostenido por el software libre. Pero indirectamente tendería a disminuir el ámbito, ofreciendo una tentación al millón de usuarios de GNU/Linux que no han aprendido a insistir en la libertad para su propia conveniencia. Al punto que la comunidad empiece a aceptar la tentación, nos estaríamos moviendo a usar controladores no-libres en lugar de escribir nuestros propios controladores libres.
UDI no obstruye, en si mismo, el desarrollo de controladores libres. Entonces, si muchos de nosotros rechazamos la tentación, todavía podríamos desarrollar controladores libres a pesar de UDI, al igual que hacemos sin UDI.
¿Pero por qué alentar la comunidad a ser más débil de lo que necesita ser? ¿Por qué crear dificultades innecesarias para el futuro del software libre? Ya que UDI no hace nada bueno para nosotros, es mejor rechazar UDI.
Dadas estas consecuencias, no es sorpresa que Intel, un partidario de UDI, ha comenzado a "buscar ayuda con UDI en la comunidad Linux". ¿Cómo una compañía rica y egoísta se acerca a una comunidad cooperadora? Pidiendo una ayuda, por supuesto. Ellos no tienen nada que perder preguntando, y nosotros quizás seamos agarrados desprevenidos y digamos sí.
La cooperación con UDI nos es imposible. No debemos etiquetar a UDI, Intel, ni a nadie, como un Gran Satanás. Pero antes de participar en cualquier trato propuesto, nosotros lo debemos juzgar detenidamente, para cerciorarnos que es ventajoso para la comunidad del software libre, no solamente para programadores de sistemas privativos. En este asunto particular, esto significa que requiramos una cooperación que nos tome un paso más adelante en un sendero que nos dirija a la última meta para los núcleos y controladores libres: apoyar todo hardware importante con controladores libres.
Una manera de hacer bueno un trato podría ser al modificar el mismo proyecto UDI. Eric Raymond ha propuesto que la conformidad con UDI podría requerir que el controlador sea software libre. Eso sería ideal, pero otras alternativas podrían servir también. Requerir que se publique la fuente para el controlador, y que no sea un secreto de comercio, podría hacer el trabajo -- porque aunque ese controlador no sea libre, por lo menos nos diría lo que necesitamos saber para escribir un controlador libre.
Intel también podría hacer algo fuera de UDI para ayudar a la comunidad del software libre para resolver este problema. Por ejemplo, puede haber algún tipo de certificación de hardware que los desarrolladores de hardware busquen, para lo cual Intel juega un papel en su otorgamiento. Si ése es el caso, Intel podría acordar hacer la certificación más difícil si las especificaciones del hardware son secretas. Eso quizás no sea una solución completa al problema, pero podría ayudar bastante.
Una dificultad con cualquier trato con Intel acerca de UDI es que nosotros haríamos nuestra parte para Intel al inicio, pero la paga de Intel se extendería sobre mucho tiempo. En efecto, estaríamos extendiendo crédito a Intel. ¿Pero Intel continuaría devolviendo su préstamo? Probablemente sí, si lo obtenemos por escrito y no hay escapatorias; de otro modo, no podemos contar con esto. Las corporaciones son notoriamente no confiables; la gente que tratamos puede tener integridad, pero ellos podrían ser reglamentados desde arriba, o incluso reemplazados en cualquier momento con gente diferente. Aún un CEO que posee la mayor parte de las acciones se puede reemplazar por un compra total. Cuando se hace un trato con una corporación, siempre se obtiene un compromiso obligatorio por escrito.
No parece probable que Intel nos ofrecería un trato que nos dé lo que necesitamos. Es más, UDI parece diseñado para hacer más fácil mantener secretas las especificaciones.
Sin embargo, no haría daño en dejar las puertas abiertas, solo necesitamos tener cuidado de a quien dejamos entrar.
Para pedido y preguntas sobre la FSF & GNU contacte a gnu@gnu.org. Otros medios de contacto con la FSF.
Por favor enviar comentarios respecto a estas páginas a webmasters@www.gnu.org, envia otra clase de preguntas a: gnu@gnu.org.
Copyright 1998 Richard Stallman
Está permitida la copia textual y distribución de este artículo en su totalidad por cualquier medio, siempre y cuando esta nota se preserve.
Actualizado: 3 Dec 2000 tower
Traductora original: Paula Aguilar
Revisión:
Coordinación: Hugo Gayosso hgayosso@gnu.org