Licencias de software libre comparadas: GPL, MIT y Apache

Casi todo el software que usas a diario lleva dentro código que alguien regaló, y ese regalo viene con condiciones escritas. Que un programa sea «libre» o «de código abierto» no quiere decir que puedas hacer con él lo que te dé la gana: quiere decir que puedes hacer bastantes cosas siempre que cumplas unas condiciones concretas, y esas condiciones cambian mucho de una licencia a otra. La distancia entre la GPL y la MIT no es de matiz: es la diferencia entre estar obligado a publicar tus cambios y no estarlo.

Esta guía compara las tres licencias de software libre más extendidas —la GPL, la MIT y la Apache 2.0—, qué obliga cada una, en qué se pueden mezclar y cuál llevan proyectos que tienes instalados ahora mismo, atando cada afirmación al texto oficial de cada licencia. Es divulgación, no asesoramiento legal: si te juegas dinero o un producto en ello, consulta a un abogado.

---

Las dos familias: copyleft y permisiva

Todas las licencias libres te dan las mismas cuatro libertades de partida. La Free Software Foundation las enumera así: usar el programa para cualquier propósito, cambiarlo para adaptarlo a tus necesidades, compartirlo y compartir los cambios que hagas.

La diferencia está en qué pasa después, cuando tú distribuyes tu versión. Y ahí hay dos familias:

• Copyleft. Lo que hagas a partir de ese código tiene que salir con la misma licencia. El software está protegido por derechos de autor, pero —en palabras de la propia FSF— en lugar de usar esos derechos para restringir a los usuarios, se usan para asegurar que todos los usuarios tienen libertad. La GPL es el caso arquetípico.
• Permisiva, o «laxa». Puedes coger el código, meterlo en un producto cerrado y no devolver nada, siempre que mantengas el aviso de copyright. MIT y Apache 2.0 están aquí.

No hay una que sea «mejor»: hacen cosas distintas. El copyleft protege al usuario final; la permisiva facilita que una empresa adopte tu código sin pensárselo.

---

GPL: qué te obliga exactamente

La GNU General Public License es la licencia con copyleft por excelencia. Su idea es sencilla de enunciar: si distribuyes un programa derivado de código GPL, tienes que distribuirlo también bajo la GPL y entregar el código fuente.

Hay un punto que se malentiende constantemente, y conviene decirlo claro: la obligación se dispara al distribuir, no al usar. Puedes modificar un programa GPL y usarlo internamente en tu empresa sin publicar nada. Lo que no puedes es entregárselo a un tercero en binario y quedarte el código.

De ahí sale el temor —a menudo exagerado— al «contagio». Es real en un sentido muy concreto: si enlazas código GPL dentro de tu programa y lo distribuyes, el conjunto tiene que licenciarse bajo la GPL, según la interpretación que mantiene la FSF en sus preguntas frecuentes. Por eso existen variantes pensadas para bibliotecas, y por eso hay empresas con políticas internas que prohíben tocar código GPL en productos cerrados.

---

GPLv2 y GPLv3: qué cambió y por qué importa

No son la misma licencia, y la diferencia tiene consecuencias prácticas. La versión 3 se publicó el 29 de junio de 2007, tras año y medio de consulta pública y cuatro borradores, y la FSF la presenta como una evolución de la anterior que responde a tres amenazas nuevas.

• La tivoización. Fabricar un aparato que lleva software GPL dentro y amarrar el hardware para que el fabricante pueda cambiarlo y tú no. La GPLv3 lo corta exigiendo al distribuidor que te dé la información o los datos necesarios para instalar software modificado en el aparato: pueden ser unas instrucciones o pueden ser claves criptográficas.
• Las leyes anti-elusión. Con la GPLv3, un sistema construido con ese código no cuenta como medida tecnológica de protección efectiva, así que romper esa protección y distribuir la herramienta que lo hace no te deja expuesto a la DMCA y equivalentes.
• Las patentes. Quien distribuye software cubierto por la GPLv3 que ha escrito o modificado tiene que dar a cada receptor las licencias de patente necesarias para ejercer los derechos que la GPL concede; y si un licenciatario usa un pleito de patentes para impedir que otro los ejerza, su licencia se extingue.

