El desarrollador tras NoFlo cambia sus nuevas licencias a EUPL
Un veterano del desarrollo de código abierto explica su cambio a la EUPL, una licencia europea con copyleft fuerte que cierra el vacío del SaaS.
En los 28 años que lleva publicando software, este desarrollador ha pasado por tres eras de licenciamiento: primero LGPLv2, luego MIT y ahora, desde hace unos meses, EUPL-1.2. En una entrada de su blog explica las razones de este cambio, que no es anecdótico.
Su primera época fue con Midgard, un framework web que licenció con LGPLv2. Después, al meterse de lleno en JavaScript hacia 2011, adoptó MIT, la licencia favorita del ecosistema npm: "haz lo que quieras, pero no me demandes". Eso funcionó durante años, pero su opinión ha cambiado. "Los de la corriente del código abierto (en contraposición a la del software libre) estábamos equivocados. Ganamos el debate y conseguimos poco para usuarios o desarrolladores. Nuestro esfuerzo solo facilitó que las grandes corporaciones construyan cosas más baratas y que los multimillonarios se hagan billonarios".
Por eso ha decidido que sus nuevos proyectos usen EUPL-1.2, una licencia aprobada por OSI creada por la Unión Europea. Lo más relevante: es copyleft fuerte y cierra el llamado "vacío del SaaS": si usas el software como servicio, también tienes que publicar tus modificaciones bajo la misma licencia. Además, tiene traducciones oficiales jurídicamente válidas a 23 idiomas.
Los primeros proyectos que ya han adoptado EUPL son:
- dacar, un sistema de autorización descentralizada sobre Reticulum.
- signalk-energy-predictor, un predictor de energía para barcos.
- offshore-blogging-system, para publicar entradas y capturar datos meteorológicos vía satélite.
- También la reescritura del NoFlo Development Environment se está desarrollando bajo EUPL. NoFlo en sí seguirá con MIT, al ser un proyecto existente con muchas contribuciones de terceros.
La decisión no es baladí: mientras que muchas empresas evitan licencias copyleft fuertes por miedo a tener que publicar su código, este desarrollador prefiere que las corporaciones que no quieran cumplir sus términos se construyan su propio software desde cero. Con esta medida, espera que el código abierto no siga alimentando únicamente los beneficios de unos pocos.
