Questa traduzione potrebbe non essere aggiornata con le modifiche effettuate dopo il 2019-10-13 alla versione originale inglese.
È disponibile un elenco delle modifiche. Per informazioni su come gestire e inviare traduzioni delle nostre pagine web consultate la Guida alle traduzioni.
Come scegliere una licenza per i propri progetti
This page is maintained by the Free Software Foundation's Licensing and Compliance Lab. You can support our efforts by making a donation to the FSF. Have a question not answered here? Check out some of our other licensing resources or contact the Compliance Lab at licensing@fsf.org.
Per vedere se una certa licenza è libera o meno, vedete il nostro elenco di licenze e la definizione di software libero.
Introduzione
Spesso gli sviluppatori ci chiedono quale licenza consigliamo per i loro progetti. Abbiamo già pubblicato dei testi su questo argomento, ma l'informazione è sparsa tra saggi, domande ricorrenti e commenti sulle licenze. Questo articolo raccoglie tutte quelle informazioni in un singolo testo allo scopo di facilitarne la consultazione.
Questi consigli sono per progetti designati a svolgere compiti pratici, come programmi e documentazione. Opere artistiche e lavori che esprimono un punto di vista soggettivo costituiscono una questione separata; il Progetto GNU non pone alcuna particolare condizione di rilascio se non rendere possibile la loro esecuzione senza l'uso di software non libero (in particolare, senza DRM). Potreste comunque decidere di seguire questi consigli per prodotti artistici che sono accompagnati da un programma.
Questi consigli si applicano al caso in cui voi dobbiate scegliere una licenza per un progetto da voi creato, sia una modifica ad un progetto esistente che un progetto originale. Non affrontano il problema che sorge dal combinare materiale esistente e rilasciato sotto licenze diverse. Se cercate informazioni a tal fine, per favore controllate le nostre domande ricorrenti sulla GPL.
Una volta finite di leggere le nostre raccomandazioni, se avete bisogno di ulteriore aiuto potete scrivere (in inglese, se possibile) a <licensing@gnu.org>. Potrebbero volerci delle settimane perché il team delle licenze vi risponda; se non ricevete risposta entro un mese, inviate un sollecito sempre allo stesso indirizzo.
Contribuire ad un progetto esistente
Quando contribuite ad un progetto esistente, è consigliato rilasciare le vostre versioni modificate sotto la stessa licenza del progetto originale. È bene cooperare con i manutentori del progetto, e rilasciare modifiche sotto un'altra licenza spesso rende la cooperazione molto difficile. Dovreste farlo solo in quei casi particolari in cui è fortemente giustificabile.
Un caso in cui usare una licenza diversa è giustificabile è quando vengono effettuate modifiche sostanziali ad un progetto rilasciato sotto una licenza non copyleft. Se la versione da voi creata è notevolmente più utile rispetto all'originale, è comprensibile rilasciarla sotto una licenza copyleft, per gli stessi motivi per cui consigliamo il copyleft. Se vi trovate in questa situazione, vi consigliamo di seguire le raccomandazioni sotto indicate per applicare una licenza ad un nuovo progetto.
Se scegliete di rilasciare le vostre modifiche sotto una licenza diversa dall'originale, dovete essere certi che la licenza originale permetta l'uso del materiale sotto la licenza da voi scelta. In nome dell'onestà, marcate esplicitamente quali parti del vostro progetto sono state rilasciate sotto quale licenza.
Software
Consigliamo licenze diverse per progetti diversi, a seconda dello scopo del software. In generale, consigliamo di usare la licenza copyleft più forte che non interferisca con tale scopo. Il nostro saggio “Cos'è il copyleft?” illustra il concetto di copyleft in dettaglio e spiega perché esso spesso rappresenti la migliore strategia di licenza.
Per la maggior parte dei programmi, consigliamo l'utilizzo della versione più recente della GNU General Public License (GPL) per i vostri progetti. È una licenza copyleft forte che include numerose salvaguardie per le libertà degli utenti, appropriata per ogni tipo di software. Vi consigliamo di dare il permesso di usare anche le future versioni, cioè, in altre parole, di indicare che il vostro programma è coperto da licenza GPL versione 3 o successiva.
Sono disponibili ulteriori consigli su come rilasciare un programma con licenza GNU GPL.
Ecco alcune eccezioni, casi in cui è meglio usare altre licenze anziché la GNU GPL.
Piccoli programmi
Usare il copyleft per un programma di piccole dimensioni non è sempre la scelta migliore. Noi poniamo 300 linee di codice come limite: quando un programma è più corto, i benefici offerti dal copyleft diventano troppo piccoli per giustificare l'inconvenienza di accertarsi che il software sia sempre distribuito con una copia della licenza.
Per quei programmi, consigliamo la Licenza Apache 2.0, una licenza non copyleft che ha il beneficio di impedire a contributori e distributori di sporgere denuncia per aver infranto dei brevetti. Questo non rende il software immune alle minacce dei brevetti (una licenza non ha questo potere), ma previene coloro che detengono i brevetti dal creare “esche” che consistono nel rilasciare il software sotto termini liberi a condizione di accettare dei termini non liberi nella licenza del brevetto.
Tra le licenze permissive, Apache 2.0 è la migliore; se avete deciso per un qualsiasi motivo di usare una licenza permissiva, è questa che raccomandiamo di usare.
Librerie
Per le librerie, distinguiamo tre casi.
Alcune librerie implementano standard liberi che competono con standard non liberi, come Ogg Vorbis (che compete con audio MP3) e WebM (che compete con video MPEG-4). Per questi progetti, la diffusione del codice è più importante per l'avanzamento della causa del software libero che l'uso di una licenza copyleft.
In queste situazioni particolari, raccomandiamo la Licenza Apache 2.0.
Per tutte le altre librerie, raccomandiamo una licenza copyleft. Se gli sviluppatori stanno già utilizzando una libreria alternativa rilasciata sotto una licenza non libera o permissiva, raccomandiamo di usare la GNU Lesser General Public License (LGPL).
A differenza del primo caso, dove la libreria implementa uno standard eticamente superiore, in questo l'adozione senza un forte motivo non serve a compiere alcun obiettivo particolare, motivo per il quale non c'è alcun motivo valido per evitare il copyleft. Ma, se chiedete agli utenti della vostra libreria di rilasciare i propri programmi sotto copyleft, questi passeranno semplicemente ad una delle alternative disponibili, senza avanzare la nostra causa. La Lesser GPL è stata creata proprio per fare da ponte tra questi casi, permettendo agli sviluppatori di software proprietario di usare la libreria senza però privare gli utenti delle libertà relative al codice stesso della libreria.
Per librerie che offrono funzionalità specifiche e che non hanno competizione non libera o non copyleft, raccomandiamo l'uso della GNU GPL. Per sapere perché, si prega di leggere “Perché evitare la Lesser GPL per la vostra prossima libreria”.
Software per server
Se è probabile che altri creino versioni migliorate del vostro programma da eseguire sui server senza distribuirle ad altri, e siete preoccupati che questo possa svantaggiare la vostra versione, raccomandiamo l'adozione della GNU Affero General Public License (AGPL). I termini della AGPL sono identici a quelli della GPL; l'unica differenza è che offre una condizione aggiuntiva che permette agli utenti di ottenere il codice sorgente di un programma eseguito tramite la rete.
Il requisito della AGPL non è sufficiente per risolvere il problema degli utenti posto dall'affidamento dei propri dati a server esterni. Per esempio, non impedirà ai servizi come surrogati del software (SaaSS) di negare le libertà dei propri utenti, ma fortunatamente la maggior parte dei server non presentano questo problema. Per saperne di più, si prega di leggere “Why the Affero GPL”.
Documentazione
Consigliamo la GNU Free Documentation License (GFDL) per tutorial, manuali di riferimento ed altre opere di documentazione di grande dimensione. È una licenza con copyleft forte pensata per lavori didattici, scritta inizialmente per manuali di software, che include termini che affrontano specificamente quei problemi che sorgono quando il progetto viene distribuito o modificato.
Per piccole opere di documentazione secondaria, come tabelle riassuntive dei comandi, è meglio usare la licenza GNU all-permissive, visto che una copia della GFDL difficilmente troverà posto nella tabella. Non usate CC-BY, visto che è incompatibile con la GFDL.
Per pagine di manuale da aprire con il comando "man", raccomandiamo la GFDL se la pagina è lunga e la licenza GNU all-permissive se corta.
A volte la documentazione include codice sorgente. Per esempio, un manuale per un linguaggio di programmazione potrebbe includere esempi da seguire. In tal caso, dovreste sia includere questi sotto i termini della FDL che rilasciarli sotto un'altra licenza appropriata per il software. Questo permette di usare il codice in altri progetti. Consigliamo di rilasciare piccoli frammenti di codice nel pubblico dominio tramite la licenza CC0 e di distribuire porzioni più grandi sotto la stessa licenza usata dal progetto originale.
Altri dati usati dai programmi
Questa sezione discute tutti quelle parti aggiuntive che potrebbero essere incluse nei vostri programmi, come ad esempio icone, grafica, font e dati geografici. Potreste anche seguire queste linee guida per contenuto di tipo artistico, anche se non vi criticheremo se non lo doveste fare.
Se state creando queste opere come parte di un progetto software, di solito consigliamo di rilasciarle sotto la stessa licenza del software. Non ci dovrebbe essere alcun problema con le licenze da noi consigliate: GPLv3, LGPLv3, AGPLv3, e GPLv2 possono essere tutte applicate ad un qualsiasi tipo di opera - non solo software - che possa essere soggetta a copyright e che possa essere modificata in un determinato modo. Usare la stessa licenza del software renderà più facile la distribuzione ed eviterà potenziali dubbi circa la compatibilità. Usare una licenza diversa ma libera potrebbe essere appropriato solo se questa offre un vantaggio pratico specifico, come miglior cooperazione con altri progetti liberi.
Se le vostre opere non vengono create per essere usate con un particolare progetto software o se non sarebbe appropriato usare la stessa licenza del progetto, l'unica cosa che vi possiamo consigliare è di scegliere una licenza copyleft appropriata al vostro lavoro. Abbiamo elencato alcune di queste nella nostra lista delle licenze. Se nessuna licenza vi sembra particolarmente appropriata, la Creative Commons Attribution-ShareAlike è una licenza copyleft che può essere usata per diversi tipi di opere.