GPL, MIT y Apache: diferencias y requisitos

GPL frente a MIT frente a Apache: qué exige cada licencia

GPL, MIT y Apache 2.0 responden de formas distintas a la misma pregunta: ¿qué debe a otras personas cuando redistribuye el software? MIT exige incluir un aviso de copyright y nada más. Apache 2.0 exige ese aviso y también un acuerdo sobre patentes con todas las personas que contribuyen al código. GPL exige publicar el código fuente de lo que haya creado sobre esa base, con la misma licencia que recibió.

Parece una cuestión para abogados hasta el día en que un proyecto que administra cambia de licencia y se divide en dos. Entonces se convierte en una cuestión operativa. Tiene que elegir entre dos repositorios de paquetes y enfrentarse a bibliotecas cliente que dejan de comunicarse entre sí. Esta guía trata sobre las licencias y su funcionamiento, no sobre el movimiento que las originó. Por eso, cada sección termina en el punto que le afecta: la persona responsable de ejecutar la actualización.

Por qué existe la GPL: una impresora que nadie podía reparar

Alrededor de 1980, el Laboratorio de Inteligencia Artificial del MIT recibió una impresora láser Xerox 9700. El laboratorio había modificado el software de una impresora anterior para que avisara cuando un trabajo se atascaba. Para la nueva, no había código fuente disponible y la solicitud de acceso fue rechazada debido a un acuerdo de confidencialidad. Richard Stallman, programador del laboratorio en aquel entonces, interpretó esa negativa como la norma general y no como un caso aislado, por lo que anunció el proyecto GNU el 27 de septiembre de 1983.

El copyleft se construye a partir de la ley de derechos de autor, no en su contra. Por defecto, usted no tiene derecho alguno a copiar el código de otra persona. La GPL concede ese derecho bajo una condición: si entrega el programa a alguien más, debe entregarle también el código fuente, bajo los mismos términos, para que esa persona pueda hacer lo que el laboratorio no pudo. La condición es ejecutable porque, sin la licencia, usted no tendría permiso alguno desde el principio.

Stallman escribió una licencia primero para GNU Emacs y luego la generalizó en la GPL versión 1 el 25 de febrero de 1989. La GPL versión 2 le siguió en junio de 1991, y sigue siendo la licencia de la mayor parte del software de sistema que usted ejecuta. La Lesser GPL surgió para las bibliotecas, de modo que una biblioteca con copyleft pudiera ser enlazada por un programa bajo cualquier licencia sin obligar a dicho programa a adoptar la GPL.

Un detalle determina cómo afecta la GPL a quien aloja sus propios servicios. La obligación se activa con la distribución, no con el uso. Usted puede modificar un programa bajo GPL, ejecutarlo en su propio servidor y ofrecer servicios al público con él sin deber nada a nadie, porque nunca ha entregado una copia. Ese vacío es la razón por la que existe la AGPL.

La tradición permisiva: BSD y después MIT

Berkeley siguió una ruta diferente. El Computer Systems Research Group publicó su trabajo sobre Unix con una licencia que exigía conservar el aviso de copyright y rechazaba cualquier garantía. La versión original tenía cuatro cláusulas. La tercera, conocida como cláusula de publicidad, exigía reconocer a la universidad en todo material publicitario que mencionara funciones del software. Ese requisito no escala. Stallman contó 75 reconocimientos distintos en una versión de NetBSD de 1997. UC Berkeley retiró la cláusula el 22 de julio de 1999, mediante una carta de William Hoskins, de su Office of Technology Licensing.

Lo que queda es la licencia BSD de 3 cláusulas, que conserva la prohibición original de usar los nombres de los colaboradores para respaldar un producto, y la versión de 2 cláusulas, que elimina incluso esa prohibición. El texto de la licencia MIT surgió en MIT en la década de 1980, cuando cubría X Window System, y en la práctica cumple la misma función que BSD de 2 cláusulas.

Los motivos eran diferentes. Una universidad financiada con dinero público quería que su trabajo se utilizara en todas partes, también por empresas. El proyecto GNU quería un fondo común que no pudiera cerrarse. Ambas posiciones son legítimas y ambas tienen un modo de fallo. El código permisivo puede convertirse en código propietario y no se recibe nada a cambio. Las empresas rechazan el código copyleft cuando sus abogados no aceptan esa condición.

