Il software Open Source

Il software Open Source
Matteo Baroni
“Open source” non significa semplicemente accesso al codice sorgente. Secondo quanto stabilito
nelle definizioni date dalla OSI (Open Source Initiative) e riportate nel sito ufficiale
www.opersource.org, i termini di distribuzione del software open-source devono soddisfare i
seguenti criteri:
1. Libera Ridistribuzione
La licenza non deve impedire la vendita o la fornitura del software come componente di una
distribuzione di software aggregato che racchiude programmi provenienti da fonti differenti. La
licenza non può prevedere il pagamento di una royalty o altre “fee” per tale vendita.
2. Codice Sorgente
Il programma deve comprendere il codice sorgente, e deve consentire la distribuzione sia del codice
sorgente, sia del software in forma compilata. Laddove un prodotto non sia distribuito con il codice
sorgente, devono esserci sistemi ben pubblicizzati per ottenere il codice sorgente ad un costo non
superiore ad un ragionevole costo di riproduzione - preferibilmente, il codice sorgente deve essere
scaricabile da Internet senza ricarico. Il codice sorgente deve essere la forma preferita in cui un
programmatore potrà partire per modificare il programma. Codice sorgente deliberatamente
oscurato non è consentito. Forme intermedie come l’output di un preprocessore o di un traduttore
non sono ammesse.
3. Prodotti derivati
La licenza deve consentire modifiche e prodotti derivati, e deve consentire che gli stessi siano
distribuiti alle medesime condizioni previste nella licenza per il software originale.
4. Integrità del Codice Sorgente dell’Autore
La licenza può limitare la distribuzione del codice sorgente in forma modificata solo se la licenza
stessa consente la distribuzione di "patch files" con il codice sorgente allo scopo di modificare
quest’ultimo allo svolgimento del “build”. La licenza deve esplicitamente consentire la
distribuzione del software prodotto a partire dal codice sorgente modificato. La licenza può
richiedere che i prodotti derivati abbiano un nome diverso o un diverso numero di versione rispetto
al software originale.
5. Nessuna Discriminazione verso Persone o Gruppi
La licenza non può discriminare persone o gruppi di persone.
6. Nessuna Discriminazione verso Campi di Applicazione
La licenza non deve impedire ad alcuno l’impiego del programma in uno specifico campo di
applicazione. Per esempio, non può essere impedita l’applicazione per un certo commercio, o per la
ricerca genetica.
7. Distribuzione della Licenza
1
I diritti legati al programma devono essere applicati a tutti coloro i quali il programma stesso è
distribuito, senza la necessità della sottoscrizione di alcuna licenza aggiuntiva.
8. La Licenza Non Deve Essere Specifica per un Prodotto
I diritti legati al programma non dipendono dal fatto che il programma è parte di una particolare
distribuzione software. Se il programma è estratto da tale distribuzione ed è utilizzato o distribuito
rispettando i termini della licenza, tutti coloro ai quali il programma è ridistribuito devono avere i
medesimi diritti che sono conferiti con il software originale.
9. La Licenza Non Deve Limitare Altri Programmi
La licenza non deve imporre restrizioni su altri software che sono distribuiti insieme al software
oggetto della licenza. Per esempio, la licenza non deve insistere sul fatto che tutti gli altri
programmi distribuiti sul medesimo supporto siano software open-source.
10. La Licenza Deve Essere Indipendente dalla Tecnologia
Nessun requisito all’interno della licenza potrà basarsi su specifiche tecnologie o tipologie di
interfaccia.
******************
Per quanto riguarda l’impiego pratico del software open-source, presenta sia aspetti vantaggiosi, sia
alcuni limiti operativi, tipicamente messi in evidenza, rispettivamente, dai sostenitori del
movimento Open Source e da coloro che invece osteggiano tale movimento.
Secondo i suoi sostenitori, il software open source presenta numerosi vantaggi rispetto al software
proprietario, tra cui: il fatto di poter essere direttamente modificato ed adattato; il fatto di essere
oggetto di attenzione da parte di molti utenti, che porta ad una riduzione di errori e bachi nel codice;
in ogni caso, proprio per il fatto che molte persone possono condividere la propria esperienza e la
propria competenza, in caso di problemi la soluzione viene trovata in tempi molto rapidi; il fatto che
sia più facile realizzare prodotti di software in grado di “interoperare” tra loro, grazie all’assenza di
standard proprietari; in generale, il fatto di poter fornire prodotti di qualità, derivanti dalla
collaborazione di più persone che altrimenti non avrebbero potuto condividere le proprie
competenze.
Non manca tuttavia chi vede anche un certo numero di svantaggi nella realizzazione di progetti
open source; le principali critiche sono le seguenti: spesso il software open source non segue i
tradizionali principi di ingegneria del software, portando alla realizzazione di prodotti che, per
quanto funzionanti, sono caratterizzati da incoerenza strutturale, difficoltà di interpretazione del
codice e di modificabilità; i prodotti sono spesso realizzati da esperti e risultano di difficile
comprensione ed utilizzabilità per utenti di minor competenza; non viene effettuata, su ciascun
prodotto sviluppato, una revisione strutturata ed organizzata, così che il software open source non
può essere impiegato per applicazioni critiche, che richiedano cioè una probabilità di errore nulla;
talvolta la documentazione manca, è incompleta o non aggiornata.
2
Software libero
Un software libero è un software che viene distribuito secondo accordi in base ai quali chiunque
può utilizzarlo, modificarlo e distribuirlo a sua volta; è genericamente contrapposto, per le sue
caratteristiche, al software proprietario.
Le caratteristiche che un software deve presentare, relativamente ai termini di distribuzione dello
stesso, per poter essere definito “software libero”, sono state definite da Richard Stallman e dalla
Free Software Foundation; tali caratteristiche sono le cosiddette quattro “libertà fondamentali”:

