Una licenza di software libero è una licenza libera, un testo legale caratterizzato da un aspetto contrattuale o para-contrattuale, che si applica ad un software per garantirne la libertà d'utilizzo, di studio, di modifica e di condivisione, ovvero per renderlo software libero.^[1][2]

La nascita del concetto di licenza applicata ad un software per renderlo libero combacia in parte con la nascita di GNU, il primo sistema operativo completamente libero ideato da Richard Stallman nel 1983.^[3] Tutt'oggi il progetto GNU e la Free Software Foundation patrocinano attivamente il software distribuito sotto licenze libere e, in generale, la libertà digitale degli utenti.^[4][5]

La GNU General Public License, la licenza Apache e la licenza MIT sono alcune fra le licenze libere più adottate.^{[2][6][7][8][9]}

Storia

L’idea di licenza libera si sviluppa con la nascita del software libero la cui storia inizia a partire dal 1980.

Tra gli avvenimenti principali che portano allo sviluppo di queste tematiche troviamo:

• Bayh-Dole Act in America: una nuova legge che permette di privatizzare i risultati ottenuti per mezzo di attività di ricerca svoltesi in ambito accademico, a patto che si verifichino specifiche condizioni (ad esempio la collaborazione con enti privati).

• Frammentazione dell’At&T: una società telefonica americana che fino a quel momento deteneva il monopolio della telefonia. In quanto azienda monopolista, nella fornitura dei servizi di telefonia, era soggetta ai limiti imposti dall’autorità anti-trust statunitense. Quest’ultima aveva imposto ad AT&T diversi obblighi, tra cui l’obbligo di non fornire prodotti o servizi diversi dalla telefonia. AT&T aveva ad un certo punto sviluppato un sistema operativo, ovvero Unix, ma non poteva venderlo. Per questo motivo lo metteva a disposizione gratuitamente nei laboratori di ricerca delle università americane. Unix era, fino al 1980, il software libero utilizzato nel sistema di ricerca nelle università americane. Nel momento in cui la società viene frazionata in più società minori, vengono meno i divieti sottoposti dall’attività anti-trust statunitense. Unix diventa così un possibile oggetto possibile di commercializzazione.

• USA Software Digital Act: prima del 1980 il tema dell’applicabilità al software del diritto d’autore era molto dibattuto. Negli Stati Uniti il primo atto normativo che rende possibile questa applicabilità è del 1976, ma nel 1980 viene adottato un ulteriore atto normativo: USA Software Copyright Act. Arriva quindi in modo definitivo la tutela del diritto d’autore applicata al software.

Nella storia del software è importante focalizzarsi su alcuni diritti, soprattutto parlando dei software degli anni ‘80. Nel 1980 erano importanti 3 facoltà:

● Diritto di riprodurre (Art. 64-bis lett. a^[10] ed art. 13^[11] LdA), cioè il diritto di moltiplicare in copie il programma

● Diritto di modificare (Art. 64-bis lett. b^[10] ed art. 18^[12] LdA), cioè autorizzare le modifiche del programma

● Diritto di distribuire (Art. 64-bis lett. C^[10] ed art 17^[13] LdA), che negli anni ‘80 era la circolazione di copie fisiche

In quegli anni si discuteva su come proteggere il software, se con i diritti d’autore o con i brevetti. La scelta cadde sul diritto d’autore soprattutto perché la lobby delle aziende trovava conveniente adottare il diritto d’autore in quanto meno costoso, mentre il brevetto deve essere concesso (c’è bisogno di una domanda di brevetto che deve essere valutata da professionisti esperti) e ciò necessita di cifre molto importanti. Il valore economico era inizialmente nell’hardware piuttosto che nel software, solo in seguito si inizia a percepire che c’è del valore anche nel software (con l’avvento di linguaggi di programmazione come C).