Berkeley ofrece una segunda lección, que es a la que este artículo vuelve continuamente. AT&T's Unix System Laboratories demandó a Berkeley Software Design en 1992 por el código de BSD, y el caso se resolvió a principios de 1994. Durante dos años nadie podía tener la certeza de que fuera seguro desarrollar sobre BSD, y su adopción se estancó mientras Linux crecía. La incertidumbre jurídica frena la adopción más rápido que la falta de una función.

Por qué Apache 2.0 añadió una concesión de patentes

La primera licencia de The Apache Group era un derivado de la BSD de 4 cláusulas que presentaba el mismo problema con la publicidad. La versión 1.1, en el año 2000, eliminó dicha cláusula. La versión 2.0, publicada en enero de 2004, fue una reescritura en lugar de un parche.

La adición importante son las patentes. Las licencias MIT y BSD no dicen nada al respecto. Un colaborador puede otorgarle un permiso de derechos de autor claro para su código y, aun así, poseer una patente que cubra lo que hace ese código, para luego demandar a quienes lo utilizan. Apache 2.0 cierra ese vacío: cada colaborador otorga una licencia de patente que cubre su contribución, y cualquiera que demande alegando que el trabajo infringe sus patentes pierde su propia licencia sobre el mismo. La amenaza es mutua, por lo que, en la práctica, nadie dispara.

El resto de la versión 2.0 es administrativo, y es por eso que a las empresas les gusta. Existe un archivo NOTICE definido, por lo que la atribución tiene un lugar único en lugar de estar dispersa por todo el árbol de directorios. La licencia puede aplicarse mediante referencia en lugar de pegarse en cada archivo fuente. Las contribuciones están cubiertas por términos explícitos. Las marcas registradas están excluidas. Una revisión legal de una dependencia bajo Apache 2.0 encuentra que cada pregunta que se quería plantear ya está respondida en el texto, por lo que la aprobación se vuelve rutinaria, que es la mayor parte de lo que significa "estándar corporativo".

Qué cambió la GPLv3 y por qué Linux se mantuvo en la GPLv2

TiVo distribuyó un grabador de vídeo que ejecutaba Linux y publicó el código fuente del kernel, exactamente como exige la GPLv2. El hardware comprobaba una firma criptográfica durante el arranque y rechazaba ejecutar cualquier kernel que no reconociera. Se podía leer el código fuente, modificarlo y compilarlo. Sin embargo, no se podía ejecutar en el dispositivo original. Se cumplía la letra de la licencia, pero se anulaba su propósito; esta práctica recibió el nombre de tivoización.

La versión 3 de la GPL, publicada el 29 de junio de 2007, responde directamente a esto. Cuando se distribuye un binario dentro de un dispositivo de consumo, también se debe proporcionar la "Información de instalación": las claves o instrucciones necesarias para instalar una versión modificada y lograr que se ejecute. La versión 3 también añadió una concesión de patentes explícita, términos redactados en respuesta al acuerdo de patentes entre Microsoft y Novell de noviembre de 2006, y compatibilidad unidireccional con Apache 2.0.

Linux no siguió este camino. El kernel es exclusivamente GPL versión 2, sin la cláusula de escape "o cualquier versión posterior", y su archivo COPYING así lo indica. Linus Torvalds se opuso públicamente a los términos anti-tivoización para hardware firmado. La barrera práctica es mayor que el desacuerdo: el kernel tiene miles de titulares de derechos de autor, por lo que nadie podría recopilar los permisos necesarios para un cambio de licencia, incluso si todos lo quisieran. Ese simple hecho es la protección más fuerte que puede tener un proyecto, y vale la pena recordarlo al analizar un proyecto propiedad de una sola empresa.

La otra licencia de 2007 es más relevante para usted. La GNU Affero GPL versión 3, publicada en noviembre de ese mismo año, extiende la obligación de publicar el código fuente a quienes interactúan con el programa a través de una red. Si ejecuta un servicio AGPL modificado para el público, debe proporcionar el código fuente a esos usuarios. Por eso gran parte del software web autohospedado es AGPL. Nextcloud es un ejemplo, y si está comparando las alternativas autohospedadas a Nextcloud, la línea de licencia en el repositorio de cada candidato le dice más sobre sus próximos cinco años que su lista de funciones.

¿Qué licencias se pueden combinar realmente?

La compatibilidad funciona en una sola dirección, desde las permisivas hacia las copyleft.

