¿Puede usar esta aplicación autoalojada para su empresa? Lista de verificación de diligencia debida sobre licencias de código abierto
El autoalojamiento puede cambiar la forma de operar una aplicación, pero no resuelve por sí solo las cuestiones de licencia, redistribución, marcas o divulgación del código fuente. Utilice esta lista de verificación práctica para reunir pruebas, definir el uso previsto y saber cuándo buscar asesoramiento jurídico cualificado.
El autoalojamiento no responde todas las preguntas sobre licencias
«Código abierto» no es un único nivel de permisos, y el acceso a un repositorio público de código fuente no basta para determinar si una empresa puede usar, modificar, alojar, identificar con una marca o redistribuir una aplicación de la manera prevista. La Open Source Initiative (OSI) establece esta distinción directamente: el código abierto se refiere tanto a los términos de distribución como al acceso al código fuente.
Si una aplicación está realmente bajo una licencia de código abierto conforme a la OSI, esa licencia no puede restringir el uso en un campo de actividad concreto, incluido el uso empresarial. Esto es útil, pero no pone fin a la revisión. Su despliegue puede incluir componentes, recursos o complementos con licencias independientes; su actividad prevista puede implicar distribución; y los nombres, logotipos y dominios pueden regirse por normas de marcas en lugar de por la licencia del software.
Considere este artículo como un marco operativo de diligencia debida, no como asesoramiento jurídico. El objetivo es sustituir las suposiciones por un registro revisable e identificar las situaciones que justifican asesoramiento jurídico cualificado antes del despliegue.
- No equipare «código disponible» con «código abierto».
- No equipare el alojamiento interno con el permiso para redistribuir copias a clientes o usuarios.
- No suponga que una licencia situada en el nivel superior del repositorio cubre todos los elementos del despliegue.
- Revise las normas sobre marcas y denominación por separado de los términos de la licencia de software.
Empiece por el uso previsto, no por la lista de funciones de la aplicación
Antes de leer el texto de la licencia, deje por escrito qué hará realmente su organización. Las cuestiones de licencia se aclaran cuando se vinculan a un modelo concreto de despliegue y distribución, en lugar de a un deseo general de «usar el software comercialmente».
Una herramienta utilizada solo por su propio personal presenta un escenario distinto al de un servicio orientado a clientes, un despliegue personalizado para un cliente o un producto que incorpora la aplicación para redistribuirla. La misma distinción importa si planea proporcionar a otra persona una imagen Docker, un instalador, un árbol de código fuente modificado o una instancia gestionada.
Haga que esta declaración sea lo bastante específica para que un colega pueda contrastarla con la licencia. Si el uso previsto cambia más adelante, reabra la revisión en lugar de basarse en la conclusión anterior.
- Herramienta interna: ¿quién puede acceder y el equipo la modificará?
- Servicio orientado a clientes: ¿usuarios externos interactuarán con la aplicación de forma remota?
- Despliegue para clientes: ¿entregará una copia, una imagen, código fuente o una compilación modificada?
- Producto redistribuido: ¿incorporará la aplicación o componentes sustanciales a su propia oferta?
- Marca: ¿usará el nombre o logotipo del proyecto, o un nombre similar, en un producto, servicio o dominio?
- Integración: ¿qué complementos, bibliotecas, modelos, fuentes, temas, conectores y recursos se incluirán?
Encuentre pruebas de licencia autorizadas y fije la versión revisada
Comience con pruebas primarias de la versión exacta de la aplicación que pretende desplegar. El archivo LICENSE de un repositorio es un punto de partida importante, pero debe comprobarse junto con la distribución del código fuente, la documentación del proveedor o proyecto, los avisos de copyright y cualquier material LICENSE o NOTICE incluido.
Registre la versión de lanzamiento, la etiqueta de imagen cuando corresponda o el commit de código fuente que revisó. Una conclusión sobre la licencia sin una referencia de versión es difícil de revisar cuando una actualización cambia dependencias, avisos o materiales de distribución.
Cuando la aplicación se distribuye sin código fuente, la definición de la OSI también es relevante: para una licencia de código abierto, el código fuente es la forma preferida para realizar modificaciones, y los términos de distribución deben proporcionar un medio ampliamente divulgado para obtenerlo cuando el código fuente no se distribuye con el producto. No deduzca que un proyecto es conforme a la OSI únicamente porque exista un repositorio.
- Capture la URL de origen y la fecha de acceso.
- Guarde o enlace el texto exacto de la licencia y su identificador, si se indica.
- Registre la versión de la aplicación, referencia de lanzamiento o commit.
- Compruebe LICENSE, COPYING, NOTICE, cabeceras de copyright y avisos de terceros.
- Compare las pruebas del repositorio con la documentación oficial y los artefactos distribuidos.
- Anote contradicciones, archivos ausentes y procedencia poco clara como cuestiones no resueltas.
Lea el alcance de la licencia antes de comparar aplicaciones
No seleccione una aplicación por su conjunto de funciones y trate la licencia indicada como una nota al pie. Lea el texto aplicable a la obra que utilizará, especialmente las disposiciones relativas a modificación, reproducción, distribución, avisos, patentes y marcas.
Por ejemplo, la Licencia Apache 2.0 incluye condiciones explícitas cuando se reproducen y distribuyen copias u obras derivadas. Entre ellas están proporcionar una copia de la licencia, marcar los archivos modificados, conservar los avisos pertinentes y preservar las atribuciones aplicables del archivo NOTICE. Estos requisitos están vinculados a la reproducción y distribución, por lo que una evaluación precisa depende de si su modelo de entrega propuesto alcanza esas actividades.
Las etiquetas de licencia no sustituyen el análisis de una combinación prevista. Las FAQ de GNU GPL describen la compatibilidad de licencias en términos de si las licencias pertinentes permiten la combinación prevista, y señalan que la forma de combinación puede ser importante. Cuando su oferta combina componentes de una manera que no está claramente documentada, es motivo para detenerse en lugar de hacer suposiciones.
- Identifique la obra cubierta: la aplicación, un complemento, una biblioteca, una imagen de contenedor u otro artefacto.
- Identifique sus acciones: ejecutar, modificar, copiar, distribuir, empaquetar, proporcionar a un cliente o exponer de forma remota.
- Lea las condiciones y excepciones en el texto completo de la licencia, no solo en un resumen.
- Enumere los avisos, ofertas de código fuente o marcas de modificación requeridos que podrían aplicarse a su modelo.
- Marque las combinaciones de componentes inciertas para revisión especializada.
Compruebe por separado las dependencias, complementos, modelos, fuentes y recursos incluidos
Un archivo de licencia de la aplicación de nivel superior puede no resolver los derechos de todo lo que llega a sus usuarios o se incluye en su compilación. La guía de licencias de Apache, por ejemplo, reconoce que pueden incluirse obras de terceros en el producto de un proyecto y que su texto de licencia puede aparecer en archivos LICENSE o NOTICE, o estar disponible por separado.
Elabore un inventario de lo que realmente se despliega, no solo de lo que aparece en la raíz del repositorio. Incluya dependencias de ejecución, dependencias de compilación que se distribuyen en un artefacto, complementos opcionales que active, temas, fuentes, conjuntos de datos, archivos de modelo y otros recursos incluidos. No suponga que todos estos elementos tienen los mismos términos que la aplicación principal.
SPDX resulta útil como vocabulario de documentación y formato de SBOM. Sus conceptos de relación incluyen dependencias, manifiestos de dependencias, dependencias de compilación, dependencias de desarrollo y dependencias de ejecución. No necesita un inventario automatizado perfecto antes de tomar una decisión, pero sí necesita pruebas suficientes para identificar los componentes que afectan materialmente a su uso previsto.
- Cree una fila de componente para cada dependencia material o elemento incluido.
- Registre el nombre del componente, versión, origen, pruebas de licencia y cómo entra en la pila.
- Diferencie los elementos de ejecución de los que son solo de compilación y desarrollo.
- Compruebe los complementos y extensiones activados por separado de las opciones no utilizadas.
- Busque avisos incluidos, textos de licencia y requisitos de atribución.
- Marque los componentes desconocidos o personalizados como bloqueadores si se distribuirán, modificarán o expondrán a clientes.
Mantenga separadas las decisiones sobre marcas, identidad y dominios
Una licencia de software no es un permiso general para usar nombres, logotipos o identidad visual del proyecto de cualquier manera. El análisis de marcas tiene una finalidad distinta: evitar confusión sobre el origen, la afiliación o el respaldo.
La política de Apache ilustra esta separación. Identifica los nombres de proyectos, los nombres de productos y los logotipos como marcas, mientras que el propio software se distribuye conforme a los términos de su licencia de software. En concreto para los proyectos Apache, las obras derivadas no deben usar nombres de proyectos o logotipos de proyectos que resulten confusamente similares, y el uso que pueda generar confusión de marcas de Apache en nombres de dominio exige aprobación por escrito.
Utilice la política de marcas del propio proyecto cuando esté disponible. Si incluirá el nombre de la aplicación en una oferta para clientes, modificará un logotipo, publicará una bifurcación con marca o registrará un dominio relacionado, añada ese plan al registro de pruebas y busque asesoramiento cuando la política no lo cubra con claridad.
- ¿El servicio público utilizará el nombre o logotipo del proyecto?
- ¿Describirá el servicio como oficial, afiliado o respaldado?
- ¿Una bifurcación modificada conservará, reemplazará o complementará la identidad visual existente?
- ¿El dominio previsto contiene el nombre del proyecto o de la organización?
- ¿El proyecto publica una política de marcas o guía de uso de marca?
- ¿La presentación prevista puede resultar confusa para los usuarios?
Comprenda con precisión las cuestiones sobre servicios de red y divulgación de código fuente
No suponga que poner software a disposición a través de una red siempre tiene el mismo efecto que distribuir una copia. GPLv3 establece que la mera interacción con un usuario a través de una red informática, sin transferencia de una copia, no constituye por sí misma «transmisión» conforme al texto de esa licencia.
AGPLv3 contiene una disposición condicional distinta para una versión modificada que admite interacción remota a través de la red. La sección 13 exige que quien modifique ofrezca a los usuarios remotos la oportunidad de recibir el Código Fuente Correspondiente de esa versión modificada. Esto no es motivo para hacer afirmaciones amplias sobre todos los despliegues alojados; es motivo para identificar la licencia exacta, si modificó el programa cubierto y si este admite interacción remota.
Si su servicio incluye múltiples componentes, analice la licencia del componente pertinente y la naturaleza de la integración. Las FAQ de GNU GPL señalan que el límite entre programas separados y un único programa combinado es, en última instancia, una cuestión jurídica. Una arquitectura no evidente no es lugar para una conclusión informal de cumplimiento.
- Identifique si algún componente accesible de forma remota está sujeto a términos con disposiciones sobre interacción de red.
- Registre si su equipo modificó ese componente y dónde residen las modificaciones.
- Determine si los usuarios reciben una copia, interactúan solo con un servicio o ambas cosas.
- Documente cómo se proporcionarían el acceso al código fuente, los avisos y los registros de modificaciones si fueran necesarios.
- Escale las combinaciones inciertas, bifurcaciones y obligaciones de divulgación de código fuente antes del lanzamiento.
Elabore un registro de pruebas antes del despliegue
Un registro de pruebas conciso convierte la diligencia debida sobre licencias en un control operativo. Debe permitir que otra persona comprenda qué se revisó, de dónde procedían las pruebas, qué pretende hacer la organización y qué permanece sin resolver.
Mantenga el registro junto con el expediente de despliegue y actualícelo cuando cambie la versión de la aplicación, active un nuevo complemento, modifique código, cambie una imagen, añada un modelo de entrega a clientes o modifique la identidad pública. Esto resulta más útil que una declaración única de sí o no, porque las pilas autoalojadas evolucionan.
Utilice identificadores estándar e información de SBOM cuando estén disponibles, pero no permita que un identificador conocido sustituya la revisión del texto aplicable, los avisos y el modelo de entrega.
- Nombre de la aplicación o componente.
- Versión, lanzamiento, referencia de imagen o commit revisado.
- URL de origen y ubicación de las pruebas de licencia.
- Identificador de licencia declarado y enlace al texto completo.
- Observaciones sobre copyright, NOTICE y atribuciones.
- Notas sobre dependencias y relaciones, incluidos elementos de ejecución y compilación.
- Modificaciones realizadas, previstas o heredadas.
- Plan de distribución, entrega a clientes y servicio remoto.<br>Plan de marcas, logotipo y dominio.<br>Cuestiones abiertas, responsable, decisión de escalado y fecha de revisión.
Preguntas frecuentes
¿El autoalojamiento de una aplicación significa que podemos usarla comercialmente?
No por sí solo. Una licencia de código abierto conforme a la OSI no puede restringir el uso en un campo de actividad concreto, incluido el uso empresarial. Sin embargo, aún debe verificar que la aplicación y los componentes exactos están sujetos a los términos indicados, y evaluar por separado la distribución, las modificaciones, los avisos, las marcas y su plan de despliegue específico.
¿Un repositorio público de Git es prueba suficiente de que una aplicación es de código abierto?
No. La OSI explica que el código abierto implica más que el acceso al código fuente; los términos de distribución deben cumplir la Definición de Código Abierto. Revise las pruebas de licencia autorizadas para la versión que planea utilizar.
¿Debemos revisar las dependencias si la aplicación tiene un archivo LICENSE?
Sí. Las obras de terceros pueden tener texto de licencia o avisos independientes. Inventaríe las dependencias de ejecución materiales, las salidas de compilación distribuidas, los complementos, modelos, fuentes, temas y recursos incluidos; después, registre las pruebas de licencia y la función de cada uno en la pila desplegada.
¿Alojar software GPL para usuarios cuenta automáticamente como distribución?
GPLv3 indica que la mera interacción mediante red sin transferencia de una copia no constituye transmisión. El resultado preciso depende de la licencia aplicable, el componente y lo que realmente proporcione. No generalice esta afirmación a todas las licencias o arquitecturas.
¿Qué diferencia hay con AGPLv3 para un servicio alojado?
La sección 13 de AGPLv3 incluye una obligación condicional para una versión modificada que admite interacción remota a través de la red: se debe ofrecer de forma destacada a los usuarios remotos acceso al Código Fuente Correspondiente de la versión modificada. Determine si modificó el programa cubierto y obtenga asesoramiento cualificado si la aplicación de la obligación no está clara.
¿Podemos usar el nombre y el logotipo del proyecto en nuestro servicio alojado?
Es una cuestión de marcas e identidad visual, independiente de la licencia de software. Revise la política de marcas del proyecto, especialmente antes de usar un logotipo, comercializar una bifurcación modificada, afirmar una afiliación o registrar un dominio relacionado.
Fuentes y lecturas adicionales
- The Open Source Definition — Open Source Initiative
- Apache License, Version 2.0 — Apache Software Foundation
- Apache Licensing and Distribution FAQ — Apache Software Foundation
- SPDX Overview — SPDX
- SPDX Specification: Relationships Between SPDX Elements — SPDX
- GNU Affero General Public License v3 — GNU Project / Free Software Foundation
- GNU General Public License v3 — GNU Project / Free Software Foundation
- GNU GPL FAQ — GNU Project / Free Software Foundation
- Apache Software Foundation Trademark Policy — Apache Software Foundation
- Docker Compose documentation — Docker