Una delle domande più frequenti, quanto all’open source, riguarda le effettive possibilità di guadagno: è possibile sostenere un business che non sia basato sui brevetti? Ovviamente, sì. Il problema è «come» ottenere dei ricavi dal proprio lavoro e un aspetto fondamentale è la scelta tra le licenze. Commettere degli errori potrebbe rivelarsi fatale, perché cambiare licenza in corso non è semplice — e neppure possibile, senza modificare i sorgenti. Electronic Fooding ha offerto un’interessante panoramica delle possibili opzioni.

Dovendo “liberare” i sorgenti del proprio mail server, la startup – come chiunque altro voglia affrontare quest’operazione – ha dovuto necessariamente scegliere una licenza: la scelta è ricaduta sulla AGPL, ma non è l’unica soluzione disponibile. Elencare le caratteristiche delle singole licenze sarebbe tedioso, però possiamo riassumerne i concetti essenziali per capire a cosa siano più adatte. La MIT è stata adottata da jQuery, ad esempio, perché permette di costruire una comunità di sviluppatori attorno al progetto originario.

Poiché è impossibile vendere il codice, la MIT ammette che un’azienda o un libero professionista sviluppino due versioni dello stesso prodotto: una open source al 100% e una proprietaria a pagamento, che solitamente rappresenta un’estensione della prima. Lasciate perdere la licenza in sé – perché entrambi utilizzano la GPL, che affronteremo dopo – e pensate a MySQL o Xen, che propongono una variante “aperta” e una variante “chiusa” dei rispettivi software. La seconda ha sempre dei componenti in più che devono essere acquistati.

La MIT e la GPL sono molto simili e persino compatibili, ma la comunità discute da tempo sulle differenze sostanziali: quella di GNU è per alcuni aspetti una licenza più restrittiva — non tanto sul codice, quanto sulla ridistribuzione. WordPress, ad esempio, adottando la GPLv3 non potrebbe essere ridistribuito da terzi con delle licenze differenti. Ghost, ricorrendo alla MIT, sarebbe ridistribuibile come un prodotto differente con un’altra. Sembrano dei dettagli trascurabili, però possono cambiare radicalmente un business plan.

Electronic Fooding ha scelto la AGPL – che costituisce una variante, meno popolare, della GPL – perché risolve il problema delle versioni differenti: il prodotto da sviluppare è uno soltanto, ma viene proposto in due formule diverse. Quella open source ne prevede la distribuzione gratuita ai privati «così com’è», l’altra consente la vendita dello stesso codice alle aziende o ai professionisti che pagano soltanto per il supporto tecnico. E un’opzione popolare cui ricorrono in molti, scegliendo delle licenze alternative alla AGPL.

Perdersi nella “giungla” delle licenze è semplice: potrei dilungarmi sulle caratteristiche della Apache, delle varie BSD, ecc. e non riuscire comunque a trasmettere nulla. Il consiglio è quello di stabilire a priori se i maggiori guadagni possano derivare più dal supporto oppure dalle estensioni del prodotto che intendete rilasciare come open source, affidandosi all’aiuto degli esperti — perché se come me non siete laureati in giurisprudenza un’attenta lettura dei termini della singola licenza potrebbe essere del tutto inutile.

Photo Credit: Kris Krug via Compfight (CC)