• El código MIT y BSD puede incluirse en cualquier proyecto, incluso en un producto cerrado.
• El código Apache 2.0 puede incluirse en un proyecto GPLv3, y el trabajo resultante es GPLv3.
• El código Apache 2.0 no puede incluirse en un proyecto exclusivamente GPLv2. Sus cláusulas de terminación de patentes e indemnización son condiciones adicionales que la GPLv2 no permite añadir. Tanto la FSF como la ASF publican esta conclusión.
• Usted no puede cambiar el código GPL a una licencia permisiva. Solo los titulares de los derechos de autor pueden hacerlo, lo que le devuelve a la pregunta de quiénes son.

La era de las relicencias: SSPL, BUSL y lo que no son

El detonante fue comercial. Una empresa posee los derechos de autor de un producto, un proveedor de nube lo ofrece como servicio gestionado a gran escala y aporta muy poco a cambio, y la empresa cambia la licencia para impedirlo. Redis Labs dio el primer paso visible en agosto de 2018 al añadir la Commons Clause sobre Apache 2.0 para varios de sus módulos. MongoDB la siguió el 16 October 2018 al pasar de AGPLv3 a Server Side Public License.

La SSPL es la AGPL con una sección reescrita. Si ofrece el programa a terceros como servicio, debe publicar el código fuente de todo lo que utiliza para ofrecerlo, incluido el software de gestión y orquestación que lo rodea. Esa obligación no tiene un límite claro y ningún tribunal la ha puesto a prueba. La OSI nunca aprobó la licencia, y MongoDB retiró su solicitud en March 2019. Debian ya había indicado en December 2018 que el software SSPL no debía estar en su archivo, y Fedora dictaminó en January 2019 que la licencia no es libre. Después, Red Hat retiró MongoDB de Fedora y de Red Hat Enterprise Linux. Ese es el resultado mecánico de una relicencia: la distribución deja de empaquetar el software, por lo que sus actualizaciones pasan a proceder de un repositorio del proveedor y según el calendario del proveedor.

La Business Source License es un mecanismo diferente. Procede de los fundadores de MariaDB, y la versión 1.1 data de 2017. No es copyleft ni es open source. El código fuente es público y el uso que no sea de producción es gratuito. El uso en producción sólo está permitido hasta el alcance que autorice la Additional Use Grant del proveedor, y esa concesión normalmente impide ejecutar un servicio alojado que compita con él. Cada versión se convierte automáticamente en una licencia open source real en una fecha de cambio que no puede ser posterior a cuatro años después de esa versión. La licencia de conversión debe ser la GPL version 2.0 o una versión posterior, o una licencia compatible con una de ellas. HashiCorp pasó Terraform y sus demás productos a BUSL 1.1 el 10 August 2023. Outline también la utiliza, algo que conviene saber si está eligiendo entre las alternativas autoalojadas a Notion: se permite ejecutarlo para su propio equipo, pero no crear un servicio basado en él.

Ninguna de las dos licencias es deshonesta. Ambas indican claramente que el código está disponible. Ninguna es open source según la definición de la OSI, y la diferencia le afecta a usted, no al proveedor de nube al que iba dirigida.

OpenSearch: cuánto cuesta al operador un cambio de licencia

Elastic anunció el 14 de enero de 2021 que Elasticsearch y Kibana dejarían Apache 2.0 para adoptar SSPL o Elastic License, a partir de la versión 7.11. La versión 7.10.2 fue la última publicada bajo Apache 2.0. Aproximadamente una semana después, AWS anunció que crearía y mantendría un fork de ambos proyectos bajo Apache 2.0. El fork recibió el nombre OpenSearch el 12 de abril de 2021, y Kibana pasó a llamarse OpenSearch Dashboards. OpenSearch 1.0 estuvo disponible de forma general el 12 de julio de 2021, creado a partir de Elasticsearch 7.10.2 y Kibana 7.10.2.

Hay que observar cuánto costó esto a las personas que administraban los clústeres. Cambiaron los nombres de los paquetes y los repositorios. Cada referencia a Kibana en un runbook pasó a ser OpenSearch Dashboards. También cambiaron los nombres de los plugins. Después, la separación llegó al código de las aplicaciones: desde la versión 7.13 de las bibliotecas cliente oficiales de Elastic, el cliente comprueba a qué se ha conectado y se niega a continuar si no es Elasticsearch. En ese caso indica que el servidor es un producto desconocido. Una decisión de licencia tomada por una empresa para la que no trabaja se convirtió en una llamada fallida dentro de su propia aplicación.

