Existe un momento que tarde o temprano llega a casi cualquier proyecto de cierto tamaño. Alguien — normalmente un abogado o un responsable de compras nervioso — pregunta: «¿Qué licencia debería llevar esto?»

Hasta entonces todo iba maravillosamente. Código escrito, pruebas en verde, repositorio enviado. Y de pronto hay gente debatiendo sobre copyleft, cláusulas de patentes y obras derivadas como si de ello dependiera todo.

En cierto sentido, todo depende de ello.

Las licencias no son formalidades. Son las reglas del juego bajo las cuales existe el software. Quien las ignora juega igual — según reglas que otro eligió.

Por qué hay tantas licencias

Respuesta breve: porque el software libre tuvo dos movimientos que nunca fueron del todo el mismo.

De un lado, Richard Stallman y la Free Software Foundation, fundada en 1985, con una posición ética clara: el software que no puede estudiarse, modificarse ni redistribuirse priva a sus usuarios de libertades fundamentales. De ahí nació la GPL — copyleft fuerte, contagioso, sin concesiones.

Del otro, los pragmáticos de la tradición Unix de Berkeley y posteriormente la Open Source Initiative (OSI, 1998), que entendían el software libre más bien como un modelo eficiente de desarrollo que como un deber moral. De ahí surgieron las licencias permisivas — MIT, BSD — cortas, liberales, favorables a la comercialización.

Entre estos polos se formó un espectro. Se sumaron abogados, intereses corporativos, patentes, problemas de compatibilidad y el sempiterno afán de reinventar la rueda. Hoy SPDX enumera más de trescientos identificadores válidos. Nadie los conoce todos. Tampoco hace falta. Pero cualquiera debería conocer los importantes.

Dos familias, una misma pregunta

En el fondo toda licencia responde a una misma pregunta: ¿Qué puede hacer otra persona con mi código — y qué debe devolver a cambio?

Las licencias permisivas liberan casi todo. Usar, modificar, vender, integrar en productos propietarios — mientras mi nombre permanezca en el aviso de copyright. Dame reconocimiento, quédate con el resto.

Las licencias copyleft exigen reciprocidad. Quien modifica mi código y lo redistribuye debe publicar sus versiones bajo la misma licencia. Lo que recibiste, lo transmites.

Las licencias de copyleft débil se sitúan entre ambos extremos: solo infectan la biblioteca, no el programa que la consume. Un compromiso que protege a los autores de bibliotecas sin alienar a los consumidores.

Con esta rejilla las licencias conocidas encuentran su sitio con naturalidad.

Las licencias que conviene conocer

MIT. La licencia seria más corta del mundo. Unos 170 palabras. Permite virtualmente todo, exige únicamente el aviso de copyright. React, Ruby on Rails, jQuery, las bibliotecas cliente de Kubernetes — todas MIT. Quien busca máxima difusión elige MIT.

BSD. Existe en tres variantes relevantes. La forma de dos cláusulas equivale en la práctica a MIT. La de tres cláusulas prohíbe además emplear el nombre del autor para publicitar derivados propios. La histórica de cuatro cláusulas exigía incluso mención en cualquier publicidad de producto — lo cual producía avisos de copyright absurdos a través de cientos de dependencias y durante largo tiempo hizo inutilizable el código BSD dentro de proyectos GPL. FreeBSD, nginx, PostgreSQL utilizan variantes BSD.

Apache 2.0. El miembro adulto de la familia permisiva. Publicada en 2004, añade a MIT y BSD tres cosas que importan en la práctica: una concesión explícita de patentes (todo contribuyente concede a los usuarios sus patentes), una cláusula de represalia (quien litigue por patentes pierde sus derechos) y el mantenimiento de un archivo NOTICE para atribuciones. Apache Kafka, el núcleo de Kubernetes, TensorFlow están bajo Apache 2.0. Suele ser la mejor opción para pilas comerciales.

GPL v2. Desde 1991, el pegamento del núcleo Linux. Copyleft fuerte: quien distribuya obras derivadas debe publicar también su código fuente completo bajo GPL v2. Concisa a propósito, sin cláusula de patentes a propósito. Su disposición más célebre se apoda «Liberty or Death» — si no puedes cumplir las condiciones, tampoco puedes redistribuir nada.