A partire dal 1980 si diffondono quindi sostanziali cambiamenti, primo tra i quali la diffusione del software privato con forti limitazioni riguardanti la riproduzione, la distribuzione e la modificale libera del codice sorgente. Nel 1981 a seguito della sentenza Diamond v. Diehr, 450 US 175 (1981) venne riconosciuta per la prima volta la natura brevettuale dei programmi per elaboratore. In seguito a questi avvenimenti cominciò ad essere sempre più utilizzato e diffuso il concetto di proprietà intellettuale, concetto che in principio generò non poche difficoltà in quanto era sempre stato associato all’aspetto materiale di un prodotto. Infatti fino agli anni 90 questa espressione non era molto usata, ma diventa una moda quando viene rinominata l’organizzazione mondiale che si occupa di queste materie, chiamata WIPO. Il primo difetto di questa espressione è che mette insieme diritti molto diversi tra di loro, il che risulta molto confusionario. Il secondo difetto è che si usa l’espressione “proprietà” che nel sentir comune ricorda un diritto che applichiamo agli oggetti materiali, un diritto esclusivo ed escludente. I beni materiali come le opere dell’ingegno non funzionano così, perché la ragione dell’uso esclusivo funziona in modo diverso.

Ed è proprio in questo contesto che nascono le prime linee di pensiero in contrapposizione alle limitazioni che si stavano sviluppando. Tra i primi ad opporsi alle nuove disposizioni ci fu Richard Stallman, ideatore della definizione di software libero nonché fondatore del GNU Project (Gnu’s Not Unix). Stallman inizia il progetto con lo scopo di rifare un sistema operativo che avesse qualità simili a quelle del sistema operativo Unix, ma che fosse comunque diverso.

L’idea che sta alla base della licenza libera del software è motivata da istanze etiche riguardanti la libera diffusione e la cooperazione.

Nella prima metà degli anni ‘90, alcuni sviluppatori si convinsero che l’enfasi sugli aspetti etici fosse d’intralcio alla diffusione del software libero in ambito industriale e iniziarono a dubitare anche dell’espressione “free software” che risulta essere un po’ ambigua (in quanto si può anche tradurre "free" come "gratis"). Quindi questo gruppo di sviluppatori pensò di fare re-branding dell’idea di software libero, creando la Open source Initiative ed evolvendo il concetto in quello di Open Source Definition, una definizione simile all’espressione di software libero nella sostanza, ma molto diversa nella forma. Questa definizione è articolata in 10 punti. Negli anni sono state create molte licenze di software libero diverse.

Caratteristiche

Il codice contenuto nel software, a livello giuridico, viene trattato dalle leggi sul diritto di autore. Nell'ambito del software si è introdotto un contratto, la licenza, il cui scopo è spesso quello di limitare ulteriormente i diritti di chi ne fruisce. Il software ha solitamente un proprietario che è colui che detiene i diritti di autore sul software stesso, cioè colui che possiede il copyright. L'uso del software può essere concesso gratuitamente o a pagamento, per le operazioni sancite dal contratto di licenza, o in sua mancanza per quanto stabilito dalla legge.^[14]

Quando si parla di licenza libera (o aperta) del software, così come intesa nell’Art. 69^[15] del CAD, si fa riferimento ad una licenza che garantisca all’utente di un software 4 libertà:

• libertà di eseguire il programma ad ogni scopo (libertà 0);
• libertà di poter studiare il funzionamento del programma con possibilità di accesso al codice sorgente per potervi apportare delle modifiche qualora ce ne fosse necessità (libertà 1);
• libertà di ridistribuire copie in linea con il concetto di condivisione nei confronti di chi necessiti del programma (libertà 2);
• libertà di apportare migliorie al programma e ridistribuire la versione aggiornata in modo che questo possa giovare alla comunità (libertà 3).

Le libertà 1 e 3 richiedono l’accesso al codice sorgente.

Tipologia di licenze copyleft

Si possono suddividere le licenze di software libero in quattro tipologie: licenze non copyleft, licenze copyleft deboli, licenze copyleft forti e licenze copyleft di rete.

Licenze non copyleft

