Licencias de software: una guía para entender permisos y obligaciones

Relato técnico. Octubre de 2026. Un mapa para leer licencias, entender integraciones y reconocer las cuestiones que requieren análisis jurídico en el caso concreto.

Encuentras una biblioteca que resuelve un problema difícil, añades la dependencia y sigues desarrollando. Meses después, el producto está listo para llegar al cliente. Entonces aparece una pregunta que debería haber acompañado la elección: ¿qué permite esta licencia y qué exige a quien entrega el software?

La respuesta depende del texto, de la versión y de lo que haces con el componente. Ejecutar una herramienta, modificar una biblioteca, entregar un instalador y ofrecer un servicio por internet son situaciones diferentes.

Esta guía recorre las principales familias de licencias, con ejemplos de dónde aparecen esas diferencias. La pregunta central es práctica: ¿qué permisos y obligaciones acompañan al software que estás construyendo?

Qué concede una licencia

Una licencia concede permisos sobre derechos que, de otro modo, permanecen reservados al titular. Puede autorizar la copia, modificación y redistribución, estableciendo condiciones para esos actos. La licencia del código tampoco resuelve por sí sola todos los derechos sobre marcas, patentes o materiales de terceros presentes en el proyecto.

La clasificación jurídica no cabe en la frase “toda licencia es un contrato”. Las condiciones de una autorización de derechos de autor y las obligaciones contractuales pueden tener consecuencias diferentes. En Jacobsen v. Katzer, en 2008, un tribunal federal de apelaciones de Estados Unidos reconoció que ciertas exigencias de la Artistic License podían funcionar como condiciones de la licencia de derechos de autor. La decisión revocó el análisis anterior y devolvió el caso al tribunal de origen; no estableció que cualquier incumplimiento de cualquier licencia produzca automáticamente la misma condena. Decisión oficial [1].

Por eso, el punto de partida es el texto aplicable al componente y a la versión recibida. Una insignia en el README ayuda a localizar la información; no sustituye la lectura de las condiciones.

Permisivas, copyleft y el significado de abierto

Las licencias permisivas conceden amplia libertad de reutilización, incluso en productos propietarios, con condiciones como conservar avisos. Las licencias copyleft añaden obligaciones de reciprocidad sobre el código cubierto. El alcance de esa reciprocidad varía: archivos, bibliotecas o una obra combinada, según la licencia y la integración.

Ambas familias permiten actividad comercial. La definición de código abierto incluye la redistribución libre y no admite prohibir el uso en determinados sectores. Un código visible con restricciones para ciertos usos puede ser source-available sin ser open source en este sentido. Open Source Definition [2].

Para quien desarrolla, la diferencia aparece en tres preguntas: ¿qué se incorporó, qué se modificó y quién recibe una copia o interactúa con la versión en ejecución?

Licencias permisivas

MIT: permisos amplios, avisos preservados

La MIT permite usar, copiar, modificar, distribuir, sublicenciar y vender el software. Exige incluir el aviso de copyright y el texto de la autorización en las copias o partes sustanciales del material. También contiene una exclusión de garantías y una limitación de responsabilidad. Texto de la MIT [3].

Ejemplo: incorporar una biblioteca MIT en una aplicación de pago puede estar permitido sin abrir el código de la aplicación. Los avisos de la biblioteca siguen acompañando la distribución; cambiar el nombre del producto no elimina esa condición.

La MIT no contiene una concesión expresa de licencia de patentes. Eso es distinto de afirmar que no podría existir ningún derecho implícito en ninguna jurisdicción. Tampoco permite concluir que la cuestión de patentes sea irrelevante solo porque el proyecto sea pequeño.

BSD: comprueba el número de cláusulas

La BSD de dos cláusulas exige conservar avisos, condiciones y exclusiones de responsabilidad. En la redistribución binaria, esa información debe aparecer en la documentación o en los materiales que acompañan la distribución. La BSD de tres cláusulas añade la restricción de usar los nombres de los titulares o contribuidores para respaldar o promover derivados sin autorización previa por escrito. BSD-2-Clause [4], BSD-3-Clause [5].

