Fonte: opensource.com

Chiunque scriva software o, in generale, si occupi di informatica, prima o poi si è imbattuto nell’intricatissimo universo delle licenze open source con le quali sono distribuiti una parte dei programmi gratuiti che si trovano in giro. Tra i più famosi ci sono il browser Firefox e la suite LibreOffice/OpenOffice. Tra i meno famosi (ma che vorremmo lo fossero) troviamo la quasi totalità dei software sviluppati dalla nostra unità: Tint, KD, EasyTurk, e così via.

Attenzione a non confondere “open source” con “gratuito”: nel secondo caso si intende un software che possiamo installare e utilizzare senza pagare nulla, mentre nel primo caso significa che insieme al programma otteniamo anche il codice sorgente che lo compone, affinché noi possiamo adattarlo e modificarlo a nostro piacimento. È un po’ come se andassimo in un ristorante e insieme al piatto ci portassero anche un foglietto con gli ingredienti e la ricetta per riprodurre la pietanza a casa.

Una licenza open source non vuol dire però che chi riceve il codice ci possa fare quello che desidera: per questo motivo sono nate negli ultimi anni decine di licenze di tipo diverso, ciascuna con le sue peculiarità.

La più libera è sicuramente la “public domain”, nota anche con il nome CC0: l’autore del software rinuncia a qualsiasi diritto su di esso, compreso quello di essere riconosciuto come autore. È una traduzione leguleia di “fate quello che vi pare”.

Procedendo per sommi capi (il discorso sarebbe lunghissimo), la limitazione più debole è quella sulla semplice attribuzione del lavoro all’autore dello stesso: se il mio software include o estende il software dell’azienda X, dovrò semplicemente dirlo. Ne sono esempi le licenze Apache e BSD, ma la lista sarebbe lunga. Perché fare tante licenze, se il succo è sempre lo stesso? Perché ciascuna ha una sua peculiarità, e potrebbe essere diversa la modalità con cui l’azienda X dovrà essere citata. Per esempio, la licenza BSD prevede che il materiale pubblicitario del software utilizzato contenga il riferimento all’autore (almeno nella prima versione), mentre per la Apache è sufficiente che sia nella documentazione. Il nostro software KD è rilasciato con licenza Apache, quindi se lo usate dovete dirlo nella documentazione del programma, ma non nelle locandine con cui tappezzerete le città.

Un altro livello di differenza tra le varie licenze è relativo invece alla sua viralità: se uso il componente X in un mio software, ho limitazioni sulla licenza che devo utilizzare per rilasciarlo? Tutte le licenze introdotte nel paragrafo precedente, per esempio, prevedono solamente l’attribuzione del lavoro. Questo significa che uno sviluppatore può prendere il software rilasciato dall’azienda X con licenza Apache, estenderlo, modificarlo a piacimento, e vendere il nuovo prodotto senza chiedere nulla a nessuno: è sufficiente nominare X nella documentazione.

La viralità invece interviene proprio sulle limitazioni che potrei avere per il mio software una volta che uso al suo interno una licenza open source: come nel caso precedente, ci sono molte opzioni. Le più famose sono Mozilla (MPL) e GPL, con le dovute differenze. La prima è debolmente virale, perché solamente le parti modificate dovranno mantenere la stessa licenza (e quindi essere rilasciate a loro volta con licenza Mozilla). La seconda invece è molto più severa: qualsiasi software estenda o utilizzi un modulo con licenza GPL deve essere a sua volta rilasciato con licenza GPL. La più intransigente di tutte resta la AGPL, sviluppata nel 2002, che estende la viralità anche alle applicazioni che utilizzano la rete: in pratica qualsiasi software che usi in qualsivoglia forma un modulo o prodotto AGPL per funzionare deve essere necessariamente rilasciato con la stessa licenza. Il nostro software di analisi di testi in italiano Tint è rilasciato in GPL: la scelta è stata obbligata, essendo Tint un modulo del tool Stanford CoreNLP, a sua volta rilasciato in GPL (ecco il perché della scelta della parola “viralità”).

Concludiamo la carrellata con la questione relativa all’utilizzo commerciale del software open source. Nonostante quello che si possa pensare leggendo fin qui, tutte le licenze discusse contemplano la possibilità di vendere i prodotti derivati da software con licenze open source. Restano però le limitazioni descritte: se io produco un software usando un “pezzo” rilasciato con la GPL, dovrò a mia volta usare la stessa licenza. Chi compra il software avrà quindi a disposizione il codice sorgente e potrà fare di questo ciò che la licenza gli garantisce (tra cui, appunto, modificarlo e venderlo).

È possibile dunque fare soldi con il software open source? Certo che sì, in almeno due modi.

Il primo consiste nel fornire valore aggiunto e personalizzazioni di un certo software. Se da una parte è vero che i programmi open source possono essere usati e modificati da chiunque, è anche vero che bisogna saper intervenire sul codice. Chi meglio di chi l’ha ideato e scritto per primo è adatto per questo lavoro?

Il secondo modo è rilasciare il software con doppia licenza: se lo vuoi gratis, allora puoi prenderlo così com’è con la licenza virale; se invece sei disposto a pagarlo, ti vendiamo lo stesso codice con una licenza diversa, proprietaria, attraverso la quale la proprietà intellettuale del prodotto derivato non deve sottostare alla viralità della licenza e quindi l’acquirente può fare quello che desidera (ovviamente in base alla nuova licenza, che potrebbe anche dipendere caso per caso). La doppia licenza è una pratica che ha più applicazione nel caso di licenze virali, visto che raramente un’azienda avrà interesse a sborsare quattrini solamente per non dover dichiarare di aver usato un certo software (l’attribuzione, appunto, di cui abbiamo parlato all’inizio dell’articolo).

Andando oltre: può un prodotto derivato da un software GPL (e quindi rilasciato con la stessa licenza per via della viralità) avere anche una doppia licenza? La risposta in questo caso è: dipende. Se tutti i prodotti GPL da cui deriva offrono la possibilità della doppia licenza e l’acquirente ha comprato quella commerciale, allora anche lo sviluppatore del prodotto derivato può applicare la doppia licenza, e quindi venderlo libero dalla viralità della GPL. Appartiene a questa casistica la situazione di Tint, un prodotto derivato da Stanford CoreNLP: poiché CoreNLP prevede una licenza commerciale, anche noi possiamo vendere Tint senza la viralità della licenza GPL, a patto che l’acquirente ne possegga una di CoreNLP.

Il mondo delle licenze open source è un dedalo nel quale è difficile districarsi se non si hanno competenze in materia, e talvolta gli sviluppatori stessi, che poi quel codice dovranno scriverlo, hanno molti dubbi a riguardo. In questa descrizione ho voluto dare solamente una panoramica a volo d’uccello su questo universo esteso, omettendo molti altri dettagli che possono essere approfonditi leggendo i documenti originali (linkati nell’articolo).

Ringrazio Chris Tagge dell’Università di Stanford, che ci ha permesso di chiarire alcuni punti relativi alla doppia licenza.