GPL v3. Revisada en 2007 después de que patentes, DRM y dispositivos cerrados («tivoización») abriesen nuevas líneas de ataque contra el software libre. Sumó la concesión de patentes, exigió información de instalación para dispositivos, codificó cláusulas anticircunvención y mejoró la compatibilidad con otras licencias. Política controvertida, jurídicamente más pulcra. Muchos proyectos insignia se quedaron en v2 (Linux), otros migraron (Bash, GCC, Samba).

LGPL v2.1 y v3. Las variantes «Lesser». Copyleft débil para bibliotecas: quien modifica la biblioteca y la redistribuye debe publicar los cambios bajo LGPL — pero los programas que simplemente enlazan contra la biblioteca pueden seguir siendo propietarios. El pacto clásico: proteger la biblioteca, dejar libre al consumidor. glibc, GTK, Qt (en ocasiones) son LGPL.

MPL 2.0. La licencia propia de Mozilla, enero de 2012. Copyleft débil a nivel de archivo: quien cambia archivos MPL concretos y los redistribuye debe publicar esos archivos bajo MPL — el resto de un programa puede permanecer propietario. Redacción limpia, pragmática, popular entre consorcios empresariales. Firefox, Thunderbird y numerosos crates de Rust usan MPL.

AGPL v3. La GPL de red. Cierra la llamada laguna ASP: el copyleft clásico solo se activa al distribuir el software. Quien simplemente lo aloja como servicio no distribuye nada — y hasta ahora no debía revelar el código. La AGPL invirtió eso: el uso en red activa por sí mismo la obligación de divulgación. Popular entre proveedores SaaS que quieren disuadir a competidores de alojar su trabajo sin permiso. Mastodon, Nextcloud, Plausible Analytics, MinIO.

EPL. La Eclipse Public License, arraigada en la tradición de IBM, actualmente en versión 2.0. Copyleft débil parecido a MPL, con concesión clara de patentes y simpatía comercial explícita. Eclipse IDE, Jakarta EE, la mayoría de proyectos de la Fundación Java, los JDK Adoptium/Temurin. Con frecuencia la alternativa pragmática cuando la GPL parece arriesgada comercialmente pero BSD resulta demasiado permisiva.

Unlicense y CC0. Las radicales. Ambas renuncian íntegramente al derecho de autor — en la medida en que ello sea posible en algunas jurisdicciones. Unlicense (2010) apunta directamente al software, CC0 (2009, Creative Commons) originalmente a datos, obras artísticas y textos. Comparten una debilidad: donde el derecho de autor es irrenunciable (Alemania, por ejemplo), persiste la incertidumbre jurídica. Además CC0 carece de cláusula de patentes. Para sistemas de producción robustos suele preferirse MIT antes que CC0.

Qué restringen o permiten las licencias

Concretamente, las licencias gobiernan cinco ejes:

  1. Uso — ¿Puedo usarlo comercialmente? En todas las aquí tratadas: sí.
  2. Modificación — ¿Puedo cambiar el código? Sí, en todas partes.
  3. Distribución — ¿Bajo qué condiciones? Aquí el rebaño se separa.
  4. Patentes — ¿Recibo una concesión explícita? Únicamente Apache 2.0, GPLv3, MPL 2.0, EPL 2.0, AGPL v3.
  5. Uso en red — ¿Provoca el alojamiento una obligación de divulgación? Únicamente AGPL.

Se suman puntos secundarios: marcas (siempre retenidas por el proyecto origen), exenciones de responsabilidad (universales), atribución (universal) y compatibilidad mutua — todo un campo en el que bufetes enteros ganan su sustento. La verdad amarga: las licencias no necesariamente son combinables. Código GPLv2 no puede mezclarse con código Apache 2.0 sin una excepción. CDDL y GPL se consideran incompatibles — base de disputas de años en torno a ZFS-sobre-Linux.

Historias que conviene conocer

La masacre BusyBox. A partir de 2007, Erik Andersen, la Software Freedom Law Center y más adelante la Software Freedom Conservancy persiguieron a unos catorce fabricantes de electrónica — Verizon, Samsung, Best Buy, Westinghouse — por distribuir routers, grabadoras de vídeo y cámaras con BusyBox embebido sin facilitar el código fuente modificado. Los pleitos terminaron en pagos transaccionales e inhibiciones fundacionales. Demostraron: la GPL es exigible. Tomar código copyleft e ignorar sus condiciones comporta un riesgo jurídico real.