Ninguna de las dos variantes incluye una concesión expresa de patentes. Escribir solo “BSD” en el inventario pierde una información necesaria: ¿qué texto se está utilizando?

ISC: breve, con condiciones concretas

La ISC concede permisos amplios para usar, copiar, modificar y distribuir, con o sin cobro. Exige conservar los avisos de copyright y de permiso, y contiene exclusiones de garantía y responsabilidad. Es una licencia concisa, pero su texto aún debe acompañar el uso conforme a sus condiciones. Texto de la ISC [6].

Apache 2.0: patentes y redistribución más detalladas

La Apache 2.0 permite reutilizar en software propietario. En la redistribución exige proporcionar la licencia, identificar archivos modificados y conservar los avisos pertinentes. Si existe un archivo NOTICE, los avisos de atribución aplicables deben reproducirse en una de las formas permitidas por la sección 4. No es una obligación de copiar indiscriminadamente cualquier archivo con ese nombre.

La sección 3 incluye una concesión expresa de patentes de los contribuidores, limitada a las reivindicaciones licenciables necesariamente infringidas por la contribución, por separado o combinada con la obra a la que se presentó. No cubre todas las patentes de todos los contribuidores ni garantiza la ausencia de patentes de terceros.

La licencia de patentes también termina cuando el usuario inicia la acción de patentes descrita en la sección 3. La sección 6 no concede una autorización general para usar marcas. Texto de Apache 2.0 [7].

Copyleft con alcance delimitado

MPL 2.0: la frontera sigue a los archivos cubiertos

La MPL 2.0 suele describirse como copyleft a nivel de archivo. Al distribuir ejecutables que contengan software cubierto, hay que poner a disposición el código fuente correspondiente bajo MPL e informar cómo obtenerlo. Esto incluye archivos cubiertos que no hayas modificado.

Los archivos separados que no sean software cubierto pueden formar una Larger Work bajo otros términos, incluso propietarios. Los cambios conservados solo para uso privado no generan automáticamente una obligación de publicarlos. Texto de MPL 2.0 [8], FAQ de Mozilla [9].

Ejemplo: si modificas un archivo MPL y distribuyes el resultado, ese archivo sigue sujeto a MPL. La licencia no pasa automáticamente a abarcar cada archivo independiente de la aplicación.

LGPL: la biblioteca y la posibilidad de sustituirla

La LGPL permite ciertas combinaciones de bibliotecas libres con aplicaciones bajo otras licencias. En LGPLv3, la distribución de la obra combinada debe cumplir condiciones que preserven la modificación de la biblioteca y la recombinación con la aplicación. Esto incluye avisos y permisos, incluso para ingeniería inversa destinada a depurar esas modificaciones.

Una posibilidad es un mecanismo adecuado de biblioteca compartida. Otra consiste en proporcionar código objeto o material suficiente de la aplicación para permitir la recombinación, además del código correspondiente de la biblioteca. El enlace estático no obliga automáticamente a divulgar el código fuente propietario de la aplicación; el enlace dinámico no elimina automáticamente las condiciones. LGPLv3, sección 4 [10].

La versión importa: LGPLv2.1 y LGPLv3 no son textos intercambiables. El empaquetado debe examinarse junto con la licencia efectivamente recibida.

EPL y CDDL: lee las definiciones de cada licencia

La EPL 2.0 define el alcance del programa y de las obras modificadas, incluidas las distinciones para trabajos que solo se enlazan o se vinculan por nombre a las interfaces. Tiene disposiciones propias de patentes y de licencia secundaria cuando esa opción se ofreció expresamente. Resumirla como “copyleft de módulo” oculta esas condiciones. EPL 2.0 [11].

La CDDL también permite una obra mayor con código bajo otros términos, manteniendo obligaciones sobre el software cubierto. Las versiones 1.0 y 1.1 tienen cláusulas de terminación relacionadas con patentes, con diferencias que exigen comprobar el texto recibido. CDDL 1.0 [12], CDDL 1.1 [13].

GPL: distribuir una obra cubierta trae obligaciones

GPLv2

