Hace unos meses, en plena discusión mundial sobre si el uso de Mono en Linux suponía un riesgo para el software libre o no, publiqué una entrada ofreciendo mi punto de vista. Sin embargo, lo que conté era sólo la mitad, porque en ese momento me pareció que no era adecuado echar más leña al fuego, así que decidí limitarme a la parte puramente técnica. Ahora que ya ha pasado un tiempo y las cosas están más calmadas he decidido escribir la segunda parte. Preparaos para un articulo de opinión, y encima largo.

Lo primero, decir que Mono, estrictamente hablando (esto es, la implementación libre de los estándares ECMA-334 y ECMA-335), no tiene por qué ser un problema para el software libre, gracias, principalmente, a la promesa de Microsoft de no ejercer esas patentes (vamos a pecar de confiados y, a pesar de no ser abogados, supondremos que realmente es universal, definitiva e irrevocable).

Sin embargo, el primer gran problema que encontramos es que esos dos estándares sólo cubren una parte de .NET, en concreto la máquina virtual, el lenguaje C# y la biblioteca estándar de dicho lenguaje. Pero .NET es mucho más que eso, porque está ASP.NET, ADO.NET y las WinForms, entre otros muchos componentes. Un argumento que esgrimen los defensores de Mono es que éste no pretende ser compatible con .NET hasta el punto de poder ejecutar todas sus aplicaciones (eso es sólo un efecto colateral), sino simplemente ser un entorno de desarrollo moderno para GNU/Linux, que aumente la productividad. Esto se puede ver perfectamente cuando leemos el Mono Rationale y algunas entrevistas a Miguel de Icaza: todo el énfasis lo ponen en el soporte de múltiples lenguajes y en la mejora del rendimiento en el desarrollo, pero no lamenta que no vaya a haber compatibilidad completa porque no hay nadie que se anime a escribir determinadas bibliotecas, sino que incluso recalca que hay muchos módulos específicos de Mono que permiten escribir programas que no funcionarían en .NET.

