Estos días, además de el exitoso lanzamiento de Ubuntu 18.04 y de que ya se sabe por dónde tirará Ubuntu 18.10, la noticia es que se ha descubierto un uso fraudulento de las aplicaciones Snap, promocionadas por Canonical. En este caso, un usuario distribuyó como software privativo empaquetado como Snap un fork del juego 2048, disponible como licencia MIT, al que le añadió un programa de minado de criptomonedas que se disimulaba como un proceso más de systemd. La aplicación, para que fuese escogida con facilidad, tenía el nombre de 2048buntu. En cuanto se dio la alarma, gracias a un usuario, Canonical ha suspendido la cuenta y retirado todas las aplicaciones subidas por este usuario de la tienda hasta nuevo aviso, por lo que lo que podía ser parece estar mitigado.
Si bien la respuesta de Canonical ha sido ejemplar y rápida, este suceso pone el foco en como se acepta software en la tienda de Snap. De momento, lo existente son controles automáticos, que por lo que se ve no están preparados para encontrar este tipo de fallas. Quizás sea momento de que en Canonical empiecen a primar la calidad sobre la cantidad en esta guerra que se traen por la supremacía del empaquetado de apps en Linux.
Si nos vamos a debates más profundos, esto además revela problemas de construcción de las licencias libres. Cuando se debate sobre si GPL o MIT o cualquiera de las otras, una de las líneas principales de debate es sobre si la libertad de poder privatizar el código es necesaria o no. Muchos programadores, con normal preocupación sobre si podrán vivir de lo suyo, suelen defender la necesidad de que el código pueda ser privado, ya que este suele ser más rentable económicamente.
Esta es la vía por la cual la mayor parte de empresas suelen estar más cómodas con licencias de este tipo frente a la GPL, que obliga a que todo sea libre una vez se implementa, tanto el original como los derivados. Sin embargo, y ya no hablando del aprovechamiento tradicional que hacen muchas empresas de la comunidad para después cerrar todo a cal y canto, es evidente que permitir a cualquiera cerrar el código facilita en cierta medida este tipo de sucesos. Crear un Caballo de Troya (troyano es otra cosa cuando hablamos de seguridad), empaquetando un software de minado como un inocente juego, teniendo que publicar todo el código se hace muchísimo más difícil.
De ahí que el problema de Snap (y de cualquier otro software que se distribuya) al final no es tanto los controles que se hagan sobre código abierto, si no lo limitados que estamos cuando este se cierra. El debate de toda la vida, vamos.
