Esplode il caso “licenze” all’Open Source Conference di Milano!

//Esplode il caso “licenze” all’Open Source Conference di Milano!

Esplode il caso “licenze” all’Open Source Conference di Milano!

Singola licenza? Doppia licenza? Copyleft? Permissiva? Proviamo a capire di cosa si tratta con Italo Vignoli, presidente onorario di LibreItalia, intervistato per chiarire aspetti e soprattutto dubbi e inesattezze legati alla scarsa informazione sul tema.

D1. Ci può spiegare cosa sono le licenze software?

R1. La licenza è un “contratto” che regola il rapporto tra il produttore e l’utente del software, per cui definisce i diritti di entrambi e tra questi stabilisce il perimetro di utilizzo del software stesso. Quest’ultimo, infatti, deve essere regolato, in quanto è più difficile stabilire la “proprietà” di un software rispetto a quella di un oggetto, in quanto il software è – per sua natura – immateriale.

D2. Qual è la sua esperienza rispetto alle licenze open source?

R2. Mi occupo di software open source dal 2004, quando ho iniziato a lavorare – come volontario – all’interno della comunità OpenOffice.org. Nel 2010, sono stato tra i fondatori del progetto LibreOffice, e da allora ho focalizzato il mio impegno su questo software. Durante questo periodo, ho iniziato a occuparmi anche delle licenze software.

In conseguenza del mio lavoro, nel 2013 ho partecipato alla commissione AgID per la definizione delle Linee Guida per l’Applicazione dell’Articolo 68 del CAD, che è sfociato nella Circolare 63/2013 pubblicata nel gennaio del 2014.

D3. Qual è il ruolo delle licenze nel mondo del software open source?

R3. Le licenze sono degli strumenti commerciali, e in quanto tali sono importanti per il successo – o l’insuccesso di un progetto di software open source. Credo sia il caso di sfatare la leggenda secondo la quale le licenze vengono scelte per motivi di tipo “filosofico”, perché dimostra solo l’incompetenza di chi la sostiene, o la sua dabbenaggine (se la scelta è stata fatta da qualcun altro).

Basta osservare progetti come Apache OpenOffice, dove la licenza “permissiva” è stata imposta da un’azienda con motivazioni di nessun valore “filosofico” e scarso valore commerciale, nonostante la storia abbia ormai dimostrato che quel tipo di licenza è inadatto per un software desktop, e questo stia portando a una lenta agonia del progetto stesso.

D4. E’ possibile fare una valutazione “qualitativa” delle licenze open source?

R4. Anche se sono favorevole alle licenze copyleft (GPL, LGPL e MPL) e profondamente contrario alle licenze “permissive” (Apache, BSD e MIT), è molto difficile effettuare una valutazione qualitativa, proprio perché ciascuna licenza è scelta in funzione del modello di business del progetto.

D5. La Circolare 63/2013 cita come esempi di software proprietari Alfresco, MySQL e Zimbra, che pur appartenendo al mondo dei software open source sono distribuiti con una doppia licenza, di cui una proprietaria. Perché alcuni software open source usano una sola licenza, e altri una doppia licenza?

R5. Quello del “dual licensing”, o doppia licenza, è un vecchio male del mondo open source. Infatti, quando un software viene erogato in questa modalità, si tratta di un software proprietario mascherato da software open source, in quanto una versione – quella commerciale, che viene proposta come la migliore per le aziende – ha un’EULA che non è molto diversa dall’EULA proprietaria, e non può essere considerata in alcun modo un software open source.

Questa soluzione viene quasi sempre adottata dai progetti legati a un’azienda, che utilizza la bandiera dell’open source come specchietto per le allodole, ma alla fine si ispira agli stessi principi del software proprietario, per cui vuole essere l’unica a trarre vantaggio dalle opportunità di mercato. In questo modo, normalmente, non solo non riesce a vendere la versione proprietaria, ma non riesce nemmeno a creare un ecosistema intorno a quella open source.

D6. Quali consigli darebbe a un’azienda che deve acquisire un software open source, rispetto alla licenza?

R6. Prima di tutto, assicurarsi che la licenza open source non consenta “derive” proprietarie, perché il software potrebbe sparire da un momento all’altro, e poi di rifiutare qualsiasi tipo di EULA perché l’EULA è una licenza proprietaria (anche se qualche progetto cerca di mascherarla come versione “enterprise” di una licenza open source).

Link alla rivista