Diferencias entre licencias GPL, MIT y Apache 2.0

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

GPL, MIT y Apache 2.0 responden a la misma pregunta de formas distintas: ¿qué debe a los demás cuando distribuye el software? MIT solicita un aviso de copyright y nada más. Apache 2.0 solicita ese aviso además de un acuerdo de patentes entre todos los que modifican el código. La GPL le exige publicar el código fuente de lo que ha construido sobre la base, bajo la misma licencia que recibió.

Esto parece una cuestión para abogados hasta el día en que un proyecto que usted ejecuta cambia su licencia y se divide en dos. Entonces se convierte en una cuestión de operaciones. Usted tiene dos repositorios de paquetes entre los que elegir y bibliotecas cliente que dejan de comunicarse entre sí. Esta guía trata sobre las licencias y su mecánica, no sobre el movimiento que las produjo, por lo que cada sección termina donde le afecta a usted: la persona que debe 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, luego MIT

Berkeley tomó un camino diferente. El Computer Systems Research Group publicó su trabajo sobre Unix bajo una licencia que solicitaba mantener el aviso de copyright y declinaba toda garantía. La versión original tenía cuatro cláusulas; la cuarta, la cláusula de publicidad, requería un reconocimiento a la Universidad en todo material publicitario que mencionara características del software. Eso no es escalable. 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 añade la prohibición de usar los nombres de los colaboradores para promocionar su producto, y la versión de 2 cláusulas, que elimina incluso esa restricción. El texto de la licencia MIT surgió del MIT en la década de 1980, donde cubría el X Window System, y en la práctica realiza la misma función que la licencia BSD de 2 cláusulas.

Los motivos fueron distintos. Una universidad financiada con dinero público quería que su trabajo se utilizara en todas partes, incluso por empresas. El proyecto GNU quería un bien común que no pudiera ser cerrado. Ambas posturas son honestas y ambas tienen un modo de fallo. El código permisivo puede privatizarse y usted no recibe nada a cambio. El código copyleft es rechazado por empresas cuyos abogados no aceptan la condición.

Hay una segunda lección de Berkeley, y es a la que este artículo vuelve constantemente. AT&T's Unix System Laboratories demandó a Berkeley Software Design en 1992 por el código BSD, y el caso se resolvió a principios de 1994. Durante dos años, nadie pudo estar seguro de que fuera seguro desarrollar sobre BSD, y la adopción se estancó mientras Linux crecía. La incertidumbre legal detiene la adopción más rápido que la falta de una funcionalidad.

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 del cambio de licencia: 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 vende como servicio gestionado a gran escala y aporta poco a cambio, por lo que la empresa cambia la licencia para evitarlo. Redis Labs realizó el primer movimiento visible en agosto de 2018 al añadir la Commons Clause sobre Apache 2.0 en varios de sus módulos. MongoDB le siguió el 16 de octubre de 2018 al pasar de AGPLv3 a la 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 utilice 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 marzo de 2019. Debian ya había declarado en diciembre de 2018 que el software bajo SSPL no tenía cabida en su archivo, y Fedora dictaminó en enero de 2019 que la licencia no es libre, tras lo cual Red Hat eliminó MongoDB de Fedora y de Red Hat Enterprise Linux. Ese es el resultado mecánico de un cambio de licencia: la distribución deja de empaquetar el software, por lo que sus actualizaciones ahora provienen de un repositorio del proveedor y bajo el calendario del proveedor.

La Business Source License es un mecanismo diferente. Proviene de los fundadores de MariaDB y la versión 1.1 data de 2017. No es copyleft y no es código abierto. El código fuente es público, su uso es gratuito excepto para el uso que el proveedor excluye, que normalmente es ejecutar un servicio de alojamiento competidor, y cada versión se convierte automáticamente en una licencia de código abierto real en una fecha de cambio no superior a cuatro años tras dicha versión. La licencia a la que se convierte debe ser compatible con GPLv2. HashiCorp trasladó Terraform y sus otros productos a BUSL 1.1 el 10 de agosto de 2023. Outline también la utiliza, lo cual es útil saber si está eligiendo entre las alternativas a Notion autohospedadas: ejecutarlo para su propio equipo está permitido, pero construir un servicio sobre él no.

Ninguna de las dos licencias es deshonesta. Ambas declaran claramente que son de código disponible (source available). Ninguna es código abierto según la definición de la OSI, y la diferencia recae sobre usted en lugar de sobre el proveedor de nube al que iba dirigida.

OpenSearch: lo que cuesta al operador una bifurcación por licencia

Elastic anunció el 14 de enero de 2021 que Elasticsearch y Kibana abandonarían la licencia Apache 2.0 por una elección entre la SSPL o la Elastic License, a partir de la versión 7.11. La versión 7.10.2 fue la última bajo Apache 2.0. Aproximadamente una semana después, AWS declaró que crearía y mantendría una bifurcación (fork) de ambos bajo Apache 2.0. La bifurcación recibió el nombre de 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, construido a partir de Elasticsearch 7.10.2 y Kibana 7.10.2.

Observe lo que esto supuso para quienes gestionan clústeres. Los nombres de los paquetes y los repositorios cambiaron. Cada referencia a Kibana en los manuales de procedimientos pasó a ser OpenSearch Dashboards. Los nombres de los complementos se movieron. Luego, la división llegó al código de la aplicación: a partir de 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, informando que el servidor es un producto desconocido. Una decisión de licencia en una empresa para la que usted no trabaja se convirtió en una llamada fallida dentro de su propia aplicación.

La historia dio dos giros más. Elastic añadió AGPLv3 como tercera opción de licencia el 29 de agosto de 2024, por lo que el Elasticsearch actual vuelve a ser 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, lo que otorgó a la bifurcación un marco de gobernanza que no depende de una sola empresa. Cinco años después de la división, ambos proyectos son de código abierto, ambos reciben mantenimiento y OpenSearch se encuentra en su serie 3.x a fecha de agosto de 2026.

El final es la lección. La licencia volvió y la bifurcación se quedó. Una vez que un ecosistema tiene dos de cada cosa, deshacer el papeleo no los vuelve a fusionar.

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

[
  {
    "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 de la bifurcación, utilizando las fechas que figuran a continuación. OpenSearch 1.0 tardó 179 días, porque la bifurcación tuvo que ser renombrada y reconstruida sin una bifurcación previa que copiar. OpenTofu tardó 153 días. Valkey tardó 27 días, porque bifurcó Redis 7.2.4 y mantuvo idénticos el protocolo y el formato en disco. La dirección es la parte útil: una bifurcación creíble llega ahora en semanas, con una fundación y mantenedores pagados 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.