Licenze open source per startup: quale scegliere e i rischi legali

Condizioni di MIT, Apache 2.0, GPL, LGPL e AGPL verificate sui testi e sulle FAQ ufficiali di OSI, Apache Software Foundation e GNU, la SSPL sul testo di MongoDB e sulla posizione dell'OSI, i casi Elastic e Redis sui loro annunci ufficiali, il 12 novembre 2026. Le licenze e le scelte delle aziende cambiano: controlla sempre il testo della versione che usi.

Open source non significa "senza regole"

Usare codice open source nella tua startup è quasi inevitabile: framework, librerie e database ne sono pieni. Il rischio legale non nasce dall'uso in sé, ma dall'abbinare la licenza sbagliata al modo in cui distribuisci o offri il tuo prodotto. Ogni componente ha una licenza con condizioni precise, e il tuo obbligo dipende dalla licenza, da come usi il componente e da se lo modifichi. Questa non è una questione solo da avvocati: fare l'inventario delle licenze è una due diligence minima che ogni CTO dovrebbe saper presentare. Ne parliamo anche nella guida sulla due diligence startup.

Le licenze permissive: MIT e Apache 2.0

MIT

Il testo ufficiale (pubblicato dall'OSI) permette di usare, copiare, modificare, unire, pubblicare, distribuire, sublicenziare e vendere il software, gratuitamente. L'unica condizione è che l'avviso di copyright e l'avviso di permesso siano inclusi in tutte le copie o parti sostanziali del software. Il software è fornito "così com'è", senza alcuna garanzia. Puoi quindi includere codice MIT in un prodotto proprietario senza rilasciare il tuo codice.

Apache License 2.0

È permissiva, ma con più tutele e più adempimenti. Ogni contributore concede una licenza sui brevetti, mondiale, gratuita e non esclusiva, limitata ai brevetti violati dal suo contributo; se però avvii una causa sostenendo che l'opera o un contributo violi un brevetto, le licenze sui brevetti che hai ricevuto per quell'opera terminano alla data in cui la causa è presentata. Per ridistribuire devi: dare ai destinatari una copia della licenza, riportare avvisi ben visibili nei file modificati, mantenere gli avvisi di copyright, brevetto, marchio e attribuzione, e includere il contenuto dell'eventuale file NOTICE. Puoi aggiungere i tuoi termini per le tue modifiche, purché rispetti le condizioni della licenza per l'opera originale.

Le licenze copyleft: GPL, LGPL e AGPL

GPL

Le FAQ ufficiali di GNU sono chiare su due punti. Primo: non puoi incorporare software coperto da GPL in un sistema proprietario; se colleghi un programma GPL al tuo codice per costruire un prodotto, quel programma va rilasciato con una licenza compatibile con la GPL. Secondo: la GPL permette di modificare un programma e usarlo senza mai distribuirlo ad altri; fare girare una versione modificata sul tuo server, di per sé, non obbliga a pubblicare il codice. Anche l'uso interno a un'organizzazione non è distribuzione, mentre dare copie a contractor esterni per uso fuori sede lo è. Questo vale per le GPL v2 e v3 secondo le FAQ.

AGPL

L'AGPL v3 chiude la "scappatoia del server". La sezione 13 dice che, se modifichi il programma e la tua versione permette agli utenti di interagire con essa in rete, devi offrire a tutti quegli utenti la possibilità di ricevere il codice sorgente corrispondente della tua versione. Le FAQ GNU confermano che una società che fa girare su un sito web una versione modificata di un programma AGPL deve rilasciarne il sorgente. Per un SaaS questo è il punto critico.

LGPL

È il copyleft "debole". Secondo la LGPL v3 (sezione 4) puoi distribuire un'opera combinata, cioè la tua applicazione collegata alla libreria, con i termini che preferisci, purché non limitino la modifica delle parti di libreria né il reverse engineering per il debug di quelle modifiche. Devi però includere un avviso che indica l'uso della libreria, fornire copia delle licenze GPL e LGPL, e permettere all'utente di ricombinare o ricollegare l'applicazione con una versione modificata della libreria (oppure usare un meccanismo di libreria condivisa). Per questo il tipo di collegamento va deciso con il team tecnico fin dall'inizio.

SSPL: "source available", non open source

La Server Side Public License usata da MongoDB prevede, alla sezione 13, che chi offre il programma a terzi come servizio debba rendere scaricabile gratuitamente il "Service Source Code": il codice del programma e quello di tutti i programmi usati per erogare il servizio, inclusi, tra gli altri, software di gestione, interfacce utente, API, automazione, monitoraggio, backup, storage e hosting. È più ampio dell'AGPL. L'OSI, con una dichiarazione del 19 gennaio 2021, ha affermato che la SSPL non è una licenza open source: chi la usa non dovrebbe dire che il suo software è open source.

Cosa è cambiato per Elastic e Redis

Molte guide, compresa una versione precedente di questa pagina, presentano Elastic e Redis come aziende che "hanno scelto l'AGPL per contrastare i cloud provider". I loro annunci ufficiali raccontano altro. Elastic ha annunciato il 29 agosto 2024 che avrebbe aggiunto l'AGPL come ulteriore opzione di licenza accanto a ELv2 e SSPL per Elasticsearch e Kibana, così da poterli di nuovo chiamare open source. Redis ha annunciato il 1° maggio 2025 l'AGPLv3 come ulteriore opzione a partire da Redis 8, dopo il passaggio del marzo 2024 a licenze source-available con la SSPL. In entrambi i casi l'AGPL è tornata come licenza approvata dall'OSI; la lezione per te è che le scelte di licenza delle società cambiano nel tempo e vanno controllate sulla versione che usi.

Dual licensing e contributi esterni

Con il dual licensing offri lo stesso codice sotto una licenza copyleft e sotto una licenza commerciale. Le FAQ GNU spiegano il meccanismo: chi detiene il copyright può rilasciare il proprio codice con più licenze non esclusive in momenti diversi; solo il titolare del copyright può farlo. Se accetti contributi da altri, devi quindi ottenere i diritti necessari, di solito tramite un accordo di contributo (CLA) che cede il diritto o concede una licenza sufficientemente ampia. Senza questo passaggio, il codice di terzi non puoi rilicenziarlo. Sul tema dei diritti d'autore dei collaboratori vedi proprietà intellettuale startup.

Come gestire il rischio, passo per passo

1. Elenca tutte le dipendenze dirette e indirette e la loro licenza, anche con uno strumento automatico di scansione (esistono prodotti commerciali e open source: scegli in base al tuo stack).
2. Per ogni componente copyleft, chiediti: lo distribuisco ai clienti? Lo modifico? Lo offro come servizio in rete? Le risposte decidono l'obbligo.
3. Scrivi una policy interna: licenze ammesse, licenze da approvare caso per caso, licenze vietate nel prodotto.
4. Conserva gli avvisi di copyright e le licenze richieste (MIT, Apache) in un file di attribuzioni distribuito con il prodotto.
5. Tieni traccia delle modifiche ai file di terzi: l'Apache 2.0 le richiede in modo esplicito.
6. Prima di un round prepara il censimento nella data room.

Esempio: tre scelte, tre obblighi

Ipotesi dichiarate: una startup SaaS usa una libreria MIT, una libreria Apache 2.0 e un database con licenza AGPL, tutti senza modifiche tranne un file della libreria Apache. La libreria MIT richiede di conservare l'avviso di copyright. Quella Apache richiede copia della licenza e un avviso nel file modificato. Il database AGPL, se lo usi senza modificarlo e solo come servizio interno al tuo backend, pone un problema diverso: l'obbligo di offrire il sorgente riguarda la versione modificata offerta agli utenti in rete, ma il confine tra uso interno e interazione degli utenti con il programma va valutato da un legale. Se invece avessi modificato il database e lo esponessi agli utenti, scatterebbe l'obbligo della sezione 13.

Errori comuni

• Credere che "open source" voglia dire "uso libero senza condizioni".
• Non distinguere tra uso interno, distribuzione e offerta in rete.
• Copiare una dipendenza GPL in un prodotto distribuito ai clienti senza rilasciare il codice combinato.
• Dimenticare gli avvisi richiesti da MIT e Apache nelle build distribuite.
• Presentare come open source un codice sotto licenza SSPL o simili.
• Accettare contributi esterni senza un accordo che permetta di rilicenziare il codice.

A chi conviene cosa

Se vuoi la massima adozione del tuo codice, MIT o Apache 2.0 sono le scelte più semplici; l'Apache offre la protezione brevettuale descritta sopra. Se vuoi che chi offre il tuo software come servizio debba condividere le modifiche, l'AGPL è la licenza approvata dall'OSI che va in quella direzione; la SSPL va oltre ma non è open source. Se usi librerie altrui nel tuo prodotto commerciale, privilegia componenti con licenze permissive e valuta caso per caso LGPL e AGPL. Per il quadro più ampio leggi proprietà intellettuale startup e contratti essenziali startup.

Questa pagina ha scopo informativo e non sostituisce la consulenza di un avvocato esperto di licenze software.

Fonti

• OSI: licenza MIT^[1]
• Apache Software Foundation: Apache License 2.0^[2]
• GNU: FAQ sulla GPL^[3]
• GNU: testo della AGPL v3^[4]
• GNU: testo della LGPL v3^[5]
• MongoDB: Server Side Public License^[6]
• OSI: The SSPL is Not an Open Source License (19 gennaio 2021)^[7]
• Elastic: annuncio AGPL per Elasticsearch e Kibana (29 agosto 2024)^[8]
• Redis: annuncio AGPLv3 (1° maggio 2025)^[9]