El Linksys WRT54G y el nacimiento de OpenWrt. En 2003, aficionados descubrieron que el popularísimo router Wi-Fi Linksys WRT54G funcionaba internamente sobre Linux y BusyBox — ambos bajo GPL. Linksys, ya propiedad de Cisco, no había publicado el código fuente. Tras el contacto de la Free Software Foundation y Bradley Kuhn, Cisco acabó publicando el árbol fuente completo. Lo que comenzó como un evento de cumplimiento se convirtió en uno de los momentos más fecundos de la informática de consumo: del código liberado surgieron OpenWrt, DD-WRT, Tomato y toda una generación de firmware de router open source. Millones de aparatos que sus fabricantes han olvidado hace tiempo siguen mantenidos por una comunidad hoy. Lección: el copyleft aplicado no produce solo cumplimiento — puede desatar todo un ecosistema.

El episodio React BSD-plus-Patentes. Facebook publicó React en 2013 primero bajo Apache 2.0 y pasó en 2014 a una licencia BSD modificada con un rider de patentes acoplado: quien demandara a Facebook por infracción de patentes perdía de inmediato sus derechos sobre React. En julio de 2017 la Apache Software Foundation, seguida por Jenkins, WordPress y otros, declararon la situación insostenible. En pocas semanas React perdió buena parte de su confianza institucional. En septiembre de 2017 Facebook capituló y colocó React, Jest, GraphQL e Immutable.js bajo MIT puro. Lección: una licencia que oculta cláusulas asimétricas puede poner en peligro todo un ecosistema.

El giro de HashiCorp. En agosto de 2023 HashiCorp anunció que Terraform, Vault, Consul y otros proyectos pasarían de MPL 2.0 a la Business Source License (BSL) — una licencia de fuente disponible que prohíbe a competidores ofrecer servicios gestionados rivales. Durante años usuarios y contribuyentes habían confiado en los proyectos bajo MPL. La comunidad respondió con OpenTofu, un fork bajo MPL ahora custodiado por la Linux Foundation. HashiCorp dilapidó en gran medida su reputación como pionero open source.

El viraje abrupto de Redis. En marzo de 2024 Redis Ltd. cambió de la noche a la mañana la licencia de su base de datos homónima de BSD 3-Clause a un esquema doble RSALv2 / SSPL. Ninguna de las dos sigue siendo open source según la definición de la OSI. Los mayores proveedores de nube — AWS, Google, Oracle, Snap — reaccionaron en cuestión de días con Valkey, un fork bajo BSD 3-Clause ahora hospedado por la Linux Foundation. En semanas Redis perdió una porción considerable de su mercado corporativo.

El paso consciente de MinIO a AGPL. A diferencia de HashiCorp y Redis, MinIO, el almacenamiento de objetos compatible con S3, eligió en 2021 un camino que permaneció dentro del open source. La empresa pasó del permisivo Apache 2.0 a AGPL v3 — una licencia genuina reconocida por la OSI. Objetivo: impedir que los proveedores de nube ofrezcan MinIO como servicio gestionado sin divulgar sus modificaciones. La AGPL se activa precisamente donde el copyleft clásico es impotente: en el uso basado en red. Quien opera MinIO como servicio y lo adapta debe publicar sus modificaciones bajo AGPL. La diferencia decisiva frente a BSL o SSPL: MinIO siguió siendo open source. Los contribuyentes no fueron excluidos, los forks siguieron siendo legítimos, la licencia sigue siendo compatible con el amplio ecosistema GPL. Lección: protegerse contra la canibalización comercial no exige abandonar el open source — exige elegir la licencia adecuada.

CentOS y los límites de lo licenciado. La historia más célebre transcurre en 2020/2023. Desde 2004 CentOS era una reconstrucción comunitaria de Red Hat Enterprise Linux — RHEL sin marca, gratuito, compatible a nivel binario. En 2014 Red Hat incorporó el proyecto, contrató a los mantenedores, lo trajo a casa. Todo parecía en buen orden. El punto de inflexión llegó en diciembre de 2020: Red Hat anunció el fin de CentOS Linux 8 a finales de 2021 y lo sustituyó por CentOS Stream — un canal ascendente continuo que alimenta a RHEL en lugar de una distribución descendente estable. Miles de despliegues en producción construidos sobre CentOS como sustituto gratuito de RHEL enfrentaban la migración. La comunidad respondió con Rocky Linux (iniciado por Gregory Kurtzer, uno de los fundadores originales de CentOS) y AlmaLinux. En junio de 2023 cayó el siguiente golpe: el código fuente de RHEL dejó de publicarse como tarballs de descarga libre, accesible solo para clientes mediante el Red Hat Customer Portal. La GPL no fue vulnerada — el código permaneció abierto para quienes tenían derecho. Pero la vía que permitía las distribuciones clon quedó cerrada. Lección: una licencia correcta por sí sola no protege contra virajes estratégicos. Quien construye sobre un proyecto debe leer, junto con la licencia, la gobernanza, la financiación y los intereses del guardián.

