Cito questo interessante post dal blog di Smashkins: viene riportato un articolo di Brian Behlendorf nel quale vengono elencate e commentate le principali licenze software legato al mondo dell'OpenSource.

da OpenSource and global development di Brian Behlendorf :

Quale licenza?
Scegliere il tipo di licenza che meglio convenga al vostro progetto
potrebbe rivelarsi un'impresa complessa e talvolta poco divertente,
anche se potrà esserlo per il vostro ufficio legale. Esistono rapporti
e siti Web molto dettagliati su quest'argomento; qui farò alcune
considerazoni generali di carattere commerciale sulle varie licenze.
Copyright di tipo BSD
È il copyright usato da Apache e dai sistemi operativi basati su BSD
(FreeBSD, OpenBSD, NetBSD) e si può riassumere così: "Ecco il codice,
fateci quello che volete, non c'interessa; solo, se lo provate e lo
vendete, datacene credito". Di solito il credito viene riscosso in
diverse forme: sulla pubblicità, in un file README, nella
documentazione cartacea, ecc. È stato obiettato che tale copyright
potrebbe non essere scalabile, cioè: chi rilasciasse un software in
bundle che includa 40 differenti moduli open source, tutti basati su
BSD, dovrebbe fornire 40 differenti notizie di copyright. Nella pratica
questo non è mai stato un problema, anzi è stato visto come una forza
positiva per diffondere consapevolezza sull'uso del software Open
Source.
Da un punto di vista commerciale, questa licenza è la migliore quando
s'interviene su di un progetto preesistente, perché non ci si deve
preoccupare di licenze o di restrizioni sull'uso o la ridistribuzione
futuri. È possibile miscelare e adattare questo software al vostro
codice proprietario e rilasciare solo quello che ritenete possa essere
utile al progetto e quindi, di riflesso, a voi. È uno dei motivi per
cui l'abbiamo scelta per il gruppo Apache. A differenza di molti
progetti software gratuiti, Apache fu avviato in gran parte da
webmaster dell'ambito commerciale che cercavano un server Web migliore
per le loro esigenze di business. È probabile che nessuno di noi
mirasse a creare un server commerciale sopra Apache, ma nessuno sapeva
che cosa il futuro avesse in serbo per noi, e limitare le nostre
opzioni fin dall'inizio non sarebbe stato intelligente.
Questo tipo di licenza è l'ideale per promuovere l'uso di un corpus di
codice di riferimento che implementi un protocollo o un servizio
comune. È un altro motivo della sua scelta per il gruppo Apache: molti
di noi volevano che l'HTTP sopravvivesse e diventasse un vero standard
multiparte, e non ci siamo minimamente preoccupati se Microsoft o
Netscape avessero deciso di incorporare nei loro prodotti il nostro
motore HTTP o qualunque altra componente del nostro codice, se solo
ciò avesse contribuito all'intento di mantenere comune l'HTTP.
Un tale grado di apertura presenta i suoi rischi. La licenza non fa
riferimento ad alcun incentivo alle aziende perché diano in cambio le
loro aggiunte al codice del progetto. Si sono in effetti dati casi in
cui alcune aziende hanno sviluppato intorno al progetto delle
tecnologie che ci sarebbe piaciuto vedere a loro volta offerte al
progetto stesso. Ma se avessimo avuto una licenza che prescriveva che
il codice aggiuntivo dovesse essere reso disponibile al progetto
d'origine, si può pensare che quelle aggiunte non sarebbero nemmeno
state fatte.
Tutto questo per dire che, strategicamente parlando, il progetto deve
mantenere una spinta sufficiente e che i partecipanti realizzano un
valore maggiore contribuendo con il loro codice al progetto: perfino il
codice che avrebbe avuto un valore se mantenuto proprietario. È un
equilibrio complicato da mantenere, specialmente quando un'azienda
decide di aumentare considerevolmente il codice scritto su un progetto
derivativo, e comincia a dubitare se il possibile ritorno valga lo
sforzo del contributo. Insomma, lavoriamo più di tutti gli altri messi
insieme, perché dovremmo spartire? Chi scrive non ha la risposta a
questa domanda. Quello che posso dire è che quell'azienda non ha
probabilmente saputo trovare un modo più persuasivo per ispirare alle
terze parti la voglia di contribuire per raggiungere gli obiettivi di
progettazione più efficacemente.
La licenza pubblica Mozilla
La Mozilla Public License (MPL) è stata sviluppata dal team Mozilla di
Netscape per l'impiego nei loro progetti. Quando fu rilasciata, era la
prima licenza di tipo nuovo dopo molti anni e rispondeva davvero a
molte questioni-chiave ignorate dalle licenze BSD o GNU. Nello spettro
delle licenze software open source è adiacente alla licenza in stile
BSD, con due differenze sostanziali:
Essa prescrive che le modifiche alla "distribuzione" siano rilasciate
sotto lo stesso copyright della MPL, il che la rende di nuovo
disponibile al progetto. "Distribuzione" sono definiti i file così
come vengono distribuiti nel codice sorgente; è importante perché
consente a un'azienda di aggiungere un'interfaccia a una libreria di
codice proprietario senza prescrivere che l'altra libreria di codice
sia pure sottoposta alla MPL, ma solo l'interfaccia. In questo modo, il
software può venir inserito, in grado variabile, entro un ambiente
software commerciale.
La licenza ha numerose clausole a protezione sia del progetto nella sua
interezza sia dei suoi sviluppatori contro questioni di brevetto nel
codice aggiunto che potrebbero insorgere. Prescrive che l'azienda o
l'individuo che contribuisca con codice al progetto rinunci a ogni
possibile pretesa a diritti di brevetto a cui il codice potrebbe dare
adito.
La seconda clausola è importantissima; al momento in cui scrivo,
contiene anche un grave difetto.
Preoccuparsi delle questioni di brevetto è Cosa Buona E Giusta. C'è
sempre il rischio che, in perfetta buona fede, un'azienda offra codice
a un progetto e poi, una volta che il codice sia stato completamente
implementato, cerchi di reclamare il pagamento di una qualche
concessione di brevetto per il suo uso. Una simile strategia
commerciale, oltre a essere di pessimo gusto, è un vero passo falso
dal punto di vista delle pubbliche relazioni, ma purtroppo non tutte le
aziende arrivano a capirlo. La seconda clausola, dunque, previene il
caso di qualcuno che fornisca di nascosto del codice ben sapendo che è
brevettato e passibile di causare dei gran mal di testa a tutte le
parti in causa.
Questo non elimina naturalmente l'eventualità che qualcun altro sia
titolare di un brevetto che possa far valere: non esiste strumento
legale che forniscono questo tipo di protezione. Per la verità, io
farei appello all'Ufficio Federale Brevetti e Commercio (U.S. Patent
and Trade Office) perché se ne faccia carico: se ha l'autorità per
definire certe idee e algoritmi come proprietà di un soggetto, dunque
perché non gli si dovrebbe richiedere di fare l'opposto e di
certificare come libero da brevetti il codice che ho presentato,
garantendomi protezione da cause per violazione di brevetto?
Come ho detto prima, tuttavia, la MPL vigente al dicembre 1998 presenta
un difetto. In sostanza, la Sezione 2.2 prescrive (nella sua
definizione di "Contributor
Version") che chi da il contributo rinunci a reclamare brevetti su
qualunque parte di Mozilla, non solo sul codice che ha fornito. Può
non sembrare un difetto: sarebbe bello che una quantità di grandi
aziende rinunciasse a ogni diritto sull'intero pacchetto.
Purtroppo c'è una grande azienda che detiene uno dei più grandi
portafogli di brevetti al mondo, che ha un grosso e specifico problema
con questo cavillo. Non già perché voglia una volta o l'altra
perseguire Mozilla e pretendere royalty, che sarebbe follia. La
preoccupa il fatto che alcune parti di Mozilla implementano processi su
cui essa detiene dei brevetti grazie ai quali incassa ogni anno
moltissimi dollari: e se rinunciasse a far rispettare i brevetti sul
codice di Mozilla, quelle altre aziende che pagano migliaia di dollari
per quei brevetti, potrebbero semplicemente prendere da Mozilla il
codice che li implementa e portarlo nei loro prodotti, eliminando la
necessità di comprare la licenza del brevetto detenuto dalla succitata
grande azienda. Questo non rappresenterebbe un problema se la Sezione
2.2 della MPL si riferisse semplicemente alle patch oggetto di
contributo piuttosto che all'intero browser, quando si viene alla
rinuncia ai diritti di brevetto.
A parte questo cavillo, la MPL è una licenza straordinariamente
solida. Prescrivere che le modifiche debbano tornare al "nucleo"
significa che le correzioni di bug essenziali e i miglioramenti della
portabilità rifluiranno nel progetto, mentre caratteristiche a valore
aggiunto potranno sempre essere sviluppate da entità commerciali. Si
tratta forse della licenza da preferire quando si sviluppano
applicazioni per l'utente finale, nelle quali i brevetti possono più
facilmente diventare un problema e più grande può essere l'impulso a
ramificare il progetto. Per contro, la licenza BSD è forse più adatta
a progetti destinati a essere "invisibili" o essenzialmente librerie di
funzioni, quali un sistema operativo o un server Web.
La Licenza Pubblica GNU
La licenza GNU, che certamente non è concepita per l'ambito
commerciale, presenta tuttavia elementi di un certo richiamo (che ci
crediate o no) anche per i fini di business.
Fondamentalmente, la GPL (General Public License) prescrive che gli
incrementi, i derivati e perfino il codice che incorpora altro codice
sotto GPL vengano rilasciati essi stessi come codice sorgente sotto
GPL. Questo comportamento "virale" è stato ampiamente propagandato
dagli apologeti dell'Open Source come un modo per assicurare che il
codice che nasce free rimanga free: che non ci sia possibilità che un
interesse commerciale possa deviare le versioni di sviluppo dal codice
disponibile e impegnare risorse che non siano rese pubbliche. Agli
occhi di chi licenzia il proprio software sotto GPL, sarebbe meglio non
ricevere addirittura contributi che riceverne per poi non poterli usare
liberamente. La cosa ha naturalmente un interesse speculativo, e si
trovano sostenitori che dichiarano che Linux non sarebbe arrivato
dov'è se non avesse avuto una GPL, perché la lusinga della deviazione
per ragioni commerciali sarebbe stata troppo forte, impedendo di
raggiungere la massa critica dello sforzo di sviluppo unificato.
A prima vista, dunque, parrebbe che la GPL non possa coesistere
felicemente con un fine commerciale collegato al software open source.
I tradizionali modelli di guadagno attraverso l'aggiunta di valore al
software non sono qui praticamente possibili. Tuttavia, la GPL potrebbe
essere un mezzo efficacissimo per affermare una piattaforma che
scoraggi perfino la creazione di piattaforme concorrenti, e per
proteggere la rivendicazione di chi voglia essere conosciuto come il
"primo" fornitore di prodotti e servizi residenti su questa
piattaforma.
Ne sono esempi Cygnus e GCC. Cygnus opera un sostanzioso blocco di
modifiche ogni anno, portando GCC su diversi tipi di hardware e
mantenendo quei porting. La grandissima parte di quel lavoro, secondo
il dettato della GPL, va come contributo alla distribuzione di GCC che
viene reso gratuitamente disponibile. Cygnus fa pagare lo sforzo insito
nel porting e nell'aggiornamento, non il codice in sé. La storia di
Cygnus e della sua leadership in questo ambito ne fanno l'azienda di
riferimento quando ci si voglia accostare a questo tipo di servizio.
Se un concorrente volesse cominciare a competere con Cygnus, sarebbe
costretto a distribuire anch'esso le sue modifiche con licenza GPL: in
altri termini, non c'è speranza che un concorrente possa trovare una
nicchia tecnico commerciale che sia sfruttabile con la struttura GCC
senza dare a Cygnus la stessa opportunità di approfittare anche di
quella tecnologia. Cygnus ha creato una situazione in cui i concorrenti
non possono competere sul piano della diversificazione tecnologica, a
meno che non intendano spendere quantità ingenti di tempo e di denaro
e usare una piattaforma completamente diversa da GCC.
Un'altra maniera in cui si potrebbe usare la GPL per intenti
commerciali è sotto forma "tecnologia sentinella", con una versione
non-GPL dello stesso codice disponibile per la vendita. Per esempio,
poniamo che abbiate un ottimo programma per criptare le connessioni
TCP/IP su Internet. Non v'importa che venga usato in modo commerciale o
meno: vostro interesse è che chi vuole incorporarlo in un prodotto o
ridistribuirlo a pagamento vi paghi per l'autorizzazione a farlo. Se
mettete il codice sotto una licenza GPL, questo secondo gruppo di
utenti non potrà fare quello che vuole senza mettere per intero sotto
GPL il suo prodotto, cosa che molti di loro non sarebbero propensi a
fare. Ma se mantenete un ramo del vostro progetto separato, ossia non
sotto GPL, potrete licenziare commercialmente il ramo separato di
codice come meglio vi aggrada. Bisogna però fare molta attenzione e
accertarsi che tutto il codice che vi è stato dato spontaneamente da
terze parti sia disponibile per questa ramificazione non-gratuita;
potete farlo dichiarando che solo voi (o vostri dipendenti) scriverete
codice per questo progetto, oppure che (in aggiunta) otterrete da
parte di tutti coloro che hanno contribuito al progetto il permesso
esplicito di riversare qualunque loro contributo in una versione
commerciale.
Per alcune società questo è un modello commerciale sostenibile: un
esempio è Transvirtual di Berkeley, che applica questo modello a una
Java Virtual Machine leggera e a un progetto di libreria di classi. Si
può obiettare che un alto numero di partecipanti a un progetto
verrebbe respinto da un simile modello, e che le versioni GPL e non-GPL
potrebbero divergere; a mia volta, obietto che se si trattano i
partecipanti con lealtà, magari anche offrendo loro denaro o compensi
d'altro tipo in cambio dei loro contributi (dopo tutto è in gioco il
vostro interesse primario), questo modello potrebbe funzionare.
L'ambito della licenza open source evolverà certamente nei prossimi
anni quanto più diventerà chiaro che cosa funziona e che cosa no. La
verità è che avete la libertà di inventarvi una licenza nuova, che
descriva esattamente il punto dello spettro (delimitato da BSD a destra
e da GPL a sinistra) in cui vorreste collocarla. Ricordatevi solo che
quanto più grande sarà la libertà che accorderete a coloro che usano
ed estendono il vostro codice, tanto più essi saranno incentivati a
contribuirvi.