Le prime applicazioni della GPL hanno fatto
però emergere un problema di tipo pratico, derivante proprio da una caratteristica specifica e peculiare della licenza: la sua ‘viralità’ . Cioè la sua capacità di trasmettere presso un numero indefinito di utenti una certa
serie di diritti e responsabilità; “in pratica tutto il codice sviluppato per funzionare in associazione con
software GPL dev’essere a sua volta coperto da GPL” , pena la caducazione dell’intera licenza ex ‘Sezione
5’. Lo dice chiaramente il periodo finale dell’appendice esemplificativa per la corretta applicazione della
GPL: “I programmi coperti da questa Licenza Pubblica Generica non possono essere incorporati all'interno
di programmi non liberi.” Ma bisogna tenere presente che il software non è un’entità statica e monolitica, bensì un insieme
fittissimo di altri software, se per software intendiamo una serie di istruzioni impartite al computer . Perciò
è possibile che nel modello “a cascata” di ridistribuzione del software libero, grazie alla disponibilità del
codice sorgente completo e alla possibilità di modifica garantite dalla GPL, qualche sviluppatore voglia
scorporare il pacchetto software e rielaborarne solo una parte (che potremmo chiamare “microsoftware”),
oppure decida di fare interagire un software di derivazione libera con un software proprietario.
E’ il tipico caso delle librerie : esse sono delle “raccolte di funzioni” precompilate (dette routine) a disposizione del computer, di cui possono “servirsi” i programmi veri e propri che vengono eseguiti, pur non facendo realmente parte dei programmi stessi. In questo modo può facilmente verificarsi che un software libero si appoggi su un libreria di origine proprietaria e viceversa. Quindi un’eccessiva rigidità (come per certi versi è quella della GPL) può risultare controproducente allo sviluppo di software libero: uno sviluppatore GNU che volesse creare una libreria sotto i parametri del copyleft saprebbe che poi molti utenti di software proprietario potrebbero avere dei problemi ad usarla. Fu per questo che, dopo che molti collaboratori del progetto GNU fecero notare questa difficoltà, la FSF decise (nel 1991) di stilare una seconda licenza, chiamata LGPL, Library General Public License . E’ dunque una licenza apposita per il caso delle librerie, che si presenta come una versione della GPL alleggerita però di alcune restrizioni (per questo infatti è stata recentemente rinominata ‘Lesser GPL’, ovvero ‘GPL minore’). Ovviamente la FSF “diffida” chiunque ad usare questa licenza per software che non siano librerie, pena l’esclusione del programma così distribuito dalla “famiglia” del software libero.
Open Source e opere non software:
E’ il tipico caso delle librerie : esse sono delle “raccolte di funzioni” precompilate (dette routine) a disposizione del computer, di cui possono “servirsi” i programmi veri e propri che vengono eseguiti, pur non facendo realmente parte dei programmi stessi. In questo modo può facilmente verificarsi che un software libero si appoggi su un libreria di origine proprietaria e viceversa. Quindi un’eccessiva rigidità (come per certi versi è quella della GPL) può risultare controproducente allo sviluppo di software libero: uno sviluppatore GNU che volesse creare una libreria sotto i parametri del copyleft saprebbe che poi molti utenti di software proprietario potrebbero avere dei problemi ad usarla. Fu per questo che, dopo che molti collaboratori del progetto GNU fecero notare questa difficoltà, la FSF decise (nel 1991) di stilare una seconda licenza, chiamata LGPL, Library General Public License . E’ dunque una licenza apposita per il caso delle librerie, che si presenta come una versione della GPL alleggerita però di alcune restrizioni (per questo infatti è stata recentemente rinominata ‘Lesser GPL’, ovvero ‘GPL minore’). Ovviamente la FSF “diffida” chiunque ad usare questa licenza per software che non siano librerie, pena l’esclusione del programma così distribuito dalla “famiglia” del software libero.
Open Source e opere non software:
Nessun commento:
Posta un commento