Una interfaz VPN, un motor GPL y un instalador: ¿qué se distribuye?

La pregunta llega como un asunto de licencias, pero la respuesta empieza por un inventario. Una interfaz VPN, el motor OpenVPN que impulsa, una biblioteca TLS y un instalador pueden tener cuatro conjuntos distintos de condiciones, y el aspecto del producto no le dice nada sobre qué archivo pertenece a qué conjunto. Recorra los artefactos en el orden en que se distribuyen, y la cuestión legal se vuelve mucho más estrecha cuando la entregue a alguien cualificado para responderla. Cada paso la estrecha más: qué se distribuye, qué se cambió y cómo se comunican las partes.

Empiece por lo que el instalador pone en el disco

Tome el instalador o paquete publicado, no una copia de desarrollo, y enumere cada archivo que coloca en una máquina limpia. Registre las versiones de la interfaz, el motor y la biblioteca TLS, y anote si el motor es un ejecutable separado o una biblioteca cargada en el mismo proceso.

Ese último dato determina todo lo que sigue. Un ejecutable separado lanzado por un socket plantea un conjunto distinto de preguntas que el código compilado en un solo binario, y un instalador que solo coloca ambos uno al lado del otro no decide la cuestión en ningún sentido. El empaquetado es una decisión de distribución, mientras que la relación entre los programas es arquitectónica.

Escriba la lista con las versiones adjuntas, porque las condiciones cambian entre versiones principales.

dpkg -L openvpn | head -n 40
openssl version -a

Separe la interfaz del motor

El archivo de copia de OpenVPN indica la versión 2 de la GPL y documenta una excepción de enlace para OpenSSL, que es un permiso específico con un alcance definido y no una licencia general para mezclar condiciones.

Capture el texto de la licencia que se distribuye con su compilación, no el que está hoy en el sitio web del proyecto. Una publicación que fijó una rama antigua lleva el documento de esa rama. Las capturas de pantalla de una página de repositorio no son un sustituto, porque el archivo que necesita es el que está dentro del artefacto. Guárdelo junto al instalador para que el paquete esté completo.

Después describa la integración con honestidad: ¿la interfaz inicia el motor como proceso hijo y habla un protocolo de texto, o enlaza una biblioteca e intercambia estructuras internas? La segunda disposición es íntima de una forma en que la primera no lo es, y esa distinción es lo primero que preguntará un revisor.

Anote qué archivos cambió

El código fuente modificado cambia el análisis más que cualquier detalle de empaquetado. Si parcheó el motor, el parche en sí es obra derivada, y la obligación recae en quien distribuye el resultado.

Registre cada parche, su propósito y si se envió al proyecto original, porque un parche que nunca salió de su repositorio sigue formando parte de lo que distribuye si distribuye el binario.

Los archivos de configuración, los temas y las traducciones suelen vivir con la interfaz, pero una traducción que incrusta cadenas del código del motor es un pequeño recordatorio de que el límite es por archivo y no por directorio. Mantenga una diferencia entre la publicación original y su compilación para que la respuesta esté disponible a petición en lugar de reconstruirse después. Esa diferencia es también el artefacto más útil cuando un auditor pregunta qué cambió.

Compruebe la versión de OpenSSL por separado

OpenSSL 3.0 y posteriores se distribuyen bajo la licencia Apache 2.0, mientras que las versiones anteriores llevan las condiciones OpenSSL/SSLeay. Son documentos diferentes con obligaciones diferentes, y un motor empaquetado puede enlazar el que haya encontrado su sistema de compilación.

Confirme la versión realmente distribuida y no la indicada en un script de compilación.

Una dependencia de OpenVPN no convierte cada modificación de OpenSSL en código GPL, y la excepción de enlace no elimina las demás obligaciones que conlleva redistribuir la biblioteca. Trate la excepción como una cláusula dentro de un análisis más amplio, y registre los propios avisos de la biblioteca TLS junto con todo lo demás.

Reúna el paquete de pruebas

El paquete tiene cuatro partes: el inventario de archivos con versiones, la descripción de la integración, la lista de modificaciones con diferencias y los textos de licencia tal como se distribuyen. Añada el archivo de avisos que distribuye y el lugar donde se ofrece el código fuente, si sus obligaciones exigen una oferta.

Mantenga el paquete bajo un solo responsable para que ninguna publicación pueda salir sin él.

Nada de esto decide una cuestión legal, y esa es la idea: da a un revisor cualificado los hechos en lugar de un resumen que alguien armó de memoria. La descripción de marketing de un proveedor no es prueba de su arquitectura, y su propia conjetura sobre ella tampoco es prueba.