Puoi usare questa applicazione self-hosted per la tua azienda? Una checklist di due diligence sulle licenze open source
L’hosting autonomo può cambiare il modo in cui un’applicazione viene gestita, ma non risponde da solo alle domande su licenze, ridistribuzione, marchi o divulgazione del codice sorgente. Usa questa checklist pratica per raccogliere evidenze, definire l’uso previsto e capire quando chiedere una consulenza legale qualificata.
L’hosting autonomo non risponde a ogni domanda sulle licenze
“Open source” non indica un unico livello di autorizzazione, e l’accesso a un repository pubblico del codice sorgente non basta a stabilire se un’azienda possa usare, modificare, ospitare, brandizzare o ridistribuire un’applicazione nel modo previsto. L’Open Source Initiative (OSI) distingue esplicitamente questi aspetti: l’open source riguarda i termini di distribuzione oltre all’accesso al codice sorgente.
Se un’applicazione è effettivamente concessa in licenza con una licenza open source conforme all’OSI, tale licenza non può limitare l’uso in un particolare settore di attività, incluso l’uso aziendale. Questo è utile, ma non conclude l’analisi. Il deployment potrebbe includere componenti, risorse o plugin concessi con licenze separate; l’attività pianificata potrebbe comportare distribuzione; e nomi, loghi e domini possono essere disciplinati dalle regole sui marchi anziché dalla licenza software.
Considera questo articolo come un quadro operativo di due diligence, non come consulenza legale. L’obiettivo è sostituire le supposizioni con una documentazione verificabile e individuare le situazioni che richiedono una consulenza legale qualificata prima del deployment.
- Non equiparare “codice disponibile” a “open source”.
- Non equiparare l’hosting interno all’autorizzazione di ridistribuire copie a clienti o committenti.
- Non presumere che la licenza del repository principale copra ogni elemento del deployment.
- Esamina separatamente le regole su marchi e denominazioni rispetto ai termini della licenza software.
Inizia dall’uso previsto, non dall’elenco delle funzionalità dell’applicazione
Prima di leggere il testo della licenza, scrivi che cosa farà effettivamente la tua organizzazione. Le questioni di licenza diventano più chiare quando sono legate a un modello concreto di deployment e distribuzione, anziché a un desiderio generico di “usare il software commercialmente”.
Uno strumento usato soltanto dal personale interno presenta una situazione di fatto diversa da un servizio rivolto ai clienti, da un deployment personalizzato per un cliente o da un prodotto che incorpora l’applicazione per ridistribuirla. La stessa distinzione vale se prevedi di fornire a terzi un’immagine Docker, un programma di installazione, un albero del codice sorgente modificato o un’istanza gestita.
Rendi questa dichiarazione abbastanza specifica da permettere a un collega di verificarla rispetto alla licenza. Se l’uso previsto cambia in seguito, riapri l’analisi anziché fare affidamento sulla conclusione precedente.
- Strumento interno: chi può accedervi e il team lo modificherà?
- Servizio rivolto ai clienti: utenti esterni interagiranno con l’applicazione da remoto?
- Deployment per il cliente: consegnerai una copia, un’immagine, il codice sorgente o una build modificata?
- Prodotto ridistribuito: incorporerai l’applicazione o componenti sostanziali nella tua offerta?
- Branding: userai il nome del progetto, il logo o un nome simile in un prodotto, servizio o dominio?
- Integrazione: quali plugin, librerie, modelli, font, temi, connettori e risorse saranno inclusi?
Trova prove autorevoli della licenza e fissa la versione esaminata
Inizia dalle fonti primarie relative alla versione esatta dell’applicazione che intendi distribuire. Il file LICENSE di un repository è un importante punto di partenza, ma dovrebbe essere verificato insieme alla distribuzione del codice sorgente, alla documentazione del fornitore o del progetto, alle note sul copyright e a qualsiasi materiale LICENSE o NOTICE incluso.
Registra la versione della release, il tag dell’immagine ove applicabile, oppure il commit del codice sorgente che hai esaminato. Una conclusione sulla licenza priva di un riferimento alla versione è difficile da riesaminare quando un aggiornamento modifica dipendenze, avvisi o materiali di distribuzione.
Quando l’applicazione viene distribuita senza codice sorgente, è rilevante anche la definizione dell’OSI: per una licenza open source, il codice sorgente è la forma preferita per le modifiche e i termini di distribuzione devono prevedere un mezzo ampiamente pubblicizzato per ottenerlo quando il sorgente non è distribuito con il prodotto. Non dedurre che un progetto sia conforme all’OSI soltanto perché esiste un repository.
- Acquisisci l’URL della fonte e la data di accesso.
- Salva o collega il testo esatto della licenza e il suo identificatore, se indicato.
- Registra la versione dell’applicazione, il riferimento alla release o il commit.
- Verifica la presenza di LICENSE, COPYING, NOTICE, intestazioni di copyright e avvisi di terze parti.
- Confronta le prove del repository con la documentazione ufficiale e gli artefatti distribuiti.
- Annota contraddizioni, file mancanti e provenienza poco chiara come questioni irrisolte.
Leggi l’ambito della licenza prima di confrontare le applicazioni
Non scegliere un’applicazione in base alle funzionalità e trattare la licenza dichiarata come una nota a piè di pagina. Leggi il testo applicabile all’opera che utilizzerai, in particolare le disposizioni relative a modifica, riproduzione, distribuzione, avvisi, brevetti e marchi.
Per esempio, la Apache License 2.0 include condizioni esplicite per la riproduzione e distribuzione di copie o opere derivate. Queste includono la fornitura di una copia della licenza, l’indicazione dei file modificati, il mantenimento degli avvisi pertinenti e la conservazione delle attribuzioni applicabili del file NOTICE. Tali requisiti sono legati alla riproduzione e alla distribuzione, quindi una valutazione accurata dipende dal fatto che il modello di fornitura proposto includa tali attività.
Le etichette delle licenze non sostituiscono l’analisi di una combinazione pianificata. Le FAQ GNU GPL descrivono la compatibilità tra licenze in termini di possibilità, secondo le licenze pertinenti, di effettuare la combinazione prevista, e osservano che la forma della combinazione può essere rilevante. Quando la tua offerta combina componenti in un modo non chiaramente documentato, questo è un motivo per fermarsi anziché indovinare.
- Identifica l’opera coperta: l’applicazione, un plugin, una libreria, un’immagine container o un altro artefatto.
- Identifica le tue azioni: eseguire, modificare, copiare, distribuire, pacchettizzare, fornire a un cliente o rendere accessibile da remoto.
- Leggi condizioni ed eccezioni nel testo completo della licenza, non soltanto in un riepilogo.
- Elenca gli avvisi richiesti, le offerte di codice sorgente o le indicazioni di modifica che potrebbero applicarsi al tuo modello.
- Segnala combinazioni di componenti incerte per una revisione specialistica.
Verifica separatamente dipendenze, plugin, modelli, font e risorse incluse
Un file di licenza dell’applicazione principale potrebbe non risolvere i diritti relativi a tutto ciò che raggiunge gli utenti o viene incluso nella build. Le linee guida sulle licenze di Apache, per esempio, riconoscono che opere di terze parti possono essere incluse in un prodotto di progetto e che il testo della loro licenza può comparire nei file LICENSE o NOTICE oppure essere disponibile separatamente.
Crea un inventario di ciò che viene effettivamente distribuito, non soltanto di ciò che appare alla radice del repository. Includi dipendenze di runtime, dipendenze di build incluse in un artefatto, plugin opzionali che abiliti, temi, font, set di dati, file di modello e altre risorse incluse. Non presumere che tutti questi elementi abbiano gli stessi termini dell’applicazione principale.
SPDX è utile come vocabolario per la documentazione e come formato SBOM. I suoi concetti di relazione includono dipendenze, manifesti delle dipendenze, dipendenze di build, dipendenze di sviluppo e dipendenze di runtime. Non ti serve un inventario automatizzato perfetto prima di prendere una decisione, ma ti servono prove sufficienti per identificare i componenti che influenzano materialmente l’uso previsto.
- Crea una riga per ogni dipendenza materiale o elemento incluso.
- Registra nome del componente, versione, fonte, prova della licenza e modalità con cui entra nello stack.
- Distingui gli elementi di runtime da quelli solo di build e solo di sviluppo.
- Verifica plugin ed estensioni abilitati separatamente dalle opzioni non utilizzate.
- Cerca avvisi inclusi, testi di licenza e requisiti di attribuzione.
- Considera i componenti sconosciuti o personalizzati come elementi bloccanti se saranno distribuiti, modificati o esposti ai clienti.
Mantieni separate le decisioni su marchi, branding e domini
Una licenza software non è un’autorizzazione generale a usare nomi, loghi o branding del progetto in qualsiasi modo. L’analisi dei marchi ha uno scopo diverso: evitare confusione riguardo a origine, affiliazione o approvazione.
La policy di Apache illustra questa separazione. Identifica nomi di progetti, nomi di prodotti e loghi come marchi, mentre il software stesso è distribuito secondo i termini della relativa licenza software. Per i progetti Apache in particolare, le opere derivate non dovrebbero usare nomi di progetto o loghi confondibilmente simili, e l’uso confondibile di marchi Apache nei nomi di dominio richiede un’approvazione scritta.
Utilizza la policy sui marchi del progetto, quando disponibile. Se inserirai il nome dell’applicazione in un’offerta per clienti, modificherai un logo, pubblicherai un fork con un brand o registrerai un dominio correlato, aggiungi tale piano al registro delle evidenze e chiedi consulenza quando la policy non lo disciplina chiaramente.
- Il servizio rivolto al pubblico userà il nome o il logo del progetto?
- Descriverai il servizio come ufficiale, affiliato o approvato?
- Un fork modificato manterrà, sostituirà o integrerà il branding esistente?
- Il dominio pianificato contiene il nome del progetto o dell’organizzazione?
- Il progetto pubblica una policy sui marchi o linee guida sull’uso del brand?
- La presentazione prevista potrebbe generare confusione negli utenti?
Comprendi con precisione le questioni relative ai servizi di rete e alla divulgazione del codice sorgente
Non presumere che rendere software disponibile tramite una rete abbia sempre lo stesso effetto della distribuzione di una copia. La GPLv3 afferma che la mera interazione con un utente attraverso una rete informatica, senza trasferimento di una copia, non costituisce di per sé “conveying” ai sensi di quel testo di licenza.
AGPLv3 contiene una disposizione condizionale diversa per una versione modificata che supporta l’interazione remota via rete. La sezione 13 richiede al modificatore di offrire agli utenti remoti l’opportunità di ricevere il Codice Sorgente Corrispondente di tale versione modificata. Questo non è un motivo per fare affermazioni generalizzate su ogni deployment ospitato; è un motivo per identificare la licenza esatta, verificare se hai modificato il programma coperto e stabilire se esso supporta l’interazione remota.
Se il tuo servizio include più componenti, analizza la licenza del componente pertinente e la natura dell’integrazione. Le FAQ GNU GPL osservano che il confine tra programmi separati e un unico programma combinato è in definitiva una questione legale. Un’architettura non ovvia non è il luogo adatto per una conclusione sommaria sulla conformità.
- Identifica se un componente accessibile da remoto è soggetto a termini con disposizioni sull’interazione di rete.
- Registra se il tuo team ha modificato tale componente e dove risiedono le modifiche.
- Determina se gli utenti ricevono una copia, interagiscono soltanto con un servizio oppure entrambe le cose.
- Documenta come verrebbero forniti accesso al sorgente, avvisi e registri delle modifiche, se richiesto.
- Sottoponi a valutazione le combinazioni incerte, i fork e gli obblighi di divulgazione del sorgente prima del lancio.
Crea un registro delle evidenze prima del deployment
Un registro delle evidenze conciso trasforma la due diligence sulle licenze in un controllo operativo. Dovrebbe consentire a un’altra persona di comprendere che cosa è stato esaminato, da dove provengono le prove, che cosa l’organizzazione intende fare e che cosa rimane irrisolto.
Conserva il registro insieme alla documentazione del deployment e aggiornalo quando cambi la versione dell’applicazione, attivi un nuovo plugin, modifichi il codice, cambi un’immagine, aggiungi un modello di consegna al cliente o modifichi il branding pubblico. È più utile di una dichiarazione una tantum di sì o no, perché gli stack self-hosted evolvono.
Usa identificatori standard e informazioni SBOM quando disponibili, ma non consentire a un identificatore noto di sostituire l’esame del testo applicabile, degli avvisi e del modello di fornitura.
- Nome dell’applicazione o del componente.
- Versione, release, riferimento all’immagine o commit esaminato.
- URL della fonte e posizione delle prove della licenza.
- Identificatore della licenza dichiarata e collegamento al testo completo.
- Osservazioni su copyright, NOTICE e attribuzioni.
- Note su dipendenze e relazioni, inclusi elementi di runtime e build.
- Modifiche effettuate, pianificate o ereditate.
- Piano di distribuzione, consegna al cliente e servizio remoto. Piano relativo a marchio, logo e dominio. Questioni aperte, responsabile, decisione di escalation e data di revisione.
Domande frequenti
L’hosting autonomo di un’applicazione significa che possiamo usarla commercialmente?
Non di per sé. Una licenza open source conforme all’OSI non può limitare l’uso in un particolare settore di attività, incluso l’uso aziendale. Tuttavia, devi comunque verificare che l’applicazione esatta e i suoi componenti siano soggetti ai termini dichiarati e valutare separatamente distribuzione, modifiche, avvisi, marchi e il tuo piano di deployment specifico.
Un repository Git pubblico è una prova sufficiente che un’applicazione sia open source?
No. L’OSI spiega che l’open source significa più del semplice accesso al codice sorgente: i termini di distribuzione devono soddisfare l’Open Source Definition. Esamina le prove autorevoli della licenza per la versione che intendi utilizzare.
Dobbiamo esaminare le dipendenze se l’applicazione ha un file LICENSE?
Sì. Le opere di terze parti possono avere testi di licenza o avvisi separati. Fai l’inventario delle dipendenze di runtime rilevanti, degli output di build distribuiti, dei plugin, dei modelli, dei font, dei temi e delle risorse incluse, quindi registra le prove della loro licenza e il loro ruolo nello stack distribuito.
Ospitare software GPL per gli utenti conta automaticamente come distribuzione?
La GPLv3 afferma che la mera interazione via rete senza trasferimento di una copia non costituisce conveying. Il risultato preciso dipende dalla licenza applicabile, dal componente e da ciò che fornisci effettivamente. Non generalizzare questa affermazione a ogni licenza o architettura.
Che cosa cambia con AGPLv3 per un servizio ospitato?
La sezione 13 di AGPLv3 include un obbligo condizionale per una versione modificata che supporta l’interazione remota via rete: agli utenti remoti deve essere offerto in modo evidente l’accesso al Codice Sorgente Corrispondente della versione modificata. Identifica se hai modificato il programma coperto e ottieni una consulenza qualificata se l’applicazione dell’obbligo non è chiara.
Possiamo usare il nome e il logo del progetto nel nostro servizio ospitato?
È una questione di marchi e branding, separata dalla licenza software. Esamina la policy sui marchi del progetto, specialmente prima di usare un logo, commercializzare un fork modificato, rivendicare un’affiliazione o registrare un dominio correlato.
Fonti e approfondimenti
- 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