Por qué un creador de 28 años cambia a EUPL: el fin del MIT

La decisión de Bergius: cerrar el grifo del SaaS loophole

Henri Bergius, el desarrollador finlandés detrás de proyectos como NoFlo y ex-CTO de Flowhub, llevaba 28 años publicando software. Tras pasar por LGPLv2, luego MIT y unos años de silencio tras cerrar su startup, este año dio un giro radical: su «licencia por defecto» pasa a ser la EUPL-1.2 (European Union Public Licence). En su blog, lo explica sin rodeos: «We won the debate, and gained little for users or developers».

La elección no es casual. EUPL-1.2 es un copyleft fuerte aprobado por la OSI que cierra el SaaS loophole: cualquier empresa que ofrezca el software como servicio sigue obligada a liberar las modificaciones bajo la misma licencia. El propio Bergius lo resume: si una corporación no quiere usar su código bajo esas condiciones, «is free to spend the effort or tokens to build their own».

Qué es la EUPL y por qué importa fuera de Silicon Valley

La EUPL no es una licencia más de una comunidad cualquiera. Fue escrita y publicada por la Comisión Europea en 2007, está aprobada por la OSI, la FSF y Debian, y tiene traducciones oficiales en los 23 idiomas oficiales de la UE, todas con la misma validez legal. La versión vigente, la 1.2, se publicó en mayo de 2017 y amplió la compatibilidad con GPLv3, AGPLv3, MPLv2 y LGPL, entre otras.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Su punto de fricción con la cultura del MIT es directo: mientras el MIT y el BSD son permisivos (deja hacer, no te metas en problemas legales), la EUPL es reciprocidad real: si distribuyes el código o lo ofreces en la nube como servicio, tus cambios vuelven a la comunidad. Es exactamente la pieza que la GPLv3 intentó añadir con el apartado «ASP loophole» y que la AGPLv3 formalizó después.

Según datos de Wikipedia, entre los usuarios notables de EUPL están AusweisApp2 (la app oficial del eID alemán), Diia (la plataforma de gobierno electrónico de Ucrania), OpenTalk (videoconferencia soberana), Pi-hole y WLED. La mayoría son proyectos de soberanía digital o administraciones públicas europeas que necesitan una licencia alineada con el derecho de autor continental, no con la costumbre californiana.

Por qué el copyleft vuelve a estar de moda

El movimiento de Bergius no es aislado. En junio de 2026, un equipo del Digital Ethics Center de Yale publicó en el International Journal of Law and Information Technology una propuesta llamada CCAI (Contextual Copyleft AI License): tratar los modelos de IA generativa entrenados con código open source como obras derivadas, obligando a publicar su arquitectura y datos de entrenamiento.

La motivación es idéntica a la de Bergius. Como dice el paper de Yale: «AI companies have benefited from using open-source code, but their resulting models are not really open». El mismo patrón, la misma asimetría: el software libre provee la materia prima, una empresa captura el valor y devuelve cajas negras. El copyleft fuerte es, otra vez, la respuesta jurídica.

El propio Bergius lo verbaliza con una dureza poco habitual en el mundillo open source: el «open source» ganó el debate cultural, pero sólo consiguió «make it easier for big corporations build things more cheaply and for billionaires to become trillionaires». Para un fundador hispano que mantiene una librería o un framework, esa frase debería sonar.

Qué cambia en su portfolio: lo que ya está en EUPL

Bergius no se limitó a escribir el post. Estos son los proyectos que ya publica bajo EUPL-1.2 según su blog:

reticulum-js: implementación en JavaScript del protocolo de red mesh Reticulum.
dacar: sistema de autorización descentralizada construido sobre Reticulum.
signalk-energy-predictor: predicción energética para embarcaciones con renovables.
offshore-blogging-system: herramienta para publicar y descargar datos meteorológicos vía mensajes satelitales InReach.

La nueva versión del NoFlo Development Environment también se desarrolla bajo EUPL. Eso sí, NoFlo en sí sigue siendo MIT por una razón práctica que cualquier CTO entiende: el proyecto preexistente ya tiene contribuciones de terceros, y cambiar retroactivamente la licencia sería legalmente costoso y éticamente cuestionable.

¿Qué significa esto para tu startup?

Si tu startup depende de una librería bajo MIT y de pronto su mantenedor cambia a EUPL, no pasa nada en el 95% de los casos: puedes seguir usándola, distribuirla y enlazarla (estática o dinámicamente) sin que tu código tenga que cambiar de licencia. La EUPL sólo te obliga a liberar bajo EUPL las modificaciones que hagas al propio código EUPL, no tu producto entero.

Pero si tu modelo de negocio es ofrecer ese software como servicio y mejorarlo internamente sin publicar nada, el SaaS loophole ya no te protege. Para una startup SaaS hispanoamericana que pivota hacia un nicho de infraestructura, eso significa que la «ventaja oculta» del fork sin retorno se acabó. Si quieres construir una capa de negocio sostenible sobre software copyleft fuerte, tienes tres caminos:

Construir valor en código propio alrededor y tratar la librería EUPL como materia prima estandarizada (es lo que hacen casi todos los usuarios de AGPLv3 en Europa).
Negociar una licencia comercial cuando la hay (no todos los proyectos la ofrecen; pregunta antes de casarte tecnológicamente).
Contribir de vuelta: en copyleft fuerte, lo que vuelve siempre supera lo que entra, sobre todo en proyectos pequeños con un solo mantenedor.

Acciones concretas que podés tomar esta semana:

Haz un inventario de licencias de las dependencias críticas de tu producto (hay herramientas gratuitas como license-checker en npm o pip-licenses en Python). Si dependes de algo con copyleft fuerte, mapea qué módulos tocas y qué no.
Si tu negocio es SaaS sobre código abierto, revisa si tu infraestructura usa AGPLv3 o EUPL: el riesgo legal no es hipotético, ha habido enforcement real en los últimos años.
Antes de empezar un proyecto personal o un side-project, elegí tu licencia como decisión de producto, no de archivo: si querés visibilidad comunitaria y adopción, MIT o Apache-2.0 siguen siendo las reinas; si querés proteger tu trabajo del scraping industrial, EUPL, AGPLv3 o SSPL son herramientas legítimas y cada vez más usadas.

Conclusión

El cambio de Bergius no es un capricho de un desarrollador veterano: es un síntoma de un giro más amplio. El copyleft fuerte vuelve a tener argumentos en una industria donde el valor se captura en la nube, no en la distribución binaria. Para founders hispanos construyendo sobre hombros de open source, la pregunta ya no es «¿es MIT o GPL?», sino «¿qué licencia encaja con el modelo de negocio que quiero defender?».