Software de código abierto y licenciamiento
Resumen
El software de código abierto es aquel cuyo código fuente puede estudiarse, modificarse y redistribuirse bajo una licencia que concede esas libertades. No significa "sin licencia", "gratis" ni "sin obligaciones": cada licencia define qué se permite, qué debe conservarse y qué ocurre al distribuir una versión modificada.
Esta guía explica los criterios de la Open Source Initiative, la diferencia entre licencias permisivas y copyleft, las obligaciones prácticas, los identificadores SPDX y la gestión de cumplimiento. El objetivo es reconocer riesgos, no sustituir el asesoramiento legal.
Material educativo independiente. No está afiliado, patrocinado ni respaldado por The Linux Foundation. LFCA es una marca de sus respectivos titulares. Esta guía no constituye asesoramiento jurídico.
Objetivos de aprendizaje
- Explicar los criterios de la definición de código abierto.
- Diferenciar licencias permisivas, copyleft fuerte y copyleft débil.
- Reconocer obligaciones de atribución, aviso y distribución de código fuente.
- Interpretar identificadores SPDX y su papel en un SBOM.
- Aplicar comprobaciones básicas de compatibilidad y cumplimiento.
Prerrequisitos y conexiones
Conviene comprender qué es un proyecto, quién es el titular de los derechos y cómo se distribuye el software. El licenciamiento conecta con la gestión de proyectos por el gobierno de dependencias, la evaluación de riesgos y el control de cambios. También se relaciona con seguridad: una dependencia sin mantenimiento es un riesgo técnico y legal.
Qué es software de código abierto
La Open Source Initiative (OSI) mantiene la Definición de Código Abierto. Una licencia se considera de código abierto si cumple, entre otros, estos criterios:
- Redistribución libre: el software puede venderse o regalarse sin regalías.
- Código fuente y obras derivadas: el fuente debe estar disponible y se permite modificarlo y distribuirlo.
- Integridad del autor: puede exigirse que las versiones modificadas usen otro nombre.
- Sin discriminación ni restricción de uso: no se excluye a personas, grupos ni campos de actividad.
- Distribución de la licencia: los derechos se aplican a todos los destinatarios.
- No específica de un producto, no restrictiva de otro software y neutralidad tecnológica: no se imponen condiciones a programas acompañantes ni una tecnología concreta.
Estos criterios distinguen el código abierto del freeware (gratuito pero sin código fuente) y del dominio público (sin derechos vigentes o con renuncia expresa). Un proyecto puede ser de código abierto y cobrar por soporte o alojamiento; la libertad se refiere al código, no al precio.
Las cuatro libertades
La Free Software Foundation formula cuatro libertades que ayudan a interpretar el propósito del código abierto: ejecutar el programa con cualquier propósito, estudiar cómo funciona y adaptarlo, redistribuir copias y mejorar la versión pública para beneficio de la comunidad. El acceso al código fuente es condición para las libertades segunda y cuarta, porque sin fuente no hay estudio ni mejora posible.
Estas libertades se refieren a lo que la licencia permite, no a lo que el proveedor garantiza. Un producto puede incluir software libre y aun así cobrar por la distribución, el soporte o el alojamiento. También puede restringir el acceso a su servicio sin dejar de respetar la licencia del componente que utiliza, salvo que esa licencia imponga obligaciones adicionales al ofrecerlo por red.
Licencia, contrato y derechos
Una licencia es una autorización condicionada para ejercer derechos que, en principio, corresponden al titular. Sin licencia, el derecho de autor impide copiar y distribuir; con licencia, se conceden permisos a cambio de cumplir condiciones. Por eso el incumplimiento no es una simple falta de cortesía: puede convertir un uso autorizado en una infracción.
Conviene distinguir tres capas: el derecho de autor sobre el código, las patentes que pudieran afectar a su funcionamiento y las marcas que identifican el proyecto. Una licencia de código no concede automáticamente derechos sobre el nombre o el logotipo, y una concesión de patentes puede tener condiciones y cláusulas de terminación propias.
Licencias permisivas y copyleft
Las licencias se suelen agrupar en dos familias:
- Permisivas: permiten usar, modificar y redistribuir con pocas condiciones, normalmente atribución y aviso de licencia. Ejemplos: MIT, BSD de 2 o 3 cláusulas y Apache 2.0.
- Copyleft: exigen que las obras derivadas se distribuyan bajo la misma licencia o una compatible, para preservar las libertades. El copyleft fuerte alcanza al conjunto combinado (GPL); el débil se limita a archivos o bibliotecas modificadas (MPL, LGPL).
| Licencia | Familia | Obligación principal | Concesión de patentes |
|---|---|---|---|
| MIT | Permisiva | Conservar copyright y aviso de licencia | No explícita |
| BSD 2/3 cláusulas | Permisiva | Conservar copyright y aviso; la variante 3 añade no endoso | No explícita |
| Apache 2.0 | Permisiva | Conservar avisos, incluir licencia y declarar cambios | Sí, explícita |
| MPL 2.0 | Copyleft débil | Publicar el código de los archivos modificados cubiertos | Sí, explícita |
| GPLv3 | Copyleft fuerte | Distribuir el código fuente correspondiente bajo GPLv3 | Sí, explícita |
| AGPLv3 | Copyleft fuerte | Como GPLv3, también al ofrecer el servicio por red | Sí, explícita |
La tabla es orientativa; los términos exactos están en el texto de cada licencia.
Permisivas
MIT exige incluir el aviso de copyright y el permiso en copias o partes sustanciales. No impone copyleft ni concede patentes de forma explícita. BSD es similar; la variante de 3 cláusulas prohíbe usar el nombre de los contribuyentes para promocionar derivados sin permiso.
Apache 2.0 añade una concesión expresa de patentes, una cláusula de terminación si se demanda por infracción y requisitos de aviso. Si se modifica un archivo, conviene conservar avisos y declarar los cambios.
Copyleft
La GPLv3 concede las libertades habituales, pero exige que quien distribuya un programa basado en ella ponga a disposición el código fuente bajo la misma licencia. También aborda patentes y medidas de protección tecnológica. La AGPLv3 extiende la obligación al servicio de red: si los usuarios interactúan con una versión modificada, debe ofrecerse el código.
La MPL 2.0 es copyleft a nivel de archivo: los archivos cubiertos modificados deben publicarse bajo MPL, pero pueden combinarse con archivos de otra licencia. La LGPL se usa en bibliotecas y permite enlazar con software propietario bajo condiciones específicas.
Anatomía de una licencia
| Elemento | Qué define | Ejemplo de pregunta |
|---|---|---|
| Concesión | Derechos otorgados y su alcance | ¿Permite modificar y redistribuir? |
| Condiciones | Obligaciones para mantener la autorización | ¿Exige conservar avisos o publicar fuente? |
| Patentes | Concesión expresa o silencio | ¿Protege frente a demandas de contribuyentes? |
| Terminación | Cuándo cesa la autorización | ¿Se revoca si se demanda por patentes? |
| Garantía | Nivel de responsabilidad del autor | ¿Se ofrece el software tal cual? |
| Ley aplicable | Marco interpretativo | ¿Qué jurisdicción resuelve disputas? |
Leer la concesión antes que el resumen evita sorpresas. Dos licencias de la misma familia pueden diferir en patentes, en terminación o en el tratamiento de avisos, y esas diferencias pesan más que la etiqueta general. Un texto permisivo con una cláusula atípica puede ser más restrictivo que un copyleft conocido.
Obligaciones prácticas
Al distribuir software de terceros, conviene comprobar:
- Atribución y avisos: conservar copyright, autores, textos de licencia y NOTICE cuando corresponda.
- Cambios: declarar modificaciones en licencias como Apache 2.0 o MPL.
- Código fuente: entregar o poner a disposición el código cuando la licencia lo requiera (GPL, AGPL, MPL para archivos cubiertos).
- Compatibilidad y patentes: revisar concesiones, cláusulas de terminación y combinaciones.
- Garantía: asumir que la mayoría de licencias se ofrece tal cual, sin garantía.
La obligación suele activarse con la distribución. El uso interno dentro de una organización normalmente no constituye distribución, aunque hay matices según la licencia y la jurisdicción. La AGPL es una excepción relevante para servicios ofrecidos por red. Ante dudas, se consulta con asesoría legal.
Ejemplo de aviso SPDX
Un archivo puede declarar su licencia con un identificador SPDX:
// SPDX-FileCopyrightText: 2026 Ejemplo S.A.
// SPDX-License-Identifier: Apache-2.0
El identificador Apache-2.0 es inequívoco y permite que herramientas de análisis lo reconozcan. SPDX también define un formato de lista de materiales de software (SBOM) que enumera componentes, versiones y licencias. Un SBOM ayuda a responder qué se distribuye y qué obligaciones aplican.
Distribución, servicios y contenedores
La mayoría de obligaciones nacen al distribuir, pero el término cambia según el canal. Entregar un binario, publicar una imagen de contenedor o embarcar software en un dispositivo son formas de distribución; mantener una instancia interna para uso propio no lo es, con excepciones que dependen de la licencia y de la jurisdicción.
| Escenario | ¿Suele activar obligaciones? | Matiz relevante |
|---|---|---|
| Uso interno sin cesión | Normalmente no | Revisar términos que obliguen más allá de la distribución |
| Binario entregado a un cliente | Sí | Avisos, licencia y fuente cuando la licencia lo exige |
| Imagen de contenedor publicada | Sí | La imagen transporta binarios y debe incluir avisos |
| Servicio propietario por red | Depende | AGPL y compromisos contractuales pueden alcanzar el servicio |
| Software embebido en un equipo | Sí | Suele exigir avisos en el producto y acceso a la fuente |
| Modificación no distribuida | Normalmente no | La obligación aparece al distribuir; AGPL es la excepción habitual |
Una imagen de contenedor no elimina obligaciones: las capas ocultan la procedencia, no la licencia. Conviene generar un inventario por imagen, incluir los textos de licencia en una ruta visible y conservar la correspondencia entre binario y fuente. Cuando se distribuye a terceros, la trazabilidad entre lo compilado y lo publicado es la evidencia que permite responder ante una revisión.
Compatibilidad y cumplimiento
La compatibilidad es la posibilidad de combinar código bajo distintas licencias sin incumplir ninguna. No es una propiedad universal: depende de cómo se combine, de si hay enlace estático o dinámico, de si se modifica y de la jurisdicción. Una licencia permisiva suele poder incluirse en un proyecto copyleft; lo contrario puede ser problemático. Mezclar GPLv2 y Apache 2.0 en un mismo trabajo puede generar conflictos según el caso.
Un proceso de cumplimiento incluye:
- Inventario e identificación: conocer dependencias directas y transitivas y su licencia SPDX.
- Evaluación: clasificar permisivas y copyleft, y detectar incompatibilidades.
- Aprobación: aplicar una política (permitir, revisar o prohibir).
- Atribución: generar avisos y textos de licencia para la distribución.
- Verificación y mantenimiento: escanear el binario antes de publicar y actualizar el inventario cuando cambien las dependencias.
Herramientas como ScanCode, FOSSA o los escáneres integrados en repositorios ayudan, pero no sustituyen la revisión humana en casos ambiguos. La política debe distinguir entre uso interno, distribución y servicio en red.
Gestión de dependencias y política
Una política de licencias convierte decisiones dispersas en criterios repetibles. No necesita ser extensa, pero sí explícita sobre qué se permite, quién aprueba y cómo se documenta una excepción. Un esquema habitual clasifica cada componente en cuatro niveles:
| Nivel | Criterio | Acción esperada |
|---|---|---|
| Permitida | Licencia permisiva conocida y sin cláusulas atípicas | Uso directo con atribución |
| Condicionada | Copyleft débil o requisitos de aviso adicionales | Revisión de arquitectura y avisos |
| Restringida | Copyleft fuerte dentro de un producto propietario | Aprobación y análisis de la combinación |
| Prohibida | Términos incompatibles con la política | Bloqueo en la construcción |
La política gana fuerza cuando se aplica en la integración continua: un archivo de bloqueo fija versiones, un escáner lee el árbol de dependencias y una compuerta impide incorporar un nivel prohibido sin aprobación. Las excepciones deben tener responsable, justificación y fecha de revisión; de lo contrario se acumulan y nadie recuerda por qué se aceptaron.
También importa el mantenimiento. Una dependencia permitida pero abandonada puede convertirse en un riesgo de seguridad y en un obstáculo para actualizar. La revisión de licencias y la revisión de salud del proyecto son tareas complementarias, no alternativas.
SBOM y trazabilidad de componentes
Una lista de materiales de software enumera los componentes de un producto, sus versiones, su procedencia y las licencias declaradas. SPDX y CycloneDX son formatos habituales para expresarla de forma legible por herramientas. El valor no está en el archivo, sino en la disciplina de generarlo en cada compilación y de vincularlo con lo que realmente se entrega.
| Campo | Para qué sirve | Riesgo si falta |
|---|---|---|
| Nombre y versión | Identificar el componente con precisión | No se puede correlacionar con avisos de seguridad |
| Proveedor u origen | Rastrear la cadena de suministro | Se desconoce quién responde por el componente |
| Licencia declarada | Conocer las condiciones esperadas | Se omiten obligaciones de atribución o fuente |
| Dependencias | Ver el árbol transitivo | Se ignoran componentes ocultos |
| Hash o identificador | Verificar que el artefacto es el esperado | Se audita una versión distinta de la distribuida |
La licencia declarada por el proyecto y la licencia concluida tras el análisis pueden diferir. Esa diferencia es una señal de revisión, no un error automático: el escaneo detecta textos y metadatos, mientras que la persona interpreta cómo se combinan los archivos. Un SBOM preciso acorta la respuesta ante una vulnerabilidad y facilita la diligencia en una compra o una auditoría.
Gobierno y sostenibilidad
Un proyecto de código abierto tiene un modelo de gobierno: quién decide, cómo se aceptan contribuciones y cómo se resuelven disputas. Puede estar mantenido por una fundación, una empresa o voluntarios. Los CLAs o los DCO documentan que quien contribuye tiene derecho a hacerlo.
La sostenibilidad importa: un componente popular sin mantenimiento puede acumular vulnerabilidades. Conviene revisar actividad, releases, respuesta a incidentes y política de seguridad; el licenciamiento no garantiza soporte.
Modelos de contribución
| Mecanismo | Qué registra | Efecto práctico |
|---|---|---|
| CLA | Permiso del contribuyente a favor del proyecto o de una entidad | Permite relicenciar o defender el proyecto con mayor margen |
| DCO | Declaración de que se tiene derecho a contribuir | Se añade con cada confirmación en el historial |
| Entrada igual a salida | La contribución entra con la licencia del proyecto | Sin papeleo adicional; exige coherencia de licencia |
El modelo elegido afecta a la confianza y a la sostenibilidad. Un CLA amplio puede facilitar una estrategia comercial, pero algunos contribuyentes lo perciben como una cesión excesiva. El DCO es más ligero y deja la responsabilidad en quien firma. En cualquier caso, quien contribuye desde una empresa necesita autorización de su empleador, porque los derechos pueden pertenecer a la organización.
Modelos de negocio
El código abierto no impone un modelo de ingresos. Las combinaciones más frecuentes son el soporte y la suscripción, el alojamiento gestionado, el núcleo abierto con funciones de pago y la licencia dual. Cada una crea tensiones distintas entre comunidad y clientes.
| Modelo | Fuente de ingresos | Tensión típica |
|---|---|---|
| Soporte | Contratos de ayuda y mantenimiento | La comunidad compite con el servicio de pago |
| Servicio alojado | Operación y disponibilidad | Obligaciones de licencias como AGPL |
| Núcleo abierto | Funciones empresariales adicionales | Dónde trazar la frontera sin decepcionar |
| Licencia dual | Versión copyleft y versión comercial | Requiere control de derechos sobre las contribuciones |
La transparencia sobre qué es abierto y qué no reduce conflictos. Cambiar de licencia o cerrar componentes después de atraer contribuciones daña la reputación y puede ser inviable si no se conservan los permisos necesarios. La sostenibilidad también depende de la diversidad de financiación: un proyecto sostenido por una sola empresa es vulnerable a sus decisiones.
Auditoría, incidentes y remediación
Cuando aparece un componente con una licencia no prevista, la respuesta se organiza como un incidente. Primero se contiene el uso o la distribución; después se identifica la obligación concreta y se decide entre sustituir, aislar, obtener una autorización o cumplir la condición. La decisión se documenta con evidencia y fecha.
| Etapa | Acción | Evidencia |
|---|---|---|
| Detección | Localizar el componente y su versión | SBOM y registro de la compilación |
| Contención | Evitar nuevas distribuciones afectadas | Bloqueo de la versión en el repositorio |
| Análisis | Interpretar la licencia y la forma de uso | Informe con el texto aplicable |
| Remediación | Sustituir, aislar o cumplir la obligación | Cambio aprobado y pruebas |
| Verificación | Confirmar que el binario ya no contiene el riesgo | Escaneo posterior a la corrección |
| Cierre | Registrar la lección y ajustar la política | Entrada en el registro de decisiones |
La remediación no siempre exige reescribir el producto. A veces basta con publicar la fuente de los archivos afectados, añadir avisos o separar un proceso para que la combinación no alcance al conjunto. La opción correcta depende de la licencia y de la arquitectura, y conviene validarla antes de prometer una fecha a un cliente.
Patentes, marcas y otros derechos
Las patentes protegen invenciones, no la expresión del código. Una licencia puede incluir una concesión expresa de patentes, como Apache 2.0 y MPL 2.0, o guardar silencio, como ocurre en los textos permisivos más breves. La diferencia importa cuando un producto se comercializa a gran escala o cuando existe litigio.
Las marcas identifican el origen del proyecto y se licencian aparte. Usar el nombre de un proyecto para describir compatibilidad suele ser aceptable, pero presentar un derivado como si fuera la versión oficial puede infringir derechos de marca. Los avisos de copyright, en cambio, deben conservarse según la licencia y no se sustituyen por una mención genérica.
También existen derechos sobre bases de datos y sobre documentación, que pueden tener condiciones propias. Un repositorio con código, manuales e imágenes no es una unidad homogénea: cada tipo de obra puede requerir un análisis distinto.
Ejemplos prácticos
Caso 1: biblioteca MIT en un producto. Un equipo incorpora una biblioteca MIT en una aplicación propietaria. Debe conservar el aviso de copyright y la licencia, pero no publicar el código de la aplicación.
Caso 2: servicio con componente AGPL. Una empresa modifica una herramienta AGPL y la ofrece por red. La licencia exige poner a disposición el código; un repositorio privado no basta.
Caso 3: parche Apache 2.0. Un equipo modifica un componente Apache 2.0 y lo redistribuye. Debe conservar avisos, incluir la licencia y declarar los cambios; las cláusulas de patentes importan si hay litigio.
Caso 4: biblioteca LGPL en un producto propietario. Un equipo enlaza dinámicamente una biblioteca LGPL. Puede distribuir su aplicación con condiciones distintas si cumple los requisitos de la LGPL, como permitir la sustitución de la biblioteca. Cambiar a enlace estático o modificar la biblioteca altera el análisis y exige revisar las obligaciones aplicables.
Caso 5: contenedor con dependencias transitivas. Una imagen incluye una herramienta de línea de comandos bajo GPLv3 que solo se usa durante la construcción. Si no se distribuye en la imagen final, la obligación no se traslada al cliente; si se copia al artefacto entregado, el análisis cambia. Separar etapas de construcción y ejecución reduce el riesgo y el tamaño de la imagen.
Caso 6: licencia dual y contribuciones. Una empresa mantiene una versión comunitaria y otra comercial. Para relicenciar contribuciones necesita permisos suficientes; por eso usa un CLA. Si dependiera solo de contribuciones sin permiso, no podría ofrecer la versión comercial sin negociar con cada autor.
Caso 7: aviso olvidado en un binario. Un producto redistribuye una biblioteca MIT pero omite el texto de licencia. La corrección es sencilla: añadir el aviso en la documentación y en el paquete. El incidente revela que el proceso de compilación no verificaba los avisos, así que se añade una comprobación automática antes de publicar.
Lista de comprobación previa a la entrega
- ¿El inventario incluye dependencias directas y transitivas?
- ¿Cada componente tiene licencia identificada y versión fijada?
- ¿Se revisaron las cláusulas de patentes y terminación?
- ¿Los avisos y textos de licencia viajan con el binario?
- ¿Las modificaciones están declaradas cuando la licencia lo pide?
- ¿La fuente se ofrece o se acompaña cuando corresponde?
- ¿El uso en red se evaluó frente a licencias como AGPL?
- ¿El SBOM corresponde al artefacto que se distribuye?
- ¿Las excepciones tienen responsable y fecha de revisión?
- ¿La política distingue uso interno, distribución y servicio?
- ¿Existe un procedimiento para retirar o sustituir un componente?
- ¿El equipo sabe a quién escalar una duda legal?
Errores frecuentes
- Creer que "open source" significa "gratis" o "sin condiciones".
- Ignorar dependencias transitivas y sus licencias.
- Ofrecer un servicio AGPL sin revisar la obligación de código fuente.
- No distinguir uso interno de distribución ni generar un SBOM.
Puntos clave para el examen
- Código abierto: libertades sobre el código, no ausencia de licencia ni precio cero.
- OSI define criterios; una licencia aprobada los cumple.
- Permisivas: MIT, BSD, Apache 2.0. Copyleft: GPL, AGPL, MPL, LGPL.
- Copyleft fuerte alcanza el conjunto; débil se limita a archivos o bibliotecas.
- Distribuir activa obligaciones de aviso, licencia y, según el caso, código fuente.
- SPDX identifica licencias y el SBOM inventaría componentes; la compatibilidad se evalúa caso por caso.
Glosario
- Atribución: conservación de autoría, copyright y avisos exigidos por la licencia.
- Copyleft: condición que obliga a mantener la misma licencia en obras derivadas o archivos cubiertos.
- Distribución: cesión del software a un tercero que activa obligaciones de licencia.
- Licencia declarada: valor que el propio componente anuncia en sus metadatos.
- Licencia concluida: resultado del análisis de los archivos y de su combinación.
- Relicenciar: cambiar la licencia de una obra cuando se tienen los derechos necesarios.
- SBOM: inventario estructurado de componentes, versiones y licencias de un producto.
- Terminación: cláusula que extingue la autorización si se incumplen condiciones.
Recursos externos
- Open Source Initiative, Open Source Definition: https://opensource.org/osd
- Open Source Initiative, lista de licencias: https://opensource.org/licenses
- SPDX License List: https://spdx.org/licenses/
- Apache License 2.0: https://www.apache.org/licenses/LICENSE-2.0
- GNU GPLv3: https://opensource.org/license/gpl-3-0
- Mozilla Public License 2.0: https://www.mozilla.org/en-US/MPL/2.0/
- CISA, Software Bill of Materials: https://www.cisa.gov/sbom
Autoevaluación
-
¿Qué diferencia hay entre software de código abierto y freeware? El código abierto concede libertades sobre el código fuente, incluida su modificación y redistribución. El freeware es gratuito pero puede no incluir fuente ni permitir cambios.
-
¿Qué obligación principal impone una licencia copyleft fuerte como GPL? Que quien distribuya una obra derivada ponga a disposición el código fuente bajo la misma licencia.
-
¿Qué significa que MPL 2.0 sea copyleft débil? Que la obligación de publicar el código se limita a los archivos cubiertos modificados, no a todo el programa que los combina.
-
¿Para qué sirve un identificador SPDX? Para declarar de forma inequívoca la licencia de un componente y permitir que herramientas y personas la reconozcan.
-
¿Cuándo conviene revisar el cumplimiento de licencias? Al incorporar dependencias, antes de distribuir y cuando cambian versiones o licencias; el inventario y el SBOM deben mantenerse actualizados.