Pubblicare codice senza licenza è uno degli errori più comuni di chi apre il primo repository. In assenza di licenza il codice resta protetto dal diritto d'autore in modo pieno: chiunque può leggerlo, ma nessuno può legittimamente copiarlo, modificarlo o ridistribuirlo. Il risultato è un progetto che sembra aperto ma non lo è. Scegliere una licenza non richiede uno studio giuridico: basta rispondere con onestà ad alcune domande. Questa è la procedura che seguo quando aiuto qualcuno ad avviare un progetto.
Domanda 1: cosa voglio che succeda alle versioni modificate?
È la domanda decisiva, perché separa le licenze permissive da quelle copyleft.
- Mi va bene che qualcuno lo includa in un prodotto chiuso. Allora una licenza permissiva è la scelta naturale: MIT, BSD o Apache 2.0.
- Voglio che chi distribuisce versioni modificate le condivida. Allora serve un copyleft: GPL per i programmi, LGPL o MPL per le librerie.
Non c'è una risposta giusta in assoluto. Molte librerie di base sono permissive perché il loro valore sta nella diffusione; molte applicazioni complete sono GPL perché gli autori vogliono che restino libere.
Domanda 2: il software girerà soprattutto su server?
Se il progetto è un'applicazione web, un'API o un servizio, la GPL non ha quasi effetto: il software non viene distribuito agli utenti, quindi gli obblighi non scattano. Se si vuole un copyleft anche in questo scenario, la scelta coerente è l'AGPLv3. Va considerato che alcune aziende evitano l'AGPL per politica interna, e questo può ridurre l'adozione.
Domanda 3: ci sono brevetti in gioco?
Se al progetto contribuiranno aziende, o se il dominio tecnico è ricco di brevetti (codifica multimediale, crittografia, reti), conviene una licenza con una concessione esplicita dei brevetti:
- tra le permissive, Apache 2.0;
- tra le copyleft, GPLv3, LGPLv3, AGPLv3 o MPL 2.0.
La MIT e la BSD non parlano di brevetti in modo esplicito. Per un piccolo strumento personale non è un problema; per un progetto con contributori aziendali può esserlo.
Domanda 4: con cosa deve convivere il codice?
Le dipendenze vincolano la scelta. Se il progetto usa una libreria GPL in modo stretto, l'insieme distribuito sarà GPL comunque. Se il progetto vuole essere incluso in un ecosistema che usa una licenza specifica, adottare la stessa licenza riduce gli attriti. Qualche esempio:
- un plugin per un'applicazione GPL tende naturalmente alla GPL;
- una libreria per un ecosistema in cui prevale la doppia licenza MIT e Apache 2.0 trae vantaggio dall'adottarla;
- un modulo per il kernel Linux deve essere compatibile con la GPLv2.
Domanda 5: che comunità mi aspetto?
La licenza manda un segnale. Una licenza permissiva attira contributi aziendali e uso commerciale. Una licenza copyleft rassicura chi teme che il proprio lavoro venga chiuso da altri. Pensare a chi si vuole coinvolgere aiuta a scegliere.
Una tabella riassuntiva
| Situazione | Licenza consigliata |
|---|---|
| Piccola utility, massima libertà | MIT |
| Libreria con contributi aziendali | Apache 2.0 |
| Libreria che deve restare libera ma usabile ovunque | LGPLv3 o MPL 2.0 |
| Applicazione desktop che deve restare libera | GPLv3 |
| Applicazione web che deve restare libera | AGPLv3 |
| Documentazione | CC BY 4.0 o CC BY-SA 4.0 |
Errori da evitare
- Scrivere una licenza propria. Una licenza inventata, anche se ben intenzionata, crea incertezza e scoraggia l'adozione. Le licenze consolidate sono state lette da molti giuristi e sono riconosciute dagli strumenti automatici.
- Modificare il testo di una licenza esistente. Aggiungere clausole come «non per uso militare» trasforma la licenza in qualcosa che non è più open source e la rende incompatibile con molte altre.
- Scegliere una licenza «non commerciale». Non è open source ed esclude molti utilizzi legittimi.
- Dimenticare i contributori. Se più persone hanno scritto codice, cambiare licenza in seguito richiede il loro consenso o un meccanismo previsto in anticipo.
Come applicarla concretamente
Una volta scelta la licenza:
- crea un file
LICENSEnella radice del repository con il testo integrale e non modificato; - compila correttamente anno e titolare del copyright dove richiesto;
- aggiungi in testa a ogni file sorgente un identificatore standard, ad esempio:
# SPDX-License-Identifier: MIT
- indica la licenza nel README e nei metadati del pacchetto (ad esempio
package.json,pyproject.toml,Cargo.toml); - se usi la Apache 2.0, valuta se creare un file
NOTICE.
Cambiare idea in futuro
Passare da una licenza permissiva a una copyleft, o viceversa, è possibile ma non banale: servono i diritti su tutto il codice o il consenso dei contributori. Le versioni già pubblicate restano disponibili con la licenza originale. Per questo vale la pena dedicare mezz'ora alla scelta fin dal primo commit.
In sintesi
- Senza licenza il codice non è riutilizzabile, anche se è pubblico.
- La prima domanda è se le versioni modificate devono restare libere: permissivo o copyleft.
- Per il software in rete serve l'AGPL; per i brevetti conviene Apache 2.0 o le licenze GPL versione 3.
- Le dipendenze e l'ecosistema possono imporre la scelta.
- Usa una licenza esistente senza modifiche e dichiarala con identificatori standard in ogni file.