Canibalización bajo el disfraz de protección

Estos episodios no son casos aislados. Forman parte de una tendencia que gana fuerza desde 2018: MongoDB (SSPL, octubre de 2018), Elastic (Elasticsearch y Kibana de Apache 2.0 a SSPL, enero de 2021), Sentry, Cockroach Labs, Confluent — la lista continúa. Patrón compartido: los proyectos construyen durante años una base de contribuyentes y una marca bajo una licencia permisiva o de copyleft débil. Apenas un gran proveedor de nube domina el negocio más rentable de servicios gestionados, el titular cambia la licencia por un modelo que blindaba precisamente ese negocio.

A veces es legítimo. Los mantenedores tienen derecho a la sostenibilidad económica, y el open source nunca fue sinónimo de explotación gratuita. Pero la forma de ejecutarlo cuenta: aceptar contribuciones bajo la licencia antigua y luego encerrar a esos mismos contribuyentes bajo la nueva rompe un contrato social implícito. El resultado ya no es open source — y el ecosistema aprende que tales proyectos pueden convertirse en factores de riesgo en cualquier momento.

Para compradores significa: la estabilidad de licencia se ha vuelto un criterio de selección, no una nota al pie.

Qué significa esto para libcom.de

Desde hace un cuarto de siglo yo — Jochen Demmer, libcom.de — trabajo con productos open source. Empecé en 2001, cuando Linux se consolidaba como sistema operativo de servidores. Hoy sostiene infraestructuras bancarias globales, redes de telecomunicaciones, informática hospitalaria e instalaciones industriales.

De aquella experiencia provienen juicios que ningún libro blanco enseña: qué licencias resisten en entornos regulados, dónde muerde realmente el copyleft, cuándo AGPL señala advertencia en lugar de recomendación, cómo detectar riesgos de retirada de licencia leyendo gobernanza, financiación y estructura de contribuyentes — no solo el README. Ya sea que necesites una estrategia de cumplimiento, una auditoría de pila, redacción de pliegos o acompañamiento de planificación de migración, estas son tareas en las que el dominio de licencias marca la diferencia entre una planificación plurianual tranquila y una renegociación sorpresiva.

Y no veo futuro viable ya para las licencias puramente propietarias en la amplia infraestructura informática. Las razones son empíricas: los sistemas operativos, bases de datos, servidores web, runtimes de contenedores, orquestadores, sistemas de construcción y compiladores de lenguajes más importantes son open source. Incluso los mayores proveedores propietarios construyen hoy sobre open source — las raíces Darwin de Apple, el núcleo Linux de Android, la base de Visual Studio Code en Microsoft. Quien en 2026 crea todavía que el código cerrado sería el camino más seguro pasa por alto que su cadena de suministro supuestamente segura ya está hecha de software libre. Las licencias propietarias podrán persistir en especializaciones estrechas. A escala ya no son contemporáneas.

El open source es el nuevo estándar de hecho. No por ideología. Por rendimiento, transparencia, auditabilidad y pervivencia.

Si te preguntas si tus pilas de TI son sólidas en materia de licencias, si cierta dependencia supone un riesgo, o cómo podría ser una estrategia de cumplimiento para tu entorno: escríbenos a contact@libcom.de. Hacemos un inventario honesto. Sin presión comercial. Con la vista en lo que dura a largo plazo.

El software libre no es la solución a todos los problemas. Pero es la única categoría de soluciones cuyas reglas siguen siendo consultables — incluso dentro de veinte años.

Aviso: Este artículo ofrece orientación general y no sustituye el asesoramiento jurídico. Las cuestiones de licencia pueden depender del caso concreto; toda la información se facilita sin garantía.