Juan A. Esteban

Artista contemporáneo e investigador independiente.

Ilustración del monograma rúnico de Juan Esteban renderizado en estilo arquitectónico tridimensional dentro de un marco, sobre fondo claro.

Licencias de código y obra artística: qué cubre cada una

Una obra hecha con código puede reunir programa, bibliotecas, tipografías, imágenes, datos, documentación y resultados. Un único archivo LICENSE no convierte esas capas en una sola obra ni resuelve todos sus permisos.

Esta guía explica cómo separarlas antes de compartir, vender o entregar el proyecto. No decide la compatibilidad de una combinación concreta: hay que revisar versiones, arquitectura, forma de distribución y textos completos. Si además quieres preparar el paquete técnico, consulta Cómo preparar código creativo para que vuelva a ejecutarse.

Qué protege la ley como programa

Los artículos 95 a 104 de la Ley de Propiedad Intelectual forman el régimen específico de los programas de ordenador. El artículo 96 define el programa como toda secuencia de instrucciones o indicaciones destinadas a utilizarse en un sistema informático e incluye su documentación preparatoria; exige originalidad, protege cualquier forma de expresión, las versiones sucesivas y los programas derivados, y excluye de la protección de derechos de autor las ideas y principios en que se basan sus elementos, incluidos los de sus interfaces.

El artículo 97 trata la titularidad: cuando una persona empleada crea el programa en el ejercicio de sus funciones o siguiendo instrucciones de la empresa, los derechos de explotación corresponden a esta, salvo pacto en contrario. El artículo 99 regula los derechos de reproducción, transformación y distribución, y presume que la licencia de uso de un programa es no exclusiva e intransferible. El artículo 100 fija límites para el usuario legítimo, como la copia de seguridad, la observación y prueba del funcionamiento y la interoperabilidad. No traslades al software sin más las reglas de una imagen o un texto.

Seis capas distintas

  1. Código propio. Aclara autoría y titularidad, especialmente con colaboradores, encargos o relación laboral.
  2. Dependencias. Conservan su licencia aunque estén dentro de tu repositorio.
  3. Recursos. Tipografías, imágenes, sonido, vídeo, modelos y datos pueden tener permisos distintos.
  4. Interfaz. La expresión concreta, como iconos, textos y diseño, puede protegerse aparte; las ideas y principios en que se basa, no.
  5. Documentación. Manuales y fichas pueden usar una licencia de contenidos.
  6. Salida artística. No queda automáticamente bajo la licencia del programa que la genera.

MIT

La licencia MIT concede permiso, sin coste, para usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender copias del software. Exige incluir el aviso de copyright y el aviso de permiso en todas las copias o partes sustanciales, y excluye toda garantía.

Es permisiva, pero no borra licencias de dependencias ni concede derechos sobre marcas, datos o materiales no cubiertos.

Apache 2.0

Apache 2.0 distingue forma fuente y forma objeto, define las obras derivadas y exige, al redistribuir, entregar una copia de la licencia, indicar de forma visible los archivos modificados, conservar los avisos de copyright, patente, marca y atribución y, si existe un archivo NOTICE, incluir sus avisos. Incluye una concesión expresa de licencia de patentes dentro de sus términos y prevé su terminación si quien la recibe demanda por infracción de patente. No la resumas como «MIT con patentes». La compatibilidad con otras licencias depende de versiones concretas.

GPL: vender está permitido

La GPL es una licencia con copyleft. Las preguntas frecuentes de GNU indican que la GPL permite vender copias y cobrar cualquier precio. Cuando se distribuye código objeto o un ejecutable, deben cumplirse las condiciones de la versión aplicable para facilitar el código fuente correspondiente; una oferta escrita es una de las vías previstas en determinados supuestos, no una regla única para toda distribución.

No toda utilización de una biblioteca produce el mismo resultado. Las preguntas frecuentes de GNU, que expresan la interpretación de la propia organización sobre sus licencias y no una sentencia ni una regla legal universal para cualquier arquitectura, sostienen que el enlace estático o dinámico con código GPL puede producir una combinación sujeta a la GPL, con una excepción para determinadas bibliotecas del sistema. Según esas mismas respuestas, la LGPL y la AGPL tienen reglas diferentes: la LGPL es más flexible en el enlace dinámico y la AGPL añade obligaciones cuando se ofrece el software a través de una red. No las confundas con la GPL.

Sobre las salidas, GNU sostiene que, por regla general, la salida de un programa no queda cubierta por el copyright del programa, y que la situación puede cambiar si la salida incorpora partes protegidas del propio programa, como pantallas completas de texto o gráficos o audio. Vender una imagen generada con un programa GPL no convierte, por tanto, necesariamente la imagen en software GPL, pero conviene comprobar qué materiales del programa se incorporan a la salida. Entregar el programa, un ejecutable o una combinación sí puede activar obligaciones.