En GPLv2, distribuir una obra cubierta en forma binaria exige cumplir las condiciones de disponibilidad del código fuente correspondiente. Cuando existe una obra derivada cubierta por la licencia, la distribución del conjunto debe observar la GPL. La propia licencia distingue esto de la mera agregación de programas independientes en un mismo medio. GPLv2, secciones 2 y 3 [14].

El alcance no es “todo lo que está en el mismo ordenador”. Hay que entender la relación entre componentes, modificaciones y forma de entrega. Ejecutar un programa y desarrollar un programa derivado de él son actos distintos.

GPLv3

GPLv3 define conveying como la propagación que permite a terceros hacer o recibir copias. La mera interacción por red, sin transferencia de una copia, no entra en esa definición. Pero un servicio web también puede entregar JavaScript, WebAssembly, aplicaciones o imágenes de contenedor: cada artefacto debe examinarse.

La versión 3 incluye disposiciones expresas de patentes y, en las situaciones previstas para User Products, la información necesaria para instalar versiones modificadas. También prevé mecanismos para restablecer derechos después de una corrección. Uno de ellos consiste en corregir la primera infracción notificada por un titular determinado en un plazo de 30 días; no es un periodo de gracia universal para cualquier incumplimiento. GPLv3, secciones 0, 6, 8 y 11 [15].

¿Fuente para quién? ¿Y se puede cobrar?

Poner el código fuente a disposición conforme a GPL no significa necesariamente colocar todo en un repositorio público específico. La licencia define destinatarios y métodos de suministro u oferta. Los destinatarios, a su vez, conservan los derechos de redistribución previstos por ella. FAQ de las licencias GNU [16].

El software bajo GPL se puede vender. Puede haber ingresos por distribución, soporte y servicios. Lo que hay que evaluar es la compatibilidad entre las obligaciones y el modelo previsto, especialmente cuando se quiere restringir la redistribución o mantener propietaria una obra cubierta. FSF: vender software libre [17].

AGPL: una condición adicional para la interacción por red

La sección 13 de AGPLv3 establece una obligación específica: si modificas el programa y la versión modificada permite interacción remota por red, debes ofrecer de manera destacada a todos esos usuarios, gratuitamente por la red, el código fuente correspondiente de esa versión. AGPLv3, sección 13 [18].

“Usuarios” no significa solo clientes externos. Los empleados que interactúan remotamente con una versión modificada tampoco quedan categóricamente excluidos por el texto. Llamar interna a la instalación no resuelve la cuestión.

Ejecutar una versión sin modificaciones no activa, por ese hecho aislado, esta exigencia específica de modificación. Eso no autoriza eliminar mecanismos existentes ni elimina otras condiciones aplicables, como las de distribución de copias. Y AGPL no prohíbe ofrecer alojamiento comercial.

Ejemplo: modificas una aplicación AGPL que las personas usan desde el navegador. Hay que examinar la oferta del código fuente correspondiente a quienes interactúan con esa versión. La frase “nadie descargó el servidor” no cierra el análisis.

Cambios de licencia: la historia debe ir en la dirección correcta

En el caso de Grafana, el cambio de 2021 fue de Apache 2.0 a AGPLv3 en los proyectos centrales Grafana, Loki y Tempo. Esto no describe automáticamente todos los productos y componentes de la organización. Licenciamiento de Grafana [19].

En 2024 Elastic anunció AGPLv3 como opción adicional para las partes gratuitas del código fuente de Elasticsearch y Kibana que ya estaban disponibles bajo SSPL y Elastic License 2.0. Las distribuciones continuaron bajo Elastic License. No fue una migración integral de todos los artefactos a AGPL. FAQ de Elastic [20].

En Redis 8 y posteriores se puede elegir entre AGPLv3, SSPLv1 y RSALv2. Redis 7.2 y anteriores siguen bajo BSD-3-Clause; la franja 7.4–7.8 está bajo RSALv2 o SSPLv1. El nombre del producto por sí solo no identifica la licencia. Historial oficial de Redis [21].

Dominio público, CC0, Unlicense y 0BSD

La Unlicense combina una declaración de dedicación al dominio público con permisos amplios y una exclusión de garantías. El efecto jurídico de esa dedicación depende del derecho aplicable; el texto no contiene una concesión expresa de patentes. Texto de Unlicense [22].