Después, la situación cambió dos veces más. Elastic anunció el 29 de agosto de 2024 que añadiría AGPLv3 como tercera opción de licencia, y su FAQ de licencias sitúa la incorporación en septiembre de 2024. Por tanto, Elasticsearch vuelve a ser actualmente software de código abierto aprobado por la OSI. El 16 de septiembre de 2024, AWS transfirió OpenSearch a la OpenSearch Software Foundation, alojada por la Linux Foundation. Esto proporcionó al fork una estructura de gobierno que no depende de una sola empresa. Cinco años después de la separación, ambos proyectos son de código abierto, ambos se mantienen y OpenSearch está en su serie 3.x en octubre de 2026.

La conclusión es la lección. La licencia volvió a cambiar, pero el fork permaneció. Cuando un ecosistema tiene dos versiones de cada componente, corregir la documentación legal no vuelve a fusionarlas.

La cifra que determina cuánto daño causa un cambio de licencia es el intervalo entre el anuncio y un fork estable que realmente se pueda desplegar.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Cada intervalo se cuenta desde el anuncio público del proveedor hasta la primera versión estable del fork, usando las fechas indicadas a continuación. OpenSearch 1.0 tardó 179 días, porque hubo que cambiar el nombre del fork y reconstruirlo sin disponer de un fork anterior como referencia. OpenTofu tardó 153 días. Valkey tardó 27 días, porque se separó de Redis 7.2.4 y mantuvo idénticos el protocolo y el formato en disco. La tendencia es lo importante: ahora un fork fiable aparece en cuestión de semanas, con una fundación y mantenedores remunerados desde el primer día.

Valkey y OpenTofu: el mismo patrón, más rápido

Redis Ltd cambió Redis de la licencia BSD de 3 cláusulas a una elección entre RSALv2 o SSPLv1 el 20 de marzo de 2024. Ocho días después, la Linux Foundation anunció Valkey, un fork de Redis 7.2.4 que mantiene la licencia BSD de 3 cláusulas. Valkey 7.2.5 se lanzó el 16 de abril de 2024 con el mismo protocolo y los mismos archivos de datos, por lo que para la mayoría de los operadores la migración consistió únicamente en cambiar el nombre del paquete. Posteriormente, Redis añadió AGPLv3 como una tercera opción en Redis 8 en mayo de 2025, lo que lo convierte de nuevo en código abierto según la definición de la OSI, mientras que Valkey continúa bajo su propia gobernanza. La estructura se asemeja mucho a la de Elasticsearch.

Terraform siguió el mismo camino con un capítulo adicional. OpenTofu realizó un fork de la última versión bajo licencia Mozilla Public License 2.0, se unió a la Linux Foundation en septiembre de 2023 y lanzó la versión 1.6.0 el 10 de enero de 2024. El 3 de abril de 2024, los abogados de HashiCorp enviaron al proyecto una carta de cese y desistimiento alegando que se había copiado código de una versión de Terraform bajo licencia BUSL en el fork. OpenTofu publicó una respuesta detallada el 11 de abril de 2024 negándolo y rastreó el código en disputa hasta el historial bajo licencia MPL que ambos proyectos comparten. No hubo más consecuencias públicas. El riesgo real en ese episodio es el que se debe recordar: una simple acusación puede congelar la adopción durante un trimestre, el mismo efecto que tuvo la demanda de Berkeley treinta años antes.

No todos los forks comienzan por una licencia. Forgejo realizó un fork de Gitea en 2022 después de que el desarrollo de Gitea pasara a estar bajo una empresa, lo cual fue una disputa de gobernanza más que de licencias. Forgejo mantuvo la licencia MIT durante su serie de versiones 8, y luego cambió a GPLv3 o posterior a partir de la versión 9.0 en 2024, para evitar que su trabajo pudiera ser absorbido por un producto controlado comercialmente. Si está evaluando las opciones de servidores Git autohospedados, ese par es el ejemplo vivo más claro de una misma base de código y dos filosofías distintas.

La prueba que debe ejecutar antes de adoptar cualquier solución

Cuatro preguntas, antes de la primera instalación y no después.