La consecuencia de todo esto la verás en la práctica en qué versión usa cada proyecto. El núcleo de Linux sigue en GPLv2 —su fichero COPYING lo declara con un identificador SPDX, GPL-2.0 WITH Linux-syscall-note, y aclara que son los términos de la versión 2 solamente—, mientras que GIMP distribuye el texto de la GPL versión 3 y VLC el de la versión 2 para el reproductor, con su motor libVLC distribuido aparte bajo la LGPL.

---

MIT: la más corta, y por qué la FSF pide no llamarla así

La licencia MIT cabe en un párrafo y medio, y eso explica buena parte de su éxito. Concede permiso sin coste para usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender copias del software, con una sola condición: que el aviso de copyright y el propio texto de la licencia se incluyan en todas las copias o partes sustanciales del software. Debajo va el descargo de garantía en mayúsculas, que es la otra mitad del texto.

Eso es todo. No hay obligación de publicar cambios, no hay que documentar qué modificaste y no se menciona la palabra «patente» ni una vez. Por eso está en medio mundo: React la usa —su fichero LICENSE empieza literalmente por «MIT License» con el copyright de Meta Platforms— y Node.js distribuye ese mismo texto a nombre de sus colaboradores.

Y aquí va un detalle que casi nadie cuenta. La FSF recomienda expresamente no usar el término «licencia MIT», y da dos motivos: es engañoso, porque el MIT ha usado muchas licencias para su software, y es ambiguo, porque la misma gente llama «licencia MIT» también a la licencia X11, sin distinguirlas. El nombre que la FSF usa para esta es licencia Expat. La diferencia con la X11 es un párrafo de más sobre el uso del nombre del X Consortium: poca cosa, dice la FSF, pero una diferencia real.

---

Apache 2.0: la permisiva que además habla de patentes

La Apache 2.0 juega en la misma liga que la MIT —puedes cerrar tu derivado— pero es mucho más larga porque resuelve cosas que la MIT ni menciona.

La principal es la concesión expresa de patentes. Su sección 3 dice que cada contribuidor te concede una licencia de patente perpetua, mundial, no exclusiva, sin coste, libre de regalías e irrevocable para fabricar, usar, ofrecer en venta, vender, importar y transferir la obra. Y trae el mecanismo defensivo que la acompaña: si demandas a alguien alegando que la obra infringe tus patentes, las licencias de patente que tenías sobre esa obra se extinguen el día en que presentas la demanda.

Esa cláusula es exactamente el motivo por el que la FSF recomienda la Apache 2.0 por encima de otras licencias permisivas laxas para programas de envergadura: la califica de «buena cosa» y dice que bloquea la traición por patentes. Si publicas algo que pueda acabar en un producto grande, es la diferencia entre regalar el código y regalar el código con una tregua de patentes escrita.

Kubernetes es un ejemplo comprobable: su fichero LICENSE es el texto íntegro de la Apache License 2.0, igual que el del servidor HTTP Apache.

---

El fichero NOTICE, la parte de Apache que más se incumple

Si usas código Apache 2.0 en un producto tuyo, la sección 4 te pone cuatro condiciones, y la cuarta es la que casi nadie cumple.

• (a) Entregar a quien reciba tu obra una copia de la licencia.
• (b) Hacer que los ficheros modificados lleven avisos destacados diciendo que los has cambiado.
• (c) Conservar, en el código fuente de tu derivado, todos los avisos de copyright, patentes, marcas y atribución del original.
• (d) Si la obra incluye un fichero de texto NOTICE, tu derivado tiene que incluir una copia legible de los avisos de atribución que contiene: dentro de un NOTICE propio, dentro del código o la documentación, o en una pantalla que genere tu programa, allí donde suelan aparecer los avisos de terceros.

