La GNU General Public License (GPL) es la licencia copyleft más conocida. Permite usar, estudiar, modificar y distribuir el software, también con fines comerciales, con una condición central: quien distribuye el programa, original o modificado, debe entregarlo bajo la misma licencia y con su código fuente. Así, el software sigue siendo libre en cada copia que circula.
El copyleft en una frase
El copyright normal restringe lo que otros pueden hacer con una obra. El copyleft usa ese mismo derecho de autor para lo contrario: garantizar que nadie pueda quitarle las libertades al software en el camino. Puedes hacer casi todo con un programa GPL, salvo distribuirlo de una forma que le niegue esas libertades a quien lo recibe. El concepto, con sus variantes fuerte y débil, está explicado en qué es el copyleft.
La licencia la escribió Richard Stallman para el proyecto GNU. La versión 1 es de 1989, la versión 2 de junio de 1991 y la versión 3 del 29 de junio de 2007. Hoy conviven la v2 y la v3.
Qué exige la GPL
Las obligaciones se activan al distribuir el programa (la v3 usa el término “transmitir”, convey). Si distribuyes software GPL, original o modificado, tienes que:
- Entregar el código fuente completo y correspondiente, o una oferta válida de entregarlo.
- Mantener la misma licencia para el programa y para las obras derivadas que distribuyas.
- Conservar los avisos de copyright y de licencia.
- No agregar restricciones adicionales a las libertades que la licencia concede.
Qué no exige
Aquí están los malentendidos más comunes:
- No prohíbe cobrar. Puedes vender software GPL. Lo que no puedes es impedir que quien lo compró lo redistribuya.
- No obliga a publicar cambios de uso interno. Si modificas un programa GPL y lo usas solo dentro de tu empresa, sin entregarlo a terceros, no tienes que liberar nada.
- No cubre el uso como servicio. Si ejecutas software GPL en tu servidor y la gente lo usa por internet, no lo estás distribuyendo. Ese vacío es el que cierra la AGPL.
- No contamina lo que el programa produce. Un documento escrito en un editor GPL o un archivo compilado con GCC no quedan bajo la GPL.
GPL v2 y GPL v3: las diferencias que importan
| Tema | GPL v2 | GPL v3 |
|---|---|---|
| Patentes | Solo una cláusula implícita | Licencia explícita de patentes de cada contribuyente |
| Dispositivos cerrados (“tivoización”) | No lo aborda | Exige entregar la información para instalar versiones modificadas en productos de consumo |
| Compatibilidad con Apache 2.0 | No compatible | Compatible |
| Incumplimiento | La licencia termina de inmediato | Hay un plazo para corregir y recuperar los derechos |
| Gestión digital de derechos (DRM) | No lo aborda | Limita usar leyes anti-elusión contra los usuarios |
La palabra “tivoización” viene de TiVo, un grabador de video que usaba Linux y cumplía la GPL v2 entregando el código, pero solo aceptaba ejecutar software firmado por el fabricante. Los usuarios tenían el código pero no podían usar su versión modificada en el aparato. La v3 lo prohíbe para productos de consumo.
“Solo v2” o “v2 o posterior”
Cada proyecto decide si acepta versiones futuras de la licencia:
GPL-2.0-only: solo la v2. Es el caso del núcleo Linux, y por eso Linux nunca pasó a la v3.GPL-2.0-or-later: la v2 o cualquier versión posterior, a elección de quien recibe el código.GPL-3.0-onlyyGPL-3.0-or-later: lo mismo para la v3.
La diferencia es práctica. Un proyecto “v2 o posterior” puede combinarse con código v3; uno “solo v2”, no.
El tema del enlazado
La pregunta más debatida es si un programa que enlaza una biblioteca GPL pasa a ser una obra derivada y debe ser GPL. La posición de la Free Software Foundation es que sí, tanto con enlazado estático como dinámico. Otros juristas sostienen que depende del caso. Lo que sí es claro: si quieres que tu biblioteca se pueda usar desde software cerrado sin discusión, la opción es la LGPL, no la GPL.
Dos programas independientes que solo conviven en el mismo disco o se comunican por mecanismos normales (una línea de comandos, un socket, una API HTTP) se consideran, en general, “simple agregación”, y la GPL de uno no alcanza al otro.
Cuándo elegir la GPL
- Quieres que todas las versiones distribuidas de tu programa sigan siendo libres.
- Te preocupa que una empresa tome tu trabajo, lo mejore y lo cierre.
- El programa es una aplicación completa más que una biblioteca.
Si lo que quieres es la máxima adopción, una licencia permisiva como MIT o Apache 2.0 encaja mejor. Para usar código GPL dentro de un producto que vendes, revisa esta guía.
Preguntas frecuentes
¿Se puede vender software con licencia GPL? Sí. La GPL permite cobrar por el software, siempre que entregues el código fuente y no impidas que quien lo compra lo redistribuya.
¿La GPL obliga a publicar el código si solo uso el programa en mi empresa? No. Las obligaciones de la GPL se activan al distribuir el programa a terceros, así que las modificaciones de uso interno no tienen que publicarse.
¿Qué diferencia hay entre la GPL y la LGPL? La LGPL es una variante pensada para bibliotecas: permite enlazarlas desde software cerrado sin discusión, algo que con la GPL es debatido. Por eso es la opción si quieres que tu biblioteca se use en programas propietarios.
¿Linux usa la GPL v3? No. El núcleo Linux usa la GPL v2 en su variante “solo v2”, por eso nunca pasó a la v3.
¿La GPL v3 es compatible con la licencia Apache 2.0? Sí. La GPL v3 es compatible con Apache 2.0, mientras que la GPL v2 no lo es. Los detalles de esa licencia están en licencia Apache 2.0.
Fuentes
- GNU General Public License v3 y v2, Free Software Foundation.
- Preguntas frecuentes sobre las licencias GNU, en español.
- Guía rápida de la GPLv3, Free Software Foundation.
- Identificadores SPDX de la GPL, SPDX License List.