Un’interfaccia VPN, un motore GPL e un installer: cosa viene distribuito?

La domanda arriva come una questione di licenza, ma la risposta comincia con un inventario. Un’interfaccia VPN, il motore OpenVPN che pilota, una libreria TLS e un installer possono avere quattro insiemi diversi di termini, e l’aspetto del prodotto non vi dice nulla su quale file appartenga a quale insieme. Percorrete gli artefatti nell’ordine in cui vengono distribuiti, e la questione legale diventa molto più ristretta quando la affidate a qualcuno qualificato per rispondere. Ogni passo la restringe ulteriormente: cosa viene distribuito, cosa è stato modificato e come comunicano le parti.

Cominciate da ciò che l’installer mette sul disco

Prendete l’installer o il pacchetto pubblicato, non una copia di sviluppo, ed elencate ogni file che colloca su una macchina pulita. Registrate le versioni dell’interfaccia, del motore e della libreria TLS, e annotate se il motore è un eseguibile separato o una libreria caricata nello stesso processo.

Quest’ultimo fatto plasma tutto ciò che segue. Un eseguibile separato avviato tramite un socket solleva un insieme di domande diverso dal codice compilato in un unico binario, e un installer che si limita a collocare entrambi uno accanto all’altro non decide la questione in nessun senso. Il raggruppamento è una decisione di packaging, mentre la relazione tra i programmi è di natura architetturale.

Scrivete l’elenco con le versioni allegate, perché i termini cambiano tra le versioni principali.

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

Separate l’interfaccia dal motore

Il file di copia di OpenVPN indica la versione 2 della GPL e documenta un’eccezione di collegamento per OpenSSL, che è un permesso specifico con un ambito definito e non una licenza generale per mescolare i termini.

Catturate il testo della licenza distribuito con la vostra build, non quello che oggi si trova sul sito del progetto. Una release che ha fissato un ramo più vecchio porta con sé il documento di quel ramo. Le schermate di una pagina di repository non sono un sostituto, perché il file che vi serve è quello dentro l’artefatto. Conservatelo accanto all’installer perché il pacchetto sia completo.

Poi descrivete l’integrazione con onestà: l’interfaccia avvia il motore come processo figlio e parla un protocollo testuale, oppure collega una libreria e scambia strutture interne? La seconda disposizione è intima in un modo in cui la prima non lo è, e questa distinzione è la prima cosa che un revisore chiederà.

Annotate quali file avete modificato

Il codice sorgente modificato cambia l’analisi più di qualsiasi dettaglio di packaging. Se avete applicato una patch al motore, la patch stessa è opera derivata, e l’obbligo ricade su chi distribuisce il risultato.

Registrate ogni patch, il suo scopo e se è stata inviata a monte, perché una patch che non ha mai lasciato il vostro repository fa comunque parte di ciò che distribuite se distribuite il binario.

I file di configurazione, i temi e le traduzioni di solito vivono con l’interfaccia, ma una traduzione che incorpora stringhe del codice del motore è un piccolo promemoria del fatto che il confine è per file e non per directory. Mantenete un diff tra la release a monte e la vostra build perché la risposta sia disponibile su richiesta invece di essere ricostruita in seguito. Quel diff è anche l’artefatto più utile quando un revisore chiede cosa è cambiato.

Controllate la versione di OpenSSL a parte

OpenSSL 3.0 e successivi sono distribuiti con licenza Apache 2.0, mentre le versioni precedenti portano i termini OpenSSL/SSLeay. Sono documenti diversi con obblighi diversi, e un motore integrato può collegare quello che il vostro sistema di build ha trovato.

Confermate la versione effettivamente distribuita e non quella indicata in uno script di build.

Una dipendenza da OpenVPN non converte ogni modifica a OpenSSL in codice GPL, e l’eccezione di collegamento non elimina gli altri obblighi che derivano dalla ridistribuzione della libreria. Trattate l’eccezione come una clausola di un’analisi più ampia, e registrate gli avvisi della libreria TLS insieme a tutto il resto.

Raccogliete il fascicolo di prove

Il fascicolo ha quattro parti: l’inventario dei file con le versioni, la descrizione dell’integrazione, l’elenco delle modifiche con i diff e i testi delle licenze come distribuiti. Aggiungete il file di avvisi che distribuite e il luogo in cui il codice sorgente viene offerto, se i vostri obblighi richiedono un’offerta.

Tenete il fascicolo sotto un unico responsabile perché nessuna release possa uscire senza.

Niente di tutto questo decide una questione legale, e questo è il punto: dà a un revisore qualificato i fatti invece di un riassunto messo insieme a memoria. La descrizione marketing di un fornitore non è una prova della sua architettura, e nemmeno la vostra supposizione in merito lo è.