Punto informatico Network
Canali
20091011195959_536691528_20091011195943_1980265020_sl_open.png

GPL ed altre licenze libere: cosa è possibile fare e cosa no

23/06/2011
- A cura di
Zane.
Linux & Open Source - È possibile usare software open source gratuitamente anche in ambito professionale? Posso vendere un software open source così com'è? posso apportare modifiche marginali, cambiargli il nome e spacciarlo per una mia realizzazione? che differenza c'è fra GPL, LGPL, BSD, MPL ed altre sigle strane? Proponiamo un articolo per rispondere a queste e ad altre domande estremamente pratiche circa l'utilizzo del software libero.

Tag

Passa qui con il mouse e visualizza le istruzioni per utilizzare i tag!

open source (1) , licenze (1) .

Valutazione

  •  
Voto complessivo 5 calcolato su 98 voti

GNU General Public License (GPL) è la licenza open source più famosa, probabilmente perché è quella che tutela lo stesso Linux.

Ne sono state realizzate molteplici versioni successive, allo scopo di chiarire alcuni concetti che potessero risultare ambigui o adattare le clausole all'evolversi della tecnologia.

La filosofia alla base di GPL è indubbiamente molto articolata (per un approfondimento, si veda "GNU/Linux: la rivoluzione culturale"), ma in linea di massima è incentrata sul garantire ogni libertà agli individui, a patto che questi siano disposti a garantire lo stesso diritto agli altri.

Ogni programma con il proprio sorgente

In caso uno sviluppatore desiderasse distribuire il risultato delle sue fatiche con licenza GPL, è chiamato a pubblicare sempre il codice sorgente a fianco della consueta versione già compilata.

Sono concesse alcune deroghe circa tempi e modalità (ad esempio, il sorgente può trovarsi su un server distinto), ma, in linea di massima, lo sviluppatore deve sincerarsi che ottenere il sorgente comporti un livello di difficoltà e costi equivalente a quello necessario per ottenere il binario.

Ogni programma deve essere accompagnato una copia della licenza

GPL prevede che tutte le opere da essa tutelate includano anche una copia del testo completo dalla licenza d'uso stessa, nella quale sono illustrate le libertà garantite e gli obblighi da rispettare.

Per preservare la massima chiarezza nel tempo, non è concesso sostituire la licenza con un semplice link: deve essere veicolato il testo completo vero e proprio.

Nessun vincolo, fino a quando non si distribuisce

L'utente è libero di prendere qualsiasi listato rilasciato sotto GPL e modificarlo a proprio piacimento.

Fino a quando il lavoro derivato da questo rimane all'interno di un ambito circoscritto, l'utente non è chiamato a rendere disponibile il codice sorgente dell'applicazione derivata.

Tale diritto si estende anche agli ambienti professionali: è quindi assolutamente lecito prendere, ad esempio, un software gestionale rilasciato sotto GPL, adattarlo alle specifiche esigenze della propria realtà lavorativa, e quindi utilizzare la versione così ottenuta senza essere costretti a pubblicare il codice sorgente della stessa.

Se rendi disponibile al pubblico, serve anche il sorgente

I vincoli di GPL divengono più stringenti in caso si desiderasse rendere disponibile al pubblico (e, quindi, anche "vendere") un programma tutelato da tale licenza oppure un suo derivato.

In tale circostanza, il soggetto è chiamato ad utilizzare la stessa licenza GPL, e non è concesso imporre vincoli più restrittivi.

Il concetto è espresso molto chiaramente da Richard Stallman, ideatore di GNU, nel corso del documento "Copyleft: Pragmatic Idealism":

I programmatori che scrivono miglioramenti per GCC (o Emacs, o Bash, o Linux, o un qualsiasi programma coperto dalla GPL) lavorano spesso per aziende o università. Quando il programmatore vuole offrire questi miglioramenti alla comunità e vedere il suo codice incluso nella versione successiva del programma in questione, il suo capo potrebbe dire: "Fermo lì! Il tuo codice appartiene a noi! Non vogliamo condividerlo con altri; abbiamo deciso di trasformare la tua versione migliorata in un prodotto proprietario". Qui viene in aiuto la GNU GPL. Il programmatore mostrerebbe al capo che un tale prodotto proprietario sarebbe una violazione del diritto d'autore e il capo capirebbe che ci sono soltanto due possibilità: rilasciare il nuovo codice come software libero o non rilasciarlo affatto.

In altre parole, se si desidera rendere disponibile al pubblico un lavoro derivato da un software GPL, è indispensabile che venga rilasciato a propria volta anche il nuovo codice sorgente, e che sia garantito il diritto di modificare anche questo nuovo prodotto secondo le stesse modalità.