Il codice sviluppato nelle licenze non copyleft può essere preso, modificato senza che il codice così risultante debba soggiacere alla stessa licenza. Le licenze che seguono questo paradigma vengono dette anche “ultraliberali”, nel senso che consentono di fare quel che si vuole. In ciò rientra anche rendere il software interamente proprietario.

In tali licenze, che per la tradizione storica vengono anche dette “accademiche” abbiamo licenze legate appunto all’ambito universitario: la BSD e, meno diffusa, la MIT.

Alle accademiche si accompagna un’altra licenza molto utilizzata, la Apache Public License, licenza usata dalla Apache Software Foundation, che si occupa del più famoso e utilizzato server web. La Apache, al contrario delle accademiche, è una licenza lunga, che comprende anche una clausola di risoluzione nel caso di uso aggressivo dei brevetti da parte di un licenziatario.^[16]

Licenza copyleft forte

Una licenza di copyleft forte tende a estendere il suo effetto vincolante il più possibile a qualunque “opera derivata” di software copyleft. Il copyleft forte richiede una struttura normativa più complessa e stringente, perché essendo “restrittivo” (nel senso che tende a imporre condizioni più stringenti ed effettive al fine di mantenere le libertà del software), richiede che tutti i “buchi” siano tappati, tutte le scappatoie siano evitate, in modo che il copyleft forte resista a chi cerca di evitarlo. Creare una licenza di copyleft forte è molto difficile.

Siccome le licenze di copyleft forte hanno condizioni più stringenti e peculiari, è molto facile che una di esse sia incompatibile con qualsiasi altra licenza di copyleft forte, perciò combinare software sotto due licenze di copyleft forte è in pratica impossibile. Anche combinare copyleft forte con copyleft debole, e a volte anche con non copyleft, si rivela sovente impossibile. Se non si possono rispettare le condizioni di licenza ‒ tutte le condizioni ‒ non si può usare il software, non si possono trarre opere derivate.

La licenza di copyleft forte è la GNU General Public License, o GPL della Free Software Foundation (FSF). Questa licenza è giunta alla sua terza versione.

Licenza copyleft debole

Il copyleft debole è più recessivo rispetto al copyleft forte. Come idea, il copyleft debole opera a livello di file; per cui se uno sviluppatore appone le proprie modifiche a quel file, quel file rimane sotto la stessa licenza. Mentre se il codice sorgente di quel file viene compilato (“linkato”) con altro codice sorgente per creare un file oggetto che li comprenda (un’opera più ampia), il file oggetto risultante ‒ pur incorporando codice copyleft ‒ non necessita di essere pubblicato sotto le stesse condizioni, dunque non c’è interferenza in caso i due file sorgente siano sotto licenze incompatibili, e il prodotto risultante può anche essere sotto licenze proprietarie. Spesso infatti le licenze di copyleft debole sono usate per file destinati ad essere incorporati in altro software, tipicamente librerie.

Per il copyleft debole esistono due licenze: la GNU Lesser General Public License (un tempo “Library General Public License”, in quanto nata per le librerie GlibC, le librerie del compilatore C del progetto GNU) o LGPL; e la Mozilla Public License o MPL, la licenza di Firefox, uno dei più diffusi browser web (poi adottata anche da LibreOffice).^[16]

Licenze copyleft di rete

Con la licenza copyleft di rete si ha diritto ad accedere al programma anche chi utilizza il programma da remoto.

Il copyleft scatta con la distribuzione, solo per chi distribuisce il software si pone dunque un problema effettivo di rispetto delle condizioni di licenza. Cosa accade, però, in quelle situazioni in cui non vi sia effettiva distribuzione, ma ciò non di meno il software venga messo a disposizione di terzi? In tal caso le licenze tradizionali nulla possono. Questo fenomeno è da tempo fonte di preoccupazione per alcuni osservatori, addirittura da prima che per il cosiddetto “Software as a Service” divenisse una forma effettiva di utilizzo del software, e invece di “cloud” si parlava di “Application Service Provider” (fornitore di servizi di applicazioni, abbreviato “ASP”). Infatti al fenomeno si diede il nome di ASP loophole (trucco dell’ASP), ovvero la possibilità per uno sviluppatore di poter sfruttare software copyleft, metterlo a disposizione di terzi, ma senza consegnare il codice, essendo così libero dalle incombenze del copyleft (forte o debole) in quanto le condizioni non sono attivate. In questo modo il fornitore in cloud beneficia di un bene comune, lo sfrutta commercialmente, ma non restituisce nulla al common.