¿Y qué problema hay, entonces, en utilizar un entorno de desarrollo basado en dichos estándares, y completándolos con herramientas y bibliotecas libres (como GTK#, por ejemplo) para rellenar los huecos que faltan, y sin buscar compatibilidad con el .NET de Windows? Personalmente tiendo a alinearme con la gente que defiende que no hay ninguno (aunque me remito a las razones técnicas que esgrimo en mi anterior entrada): por una parte el riesgo de patentes es prácticamente nulo, porque Microsoft se ha comprometido a no atacar con ninguna de ellas (aunque pienso que la razón es que, estratégicamente, sería peor para ella); y por otro lado, aunque .NET avance demasiado rápido para mantenerse a la par (cosa que ni siquiera hoy en día se está consiguiendo con Mono) o si Microsoft cambiase las APIs creando problemas de compatibilidad, tampoco sería un problema porque el objetivo no es ser compatibles con ellos.

Pero…

Obviamente hay un pero, porque si no, el título de este post no tendría ningún sentido. Ese pero surge del hecho de que la misma existencia de .NET, tan abierto, tan estandarizado, tan portable, no parece tener sentido viniendo de una empresa que ha monopolizado la web durante años, que ha intentado poner trabas al software libre mediante tácticas cuanto menos discutibles, y que ha sido acusada de mantener una posición de monopolio en el mercado de los sistemas operativos y navegadores. ¿Por qué sacar un producto que puede beneficiar tanto a tu rival, y además darle tantas facilidades, cuando tu historial habla siempre de acciones totalmente opuestas? ¿Se está regenerando Microsoft?

La respuesta, en mi opinión, está en Silverlight: Microsoft perdió el control que tenía sobre la web y ahora quiere recuperarlo, pero la gran cantidad de navegadores disponibles hoy en día, así como la sensibilización que hay hacia el uso de estándares, le impide repetir la táctica de añadir sus propias extensiones a HTML. Por otro lado están Java y Adobe Flash. El primero, a nivel web, está hoy de capa caída, aunque intenta recuperar el terreno mediante JavaFX. El segundo es un peso pesado, pero está perdiendo terreno gracias a HTML5 y al peso de la comunidad, que intenta incentivar el uso de estándares. Y es justo aquí donde Microsoft intenta atacar con Silverlight: crea un nuevo plugin para que los desarrolladores hagan lo que hacían con Flash, pero con la ventaja de que es tecnología basada en .NET, lo que significa que se puede reutilizar código de otras aplicaciones aunque no sean aplicaciones web (cosa imposible con HTML5); es una plataforma agnóstica respecto al sistema operativo y a la arquitectura gracias al uso de una máquina virtual (igual que Java y Flash), y encima se basa en estándares abiertos (ECMA-334 y ECMA-335), lo que permite a terceros hacer implementaciones propias, como por ejemplo Moonlight, que se basa, como no, en Mono.

¿Y donde está el problema? Pues en que Silverlight no está dentro de ningún estándar. Como dije al principio, los dos estándares ECMA cubren únicamente el lenguaje C# y su biblioteca estándar, así como la máquina virtual, pero todas las bibliotecas específicas de Silverlight están fuera, por lo que Microsoft tiene libertad absoluta para cambiarlas y ampliarlas a su antojo.

Con esto echamos por tierra el principio de que no importa que cambie la especificación porque la compatibilidad no es un objetivo: si Mono no es 100% compatible con .NET, Moonlight no lo será con Silverlight y no servirá para nada. Y si hay que garantizar la compatibilidad, el software libre siempre irá a remolque, y a buena distancia, de Microsoft, por lo que la gente se verá obligada a utilizar la máquina de .NET, pues Mono y Moonlight no implementarán todo lo necesario (y la especificación se mantendrá en continuo aumento). Para aquellos que piensen que exagero, me remito a los diversos clones de Flash que se han intentado hacer en el mundo del software libre: ninguno funciona lo suficientemente bien como para reemplazar sin problemas al plugin oficial de Adobe. Y que no se me interprete mal: hay un gran trabajo detrás de todos ellos; simplemente es una tarea muy grande sobre un blanco muy móvil.

Hace tiempo ya nos topamos con el primer aviso cuando el SIGPAC se pasó a Silverlight: la respuesta de los creadores comenzaba diciendo que los datos ya están disponibles en formato WMS, que es un estándar para acceso a información cartográfica, aunque sí se puede alegar que no son los datos, sino el servicio, el que también debería ser accesible desde cualquier sistema operativo. A continuación, añadía que la versión en Silverlight es accesible desde multitud de sistemas operativos, incluido Linux, gracias a Moonlight, aunque luego aclaraba que, en este último caso, se conocían algunos problemas porque el SIGPAC necesita la versión 3 de Silverlight, y Moonlight implementa sólo la versión 2. Cinco meses después sólo hay una versión preliminar de la 3, todavía en fase alfa, mientras que Silverlight ya va por la versión 4: el software libre siempre irá a remolque si la especificación depende de una única empresa en lugar de ser un estándar oficial.

Lo mismo ocurre con los mundiales de fútbol en Telecinco: para verlos necesitas Silverlight, y Moonlight todavía no sirve (aunque la versión alfa de la 3.0 parece que sí lo soporta, pues en la página oficial dice textualmente: “With Moonlight you can watch the Olympics on Linux with our 3.0 preview”). Por otro lado, vemos que también quiere integrarlo en televisores y otros dispositivos, lo que parece indicar ya la estrategia de Microsoft: meter Silverlight en todos los ámbitos que pueda.

Y si alguien aún se pregunta qué gana Microsoft consiguiendo que todo el mundo utilice una plataforma que se consigue gratis o de la que cualquiera puede crear una versión alternativa (aunque siempre vaya a remolque de la oficial), la respuesta (aparte de vender más herramientas de desarrollo y de que, como su versión será siempre la más avanzada y sólo la hay para windows, se asegura de que windows se utilice más, que ya es bastante) es que tiene el poder de forzar el uso de otras tecnologías en las que colabora, muchas de ellas de pago. Por poner un ejemplo, Microsoft forma parte del MPEG-LA, que cobra los royalties por el uso de H.264, codec de vídeo que se utiliza en Silverlight para realizar streaming. Al ser Silverlight su tecnología, ellos deciden qué entra y qué no, pudiendo eliminar a la competencia (por ejemplo, a Theora o a WebM) y ganando ellos dinero con las licencias de esas tecnologías. De hecho, la licencia de Microsoft por la que promete no perseguir implementaciones libres de Silverlight excluye expresamente el pago de royalties por codecs patentados. Por otro lado, que actualmente sea gratis no significa que, en el futuro (cuando esté extendido y sea casi obligatorio integrarlo si quieres vender), no haya que pagar por poner Silverlight en el último modelo de televisor.

Y esto es lo realmente peligroso para el software libre, pues no solo iremos siempre a remolque de la implementación privativa, sino que, en muchos casos, podremos vernos completamente atados (baste ver los problemas que tiene Debian o la Mozilla Foundation para incluir algunos codecs de serie en países con patentes de software).

Por todo esto, aunque no rechacemos a Mono en sí, creo que sí deberíamos rechazar con todas nuestras fuerzas a Silverlight y a Moonlight, y exigir que se utilicen únicamente estándares abiertos como HTML5 para realizar las páginas web, en lugar de sistemas privativos controlados por empresas. Precisamente ahora que tenemos las herramientas necesarias para ganar la batalla a Flash no debemos cometer el error de caer en un nuevo plugin privativo.

O esa es, al menos, mi opinión.

El verdadero peligro de Mono por A cuadros está licenciado bajo una Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.