CC0 intenta renunciar a los derechos de autor y conexos en la medida permitida y contiene una licencia de respaldo cuando la renuncia no produce el efecto pretendido. Excluye expresamente los derechos de marcas y patentes de su alcance. CC0 1.0, texto legal [23].

0BSD es una licencia permisiva sin condición de atribución. No depende de presentar el software como dominio público y tampoco contiene una concesión expresa de patentes. Texto de 0BSD [24].

Son instrumentos diferentes. La ausencia de una exigencia de crédito no demuestra la ausencia de todos los demás derechos posibles sobre el material.

Creative Commons: contenido y código requieren distinciones

Creative Commons recomienda licencias específicas de software para el código porque sus licencias de contenido no fueron diseñadas para tratar cuestiones como la distribución del código fuente. Pero eso no autoriza a decir que toda licencia CC sea incompatible con el software libre.

La propia organización considera CC0 aceptable para software, con sus limitaciones, y explica una compatibilidad específica y unidireccional entre CC BY-SA 4.0 y GPLv3 para ciertas adaptaciones. Esta excepción no vuelve automáticamente compatible cualquier combinación de licencias CC. FAQ oficial de Creative Commons [25].

En un mismo repositorio, el código, la documentación y las imágenes pueden tener licencias distintas. Un README bajo Creative Commons no significa necesariamente que la biblioteca también lo esté.

Source-available: poder leer no es tener todas las libertades

La SSPL de MongoDB contiene una condición de servicio más amplia que la cláusula de red de AGPL. Su sección 13 alcanza la puesta a disposición de la funcionalidad del programa como servicio a terceros y exige el Service Source Code, definido para incluir el software de gestión y operación necesario para ejecutar una instancia del servicio. No basta con equipararla a “AGPL con otro nombre”. Texto de SSPL [26].

La SSPL no está aprobada por la OSI. La propuesta de aprobación fue retirada; describir el episodio como una aprobación denegada mediante una decisión formal sería impreciso. Posición de la OSI sobre SSPL [27].

La Business Source License, abreviada con frecuencia BSL o BUSL, fue creada por MariaDB. En la versión 1.1, los permisos adicionales y el cambio futuro a otra licencia dependen de los parámetros de la obra: Additional Use Grant, Change Date y Change License. Durante la fase restringida no es una licencia open source. Elastic License 2.0 es otro instrumento. Business Source License 1.1 [28].

El identificador SPDX de esta versión es BUSL-1.1. No hay que confundirlo con BSL-1.0, que identifica la Boost Software License, una licencia open source diferente. BUSL-1.1 en SPDX [29], Boost Software License 1.0 [30].

Examinar las restricciones de producción, alojamiento y competencia forma parte de la elección. Poder descargar el código fuente no sustituye esas condiciones.

Compatibilidad: importan las versiones y la dirección

Compatibilidad significa poder cumplir simultáneamente las condiciones aplicables a la combinación pretendida. No es solo una clasificación entre licencias más ligeras y más fuertes.

La Apache Software Foundation explica que Apache 2.0 es compatible con GPLv3, permitiendo la combinación bajo GPLv3, pero no con GPLv2. Si el componente admite una versión posterior de GPL, esa opción puede cambiar el análisis. FAQ de compatibilidad de Apache [31].

El código permisivo puede participar en obras copyleft, conservando sus avisos y condiciones pertinentes. El camino inverso no es automático: recibir código GPL no concede el derecho de redistribuirlo únicamente bajo MIT. Excepciones expresas, licencias alternativas y autorización de los titulares pueden cambiar el resultado. FAQ GNU sobre combinaciones y compatibilidad [16].

También importa distinguir GPL-2.0-only de GPL-2.0-or-later. “GPL” sin versión es información insuficiente para decidir una integración.

Doble licencia y open core

En la dual licensing, el mismo código puede ofrecerse bajo licencias alternativas. Una puede ser copyleft; otra puede permitir ciertas integraciones propietarias mediante condiciones negociadas. Las garantías y el soporte dependen del acuerdo, no del nombre de la estrategia.