Creative Commons no es la licencia recomendada para código

Creative Commons recomienda no usar sus licencias para software. Según sus preguntas frecuentes, no contienen términos específicos sobre distribución de código fuente, no tratan los derechos de patente que muchas licencias de software sí abordan y no son compatibles con las principales licencias de software.

Las licencias Creative Commons sí pueden aplicarse a documentación, a materiales artísticos separados, como imágenes o música, y a otros contenidos. Indica qué archivos cubre cada licencia:

  • carpeta del código: Apache-2.0;
  • carpeta de materiales artísticos: CC BY 4.0;
  • carpeta de documentación: CC BY 4.0;
  • tipografías: remite a un archivo THIRD_PARTY_LICENSES;
  • salidas: condiciones propias.

Es un ejemplo de separación, no una combinación recomendada para todos los proyectos.

Creative Commons señala que CC0 puede aplicarse a software, aunque recomienda estudiar su implementación y las cuestiones de patentes, garantías y derechos que no puedan renunciarse en cada jurisdicción. Su FAQ específica, cuya última edición es de 2016, precisa que CC0 no concede licencia sobre patentes y que no había sido aprobada por la Open Source Initiative. CC0 no es una licencia de software equivalente a MIT, Apache o GPL: es una herramienta de dedicación al dominio público y renuncia de derechos, en la medida en que la ley lo permita.

Código abierto no significa sin condiciones

Según las preguntas frecuentes de la Open Source Initiative, todo el software de código abierto puede usarse con fines comerciales, y las licencias abiertas no pueden discriminar por campos de aplicación ni limitar el uso del programa. Pueden, en cambio, imponer condiciones como reconocer a los autores o, en las licencias con copyleft, ofrecer el código fuente y mantener la misma licencia en las versiones modificadas que se distribuyan. «Comercial» no equivale a «propietario».

Compatibilidad

Registra para cada componente:

  • licencia y versión exactas;
  • identificador SPDX;
  • titular y aviso;
  • forma de combinación;
  • modificaciones;
  • distribución prevista;
  • fuente que debe facilitarse;
  • restricciones, patentes y marcas.

No deduzcas compatibilidad porque dos licencias admitan uso comercial. «GPL» y «licencia abierta» son descripciones insuficientes.

Vender una obra que usa código abierto

Puedes vender una obra realizada con software abierto. Lo decisivo es qué entregas:

  • una imagen puede no distribuir el programa;
  • un ejecutable puede exigir avisos o fuente;
  • el código arrastra licencias propias y de dependencias;
  • una obra servida por red puede activar condiciones específicas, como las de la AGPL;
  • los recursos ajenos requieren permiso de redistribución.

Separa en el contrato obra, soporte, copia de exhibición, programa y licencia.

Licencia de las salidas

Si quieres permitir exhibición, reproducción o transformación de resultados, identifícalos en una licencia o cláusula propia. Consulta cómo autorizar la reproducción.

No concedas una licencia abierta sobre materiales cuyos derechos no controlas. Una licencia solo transmite los permisos disponibles.

Créditos y expediente

Mantén LICENSE, THIRD_PARTY_LICENSES, NOTICE, AUTHORS, cambios, licencias de recursos y condiciones de salidas. MIT exige incluir el aviso de copyright y de permiso en las copias, y Apache 2.0 exige entregar una copia de la licencia: un enlace que puede cambiar no cumple por sí solo esas obligaciones (interpretación).

La licencia concede permisos; no sustituye la prueba de autoría ni el registro de una obra. Si publicas el repositorio, revisa además la reserva frente a minería de datos.

Lista de comprobación

  • Código, dependencias, recursos, documentación y salidas están separados.
  • Consta licencia y versión exacta de cada elemento.
  • Se ha comprobado la titularidad del código propio.
  • La distribución prevista cumple las dependencias.
  • Avisos, licencia, cambios y NOTICE están conservados.
  • Se revisó la combinación, no solo cada paquete aislado.
  • La venta no se confunde con cesión de derechos.
  • Se distingue fuente, ejecutable y salida.
  • Recursos artísticos tienen permisos propios.
  • Secretos, credenciales y datos personales no se publican.
  • La compatibilidad crítica recibió revisión especializada.

Para seguir

Fuentes

Estado: Verificada. Revisión: 11 de octubre de 2026. Información general, no análisis jurídico de una combinación concreta. Si encuentras un error, escríbeme.

Descubre más desde Juan A. Esteban

Suscríbete y recibe las últimas entradas en tu correo electrónico.

Español English (UK)