Non importa che le modifiche siano sostanziali come una profonda riscrittura di certe funzioni, minime come la variazione di poche stringe di testo o, ancora, che si tratti dello stesso programma "rimarchiato": quello che importa è che, in caso si decidesse di distribuirlo al pubblico, sia reso disponibile anche il sorgente di ogni versione derivata con le stesse modalità previste da GPL.

Finché c'è il sorgente, si può anche vendere

Nulla vieta di vendere un software tutelato da GPL: l'importante è che venga garantita anche la presenza del codice sorgente.

È evidente però che l'acquirente potrà poi scegliere di rendere disponibile a terzi tale lavoro in modo completamente legale.

Non si tratta di una contraddizione: vendendo software tutelato da GPL, il commerciante non è retribuito per il prodotto in sé, ma piuttosto per il servizio erogato, ovvero il "rendere disponibile" il prodotto.

Niente linking da applicazioni closed

Un altro limite che deve essere tenuto bene a mente da chi realizza programmi derivati riguarda l'impiego di librerie coperte da licenza GPL.

Il cosiddetto static linking (ovvero la copia, compiuta in fase di compilazione, di codice contenuto in una libreria esterna all'interno dell'eseguibile principale) è consentito solamente all'interno di programmi che vengano poi rilasciati con la medesima licenza.

In altre parole, non è possibile realizzare un programma closed source utilizzando librerie tutelate da GPL.

Un esempio per capire

Come scenario pratico, si pensi a questa circostanza. Uno sviluppatore ha reso disponibile con licenza GPL una libreria che espone funzioni che consentono la creazione di grafici d'ogni tipo (istogrammi, a torta e via dicendo).

Un'azienda sta sviluppando un software di analisi finanziaria, e vorrebbe quindi utilizzare le funzioni esposte dalla libreria open per mostrare diagrammi al suo interno.

Ai sensi della licenza GPL, tale operazione è permessa solamente a patto che anche l'intero applicativo finanziario sia rilasciato sotto licenza GPL.

Arriva LGPL

Appare evidente che si tratta di un limite piuttosto pericoloso: il programma completo potrebbe essere infatti estremamente ampio, mentre il codice della libreria adibita ai grafici solo poche centinaia di righe.

Si crea quindi una situazione per cui l'utilizzo di un frammento di codice che può costituire una piccola percentuale del totale che costituisce il programma costringe l'azienda a rilasciare il tutto sotto GPL. Una scelta che, all'atto pratico, potrebbe condurre l'azienda a desistere.

Per ovviare a questa situazione, la licenza GPL è disponibile anche in una declinazione specifica, denominata GNU Lesser General Public License (LGPL).

LGPL è pressoché identica alla GPL tradizionale, non fosse per il fatto che il limite relativo all'utilizzo di librerie statiche all'interno di applicazioni non-open è assente: questo significa che è possibile utilizzare librerie LGPL anche all'interno di programmi a codice chiuso.

Starà però al programmatore che ha rilasciato la libreria stessa scegliere di preferire LGPL rispetto alla più restrittiva GPL: questa è però una scelta influenza solamente dagli scopi del singolo sviluppatore.

L'eccezione del "dynamic linking"

Una importante eccezione a quanto appena detto riguarda le librerie studiate per essere linkate dinamicamente (dynamic linking, di cui le .dll di Windows sono l'esempio più famoso).

Poiché il codice di tali componenti viene sì utilizzato, ma mai copiato all'interno del programma vero e proprio (e sarebbe quindi alquanto difficile sostenere che possa trattarsi di un "lavoro derivato), l'impiego di librerie di questo tipo è sempre concesso, anche all'interno di programmi closed source.

Questo è vero indipendentemente dal fatto che la libreria stessa sia rilasciata con licenza GPL o LGPL.

Ogni derivato, con un proprio nome

Per evitare l'enorme confusione che sarebbe generata in caso contrario, GPL impone che l'autore inserisca il proprio nome come parte integrante di ogni versione derivata.

Nessuna variazione al testo della licenza

Il testo della licenza è coperto da copyright, e non ne è consentita la modifica.

In particolar modo, non è generalmente permesso di realizzare licenze derivate che introducano limitazioni aggiuntive rispetto a quelle già presenti.

Fonti e approfondimenti

Per quanto possa sembrare strano, la risposta è "sì": la licenza non vieta di prendere il codice sorgente e modificarlo liberamente.
Pagina successiva
Berkeley Software Distribution (BSD)
Pagina precedente
GPL ed altre licenze libere: cosa è possibile fare e cosa no

 

Segnala ad un amico

Tuo nome Tuo indirizzo e-mail (opzionale)
Invia a:
    Aggiungi indirizzo email
    Testo

    © Copyright 2020 BlazeMedia srl - P. IVA 14742231005

    • Gen. pagina: 0.15 sec.
    •  | Utenti conn.: 37
    •  | Revisione 2.0.1
    •  | Numero query: 43
    •  | Tempo totale query: 0