Quien ofrece la alternativa necesita tener derechos suficientes para hacerlo. Esto puede derivarse de la titularidad, una cesión o permisos adecuados de contribución. Un CLA es un camino posible; no es un requisito universal y no permite relicenciar derechos de terceros que nunca se concedieron. FSF: cesión de copyright y venta de excepciones [32].

En open core, el núcleo abierto convive con extensiones o funciones bajo otros términos. La arquitectura ayuda a organizar las fronteras, pero las licencias de las dependencias y la relación entre componentes siguen siendo relevantes. Separar carpetas o procesos no constituye por sí solo una conclusión jurídica sobre la independencia.

Cumplimiento en la práctica: seguir lo que sale del build

Una política útil comienza con un inventario de lo que el producto realmente contiene. Esto incluye dependencias transitivas, código copiado, binarios, fuentes tipográficas, imágenes y materiales generados o incorporados durante el build.

Un flujo operativo puede seguir esta secuencia:

1. Identificar componente, origen y versión. Registrar también las modificaciones locales y los artefactos donde aparece. 2. Guardar el texto aplicable. Comprobar la licencia de la raíz, los avisos por archivo, las excepciones y las licencias de terceros incluidas en el paquete. 3. Mapear los actos. Diferenciar ejecución, modificación, entrega de copias e interacción remota; examinar qué llega al navegador y al cliente. 4. Preparar las obligaciones antes de la entrega. Incluir avisos y, cuando se exijan, código fuente correspondiente, ofertas y materiales de recombinación o instalación. 5. Automatizar la detección de cambios. Usar escáneres y un inventario de componentes —una SBOM— para señalar dependencias nuevas y divergencias que requieren revisión. 6. Comprobar el paquete final. El inventario del repositorio y el contenido efectivamente distribuido pueden divergir.

Los escáneres ayudan a encontrar evidencias; sus resultados necesitan interpretación. Un archivo sin licencia identificada exige investigación. Publicar en un repositorio visible no equivale por sí solo a una autorización general de reutilización. GitHub: licenciamiento de repositorios [33].

SPDX: expresar la licencia sin perder condiciones

Los identificadores SPDX permiten registrar licencias de forma normalizada. Una expresión como MIT OR Apache-2.0 indica alternativas; MIT AND Apache-2.0 indica obligaciones acumulativas en el alcance representado; WITH asocia una excepción identificada a una licencia.

Una línea como SPDX-License-Identifier: MIT ayuda a herramientas y personas a reconocer la declaración. No demuestra que quien declara poseyera todos los derechos. Y aparecer en la lista SPDX no significa aprobación de la OSI: la lista también identifica licencias que no son open source. Lista SPDX [34], especificación de expresiones [35].

Un mapa rápido para volver al texto correcto

MIT, BSD e ISC — Punto principal que comprobar: Permisos amplios, con los avisos y demás condiciones de la variante recibida.

Apache 2.0 — Punto principal que comprobar: Redistribución, avisos pertinentes, archivos modificados y alcance de la concesión de patentes.

MPL 2.0 — Punto principal que comprobar: Código fuente de los archivos cubiertos en la distribución, incluidos los no modificados.

LGPL — Punto principal que comprobar: Condiciones de la biblioteca y de la obra combinada, incluida la sustitución o recombinación.

GPL — Punto principal que comprobar: Alcance de la obra cubierta, entrega de copias y suministro del código fuente correspondiente.

AGPLv3 — Punto principal que comprobar: Condiciones de GPL y oferta de código fuente en la interacción remota con la versión modificada.

Unlicense, CC0 y 0BSD — Punto principal que comprobar: Instrumentos distintos; atención a los derechos que no conceden expresamente.

SSPL y Business Source License — Punto principal que comprobar: Condiciones propias de servicio o uso; no clasificarlas automáticamente como open source.

La tabla es un índice, no un sustituto de los textos. Una etiqueta genérica de “bajo riesgo” o “alto riesgo” dice menos que una descripción concreta de la integración y de las obligaciones que se cumplirán.

La licencia acompaña las decisiones de arquitectura, distribución y negocio desde la primera dependencia. Entender esa relación permite elegir con más claridad qué reutilizar, qué compartir y cómo sostener el producto sin borrar los derechos de quienes construyeron sus partes.