Esta es una traducción de la página original en inglés.

El software libre y el juicio antimonopolio contra Microsoft

Con el juicio antimonopolio contra Microsoft llegando a su conclusión, se empieza a plantear la cuestión de qué pedir a Microsoft en caso de que pierda. Ralph Nader incluso organizó [cuando se escribió este artículo, en marzo de 1999] una conferencia sobre el tema (véase appraising-microsoft.org/).

Las respuestas obvias de restringir los contratos entre Microsoft y los fabricantes de ordenadores o de dividir la empresa, no constituirán una diferencia significativa. La primera facilitaría la disponibilidad de ordenadores con el sistema GNU/Linux preinstalado, pero de todos modos esto ya está ocurriendo. La segunda ayudaría a otros desarrolladores de aplicaciones privativas a competir, con lo que sólo se ofrecería a los usuarios otras formas alternativas para renunciar a su libertad.

Por este motivo, propongo tres soluciones que podrían ayudar para que los sistemas operativos de software libre, como GNU/Linux, sean técnicamente competitivos respetando al mismo tiempo la libertad de los usuarios. Estas tres soluciones abordan directamente los tres mayores obstáculos para el desarrollo de los sistemas operativos libres y para dotarlos de la capacidad de ejecutar programas escritos para Windows. También abordan directamente la cuestión de los métodos que Microsoft utilizará para bloquear el software libre (anunciados en los «documentos Halloween»). Lo más efectivo sería usar las tres soluciones conjuntamente.

  1. Exigir a Microsoft que publique la documentación completa de todas sus interfaces entre componentes de software, protocolos de comunicación y formatos de ficheros. Esto bloquearía una de las tácticas favoritas de Microsoft: las interfaces secretas e incompatibles.

    Para que este requerimiento sea realmente eficaz, no se debe permitir que Microsoft utilice acuerdos de confidencialidad [nondisclosure agreement][1] con otras organizaciones como pretexto para implementar interfaces secretas. La regla ha de ser: si no pueden publicar la interfaz, tampoco pueden publicar su implementación.

    No obstante, sería aceptable permitir que Microsoft empezara a implementar una interfaz antes de publicar las especificaciones, siempre y cuando se publiquen las especificaciones junto con la implementación.

    Hacer cumplir este requisito no sería difícil. Si otros desarrolladores de software se quejaran de que la documentación publicada no describe algún aspecto de la interfaz o cómo hacer una determinada tarea, los tribunales obligarían a Microsoft a dar una explicación sobre estos aspectos. Cualquier pregunta sobre las interfaces (diferenciándolas de las técnicas de implementación) deberá ser respondida.

    En el año 1984 se incluyeron términos similares a estos en un acuerdo entre IBM y la Comunidad Europea, con lo cual se puso fin a una más de las disputas antimonopolio. Véase www.cptech.org.

  2. Exigir a Microsoft que, en el campo del software, use sus patentes únicamente para defenderse. (en el caso de que posea patentes que se aplican a otros campos, estos últimos podrían incluirse en este requerimiento, o bien podrían excluirse). Esto bloquearía otra de las tácticas que Microsoft mencionó en los «documentos Halloween»: utilizar las patentes para bloquear el desarrollo de software libre.

    Deberíamos dar a Microsoft la opción de usar la defensa propia o la defensa mutua. La defensa propia significaría ofrecer un intercambio de licencias de todas las patentes, sin coste alguno, a cualquiera que la quiera. La defensa mutua significaría dar la licencia de todas las patentes a un grupo, donde cualquiera pueda unirse, incluso aquellas personas que no tengan ninguna patente en propiedad. Este grupo permitiría que cualquier miembro tuviera las licencias de todas las patentes de todos los miembros.

    Es vital abordar la problemática de las patentes, porque no serviría de nada que Microsoft publicara una interfaz si logran introducir algún elemento patentado en la interfaz misma (o en la funcionalidad a la que da acceso), de tal forma que al resto de nosotros no se nos permita implementarla.

  3. Exigir a Microsoft que no certifique que el hardware funciona con software de Microsoft, a menos que se hayan publicado las especificaciones completas del hardware en cuestión. De esa manera cualquier programador podríaimplementar software que funcione en ese hardware.

    En general las especificaciones de hardware secretas no constituyen una práctica habitual de Microsoft, pero son un obstáculo significativo para el desarrollo de sistemas operativos libres que puedan competir con Windows. Eliminar este obstáculo sería una gran ayuda. En el caso de que se establezca una negociación con Microsoft, incluir este tipo de disposición no sería imposible, sería un punto de la negociación.

En abril de este año, Steve Ballmer, de Microsoft, anunció un posible plan para publicar parte del código fuente de Windows. No está muy claro si esto implica hacerlo software libre, o de qué parte de Windows se trataría. Pero si Microsoft publica una parte importante de Windows como software libre, podría solucionar estos problemas en lo que respecta a esa parte (también podría contribuir a la comunidad del software libre, si el software en cuestión pudiera utilizarse para otros propósitos además de ejecutar más software privativo de Microsoft).

Sin embargo, poder usar como software libre parte de Windows es menos crucial que el hecho de que esté permitida la implementación de todas las partes. Las soluciones propuestas arriba es lo que realmente necesitamos, abrirán el camino para que desarrollemos una alternativa realmente superior al Windows de Microsoft, en todas aquellas áreas de Windows que Microsoft no publique como software libre.

Notas de traducción
  1. «Nondisclosure agreement» es un tipo de acuerdo confidencial mediante el cual los firmantes intercambian información obligándose a no difundirla.