Libertà 0:
Libertà di eseguire il programma per qualunque applicazione

Libertà 1:
Libertà di accedere al codice del programma e modificarlo

Libertà 2:
Libertà di copiare il programma per aiutare gli altri

Libertà 3:
Libertà di modificare il programma e distribuire pubblicamente le versioni
modificate, così che chiunque possa beneficiarne
Va notato che qualunque software venga distribuito rispettando le quattro libertà fondamentali, può
essere definito software libero, mentre il software open source è quello che viene distribuito
secondo i 10 criteri sopra specificati (nel paragrafo “open source”).
Pertanto, software open source e software libero non sono sinonimi in senso assoluto, ma solamente
nella misura in cui il rispetto delle quattro libertà fondamentali viene sostanziato nell’applicazione
proprio dei criteri dettati dall’open source.
3
GNU General Public License
La GNU General Public License è una licenza per software libero.
All’indirizzo http://www.gnu.org/licenses/gpl.html può essere consultato il testo integrale di tale
licenza.
A titolo riassuntivo, si può affermare che GNU General Public License prevede la distribuzione di
un software nel rispetto delle quattro libertà fondamentali; ciascun utente, nel momento in cui
fruisce di un programma distribuito secondo la GNU GPL, deve consentire a coloro ai quali
fornisce tale programma (o una sua modifica) i medesimi diritti di cui ha goduto lui stesso.
Si consideri, per esempio, il caso in cui un soggetto A realizzi un certo software e ne distribuisca il
codice sorgente tramite la GNU GPL.
Un soggetto B scarica il programma realizzato da A, aderendo quindi alla licenza, lo modifica
aggiungendo delle caratteristiche o migliorando una o più di quelle già esistenti, e lo distribuisce a
sua volta.
Se il soggetto B non rispettasse i termini della licenza, che ha sottoscritto nel momento in cui ha
potuto fruire del programma sviluppato da A, cioè se non fornisse copia del codice sorgente
migliorato, potrebbe subire un’azione legale da parte di A stesso, per il fatto che il software
sviluppato da quest’ultimo è stato distribuito, ancorché in forma modificata, senza il consenso
dell’autore.
Si tratta di un meccanismo legale denominato “copyleft”, per sottolinearne la contrapposizione al
normale diritto di copyright esercitato dagli sviluppatori di software proprietario; in pratica, tramite
la GNU GPL si obbliga ciascun utente a distribuire e rendere disponibile il codice sorgente dei
miglioramenti di un programma acquisito sotto tale licenza (copyleft), pena il rischio di subire
un’azione legale fondata sul copyright.
4
La Tutela Brevettuale del Software
Una maniera totalmente diversa, rispetto a quelle finora prospettate, di approcciare la modalità di
distribuzione commerciale di un software, consiste nel prendere in considerazione la possibilità di
richiedere, ed ottenere se possibile, una protezione di tipo brevettuale su tale software.
La possibilità di ottenere uno o più brevetti volti a tutelare un determinato software non viene
concessa in maniera uniforme dalle varie autorità competenti demandate al rilascio di privative
brevettuali.
A livello italiano, è ormai noto che l’Ufficio emetta rifiuti provvisori – peraltro ben difficilmente
superabili – ogniqualvolta venga depositata una domanda di brevetto avente per oggetto un
software, indipendentemente dagli aspetti tecnici e dalle possibili implementazioni pratiche dello
stesso.
Una posizione diametralmente opposta si riscontra presso l’Ufficio Statunitense, che non pone
abitualmente obiezioni di sorta né relativamente a domande di brevetto su programmi per
elaboratore, né tantomeno in relazione a domande di brevetto sui cosiddetti “methods for doing
business” che, contrariamente alla grande maggioranza dei brevetti depositati nel corso della storia,
non riguardano necessariamente il mondo della tecnica e dell’innovazione tecnologica.
La prassi seguita dall’Ufficio Brevetti Europeo, sulla quale ci dilungheremo maggiormente, segue
una condotta “intermedia” rispetto agli Uffici italiano e statunitense, non negando cioè la
brevettabilità del software a priori, ma verificando alcuni fondamentali requisiti (prima ancora di
quelli, comunque imprescindibili, di novità ed altezza inventiva) per collocare un certo software
nella sfera delle invenzioni considerabili tali dalla Convenzione sul Brevetto Europeo e dalla
giurisprudenza rilevante.
Scendendo in maggiore dettaglio, i programmi per computer sono considerati brevettabili solo con
riferimento ad un effetto tecnico, che deve per sé presentare il requisito dell’altezza inventiva.
Un procedimento rivendicato che comprende un software non è brevettabile, se (i) il procedimento
non influenza il funzionamento fisco o tecnico di un dispositivo; (ii) i dati che vengono processati
non sono parametri operativi di un dispositivo; e (iii) il procedimento non risolve un problema
tecnico (T158/88).
Un metodo matematico è in generale svolto su dei numeri e fornisce un risultato in termini
numerici. Nessun risultato tecnico diretto è prodotto dal metodo in quanto tale. Viceversa, se un
metodo matematico è utilizzato in un processo tecnico, quel processo è svolto su un’entità fisica
(che può essere sia un oggetto materiale, sia un’immagine digitale, sia un segnale elettrico) tramite
certi mezzi tecnici che implementano il metodo e forniscono come risultato una variazione in detta
entità fisica. I mezzi tecnici possono comprendere un computer dedicato o un elaboratore “general
purpose” opportunamente programmato.
La decisione T1173/97 è presa come riferimento per la determinazione della brevettabilità di un
programma per elaboratore.
L’interpretazione proposta – e tuttora seguita – prevede che, alla luce del coordinato disposto dei
commi (2) e (3) dell’Art. 52 EPC, non tutti i software sono esclusi dalla brevettabilità, ma
solamente i software “as such”.
Un programma per computer “as such” è considerato il solo contenuto basico del programma privo
di qualunque funzionalità tecnica, cioè una mera creazione astratta, sprovvista di carattere tecnico.
5
Pertanto, un software sarà brevettabile se presenta un “carattere tecnico”. Quest’ultimo può essere
derivato da un “ulteriore effetto tecnico”, prodotto dal programma quando eseguito su un computer,
detto effetto andando oltre la normale interazione tra programma e computer.
Esempi di tale “ulteriore effetto tecnico” possono essere il controllo di un processo industriale,
l’elaborazione di dati rappresentativi di entità fisiche, o il controllo del funzionamento del
computer.
È pertanto da valutarsi di volta in volta, in funzione delle caratteristiche peculiari di ciascun caso
specifico, la possibilità di richiedere una tutela brevettale per un software di fronte all’Ufficio
Brevetti Europeo.
Va infine notato come la modifica al tenore letterale dell’art. 52(2) EPC, prevista dall’introduzione
della cosiddetta EPC 2000, potrebbe portare, nel corso del tempo, a modifiche nel sopra descritto
orientamento giurisprudenziale.
È ovviamente necessario attendere gli sviluppi futuri del case law per verificare in che misura ciò
potrà accadere.
6
L’oscurazione di siti internet
Qualora dovessero sorgere contestazioni relativamente ad un sito internati, per esempio per la non
liceità dei contenuti del sito, per la violazione di dritti di proprietà intellettuale, ecc. – vi sono
sostanzialmente due aspetti da prendere in considerazione:
a) contestazione del nome a dominio, per esempio perché identico o simile ad un marchio registrato
di terzi, e destinato ad individuare un sito che si colloca nel medesimo settore commerciale del
titolare di detto marchio;
b) contestazione dei contenuti veri i propri del sito, cioè di quello che viene mostrato nelle singole
pagine.
Il primo aspetto viene gestito secondo le note procedure di rassegnazione, di fronte agli enti
competenti per il domain name in questione.
Con particolare riferimento alla seconda opzione, è possibile ottenere che venga imposto al
proprietario del sito di eliminare certi contenuti (magari solo di alcune pagine web, quelle
presentanti il materiale contestato) dal proprio sito.
Nel caso in cui il proprietario non dovesse agire di conseguenza, una volta ottenuta un’ordinanza o
decisione favorevole alla chiusura (o oscurazione del sito), viene imposto al provider di pertinenza
di rendere inaccessibili i contenuti contestati.
Una prima soluzione, abbastanza immediata, si ha nel caso in cui le pagine da eliminare risiedano
fisicamente presso il provider, cioè su una porzione di macchina messa a disposizione dal provider
stesso al titolare del sito; in tal caso il provider è in grado di cancellare tali pagine senza alcuna
difficoltà dal punto di vista tecnico.
Se invece il provider non gestisce direttamente i contenuti contestati, può comunque modificare i
propri files di zona, così che questi ultimi non puntino più sul sito incriminato.
In maggiore dettaglio, i files di zona sono quei files che contengono i record DNS (Domain Name
System) per gli host della rete. I record DNS consentono di trasformare i nomi degli host in indirizzi
IP e viceversa, di definire i server di posta e di specificare molte altre informazioni; la conversione
di un nome a dominio nel corrispondente indirizzo IP viene anche indicata come “risoluzione” del
nome a dominio.
Ciò che viene tecnicamente ordinato al provider è di modificare i files di zona, così che venga
rimosso l’indirizzo IP della macchina (fisica o virtuale) sulla quale il sito contestato è residente, in
modo che lo stesso non sia più raggiungibile dagli utenti della rete. Infatti, la richiesta di
connessione ad un sito oscurato comporta una ricerca, da parte del DNS, dell’indirizzo IP al quale
connettere la macchina richiedente affinché le pagine richieste siano scaricate; nel momento in cui il
corrispondente indirizzo IP non è reperibile, viene visualizzato un messaggio di errore.
Alternativamente, è possibile re-indirizzare tale domain name su (cioè modificare l’indirizzo IP
relativo a tale domain name in modo che si connetta ad) una pagina opportunamente predisposta,
nella quale viene accennato alla chiusura del sito ed alle motivazioni della stessa.
Marzo 2007
7