Per tentare di ovviare a tale problema, Bradley Kuhn, un attivista americano, concepì una clausola aggiuntiva alla GNU GPL v.2 che venne conosciuta come “Affero clause” (dal nome del progetto per cui Kuhn lavorava e per cui concepì la clausola). La Affero è l’unica condizione di copyleft che viene attivata non dalla distribuzione, ma dall’uso del software in una particolare situazione: quella sfruttata per dare accesso tramite interfacce di rete al software modificato. In tali condizioni, chi modifica il software deve mettere a disposizione, tramite la stessa interfaccia di rete, l’intero codice sorgente corrispondente alla versione utilizzata. La clausola Affero, nata come un’aggiunta alla GPL, ha poi trovato spazio in una licenza sua propria, denominata GNU AGPL, nella quale rappresenta la clausola 13.1.^[16]

Esistono altre licenze di copyleft di rete, come ad esempio la EUPL, nata nell’ambito delle istituzioni dell’Unione Europa.^[17]

Licenza libera e pubbliche amministrazioni

In Italia abbiamo due articoli che disciplinano l’uso del software libero nella pubblica amministrazione(PA):

Art 68 del CAD: prevede l’obbligo della valutazione comparativa; il comma 1bis spiega quali siano i criteri da considerare nella valutazione comparativa; il comma 1ter spiega che la valutazione comparativa va fatta seguendo una metodologia scritta nelle linee guida dell’AGID. Inoltre prevede l’obbligo di preferenza del software libero nelle pubbliche amministrazioni quando possibile.

Art 69 del CAD: parla del concetto di riuso del software sviluppato per una PA a favore delle altre PA e dei soggetti giuridici. Il concetto fondamentale è che le pubbliche amministrazioni devono consentire il riuso. Questa norma ha avuto una serie di modifiche, che hanno trasformato il concetto di riuso: dal 2016, con la modifica dell'articolo 69, il riuso non è più facoltà solo delle PA ma può essere chiesto dai soggetti giuridici (imprese, persone, enti no-profit ecc...). Un’altra novità della modifica del 2016 è l’obbligo di rendere disponibile a tutti il codice sorgente completo della documentazione e pubblicato in repertorio pubblico sotto licenza aperta, pur tenendo conto di eventuali eccezioni (“salvo motivate ragioni di ordine e sicurezza pubblica, difesa nazionale e consultazioni elettorali”). Il secondo comma definisce cosa debba fare una PA per mettersi nelle condizioni di poter distribuire il software con licenza libera, ovvero essere titolare del diritto di distribuzione con licenza libera.

Valutazione Comparativa

Viene svolta seguendo dei criteri quali:

• Costo Complessivo
• Livello di utilizzo di formati di dati aperti
• Garanzie riguardo alla sicurezza e alla protezione dei dati personali

Le modalità di tale valutazione sono definite dalle https://www.agid.gov.it/it/design-servizi/riuso-open-source/linee-guida-acquisizione-riuso-software-pa%7C^{[collegamento interrotto]} dell'AgID.

• Macro fase 1: individuazione delle esigenze
• Macro fase 2: analisi delle soluzioni a riuso delle Pubbliche Amministrazione e delle soluzioni Open Source

Vanno verificate:

• Conformità alle regole sull'interoperabilità
• Conformità alle normative sulla protezione dei dati personali
• Conformità ai livelli di minima sicurezza previsti per le Pubbliche Amministrazioni

È necessario anche calcolare il valore della soluzione attraverso ulteriori parametri, tra i quali:

• Percentuale di copertura dei requisiti
• Presenza di un manutentore del codice
• Presenza e grado di competenza delle risorse interne della Pubblica Amministrazione
• Numero e tipologia di altre pubbliche amministrazioni che usano lo stesso progetto open source
• Sostenibilità del progetto open source secondo i seguenti indicatori:

1. frequenza delle modifiche
2. frequenza delle pubblicazioni
3. comunità degli utenti
4. longevità del progetto

Va anche calcolato il costo complessivo tenendo conto degli eventuali costi aggiuntivi per:

• Installazione
• Formazione
• Personalizzazione
• Integrazione

Sono da stimare anche i tempi necessari per la messa in produzione.

• Macro Fase 3: analisi di altre soluzioni

Licenza libera di dati

Esistono delle limitazioni legate al diritto d’autore di default che si applica anche alle banche di dati, per questo motivo anche in quest’ambito è necessario utilizzare delle licenze ad hoc per favorire il riuso e la condivisione delle banche di dati.

Da qui parliamo di licenze Open Data, ovvero licenze che regolano il riutilizzo e la distribuzione dei dati tenendo conto del riconoscimento della paternità di chi ha licenziato la base di dati. È importante però tenere sempre conto del fatto che se i dati contenuti riguardano persone sono soggetti alla privacy e di conseguenza non possono circolare in modo del tutto libero.

Principali licenze per software libero

Lo stesso argomento in dettaglio: Comparazione di licenze di software libero.

GNU GPL

La GNU General Public License (GNU GPL, attualmente alla sua terza versione) è una delle licenze libere più adottate.^[8] Secondo tale licenza l'autore conserva i diritti morali sull'opera, ma ne permette la redistribuzione e la modifica con condizioni volte a garantire che tutte le versioni derivate continuino a conservare le stesse libertà. In altre parole se un software sotto GNU GPL viene modificato anche il derivato eredita a sua volta una licenza GNU GPL a prescindere dalla quantità e qualità di ciascuna delle parti. Ideata da Richard Stallman (fondatore della Free Software Foundation) in aiuto con il professore di legge Eben Moglen, fu storicamente la prima licenza libera forte.^[18] Può capitare che un software sotto licenza debole avanzi a licenze più forti, fino ad arrivare alla GNU GPLv3+ che è una delle licenze libere più forti.^[9]:: La licenza GPL3:

• è una licenza di tipo copyleft
• non presenta accordi di co-desistenza
• cerca di risolvere in certa misura dei problemi di compatibilità
• prevede delle nuove modalità di distribuzione di codice sorgente

GNU AGPL

La GNU AGPL (GNU Affero General Public License o Affero GPL) è sostanzialmente la GNU GPLv3 con un paragrafo aggiuntivo che permette agli utenti che interagiscono tramite l'output di un software lato server di ricevere il codice sorgente di quel software. La Free Software Foundation consiglia agli sviluppatori di considerare l'uso della GNU AGPL per software destinato ad essere utilizzato via rete.^[19][20]:: La licenza AGPL3:

• è una licenza di tipo network copyleft
• è compatibile con la licenza GPL3

GNU LGPL

La GNU Lesser General Public License (GNU LGPL) è una licenza copyleft come la GNU GPL.

La LGPL è usata in particolar modo per librerie software e talvolta anche da applicativi come Mozilla Firefox e LibreOffice.^[21]

La licenza LGPL3 è una licenza di tipo weak copyleft: permette di effettuare linking da software con diverse licenze.

MIT

La licenza MIT, chiamata anche "license X" o "license X11", è una licenza di software libero creata dal Massachusetts Institute of Technology (MIT). È una licenza permissiva o week copyleft, la quale permette il riutilizzo nel software proprietario con la condizione che la licenza sia distribuita con tale software. Non pone vincoli all'utilizzo del software modificato, infatti a differenza della licenza GPL, con il software licenziato con essa si può creare software proprietario. MIT è anche GPL-compatibile, cioè è possibile combinare e ridistribuire software GPL con codice che usa la licenza MIT. La licenza è simile alla licenza BSD, tranne per il fatto che quest'ultima contiene una nota che proibisce l'utilizzo del nome del detentore del copyright per fini pubblicitari.