1. ¿Quién posee los derechos de autor? El cambio de licencia requiere el permiso de cada titular de los derechos de autor, por lo que un proyecto con cientos de colaboradores independientes y sin una cesión de derechos no puede cambiar de licencia de forma realista. Un proyecto donde una sola empresa posee todo puede cambiar de licencia en una reunión de la junta directiva.
2. ¿Existe un CLA y qué otorga? Un acuerdo de licencia de colaborador (CLA) que permite a la empresa volver a licenciar su contribución bajo cualquier término que desee es el mecanismo exacto detrás de cada cambio de licencia mencionado anteriormente. Un DCO (certificado de origen del desarrollador), la línea de firma que el kernel de Linux adoptó en 2004, no transfiere ningún derecho. Un CLA en manos de una fundación es más seguro que uno en manos de una empresa, porque una empresa puede ser vendida.
3. ¿Quién posee la marca registrada? Elastic mantuvo el nombre Elasticsearch, por lo que el fork tuvo que cambiar su propio nombre y cada manual de procedimientos que mencionaba Kibana tuvo que ser reescrito.
4. ¿Qué le costaría a usted en particular un cambio de licencia? Cuente el formato de datos, las bibliotecas cliente, la configuración que tendría que reescribir y si ya existe un fork compatible.

Dos comandos responden a parte de esto en segundos.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Cada paquete de Debian y Ubuntu incluye un archivo en /usr/share/doc/<package>/copyright, el cual registra la licencia de la versión que usted instaló, no la licencia que el proyecto utiliza hoy. Para bash en Ubuntu 24.04, ese archivo nombra la GNU General Public License version 3. Ejecute el segundo comando dentro de una descarga del código fuente y obtendrá el historial del archivo de licencia en sí. Vale la pena leer cualquier commit realizado en los últimos dos años antes de construir algo sobre el proyecto. Si el comando no imprime nada, el repositorio nombra su archivo de licencia de otra manera, así que liste el directorio raíz y busque.

Ninguna licencia le protege de todos los resultados, y elegir por ideología es la forma en que la gente termina sorprendida. Prefiera proyectos cuyos derechos de autor estén repartidos entre muchas manos o en manos de una fundación, y mantenga sus datos en un formato que pueda exportar. Luego, averigüe a qué fork se mudaría y anote el nombre antes de necesitarlo. Aplicar esta comprobación a cada candidato cuesta menos de una hora, y es lo que separa una actualización de una migración cuando está decidiendo qué alojar usted mismo en 2026.

FAQ

¿Es la licencia MIT igual que la licencia BSD?

En la práctica, la licencia MIT equivale a la licencia BSD de 2 cláusulas: mantenga el aviso de copyright y la exención de responsabilidad, y haga lo que desee, incluido crear un producto cerrado. La licencia BSD de 3 cláusulas añade una restricción: prohíbe utilizar los nombres de los colaboradores para promocionar su producto sin permiso. La versión antigua de 4 cláusulas también exigía un reconocimiento en el material publicitario; la Universidad de California en Berkeley retiró esa cláusula el 22 de julio de 1999, por lo que casi ningún software actual la incluye.

¿Puedo incluir código con licencia Apache 2.0 en un proyecto GPLv2?

No. La licencia Apache 2.0 añade condiciones que la GPLv2 no permite, principalmente la cláusula de terminación de patentes, por lo que una obra combinada no puede cumplir ambas licencias simultáneamente. Tanto la FSF como la ASF publican esta conclusión. En sentido contrario sí es posible: el código Apache 2.0 puede incluirse en un proyecto GPLv3, y el resultado es GPLv3. Esta es la razón por la cual el código Apache 2.0 no puede integrarse en el kernel de Linux, que utiliza exclusivamente la versión 2 de la GPL.

¿Es la SSPL una licencia de código abierto?

No, y esta respuesta tiene consecuencias prácticas. La OSI nunca la aprobó y MongoDB retiró su solicitud en marzo de 2019. Debian declaró en diciembre de 2018 que el software bajo SSPL no debía formar parte de su archivo, y Fedora dictaminó en enero de 2019 que la licencia no es libre; tras esto, Red Hat eliminó MongoDB de Fedora y de Red Hat Enterprise Linux. Para usted, esto significa que un paquete que su distribución solía mantener ahora proviene de un repositorio del proveedor, sujeto al calendario de soporte de dicho proveedor. La Business Source License también es de código disponible (source available) en lugar de código abierto, aunque cada versión se convierte a una licencia de código abierto en un plazo de cuatro años.

¿Un cambio de licencia afecta a la versión que ya estoy ejecutando?

No. Una licencia concedida con una versión no puede retirarse de las copias ya publicadas, que es precisamente la razón por la cual los forks son posibles. OpenSearch se creó a partir de Elasticsearch 7.10.2, la última versión que Elastic publicó bajo Apache 2.0. Lo que usted pierde es el futuro, ya que el siguiente parche de seguridad llegará bajo los nuevos términos. Fijar la última versión con licencia permisiva le otorga unos meses de margen, pero no es una estrategia a largo plazo.