¿Qué es la GPL? La licencia pública general de GNU explicada
Comprende las libertades de la GPL, el copyleft y las obligaciones sobre el código fuente, con ejemplos de uso comercial, distribución y software de WordPress.
GPL significa General Public License, o licencia pública general. En el ámbito del software, suele referirse a la GNU General Public License: una licencia de software libre que permite ejecutar, estudiar, modificar y compartir un programa. Su característica principal es el copyleft. Cuando distribuyes una obra cubierta, debes conservar las libertades que la licencia concede a sus destinatarios y cumplir sus requisitos sobre el código fuente.
La licencia GPL permite el uso comercial y la distribución de pago. No exige publicar en internet todos los cambios privados ni proporciona automáticamente una suscripción de soporte o una cuenta en la nube del desarrollador. Estas diferencias importan tanto al instalar un plugin de WordPress como al crear una aplicación o compartir un programa modificado.
Qué significa la licencia GPL para tu copia
La GNU GPL la publica la Free Software Foundation. GNU identifica el proyecto del que procede la licencia; GPL es el nombre de la propia licencia. Las expresiones inglesas «GPL license» y «GPL licence» se refieren al mismo concepto, con dos variantes ortográficas. Las condiciones concretas dependen de la versión y del aviso de licencia que acompaña al software.
La palabra libre describe libertades, sin garantizar un precio de cero. Alguien puede cobrar por un programa cubierto por la GPL. Una vez que recibes una copia bajo esta licencia, pagar por ella no elimina los derechos que te concede. GNU explica esta diferencia en su definición de software libre.
Esos derechos hacen posibles varias actividades habituales:
- Ejecutar el software: usarlo para tus propios fines, incluido el trabajo empresarial.
- Estudiarlo: examinar el código fuente para comprender cómo funciona.
- Modificarlo: adaptar el código a tus necesidades.
- Compartirlo: redistribuir las copias permitidas, incluidas las versiones modificadas, siguiendo las condiciones de la GPL aplicable.
Por ejemplo, una pequeña empresa puede usar una aplicación GPL para gestionar sus registros internos. Un desarrollador puede cambiar una función para ajustarla a otro proceso de trabajo. Un distribuidor puede ofrecer copias junto con ayuda para instalarlas. La licencia permite estas actividades, pero las obligaciones varían según lo que se comparte.
Por eso, leer la licencia resulta más útil que preguntar únicamente si un programa es «gratis». Comprueba qué cubre el aviso, qué versión de la GPL se aplica y si otros componentes tienen condiciones independientes.
El copyleft conserva los permisos cuando se comparte el software
El código cubierto por la GPL sigue protegido por derechos de autor. Sus autores utilizan una licencia para conceder permisos con condiciones. Por tanto, el software GPL es distinto del software que pertenece al dominio público.
El copyleft significa que un distribuidor no puede tomar una obra derivada cubierta y negar a sus destinatarios las libertades GPL asociadas a ella. Protege la capacidad de la siguiente persona para trabajar con el programa, en lugar de reservar ese permiso para el primer destinatario. La explicación de GNU sobre el copyleft describe este mecanismo.
Imagina este ejemplo: mejoras la visualización de zonas horarias de una aplicación de planificación bajo GPL. Puedes utilizar tu copia modificada de forma privada. Si distribuyes esa aplicación modificada cubierta, debes cumplir los requisitos de la GPL correspondientes a la obra distribuida. Un aviso como «puedes usarla, pero nunca redistribuirla» entraría en conflicto con los derechos que sus destinatarios deben recibir.
Eso no significa que todos los archivos sin relación que hay en tu ordenador pasen a estar cubiertos por la GPL. Para determinar si un código forma una obra derivada o combinada cubierta hay que examinar su relación con el programa GPL. Compartir un dispositivo de almacenamiento o un servidor con otra aplicación no resuelve por sí solo esa cuestión. La integración de bibliotecas y los productos combinados requieren analizar la arquitectura real antes de tomar decisiones sobre las licencias.
Usar software y distribuir software son acciones diferentes
La pregunta más útil es: ¿estás dando a alguien una copia del software cubierto? Cobrar dinero es una cuestión aparte.
La GPLv3 usa el término inglés convey, que aquí explicamos como «transmitir», para referirse a las actividades que permiten a otras personas hacer o recibir copias. Lo distingue expresamente de interactuar mediante una red sin transferir una copia. La GPLv2 emplea el lenguaje de la distribución. Las secciones 0–2 del texto de la GPLv3 establecen estas definiciones y los permisos básicos.
| Ejemplo de acción | Qué conviene examinar |
|---|---|
| Ejecutar un programa GPL para una actividad empresarial | El uso comercial está permitido; ejecutarlo no exige, por sí mismo, publicar el código fuente. |
| Modificar una copia y conservarla de forma privada | Los cambios privados no tienen que publicarse en internet simplemente porque existan. |
| Entregar a un cliente un programa cubierto o una versión modificada | Se aplican las obligaciones de distribución, incluidos los avisos, la licencia y los requisitos relativos al código fuente. |
| Vender copias de un programa cubierto | Se permite cobrar; los destinatarios conservan los derechos de la GPL aplicable. |
| Dejar que los visitantes utilicen software GPL del servidor mediante una web | La interacción por red no constituye por sí sola una transmisión bajo GPLv3; comprueba si también se entrega código cubierto. |
Un instalador, un archivo descargable o un conjunto de código que se ejecuta en el dispositivo del usuario pueden cambiar el análisis, porque este puede recibir software. Del mismo modo, entregar un paquete modificado a una organización independiente es distinto de conservarlo en tu propio ordenador. La tabla ofrece una orientación; no resuelve todas las situaciones posibles con contratistas, grupos empresariales o modalidades de despliegue.
¿La GPL exige que tu código fuente sea público?
No impone una obligación universal de subir todos los cambios a un repositorio público. Si distribuyes software cubierto, debes cumplir las reglas de acceso al código fuente de la versión aplicable y del método de distribución que utilices.
Hay un matiz importante: algunas vías permitidas basadas en una oferta escrita alcanzan a otras personas además del comprador directo. Por ejemplo, la sección 3(b) de la GPLv2 describe una oferta de proporcionar el código fuente a cualquier tercero. Por tanto, afirmar que «el código fuente solo se entrega a tus clientes» también resulta demasiado general. Lee la vía que estés utilizando en la sección 3 del texto de la GPLv2.
Para un distribuidor, una pregunta práctica más precisa es: ¿puede la persona con derecho al código fuente correspondiente obtener realmente el código correcto de esta copia? Una referencia vaga al proyecto original aporta menos claridad que un mecanismo de entrega concreto que coincida con la versión distribuida.
¿Qué es el código fuente correspondiente?
El código fuente es la forma que los desarrolladores utilizan para modificar la obra. Bajo GPLv3, el código fuente correspondiente incluye el material necesario para generar, instalar, ejecutar y modificar el código objeto cubierto, con las exclusiones definidas en la licencia.
Imagina un distribuidor que cambia la lógica de procesamiento de una aplicación y envía una versión compilada a sus clientes. Entregar únicamente el código fuente original del proyecto dejaría fuera el cambio que ellos han recibido. La entrega del código fuente debe corresponder a esa versión compilada e incluir el material de compilación pertinente. Este ejemplo trata de la coherencia entre una copia distribuida y su código fuente; las opciones exactas de entrega siguen dependiendo de la licencia aplicable.
También importa conservar el texto de la licencia y los avisos pertinentes. Una carpeta de código fuente legible no sustituye esos requisitos. Gestiona conjuntamente el código fuente, los avisos y el método de distribución al preparar una versión.
GPLv2 y GPLv3: lee el aviso antes de elegir
GPLv2 y GPLv3 son versiones diferentes de la GNU GPL. GPLv2 se publicó en 1991 y GPLv3 en 2007. Ambas son licencias copyleft, pero su redacción y sus requisitos no son intercambiables. Una licencia más reciente no sustituye automáticamente a la que acompaña a un programa existente.
GPLv3 incluye disposiciones explícitas sobre patentes, disposiciones de compatibilidad revisadas y requisitos de información de instalación en determinadas circunstancias relativas a los «productos de usuario» o User Products. Estos cambios abordan situaciones que van más allá de descargar código fuente. La guía rápida de GNU sobre GPLv3 los explica.
Es especialmente fácil generalizar en exceso los requisitos de información de instalación. GPLv3 no obliga a todos los vendedores de software a entregar todas sus contraseñas operativas. Su sección 6 aborda el código objeto cubierto transmitido dentro de, junto con, o específicamente para utilizarse en determinados User Products, bajo condiciones y excepciones concretas. Esta diferencia es relevante para productos que, de otro modo, podrían impedir que un destinatario instalara una versión modificada.
Para la mayoría de los lectores, el primer paso es más sencillo: encontrar el aviso de licencia del programa.
- Solo GPLv2: el permiso se limita a esa versión, salvo que exista otro permiso aplicable.
- GPLv2 o posterior: el aviso permite elegir GPLv2 o una versión posterior publicada por la FSF.
- Solo GPLv3: el programa tiene licencia GPLv3, sin una opción general para versiones posteriores.
El código bajo GPLv2 únicamente y el código bajo GPLv3 no son automáticamente compatibles para una obra combinada. Un aviso GPLv2 o posterior puede permitir utilizar GPLv3. La lista de compatibilidad de licencias de GNU explica esta diferencia.
No deduzcas «o posterior» de un título web que solo diga GPL. Si el paquete contiene varias dependencias, revisa también sus avisos. El permiso de un componente para usar una versión posterior no reescribe la licencia de todas las dependencias.
GPL, LGPL, AGPL y MIT responden a necesidades distintas
Estos nombres describen regímenes de licencia diferentes. Conocer sus diferencias básicas ayuda a encontrar el texto adecuado sin tratar todas las licencias de código abierto como equivalentes.
| Licencia | Diferencia principal | Pregunta útil |
|---|---|---|
| GNU GPL | Copyleft fuerte para las obras cubiertas que se distribuyen | ¿Distribuimos un programa cubierto o una obra combinada? |
| GNU LGPL | Permisos adicionales permiten ciertas combinaciones con aplicaciones que tienen otras licencias, bajo condiciones | ¿Pueden los usuarios sustituir el componente LGPL o volver a enlazarlo cuando se exige? |
| GNU AGPL | Añade, en las circunstancias correspondientes, un requisito de ofrecer el código fuente a quienes interactúan a distancia con una versión modificada | ¿Hemos modificado software AGPL que otras personas utilizan mediante una red? |
| MIT | Licencia permisiva con requisitos de conservación de avisos, sin copyleft de tipo GPL | ¿Hemos conservado los avisos de derechos de autor y de permiso exigidos? |
La Lesser General Public License, o licencia pública general reducida, se utiliza a menudo para bibliotecas. No permite ignorar sus condiciones de licencia. Por ejemplo, la sección 4 de LGPLv3 incluye condiciones relativas a las obras combinadas, los avisos y la capacidad del usuario para trabajar con una biblioteca modificada.
La Affero General Public License aborda de forma más directa la interacción a distancia. La sección 13 de AGPLv3 exige que una versión modificada ofrezca de forma destacada el código fuente correspondiente a los usuarios que interactúan con ella a distancia mediante una red informática. GPLv3 ordinaria no crea esa misma obligación por el simple hecho de que un programa funcione en un servidor.
La licencia MIT permite una reutilización amplia y exige conservar sus avisos de derechos de autor y de permiso. Por lo general, el código bajo MIT puede incorporarse a un proyecto cubierto por la GPL si se mantienen esas condiciones. Eso no convierte el código ya cubierto por GPL en código MIT ni elimina las obligaciones GPL de la obra combinada.
No hay una licencia universalmente mejor entre ellas. Para un autor, la elección refleja cómo quiere que funcione el intercambio posterior. Para quien utiliza un proyecto existente, los permisos disponibles parten de la licencia que realmente han concedido los titulares de los derechos.
Cuándo puede limitar la GPL un proyecto
La principal limitación surge cuando las condiciones de distribución que quieres imponer entran en conflicto con el copyleft. Si pretendes entregar código ejecutable de una obra combinada cubierta y, al mismo tiempo, prohibir a sus destinatarios que la redistribuyan o accedan a su código fuente correspondiente, la GPL puede ser incompatible con ese plan de distribución. Preparar el código fuente y comprobar la compatibilidad de las dependencias también requiere tiempo en el proceso de entrega.
La decisión práctica consiste en preservar las libertades de los destinatarios o mantener determinadas restricciones de distribución. No impide construir un negocio alrededor del software. Valora esa decisión antes de incorporar un componente GPL a un producto que vayas a entregar, para evitar descubrir compromisos contradictorios cuando llegue el momento de distribuirlo.
Qué significa la GPL para WordPress, sus plugins y sus temas
WordPress indica que su software se publica bajo GPLv2 o posterior. Su página oficial sobre la licencia también explica la postura del proyecto: los plugins y los temas son obras derivadas. A la vez, reconoce las zonas de incertidumbre jurídica en torno a qué constituye una obra derivada.
Por eso la GPL aparece con tanta frecuencia en las conversaciones sobre extensiones de WordPress. Permite compartir el software cubierto siguiendo sus condiciones, incluso mediante distribución comercial. Sin embargo, el nombre de un producto o la etiqueta de un proveedor no te cuenta todo sobre un paquete concreto.
Al examinar un plugin, separa tres elementos:
- La licencia de derechos de autor: ¿qué permisos se aplican al código cubierto?
- El paquete entregado: ¿qué archivos y recursos con licencias independientes incluye realmente?
- Los servicios: ¿quién proporciona las descargas, las actualizaciones, el soporte y las funciones alojadas, si existen?
Una clave de cuenta del desarrollador puede controlar el acceso a un servicio o a un canal de actualizaciones. Esa cuestión es distinta del permiso de derechos de autor asociado al código que has recibido. La GPL no promete por sí misma una cuenta del proveedor, un servicio remoto de pago ni soporte futuro.
Los requisitos de los directorios de WordPress también tienen su propio ámbito. Las normas del directorio de plugins exigen que el código, los datos y las imágenes enviados utilicen licencias compatibles con la GPL. Es una regla del directorio; no demuestra que todos los archivos descargables de otros sitios tengan idéntico contenido o los mismos derechos.
Si tu pregunta práctica es qué incluye una descarga de WordPress procedente de un tercero, consulta la guía de paquetes de plugins de WordPress bajo GPL. Profundiza en la elección del paquete y de los servicios. Esta explicación general se centra en la licencia, en lugar de comparar vendedores o plugins individuales.
Cuatro ejemplos para entender mejor los límites
Las siguientes situaciones son ejemplos. Muestran qué hecho cambia la pregunta; no son informes de pruebas de productos.
Una tienda utiliza internamente una aplicación GPL
Una tienda instala una herramienta de inventario GPL y la utiliza para controlar sus existencias. Cobra a sus clientes por productos físicos. Esa actividad comercial no distribuye por sí misma la aplicación de inventario. La acción relevante respecto al software es ejecutar el programa, algo que la GPL permite con fines comerciales.
La tienda debería conservar un registro de lo que ha instalado y de su licencia. Si más adelante entrega la aplicación a otra organización, esa nueva acción requiere revisar las obligaciones de distribución.
Un desarrollador entrega una aplicación modificada a un cliente
Un desarrollador cambia el formato de los informes de una aplicación GPL y entrega la aplicación modificada a un cliente. El cliente recibe una copia del software, por lo que deben cumplirse los requisitos de distribución aplicables. Cobrar por el trabajo de desarrollo no los elimina.
Antes de la entrega, el desarrollador debe identificar los cambios cubiertos, conservar los avisos necesarios y organizar el acceso al código fuente correspondiente. Un contrato puede describir el trabajo y el soporte, pero no debería prometer restricciones que contradigan los derechos GPL transmitidos al cliente.
Una web utiliza software GPL en el servidor
Una empresa modifica un programa GPLv3 para realizar cálculos en su servidor. Los visitantes envían datos y reciben resultados sin recibir una copia de ese programa. La interacción por red no constituye por sí sola una transmisión bajo GPLv3.
Ahora cambia un hecho: la web envía código cubierto a los dispositivos de los visitantes. Vuelve a plantearse la cuestión de la distribución. Cambia otro hecho: el programa del servidor está bajo AGPLv3 y la empresa lo ha modificado. La disposición de AGPL sobre el código fuente para los usuarios de la red pasa a ser relevante. Por tanto, decir «es una web» no basta para identificar las obligaciones aplicables.
Una diseñadora crea contenido con una herramienta GPL
Una diseñadora utiliza una aplicación gráfica GPL para crear una ilustración original. Que la aplicación sea GPL no convierte automáticamente la ilustración en GPL. Importa el contenido del resultado: GPLv3 solo cubre la salida cuando esa salida constituye en sí misma una obra cubierta.
La diseñadora debe comprobar por separado las fuentes tipográficas, las plantillas y los recursos utilizados en la ilustración. La licencia de la herramienta de edición y los permisos de esos elementos son hechos diferentes. GNU explica este principio en su FAQ sobre los resultados de los programas.
Cómo usar la GPL para tu propio software
No obtienes la GPL comprando una clave especial de activación. Si tienes los permisos de derechos de autor necesarios, puedes publicar tu propio software bajo ella. La guía de GNU para aplicar sus licencias describe el proceso.
Empieza por identificar el código cuyos derechos controlas. Un proyecto puede incluir contribuciones, trabajo que pertenece a un empleador, dependencias y recursos con distintos derechos. Elegir GPL para tus archivos originales no te da permiso para cambiar la licencia del material de otras personas.
Después, elige la versión de la licencia y decide si el aviso permitirá versiones posteriores. Incluye el texto completo de la licencia y los avisos adecuados con el código fuente. Haz visible la elección en la documentación del proyecto y prepara el mecanismo de entrega de código fuente que corresponda a tu distribución antes de suministrar versiones compiladas.
Para una pequeña utilidad escrita por completo por un solo autor, el trabajo práctico puede ser sencillo: añadir un archivo de licencia, aplicar los avisos adecuados y publicar el código fuente con instrucciones claras de compilación. Un proyecto mayor con dependencias necesita una revisión componente por componente. Copiar una etiqueta GPL en un README no basta si el contenido del paquete cuenta otra historia.
Respuestas breves a otras preguntas sobre la GPL
¿Puedes vender software con licencia GPL?
Sí. La GPL permite distribuir el software cubierto a cambio de un pago si se cumplen sus condiciones. Los compradores reciben los derechos de la GPL aplicable, incluido el derecho a redistribuirlo. La guía de GNU sobre la venta de software libre explica por qué cobrar y conservar las libertades pueden coexistir.
¿GPL es lo mismo que código abierto?
GPL es una licencia de código abierto, pero el código abierto incluye otras licencias con condiciones distintas. Una licencia permisiva como MIT y una licencia copyleft como GPL permiten colaborar a partir del código fuente, aunque fijan reglas diferentes para su distribución posterior.
¿La GPL te da derecho a utilizar la marca de un proyecto?
Los permisos de derechos de autor sobre el software no resuelven automáticamente los derechos de marca. Redistribuir código no autoriza necesariamente a afirmar que el desarrollador original respalda tu versión. WordPress, por ejemplo, tiene una política independiente sobre marcas.
¿Una etiqueta GPL demuestra que una descarga es segura?
No. Las condiciones de licencia describen permisos y obligaciones. No establecen el origen, la integridad ni el mantenimiento de un archivo concreto. Son comprobaciones distintas, tanto si el software es GPL como si tiene una licencia permisiva o propietaria.
Empieza por la copia y por lo que quieres hacer
Para aplicar esta explicación a un proyecto real, registra el aviso de licencia del software, identifica lo que pretendes hacer y determina si alguien recibe código cubierto. Después, comprueba las condiciones de esa versión y de ese método de distribución.
Para una compra de WordPress, añade una comprobación independiente del paquete y de los servicios que necesitas. Para una entrega de desarrollo, revisa las dependencias y el código fuente correspondiente. Esos hechos concretos te dirán mucho más que la palabra GPL por sí sola.