BSD

In principio venne utilizzata per distribuire il sistema operativo Unix Berkeley Software Distribution. Si tratta di una licenza debole, per cui da essa può derivare anche software non libero. Uno dei suoi punti di forza è che rimane compatibile con la GNU GPL in quanto, in caso di riutilizzazione di codice sorgente appartenente a quest'ultima, cede le sue credenziali in favore della GNU GPL.

Si può quasi sostenere che questa licenza software sia "realmente" libera, in quanto all'utente è consentito di distribuire il software da lui modificato o ampliato come libero o no.

Gli sviluppatori GNU GPL sottolineano però come questa licenza non contribuisca allo sviluppo di altro software libero e ritengono che la licenza BSD è più libera di una licenza GNU GPL se e solo se si crede che un Paese che consenta la schiavitù sia più libero di uno che non la consente.

Apache

La Licenza Apache, sviluppata dalla Apache Software Foundation, non è una licenza copyleft pertanto versioni modificate del software possono essere oggetto di software proprietario, ma impone di includere un'informativa sul fatto che si sta usando software licenziato secondo i termini della Licenza Apache. La licenza è utilizzabile da qualsiasi sviluppatore interessato, anche in caso non fosse associato ad ASF. Il vincolo più importante imposto da questa licenza è la necessità di dare credito all'autore originale in ogni progetto derivato.^[22]

La versione 2.0 della licenza è compatibile con la GNU GPLv3, ma non con le versioni precedenti.^[23]

MPL

La Mozilla Public License favorisce una collaborazione efficace permettendo di unire software libero e non libero. Il codice sorgente copiato o modificato sotto la licenza MPL deve rimanere sotto MPL, fattore che la rende ovviamente incompatibile con la GNU GPL (fatte le dovute eccezioni) nonostante sia meno permissiva della licenza BSD. La NPL (Netscape Public License, prima versione della MPL) fu la prima a curarsi di alcuni punti che non furono mai presi in considerazione dalle licenze BSD e GNU GPL: poter combinare codice sotto MPL con codice proprietario rende questa licenza molto appetibile anche dal punto di vista commerciale. Nello spettro delle licenze di software libero può essere considerata adiacente alla licenza BSD, ma ristretta.

EUPL

L'European Union Public Licence è una licenza network copyleft approvata dalla Commissione europea in lingua Inglese, Francese e Tedesca il 9 gennaio 2007, mentre il 9 gennaio 2008 è stata approvata in tutte le restanti lingue ufficiali dell'Unione europea. Dal gennaio 2009 la Commissione ha adottato la versione 1.1. La presente licenza si applica a tutte le opere sotto le condizioni previste dall'EUPL.^[24] Secondo la Free Software Foundation (FSF) la licenza impone un copyleft forte e non è compatibile con la GPL. Essendo compatibile con licenze copyleft debole permette di avere effetti legali diversi non voluti dagli sviluppatori originali.^[25]:Risulta compatibile con alcune licenze indicate nella licenza stessa, ma non è riportata la GNU GPLv3.^[26]

Viene usata prevalentemente nell'ambito della Pubblica Amministrazione dei paesi membri dell'Unione Europea.

Leggi regionali sul software libero

In molte regioni italiane la preferenza per il software libero è prevista anche da prima del 2012 attraverso varie leggi regionali:

● art. 4, comma 1, lett. i), L1/2004 Regione Toscana^[27]

● art. 3 e 4, L11/2006 Regione Umbria^[28]

● art. 1, comma 1, lett. c), L19/2008 Regione Veneto^[29]

● art. 6, comma 2, L.9/2009 Regione Piemonte^[30]

● art. 10, L.20/2012 Regione Puglia^[31]

All’estero solo dopo il 2012 (ad esempio in Ecuador e Francia) viene introdotta una norma che impone la preferenza nelle pubbliche amministrazioni per il software libero.