Open source non significa "senza diritti"
Usare codice open source nella tua startup è quasi inevitabile. Il rischio legale non viene dall'uso in sé, ma dall'uso della licenza sbagliata nel contesto sbagliato. Un singolo componente GPL nella codebase di un prodotto commerciale proprietario può, in teoria, obbligare a rilasciare tutto il codice sorgente. Capire le licenze che stai usando non è roba da avvocati: è due diligence minima che ogni CTO dovrebbe fare.
Le licenze permissive: MIT e Apache 2.0
MIT License
La più semplice e diffusa. Permette qualsiasi uso (commerciale, modifica, distribuzione) con un'unica condizione: mantenere l'avviso di copyright e la licenza. Zero copyleft. Puoi includere codice MIT in un prodotto proprietario senza dover rilasciare il tuo codice. Ideale per librerie che vuoi adottare liberamente o per il tuo codice che vuoi rendere maximally adottabile.
Apache License 2.0
Simile alla MIT ma con due elementi aggiuntivi: un grant esplicito di licenza sui brevetti dei contributori (ti protegge da future rivendicazioni brevettuali dei contributori del progetto) e un obbligo di indicare le modifiche apportate ai file originali. Preferita da aziende (Google, Apache Foundation) proprio per la protezione brevettuale. Compatibile con la maggior parte degli usi commerciali.
Le licenze copyleft: GPL e varianti
GPL (GNU General Public License)
Il copyleft "forte": se distribuisci software che include o è derivato da codice GPL, devi rilasciare il codice sorgente dell'intero software combinato con la stessa licenza GPL. Per un SaaS che non distribuisce il binario (lo usi solo sul server), la GPL v2 non si attiva — ma la AGPL sì.
AGPL (Affero GPL)
Estende il copyleft anche all'uso via rete: se dai accesso a un'applicazione AGPL via web, devi rilasciare il codice sorgente a chi la usa. È usata deliberatamente da molte startup (MongoDB, Redis, Elasticsearch in passato) per impedire ai cloud provider di offrire il loro software come servizio senza contribuire.
LGPL
Copyleft "debole": puoi usare una libreria LGPL in un'applicazione proprietaria a patto di consentire agli utenti di sostituire la libreria con una versione modificata. Meno restrittiva della GPL, ma richiede attenzione al linking dinamico vs statico.
- Vuoi massima adozione del tuo codice: MIT o Apache 2.0
- Vuoi protezione brevettuale inclusa: Apache 2.0
- Vuoi impedire l'uso cloud senza contribuire: AGPL o SSPL
- Stai usando una libreria open source in un prodotto commerciale: verifica che sia MIT/Apache/BSD, non GPL/AGPL
- Dual licensing (commerciale + open): richiede che tutti i contributori cedano il copyright alla società
SSPL: la licenza "source available"
La Server Side Public License (usata da MongoDB) è ancora più restrittiva dell'AGPL: chi offre il software come servizio deve rilasciare non solo il codice del software ma anche tutto il codice dell'infrastruttura di servizio (monitoring, deployment, ecc.). Non è considerata open source dalla OSI. Usarla significa proteggersi dai cloud provider ma anche ridurre l'adozione nella community developer.
Dual licensing
Molte startup tech usano il dual licensing: il codice è disponibile sotto licenza copyleft (GPL/AGPL) per l'uso open source, e sotto licenza commerciale (a pagamento) per chi vuole integrarlo in prodotti proprietari senza obblighi copyleft. MySQL, Qt e molti altri usano questo modello. Funziona solo se possiedi il copyright su tutto il codice — quindi tutti i contributori devono firmare un Contributor License Agreement (CLA) che cede il copyright alla società.
Impatto sull'investibilità
I VC e gli acquirenti in M&A fanno sempre una license audit in fase di due diligence. Trovare componenti AGPL o GPL nel codice proprietario di un SaaS è un red flag che può bloccare il round o abbassare la valutazione. Strumenti come FOSSA, Black Duck o Snyk automatizzano la scansione delle dipendenze — integrali nella CI/CD pipeline prima che diventi un problema.
Per il quadro IP complessivo leggi proprietà intellettuale startup e contratti essenziali startup.