La propia licencia aclara que el contenido del NOTICE es solo informativo y no modifica la licencia, y que puedes añadir tus propios avisos de atribución siempre que no se puedan interpretar como una modificación de ella. Dicho de otro modo: la pantalla de «Acerca de» con la lista de componentes de terceros que ves en tanta aplicación no es una cortesía, es el punto 4(d).

---

Compatibilidad: qué se puede mezclar con qué

Aquí está la trampa que más cara sale, y la respuesta oficial es de la FSF, que mantiene una lista pública de licencias y su compatibilidad con la GPL.

• Apache 2.0 es compatible con la GPLv3, y la GPLv3 se hizo compatible con ella a propósito: la FSF lo pone como ejemplo principal de licencias nuevas que entraron en el redil con la versión 3.
• Apache 2.0 NO es compatible con la GPLv2, porque tiene requisitos que no están en esa versión de la GPL: en concreto, ciertas cláusulas de extinción de patentes e indemnización.
• La MIT o Expat sí es compatible con la GPL: es una licencia laxa, permisiva y sin copyleft, y su código se puede incorporar a un proyecto GPL.
• La GPLv2 es compatible con la GPLv3 si el programa te deja elegir «cualquier versión posterior», que es lo que ocurre con la mayoría del software publicado bajo esa licencia. Ojo con esto, porque es exactamente lo que el núcleo de Linux no hace: su licencia es la versión 2 solamente.

La regla mental que funciona es esta: el código permisivo puede entrar en un proyecto copyleft, pero no al revés. Y la combinación «Apache 2.0 con GPLv2» es un callejón sin salida, no un descuido que se arregle citando a los autores.

---

Qué licencia lleva el software que ya usas

Puesto en una fila, y comprobado en el repositorio de cada proyecto, el reparto queda así: el núcleo de Linux va con GPL versión 2 solamente; VLC, con la GPL versión 2 para el reproductor (su motor, libVLC, se distribuye aparte bajo la LGPL); GIMP, con la GPL versión 3; React y Node.js, con MIT; Kubernetes y el servidor HTTP Apache, con Apache 2.0.

Ese reparto explica cosas que se ven desde fuera. Que el mundo del escritorio y el sistema operativo sea sobre todo GPL tiene que ver con quién lo empezó y con qué quería proteger; que la infraestructura de nube y las herramientas de desarrollo sean sobre todo MIT y Apache tiene que ver con que ahí quien adopta el código son empresas que no quieren abrir su producto. Si te interesa cómo se reparte ese software una vez instalado, lo contamos en la guía sobre cómo funciona cada gestor de paquetes.

---

Cómo elegir si eres tú quien publica

Si vas a poner código tuyo en internet, la decisión se reduce a tres preguntas honestas.

• ¿Quieres que quien use tu código devuelva sus mejoras? Entonces GPL, y decide si la versión 3 —con su protección de patentes y su cláusula anti-tivoización— o la 2, que es la que sigue usando el núcleo de Linux.
• ¿Quieres la adopción más amplia posible y te da igual que alguien cierre su derivado? Entonces permisiva. Para un fragmento pequeño, MIT. Para algo de envergadura, Apache 2.0, por la concesión de patentes: es lo que recomienda la propia FSF.
• ¿Vas a mezclar código de terceros? Mira su licencia antes de escribir una línea, no después. Cambiar la licencia de un proyecto con contribuciones externas exige, en general, el permiso de quienes conservan los derechos de cada aportación —salvo que firmaran un acuerdo de cesión o de licencia de contribuciones—, y eso en la práctica significa que casi nunca se cambia.

Y dos consejos de higiene que no cuestan nada: pon el fichero de licencia en la raíz del repositorio desde el primer día, y usa el identificador SPDX en las cabeceras, como hace el núcleo de Linux. Si trabajas con Linux desde Windows, el subsistema WSL es un buen sitio para probar todo esto sin tocar tu equipo, y si prefieres un sistema que no se pueda romper mientras experimentas, mira las distribuciones inmutables.

---

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.