GUIDA OPEN SOURCE:
Guida pratica per strategie e servizi
Open Source di e-Government
nella P. A. locale
Guida originale in lingua inglese:
Thematic guide “Open Source Software in Public Administrations” Progetto europeo PRELUDE coordinato da CEMR (2004)
con il supporto di ELANET finanziato dal progr. IST-FP5 della Commissione Europea
Autori:
General advice and development guide
Alasdair Mangham
Arturo Dell
Lee Denison
Enquiries to the authors of this section should be addressed to [email protected].
Floss licensing guide (terza sezione e appendice 1)
Maureen O’Sullivan BA, BCL, LLM,
Lecturer in Law, UWE, Bristol,
Co-ordinator of Free Software Consortium Legal Governing Body,
Senior Legal Counsel to ELANET.
Enquiries on this section should be addressed to [email protected].
D.ssa Flavia Marzano (appendice 2)
Dr. Francesco Carbone (appendice 2 e 3)
Coordinamento tecnico:
Francesca Romana Strinati
Progetto Grafico:
Francesco Botteri
Testo tradotto ed adattato da Ancitel (Javier Ossandon).
Le Guide ADL di Ancitel sono soggette alle condizioni stabilite dalla licenza Creative Commons “Attribuzione non commerciale - non opere derivate 2.5”
(http://www.creativecommons.org/licenses/by-ncnd/2.5/deed.it).
Copyright © Ancitel SpA 2006
INDICE
Presentazione
Introduzione
..................................................................................................................................................................
...................................................................................................................................................................
PRIMA SEZIONE Decidere di utilizzare l’Open Source
.........................................................
7
10
11
..................................... 11
1
Applicazioni e-Governament ed applicazioni Open Source
1.1
Organizza il tuo business-case
1.2
Come fare il calcolo del TCO (costo totale di possesso del software)
1.3
L’Open Source offre una nuova modalità di gestione del
costo totale di possesso(TCO) ............................................................................................................... 15
............................................................................................................ 12
.............. 12
1.3.1 Acquistare o Sviluppare - Come decidere se sviluppare interamente
un’applicazione oppure lavorare su un’applicazione OS che già esiste
1.3.2 L’Open Source può avere dei limiti
........ 15
............................................................................................. 15
1.3.3 Adattare il progetto o adattare il software - Il software OS è flessibile,
ma come si può sapere se risulta sempre una buona idea ....................................... 16
1.4
La ricerca del software OS
1.5
Attenzione al Mozilla mutants
1.6
Cercare progetti su Source Forge
1.7
Altri siti che raccolgono progetti OS
2
Quando un progetto OS è realizzabile
2.1
Criteri di fattibilità
.................................................................................................................... 17
.......................................................................................................... 19
...................................................................................................
...........................................................................................
21
.....................................................................................................................................
21
2.1.2 La qualità della documentazione
............................................................................
21
..................................................................................................
21
2.1.3 Il controllo del nucleo del codice sorgente
Open Standards
2.2.2 Obiettivi concreti
................................................................................................................................... 23
.......................................................................................................................................... 23
................................................................................................................................................. 23
3
La torre di babele binaria
4
Comprare software
Le guide di Ancitel
............................................................................ 22
............................................................................................................................................... 22
2.2.1 Associare la necissità
2.2.3 Più alternative
20
....................................................................................
2.1.1 La dimensione della comunità di sviluppo
2.2
20
...................................................................................................................... 24
.................................................................................................................................... 25
3
4.1
Come comprare ciò che è già free. Come creare un livello di concorrenza tra
software OSS e software propietario quando si apre una gara d’appalto ... 25
SECONDA SEZIONE Implementazione di applicazioni Open Source
....................
27
5
Sviluppo
5.1
Introduzione
5.2
La Design Authority (DA): l’organo d’indirizzo tecnico
della Direzione del progetto ............................................................................................................. 27
................................................................................................................................................................. 27
...................................................................................................................................................... 27
5.2.1 Ruolo .............................................................................................................................................................................27
5.2.2 Membri
.................................................................................................................................................................... 28
5.2.3 Funzione e potere
5.2.4 Linguaggio
......................................................................................................................................... 28
......................................................................................................................................................... 28
5.2.5 Attività .........................................................................................................................................................................30
5.2.6 Prodotti
.................................................................................................................................................................... 31
5.3
Il piano generale di Compatibilità: la guida tecnica del progetto
5.4
Comitato di Controllo della Qualità
..................... 31
............................................................................................ 31
5.4.1 Ruolo .............................................................................................................................................................................31
5.4.2 Membri
.................................................................................................................................................................... 32
5.4.3 Partner per la Quality Assurance “Partner QA”
5.4.4 Verifica
.................................................................. 33
................................................................................................................................................................... 34
5.4.5 Funzione e potere ..............................................................................................................................................34
5.4.6 Linguaggio
5.4.7 Attività
5.4.8 Prodotti
5.5
........................................................................................................................................................... 35
..................................................................................................................................................................... 35
..................................................................................................................................................................37
Raccomandazioni generali .........................................................................................................................37
5.5.1 Rilascio anticipato
5.5.2 Code freeze
.......................................................................................................................................... 38
......................................................................................................................................................... 38
5.5.3 Strumenti di collaborazione on-line
............................................................................................ 38
6
Modelli di sostenimento ..............................................................................................................................38
6.1
Gruppi di utenza
............................................................................................................................................ 38
6.1.1 Creazione di sottogruppi: (tecnico, training, standards, di accessibilità)
.... 40
6.2
Capacità In-house
6.2.1 Sviluppo
.............................................................................................................................................. 40
.................................................................................................................................................................. 41
6.3
I test sulla documentazione a carico del gruppo di sviluppo interno
6.4
Modelli di supporto
.............. 41
................................................................................................................................... 41
6.4.1 JBoss ...............................................................................................................................................................................41
6.4.2 MySQL
...................................................................................................................................................................... 42
6.4.3 Red Hat Linux
.................................................................................................................................................... 42
TERZA SEZIONE Attribuire licenze al software Open Source
......................................
43
..................................................................................................................................................... 43
7.1
Introduzione
7.2
Considerazioni preliminari .........................................................................................................................43
7.3
Dove trovare le licenze FLOSS
7.4
Perche assegnare le licenze?
7.5
Le licenze BSD
.............................................................................................................. 44
................................................................................................................ 45
................................................................................................................................................. 46
7.5.1 Vantaggi .....................................................................................................................................................................47
7.5.2 Svantaggi
7.6
............................................................................................................................................................... 47
La licenza GNU General Public License (GNU GPL)
7.6.1 Vantaggi
............................................................. 47
............................................................................................................................................................... 49
7.6.2 Svantaggi ...................................................................................................................................................................50
7.7
Il contributo “Creative Commons”
7.8
Problemi comuni delle licenze FLOSS
7.9
Raccomandazioni per gli enti locali e regionali
coinvolti nello sviluppo del FLOSS ................................................................................................ 52
................................................................................................. 50
........................................................................................... 51
7.9.1 Licenze BSD ..............................................................................................................................................................52
7.9.2 Utilizzo delle licenze GNU GPL
7.9.3 Utilizzo della doppia licenza
........................................................................................................... 52
................................................................................................................ 52
8
Perchè avere una legge separata (direttiva) per le
FLOSS in ambito Unione Europea ................................................................................................. 52
9
Temi suggeriti per una direttiva FLOSS ..........................................................................................54
APPENDICE 1: Esempio di free software act (propedeutico ad
una direttiva europea) ................................................................................................... 56
Le guide di Ancitel
5
APPENDICE 2: Le licenze nel dettaglio
................................................................................................. 59
APPENDICE 3: Normativa di riferimento per OSS
6
................................................................... 92
Le guide di Ancitel
PRESENTAZIONE
Quando ANCITEL ha deciso di pubblicare queste linee guida per la pubblica
amministrazione locale e regionale sull’open source, abbiamo pensato non soltanto
di sfruttare al meglio una delle migliore iniziative sviluppate in Europa dalla nostra
rete europea ELANET (CEMR), ma anche di produrre uno strumento che serva non
soltanto agli sviluppatori di software interni all’Amministrazione o alla sempre più
estesa rete di supporto ed assistenza tecnica che le gira attorno, ma anche agli amministratori e a tutti quelli che negli enti locali hanno a che fare con questo nuovo fenomeno dei servizi pubblici sotto licenza open source. Inoltre, sono state fatte due considerazioni fondamentali:
● Non c’è ancora abbastanza conoscenza in Italia sul valore reale dell’Open Source
e quindi, si fatica a presentarlo come una valida alternativa al software proprietario;
●
L’attuazione di strategie di progetto che mettono al centro il software Open
Source, non può essere soltanto una prerogativa delle grandi amministrazioni
che hanno tutte le risorse necessarie, ma deve diventare una possibilità per i piccoli Comuni, soprattutto con la nascita dei Centri di Servizi Territoriali. Si richiede un approccio corretto ai problemi, valutando i benefici e i rischi che comporta una tale scelta e soprattutto mettere in moto una vera e propria “governance” del processo.
Occorre essere consapevoli, che un software può essere di buona, o cattiva
qualità indipendentemente dal fatto che sia prodotto in un ambiente Open Source
o in un ambiente proprietario. Inoltre, il costo totale di possesso del software
Open Source (sviluppo/acquisizione + utilizzo + formazione + supporto tecnico e
manutenzione, altre) non è inferiore a quello del software proprietario. Tuttavia,
l’investimento iniziale è sensibilmente più basso e non ci sono costose licenze commerciali da pagare. Il software di partenza, da modificare in base alle proprie
necessità viene scaricato liberamente.
Ma quali sono dunque i benefici per la pubblica amministrazione locale?
Ne 2003, il progetto “Three Roses” finanziato dalla Commissione Europea
cominciò ad analizzare questo tema ed a costruire una roadmap per l’implementazione di FLOSS (free-libre open source software) nel settore pubblico (rif:
www.prelude-portal.org/3roses). Il progetto è stato coordinato dal Consiglio dei
Comuni e Regioni d’Europa (CEMR) con il supporto della rete europea ELANET,
coordinata da ANCITEL, ed ha coinvolto altre 2 network europee per l’eGovernment
e la Società dell’Informazione: eris@ e TeleCities. Sono stati organizzati diversi workshop con un numero importante di membri della comunità Open Source, di centri
di ricerca e dell’industria ICT, della piccola e media impresa, nonché rappresentanti di amministrazioni locali e regionali che già utilizzano l’OS.
La licenza Open Source più nota ed utilizzata è la GNU-GPL, che autorizza il
libero accesso ai software disponibili sul mercato, sia software di base come il sisteLe guide di Ancitel
7
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
ma operativo LINUX che le singole applicazioni/servizi, l’unico vincolo è quello di
mettere a disposizione della comunità di utenti che fa uso di soluzioni open source le modifiche effettuate sul software originale. Negli ultimi anni, sono diventate
sempre più popolari le licenze scritte all’interno dell’iniziativa “Creative Commons”
. Non esiste una visione unica sulle licenze e quindi i vincoli che vengono proposti
possono essere più o meno restrittivi. Tuttavia tutti tendono a preservare il principio fondamentale, il libero accesso al software ed al codice nel quale è stato scritto.
Le ultime pagine della guida affrontano il problema di proteggere le licenze
FLOSS (free-libre open source software) da eventuali conflitti legali in tribunale, in
modo che la legalità ed i vincoli delle licenze vengano rispettati. A questo riguardo viene richiamata l’attenzione delle autorità europea per la promulgazione di
una direttiva europea a tutela dell’open source.
L’Open Source diventa sempre più importante per la condivisione e/o il riuso
delle migliori pratiche tra le Pubbliche Amministrazioni. Infatti, l’Open Source crea
un valore aggiunto per qualsiasi Amministrazione che mette a disposizione di altre
amministrazioni il codice software di una applicazione/servizio . La licenza garantisce a questa amministrazione la possibilità di sfruttare qualsiasi miglioramento che
venga fatto al software.
In sintesi, i vantaggi che vengono attribuiti all’utilizzo di soluzioni open
source sono i seguenti:
● L’investimento iniziale è più basso;
●
Il rischio di rapido invecchiamento della tecnologia diminuisce grazie ai costanti
miglioramenti, nonché alla minore dipendenza da strategie di produzione del
software commerciale;
●
Permette di adattare il codice sorgente senza prendersi la responsabilità di sviluppo del software per intero (importante specialmente per piccole/medie organizzazioni);
●
Favorisce, sotto certe condizioni, la crescita delle PMI hi-tech nel settore ICT, che
svolgeranno una funzione di assistenza tecnica e supporto alle pubbliche amministrazioni locali che utilizzano una soluzione open source;
●
Tralasciando ogni discussione sui costi del software Open Source in relazione al
software proprietario, resta il fatto che sia il guadagno economico (legato
all’adattamento e miglioramento del software) che le nuova conoscenze acquisite rimangono in casa, cioè nel territorio, dove il software viene utilizzato,
migliorato e aggiornato.
La strada per attuare una strategia di open source richiede una politica attenta e
consapevole. Per venire incontro a quest’esigenza di rigorosità, la prima e seconda
parte della Guida sono state scritte da un gruppo di lavoro che ha implementato
con successo una tale strategia nel piccolo Comune inglese di “Camden” (area
metropolitana di Londra). La terza parte relativa alle licenze è stata preparata dalla
8
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
D.ssa Maureen Sullivan, giurista e Presidente del Open Source Consortium ed integrata, soprattutto nella parte relativa ai “creative commons” da esperti Ancitel. La
guida è stata precedentemente pubblicata in lingua inglese all’interno del progetto europeo “Prelude”, coordinato da ELANET (CEMR) e finanziato dalla
Commissione Europea come misura d’accompagnamento nel programma IST, il
quale ha avuto come finalità la promozione della ricerca e l’innovazione in ambito
locale e regionale. La presente guida presenta delle modifiche in funzione della
realtà italiana.
Javier Ossandon
Direttore Area Innovazione di ANCITEL
Presidente della rete europea ELANET (CCRE)
Le guide di Ancitel
9
INTRODUZIONE
Se non si conosce bene l’Open Source, la prima volta si può avere l’impressione di
essere in un ambiente con non poche contraddizioni. L’Open Source è sia un movimento sociale che tecnologico che è stato sottoposto ad un processo di politicizzazione come poche altre tecnologie software. Infatti, risulta spesso difficile avere un consiglio imparziale sui meriti di un determinato tipo di tecnologia Open Source rispetto
ad un’altra, oppure su una soluzione Open Source che si presenta come alternativa ad
un’altra fornita da una software house sotto licenza proprietaria.
Lo scopo di questa guida non è dimostrare che il software Open Source sia meglio
di altri, nè quello di fare una valutazione del software OS rispetto al software proprietario. L’obiettivo è invece quello di fornire alle persone che si occupano di eGovernment negli Enti Locali, orientamenti e metodologie finalizzate alla gestione di
un processo di informatizzazione basato su soluzioni OS, allo scopo di proporre delle
alternative valide ai loro amministratori.
●
Fatta questa premessa il lavoro è stato suddiviso in tre parti.
La prima parte Decidere di utilizzare la soluzione Open Source, riguarda le regole
generali su quando e come utilizzare OS per sviluppare applicazioni e-government.
A causa della diversità delle regole locali sull’acquisizione di beni in Europa questa
guida ha un carattere generale;
● La seconda parte Implementazione di applicazioni Open Source, contiene alcuni
suggerimenti molto tecnici su come procedere per gestire il proprio progetto una volta
stabilito di intraprendere la strada dell’Open Source;
● la terza parte Attribuire licenze all’Open Source, contiene uno studio su alcune delle
licenze OS più popolari.
Il documento descrive la ricerca e i risultati del progetto Three Roses (www.prelude-portal.org/3roses), nonché l’esperienza raccolta dagli autori nel lavorare su numerosi progetti OS. Il documento è rivolto a persone che prendono in considerazione
l’implementazione, o lo sviluppo di applicazioni Open Source per scopi di eGovernment, ma non descrive la migrazione di servers, o desktop applications ad un
ambiente Open Source, in quanto questo argomento è già stato trattato nel rapporto IDA “Open Source Migration guidelines” (il relativo manuale di 148 pagine può
essere scaricato in lingua inglese dal sito Europa al seguente indirizzo http://ec.europa.eu/idabc/en/document/2623) .
Lo sviluppo di applicazioni e-Government utilizzando tecnologie Open Source può
portare diversi benefici all’Amministrazione, ma come ogni progetto di sviluppo non
è esente da rischi, ed è importante valutare le modalità per gestirli. Questo documento fornisce un piano guida generale (framework) per gestire questi progetti in modo
da assicurare un alto livello di successo.
10
Le guide di Ancitel
PRIMA SEZIONE
Decidere di utilizzare l’Open Source
1
Applicazioni e-Government ed applicazioni Open Source
Lo studio realizzato dal progetto “Three Roses” ha messo in evidenza tre motivazioni principali per la pubblica amministrazione locale al fine di decidere di adottare l’Open Source:
a. Politica – in alcuni casi la decisione di scegliere le tecnologie Open Source è
stata una decisione esclusivamente politica mentre in altri casi è stato un modo
per stimolare la crescita dell’economia locale, aprendo un mercato alle società
di software locali.
b. Costi – il costo per l’aggiornamento delle applicazioni in loco, oppure per l’acquisto di nuove applicazioni dalle società di software proprietario hanno
costretto le amministrazioni a considerare l’Open Source come una possibile
alternativa per abbattere i costi.
c. Assenza di una alternativa già pronta sul mercato – l’e-Government ha portato
le amministrazioni locali a considerare nuovi tipi di servizi ai cittadini. In molti
casi, la fornitura di questi servizi per via digitale è così complessa che non si
trova sul mercato una soluzione già pronta ideata dal software proprietario.
Nell’implementare una soluzione Open Source, ciascuno dei punti di partenza
enunciati ha un certo livello di rischio, in ciascuno di essi si devono comunque
compiere i seguenti passi fondamentali:
a. Organizzare il proprio business case;
b. Lavoro di ricerca;
c. Procurare quanto risulta necessario;
d. Dare una configurazione al proprio team interno;
e. Cominciare a lavorare nella strategia di sostenibilità del progetto.
Per capire meglio i diversi tipi di rischio a cui si viene incontro conviene suddividere le applicazioni di eGovernment in due principali categorie:
a. Applicazioni che pongono l’accento sul miglioramento dell’efficienza del governo locale, normalmente utilizzando la tecnologia come parte di un processo di
reingegnerizzazione della macchina comunale;
b. Applicazioni che pongono l’accento sull’efficacia del governo locale, utilizzando la tecnologia per fornire servizi innovativi verso i cittadini.
Le guide di Ancitel
11
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Nel primo caso, le tecnologie da utilizzare saranno essenzialmente quelle
finalizzate alla gestione di processi. Questi tipi di tecnologie forniscono applicazioni del tipo:
a. Gestione dei flussi documentali nei processi di lavoro (workflow);
b. Pubblicazione di documenti ed immagini;
c. Archivio elettronico dei dati;
d. Gestione del rapporto con i cittadini (CRM);
e. Gestione delle risorse umane e della contabilità;
f. Sistemi di pagamento dei tributi;
g. Sistemi di gestione della clientela che affitta delle proprietà comunali;
h. Sviluppo di “middleware”.
Queste applicazioni raggruppate dal punto di vista dell’efficienza, sono valide
soltanto le prime due motivazioni indicate all’inizio, in quanto si tratta di applicazioni Open Source già abbastanza mature e conosciute nel mercato.
Nel secondo caso, cioè dell’efficacia, le tecnologie implicate sono le tecnologie web con applicazioni del tipo:
a. Sistemi web di gestione dei contenuti;
b. eParticipation (partecipazione via web alle decisioni locali);
c. Voto elettronico;
d. Piattaforme web di formazione a distanza;
e. Web services applications (applicazioni di servizio web).
Trattandosi di applicazioni raggruppate dal punto di vista dell’efficacia nell’azione di governo, è probabile che si presenti la terza motivazione per decidersi
per l’open source, cioè la mancanza di una soluzione già pronta sul mercato.
Essendo la componente di rischio nello sviluppo di una soluzione innovativa sempre alto, è più probabile che nel vostro business case la soluzione sviluppata in
ambiente Open Source sia quella che offre un livello di rischio minore.
1.1 Organizza il tuo business-case
Le motivazioni essenziali di base per decidere di utilizzare OS sembrano adesso più chiare. Ma forse avete pensato anche la possibilità di utilizzare soluzioni OS
insieme a delle soluzioni proprietarie. Questo approccio ha dei rischi notevoli,
soprattutto se non si hanno le capacità interne per capire quali sono le differenze
tra le diverse licenze e tra le diverse strategie utilizzate dalle società software per
vendere i loro prodotti ed offrire il pacchetto di supporto/assistenza tecnica.
1.2 Come fare il calcolo del TCO (costo totale di possesso del software)
Da una prospettiva di marketing, una parte sostanziale della discussione
sull’Open Source si è concentrata sul costo totale di possesso (TCO – Total Cost
12
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Ownership) in confronto a quello del software proprietario. Questo approccio non
serve a molto in quanto risponde a degli scenari di carattere generale che sono
propri dell’America e che hanno una vaga somiglianza con i problemi reali affrontati da chi si occupa di qualcosa di molto specifico, come l’eGovernment.
Il costo maggiore nello sviluppo in ambiente Open Source sono le persone.
Se l’attività di sviluppo viene curata direttamente da voi, avete bisogno di contattare sia programmatori sia manager di progetto che abbiano accumulato sufficiente esperienza nella gestione di progetti di sviluppo. Altrimenti è necessario
avviare un’iniziativa per formare internamente delle persone che corrispondano a
questi due profili. Se si decide di utilizzare una società che ha la capacità di sviluppare software in ambiente OS, allora bisogna risolvere dall’inizio la questione su
come verrà mantenuto in futuro il codice software di base, cioè dopo che è stato
completamente sviluppato dalla società. Diversi tipi di applicazioni hanno bisogno
di livelli di supporto anche diversi. Si deve tener presente che sono poche le società OS che hanno la possibilità di offrire un supporto per via telefonica e che la
maggior parte di esse fornisce invece un supporto per posta elettronica. Per questo è importante portare avanti il proprio progetto contattando oppure preparando adeguatamente una propria risorsa che si occupi del futuro mantenimento dell’applicazione anche quando il supporto è esterno.
Nel calcolo del vostro TCO, è necessario considerare tutti gli elementi che si
presentano, compresa la longevità dell’hardware nonché il livello d’intervento che
il sistema richiederà per funzionare nel tempo. Come regola generale, si può affermare che molte delle applicazioni proprietarie relative alla categoria del governo
efficiente, hanno probabilmente un TCO più basso del costo che ha lo sviluppo di
una propria alternativa Open Source.
Questa regola è soprattutto valida quando sono presenti i seguenti fattori:
1. L’applicazione è già ampiamente utilizzata nel settore pubblico o nel settore di
business;
2. L’implementazione dell’applicazione non richiede modifiche o adattamenti di
nessun genere;
3. Si rendono necessari solo interventi minori da parte di chi avrà la responsabilità
di amministrare il sistema, poiché si tratta di un software abbastanza maturo e
privo di bachi;
4. Esiste un contratto tipo su base commerciale per la manutenzione del software;
5. Sono presenti più fornitori per quel tipo di applicazione e non uno soltanto, quindi, c’è una situazione di concorrenza sul mercato per acquistare a prezzi competitivi con un adeguato ritorno sul piano qualitativo;
6. Non è il caso di una grossa società OS (con ciò s’intende una società presente
sul mercato azionario) che fa il suo business proprio con questo prodotto o
applicazione.
Le guide di Ancitel
13
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Malgrado quanto detto, conviene sottolineare che il costo di sviluppo di una
alternativa in proprio può ridursi notevolmente, anche in forma drastica, se la strada intrapresa è quella di condividere i costi di sviluppo e di manutenzione dell’applicazione con altre amministrazioni locali. In questo caso, si innesca un modello di
gestione economica che non ha di solito paragoni rispetto ad una soluzione basata invece sul software proprietario. Ad esempio, un gruppo di 10 Comuni dove ciascuno di essi ha un singolo sviluppatore di software, potrebbe concordare che ogni
sviluppatore dedichi un giorno a settimana al progetto comune. Ciò permetterebbe di avere 2 settimane-uomo di lavoro per il progetto in ciascuna settimana. In
sintesi, se l’approccio finalizzato alla condivisione è quello adottato, allora il TCO
della soluzione Open Source diventa inferiore a quello del software proprietario.
Per la maggior parte dei Comuni tutto questo rappresenta un nuovo modo di
lavorare nel settore delle nuove tecnologie. Infatti, si richiede a monte una decisione in comune sia sulla necessità condivisa di avere un determinato applicativo, sia
sul come dovranno essere suddivisi i costi di sviluppo e di manutenzione dell’applicazione. Per contro i benefici che si riuscirà a tirare fuori possono diventare assai
importanti.
Si veda il caso della applicazione LGOLnet (www.lgolnet.org) che è parte del
progetto UK Local Authority Websites (portali web della P.A. locale www.laws.org). L’applicazione LGOLnet è un middleware che contiene una soluzione per la messaggistica costruita sugli stessi principi di prodotto come l’IBM Q messaging system o Microsoft Biztalk. Attraverso la sua rete, LGOLnet gestisce messaggi e richieste provenienti dai diversi Sistemi collegati (back-end), permettendo
così a questi (prima del tutto incompatibili) di parlarsi tra loro. Ci sono ancora altri
potenziali benefici, come ad esempio, la posta elettronica sicura. Questo prodotto
è disponibile sotto licenza Open Source e come in tutti i sistemi di messaggistica,
il vero costo riguardarebbe lo sviluppo dei collegamenti alla rete del back-office dei
diversi Sistemi in periferia. Invece, quello che fa di LGOLnet una soluzione valida è
la sua capacità di offrire uno schema per collegare insieme i diversi Sistemi di back
office senza nessun costo. La soluzione software è stata implementata sia da
gruppi di Comuni che hanno pagato insieme lo sviluppo del collegamento ai loro
back-office e messo quanto sviluppato in condivisione, sia da società private che
hanno fornito i collegamenti ai loro sistemi. Ad esempio, Anite (www.anite.com),
un fornitore molto conosciuto di sistemi di contabilità per la gestione delle locazioni sulle case di proprietà comunale ha fornito a LGOLnet i loro connettori in
forma gratuita, valutando non solo il servizio fornito all’utente da LGOLnet, ma
anche il fatto di voler fornire i propri prodotti con un’ulteriore valore aggiunto.
Nel caso di applicazioni che riguardino l’efficacia dell’azione di governo, la regola
è che il TCO della soluzione sviluppata in ambiente l’Open Source è di norma inferiore a quello del software proprietario.
Questa alternativa si basa nei seguenti presupposti:
a. Non esiste un sistema utilizzato dai privati o dal settore pubblico che corrisponda
ai requisiti da voi cercati;
14
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
b. C’e la capacità interna a livello dell’Ente Locale oppure presso un fornitore presente sul territorio per sviluppare la soluzione in ambiente Open Source.
1.3 L’Open source offre una nuova modalità di gestione del costo totale di
possesso (TCO)
1.3.1 Acquistare o Sviluppare – Come decidere se sviluppare interamente
un’applicazione oppure lavorare su un’applicazione OS che già esiste
Nell’approccio ad un progetto Open Source, gran parte dell’attenzione è di
solito rivolta alla decisione di realizzare la migliore versione esistente di un determinato sistema. Ciò si deve in parte al community movement sul quale poggia in
forma intrinseca tutto il progetto di sviluppo Open Source. Infatti, per alcuni sviluppatori in ambiente Open Source, nulla è più soddisfacente che vivere il processo che va dal prendere in mano un progetto, scegliere il linguaggio di sviluppo, fornire un’idea alla comunità di sviluppo a seguire la loro visione del progetto e osservare la graduale espansione della comunità di sviluppatori interessati fino alla pubblicazione dell’applicazione su Sourceforge. Indubbiamente Sourceforge è il
migliore risultato per il proprio progetto di e-Government. Se si dà una rapida
occhiata alla realtà dei fatti su Sourceforge (www.sourceforge.org), da una veloce
lettura è facile accorgersi che ci sono già migliaia di altri progetti che hanno cominciato in questo modo.
Per risparmiare tempo e risorse occorre prima cercare di vedere se c’è già un
progetto OS nella lista di Sourceforge che sta affrontando la maggior parte oppure tutti i requisiti del proprio business case. Se non si riesce a trovare un’applicazione con i requisiti desiderati conviene allora scomporre questi requisiti in componenti di un sistema e cercare di trovare dei toolkits open source che soddisfino ciascun componente in parte o per intero.
Un “toolkit” è un pacchetto di componenti sviluppati, i quali possono essere
incorporati in una nuova applicazione (o che possono essere utilizzati per costruire sopra un’applicazione). Questo è un modo sicuramente più veloce di sviluppare
la soluzione software, rispetto a quello di creare interamente la propria applicazione partendo dal nulla. Tale strada può anche dare una certa protezione contro il
rischio di trovarsi con un’applicazione Open Source di cui solo la società sviluppatrice è in grado di occuparsene, sia per quanto riguarda il supporto tecnico che la
manutenzione.
1.3.2 L’Open Source può avere dei limiti
Lo sviluppo di modelli di business legati all’Open Source è ancora all’inizio.
L’opinione comune è che l’unico modo per far soldi con il software Open Source
consiste nel fornire servizi ed espertise nell’attività di installazione del software. Ciò
può riguardare l’integrazione del software open source con altri software o anche
la possibilità di farlo diventare parte di un sistema hardware che acquisisce così un
ulteriore valore aggiunto. Uno dei rischi nascosti di cui occorre tener conto è la
Le guide di Ancitel
15
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
possibilità che il software venga utilizzato come un modo per vincolare l’utenza,
attraverso un contratto di fornitura di servizi esclusivi.
Uno scenario tipico è quello della società che fornisce un software con licenza
Open Source, costruito in modo tale da impedire a chiunque (al di fuori della società stessa) di poter dare un supporto tecnico all’applicazione, costringendo l’utente
ad accettare un contratto di supporto tecnico a lungo termine, il quale potrebbe
costare tanto quanto l’acquisto di una licenza di software proprietario. La licenza
stessa non contempla di per se l’obbligo a carico del fornitore di dare alcuna documentazione relativa al codice.
Anche per questo, l’attività di gestione del progetto dovrebbe continuamente
insistere sull’aggiornamento e la revisione della documentazione che viene prodotta
e soprattutto accertarsi che le diverse consegne concordate nell’arco di vita del progetto siano supportate da un’adeguata documentazione. Accade spesso che la produzione della documentazione venga lasciata per l’ultimo momento quando non ci
sono più i tempi tecnici per le scadenze imminenti di fine progetto. Il risultato è nefasto: la documentazione di supporto finisce per essere tralasciata compromettendo in
modo non indifferente la piena riuscita dell’iniziativa.
La licenza OS offre una protezione nel caso in cui il fornitore del software originale fallisce o viene acquistato da un terzo. Tuttavia, la licenza non diventa in
verità molto utile se non si ha avuto la cura di gestire il progetto in modo tale da
rendere fattibile che altri sviluppatori possano prelevare il codice software per continuare e/o completare lo sviluppo.
1.3.3 Adattare il progetto o adattare il software – Il software OS è flessibile,
ma come si può sapere se risulta sempre una buona idea
Il problema della maggior parte dei software proprietari sviluppati per il settore privato è che non sono di facile adattamento per il settore pubblico. Questo per
due motivi principali:
a. le aziende del settore privato scelgono i loro clienti e conoscono i loro bisogni
mentre il settore pubblico ha l’obbligo di fornire servizi a tutti i cittadini;
b. il settore privato è molto attento ai processi di reingegnerizzazione di un business, mentre il settore pubblico non lo è affatto.
Il risultato di tutto questo è che quando le organizzazioni del settore pubblico
utilizzano un’applicazione sviluppata per il settore privato, finiscono per spendere
molto tempo e denaro per modificare ed adattare il software alle forme di gestione delle procedure alle quali sono abituate. L’adattamento di una applicazione non
fa parte dell’attività principale dell’azienda della società di software che ha vinto
l’appalto. Ciò determina che il software applicativo avrà bisogno di nuovi adattamenti ogni qualvolta la società dovrà aggiornare il codice (p.es. l’aggiornamento o
il cambio di un sistema operativo di base utilizzato dall’applicativo) per evitare il
rischio di diventare obsoleta. Questo genera costi, di solito elevati, per l’utente e/o
società che ha comprato e/o modificato l’applicazione originale.
16
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Di solito si presume che le tecnologie Open Source risolvono questo problema,
ma chi pensa così sbaglia. Sebbene l’Open Source offre la possibilità di cambiare
alcuni modelli di costo riguardanti le modifiche del software, il problema fondamentale resta lo stesso: cioè, è altrettanto vero che qualsiasi modifica dell’applicazione
produce delle complicazioni per aggiornare il software originale che sta alla base.
In qualsiasi caso, la sostenibilità è un aspetto centrale del progetto ed è quindi, molto importante che ci sia un attento studio sul merito all’inizio del progetto
per non trovarsi dopo in una situazione dove si è scelto un progetto OS dietro il
quale ci sono pochi esperti capaci di affrontare ulteriori sviluppi o di fare dei cambiamenti futuri al sistema.
Se si affronta l’appalto di un progetto di software Open Source con lo stesso
rigore con cui si prepara una gara di appalto di software proprietario, è molto probabile che il costo totale di possesso che uscirà fuori sia quanto meno allo stesso
livello di quello del software proprietario.
Le differenze essenziali tra software Open Source e software proprietario sono
quindi di natura diversa, in sintesi:
a. il diritto di modificare o cambiare il codice sorgente;
b. il diritto di distribuire a terzi il codice sorgente.
Quando si prende in considerazione la possibilità di utilizzare un software Open
Source, i due punti appena indicati dovrebbero essere al centro del vostro piano di
“business” (sfruttamento del software). Essi sono quelli che fanno la differenza nel
calcolo del costo totale di possesso (TCO - Total Cost of Ownership). Il TCO
dell’Open Source può essere considerato come inversamente proporzionale alla
estensione che ha la comunità di sviluppatori che ha fatto dell’applicazione una
parte del suo proprio bagaglio applicativo. Più si diffonde un’applicazione open
Source più basso tende ad essere il TCO.
Il consiglio forte è quello di avere un approccio verso i progetti Open Source
che privilegia la sua realizzazione come parte di una partnership dove collaborano
varie amministrazioni locali. Come si vedrà nella parte più tecnica di questo documento, la capacità per condividere delle conoscenze e dei rischi sono i due aspetti che permettono di ottenere un vero guadagno quando si decide di implementare una soluzione basata su software OS.
1.4 La ricerca del software OS
Una volta chiariti i rischi ed i benefici della soluzione Open Source è arrivato il
momento di entrare nel dettaglio. Non è consigliabile passare direttamente dalla
fase di “business case” alla fase di ricerca/acquisizione del software senza prima
fare delle considerazioni sullo sfruttamento (business plan).
Presa la decisione di sviluppare e/o implementare un’applicazione Open Source
conviene effettuare una ricerca più accurata e anche diversa da quella che viene
Le guide di Ancitel
17
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
effettuata quando si tratta di acquistare software proprietario. Questo perché non
è possibile affidarsi del tutto alla dimostrazione di prodotti che i potenziali fornitori
presentano, ansiosi che si prenda in considerazione la loro applicazione. Pochi produttori/distributori di applicativi Open Source producono una documentazione
accattivante sul proprio prodotto e sono ancora meno quelli in grado di organizzare un team preposto alla distribuzione in grado di persuadere i potenziali utenti/sviluppatori sulla buona qualità del loro prodotto rispetto a quello della concorrenza.
Anche se le società di sviluppo OS si trovano in un momento nel quale stanno ricavando un buon profitto, predomina sempre l’aspetto tecnico su quelli più prettamente “commerciali” (management e distribuzione), non essendo nelle loro abitudini la realizzazione dei progetti nei quali viene esaminato in modo appropriato lo
sfruttamento sul mercato del prodotto creato.
Se non si ha alcuna conoscenza riguardo al software Open Source, ci sono dei
buoni siti per cominciare a raccogliere informazioni, come www.opensource.com e
www.gnu.org. Anche la Commissione Europea ha un osservatorio sulle soluzioni
eGovernment sviluppate con software Open Source (http://ec.europa.eu/idabc/en/chapter/452).
Il termine stesso Open Source nasconde una varietà di licenze che definiscono
diversi livelli di responsabilità sulla distribuzione del codice sorgente all’utente finale. Prima di intraprendere qualsiasi progetto Open Source è buona pratica acquisire un’effettiva conoscenza su cosa comporta a lungo termine la scelta di una licenza o d’un altra per lo sviluppo e il supporto del progetto stesso.
A tal proposito, una visita al sito www.opensource.org/licenses/ ed altri siti che
vengono indicati più avanti, come quello di “creative commons”vi aiuteranno a
conoscere i diversi tipi di licenze Open Source disponibili. L’elemento che le licenze hanno in comune è il diritto che ha l’utente di accedere al codice sorgente del
software. I punti nei quali differiscono le varie licenze riguardano le condizioni
sotto le quali è autorizzata la distribuzione del software, o la richiesta di un pagamento a tale fine, così come l’effetto che ha la modalità di implementazione di
quel codice sorgente su altre applicazioni collegate.
Quando si apre una gara per un progetto Open Source o se ne costruisce uno
proprio è importante capire quale sono le restrizioni che le licenze in esame vi possono imporre in futuro. La terza sezione di questo documento approfondirà nel dettaglio questo aspetto.
Uno dei fattori cruciali della GPL (la licenza GNU-GPL è la più popolare e permette di acquisire liberamente e cambiare a volontà il codice sorgente con l’unica condizione di mettere a disposizione degli altri nella stessa forma le modifiche realizzate)
è il problema della “contaminazione”. Quando si collega una parte di software Open
Source con un codice software proprietario, la parte collegata diventa per forza
“open sourced”. L’atto stesso di rendere aperto un codice software di cui è proprietario un terzo non è consigliabile, perché potrebbe aprire una questione legale piuttosto intricata. Ciò affonda le sue radici in una clausola GPL che dice:
18
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
‘[...] il lavoro basato sul programma (codice) include sia il programma che qualsiasi lavoro derivato sotto diritti di copyright, cioè qualsiasi lavoro contenente un
programma o una porzione di esso, sia che si tratti di una copia che di una modifica a un programma e/o di un programma tradotto da un altro linguaggio.
Se l’efficienza è il motivo fondamentale che giustifica l’applicazione che si
vuole installare o sviluppare, allora l’utilizzo della licenza GPL diventa un problema.
A meno che si voglia cambiare completamente tutta la architettura software del
proprio sistema, prima o poi si andrà a finire in una situazione dove ci sarà bisogno di collegarsi ad un sistema proprietario.
Ci sono due strade per superare questo ostacolo:
a. Scegliere un altro tipo di licenza Open Source, come la GNU Lesser Public License
oppure la licenza LGPL che gestiscono in maniera più efficiente il problema dell’inserimento.
b. Collegare insieme i sistemi utilizzando webservices , cioè utilizzare standards
emergenti per collegare sistemi diversi sul web attraverso protocolli del tipo
SOAP (simple object application protocol). Poiché SOAP è uno standard Open,
diventa possibile creare un collegamento tra un’application programming
interface (API) che agisce su un sistema proprietario e anche su un sistema OS
con licenza GPL senza che ci sia alcun problema di “contaminazione”.
1.5 Attenzione ai Mozilla mutants
Per le società di sviluppo software non è qualcosa di sconosciuto il rilascio di licenze publiche. Alcune di queste sono disponibili nel sito www.opensource.com/licenses/. L’elenco contiene tutte quelle approvate dalla Open Source Iniziative (OSI).
Alcune società software potrebbero presentarsi alla gara proponendo una
licenza pubblica e dicendo che si tratta di una versione della Mozilla Public License.
In questo caso è importante rivolgere qualche domanda a loro e ai propri rappresentanti legali:
a. Chiedere loro se abbiano o meno sottoposto la loro licenza pubblica all’approvazione dell’OSI;
b. Chiedere loro perché non utilizzino una delle licenze standard OS (es.: LGPL,
GPL, BSD, MIT, o Mozilla);
c. Chiedere al proprio rappresentante legale di verificare se c’e qualcosa nella
licenza che permetterebbe alla società di interrompere le condizioni open source in una futura versione del codice sorgente che deve essere sviluppato, allo
scopo di chiedere il pagamento della licenza;
d. Chiedere al proprio rappresentante legale di controllare quali differenze vi siano
tra la licenza standard Mozilla e quella che viene proposta, per evidenziare le
problematiche che potrebbero presentarsi a lungo termine a causa di queste
differenze.
Converrebbe anche guardare il paragrafo 1.3.2 sugli Open standards nel caso
Le guide di Ancitel
19
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
si verificasse questo tipo di situazione. Certamente approfondire il punto guardando la parte terza di questa guida.
1.6 Cercare progetti su Source Forge
Source Forge (www.sourceforge.net) è il sito più importante per lo sviluppo di
progetti Open Source che c’e sulla rete. Contiene attualmente circa 80.000 progetti
ed ha più di 800.000 utenti registrati. Non è necessario registrarsi come utente del
sito per navigare tra i progetti disponibili. Per fortuna l’interfaccia utente è ben progettata e la ricerca fra 80.000 progetti risulta meno scoraggiante di quanto possa
sembrare.
La sezione software map (http://sourceforge.net/softwaremap/trove_list.php)
permette all’utente di cercare un progetto attraverso la categoria a cui essi appartiene. Una delle categorie di ricerca riguarda proprio l’identificazione dell’utente
che sarà il destinatario (end user) del progetto. Alla data di pubblicazione di questa guida, se si consulta questa sezione non si troverà Government come una delle
categorie. Si dovrà allora cercare nell’elenco in modo più specifico, facendo diretto riferimento all’applicazione che si vuole implementare.
Nell’elenco di progetti di Source Forge, la graduatoria si basa sul grado di attività che ha il progetto nel sito e questa attività è giudicata misurando la frequenza con cui si accede al repository (archivio dinamico) del progetto nel sito. Quindi,
questo ranking funziona solo quando i progetti mantengono il loro archivio nel repository principale di Source Forge. E’ paradossale che le due più popolari banca dati
Open Source, cioè MySQL (www.mysql.org) e PostgreSQL (www.postgresql.org), non
compaiano su Source Forge tra i primi venti progetti più attivi. Infatti, si tratta di
progetti troppo grandi che hanno le risorse per avere un proprio repository e sito
sul web, sfuggendo così al Source Forge..
1.7 Altri siti che raccolgono progetti OS
Sfortunatamente Source Forge è praticamente la sola lista globale di progetti
OS, ma come si può vedere dall’esempio precedente non è priva di difetti.
Per questo, conviene fare degli incroci con altre fonti (anche quelle indicate
della Commissione Europea) utilizzando un motore di ricerca come Google per trovare l’applicazione che si sta cercando. In questo caso, ad esempio, Databases
Open Source e MySQL vengono evidenziate in cima alla lista con i risultati della
ricerca, insieme con PostgreSQL che appare al quarto posto nella lista. Tuttavia,
nessuna delle “top twenty applications” di Source Forge apparirà nella prima pagina della vostra ricerca Google.
Il sito più grande per le news sullo sviluppo Open Source è “l’Open Source
Development Network”, che può essere visitato all’indirizzo www.osdn.com.
Questo sito, tuttavia, può confondere una persona inesperta in quanto non ha dei
contenuti specifici. Infatti, consiste in un meta sito che ha come funzione principale di puntare ad altri siti specializzati, molti dei quali vengono indicati al meta sito
20
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
da sviluppatori professionisti. Offre, tuttavia, alcune newsletters che sono state
pensate specificamente per i neofiti dell’Open Source.
Non c’è dubbio che tutte queste ricerche impegnano molto tempo. Un Portale
Europeo specializzato in applicazioni di e-Government Open Source risparmierebbe
agli utenti tempo e fatica. Un primo intento è stato intrapreso dalla Commissione
Europea attraverso il programma IDABC, a cui si è già fatto riferimento.
2 Quando un progetto OS è realizzabile
2.1 Criteri di fattibilità
Giudicare la fattibilità di un progetto richiede la stima attenta e puntuale di molti
fattori. La prima domanda da porsi riguarda la grandezza della comunità di sviluppo associata al progetto. I progetti appaiono su Source Forge per i più diversi motivi, ma sopravvivono quelli che hanno in comune alcuni pochi punti:
a. Vi è una sufficiente richiesta accademica per lo sviluppo della soluzione, tale da
attrarre molti sviluppatori a lavorare al progetto – p.es. semantic web applications
b. Vi è una grossa società che sponsorizza lo sviluppo e quindi c’è un gruppo di
sviluppatori che lavorano full time sull’applicazione – es. SUSE Linux.
c. Vi è sufficiente richiesta sul piano commerciale per lo sviluppo, tale da attrarre
molti sviluppatori a lavorare al progetto – es. ZOPE.
d. Il progetto risulta entusiasmante ed attraente per molti sviluppatori che decidono di lavorare ad esso – es. PhP Nuke. problemi da risolvere.
Quando si valuta un’applicazione Open Source è importante tenere presente
quanto segue:
2.1.1 La dimensione della comunità di sviluppo
a. Quante persone contribuiscono a questo progetto?
b. Dove si trovano geograficamente?
c. Lavorano tutti per la stessa società? Se sì, qual è la storia di questa compagnia?
d. Da quando è stato stabilito il progetto? E’ in uno stadio antecedente alla v1.0
(prima versione) ? Se sì, vuol dire che si andrà incontro ancora a molti bachi.
e. Quanto è attiva la comunità di sviluppo? Per capire occorre controllare i relativi forum sul web e guardare quanti posts vengono effettuati e quanto velocemente viene data una risposta. Provare a porre una domanda da principiante e
controllare se qualcuno risponde e quanto velocemente.
2.1.2 La qualità della documentazione
a. Esiste o meno una documentazione che descriva l’architettura d’insieme del
sistema/applicativo? L’annotazioni individuali sulle singole linee di codice vanno
bene, ma se non si riesce a vedere lo sviluppo dell’intera architettura capirlo
può richiedere fin troppo tempo.
Le guide di Ancitel
21
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
b. L’annotazione di codice dovrebbe mostrare con chiarezza quale è lo scopo del codice. Se si vuole avere in futuro la possibilità di adattare o sviluppare con questo codice delle altre applicazioni, allora queste annotazioni dovranno essere ben fatte.
c. La documentazione ha o meno un sistema di controllo della versione? Il controllo della versione è cruciale per capire se si sta consultando o meno il documento più recente – ciò rappresenta una chiara indicazione sulla serietà della
comunità di sviluppo.
2.1.3 Il controllo del nucleo del codice sorgente
a. Ci sono molte diramazioni in questo codice? Un sintomo della perdita di controllo
è proprio il numero di diramazioni del nucleo del codice. La piattaforma PhP nuke
è appunto un caso in cui il nucleo del codice si è ramificato molte volte. Queste
ramificazioni rendono più problematico l’upgrade del nucleo dell’applicazione.
b. Qual è il trattamento per le persone che vogliono proporre dei cambiamenti al codice sorgente? C’è una chiara regola per la presentazione e accettazione delle proposte, o gli utenti possono attaccare direttamente le loro versioni sul sito? Quest’ultima
opzione può andar bene quando si vogliono eseguire molti test per conto proprio.
c. Ci sono delle patches (cure) disponibili sul sito per risolvere le questioni di sicurezza? Anche il miglior codice ha problemi di sicurezza: il punto chiave è la velocità con
cui possono essere individuati e approvati. Per questo, occorre controllare i relativi
forums, allo scopo di rintracciare delle notizie sui problemi di sicurezza individuati,
nonché controllare quanto velocemente è stata sviluppata una patch (cura).
2.2 Open Standards
L’aspetto relativo a “open standards è una componente chiave dello sviluppo
di un progetto Open Source che punti al successo. Attualmente, non hanno ancora assunto il livello di importanza che dovrebbero avere nei progetti di
eGovernment OS.
Ciò è sorprendente perché il government nel suo insieme gestisce un mercato
sufficientemente grande per “imporre” degli standard ai fornitori. Nel lungo termine, gli Open Standards portano dei grossi benefici. Non solo per il pregio che
hanno per rendere più facile lo scambio dei dati, ma anche perché quando gli
Open Standards sono buoni diventano spesso la base per costruire attorno una
politica OS e sviluppare delle soluzioni applicative.
Gli Open Standards rappresentano, inoltre, la via con cui le amministrazioni
possono cominciare ad assicurare l’interoperabilità dei sistemi e il trasferimento dei
dati. Essi sono, quindi, delle componenti cruciali per il sostenimento dell’eGovernment a lungo termine.
I progetti Open Source che hanno avuto più successo, si affidano ad uno o più
standards di interoperabilità, attraverso i quali svolgono le loro funzionalità di base.
22
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Ad esempio:
● GNU/Linux - POSIX,
● Apache - HTTP SSL HTML CSS,
● Sendmail - SMTP MIME,
● Postgresql - SQL,
● Tomcat, JBoss - J2EE,
● Blackdown - Java,
● Mozilla - HTTP SSL HTML CSS.
Vi sono tre ragioni principali per cui i progetti dovrebbero essere svolti
in questo modo:
2.2.1 Associare le necessità
La necessità guida i progetti Open Source. Quando un gruppo abbastanza
grande di sviluppatori software ha bisogno di una porzione di codice, allora esistono le potenzialità per costituire una comunità Open Source attorno ad un progetto. Gli standard aiutano ad associare le necessità.
Vi sono due lati di uno standard di interoperabilità. Quello del fornitore del servizio (service provider) e quello del consumatore (service consumer). Apache è un
esempio di service provider e Mozilla è un esempio del corrispondente service consumer.
Prima di HTTP e HTML vi era un bisogno insoddisfatto di rendere disponibili e
accessibili in modo esteso su una rete una grossa quantità di documenti ed informazioni. Senza questi standards ci si può immaginare una situazione in cui i bisogni degli utenti vengono dispersi in un gran numero di soluzioni end-to-end. Con
gli open standards HTTP e HTML, si sono create le condizioni per la collaborazione
tra i service providers che hanno sfornato Apache, mentre i service consumers
hanno collaborato per creare Mozilla.
2.2.2 Obiettivi concreti
Obiettivi chiari e ben definiti rappresentano un enorme beneficio per ogni progetto di sviluppo software. E mentre la leadership di un progetto è principalmente responsabile di fornire chiarezza, essa necessita anche di un modo per esprimere le proprie intenzioni. Gli standards sono una buona via per dichiarare i propri
obiettivi sia agli sviluppatori all’interno della comunità, sia ai potenziali utenti.
2.2.3 Più alternative
L’intenzione di creare software compatibile e interoperabile con altre applicazioni utilizzando standards permette di lavorare con una grande varietà di implementazioni. Ad esempio, un web server compatibile con HTTP è progettato per
lavorare con molti web browsers. Al contrario, un web browser compatibile con
HTTP è progettato per lavorare con molti web servers.
Ciò diminuisce la barriera dell’adozione di software Open Source, in quanto
Le guide di Ancitel
23
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
l’esistenza di alternative attenua i rischi di un’unica implementazione. Quindi,
senza promuovere gli Open Standards un progetto troverà più difficoltà per attrarre una comunità credibile di sviluppatori con degli obiettivi definiti e diventerà piuttosto un progetto pseudo Open Source, perché la realtà dimostrerà che i fruitori
risulteranno legati ad un singolo fornitore di software.
In effetti, i buoni progetti Open Source lavorano partendo dagli open standards. Se una amministrazione locale può influenzare la società Open Source con
la quale lavora ad utilizzare gli Open Standards, avrà più possibilità di avere in
mano un buon progetto Open Source. Purtroppo, ciò richiede che il cliente stesso
venga coinvolto nell’architettura del software e per questo è necessario un certo
grado di esperienza.
Una buona guida relativa agli OpenStandards si trova sul portale UK
Government “Govtalk” all’indirizzo www.govtalk.gov.uk . Si tenga in considerazione che la maggior parte di quanto si può trovare sul sito di Govtalk è stato considerato dall’IDA (http://europa.eu.int/ISPO/ida) come parte dell’European
Interoperability Framework.
3 La torre di babele binaria
OS non è una singola tecnologia né una diversità di tecnologie scritte in un singolo linguaggio di programmazione. E’ una diversità di tecnologie, qualche volta
dello stesso tipo, scritte in diversi linguaggi di programmazione, come:
● Java - www.java.com un linguaggio di programmazione ad oggetti
●
Mono - www.go-mono.com un’implementazione Open Source del framework di
sviluppo .net
●
PhP - www.php.net un linguaggio di scripting
●
Python – www.python.org – un linguaggio ibrido che utilizza sia lo scripting che
l’object oriented
●
TCL - www.tcl.tk/ - un linguaggio di scripting
Il problema della scelta di un linguaggio di scripting rispetto ad un linguaggio
orientato agli oggetti non è oggetto di questa guida.
Come regola generale, le applicazioni indicate sotto la categoria di Governo
Efficiente sono più adatte a linguaggi object oriented, mentre quelle indicate come
Governo Efficace sono forse più adatte ai linguaggi di scripting.
Si dovrà analizzare anche le capacità di base di cui si dispone. Se si hanno a
disposizione degli sviluppatori, o si vuole promuovere la crescita delle società ICT
locali, allora occorre capire cosa sono in grado di imparare e in quanto tempo. I linguaggi di scripting sono più facili da imparare rispetto ai linguaggi orientati agli
oggetti e per questo sono anche più economici.
Linguaggi come PhP hanno già sviluppato una base molto ampia, con molte librerie
di applicazioni scritte e disponibili, tra le quali si trova anche molta spazzatura. Per questo
occorrono degli sviluppatori con sufficiente esperienza per distinguere il materiale buono
24
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
da quello da scartare. Applicazioni scritte in TCL come OpenACS (www.openacs.org) possono non avere tante librerie, in quanto quelle a disposizione sono strettamente controllate e ciò può essere rassicurante dal punto di vista della sicurezza.
Java è supportato da Sun e viene anche utilizzato in modo esteso fuori dalle
applicazioni Open Source. Di conseguenza, i buoni sviluppatori Java sono abbastanza cari e può risultare difficile trattenerli in casa . Tuttavia, Java rappresenta il
cuore di molte tecnologie chiave Open Source. Per questo, sviluppare un’applicazione in Java potrebbe aprire delle possibilità di integrazione con molte altre applicazioni già sviluppate (http://jakarta.apache.org) oppure l’integrazione con altre
applicazioni proprietarie integrate mediante l’utilizzo di application servers come
Oracle 9i AS o IBM websphere.
Python viene usato per sviluppare ‘Google’, e la sua combinazione di linguaggio di scripting con l’object oriented offre la possibilità di essere più veloce da
imparare rispetto a Java. La sua applicazione più importante nel campo Open
Source è Zope (www.zope.org), che consiste in un’application server Open Source
per la gestione di contenuti web.
In ogni caso è importante notare che i linguaggi non garantiscono di per se lo
stato di Open Source che può avere una determinata applicazione che lo utilizza.
4
Comprare software
Una volta studiato il proprio business case, fatta la ricerca, organizzato il proprio team, bisogna conoscere sufficientemente le differenze tra il software OS e il
software proprietario, per avere così in mano tutti gli elementi necessari per poter
decidere di passare alla fase successiva, cioè quella finalizzata all’acquisizione di un
applicativo open source che risponde alle proprie esigenze.
4.1 Come comprare ciò che è già “free,‘Come creare un livello di concorrenza tra software OSS e software proprietario quando si apre una gara
d’appalto
Una delle questioni chiave nata nei vari workshop del progetto “Three Roses”,
fu come avviare una politica per l’acquisto di software a livello dell’amministrazione pubblica locale che permetta di fare una valutazione con pari regole del software Open Source in relazione al software proprietario.
Il governo del Regno Unito attraverso il suo dipartimento per il commercio ha
emesso delle linee guida nel luglio 2002 (www.ogc.gov.uk/) basate sui seguenti
principi:
● Il governo del Regno Unito considererà le soluzioni OSS (Open Source Software)
insieme a quelle sotto licenza proprietaria con un criterio costo/beneficio;
●
Il governo del Regno Unito utilizzerà prodotti per l’interoperabilità che rispondono a specifiche e a open standards in tutti i futuri sviluppi dell’Information
Technology.
Le guide di Ancitel
25
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
●
Il governo del Regno Unito eviterà per quanto sia possibile di utilizzare prodotti
e servizi ermetici sotto licenza proprietaria
Nell’agosto del 2003, il governo del Regno Unito ha annunciato la pre-selezione di 11 candidati per un contratto di 3.300 milioni di euro con la finalità di mettere on-line le cartelle mediche dei pazienti del Sistema Sanitario Nazionale di quel
paese. Nessuno di questi candidati ha presentato una soluzione Open Source e
quindi, il Dipartimento per il Commercio (OGC) del governo non è stato in grado
di continuare con la procedura di gara.
La ragione di tutto ciò risiede nel fatto che i processi di offerta del Governo
sono processi complessi che richiedono ad un fornitore molto tempo per poter
entrare nella preselezione. Conseguentemente, si tende di fatto a scegliere quei
fornitori che hanno stanziato un buon budget ed esperti per seguire queste gare.
Poche società di sviluppo per applicazioni Open Source sono nella posizione di
prendersi un onere così rischioso.
Come indicato in precedenza a proposito del costo totale di possesso, non si
va avanti con successo se le applicazioni Open Source vengono esposte alle stesse
condizioni dei sistemi proprietari. Quindi, la decisione di introdurre un sistema
Open Source nell’ amministrazione deve essere presa prima di indire una gara e
quest’ultima dovrebbe riflettere nella documentazione di gara messa a disposizione dei potenziali fornitori proprio questa decisione.
La domanda chiave da porsi prima dell’acquisizione di un software Open
Source è: che cosa si sta realmente cercando?
a. Se l’ intenzione è di acquistare un’applicazione disponibile sul mercato, allora il
migliore approccio è quello di realizzare una gara con gli orientamenti suggeriti per esempio dall’OGC. Questo potrebbe incoraggiare una società software
Open Source a partecipare in gare dove altrimenti non avrebbe partecipato.
b. Se si vuole scegliere un’applicazione soltanto per la propria amministrazione,
oppure, l’intenzione è quella di condividere l’applicazione senza spese con altre
amministrazioni, è necessario esplicitare quale sia l’intenzione nei documenti
della gara, poiché sarà utile per stimolare nei potenziali fornitori l’idea di proporre una soluzione Open Source, senza che ciò diventi necessariamente una restrizione per fornitori di software proprietario, che possono comunque offrire un
eventuale modello alternativo.
c. Probabilmente non si vuole comprare direttamente un’applicazione, ma soltanto acquistare dei servizi di sviluppo software da terzi allo scopo di creare e
installare un Toolkit OS con il quale sarà possibile sviluppare a sua volta un’applicazione per la propria amministrazione (e altri partners).
26
Le guide di Ancitel
SECONDA SEZIONE
Implementazione di applicazioni
Open Source
5 Sviluppo
5.1 Introduzione
Questo capitolo è dedicato all’analisi dell’aspetto qualità del lavoro di sviluppo
che viene intrapreso per integrare la soluzione Open Source nella propria organizzazione.
●
I contenuti di questo capitolo si basano nelle seguenti premesse:
La soluzione Open Source scelta sarà costruita su un progetto già esistente;
●
La soluzione Open Source sarà sviluppata per soddisfare una necessità del proprio “business” con un forte enfasi nello sfruttamento del prodotto;
●
E’ previsto un certo lavoro di sviluppo finalizzato ad integrare, estendere o migliorare la soluzione Open Source scelta all’interno della propria organizzazione;
●
Questo lavoro di sviluppo verrà portato avanti in parallelo da più di un gruppo
di sviluppatori, anche separati tra loro in termini geografici;
●
Lo sviluppo verrà portato avanti utilizzando forme di processo iterativi.
Questo è uno scenario nel quale un approccio strutturato, sia per gestire le attività, sia per assicurare un risultato di buona qualità, è di vitale importanza per
garantire il successo del progetto. Il suggerimento è quello di creare due organismi
tecnici: la Design Authority (DA) e la Qualità Assurance (QA) nonché un piano
guida generale, il cosiddetto framework di compatibilità (compliance framework),
una sorta di guida tecnica per strutturare il progetto).
5.2 La Design Authority (DA): l’organo d’indirizzo tecnico della Direzione
del progetto
5.2.1 Ruolo
Questo è un gruppo di lavoro nel quale sono rappresentati tutti quelli che
hanno una determinata responsabilità nello sviluppo del progetto, fa capo al
Comitato di Direzione del progetto e ha il compito di risolvere i problemi tecnici
che riguardano l’interoperabilità e l’integrazione.
Le guide di Ancitel
27
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
5.2.2 Membri
L’organo di indirizzo tecnico è di solito formato dagli architetti di software specializzati in ciascuno dei segmenti di sviluppo, da esperti in standards e da un rappresentante tecnico del cliente/clienti.
Succede spesso che le discussioni diventino troppo tecniche e che si perda di vista l’obiettivo generale dell’incontro, diluendosi all’interno di accesi dibattiti sui benefici dei profili di
comportamento che ha un certo software per lo sviluppo rispetto ad altri. Le persone
responsabili dello sviluppo in termini pratici dovrebbero essere invitati alle sessioni
della DA quando c’e bisogno che diano il loro parere su un approccio specifico alla
soluzione del problema, ma la decisione dovrebbe restare in mano alla DA.
5.2.3. Funzioni e potere
E’ molto importante definire chiaramente il potere e le attribuzioni della DA. Nei progetti che hanno molti segmenti/direzioni di sviluppo paralleli, impegnando gruppi distribuiti in diverse città e zone geografiche, bisogna essere in grado di conciliare le aspettative con quello che la DA può effettivamente gestire. Da un lato, se la DA si comporta
in forma rigida cercando di imporre delle determinate pratiche di sviluppo, finirà per
compromettere l’indipendenza dei processi di sviluppo rallentandoli; dall’altro lato, se
non c’è alcuna autorità nella gestione dei flussi molti aspetti di integrazione potrebbero
non venire a galla, costringendo il progetto a tentare un recupero in una fase troppo
avanzata dello stesso, con un aumento dei costi in termini di tempo e risorse.
5.2.4 Linguaggio
In progetti estesi, è molto comune che nascano dei seri problemi di comunicazione, non soltanto perchè i gruppi di sviluppo parlano delle lingue diverse, ma anche
perché la tecnologia è qualcosa difficile da comunicare. Per questo, si consiglia l’utilizzo di UML per rappresentare le idee di sviluppo, tenendo anche presente che l’UML
è diventato uno standard ufficiale per le rappresentazioni visive di software.
●
Gli scopi dell’UML sono quelli di:
Fornire agli utenti un visual modelling language (linguaggio di rappresentazione
visuale di modelli) espressivo e pronto per l’uso, che permette di scambiare
modelli significativi per l’attività di sviluppo;
●
Fornire meccanismi di estensione e specializzazione per ampliare i concetti chiave;
●
Supportare le specifiche con indipendenza dai diversi linguaggi di programmazione e dai processi di sviluppo;
●
Fornire una base formale per comprendere i linguaggi di modellazione utilizzati;
●
Incoraggiare la crescita del mercato di strumenti di modellazione ad oggetti;
●
Dare un supporto dinamico ai concetti di sviluppo ad alto livello come quelli relativi ai componenti, alla collaborazioni,alla creazione di piani guida generalI (frameworks) e di norme di comportamento (patterns);
28
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
●
Integrare le best practices.
(tratto da “Object Management Group, “OMG Unified Modelling Language Specification”,
versione 1.4, September 2001, pagina 46).
E’ importante dire che l’UML va utilizzato come sostegno alla comunicazione.
Il comitato di direzione del progetto dovrebbe costruire un accordo con i diversi
gruppi di sviluppo del software che specifiche quale sarà il reale grado di utilizzo
dell’UML nello sviluppo (in quanto tale onere può facilmente diventare un impegno troppo forte per squadre non abituate a lavorare con tali strumenti). Si consiglia certamente un uso estensivo di UML nella fase di sviluppo del software, malgrado l’esperienza indichi che non tutte le società di software lo utilizzano, cosa
che può provocare notevoli ritardi nello sviluppo del progetto quando tale onere
sul codice o sulla documentazione viene vissuto come una sorpresa che non era
prevista nel conto. Per comportamenti che sono particolarmente complessi come
nei casi di integrazione di applicazioni, si consiglia l’uso di class diagrams e interaction diagrams (si veda “Object Management Group”, pag. 294 e pag. 375).
window
{ abstract
author= Joe
status= tested }
+size: Area = (100,100)
#visibility: Boolean = true
size: Area
+default-size: Rectangle
visibility: Boolean #maximum-size: Rectangle
-xptr: XWindow
display()
hide()
+display ()
+hide ()
+create
-attachXWindow(xwin:XWindow)
Fig. 1 – Class Diagram (UML specifics pag. 297)
Le guide di Ancitel
29
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
redisplay()
window
:Controller
:Window
parameter>> window
<<
1:displayPosition(window)
contents {new}
wire
1.1*[i:1..n]: drawSegment(i)
wire: Wire
wire
i-1
1.1.1a: r0:= position()
left: Bead
1.1.3.1: add(self)
i
local>> line
1.1.2: create r0,r1
1.1.3: display window
<<
:Line {new}
1.1.1b: r1:= position()
right: Bead
Fig. 2 – Collaboration Diagram (UML specifics, pag. 377)
Martin Fowler, uno dei principali esponenti della metodologia OO definisce con
chiarezza l’importanza del visual modelling all’interno di un gruppo come la DA:
“Il motivo principale per utilizzare l’UML riguarda la comunicazione, cioè
utilizzo l’UML perché mi permette di comunicare alcuni concetti più chiaramente di qualsiasi alternativa in linguaggio naturale, il quale appare
impreciso e inadatto per affrontare concetti più complessi. Il codice d’altro
canto è preciso ma troppo dettagliato. Quindi l’UML mi serve perché
ottengo una certa precisione senza perdermi nei dettagli”
(Fowler, Martin, “UML Distilled”, Second Edition, Addison Wesley, 2000, pag. 7)
5.2.5 Attività
La primissima attività di questo gruppo è quella di mettere in risalto gli aspetti
relativi alla interoperabilità e le possibili integrazioni per disegnare a tal fine delle
apposite strategie. Uno dei ruoli più importanti della design authority è quello di valutare il progresso di ciascuno dei gruppi di sviluppo con particolare attenzione alle consegne, alle scadenze ed alla integrazione del prodotto finale. La letteratura che ha
approfondito i processi iterativi, suggerisce di cercare di sincronizzare i rilasci parziali relativi al codice dei diversi gruppi di sviluppo, mettendo per primi quelli che hanno
i requisiti più complessi con maggiore valore. Le iterazioni dovrebbero essere di breve
durata (da 2 a 6 settimane), per ridurre i rischi e permettere di avere un feedback in
tempo utile dalle persone chiave. Idealmente gli incontri della DA dovrebbero essere organizzati in base al calendario di rilasci del codice, e dovrebbero effettuarsi almeno dopo i rilasci alfa, beta e finale. In alcuni progetti, gli incontri DA sono organizzati prima delle riunioni del comitato di direzione del progetto, per riportare le questioni tecniche che sono rilevanti e per evidenziare dei potenziali ritardi.
30
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
5.2.6 Prodotti
●
La DA deve generare i seguenti prodotti:
Rapporti sulle riunioni sotto forma di note che raccolgono uno o più punti di
azione, verbali,ecc...
●
Il Piano Generale di Compatibilità
5.3 Il Piano Generale di Compatibilità: la guida tecnica del progetto
Dopo aver descritto le sfide di una design authority che vuole avere successo,
si consiglia di creare un documento che contenga il piano generale di compatibilità del progetto, il quale dovrà essere sottoscritto da tutti i gruppi di sviluppo. Il
piano generale di compatibilità è uno strumento nato dalle esperienze dei gruppi
che si occupano della definizione di standards. Dovrebbero essere stabiliti nei primi
tempi del progetto una serie di principi guida, ai quali si devono conformare tutti
coloro che sviluppano il codice, seguendo le loro pratiche usuali di sviluppo del
software. Un piano generale di questo tipo nel mondo dell’e-Government è il
cosiddetto “e-GIF”
che fu deciso dal governo del Regno Unito:
www.govtalk.gov.uk/schemasstandards/egif.asp .
Il Piano Generale di Compatibilità dovrebbe essere uno dei compiti iniziali della
DA, e dovrebbe essere adottato con il voto unanime di tutti i membri. Il piano generale dovrebbe includere i seguenti elementi:
● Le specifiche hardware per l’implementazioni di software pilota e/o software di
produzione;
●
Le versioni di software di terze parti che verranno utilizzate;
●
La compatibilità richiesta con gli standards di interoperabilità;
●
La compatibilità richiesta con gli standards di accessibilità;
●
Il formato e gli argomenti che devono essere coperti dalla documentazione.
Grazie a questo tipo di documento una gran parte delle problematiche d’integrazione vengono messe sul tavolo fin dall’inizio, quindi, le relative decisioni per
risolverle possono essere prese facendo delle valutazioni in tempo utile. Questo
modus operandi permette inoltre alla DA, di risolvere delle questioni tecniche
durante lo sviluppo con piena consapevolezza, nonché di avere un reale potere per
coordinare lo sviluppo in modo che rimanga nei limiti del piano generale stabilito.
5.4 Comitato di Controllo della Qualità
Come anticipato all’inizio del capitolo, l’approccio della presente guida suggerisce
la creazione di due organismi e di un piano guida. E’ tempo ora di descrivere la seconda struttura: il Comitato di Controllo della Qualità.
5.4.1 Ruolo
Il Comitato di Controllo della Qualità è un gruppo che va strutturato all’inter-
Le guide di Ancitel
31
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
no del flusso di sviluppo. Esso si occupa di questioni tecniche e gestionali diventando un ponte tra il comittente e il team di sviluppo. Il ruolo del comitato di controllo della qualità, nei progetti Open Source, è diverso dai progetti a codice chiuso,
sia perché il codice aperto e più soggetto a forme di verifica e miglioramento, sia
perché il livello di testing e di validazione è potenzialmente più esteso ed efficace.
D’altra parte risulterebbe abbastanza difficile trovare l’assistenza professionale per
il controllo della qualità del software Open Source, se il pacchetto applicativo in
oggetto non fosse utilizzato in maniera estesa dagli utenti.
5.4.2 Membri
Il Comitato di Controllo della Qualità ha bisogno di lavorare a stretto contatto
con il committente e con il team di sviluppo, per cui la selezione dei membri che
ne fanno parte è fondamentale. L’esperienza ci indica che il Comitato di Controllo
della Qualità non deve essere molto grande, non più di un rappresentante per ciascun stakeholder importante: committente, team di sviluppo e partner QA. (quality assurance - controllo della qualità). Il profilo dei membri è sicuramente di tipo
tecnico, anche se è fondamentale un’attitudine a gestire le scadenze e i momenti
di tensione all’interno del progetto.
Durante il processo di sviluppo del software ci sono molte situazioni di potenziale conflitto tra il committente ed il team di sviluppo. Perciò alcune metodologie di
gestione applicano un sistema al quanto rigido, basato su specifiche definite a priori. Questo metodo è conosciuto come il metodo “a cascata”. L’esperienza ci indica
però che non è il metodo migliore perché crea dei limiti artificiali e rende il progetto
troppo statico quando si verifica un qualsiasi cambiamento nelle specifiche.
Requisiti
Analisi
Disegno
Codice
Verifica
Mantenimento
Fig. 3 – Il modello “a cascata”
32
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Il suggerimento è quello di adottare un approccio iterativo, che tenga presente la possibilità che i requisiti vengano modificati durante lo sviluppo, seguendo un
procedimento secondo iterazioni suddivise in base al tempo ed evidenziando per
primi quelle con i requisiti più difficili e di maggior valore. Questo approccio prevede la consegna di una parte di codice al termine di ciascuna iterazione. Tale approccio richiede un buon livello di comprensione degli aspetti tecnici da parte del committente, perché nelle prime iterazioni è possibile che i cambiamenti introdotti non
siano così evidenti e anche difficili da testare se non si da uno sguardo al codice,
soprattutto, quando si tratta di ampliare oppure di incrementare l’APIs esistenti.
Siccome non è prevedibile ne ragionevole aspettarsi una grande capacità da
parte del committente a questo riguardo, il problema va risolto nel Comitato di
Controllo della Qualità attraverso la presenza del QA partner.
5.4.3 Partner per la Quality Assurance “Partner QA”
Il Comitato di Controllo della Qualità è stato già descritto come un gruppo che
deve confrontarsi con lo sviluppo del software, che ha la responsabilità di valutare
la qualità del codice prodotto rispetto alle specifiche, oltre che portare avanti il progetto cercando di mantenere sotto controllo le tensioni naturali che nascono tra il
committente e il team di sviluppo. Quindi il partner QA è in sostanza la “terza
parte” del progetto e viene contrattata dal committente per fornire a nome suo il
necessario supporto di tipo tecnico. Si potrebbe pensare che dopotutto questo partner QA non sia diverso da altri partner principali (contractors) del progetto, o da
un consulente, ma in verità c’è una differenza rilevante: il partner QA dovrebbe
guardare al progetto di sviluppo come qualcosa di centrale al suo proprio modello
di business.
Nei capitoli precedenti si è parlato su come scegliere il software sotto licenza
Open Source. Quando si tratta di cercare il partner che vi affiancherà come il vostro
principale supporter dei processi di controllo della qualità, bisogna distinguere a
monte se il pacchetto di software è affidato a sviluppatori indipendenti o se è affidato a delle società che forniscono oltre allo sviluppo il necessario supporto tecnico. Ipotizzando che lo sviluppo del software venga affidato a questi ultimi, il partner QA sarà sicuramente il primo interessato a dare il suo contributo per il controllo della qualità, soprattutto se rassicurato che alla fine del processo di sviluppo
si riuscirà ad avere un software che è migliore di quello precedente. Questo è forse
l’elemento più caratterizzante di quando si lavora in ambiente open source, soprattutto in ambito e-government, dove il successo dipende in grande misura dalla
capacità che si ha per coinvolgere nell’intero processo delle società competitive,
che offrono sia i servizi che il supporto tecnico adeguato.
Nel caso che siano molte le società che offrono supporto per il controllo della
qualità, la scelta definitiva del partner responsabile della QA dovrebbe essere fatta
guardando all’esperienza che hanno accumulato nella verifica e nella validazione
di software.
Le guide di Ancitel
33
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
5.4.4 Verifica
La scelta del partner QA può essere basata su aspetti che vanno anche oltre la
pura esperienza in processi di controllo della qualità. L‘esperienza ci indica che è
più importante coinvolgere una società software competitiva sul mercato piuttosto
che una compagnia “neutrale” esperta.
I metodi di controllo qualità suggeriti sono i seguenti:
● Unit testing (test per unità) in alcun casi il software che viene prodotto è molto
difficile da verificare utilizzando i test convenzionali, in altri casi la verifica di una
determinata funzionalità risulta ripetitiva e dispendiosa in termini di tempo
essendo pertanto più adatta a una forma di verifica automatizzata. In ambiente
java c’è un piano generale di verifica ben definito per fare il unit testing:
http://www.junit.org/index.htm.
●
Functional testing (test funzionale): chiamato anche client testing che viene eseguito attraverso la UI e risulta essenziale per identificare errori di interpretazione. Questa verifica è fondamentale in quanto si avvicina all’esperienza dell’utente con il prodotto finale, ed è anche più vicina all’idea di acceptance test (test
per il collaudo), dove il committente ha la possibilità di conciliare le sue aspettative con le caratteristiche del prodotto realizzato.
● Developer testing (test di sviluppo): questo tipo di sviluppo non si trova comunemente nella letteratura, ma crediamo che sia fondamentale per fare la verifica della
documentazione prodotta del software Open Source (come già indicato, un’area
tradizionalmente sottovalutata in questo tipo di progetto). Questo è un test particolarmente adatto quando il software è affidato a degli sviluppatori interni, oppure per
la considerazione dello staff tecnico. Questa è una fase fondamentale per la futura
sostenibilità del progetto, cioè per garantire una buona qualità del prodotto mentre
si lavora allo stesso tempo verso il collaudo per l’accettazione del nuovo codice.
5.4.5 Funzioni e potere
Con tanti interessi in gioco, la gestione del Comitato di Controllo della Qualità non
è facile, ed è importante che la relazione tra il committente e il partner QA sia definita
con chiarezza. Il committente ha la decisione finale ed è la massima autorità in questo
comitato ma ciò non significa che il cliente può trascurare ogni raccomandazione fatta
dal comitato. D’altra parte, è sempre vero che il committente non può perdere tempo
in discussioni tra le società concorrenti sui diversi approcci allo sviluppo di software. Uno
dei benefici della metodologia iterativa è quella di avere indicazioni frequenti sullo stato
di salute del progetto. Permette anche al committente di vincolare i pagamenti al completamento con successo delle singole fasi del processo iterativo. In questo modo, il
cliente mantiene l’autorità globale sulla commessa ed ha uno strumento di pressione
sulle parti coinvolte, riguardo il pieno rispetto dei tempi di consegna del codice funzionante da parte del team di sviluppo e in merito alla metodologia di verifica da parte del
partner QA e del Comitato di Controllo della Qualità per quanto riguarda la validazione delle singole fasi ed il rilascio del nulla osta per i pagamenti.
34
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
5.4.6 Linguaggio
Si applicano gli stessi principi che per la DA (Design Authority) nell’utilizzo dell’UML
per facilitare la comunicazione. Probabilmente la differenza maggiore è che il
Comitato di Controllo della Qualità ha a che fare con la scrittura delle specifiche,
avendo a disposizione per questo un ampio pacchetto di oggetti UML con questa
specifica finalità. L’esperienza indica che lo strumento più appropriato è il use case
diagram (diagramma d’utilizzo in base ad un caso tipo).
Telephone Catalog
Check
status
Salesperson
Place order
Customer
Fill orders
Shipping Clerk
Establish credit
Supervisor
Fig. 4 – Diagramma di un caso tipo (use case)
I diagrammi use case sono molto utili per la revisione dei requisiti o per semplificare
le funzioni che deve avere il software dovuto a ristrettezze di tempo o di budget.
5.4.7 Attività
Il Comitato di Controllo della Qualità deve compiere una serie di attività. Di
seguito un elenco delle attività da realizzare prima dello sviluppo:
a. Definizione dei requisiti: il committente dovrà definire una serie di requisiti
che possono andare, a seconda delle capacità tecniche dello stesso, da una
elenco di quello che si desidera di alto profilo a un ben definito pacchetto di
UML di use cases. Il Comitato di Controllo della Qualità dovrebbe essere capace di definire con chiarezza quali sono questi requisiti e di concordare la forma
di rappresentarli. Durante questo periodo viengono discusse la maggior parte
delle questioni architetturali di alto livello, dando di solito luogo ad una interazione molto positiva tra il partner QA e il team di sviluppo;
Le guide di Ancitel
35
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
b. Redigere l’elenco delle specifiche: dopo aver definito i requisiti, il passo successivo è quello di produrre una lista delle specifiche. L’elenco è una sorta di strumento di gestione, attraverso il quale ognuno dei requisiti stabiliti viene isolato per trasformarlo in un singolo pacchetto di consegna (deliverable). Ciascun pacchetto di
consegna è atomico; quindi, in un diagramma “use case” il singolo requisito può
a sua volta esplodere in una serie di singole specifiche. La lista delle specifiche da
consegnare deve comprendere anche la documentazione richiesta per ognuna,
essendo questo un aspetto spesso trascurato nel software Open Source;
c. Approvare il piano di iterazione: dopo l’accordo sui requisiti e l’elenco delle
singole specifiche, il team di sviluppo proporrà un piano di iterazione dove indicherà quando ogni pacchetto di specifiche verrà consegnato. Il piano di iterazione deve inoltre includere aspetti come i dettagli sul formato nel quale il codice
verrà consegnato, i bisogni di hardware per realizzare i test di verifica, ecc. A
questo riguardo, il ruolo del Comitato di Controllo della Qualità è quello di evidenziare le criticità presenti nella struttura di iterazione proposta dal team di sviluppo;
d. Approvare il piano di verifica: il partner QA definirà un piano per i test di verifica di ciascuna iterazione, che dovrà contenere il tipo di cambiamenti che
dovranno essere effettuati sul codice originale, le risorse a disposizione, l’hardware necessario per realizzare il processo di verifica, il formato nel quale verrà
consegnato il codice, ecc.. Il piano di test dovrà essere approvato da tutti i membri del Comitato di Controllo della Qualità (incluso il team di sviluppo) e, quando conveniente, dovrà vincolare il pagamento al completamento con successo
dell’iterazione;
e. Consolidare l’elenco delle singole specifiche con le date di consegna e l’informazione relativa alla verifica: la lista delle singole specifiche non deve
essere distribuita senza le date di consegna fissate e senza l’informazione relativa alla attività di verifica (controllo qualità). Un possibile layout è il seguente:
Pacchetto
A
36
Requisiti
questa
colonna
dovrebbe descrivere
la funzionalità atomizzata e i requisiti.
Essa dovrebbe puntare sui diagrammi
use case archiviati i
quei ambienti relativi ai progetti già
realizzati che sono
stati identificati
Note
Iterazione Controllo Qualità (QA)
questa colonna 1
viene usata per
qualsiasi chiarificazione o per
qualsiasi ulteriore informazione richiesta
questa colonna dovrebbe
descrivere i tipi di test richiesti
per la sua accettazione. Essa
dovrebbe servirsi della documentazione di verifica, presente in quei ambienti relativi
ai progetti già realizzati
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Una volta che lo sviluppo è cominciato, le attività previamente descritte saranno utili a definire la struttura del processo: il concatenamento tra le diverse fasi di
iterazione, le diverse verifiche da applicare al codice e come viene completata ciascuna fase del procedimento iterativo. Le attività nella fase di sviluppo che meritano essere menzionate sono le seguenti:
a. Riunione intermedia sullo stato di avanzamento: poiché il Comitato di Controllo della
Qualità è direttamente coinvolto nello sviluppo, è importante organizzare un progress meeting in cui il team di sviluppo può evidenziare un qualsiasi ritardo oppure
la necessità di rivedere un qualche punto negli accordi intrapresi. Il suggerimento è
di documentare queste riunioni in modo semplice, attraverso un elenco con i punti
principali relativi alla attività da intraprendere oppure mediante un verbale;
b. Relazione finale per ogni singola fase del Comitato di Controllo della Qualità:
questa è la relazione principale in ciascuna delle fasi per esplicitare l’esito positivo del procedimento di verifica alla luce dei test realizzati dal partner QA. Se
necessario questa relazione può essere sottoscritta da chi corrisponde, in quanto serve di documento per autorizzare il pagamento;
c. Riunione per revisionare il procedimento iterativo: in questa riunione il Comitato
di Controllo della Qualità analizza e discute la relazione presentata per concordare qualsiasi eventuale cambiamento da apportare al piano iterativo, nelle
consegne o nel calendario delle verifiche.
E’ importante definire con lago anticipo questo tipo di attività , assicurarsi che
tutte le parti coinvolte definiscano le risorse necessarie per la loro partecipazione
alle riunioni e per produrre la necessaria documentazione.
5.4.8 Prodotti
Il Comitato di Controllo della Qualità ha la responsabilità di consegnare e di
rendere disponibili ad altre parti interessate i seguenti prodotti:
● Documentazione sui requisiti: possibilmente sotto forma di diagrammi UML use
case.
● Elenco delle singole specifiche: compresa la data di consegna e la data per i test
di verifica
● Iteration report (rapporto iterattivo): è un sommario del lavoro che fa parte della
relativa iterazione, dei test di verifica realizzati e di ogni decisione presa che implica un cambiamento di quanto prima concordato.
● Testing scripts (descrizioni dell’esame di verifica): la natura di questi dipende dal
tipo di verifica. Se il test di verifica è un unit test, il prodotto sarà il codice mentre
se si tratta di una verifica funzionale, il prodotto sarà un documento che descrive
i passi da compiere per testare la funzionalità (si veda la sezione 5.4.4).
5.5 Raccomandazioni generali
Ci sono alcune raccomandazioni di carattere generale basate sulle buone pratiche, che
occorre tenere presente quando si gestisce lo sviluppo del software Open Source.
Le guide di Ancitel
37
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
5.5.1 Rilascio anticipato
L’esperienza ci indica che la metodologia iterativa è quella più adatta e, nel
caso dell’ Open Source, c’è anche un beneficio in più: quello di permettere alle
parti interessate (società software e altri sviluppatori) di accedere al codice abbastanza pronto.
5.5.2 Code freeze
Una metodologia iterativa non dovrebbe essere confusa con la capacità di
improvvisare dalla sera alla mattina. E’ importante che durante il progetto vengano fissate le consegne in modo concreto e che venga costantemente monitorato
la compatibilità con gli standards e le scadenze di progetto definite. Una delle
situazioni più difficili del processo di controllo della qualità è quando il target
(l’obiettivo a cui puntare) muta con una certa rapidità. L’indicazione utile è quella
di stabilire un code freeze, cioè avere un accordo preciso sulla stabilità delle APIs e
del data model (modello dei dati). Questo aspetto dovrebbe costituire una delle
pietre miliari (milestones) del progetto. E’ inoltre importante essere flessibili e non
forzare un “congelamento” che possa mettere a rischio le funzionalità. Si tenga
presente che se il codice diventa un “obiettivo mobile”, i tre tipi di test identificati
in precedenza ne verranno influenzati, ma soprattutto le unit test automatizzate
dovranno essere riscritte. Un altro punto rilevante nel code freeze è l’integrazione.
Se il progetto viene sviluppato in “ambienti di sviluppo” separati tra loro, il code
freeze è essenziale per poter fare i ponti tra questi ambienti e permettere un corretto funzionamento dell’attività di sviluppo fino al rilascio definitivo del software.
5.5.3 Strumenti di collaborazione online
In molti casi in cui ci sono progetti consegnati da “ambienti di sviluppo” separati, fisicamente distanti, risulta determinante che venga stabilito una modalità di condivisione della conoscenza. Ci sono degli strumenti di collaborazione online come
Phproject sviluppato come CCT (communication end controlling tool) per la EQUAL,
TCA 866 project: http://137.224.153.58/documentation/EQUAL_manual_en.pdf.
6
Modelli di sostenimento
6.1 Gruppi di utenza
Una volta completata la fase di sviluppo, la sostenibilità diventa la priorità. Nel
caso dell’Open Source è particolarmente importante pensare alla strategia di sostenibilità del prodotto, a causa delle importanti differenze con il software tradizionale.
I gruppi di utenza sono un modello comunemente utilizzato per riunire i principali interessati nell’utilizzo del software a discutere il suo indirizzo. La definizione
del ruolo del gruppo utente fatta dal gruppo di utenti SAP è un buon esempio:
“La nostra missione è diretta ed efficace: educare i nostri membri, facilitare il lavoro di rete tra i nostri colleghi e i diversi rappresentanti SAP, influi-
38
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
re sull’indirizzo e le versioni future di un prodotto SAP. Ciascuno dei nostri
programmi viene progettato ed eseguito avendo in mente questi obiettivi” (5 Americas’ SAP Users’ Group http://www.asug.com/about/history.cfm.
Nei progetti Open Source c’e una differenza essenziale che ha a che vedere con
il potere di decidere. Chi è che decide sulla risposta alla seguente domanda di base:
“Quale sono gli elementi costitutivi di una release (rilascio di un software)?”. Nel
caso del software proprietario, il gruppo di utenza può tentare di influenzare o cercare di intervenire rispetto a questa o quella funzionalità, ma la decisione finale su
cosa andrà a finire nel prossimo rilascio è molto chiara. Nel caso del software OS, le
cose sono diverse, il codice è disponibile, quindi è possibile per chiunque è interessato iniziare ad aggiungere delle proprie modifiche senza dover attendere il prossimo
rilascio. Questa è una delle qualità migliori del software OS, però si corre il pericolo
di finire con una “biforcazione del codice” e tutti gli sforzi fatti saranno diluiti in
diverse versioni concorrenti dello stesso software originale. Tuttavia, si configura uno
scenario di concorrenza molto attivo quando il mercato sarà stabile, dando la possibilità alle società o gruppi di sviluppatori di scegliere in base al loro business case, il
prodotto più vicino fra i diversi software concorrenziali. Non è invece il caso di un prodotto lanciato di recente, che non avendo avuto il tempo di maturare, si dissolve in
una serie di ramificazioni, senza che abbia prima dimostrato a se stesso di essere una
reale alternativa. La costituzione di un gruppo di utenti per far fronte questo tipo di
scenario è una componente molto importante in ogni progetto Open Source che si
pone l’obiettivo di creare una comunità attorno a quella soluzione OS.
Nel caso di progetti di sviluppo di e-Government, la funzione di indirizzo del
gruppo di utenti risiede in modo abbastanza naturale nel gruppo che ha lanciato il
progetto originale. Il problema è che in molti casi questi gruppi sono creati esclusivamente per la durata del progetto e non ci sono risorse disponibili per continuare successivamente con i gruppi di utenza. Questo è un problema molto pratico che deve
affrontare il software Open Source. Infatti, bisogna riconoscere che l’investimento in
Open Source ha una differenza importante con il resto, poiché richiede l’allocazione
di fondi specifici per la sostenibilità. Uno dei primi utilizzi di questo denaro dovrebbe
essere destinato proprio a formare un gruppo di utenti stabile.
Il punto di partenza per organizzare il gruppo di utenti dovrebbe essere l’invito
a partecipare ad un nucleo di potenziali utenti che sarebbero tra i primi ad adottare
il software. In molti progetti di sviluppo OS c’è l’interesse a sviluppare delle soluzioni
di carattere pratico e ciò si riflette nel ruolo che hanno nel progetto l’implementazioni pilota. In generale, le implementazioni pilota avranno il beneficio di essere degli
sperimentazioni finanziate, fatto che giova sia al team di sviluppo che al processo
interno di implementazione pilota. Una volta terminato il progetto, alcuni dei processi della implementazioni pilota verranno gestiti dal software sviluppato durante lo
stesso. Questo è un indice del grado di successo avuto dal progetto, ma siccome
diverse organizzazioni vorranno imparare dall’esperienza realizzata e le società di
software si faranno avanti per offrire dei servizi associati al software, c’e un reale
rischio di una molto veloce frammentazione.
Le guide di Ancitel
39
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Se si prende la decisione strategica di formare un gruppo di utenti che sarebbero i primi ad adottare il software, c’è una buona possibilità di evitare questa frammentazione e di coordinare la gestione del prodotto nell’immediato futuro . Quando
la base di utenti crescerà e ci saranno più organizzazioni coinvolte, può diventare
importante prendere in considerazione alcune opzioni, come la gestione condivisa
degli acquisti che sono necessari, anche se inizialmente la cosa più importante è avere
una buona piattaforma che tenga insieme il prodotto e permetta di condividere le
informazioni.
6.1.1 Creazione di sottogruppi: (tecnico, training, standards, di accessibilità)
I gruppi di utenti possono attrarre diversi tipi di utenza provenienti dalle organizzazioni partecipanti e sarà molto importante suddividerli in diversi sottogruppi
in base alle loro specialità. Alcuni sottogruppi da considerare sono:
a. Tecnico: questo sottogruppo scambia informazioni sul deployment (implementazione diffusa) la manutenzione e lo sviluppo. Esso ha anche una grossa responsabilità nella determinazione del contenuto dei diversi rilasci del software;
b. Formazione: questo sottogruppo affronta le necessità di training all’interno dell’organizzazione che adotta il software. La formazione può tradursi in sessioni
di formazione dei formatori così come nella produzione di manuali di formazione.
c. Commerciale: questo è un altro sottogruppo indispensabile. Senza “venditori” che
forniscono servizi funzionali al sostenimento del progetto. lo stesso è seriamente a
rischio. L’obiettivo principale di questo sottogruppo è quello di scambiare informazioni con i diversi sistemi di distribuzione, di facilitare il lavoro in rete e di riuscire a
far capire quali servizi possono essere utilizzati dalla distribuzione commerciale.
6.2 Capacità In-house
E’ abbastanza sintomatico trovare in tutte le organizzazioni delle resistenze ai
cambiamenti, in particolar modo se la sfida delle nuove tecnologie vuol dire espandere le capacità all’interno. Questo è particolarmente vero nei progetti di sviluppo
che introducono un nuovo software. Un fattore critico di successo per il sostenimento è il modo in cui viene gestito l’introduzione del software nell’organizzazione, sviluppando e diffondendo le capacità in-house (interne) per “appropriarsi”
veramente del nuovo software
Non tutte le organizzazioni hanno un team di sviluppo interno, in alcuni casi la
politica è quella di esternalizzare questa funzione (outsourcing) oppure di avere un
fornitore esterno con un contratto a tempo determinato. Nei progetti Open Source
fin dai primi stadi è importante provare a coinvolgere nel processo il team ICT interno. Se non c’è un gruppo di sviluppo, il CED o chi ne fa le veci può decidere se
organizzare internamente il servizio o se farlo partire come un servizio interamente gestito dall’esterno. Se c’è un team di sviluppo interno, una delle prime misure
per integrarli è quella di allocare risorse per la funzione di controllo qualità.
40
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
6.2.1 Test sulla documentazione a carico del gruppo di sviluppo interno
Come descritto nel paragrafo 5.4.4 esistono diversi approcci ai test di un utente.
Uno dei modi migliori per incoraggiare la comprensione in-house del progetto è di assegnare la verifica della documentazione agli sviluppatori interni e/o staff tecnico. Questo
principio è consigliato vivamente da questa guida, fare in modo che le persone a cui
servirà il software vengano coinvolti ancora prima in modo da attrarre la loro attenzione. Se l’unità interna ICT sa come si dovrà utilizzare il software sviluppato dal progetto, farà un miglior lavoro di controllo qualità, perché consapevole che questo compito
renderà più facile un domani il loro lavoro quotidiano. Inoltre, se gli sviluppatori interni
sanno che gli verrà richiesto prima o poi di ampliare, mantenere oppure di migliorare il
software introdotto essi saranno molto più interessati a capirne gli scopi.
6.3 La comunità di sviluppo
Di tutti i modelli di sostenibilità l’organizzazione di una comunità di sviluppo è
di gran lunga quello più comune. In generale, il coinvolgimento necessario a tale
scopo sarà stimolato dalla produzione di un buon software, da una buona documentazione e da strumenti di collaborazione on-line, ecc. Un eccellente modello di
questo tipo di ambiente è Sourceforge: http://sourceforge.net . Un buon studio per
approfondire le motivazioni che muovono la comunità di sviluppo Open Source,
può essere trovata nel sito http://flossproject.org/papers.htm.
Come parte di questa strategia un altro importante obiettivo dovrebbe essere
non solo di coinvolgere sviluppatori individuali, ma anche piccole e medie imprese
locali di sviluppo software. La situazione di partenza è quasi sempre la presenza di
un sviluppatore che lavora per una PMI, che trova il progetto interessante e vuole
coinvolgere la sua impresa, ma si possono ottenere anche buoni ritorni invitando
formalmente le PMI locali a far parte del gruppo di utenti.
6.4 Modelli di supporto
Uno dei “problemi” conosciuti del software Open Source per le piccole e
medie imprese locali è la mancanza di modelli di supporto e di assistenza al cliente. Non è questo il luogo in cui discutere la veridicità di queste accuse. In verità,
esistono modelli di supporto e di assistenza per il software Open Source, e questa
Guida intende ora indicare alcuni:
6.4.1 JBoss
L’application server JBoss http://www.jboss.org è uno dei progetti più importanti
nell’enterprise java world (J2EE). JBoss Inc. è una compagnia fondata dagli sviluppatori originari dell’applicazione. La società offre supporto e assistenza diretta on line
alla produzione di software sempre, oppure un supporto indiretto attraverso i loro
partner certificati per il servizio. Essi offrono anche formazione e documentazione.
Le guide di Ancitel
41
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
6.4.2 MySQL
MySQL AB, la società che sta dietro al database MySQL, ha un approccio diverso. Loro distribuiscono il proprio database sotto licenze Open Source e commerciali, in modo da fornire software anche nei mercati in cui l’ Open Source non è fattibile. Forniscono anche diversi pacchetti di supporto fino all’assistenza on-line
continua.
6.4.3 Red Hat Linux
Red Hat Linux si è spostato ad un nuovo campo di licenze open source relative
a sistemi operativi. Hanno sospeso l’erogazione gratuita del loro sistema Red Hat
ha iniziato il progetto Fedora: http://fedora.redhat.com per proseguire il loro impegno con la comunità di sviluppo Open Source. Red Hat ha lanciato la propria versione “Enterprise Linux” cercando di offrire sia la licenza che una forma di abbonamento per il supporto tecnico necessario venendo incontro alle necessità dell’impresa. Red Hat ha anche lanciato una “Open Source Architecture Roadmap” che
descrive in dettaglio i passi che stanno seguendo per aggiornare il loro modello
Open Source, dove il software sale verso i livelli propri del middleware associato a
strumenti di gestione.
42
Le guide di Ancitel
TERZA SEZIONE
Attribuire licenze al software
Open Source
7
Guida alle licenze FLOSS
7.1 Introduzione
FLOSS è un acronimo per “free, libre, open source software”. E’ stato coniato
da Rishab Ghosh per riferirsi al software non proprietario. “Free software” è un
termine spesso usato dalla Free Software Foundation (FSF) per descrivere le proprie iniziative. La Open Source Iniziative (OSI) preferisce utilizzare soltanto il termine “Open Source”. Il termine “libro” è ugualmente usato per descrivere questo
software. Sono differenze terminologiche più ideologiche, che basate su considerazioni di tipo tecnico. FSF e OSI approvano entrambe alcune delle licenze FLOSS e
in alcuni casi tutte due certificano una licenza particolare come compatibili con le
loro pratiche, come è il caso della licenza GNU-GPL.
Questa parte della Guida spiega nel dettaglio le licenze FLOSS, la popolarità
che hanno acquisito alcune di queste licenze tra gli utenti e i motivi che spiegano
tale popolarità. L’idea è quella di mettere in risalto tutto quello che ha importanza
per le autorità locali e regionali interessate allo sviluppo o l’acquisizione di software Open Source.
I problemi potenziali associati al copyright e alle questioni contrattuali non
sono parte di questa guida, in quanto le licenze FLOSS non hanno per il momento generato molte situazioni di litigio all’interno dell’Unione Europea.
E’ degno di nota che la maggior parte delle decisioni riguardanti la licenza da
adottare non vengono prese da avvocati, ma piuttosto dagli stessi sviluppatori del
software. Ciò mette in rilievo la mancanza di attaccamento agli aspetti legali da
quelli che adoperano queste licenze. Infatti, i programmatori scelgono la licenza in
funzione del modello di sviluppo che ha il software che preferiscono o che è prodotto dallo stesso mondo a cui appartengono gli sviluppatori. Così, i termini e le
condizioni delle diverse licenze sono solitamente ben conosciuti dagli sviluppatori
FLOSS.
7.2 Considerazioni preliminari
I governi locali e regionali coinvolti per la prima volta nello sviluppo o acquisizione
di un software FLOSS dovrebbero essere consapevoli sulla necessità di guardare la
licenza da diverse prospettive. E’ anche opportuno decidere il modello di licenza chiedendo l’opinione degli sviluppatori FLOSS che hanno esperienza, poiché essi normalmente sanno quale licenza può essere la più appropriata per il progetto in esame.
Le guide di Ancitel
43
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Converrebbe anche affidarsi ad uno studio di avvocati specializzati su copyright
e contratti, per identificare i potenziali punti deboli delle licenze FLOSS in esame.
Il contatto con lo studio legale va condiviso con gli sviluppatori di software
poiché la maggior parte degli avvocati che lavorano nel campo della “information technology law” o “intellectual property law” trascurano gli aspetti
socio-legali che sono molto importanti nelle licenze FLOSS. Per capirci, la
GNU-GPL, che è la licenza FLOSS più comunemente usata, non è stata scritta da un avvocato ma da un programmatore, Richard Stallman.
Diversamente di quanto succede con le licenze di software proprietario che
sono spesso violate più che osservate, la GNU-GPL viene rispettata ed ha
oggi una affermazione quasi universale, dopo quindici anni di vita. Quindi,
se gli avvocati si mettono a lavorare da soli potrebbero non afferrare alcuni punti essenziali sul funzionamento delle licenze FLOSS, e potrebbero
favorire delle leggi che distruggono ciò che loro vorrebbero proteggere,
oppure non capire a dovere le motivazioni che sono dietro lo sviluppo
FLOSS dal punto di vista di tutti gli attori coinvolti).
E’ abbastanza prevedibile che nel medio-lungo termine sarà comunque necessaria una direttiva UE, oppure una altra forma di legislazione, al fine di chiarire ogni
dubbio su problemi legali delle licenze Open Source e delle licenze proprietarie.
Qualsiasi persona che ha una qualunque autorità sullo sviluppo FLOSS, dovrà
fare attenzione quando le modifiche sono da effettuare su un progetto FLOSS esistente, in modo da non infrangere i termini della licenza. In caso contrario questa
autorità potrebbe essere ritenuta responsabile di aver infranto il copyright oppure
il contratto e in aggiunta, essere vista in forma molto negativa dalle comunità
FLOSS esistenti. Una speciale attenzione deve essere data al software FLOSS che è
composto da diverse pezzi di software rilasciati sotto diverse licenze, in quanto ciò
che è o non è permesso, potrebbe non essere del tutto chiaro.
7.3 Dove trovare le licenze FLOSS
I termini e le condizioni della maggior parte delle licenze FLOSS sono disponibili nei seguenti siti web:
http://www.fsf.org/licenses/licenses.html
http://www.opensource.org/licenses
Alcune licenze FLOSS sono approvate dalla Free Software Foundation (FSF), il
cui fondatore ha scritto le più diffuse licenze FLOSS: le GNU General Public Licence
o GNU GPL. La Open Source Iniziative (OSI) approva diverse licenze, inclusa la GNU
GPL. Invece, la maggior parte delle licenze approvate dalla OSI non vengono sottoscritte dalla FSF.
E’ auspicabile che i governi locali e regionali abbiano un approccio pragmatico in
relazione alle licenze FLOSS: decidano prima come vogliono gestire il loro software
in termini di permessi garantiti agli utenti e ad altri programmatori per poi scegliere la licenza più adatta. La GNU GPL viene usata in più dell'80% dei progetti FLOSS
44
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
nel mondo. Altre licenze con un certo grado di popolarità sono la LESSER (un
tempo Library) GNU-GPL e la licenza BSD (con le sue varianti, le cosiddette “BSDstyle licences”). In totale ci sono probabilmente 50 licenze FLOSS attualmente in
uso. Oltre ad utilizzarle si può anche creare delle nuove. E' sicuramente più semplice scegliere una licenza esistente che crearne una nuova, tenuto conto che le
nuove licenze potrebbero non essere compatibili con quelle già esistenti.
7.4 Perché assegnare licenze?
FLOSS così come qualsiasi software ha automaticamente la protezione del copyright a favore degli sviluppatori senza che ci sia alcun bisogno di registrare l'autore.
Molte ditte preferiscono tuttavia di farlo. Il copyright non consente a terzi di accedere ai programmi se non c'e una licenza. Sotto questa veste, le licenze sono permessi
per garantire l'accesso al software e l'esercizio di alcuni diritti, sempre che vengano
rispettate le condizioni stabilite nella licenza.
Le licenze di software proprietario permettono di utilizzare il software ma non di
copiarlo, modificarlo, o di realizzare il cosiddetto “bug fixing”. FLOSS è al lato opposto e gli sviluppatori FLOSS potrebbero addirittura rilasciare un software
rinunciando,tutti insieme, alla protezione del copyright (ciò accade molto raramente,
ma un esempio qualificato di ciò è stato quello del software World Wide Web).
Questo approccio può creare dei problemi quando i fondi che vengono utilizzati per
sviluppare il software FLOSS sono di natura pubblica poiché il software dovrà essere
modificato in seguito e potrebbe essere privatizzato da qualcuno in assenza di restrizioni stabilite dalla licenza. Se un programma proprietario viene costruito sopra un
software FLOSS e questo software Open Source diventa poi uno standard, gli utenti
(per esempio, i governi locali) potrebbero trovarsi nella situazione di dover pagare
tutto il software per avere lo standard, oppure darsi da fare per creare a loro volta
un'alternativa che sia puramente software FLOSS (senza l'applicazione di software
proprietario, sprecando sicuramente tempo e denaro). E' pertanto auspicabile che
come minimo ogni software FLOSS sviluppato da o per un governo locale o regionale venga sempre rilasciato sotto una qualsiasi forma di licenza FLOSS, piuttosto che
rinunciare al copyright.
L'arco delle licenze FLOSS va dalla licenza BSD, che permette agli utenti e a coloro che vogliono effettuare delle modifiche di fare praticamente qualsiasi cosa con il
codice, alla licenza GNU-GPL, che permette anche di copiare e utilizzare il software,
con la condizione però che qualsiasi modifica fatta al codice sorgente deve essere pubblicata e resa accessibile anche ad altri. Le altre licenze FLOSS che si possono elencare
sono delle varianti intermedie tra questi due estremi.
Molte di queste varianti si avvicinano alla licenze BSD (sono le licenze BSD-style) o
sono delle licenze riscritte per essere il più vicino possibile alla GNU-GPL, che è la licenza FLOSS più diffusa.
Le guide di Ancitel
45
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
7.5 Le Licenze BSD
Le licenze BSD erano originariamente usate per il software sviluppato in ambito universitario, in particolare l’accesso senza restrizioni alla versione Unix
dell’Università di Berkeley, in California. Tra le regole da rispettare quando si utilizza un software con questa licenza, conviene sottolineare le seguenti:
- le note di copyright devono essere mantenute;
- il ricercatore e la sua istituzione devono essere nominati (come nella legge roma
na oppure nel diritto civile che regola il copyright: prima che essere un diritto
economico è una specie di diritto morale e d’autore);
- deve essere richiesto un permesso quando si vuole usare il nome dell’autore per
attribuirsi lavori derivati da questo software (questo caso si può presentare per
esempio quando degli sviluppatori esterni hanno modificato il codice già sviluppato da un ente locale). Si tratta di una clausola auspicabile in quanto impedisce delle false attribuzioni, per esempio se qualcuno afferma che il software
modificato è stato sviluppato dall’ente locale a sua insaputa, danneggiando di
fatto la reputazione che hanno i prodotti (applicativi) dell’istituzione.
Alcune licenze BSD più vecchie richiedevano la nomina espressa dell’autore del
software in qualsiasi materiale pubblicitario. Questa condizione fu poi rimossa in
quanto si è rivelata troppo onerosa (se si sceglie una licenza di tipo BSD, conviene
rassicurarsi che si tratta di una nuova licenza BSD senza questa clausola (fu anche
rimossa per venire incontro alle pressioni di chi voleva una licenza BSD compatibile
con la GNU-GPL).
Le licenze BSD permettono la modifica del codice sorgente e tale modifiche
possono essere usate come si vuole, purché soggette alle tre restrizioni sopraccitate. Il software sviluppato sotto questa licenza può essere utilizzato nella creazione
di lavori derivati di natura proprietaria, in cui il codice sorgente non viene reso
disponibile. Così, questo tipo di licenza ha facilitato la crescita di internet. Le Free
BSD sono ampiamente diffuse. La licenza è adatta specialmente laddove gli sviluppatori di software non sono interessati all’accesso al codice sorgente, o ai lavori
derivati basati sul loro software. Potrebbe non essere adatta dove viene utilizzato
il denaro pubblico nello sviluppo dei FLOSS: la maggior parte dei cittadini vorrebbe vedere un ritorno di qualsiasi tipo in cambio dell’utilizzo di quel denaro.
Le licenze di tipo BSD-style governano prodotti FLOSS come BSD Unixes, BIND,
Sendmail e Apache.
Uno dei membri fondatori di Apache sostiene che le compagnie che utilizzano
questo web server dovrebbero reinvestire nel progetto per incoraggiare la crescita di Apache. Pensa anche che tale tipo di contributo dovrebbe avere un carattere volontario.
(O’Reilly Network, (August 9, 2001). Shared Source vs. Open Source: Panel
Discussion, www.linuxdevcenter.com/pub/a/linux/2001/08/09/oscon_panel.html
(June 8, 2004 edition).
46
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Dal punto di vista di un qualsiasi ente locale che studia l’utilizzo di una licenza BSD-style, si possono presentare i seguenti vantaggi e svantaggi.
7.5.1 Vantaggi
a. Poiché le licenze BSD pongono poche condizioni, hanno un minimo di conflittualità. In questo modo sarà tutto più semplice per il governo locale o regionale. Ciò potrebbe anche ridurre i rischi potenziali di una causa legale.
b. Le licenze di tipo BSD-style sono state molto popolari e hanno avuto un discreto successo in alcuni progetti ( Wheeler, D.A., ( Revised, April 7, 2004): Make
Your
Open
Source
Software
GPL
Compatible.
Ancora,
http://www.dwheeler.com/essays/gpl-compatible.html ( April 19, 2004 edition).
c. Le licenze BSD non sono utilizzate in maniera diffusa e non hanno una domanda tale da generare contenziosi giudiziari (il processo giudiziario attivato da
SCO contro IBM negli Stati Uniti che mette in discussione - tra varie cose - la
legalità della licenza GNU-GPL, ha un carattere profondamente politico e ha
come motivazione attaccare le condizioni restrittive a cui sono sottoposti i lavori derivati dal software originale, condizioni che non si presentano in verità nelle
licenze BSD)
7.5.2 Svantaggi
a. Il codice sorgente dei lavori derivati può diventare non acessibile. In altre parole, le società di software proprietario possono realizzare delle aggiunte al software originale facendolo diventare un software “proprietario”. Ciò può finire
per rendere obsoleto questo software in un breve periodo di tempo, se viene
creato uno standard di natura proprietaria. Gli enti locali sì troveranno così nel
dilemma di dover trovare o sviluppare un’alternativa FLOSS, pena di dover
comprare il programma proprietario.
b. Permettere biforcazioni di codice proprietario all’interno può facilmente portare alla divisione del progetto. Infatti, può in definitiva portare a versioni multiple o incompatibili tra loro, tutte quante costruite sullo stesso codice base
FLOSS.
c. Se viene utilizzato denaro pubblico nello sviluppo del software FLOSS, il fatto di
decidersi per una licenza BSD potrebbe generare degli interrogativi all’interno
dell’ente su un eventuale miglior utilizzo dei fondi allocati.
7.6 La licenza GNU General Public License (GNU GPL)
La GNU GPL è attualmente la più comune licenza FLOSS utilizzata nel mondo.
E’ stata scritta dalla Free Software Foundation, allo scopo di fornire un modello
legale alternativo per lo sviluppo di software diverso dal software proprietario, così
come per neutralizzare quella che la FSF considera debolezze delle licenze BSD.
All’occorrenza la FSF aveva la percezione che un team di sviluppatori poteva
Le guide di Ancitel
47
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
creare un programma FLOSS (cioè open source), il quale risultava successivamente
modificato da qualcuno, trasformando lo stesso in software proprietario, chiudendo così la strada ad altri liberi contributi. C’era la volontà da parte del FSF di creare un nuovo tipo di software in comune: uno che fosse arricchito attraverso la partecipazione piuttosto che lasciato da parte o reso obsoleto.
Ci sono attualmente diversi progetti nel mondo che tentano di rafforzare lo status legale del GNU-GPL. Questi includono l’impegno del Free Software Consortium
(http://www.fsc.cc per sviluppare una legislazione internazionalmente riconosciuta
per FLOSS e il progetto di Creative Commons (http://www.creativecommons.org )
per adattare la GNU-GPL alle leggi di ogni paese. La sua legalità è attualmente
discussa in un caso giudiziario negli US (il caso SCO contro IBM. Tuttavia, se la
GNU-GPL risultasse accettata dalla giurisprudenza americana, ciò non avrà alcun
effetto legale su altri Stati.)
La GNU-GPL come tutti gli altri modelli di licenza software si affida al copyright
dello sviluppatore software. La FSF richiede che gli sviluppatori assegnino i loro
copyrights all’organizzazione perché si pensa che una tale strategia contribuisca a
stabilizzare e/o difendere in modo efficiente in eventuali cause sul copyright (ciò
differisce dal modello di copyright GNU/Linux in cui ciascun sviluppatore è riconosciuto come autore di specifiche linee del codice. Centinaia di programmatori sono
citati nei credits GNU/Linux. Gli enti locali dovrebbero porre la loro attenzione su
questo punto, allo scopo di decidere se sono d’accordo di diventare titolari del
copyright FLOSS. L’onere sarà quello di difendere e di perseguire ogni qualsiasi
infrazione della licenza. Alternativamente, il copyright per intero potrebbe essere
attribuiti all’autore di una particolare porzione del relativo codice (il tema dell’applicabilità del copyright diventerà materia controversa perché vengono attribuiti
diversi diritti a seconda del paese dell’Unione Europea dove s’applica).
La GNU-GPL permette l’utilizzo, la copia e la modifica di ogni programma concesso sotto licenza GNU-GPL. Al contrario delle licenze BSD, ogni modifica o lavoro derivato deve essere rilasciato anche come GNU-GPL. Questa licenza è utilizzata per il sistema operativo GNU/Linux e ha facilitato la sua crescita rendendo obbligatorio ai partecipanti di contribuire agli obiettivi comuni, piuttosto che trarne dei
profitti individuali . Alcuni programmatori pensano che la presenza di una condizione di questa natura comporti che questo software non sia veramente “free”.
Altri credono che ciò è del tutto giusto in quanto nessuno è forzato a partecipare
e poi i benefici non dovrebbero essere goduti soltanto da una delle parti. La GNUGPL ha superato tutte le altre licenze e si stima che venga utilizzata tra il 50% e
l’80% dei progetti FLOSS nel mondo.
La GNU-GPL contiene alcune delle clausole BSD, come il requisito che gli autori di modifiche debbano identificarsi in quanto tali, ciò come protezione contro le
false attribuzioni. Una delle clausole della GNU-GPL è stata definita “virale”. La
sezione 2, paragrafo 2 della licenza dice che dove un programma software nonFLOSS venga incorporato come componente in un lavoro derivato, l’intero lavoro
dovrà essere comunque rilasciato sotto licenza GNU-GPL. In alcuni ambienti, que48
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
sta clausola viene considerata una interferenza ai diritti proprietari del software.
La GNU-GPL ha più di dieci anni, e soltanto adesso è saltato fuori, per la prima
volta, una causa giudiziaria, ancora in atto, negli Stati Uniti. Ci sono diverse ragioni che spiegano perché la licenza è stata rispettata così a lungo. Essa è stata sviluppata inizialmente per proteggere un certo modello software, quindi, i suoi utilizzatori erano programmatori che volevano lavorare secondo un set di regole prestabilito. Finchè i progetti FLOSS sono stati di piccole dimensioni hanno avuto poca
attenzione all’esterno e la licenza è stata quindi pienamente rispettata all’interno
delle comunità di programmatori che l’avevano fatta ed adottata. Quando negli
anni ’90 le società di software furono coinvolte nello sviluppo FLOSS, i termini della
GNU-GPL divennero oggetto di un’analisi più approfondita. Questa analisi risulta
condizionata dallo sviluppo di due campi rivali all’interno delle comunità FLOSS
(“free software” versus “open source”). Le grosse società di software ebbero
comunque un forte incentivo per sostenere la licenza GNU-GPL, dati i benefici portati dalla revisione estesa del software, il tracciamento dei bugs e i contributi creativi forniti da tanti programmatori in tutto il mondo.
A causa della popolarità acquisita dalla GNU-GPL, del trattamento non convenzionale ma efficace dei diritti di proprietà intellettuale, la causa SCO contro IBM, è
stata vissuta in modo negativo, come un tentativo di attaccare l’egemonia della
licenza all’interno delle comunità di sviluppo FLOSS. Tuttavia, è servito per avviare
delle iniziative di studio in tutto il mondo, per cercare delle possibili soluzioni sul
piano legale. Gli enti locali e regionali che vogliono fare uso di una licenza FLOSS,
dovrebbero comunque privilegiare una discussione su cosa vogliano realizzare con
il codice sorgente, piuttosto che dilungarsi nelle questioni di natura legale. Questi
problemi dovranno comunque essere risolti dalla Commissione Europea man mano
che crescerà il numero di progetti FLOSS all’interno dell’UE.
7.6.1 Vantaggi
a. Il primo vantaggio della GNU GPL è che essa tende ad incoraggiare la realizzazione di progetti di collaborazione dove vengono massimizzati i risultati per
qualsiasi input. Economicamente ciò ha un senso, ma la licenza porta anche ad
avere software molto stabili, visto che viene revisionato da un’ ampia platea di
programmatori normalmente molto stimati sul piano professionale, anche per
i rilevanti contributi allo stesso software.
b. Si tratta della licenza FLOSS più comunemente usata nel mondo e che ha fatto
“massa critica” a causa delle clausole che costringono a rilasciare qualsiasi
modifica anche sotto licenza GNU-GPL. Le licenze alternative che restringono
l’accesso al codice di base risultano meno attrattive agli sviluppatori e questo è
un forte incentivo per il suo utilizzo.
Le guide di Ancitel
49
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
7.6.2 Svantaggi
a. I costi per applicarla e farla rispettare possono diventare alti e/o laboriosi.
Tradizionalmente, le dispute sulla eventuale violazione della licenza GNU-GPL
vengono risolte informalmente dai contendenti attraverso chiamate telefoniche, posta elettronica e qualche volta con l’aiuto della FSF. Questo meccanismo informale utilizzato per risolvere le controversie, data l’ampia diffusione
della licenza,non sarà più nei prossimi anni una via così facilmente percorribe.
b. Viene vista come una licenza molto politicizzata e, guardando il punto di vista
dell’autore, è percepita (spesso erroneamente) come ostile ai diritti di proprietà intellettuale.
c. E’ dal 19 aprile 2004 oggetto della causa legale citata negli Stati Uniti.
7.7 Il contributo “Creative Commons”
Il progetto Creative Commons è nato nel 2001 grazie all’opera di alcuni giuristi californiani tra cui Lawrence Lessig, che ne è l’esponente di spicco in qualità di
docente presso la facoltà giuridica dell’università di Stanford, e che in questa veste
è stato uno degli ispiratori della cultura open content, nonché un sostenitore del
progetto GNU (http://www.lessig.org ).
In Italia il progetto ha avuto subito un riscontro a livello universitario, in particolare Juan Carlos De Martin, professore associato di ingegneria dell’informazione
presso il Politecnico di Torino, e il prof. Marco Ricolfi del Dipartimento di Scienze
Giuridiche dell’Università di Torino. Grazie al loro contributo è stata curata la versione italiana delle licenze Creative Commons (http://www.creativecommons.it).
L’obiettivo originario del progetto è quello di pensare un modello alternativo di
diritto d’autore sulla scorta degli esempi sperimentati nel software libero e open
source ma guardando in particolare alle opere di carattere artistico-espressive.
Con “I Commons” e cioè International Commons si fa riferimento proprio alla
internazionalizzazione delle licenze Creative Commons. Il processo vede ormai 39
progetti nazionali, alcuni completati altri in dirittura d’arrivo. In Italia coinvolge
appunto il DSG dell’Università di Torino e l’IEIIT ovvero l’Istituto di Elettronica e di
Ingegneria dell’Informazione e delle Telecomunicazioni presso il CNR.
I giuristi californiani hanno pensato degli standard di base (attribuzioni) che si
ritrovano in tutte le licenze. Su questo modello di base si innestano delle variabili
a seconda delle diverse esigenze degli autori, secondo un ordine di valori che vede
sei licenze attualmente, dalla più permissiva ad una più restrittiva. In dettaglio sulla
Attribuzione 2.0 si innestano la Attribuzione-Non opere derivate, la AttribuzioneNon commerciale-Non opere derivate, la Attribuzione-Non commerciale, la A-Non
commerciale-Condividi allo stesso modo e la Attribuzione-Condividi allo stesso
modo.
In ragione delle citate difficoltà per un non giurista nella interpretazione di
tutte le clausole di una licenza, l’idea originale dei creatori di CC è stata quella di
50
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
affiancare alla versione Legal Code che rappresenta la licenza con valore legale,
una versione Common Deeds, ovvero “Atto per persone comuni” in cui si sintetizzano in un vero e proprio sunto intelligibile i concetti chiave alla base del Legal
Code. Lo scopo è quello di agevolare la scelta della licenza più consona alle proprie esigenze linkando poi in ogni caso alla vers. Legal Code.
Inoltre i promotori di CC hanno pensato a facilitare la reperibilità su internet
delle licenze confezionando una terza versione “Digital Code” in cui una serie di
metadati sono stati predisposti perché possano agevolmente essere rintracciati dai
diversi motori di ricerca presenti sul web.
Tornando all’aspetto più importante e cioè all’adattamento delle licenze CC ai
diversi ordinamenti giuridici, conviene sottolineare che l’approccio specialistico dei
soggetti coinvolti nel progetto ha fatto si che si sia ottenuta non semplicemente
una traduzione pura e semplice delle singole licenze nelle diverse lingue e per
quanto ci riguarda in italiano, ma un contestuale adattamento (porting) delle singole clausole in ragione dei diversi ordinamenti giuridici coinvolti. Nel caso nostrano, il gruppo italiano ha ritenuto di optare per una traduzione essenzialmente
fedele all’originale e questo emerge dai documenti ufficiali confrontabili visitando
le pagine del sito italiano per CC (http://www.creativecommons.it/aspettigiuridici ).
(Cfr. Simone Aliprandi, Teoria e pratica del copyleft- www.copyleft-italia.it/libro2 )
7.8 Problemi comuni delle licenze FLOSS
a. Alcune delle questioni sul copyright non sono chiare: mentre il software è protetto dal copyright garzie alla Convenzione di Berna, i diritti che ciascun paese
garantisce ai programmatori sotto le proprie leggi che regolano il copyright
risultano abbastanza diversi. Da una prospettiva legale, tutto ciò non facilita la
collaborazione su FLOSS tra i diversi Stati Membri. La necessità di rendere simili le leggi in questa area per proteggere specificatamente i diritti di utenti e sviluppatori di FLOSS, è ormai un imperativo a livello della Unione Europea.
b. Le leggi che regolano i contratti, relativamente alle condizioni delle licenze, non
sono uniformi in Europa. I termini delle licenze certamente possono essere modificati per via contrattuale in ciascun paese ma ciò non è auspicabile, soprattutto
perché spesso diversi paesi risultanto coinvolti nello sviluppo FLOSS e diventa un
problema se le stipule contrattuali differiscono da uno Stato Membro ad un altro.
c. Tutte le licenze software, sia proprietarie che FLOSS, escludono ogni forma di
garanzia. Ma ci possono essere delle giurisdizioni dove ciò non accade e per questo c’è bisogno di trovare una soluzione urgente all’interno dell’Unione Europea.
d. E’ più che necessaria un’iniziativa per organizzare un team di avvocati che lavorino in stretta collaborazione con i programmatori FLOSS, per esaminare le questioni legali all’interno e fuori dell’UE, in modo da anticipare potenziali problemi legali e di trovare le migliori soluzioni per i problemi già identificati.
Le guide di Ancitel
51
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
7.9 Raccomandazioni per gli enti locali e regionali coinvolti nello sviluppo
di FLOSS
Quando si sviluppa FLOSS occorre decidere prima, cosa si vuol fare con il codice sorgente.
7.9.1 Licenze BSD
Se il progetto non è costoso e non c’è un beneficio reale nel controllare cosa
accadrà con il codice sorgente, la licenza BSD potrebbe essere la scelta più adatta. Se le società coinvolte desiderano contribuire volontariamente al progetto, questa licenza potrebbe anche funzionare. Un buon esempio, è il caso del web server
Apache, che ha riscosso un grande successo utilizzando una licenza BSD-style e
ricevendo molto supporto dall’IBM.
7.9.2 Utilizzo delle licenze GNU GPL
Se molte risorse sono state investite in un progetto FLOSS ed è stato utilizzato
del denaro pubblico, la GNU-GPL dovrebbe essere il modello più appropriato. Ciò
porterà maggiori risultati in termini di contributi al codice base, revisioni e bug tracking (ricerca di bacche). Se il software FLOSS non è stato sviluppato dall’inizio e la
licenza originale è stata una licenza BSD che rispecchia le condizioni minimali citate in precedenza, quando il codice viene poi modificato potrebbe essere rilasciato
sotto licenza GNU GPL, poiché il codice che è stato concesso attraverso una licenza BSD gode di molta libertà.
7.9.3 Utilizzo della doppia licenza
Qualsiasi progetto può essere rilasciato simultaneamente sotto due diverse
licenze. Ciò può avere effetti desiderabili e indesiderabili. La libertà per l’ente locale/regionale è massima quando dovrà decidere sui futuri utilizzi del codice.
Massimizza anche, almeno inizialmente, le scelte che dovranno fare i programmatori. Il principale effetto non desiderato è che nasceranno due versione incompatibili tra loro, qualora il progetto venga diviso. Una volta diviso, un’eventuale futura
integrazioni dei due comporterà nuovi costi e dispendio di tempo. Inoltre, potrebbe addirittura non essere fattibile secondo i termini delle licenze adottate. Per contro, il modello di sviluppo software regolato dalla GNU-GPL è diventato popolare
perché l’integrazione viene facilitata dal fatto che tutte le modifiche al codice sorgente sono accessibili.
8
Perchè avere una legge separata (direttiva) per le FLOSS in ambito
Unione europea
1. La legalità della GNU GPL è stata messa in discussione negli Stati Uniti. La società che l’ha richiesta ha minacciato di estendere la causa ad altri paesi. Ciò
potrebbe danneggiare seriamente lo sviluppo futuro di FLOSS.
2. L’UE sta sviluppando attivamente FLOSS affidandosi pesantemente a GNU-GPL.
52
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Se venisse messa in dubbio la sua validità sul piano legale dalla SCO, sarebbe
possibile ancora usare FLOSS, ma potrebbe essere negato l’accesso alle modifiche fatte al codice o persino l’accesso al codice FLOSS stesso. Ciò potrebbe
diventare un colpo di fortuna per alcune società software, se poi esse creano
uno standard: l’investimento andrà perso, e sarà necessario ideare un altro
modo per creare un software simile oppure l’UE dovrà pagare per il nuovo software che è stato “privatizzato”.
3. La GNU GPL si basa sulla combinazione tra le leggi che regolano i contratti ed
il copyright. Entrambe queste leggi variano da paese a paese, per cui le clausole possono essere valide in un paese ma non in un altro. Ciò è potenzialmente
dannoso per lo sviluppo futuro del FLOSS, in quanto crea un’insicurezza per cui
i programmatori potrebbero rifiutarsi di essere sottoposti a una licenza FLOSS.
4. Una soluzione ovvia è quella di abbozzare una direttiva europea sul FLOSS e
portare il FLOSS fuori dal mondo del copyright e delle licenze. Una legislazione
di questo tipo non deve interferire con il copyright e le licenze ( i programmatori potrebbero sempre scegliere la GNU GPL come guida per i loro diritti legali), ma se ci fosse una qualsiasi violazione, i diritti degli sviluppatori FLOSS, dei
programmatori e degli utenti sarebbero protetti all’interno dell’ UE.
5. Un’alternativa consisterebbe nell’omologare la GNU GPL in ogni stato membro
cioè riscriverla in modo tale da adattarla alle leggi sul copyright e sui contratti
di ciascun paese. Ci sono due ragioni per non farlo: primo, sarebbe un compito
immensamente oneroso, secondo, darebbe origine a diverse leggi nei paesi
europei, ciascuna delle quali verrebbe applicata solo dal paese che l’ha promulgato. E’ vero comunque che il codice FLOSS creato in un paese potrebbe essere privatizzato con successo in un altro.
6. L’obiezione immediata a una direttiva così pensata è che interferisce con la
legge sul copyright. Non è il caso come già indicato nel punto 4. Questa direttiva elencherà i diritti degli sviluppatori del software e degli utilizzatori in una
situazione come quella argomentata da SCO nella causa americana. Questo
significherebbe che se SCO, per esempio, tentasse di violare la GNU GPL, ciò
non avrebbe rilevanza, perché il modello di sviluppo FLOSS sarebbe già protetto dalla direttiva europea su FLOSS. Infatti, una direttiva FLOSS ha una sua funzione essenziale quale misura precauzionale contro minacce legali allo sviluppo
FLOSS, situazione che verrà fuori prima o poi. Una tale direttiva non interferirà
con la legge sul copyright.
Le guide di Ancitel
53
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
9
Temi suggeriti per una direttiva FLOSS.
I punti di seguito elencati sono parte di uno studio realizzato dall’autrice di
questa parte della Guida per la rete europea ELANET (CEMR) coordinata da ANCITEL, il quale è stato sottoposto alla supervisione dello staff preposto al mercato
interno della Commissione Europea.
1. La direttiva dovrebbe chiaramente enumerare i diritti degli utenti FLOSS, dei
programmatori e degli sviluppatori (e possibilmente di altri beneficiari del
FLOSS). Diventerebbe una specie di versione codificata dei codici della GNU
GPL ma molto semplificata.
2. La direttiva dovrebbe contemplare delle esenzioni di responsabilità per coloro
che sono impegnati nello sviluppo FLOSS e violano inavvertitamente la proprietà intellettuale. Questo è essenziale, perché altrimenti i vari sviluppatori FLOSS
che lavorano in progetti co-finanziati dall’UE potrebbero essere soggetti a
cause legali e tali azioni dei tribunali diventerebbero una pubblicità molto
negativa per lo sviluppo FLOSS in generale. Ciò potrebbe anche comportate
delle spese per le amministrazioni pubbliche coinvolti nei progetti che sono da
evitare.
Dovrebbero essere concesse delle esenzioni di responsabilità oppure stabilito
un termine ragionevole per poter riscrivere il codice oggetto del contendere,
quando nel corso dello sviluppo FLOSS accada uno dei seguenti eventi:
(a) si viola inavvertitamente la patente (di proprietà)
(b) si viola inavvertitamente il copyright
(c) si viola inavvertitamente una licenza software proprietaria
Ciò ovviamente non si riferisce a quelle violazioni dove è presente il dolo. Se gli
sviluppatori FLOSS hanno volontariamente infranto le leggi sulla proprietà del
software, essi sarebbero soggetti alle pene previste da quelle stesse leggi.
3. La questione delle garanzie è da chiarificare e si dovrebbe decidere se debbano
essere fornite delle garanzie per i FLOSS e se si debba o meno pagare per esse.
4. Ci dovrebbe essere chiarezza sui requisiti (locus standi) per fare causa in caso di
violazioni della direttiva. E’ da considerare se il “locus standi” viene limitato a
programmatori e sviluppatori, o se possono anche fare causa gli utenti in qualsiasi caso.
5. La forma di arbitraggio delle violazioni FLOSS dovrebbe essere ben pensata.
Sarebbe nello spirito delle GNU-GPL e della sua direttiva codificata avere una
sorta di tribunale di arbitraggio per questo specifico scopo: ad esempio, una
specie di Cyber-Tribunale . Ciò ridurrebbe i costi, di qualsiasi pubblicità negativa legata alle infrazioni FLOSS e velocizzerebbe la loro risoluzione. Da sottolineare il fatto che la GNU-GPL non è mai stata oggetto di causa – in realtà ogni
violazione è stata risolta amichevolmente fuori dalla Corte. Un organo FLOSS
di questo tipo renderebbe lo sviluppo FLOSS un processo molto più naturale
all’interno dell’UE, libero da conflitti legali, o almeno dotato di un potente e
rapido meccanismo per risolverli.
54
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
6. C’è sempre un motivo per favorire la competitività dell’UE in ambito internazionale. A causa della sua affidabilità, sicurezza, convenienza nei costi e adattabilità, FLOSS è uno strumento che favorisce di molto questo aspetto e l’UE verrebbe identificata come un potente motore dello sviluppo FLOSS, unico nel
mercato internazionale. Ciò sarebbe per l’Unione Europea un punto di partenza nella reale possibilità di trarre profitti da FLOSS come servizio industriale.
Altri aspetti potrebbero essere necessari a tale fine come descritto di seguito.
7. L’introduzione di Linux in Extremadura, Spagna ha incrementato notevolmente
l’accesso a FLOSS in un periodo di tempo molto breve . La Giunta Regionale ha
anche risparmiato molti soldi usando FLOSS. L’educazione digitale, al centro
della politica attuata in Extremadura, contribuisce anche a irrobustire gli obiettivi egalitari nelle leggi in ambito diritti umani, in particolare il diritto all’educazione, ma anche a quelli della vita e della libertà. FLOSS inoltre aiuterebbe ad
eliminare le discriminazioni di sesso nel posto di lavoro poiché l’educazione con
pari opportunità è ormai una conquista nei Paesi Europei.
8. La formazione per acquisire delle capacità di programmare il codice FLOSS
dovrebbe diventare la norma nell’educazione primaria e secondaria dei cittadini europei. Non ha molto senso che per insegnare come funziona un computer si ricorra ad un’interfaccia ed è limitativo insegnare a leggere utilizzando
soltanto delle fotografie; tutto ciò pone in evidenza l’ignoranza ancora presente in questo campo.
9. Se dovesse passare questa direttiva, l’utilizzo del codice FLOSS, sviluppato
nell’Unione Europea, in Paesi terzi, potrebbe essere vincolata all’adozione in
questi Paesi, di leggi FLOSS simili (come negli anni ’80, quando numerosi paesi
sono stati persuasi dagli Stati Uniti a proteggere il nuovo software proprietario
nelle loro leggi di copyright). Certamente ciò comporterà alcuni problemi di
implementazione. E’ da notare, tuttavia, che statisticamente avvengono molte
più violazioni di licenze di software proprietario di quante colpiscano invece
licenze FLOSS. Ciò è largamente dovuto alla praticità di queste ultime ed alla
loro adattabilità alle abitudini e alle convenzioni dei programmatori FLOSS (la
GNU-GPL stessa è stata inventata da un programmatore, Richard Stallman)
Le guide di Ancitel
55
APPENDICE 1
ESEMPIO DI UN FREE SOFTWARE ACT
(PROPEDEUTICO AD UNA DIRETTIVA EUROPEA)
(commenti a [email protected] o [email protected])
56
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Version 3
Recitals:
(I) “Free software” for the purposes of this Act is not a technical definition. Instead,
it is software licensed so as to assure users, copiers, modifiers, distributors and
any other beneficiaries of free software of certain freedoms.
(II) Any user, copier, modifier, distributor or beneficiary of free software has standing to sue for any violation of this Act.
(III) This Act applies to all non-proprietary software described under the following
headings: free software, open source software, libre software, foss and floss
and also to any software licensed under Free Software Foundation or Open
Source Initiative licences.
(IV) This Act affords legislative protection to the terms and conditions of any licence enumerated in paragraph (iii). It does not abrogate the conditions of any
licence. This paragraph will supersede any other recital or section of this Act.
(V) Where non-proprietary software has not been released under a licence or its
developers’ copyright is not recognised in court, the relevant terms and conditions of this Act shall apply.
Sections:
1. Free software guarantees the following freedoms to its authors, users, copiers,
modifiers, distributors and any other beneficiaries, subject to any contradictory
requirements of any licences used to cover the program:
(a) The right to access the source code of any free software program for any
reason.
(b) The right to run the program for any reason.
(c) The right to copy the program for any reason.
(d) The right to modify the program for any reason.
(e) The right to distribute the program for any reason.
Open Source in Public Administration
52
2. Authors’ rights shall be protected in the following way, subject to any contra dictory
requirements of any licences used to cover the program:
(a) The author of any free software program retains the right of attribution
to his/her work.
(b) Any modifier must acknowledge the authorship of the original and any
subsequent versions of the program, along with the authorship of the
modification.
(c) Authorship must always be correctly attributed.
3. All users, copiers, modifiers, distributors and any beneficiaries of free software
have the right to know about and be informed about the rights listed in section
Le guide di Ancitel
57
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
1 and section 2 of this Act.
4. Distributors of free software, whether in its original, copied or modified form,
when distributing the program, may not restrict any of the rights in sections 1,
2 and 3.
5. Copies of the program may be distributed in exchange for money, providing that
the rights in sections 1, 2 and 3 are preserved.
6. Exemptions from liability:
(a) When any free software programmer or user, while engaged in free software development, inadvertently violates a proprietary software licence, or
any national or international law relating to “intellectual property” coverage of proprietary software, s/he will be exempt from the payment of damages and will be granted a reasonable time in which to rewrite any infringing
code.
(b) The onus to identify any infringing code enumerated in 6(a) will fall on the
plaintiff.
(c) There shall be no warranties for free software, unless such a warranty has
been requested by the purchaser, agreed to by the vendor and paid for
appropriately.
7. Where a program has been developed in more than one jurisdiction, each with
different copyright requirements, the provisions of this Act will apply.
8. Sanctions:
Any violation of this Act will result in an obligation on the part of those responsible to give access to the source code of any modified program based on free
software. Further sanctions may be imposed by the courts.
Definitions:
The Program: The “program” in this Act means the program, copies of the program, modified versions of the program and copies of modified versions of the
program and source code of the same.
Open Source in Public Administration
53
Use; Run; Copy; Modify; Distribute; User; Copier; Modifier; Distributor;
Beneficiary of free software; Free software programmer.
Maureen O’Sullivan, B.A., DipL., B.C.L.(Cork), LL.M.(Warwick), Lecturer in Law,
UWE, UK, President Free Software Consortium Foundation, Co-ordinator Legal
Governing Body and Cyber Tribunal, FSC © 2004. This chapter may be reproduced
verbatim in any medium, providing that this attribution is preserved.
58
Le guide di Ancitel
APPENDICE 2
LE LICENZE NEL DETTAGLIO
01 - Licenza Opensource
Natura ed obiettivi delle licenze liberali
02 - Licenza Opensource
Elenco comparativo di alcune licenze liberali
03 - Licenza Creative Commons
Le sei versioni in italiano
04 - La licenza del progetto GNU
General Public License (GPL )
05 - European Union Public License
Verso una “public license” targata EU
06 - CeCILL
La licenza per il software libero della ricerca francese
Le guide di Ancitel
59
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
01 - LICENZA OPENSOURCE
NATURA ED OBIETTIVI DELLE LICENZE LIBERALI
Da Wikipedia, l’enciclopedia libera1
Una licenza open source è una licenza liberale concessa dal detentore di un
diritto d’autore utilizzata prevalentemente nell’ambito dell’informatica riguardante solitamente il software, ma che può riguardare qualsiasi altro ambito nel
quale si applica la normativa sul diritto d’autore.
La sua particolarità è dovuta al fatto che gli autori invece di vietare, permettono. Non solo di usare e copiare, ma anche di modificare, ampliare, elaborare, vendere e quant’altro. E tutto questo senza imporre obblighi a ricompensare economicamente gli autori.
L’esempio più lampante (e noto al largo pubblico) sono le decine di distribuzioni GNU/Linux: un sistema operativo completo di migliaia di applicativi anche di
elevatissimo valore, spesso allegate a riviste ad un costo di 5 Euro.
Un termine poco usato è quello di licenza liberale o licenza permissiva in
contrapposizione a licenza restrittiva.
La FDL, la licenza usata da questo progetto (e dal progetto principale
Wikipedia) è un esempio di licenza open source o liberale se si preferisce quest’ultimo termine (che però ha propriamente un significato meno ampio).
NATURA ED OBIETTIVI DELLE LICENZE LIBERALI
Una licenza liberale autorizza chiunque ad usare, modificare, integrare,
riprodurre, duplicare e distribuire un programma (o qualsiasi lavoro tutelato
dalle norme sul diritto d’autore), anche a scopi commerciali in quanto la commercializzazione del programma non è vietata in modo esplicito. Il programma stesso
deve essere disponibile anche in una forma leggibile e comprensibile all’uomo.
Alcune licenze - come per esempio la GNU GPL - impongono dei vincoli alle licenze da applicare ad eventuali modifiche, oppure degli obblighi di comunicazione a
determinate persone o gruppi di persone. Ci sono licenze i cui autori si riservano dei
diritti che non vengono concessi agli altri coautori del prodotto, come ad esempio la
NPL. Altre invece permettono persino di integrare completamente il codice dentro un
prodotto commerciale, ovvero soggetto a royalty, come ad esempio la licenza X11.
Lo scopo primario delle licenze liberali non è la gratuità del software, ma la
sua sopravvivenza ovvero la certezza che vi sia la possibilità per chiunque e in
qualunque momento, anche futuro, di apportare miglioramenti o comunque
modifiche al programma, e di installarlo senza alcuna limitazione.
Per alcuni esponenti della comunità del Software Libero, come Stallman, lo
scopo primario è la libertà del software in sé, in quanto più importante rispetto
agli aspetti tecnologici.
1) http://it.wikipedia.org/wiki/licenzaopensource
60
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
LA DEFINIZIONE DI OPEN SOURCE
Il termine “open source” venne coniato agli inizi del 1998 su iniziativa di Bruce
Perens, Eric S. Raymond, Hall, Tim O’Reilly, Linus Torvalds e altri importanti
sviluppatori della comunità Free Software, come allora veniva chiamata.
L’obiettivo principale era quello di rendere l’idea del software libero più accettabile all’ambiente commerciale, evitando le posizioni intransigenti di Stallman e contemporaneamente evitare l’equivoco generato dalla parola “free” in inglese (che
significa sia gratuito che libero). La parola “source” stava a sottolineare il fatto che
un software non è tanto il programma eseguibile, quanto il suo punto di partenza, il sorgente appunto. La definizione di cosa può essere considerato “open source” deriva dalle regole che si era dato il progetto Debian nella scelta di quali software includere nella propria distribuzione GNU/Linux. Nacque in seguito una fondazione che tuttora gestisce il marchio creato ad hoc.
Secondo tale definizione è evidente che non si tratta soltanto di avere accesso
al codice sorgente, infatti affinché si possa parlare di una licenza open source è
necessario che tale licenza soddisfi contemporaneamente tutte le condizioni sottoindicate, il cui obiettivo è molteplice: permette a chiunque di mettere mano al
codice sorgente e contemporaneamente permette a chiunque di ridistribuirlo, il
tutto senza che alcuno possa pretendere anche il minimo compenso, però senza
impedire di chiedere un compenso a chi è disposto a pagarlo.
●
●
Ridistribuzione libera. La licenza non può impedire ad alcuna parte in causa
la vendita o la cessione del software. Chiunque deve poter fare tutte le copie
che vuole, venderle o cederle, e non deve pagare nessuno per poter fare ciò.
Codice sorgente. Il programma deve includere il codice sorgente. Codice deliberatamente offuscato non è ammesso. Questo in quanto il codice sorgente è
necessario per modificare o riparare un programma.
●
Opere derivate. La licenza deve permettere modifiche e opere derivate e deve
consentire la loro distribuzione sotto i medesimi termini della licenza del software originale, in quanto il software serve a poco se non si può modificare per fare
la manutenzione ad esempio per la correzione di errori o il porting su altri sistemi operativi.
●
Integrità del codice sorgente dell’autore. La licenza può proibire che il codice sorgente venga distribuito in forma modificata solo se la licenza permette la
distribuzione di “patch file” con il codice sorgente allo scopo di modificare il
programma al momento della costruzione.
●
Nessuna discriminazione contro persone o gruppi. La licenza deve essere
applicabile per tutti, senza alcuna discriminazione per quanto nobile possa essere l’obiettivo della discriminazione. Ad esempio non si può negare la licenza
d’uso neanche a forze di polizia di regimi dittatoriali.
●
Nessuna discriminazione di settori. Analogamente alla condizione precedente, questa impedisce che si possa negare la licenza d’uso in determinati settori,
per quanto questi possano essere deplorevoli. Non si può dunque impedire l’uso
Le guide di Ancitel
61
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
di tale software per produrre armi chimiche o altri strumenti di distruzione di
massa.
●
Distribuzione della licenza. I diritti relativi al programma devono applicarsi a
tutti coloro ai quali il programma sia ridistribuito, senza necessità di esecuzione
di una licenza aggiuntiva.
●
La licenza non dev’essere specifica a un prodotto. I diritti relativi a un programma non devono dipendere dall’essere il programma parte di una particolare distribuzione di software.
●
La licenza non deve contaminare altro software. La licenza non deve porre
restrizioni ad altro software che sia distribuito insieme a quello licenziato.
LE LICENZE
Mentre non tutte le licenze dichiarate liberali rispettano completamente le condizioni poste dalla Open Source Definition, ve ne sono alcune che sono riconosciute esplicitamente come tali dalla Open Source Initiative (OSI), titolare del marchio. A tal proposito la Free Software Foundation (FSF) ha a sua volta una lista di licenze ritenute
più o meno libere e più o meno compatibili con la licenza GPL da loro promossa.
In generale le licenze liberali non sono a priori reciprocamente compatibili. Il titolare dei diritti d’autore può comunque distribuire il proprio codice con diverse licenze,
sia liberali che commerciali. Questo vale sia per l’iniziatore del progetto che per gli
autori che contribuiscono al progetto, ciascuno per il proprio codice. Questa possibilità, detta pure dual-licensing o dual-system viene effettivamente praticata, p.es. dalla
Sun per la propria Suite Star Office, ma anche da Larry Wall per l’interprete Perl.
Nel novembre del 2001, Netscape ha deciso di rilasciare il codice del proprio browser anche sotto la licenza GPL - cosicché il progetto Mozilla viene rilasciato con le
licenze NPL, MPL, GNU GPL e GNU LGPL - per venire incontro alla comunità degli
sviluppatori di progetti open source soggetti alla GPL. Il risultato attuale è che parti del
codice sorgente sono soggette a una o più di queste licenze; lo staff di Mozilla lavora per cercare di distribuire tutto il codice sotto la triplice licenza MPL/LGPL/GPL.
62
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
02 - LICENZA OPENSOURCE
ELENCO COMPARATIVO DI ALCUNE LICENZE LIBERALI
Tratto da Wikipedia, l’enciclopedia libera 2
LICENZA OPEN SOURCE 3 :
Elenco comparativo di alcune licenze liberali 4 (vedi anche open source5 )
Sia la Open Source Initiative 6 (OSI) che la Free Software Foundation 7
(FSF) hanno valutato con propri criteri le licenze utilizzate per la distribuzione di
software. Come si può vedere nella tabella seguente, non tutte le licenze approvate esplicitamente dalla OSI sono considerate free dalla FSF, la quale considera free
e persino compatibili con la GPL alcune licenze non approvate dalla OSI.
Quest’ultima differenza è dovuta verosimilmente al fatto che le licenze vengono approvate dalla OSI dietro richiesta di chi le ha scritte, mentre il giudizio sulle
licenze non scritte dalla FSF è stato dato da questa su propria iniziativa, per fare
chiarimento rispetto alla compatibilità con la propria licenza GPL e anche per ribadire il proprio concetto di “free”.
Nella colonna “Approvata OSI” viene indicato con “OS” se tale licenza può
essere considerata “open source 8” . Nella colonna “Giudizio della FSF” vengono
indicate con “GPL” le licenze ritenute dalla FSF compatibili con la licenza GNU
General Public License 9 scritta dalla FSF stessa. Con “free” vengono indicate le
licenze giudicate libere dalla FSF. Un esplicito giudizio di “not free” è stato contrassegnato con un “no”.
2) http://it.wikipedia.org/wiki/licenza_opensource/elenco_comparativo_di_alcune_licenze_liberali
3) http://it.wikipedia.org/wiki/licenza_open_source
4) http://it.wikipedia.org/wiki/licenza_liberale
5) http://it.wikipedia.org/wiki/open_source
6) http://it.wikipedia.org/w/index.php?title=open_source_initiative&action=edit
7) http://it.wikipedia.org/wiki/free_software_foundation
8) http://it.wikipedia.org/wiki/open_source
9) http://it.wikipedia.org/wiki/gnu_general_public_license
Le guide di Ancitel
63
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
ELENCO DELLE LICENZE APPROVATE DALLA OSI O GIUDICATE DALLA FSF
Fonte: http://www.opensource.org/licenses/index.html per le licenze approvate dalla OSI e
http://www.gnu.org/licenses/license-list.html per i commenti da parte la FSF riguardanti svariate licenze giudicate a torto o a ragione “libere”. (Elenco aggiornato a Marzo 2002)
Licenza
Approvata OSI
Giudizio FSF
Licenze approvate dalla OSI o giudicate free dalla FSF
GNU General Public License (GPL)
OS
GPL
GNU Lesser General Public License
OS
GPL
license of the iMatiz Standard Function Library
original BSD license
GPL
OS
modified BSD license
free
GPL
X11 license
GPL
Qt Public License
OS
free
Expat license (MIT License)
OS
GPL
Standard ML of New Jersey Copyright License
GPL
Cryptix General License
GPL
license of Zlib, libpng
OS
license of Guile
GPL
GPL
GNU Ada compile
GPL
PHP License, 2.02
free
license of Python 1.6a2 and earlier versions
OS
GPL
license of Python 2.0.1, 2.1.1, and newer versions
OS
GPL
license of Python 1.6b1 and later versions, through 2.0 and 2.1 OS
free
license of Perl
GPL
Original Artistic License
OS
no
Clarified Artistic License
GPL
Artistic License 2.0
GPL
LaTeX Project Public License
free
Arphic Public License
free
Apache License 1.0
OS
free
Apache License 1.1
OS
free
Zope Public License
free
license of xinetd
free
OpenLDAP License, 2.3
free
Intel Open Source License
OS
Ricoh Source Code Public License
OS
Nokia Open Source License
OS
free
IBM Public License, 1.0ac
OS
free
Apple Public Source License
OS
no
64
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Apple Public Source License v.2.0
free
Common Public License 0.5
OS
Eiffel Forum License
OS
Phorum License, 1.2
free
free
license of Netscape Javascript
GPL
Sun Industry Standard Source License 1.0
OS
free
Sun Public license
OS
free
Sun Community Source License
no
Sun Solaris Source Code (Foundation Release) License. 1.1
no
Netscape Public License
Mozilla Public License
free
OS
Netizen Open Source License, 1.0
W3C Software Notice and License
free
free
OS
Interbase Public License, 1.0
GPL
free
Berkeley Database License (Sleepycat Software Product License)
OS
Motosoto License
OS
Vovida Software License 1.0
OS
Jabber Open Source License 1.0
OS
FreeType license
GPL
free
free
Open Compatibility License
free
MITRE Collaborative Virtual Workspace License
OS
Nethack General Public License
OS
X.Net License
OS
Open Group Test Suite License
OS
Licenze commentate dalla FSF in quanto ritenute da alcuni “libere”
Plan 9 License
no
Open Public License
no
YaST License
no
Daniel Bernstein’s licenses
no
Aladdin Free Public License
no
Scilab license
no
Licenze riguardanti documentazione o raccolte dati
GNU Free Documentation License (FDL)
FDL
FreeBSD Documentation License
FDL
Apple’s Common Documentation License, 1.0
free
Open Publication License, 1.0
free
Open Content License, 1.0
no
Open Directory License (dmoz.org License)
no
Design Science License
GPL
Le guide di Ancitel
65
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
03 - LICENZE CREATIVE COMMONS
LE SEI VERSIONI IN ITALIANO
Da Wikipedia, l’enciclopedia libera 10 e dal sito Creative Commons Italia 11
Creative Commons, versione 2.0
Licenze Creative Commons è la denominazione di alcune licenze di diritto
d’autore (copyright), rilasciate a partire dal 16 dicembre 2002 dalla Creative
Commons, una corporation no profit statunitense fondata nel 2001.
In breve, le sei licenze Creative Commons (versione 2.0) si ottengono combinando tra loro i seguenti quattro attributi:
Attribuzione - Attribution - (by): Permette che altri copino, distribuiscano, mostrino ed eseguano copie dell’opera e dei lavori derivati da questa solo se sono mantenute le indicazioni di chi è l’autore dell’opera (i
credit). Questo attributo è sempre presente in tutte e sei le licenze.
Non commerciale - Noncommercial - (nc): Permette che altri copino,
distribuiscano, mostrino ed eseguano copie dell’opera e dei lavori derivati da questa solo per scopi di natura non commerciale.
Non opere derivate - No Derivative Works - (nd): Permette che altri
copino, distribuiscano, mostrino ed eseguano soltanto copie identiche
dell’opera, non sono ammessi lavori che derivano dall’opera o basati su
di essa.
Condividi allo stesso modo - Share Alike - (sa): Permette che altri
distribuiscano lavori derivati dall’opera, solo con una licenza identica a
quella concessa con l’opera originale. (Vedi anche copyleft).
“Creative Commons offre un insieme flessibile di protezioni e libertà per
autori e artisti. Basandoci sul diritto d’autore tradizionale - “tutti i diritti riservati”
- abbiamo creato un diritto d’autore su base volontaria fondato sul principio “alcuni diritti riservati”. Creative Commons è un’organizzazione non-profit. Tutti i nostri
strumenti sono utilizzabili gratuitamente.”
10) http://it.wikipedia.org/wiki/licenza_creative_commons
11) http://www.creativecommons.it
66
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
LE CREATIVE COMMONS PUBLIC LICENSES (CCPL) ITALIANE
Common Deeds 2.0 (ovvero i riassunti delle licenze)
Attribuzione 2.0
Attribuzione - Non opere derivate 2.0
Attribuzione - Non commerciale - Non opere derivate 2.0
Attribuzione - Non commerciale 2.0
Attribuzione - Non commerciale - Condividi allo stesso modo 2.0
Attribuzione - Condividi allo stesso modo 2.0
Legal Code Italiano 2.0 (ovvero, le licenze vere e proprie)
Attribuzione 2.0
Attribuzione - Non opere derivate 2.0
Attribuzione - Non commerciale - Non opere derivate 2.0
Attribuzione - Non commerciale 2.0
Attribuzione - Non commerciale - Condividi allo stesso modo 2.0
Attribuzione - Condividi allo stesso modo 2.0
04 - LA LICENZA DEL PROGETTO GNU
GENERAL PUBLIC LICENSE GPL
Da Wikipedia, l’enciclopedia libera 12
GNU (Da Wikipedia, l’enciclopedia libera 13)
GNU è un acronimo ricorsivo e significa GNU is Not Unix (ovvero “GNU non
è Unix”).
Il Progetto GNU, lanciato nel 1983 da Richard Stallman, si basa su una gestione particolare dei diritti d’autore sul software, secondo la definizione di software libero (contrapposta a software proprietario).
Scopo ultimo del Progetto GNU è la creazione di un sistema operativo completamente libero, chiamato Sistema GNU; per arrivare a questo risultato, all’interno del progetto vengono creati programmi per coprire ogni necessità informatica: compilatori, lettori multimediali, programmi di crittografia... Nel 2005 il
sistema non è ancora stato sviluppato completamente (il kernel HURD non è ancora pronto per poter essere utilizzato), ma grazie al lavoro di Linus Torvalds è possibile usare il Sistema GNU con il kernel Linux, ovvero il sistema GNU Linux.
Attualmente esistono delle alternative al kernel Linux, fra cui Darwin che è anche
alla base di Mac OS X, ma nessuna è diffusa come il kernel Linux.
12) http://it.wikipedia.org/wiki/gnu_general_public_license
13) http://it.wikipedia.org/wiki/gnu
Le guide di Ancitel
67
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Fulcro di tutta l’attività del Progetto GNU è la licenza chiamata GNU General
Public License (GNU GPL), che sancisce e protegge le libertà fondamentali che,
secondo Stallman, permettono l’uso e lo sviluppo collettivo e naturale del software. Un’altra licenza, la GNU Free Documentation License (GNU FDL), è stata
scritta per coprire la documentazione, ed è usata anche dal progetto Wikipedia.
Per poter gestire alcuni casi, ad esempio lo sviluppo di librerie, il Progetto GNU ha
creato anche la GNU Lesser General Public License (GNU LGPL), che permette di
integrare software libero all’interno di software proprietario, specialmente per
ragioni di compatibilità e portabilità.
GNU GENERAL PUBLIC LICENSE
La GNU General Public License è una licenza per software libero.
Il testo ufficiale della licenza è disponibile all’URL http://www.gnu.org/licenses/gpl.html,mentre all’URL http://www.softwarelibero.it/gnudoc/gpl.it.txt è disponibile la traduzione
non ufficiale in italiano.
Viene spesso indicata con l’acronimo GNU GPL o (quando non c’è il rischio di confondersi con un’altra “General Public License”) semplicemente GPL. Per evitare un
errore alquanto comune, si tenga presente che GPL non significa Gnu Public License.
La GNU GPL è stata scritta da Richard Stallman e Eben Moglen nel 1989, per
distribuire i programmi creati dal Progetto GNU. È basata su una licenza simile usata
per le prime versioni di GNU Emacs. Contrapponendosi alle licenze per software proprietario, la GNU GPL permette all’utente libertà di utilizzo, copia, modifica e distribuzione; a partire dalla sua creazione è diventata una delle licenze per software libero più usate.
TERMINI DELLA LICENZA
Quanto segue è un riassunto dei termini della licenza. L’unica descrizione legalmente precisa, in ogni caso, è quella del testo della licenza stessa.
Il testo della GNU GPL è disponibile per chiunque riceva una copia di un software coperto da questa licenza. I licenziatari (da qui in poi indicati come “utenti”)
che accettano le sue condizioni hanno la possibilità di modificare il software, di
copiarlo e ridistribuirlo con o senza modifiche, sia gratuitamente sia a pagamento.
Quest’ultimo punto distingue la GNU GPL dalle licenze che proibiscono la ridistribuzione commerciale.
Se l’utente distribuisce copie del software, deve rendere disponibile il codice
sorgente a ogni acquirente, incluse tutte le modifiche eventualmente effettuate
(questa caratteristica è detta copyleft). Nella pratica, i programmi sotto GNU GPL
vengono spesso distribuiti allegando il loro codice sorgente, anche se la licenza
non lo richiede. Ci sono casi in cui viene distribuito solo il codice sorgente, lasciando all’utente il compito di compilarlo.
L’utente è tenuto a rendere disponibile il codice sorgente solo alle persone che
hanno ricevuto da lui la copia del programma o, in alternativa, accompagnare il
software con una offerta scritta di rendere disponibile il sorgente su richiesta.
Questo significa, ad esempio, che è possibile creare versioni private di un softwa68
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
re sotto GNU GPL, a patto che tale versione non venga distribuita a qualcun altro.
Questo accade quando l’utente crea delle modifiche private al software ma non lo
distribuisce: in questo caso non è tenuto a rendere pubbliche le modifiche.
Dato che il software è protetto da copyright, l’utente non ha altro diritto di
modifica o ridistribuzione al di fuori dalle condizioni di copyleft. In ogni caso,
l’utente deve accettare i termini della GNU GPL solo se desidera esercitare diritti
normalmente non contemplati dalla legge sul copyright, come la ridistribuzione. Al
contrario, se qualcuno distribuisce un software (in particolare, versioni modificate)
senza rendere disponibile il codice sorgente o violando in altro modo la licenza,
può essere denunciato dall’autore originale secondo le stesse leggi sul copyright. È
un intelligente cavillo legale, ed è per questo che la GNU GPL è stata descritta
come un “copyright hack”. La licenza specifica anche che il diritto illimitato di ridistribuzione non è garantito, in quanto potrebbero essere trovate delle debolezze
legali (o “bug”) all’interno della definizione di copyleft.
DETENTORI DEL COPYRIGHT
La Free Software Foundation (FSF) detiene i diritti di copyright per il testo
della GNU GPL, ma non detiene i diritti del software rilasciato con questa licenza.
A meno che venga emessa una specifica nota di copyright da parte della FSF, l’autore del software detiene i diritti di copyright per il suo lavoro, ed è responsabile di
perseguire ogni violazione della licenza riguardante il suo software.
A differenza dei software con essa distribuiti, la GNU GPL non è liberamente
modificabile: copiarla e distribuirla è permesso, ma modificarla è vietato. La FSF
permette di creare nuove licenze basate sulla GNU GPL, a patto che tali licenze non
usino il suo preambolo senza permesso. Dato che, solitamente, la nuova licenza
non è compatibile con la GNU GPL, la FSF sconsiglia di creare versioni modificate.
LICENZE VARIE E COMMENTI RELATIVI
Tratto dal sito GNU
Sommario
14
●
Introduzione
●
Licenze per il software
- Licenze di software libero compatibili con la GPL
- Licenze di software libero, incompatibili con la GPL
- Licenze di software non libero
●
Licenze per la documentazione
14) http://www.gnu.org/licenses/license-list.it.html
Le guide di Ancitel
69
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
- Licenze di documentazione libera
Licenze per documentazione non libera
●
Licenze per materiale diverso da software e documentazione
INTRODUZIONE
Noi classifichiamo le licenze in base ad alcuni requisiti chiave:
●
Se si qualifica come licenza per software libero.
●
Se è una licenza con permesso d’autore.
●
Se è compatibile con la licenza GNU GPL. (Questo significa che è possibile combinare un modulo rilasciato sotto quella licenza con un modulo rilasciato sotto
GPL per creare un programma più grande.)
●
Se può causare un qualunque problema di tipo pratico.
Se avete bisogno di aiuto per scegliere una licenza, valutarla oppure avete una qualsiasi altra domanda relativa alla licenze, scriveteci all’indirizzo <[email protected]>.
Se ritenete di aver trovato una violazione di una delle nostra licenze di permesso d’autore, per favore fate riferimento alla nostra pagina sulla violazione delle
licenze.
LICENZE PER IL SOFTWARE
●
Licenze di software libero compatibili con la GPL
●
Licenze di software libero incompatibili con la GPL
●
Licenze di software non libero
Le seguenti licenze si qualificano come licenze per software libero e sono compatibili con la licenza GNU GPL:
Licenze di software libero compatibili con la GPL
●
La GNU General Public License o GNU GPL come abbreviazione.
Questa è una licenza per software libero e una licenza con permesso d’autore.
Ne raccomandiamo l’uso per la maggior parte dei pacchetti software.
●
La GNU Lesser General Public License o GNU LGPL come abbreviazione.
Questa è una licenza per software libero, ma non è una licenza con forte permesso d’autore, poiché ne permette il collegamento con moduli non liberi. È
compatibile con la licenza GNU GPL. Ne raccomandiamo l’uso soltanto in circostanze molto particolari.
Tra la versione 2 e la 2.1 la GNU LGPL è stata rinominata da GNU Library General
Public License a GNU Lesser General Public License per meglio rispecchiare i suoi
scopi reali. Non si tratta quindi di una licenza per sole librerie, e l’uso della GNU
GPL è talvolta più appropriato per le librerie.
●
La licenza di Guile.
70
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Questa licenza consiste nella GNU GPL più una clausola speciale che ne permette il collegamento con software non libero. Il risultato è quindi una licenza con
debole permesso d’autore ed è compatibile con la GNU GPL. Ne raccomandiamo l’uso solo per circostanze speciali, più o meno le stesse che suggeriamo per
l’uso della LGPL.
●
La licenza delle unità run-time del compilatore GNU Ada.
Questa licenza è molto simile a quella di Guile.
●
La licenza X11.
Questa è una semplice licenza per software libero permissiva, senza permesso
d’autore, compatibile con la GNU GPL. XFree86 utilizza la stessa licenza.
●
La licenza di Expat.
Questa è una semplice licenza per software libero permissiva, senza permesso
d’autore, compatibile con la GNU GPL. Spesso viene ambiguamente chiamata
con il nome di Licenza MIT.
●
Licenza di copyright Standard ML of New Jersey.
Questa è una semplice licenza per software libero permissiva, senza permesso
d’autore, compatibile con la GNU GPL.
●
Public Domain.
Essere di dominio pubblico non è una licenza: piuttosto, significa che il materiale non è protetto da copyright e non è necessaria nessuna licenza. In pratica
quindi se un’opera è di dominio pubblico, potrebbe anche avere una licenza
come software libero del tutto permissiva senza permesso d’autore. Lo stato di
dominio pubblico è compatibile con la GNU GPL.
●
La licenza generica Cryptix.
Questa è una semplice licenza per software libero permissiva, senza permesso
d’autore, compatibile con la GNU GPL. È molto simile alla licenza X11.
●
La licenza BSD modificata.
(Nota: in questo link, la licenza BSD modificata è elencata nella sezione
“General”.)
Questa è la licenza BSD originale, modificata rimuovendo la clausola pubblicitaria. È una licenza per software libero semplice, permissiva, senza permesso d’autore, compatibile con la GNU GPL.
Se desiderate una licenza per software libero semplice, permissiva e senza permesso d’autore, allora la licenza BSD modificata è una buona scelta. Ad ogni
modo, è rischioso raccomandare l’uso della “licenza BSD”, per una possibile
confusione che può portare all’uso della licenza BSD originale. Per evitare questo rischio suggerite la licenza X11. La licenza X11 e la BSD modificata sono piú
o meno equivalenti.
Le guide di Ancitel
71
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
●
La licenza di ZLib.
Questa è una licenza per software libero ed è compatibile con la licenza GPL.
●
La licenza della iMatix Standard Function Library.
Questa è una licenza per software libero ed è compatibile con la licenza GPL.
●
La licenza e le note per il Software del W3C.
Questa è una licenza per software libero ed è compatibile con la licenza GPL.
●
La licenza del Berkeley Database (nota anche come la licenza Sleepycat
Software Product). Questa è una licenza per software libero ed è compatibile
con la GNU GPL.
●
La licenza di Python 1.6a2 e versioni precedenti.
Questa è una licenza per software libero ed è compatibile con la GNU GPL. Si
noti che le versioni più recenti di Python sono rilasciate sotto altre licenze (si
veda sotto).
●
La licenza di Python 2.0.1, 2.1.1 e versioni successive.
Questa è una licenza per software libero ed è compatibile con la GNU GPL. Si
noti che le versioni intermedie di Python (dalla 1.6b1 alle 2.0 e 2.1) sono rilasciate sotto una diversa licenza (si veda sotto).
●
La licenza di Perl.
Questa licenza è l’unione disgiunta della Licenza Artistica e della GNU GPL; in
altre parole, è possibile scegliere tra una delle due licenze. Si qualifica come
licenza per software libero, ma può non essere un effettivo permesso d’autore.
È compatibile con la GNU GPL poichè la GNU GPL è una delle possibili alternative. Vi raccomandiamo di utilizzare questa licenza per qualunque pacchetto Perl
4 o Perl 5 che desiderate scrivete, per promuovere la coerenza e l’uniformità
nella programmazione in Perl. Al di fuori di questo, vi chiediamo di non utilizzare questa licenza; è meglio utilizzare solo la GNU GPL.
●
La Licenza Artistica chiarificata.
Questa licenza è per software libero, compatibile con la GPL. Contiene l’insieme dei minimi cambiamenti necessari per correggere l’indeterminatezza della
Licenza Artistic Originale.
●
La licenza Artistic, 2.0.
Questa è una licenza per software libero, compatibile con la GPL. Per quanto ne
sappiamo non è ancora in uso; questa licenza verrà presa in considerazione per
Perl 6 come parte di un sistema di licenza disgiunta.
Se state pensando di rilasciare un programma sotto la Licenza Artistica originale, per favore scrivete a <[email protected]> per chiedere una copia revisionata
di questa versione. Ad ogni modo, vi consigliamo di consultare prima l’elenco
delle altre licenze per software libero compatibili con la GPL.
●
La licenza pubblica Zope versione 2.0.
Questa è una licenza per software libero semplice, senza permesso d’autore,
compatibile con la licenza GPL.
72
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
●
La licenza Intel Open Source (come pubblicata da OSI)
Questa è una licenza per software libero, compatibile con la GNU GPL.
●
La licenza di Netscape Javascript.
Questa è una unione disgiunta della Licenza Pubblica Netscape e della GNU GPL.
Per questo motivo è una licenza per software libero, compatibile con la GNU
GPL, ma senza un forte permesso d’autore.
Questa licenza disgiunta è una buona scelte se desiderate rendere il vostro pacchetto compatibile con la GPL ed anche con la MPL. In ogni caso questo si può
raggiungere questo scopo anche utilizzando la licenza LGPL o la licenza di Guile.
Questa licenza disgiunta può essere una buona scelta se avete utilizzato la MPL
e desiderate passare a una licenza compatibile con la GPL senza togliere nessun
permesso attribuito per le versioni precedenti.
Licenze di software libero incompatibili con la GPL
Le seguenti licenze sono licenze per software libero, ma non sono compatibili con la GNU GPL:
●
La licenza pubblica Arphic.
Questa è una licenza per software libero con permesso d’autore, incompatibile
con la GPL. L’uso comune è per i font, e per questo l’incompatibilità non causa
problemi.
●
La licenza BSD originale.
(Nota: in questo link la licenza originale BSD viene elencata nella sezione
“UCB/LBL”.) Questa è una semplice licenza per software libero, senza permesso d’autore con un problema serio: la “noiosa clausola pubblicitaria BSD”. Il problema non è determinante: non rende il software non libero. Ma causa molti
problemi pratici, inclusa l’incompatibilità con la GNU GPL.
Vi chiediamo di non utilizzare la licenza BSD originale per il vostro software. Se
desiderate una licenza per software libero semplice, permissivo, senza permesso d’autore, vi consigliamo l’uso della licenza BSD modificata oppure della licenza X11. In ogni caso, non sussiste una valida per ragione per non utilizzare programmi rilasciati sotto la licenza BSD originale.
●
La licenza Apache, versione 1.0.
Questa è una licenza per software libero semplice, permissiva, senza permesso
d’autore, con problemi pratici come quelli della licenza BSD originale, inclusa
l’incompatibilità con la GNU GPL.
●
La licenza Apache, versione 1.1.
Questa è una licenza per software libero permissiva, senza permesso d’autore
con alcuni requisiti che la rendono incompatibile con la GNU GPL.
Vi raccomandiamo di non utilizzare le licenze Apache per il software che scrivete. In ogni caso non esiste una ragione per evitare di utilizzare programmi rilasciati sotto questa licenza, come ad esempio il server web Apache.
●
La licenza pubblica Zope versione 1.
Le guide di Ancitel
73
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Questa è una licenza per software libero semplice, leggermente permissiva e
senza permesso d’autore con problemi pratici come quelli riscontrati nella licenza originale BSD, inclusa l’incompatibilità con la GNU GPL. Vi invitiamo a non utilizzare la ZPL versione 1 per il vostro software. Ad ogni modo, non esiste una valida ragione per non utilizzare programmi rilasciati sotto questa licenza, come le
precedenti versioni di Zope.
L’ultima versione di Zope è disponibile sotto una licenza compatibile con la GPL.
●
La licenza di xinetd
Questa è una licenza per software libero con permesso d’autore, incompatibile
con la GPL. Lo è poiché aggiunge ulteriori restrizioni sulla ridistribuzione di versioni modificate che vanno contro i requisiti di distribuzione della GPL.
●
La licenza di Python 1.6b1 e versioni successive, fino alla 2.0 e 2.1.
Questa è una licenza per software libero ma è incompatibile con la GNU GPL. Il
problema principale è che questa licenza di Python è regolata alle leggi dello
Stato della Virginia, negli Stati Uniti, e la GPL non lo permette.
●
La licenza di OpenLDAP, versione 2.3.
Questa è una licenza per software libero permissiva, senza permesso d’autore
che include alcune richieste (nelle sezioni 4 e 5) che la rendono incompatibile
con la GNU GPL.
Vi invitiamo a non utilizzare la licenza OpenLDAP per il vostro software. Ad ogni
modo, non sussiste una valida ragione per evitare di utilizzare programmi rilasciati sotto questa licenza, come per esempio OpenLDAP.
●
La licenza di Vim
Questa è una licenza per software libero, con un permesso d’autore parziale e
incompatibile con la GPL. È incompatibile con la GPL a causa dei requisiti necessari per inviare una copia al manutentore originario nel caso ne chieda una,
requisito questo non richiesto dalla GPL.
●
Licenza pubblica IBM, versione 1.0
Questa è una licenza per software libero ma è incompatibile con la GPL.
La licenza pubblica IBM è incompatibile con la GPL poiché ha diversi requisiti
specifici che non si trovano nella GPL. Ad esempio, richiede che vengano date
certe licenze per brevetti che la GPL non richiede. (Noi non riteniamo che questi requisiti delle licenze per brevetti siano di per sé una cattiva idea, tuttavia
sono incompatibili con la GNU GPL.)
●
Licenza pubblica comune versione 0.5
Questa è una licenza per software libero ma è incompatibile con la GPL.
La Licenza Pubblica Comune è incompatibile con la GPL poiché ha diversi requisiti specifici che non si trovano nella GPL. Ad esempio, questa richiede che vengano concesse alcune licenze per brevetti che la GPL non richiede. (Non riteniamo che questi requisiti delle licenze per brevetti siano di per sé una cattiva idea,
sono tuttavia incompatibili con la GNU GPL.)
La licenza Phorum, versione 1.2
●
74
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Questa è una licenza per software libero ma è incompatibile con la GPL. Ad
esempio, i termini delle sezioni 3 e 4 rendono la licenza incompatibile con la
GPL. La licenza pubblica del Progetto LaTeX. Questa licenza è una parte dei termini di distribuzione per LaTeX. Per il suo stato attuale è una licenza per software libero, ma incompatibile con la GPL poiché ha molti requisiti che non si trovano nella GPL. Questa licenza contiene restrizioni complesse e noiose su come
pubblicare una versione modificata, inclusa una richiesta che rientra appena in
ciò che si può accettare: che qualunque file modificato deve avere un nuovo
nome. Il motivo di questa richiesta è accettabile per LaTeX poiché LaTeX ha la
caratteristica di poter tracciare i nomi dei file, per specificare opzioni tipo “utilizza il file pluto quando viene richiesto il file paperino”. Con questa caratteristica, la richiesta è decisamente noiosa. Senza, la stessa richiesta diventerebbe un
ostacolo molto serio, e quindi siamo arrivati alla conclusione che questa licenza
rende il programma non libero. La LPPL dice che alcuni file, in determinate versioni di LaTeX, possono avere ulteriori restrizioni, che potrebbero renderli non
liberi. Per questa ragione, bisogna stare molto attenti nel produrre una versione
libera di LaTeX. La LPPL fa l’affermazione controversa che semplicemente il fatto
di avere dei file in una macchina sulla quale altre persone possono fare login e
accedervi viene considerata una forma di distribuzione. Crediamo che i tribunali non sosterranno questa rivendicazione, ma è un brutto segno che si inizi a
farla. Per favore non utilizzate questa licenza per nessun altro progetto.
Nota: Questi commenti sono basati sulla versione 1.2 (3 Set 1999) della LPPL.
●
La Licenza Pubblica Mozilla (MPL).
Questa è una licenza per software libero che non ha un forte permesso d’autore; diversamente dalla licenza X11, ha alcune restrizioni complesse che la rendono incompatibile con la GNU GPL. Per questo, un modulo rilasciato sotto licenza GPL ed uno rilasciatosotto MPL non possono essere legalmente uniti assieme.
Vi invitiamo a non utilizzare la MPL per questo motivo.
Ad ogni modo, la MPL versione 1.1 ha una clausola (sezione 13) che permette
ad un programma (o ad una sua parte) di offrire la possibilità di scegliere anche
un’altra licenza. Se parte di un programma permette la GNU GPL come scelta
alternativa, o qualunque altra licenza compatibile con la GPL, quella parte di
programma ha una licenza compatibile con la GPL.
●
La Licenza Open Source di Netizen (NOSL), versione 1.0.
Questa è una licenza per software libero che è essenzialmente uguale alla
Licenza Pubblica Mozilla versione 1.1. Come la MPL, la NOSL ha alcune restrizioni complesse che la rendono incompatibile con la GNU GPL. Cioè, un modulo rilasciato con licenza GPL e uno con licenza NOSL non possono essere legalmente uniti assieme. Vi invitiamo a non usare la NOSL per questo motivo.
●
La Licenza Pubblica Interbase, versione 1.0.
Questa è una licenza per software libero che è essenzialmente uguale alla
Licenza Pubblica Mozilla, versione 1.1. Come la MPL, la IPL ha alcune restrizioni
complesse che la rendono incompatibile con la GNU GPL. Quindi un modulo
Le guide di Ancitel
75
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
rilasciato con licenza GPL e uno con licenza IPL non possono essere legalmente
uniti assieme. Vi invitiamo a non usare la IPL per questo motivo.
●
La Licenza Pubblica Sun.
Questa licenza è essenzialmente uguale alla Licenza Pubblica Mozilla: una licenza per software libero imcompatibile con la GNU GPL. Non confondetela con la
Licenza Sun Community Source che non è una licenza per software libero. La
Licenza Nokia Open Source. Questa licenza è molto simile alla Licenza Pubblica
Mozilla: una licenza per software libero incompatibile con la GNU GPL.
●
La Licenza Pubblica Netscape (NPL)
Questa è una licenza per software libero, con un debole permesso d’autore,
incompatibile con la GNU GPL. Consiste nella Licenza Pubblica Mozilla con l’aggiunta di una clausola che permette a Netscape di utilizzare il codice che voi
aggiungete anche alle loro versioni proprietarie del programma. Ovviamente,
loro non permettono a voi di utilizzare il loro codice in modo analogo. Vi invitiamo a non utilizzate la NPL.
●
La Licenza Open Source di Jabber, versione 1.0
La licenza è per software libero, incompatibile con la GPL. Permette il re-licenziamento all’interno di una specifica classe di licenze, quelle che soddisfano tutti
i requisiti della licenza di Jabber. La GPL non fa parte di questa classe di licenze,
quindi la licenza di Jabber non permette il re-licenziamento sotto GPL. Perciò
non è compatibile.
●
La Licenza Sun Industry Standards Source 1.0
Questa è una licenza per software libero, con debole permesso d’autore, incompatibile con la GNU GPL a causa di piccoli dettagli piuttosto che per l’impostazione generale.
●
La Licenza Pubblica Q (QPL), versione 1.0.
Questa è una licenza per software libero senza permesso d’autore che è incompatibile con la GNU GPL. Crea inoltre rilevanti inconvenienti di tipo pratico, poiché i sorgenti modificati possono essere distribuiti solo sotto forma di patch.
Raccomandiamo di non utilizzare la QPL per il vostro software ed utilizzare pacchetti rilasciati sotto questa licenza solo se strettamente necessario. Ad ogni
modo, questo avvertimento non vale per Qt, dato che Qt adesso viene rilasciato anche sotto licenza GNU GPL.
Dato che la QPL è incompatibile con la GNU GPL, non è possibile prendere un
programma rilasciato sotto GPL e uno rilasciato sotto licenza QPL per unirli assieme, non importa come. Ad ogni modo, se avete scritto un programma che utilizza una libreria rilasciata sotto licenza QPL (chiamata, per esempio, RUBI) e
volete rilasciare il vostro programma con la licenza GNU GPL, potete facilmente
farlo. È possibile risolvere il conflitto per il vostro programma aggiungendo una
nota come questa:
Come eccezione, avete il permesso di unire questo programma alla libreria RUBI
e di distribuire eseguibili se rispettate i termini delle licenza GNU GPL per quanto riguarda tutto il software nell’eseguibile eccetto a parte RUBI.
76
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
È possibile fare questo, legalmente, se siete i detentori del copyright del programma. Aggiungetelo nei file sorgente, dopo la nota che specifica che il programma è rilasciato sotto licenza GNU GPL.
●
La Licenza FreeType
La Licenza FreeType è una licenza per software libero senza permesso d’autore
che è incompatibile con la GPL per ragioni tecniche.
●
La Licenza Open Compatibility
Questa è una licenza per software libero con due grandi problemi: garantisce
speciali privilegi all’autore originale, ed è incompatibile con la GPL.
●
La Licenza PHP, versione 2.02.
Questa licenza è utilizzata da gran parte di PHP4, ma una parte importante di
PHP4, l’optimizer Zend, utilizza una licenza diversa e peggiore: la QPL.
Questa è una licenza per software libero senza permesso d’autore con problemi
pratici come quelli presenti nella licenza BSD originale, inclusa l’incompatibilità
con la GNU GPL. PHP3 non è rilasciato sotto questa licenza. PHP3 ha una licenza disgiunta con la GNU GPL. Quindi, anche se PHP4 (che è rilasciato unicamente sotto la licenza PHP 2.02) è ancora software libero, vi incoraggiamo ad utilizzare e a migliorare soltanto PHP3. In questo modo, possiamo avere una versione attiva di PHP la cui licenza è compatibile con la GPL. Se siete interessati ad
aiutare a mantenere una versione attiva di PHP3, contattate i Coordinatori dei
Volontari GNU <[email protected]>.
Licenze per software non libero
Le seguenti licenze non si qualificano come licenze per software libero. Una
licenza non libera è automaticamente incompatibile con la GNU GPL.
Ovviamente, vi invitiamo ad evitare l’uso di licenze per software non libero, ed
evitare il software non libero in generale. Non esiste modo per elencare tutte le
licenze di software non libero conosciute in questa pagina; in fondo, ogni azienda
di software proprietario ha la propria. Ci concentriamo qui sulle licenze che spesso vengono confuse con licenze per software libero ma sono, nei fatti, licenze per
software non libero.
Abbiamo fornito collegamenti a quei pacchetti quando potevamo farlo senza
violare la nostra regola generale. Non forniamo collegamenti a siti che promuovono, incoraggiano o facilitano l’uso di pacchetti software non liberi. L’ultima cosa
che vogliamo fare è quella di fornire a qualunque pacchetto non libero della pubblicità gratuita che possa incoraggiare le persone ad usarlo. Per la stessa ragione,
abbiamo evitato di menzionare i programmi che utilizzano queste licenze, a meno
che non pensiamo che per motivi particolari questo non sia controproducente.
●
La Licenza Artistic (l’originale).
Non possiamo dire che questa sia una licenza per software libero poiché è troppo vaga; alcuni passaggi sono fin troppo elaborati a loro vantaggio, e il loro
significato non è chiaro. Vi invitiamo a non utilizzarla, eccetto nel caso in cui sia
Le guide di Ancitel
77
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
parte della licenza disgiunta di Perl.
I problemi sono legati alle parole, non alla sostanza. Esiste una versione rivisitata della Licenza Artistic (chiamata “Licenza Artistic 2.0”) che è una licenza per
software libero e anche compatibile con la GNU GPL. Questa licenza viene presa
in considerazione per Perl 6. Se state pensando di rilasciare un programma sotto
la licenza Artistic, per favore contattate [email protected] per richiedere una
copia della versione modificata di questa licenza. Prima però consultate l’elenco
delle licenze compatibili con la GPL per software libero elencate in questa pagina per trovare una possibile alternativa valida.
●
La Licenza Apple Public Source (APSL).
Questa licenza non è per software libero. Vi invitiamo a non usare questa licenza e ad evitare l’uso di software rilasciato sotto di essa.
Maggiori argomentazioni sul perché la APSL non è una licenza per software libero.
●
La Licenza Sun Community Source.
Questa non è una licenza per software libero. Non fornisce le libertà essenziali
come la pubblicazione di versioni modificate. Non utilizzate questa licenza, e vi
invitiamo ad evitare tutto il software rilasciato sotto di essa.
●
La licenza di Plan 9
Questa non è una licenza per software libero. Non fornisce le libertà essenziali
come il diritto di effettuare ed utilizzare modifiche private. Non utilizzate questa
licenza, e vi invitiamo a non utilizzare alcun software rilasciato sotto di essa. È
disponibile anche una dettagliata discussione su questa licenza.
●
Licenza Open Public
Questa non è una licenza per software libero, poiché richiede l’invio di ciascuna
versione modificata pubblicata allo specifico sviluppatore iniziale. Sono presenti
inoltre in questa licenza alcuni paragrafi ambigui: non siamo sicuri che non possano creare problemi.
Esiste inoltre un altro sito per la Licenza Open Public. Non siamo sicuri quale sia
quella canonica. Queste due differiscono solo in piccoli dettagli che non cambiano il nostro giudizio su questa licenza.
●
La Licenza Sun Solaris Source Code (Foundation Release), versione 1.1
Questa non è una licenza per software libero. Questa licenza proibisce la redistribuzione, proibisce l’uso commerciale del software e può essere revocata.
●
La Licenza di YaST
Questa non è una licenza per software libero. La licenza proibisce la distribuzione a pagamento e rende impossibile includere il software in molti dei CD-ROM
contenenti software libero che vengono venduti da aziende e da organizzazioni
come la FSF.
Inoltre possono sussistere ulteriori problemi con la sezione 2a, ma sembra che
manchi una parola, quindi è difficile stabilire cosa la licenza voglia veramente dire.
●
Le Licenze di Daniel Bernstein
78
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Queste licenze non sono per software libero, poiché non permettono la pubblicazione di versioni modificate.
●
La “Aladdin Free Public License”
A differenza di quanto espresso nel nome, questa non è una licenza per software libero. È troppo restrittiva.
●
La licenza di Scilab
Questa non è una licenza per software libero poiché non permette la distribuzione commerciale di versioni modificate.
Licenze per la documentazione
●
●
Licenze per documentazione libera
Licenze per documentazione non libera
Le seguenti licenze si qualificano come licenze per documentazione libera:
●
La Licenza GNU Free Documentation
Questa licenza è stata progettata per documentazione libera con permesso
d’autore. Pensiamo di adottarla per tutti i manuali GNU.
●
La Licenza FreeBSD Documentation
Questa è una licenza permissiva senza permesso d’autore per documentazione
libera, compatibile con la GNU FDL.
●
La Licenza Apple’s Common Documentation, versione 1.0
Questa è una licenza per documentazione libera che è incompatibile con la GNU
FDL. È incompatibile poiché la sezione 2c dichiara “Non è possibile aggiungere
altri termini o condizioni a quelli presenti in questa licenza”, e la GNU FDL ha
termini aggiuntivi che non si trovano nella licenza Common Documentation.
●
Licenza Open Publication, versione 1.0
Questa licenza può essere utilizzata come licenza per documentazione libera. È
una licenza per documentazione libera con permesso d’autore a condizione che il
detentore del copyright non eserciti nessuna delle “OPZIONI DI LICENZA” elencate nella sezione VI della licenza stessa. Se una delle opzioni viene scelta, la licenza
diventa non libera.
Questo crea uno scompenso pratico nell’uso o nel raccomandare l’uso di questa
licenza: se invitate ad usare la Open Publication Licence, versione 1.0 senza scegliere nessuna delle opzioni, sarebbe facile dimenticare la seconda parte della raccomandazione. Qualcuno potrebbe utilizzare questa licenza e le sue opzioni e rendere un manuale non libero pur credendo di seguire lo stesso il vostro consiglio.
Allo stesso modo, se utilizzate questa licenza senza nessuna delle opzioni per
rendere il vostro manuale libero, qualcun’altro potrebbe imitarvi e cambiare poi
la sua idea riguardo alle opzioni pensando che si tratti solo di un dettaglio. Il
risultato è che renderebbe il suo manuale non libero.
Quindi, mentre i manuali pubblicati sotto questa licenza si qualificano come
documentazione libera se nessuna opzione viene utilizzata, è meglio utilizzare la
Le guide di Ancitel
79
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Licenza GNU Free Documentation per evitare i rischi di portare qualcun’altro
all’errore.
Notate per favore che questa licenza non è la stessa che la Licenza Open Content.
Queste due licenze vengono spesso confuse, dato che la Licenze Open Content
viene spesso chiamata con l’acronimo di “OPL”. Per chiarezza è meglio non utilizzare la forma abbreviata “OPL” per entrambe le licenze. È meglio scrivere il
nome completo per essere sicuri che si comprenda quello che state dicendo.
Le seguenti licenze non si qualificano come licenze per documentazione libera:
●
La Licenza Open Content, versione 1.0
Questa licenza non si qualifica come libera, poiché sussistono restrizioni sul pagamento in denaro delle copie. Vi raccomandiamo di non usare questa licenza.
Notate per favore che questa licenza non è la stessa che la Licenza Open
Publication. Queste due licenze vengono spesso confuse, dato che la Licenze
Open Content viene spesso chiamata con l’acronimo di “OPL”. Per chiarezza è
meglio non utilizzare la forma abbreviata “OPL” per entrambe le licenze. È
meglio scrivere il nome completo per essere sicuri che si comprenda quello che
state dicendo.
●
La Licenza Open Directory (nota anche come Licenza dmoz.org)
Questa non è una licenza per la documentazione libera. I problemi principali
sono che il vostro diritto di ridistribuzione per qualunque versione non è permanente e che si richiede all’utente di tornare periodicamente sul sito a controllare, pratica troppo restrittiva per la libertà dell’utente stesso.
Licenze per materiale diverso da software e documentazione
●
La Licenza Design Science
Questa è una licenza libera e con permesso d’autore creata per dati generici e
non per il software in particolare.
Notate, però, che la GNU GPL può essere utilizzata per dati generici che non
sono software, a condizione che sia possibile determinare a cosa si riferisce la
definizione di “codice sorgente” in quel particolare caso. Anche la DSL richiede
che si determini quale sia il “codice sorgente”, usando approssimativamente la
stessa definizione utilizzata nella licenza GPL.
80
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Per informazioni e domande sulla FSF e GNU rivolgersi, possibilmente in inglese, a
[email protected].
Altri modi per contattare la FSF.
Commenti su queste pagine web a [email protected], altre domande a
[email protected].
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation,
Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA
La copia letterale e la distribuzione di questo articolo nella sua integrità sono permesse con qualsiasi mezzo, a condizione che questa nota sia riprodotta.
Aggiornato: $Date: 2005/05/05 19:37:12 $ $Author: novalis $
La GNU General Public License è una licenza per software libero.
Il testo ufficiale della licenza è disponibile all’URL http://www.gnu.org/licenses/gpl.html,
mentre all’URL di seguito riportiamo la traduzione non ufficiale in italiano disponibile
su http://www.softwarelibero.it/gnudoc/gpl.it.txt
Questa è una traduzione italiana non ufficiale della Licenza Pubblica Generica
GNU. Non pubblicata dalla Free Software Foundation e non ha valore legale nell’esprimere i termini di distribuzione el software che usa la licenza GPL. Solo la
versione originale in inglese della licenza ha valore legale. Ad ogni modo, speriamo che questa traduzione aiuti le persone di lingua italiana a capire meglio il
significato della licenza GPL.
Le guide di Ancitel
81
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
LICENZA PUBBLICA GENERICA (GPL) DEL PROGETTO GNU
Versione 2, Giugno 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.59 Temple Place, Suite
330, Boston, MA 02111-1307 USA
Traduzione curata da gruppo Pluto, da ILS e dal gruppo italiano di traduzione
GNU. Ultimo aggiornamento 19 aprile 2000.
Chiunque può copiare e distribuire copie letterali di questo documento di licenza,
ma non ne è permessa la modifica.
Preambolo
Le licenze della maggior parte dei programmi hanno lo scopo di togliere
all’utente la libertà di condividere e modificare il programma stesso. Viceversa, la
Licenza Pubblica Generica GNU intesa a garantire la libertà di condividere e modificare il software libero, al fine di assicurare che i programmi siano liberi per tutti
i loro utenti. Questa Licenza si applica alla maggioranza dei programmi della Free
Software Foundation e ad ogni altro programma i cui autori hanno deciso di usare
questa Licenza. Alcuni altri programmi della Free Software Foundation sono invece coperti dalla Licenza Pubblica Generica Minore. Chiunque può usare questa
Licenza per i propri programmi.
Quando si parla di software libero (free software), ci si riferisce alla libertà non
al prezzo. Le nostre Licenze (la GPL e la LGPL) sono progettate per assicurarsi che
ciascuno abbia la libertà di distribuire copie del software libero (e farsi pagare per
questo, se vuole), che ciascuno riceva il codice sorgente o che lo possa ottenere se
lo desidera, che ciascuno possa modificare il programma o usarne delle parti in
nuovi programmi liberi e che ciascuno sappia di potere fare queste cose.
Per proteggere i diritti dell’utente, abbiamo bisogno di creare delle restrizioni
che vietino a chiunque di negare questi diritti o di chiedere di rinunciarvi. Queste
restrizioni si traducono in certe responsabilità per chi distribuisce copie del software e per chi lo modifica.
Per esempio, chi distribuisce copie di un programma coperto da GPL, sia gratis sia in cambio di un compenso, deve concedere ai destinatari tutti i diritti che ha
ricevuto. Deve anche assicurarsi che i destinatari ricevano o possano ottenere il
codice sorgente. E deve mostrar loro queste condizioni di licenza, in modo che essi
conoscano i propri diritti.
Proteggiamo i diritti dell’utente in due modi: (1) proteggendo il software con
un copyright, e (2) offrendo una licenza che dia il permesso legale di copiare,
distribuire e modificare il Programma.
Inoltre, per proteggere ogni autore e noi stessi, vogliamo assicurarci che ognu-
82
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
no capisca che non ci sono garanzie per i programmi coperti da GPL. Se il programma viene modificato da qualcun altro e ridistribuito, vogliamo che gli acquirenti
sappiano che non hanno l’originale, in modo che ogni problema introdotto da altri
non si rifletta sulla reputazione degli autori originari.
Infine, ogni programma libero costantemente minacciato dai brevetti sui programmi. Vogliamo evitare il pericolo che chi ridistribuisce un programma libero
ottenga la proprietà dei brevetti, rendendo in pratica il programma cosa di sua proprietà. Per prevenire questa evenienza, abbiamo chiarito che ogni brevetto debba
essere concesso in licenza d’uso a chiunque, o non avere alcuna restrizione di licenza d’uso.
Seguono i termini e le condizioni precisi per la copia, la distribuzione e la modifica.
LICENZA PUBBLICA GENERICA GNU TERMINI E CONDIZIONI PER LA COPIA,
LA DISTRIBUZIONE E LA MODIFICA
0. Questa Licenza si applica a ogni programma o altra opera che contenga una
nota da parte del detentore del copyright che dica che tale opera può essere
distribuita sotto i termini di questa Licenza Pubblica Generica. Il termine
“Programma” nel seguito si riferisce ad ogni programma o opera così definita,
e l’espressione “opera basata sul Programma” indica sia il Programma sia ogni
opera considerata “derivata” in base alla legge sul copyright; in altre parole,
un’opera contenente il Programma o una porzione di esso, sia letteralmente sia
modificato o tradotto in un’altra lingua. Da qui in avanti, la traduzione in ogni
caso considerata una “modifica”. Vengono ora elencati i diritti dei beneficiari
della licenza.
Attività diverse dalla copiatura, distribuzione e modifica non sono coperte
da questa Licenza e sono al di fuori della sua influenza.
L’atto di eseguire il Programma non viene limitato, e l’output del programma è coperto da questa Licenza solo se il suo contenuto costituisce un’opera
basata sul Programma (indipendentemente dal fatto che sia stato creato eseguendo il Programma). In base alla natura del Programma il suo output può
essere o meno coperto da questa Licenza.
1. E’ lecito copiare e distribuire copie letterali del codice sorgente del Programma
così come viene ricevuto, con qualsiasi mezzo, a condizione che venga riprodotta chiaramente su ogni copia una appropriata nota di copyright e di assenza di garanzia; che si mantengano intatti tutti i riferimenti a questa Licenza e
all’assenza di ogni garanzia; che si dia a ogni altro destinatario del Programma
una copia di questa Licenza insieme al Programma.
E’ possibile richiedere un pagamento per il trasferimento fisico di una
copia del Programma, è anche possibile a propria discrezione richiedere un
pagamento in cambio di una copertura assicurativa.
2. E’ lecito modificare la propria copia o copie del Programma, o parte di esso,
Le guide di Ancitel
83
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
creando perciò un’opera basata sul Programma, e copiare o distribuire tali
modifiche o tale opera secondo i termini del precedente comma 1, a patto che
siano soddisfatte tutte le condizioni che seguono:
a) Bisogna indicare chiaramente nei file che si tratta di copie modificate e la
data di ogni modifica.
b) Bisogna fare in modo che ogni opera distribuita o pubblicata, che in parte
o nella sua totalità derivi dal Programma o da parti di esso, sia con cessa
nella sua interezza in licenza gratuita ad ogni terza parte, secondo i termini di questa Licenza.
c) Se normalmente il programma modificato legge comandi interattivamente
quando viene eseguito, bisogna fare in modo che all’inizio dell’esecuzione
interattiva usuale, esso stampi un messaggio contenente una appropriata
nota di copyright e di assenza di garanzia (oppure che specifichi il tipo di
garanzia che si offre). Il messaggio deve inoltre specificare che chiunque
punti a ridistribuire il programma alle condizioni qui descritte deve indicare
come reperire questa Licenza. Se però il programma di partenza è interattivo ma normalmente non stampa tale messaggio, non occorre che un’opera basata sul Programma lo stampi.
Questi requisiti si applicano all’opera modificata nel suo complesso. Se sussistono parti identificabili dell’opera modificata che non siano derivate dal
Programma e che possono essere ragionevolmente considerate lavori indipendenti, allora questa Licenza e i suoi termini non si applicano a queste parti
quando queste vengono distribuite separatamente. Se per queste parti vengono distribuite all’interno di un prodotto che è un’opera basata sul Programma,
la distribuzione di quest’opera nella sua interezza deve avvenire nei termini di
questa Licenza, le cui norme nei confronti di altri utenti si estendono all’opera
nella sua interezza, e quindi ad ogni sua parte, chiunque ne sia l’autore.
Quindi, non è nelle intenzioni di questa sezione accampare diritti, ne contestare diritti su opere scritte interamente da altri; l’intento è piuttosto quello
di esercitare il diritto di controllare la distribuzione di opere derivati dal
Programma o che lo contengano.
Inoltre, la semplice aggregazione di un’opera non derivata dal Programma
col Programma o con un’opera da esso derivata su di un mezzo di memorizzazione o di distribuzione, non sufficente a includere l’opera non derivata nell’ambito di questa Licenza.
3. E’ lecito copiare e distribuire il Programma (o un’opera basata su di esso, come
espresso al comma 2) sotto forma di codice oggetto o eseguibile secondo i termini
dei precedenti commi 1 e 2, a patto che si applichi una delle seguenti condizioni:
a) Il Programma sia corredato del codice sorgente completo, in una forma
leggibile da calcolatore, e tale sorgente sia fornito secondo le regole dei
precedenti commi 1 e 2 su di un mezzo comunemente usato per lo scam-
84
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
bio di programmi.
b) Il Programma sia accompagnato da un’offerta scritta, valida per almeno tre
anni, di fornire a chiunque ne faccia richiesta una copia completa del codice sorgente, in una forma leggibile da calcolatore, in cambio di un compenso non superiore al costo del trasferimento fisico di tale copia, che deve
essere fornita secondo le regole dei precedenti commi 1 e 2 su di un mezzo
comunemente usato per lo scambio di programmi.
c) Il Programma sia accompagnato dalle informazioni che sono state ricevute
riguardo alla possibilità di ottenere il codice sorgente. Questa alternativa è
permessa solo in caso di distribuzioni non commerciali e solo se il programma è stato ottenuto sotto forma di codice oggetto o eseguibile in accordo
al precedente comma B.
Per “codice sorgente completo” di un’opera si intende la forma preferenziale usata per modificare un’opera. Per un programma eseguibile, “codice
sorgente completo” significa tutto il codice sorgente di tutti i moduli in esso
contenuti, più il file associato che definisca le interfacce esterne del programma, più i script usati per controllare la compilazione e l’installazione dell’eseguibile. In ogni caso non è necessario che il codice sorgente fornito includa
nulla che sia normalmente distribuito (in forma sorgente o in formato binario)
con i principali componenti del sistema operativo sotto cui viene eseguito il
Programma (compilatore, kernel,e così via), a meno che tali componenti
accompagnino l’eseguibile.
Se la distribuzione dell’eseguibile o del codice oggetto è effettuata indicando un luogo dal quale sia possibile copiarlo, permettere la copia del codice sorgente dallo stesso luogo è considerata una valida forma di distribuzione del
codice sorgente, anche se copiare il sorgente è facoltativo per l’acquirente.
4. Non è lecito copiare, modificare, sublicenziare, o distribuire il Programma in
modi diversi da quelli espressamente previsti da questa Licenza. Ogni tentativo di copiare, modificare, sublicenziare o distribuire altrimenti il Programma
non è autorizzato, e farà terminare automaticamente i diritti garantiti da questa Licenza. D’altra parte ogni acquirente che abbia ricevuto copie, o diritti,
coperti da questa Licenza da parte di persone che violano la Licenza come qui
indicato non vedranno invalidata la loro Licenza, purchè si comportino conformemente ad essa.
5. L’acquirente non è tenuto ad accettare questa Licenza, poiché non l’ha firmata. D’altra parte nessun altro documento garantisce il permesso di modificare o distribuire il Programma o i lavori derivati da esso. Queste azioni sono proibite dalla legge per chi non accetta questa Licenza; perciò modificando o distribuendo il Programma o un’opera basata sul programma, si indica nel fare ciò
l’accettazione di questa Licenza e quindi di tutti i suoi termini e le condizioni
poste sulla copia, la distribuzione e la modifica del Programma o di lavori basati su di esso.
Le guide di Ancitel
85
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
6. Ogni volta che il Programma o un’opera basata su di esso vengono distribuiti,
l’acquirente riceve automaticamente una licenza d’uso da parte del licenziatario originale. Tale licenza regola la copia, la distribuzione e la modifica del
Programma secondo questi termini e queste condizioni. Non è lecito imporre
restrizioni ulteriori all’acquirente nel suo esercizio dei diritti qui garantiti. Chi
distribuisce programmi coperti da questa Licenza non e’ comunque tenuto a
imporre il rispetto di questa Licenza a terzi.
7. Se, come conseguenza del giudizio di un tribunale, o di una imputazione per la
violazione di un brevetto o per ogni altra ragione (non limitatamente a questioni di brevetti), vengono imposte condizioni che contraddicono le condizioni di questa licenza, che queste condizioni siano dettate dalla corte, da accordi tra le parti o altro, queste condizioni non esimono nessuno dall’osservazione di questa Licenza. Se non è possibile distribuire un prodotto in un modo
che soddisfi simultaneamente gli obblighi dettati da questa Licenza e altri
obblighi pertinenti, il prodotto non può essere affatto distribuito. Per esempio,
se un brevetto non permettesse a tutti quelli che lo ricevono di ridistribuire il
Programma senza obbligare al pagamento di diritti, allora l’unico modo per
soddisfare contemporaneamente il brevetto e questa Licenza e’ di non distribuire affatto il Programma.
Se una qualunque parte di questo comma è ritenuta non valida o non
applicabile in una qualunque circostanza, deve comunque essere applicata
l’idea espressa da questo comma; in ogni altra circostanza invece deve essere
applicato questo comma nel suo complesso.
Non è nelle finalità di questo comma indurre gli utenti ad infrangere alcun
brevetto ne ogni altra rivendicazione di diritti di proprietà ne di contestare la
validità di alcuna di queste rivendicazioni; lo scopo di questo comma è unicamente quello di proteggere l’integrità del sistema di distribuzione dei programmi liberi, che viene realizzato tramite l’usodi licenze pubbliche. Molte
persone hanno contribuito generosamente alla vasta gamma di programmi
distribuiti attraverso questo sistema, basandosi sull’applicazione fedele di tale
sistema. L’autore/donatore può decidere di sua volontà e preferisce distribuire
il software avvalendosi di altri sistemi, e l’acquirente non può opporre la scelta del sistema di distribuzione.
Questo comma serve a rendere il più chiaro possibile ciò che crediamo sia
una conseguenza del resto di questa Licenza.
8. Se in alcuni paesi la distribuzione o l’uso del Programma sono limitati da brevetto o dall’uso di interfacce coperte da copyright, il detentore del copyright
originale che pone il Programma sotto questa Licenza può aggiungere limiti
geografici espliciti alla distribuzione, per escludere questi paesi dalla distribuzione stessa, in modo che il programma possa essere distribuito solo nei paesi
non esclusi da questa regola. In questo caso i limiti geografici sono inclusi in
questa Licenza e ne fanno parte a tutti gli effetti.
86
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
9. All’occorrenza la Free Software Foundation può pubblicare revisioni o nuove
versioni di questa Licenza Pubblica Generica. Tali nuove versioni saranno simili
a questa nello spirito, ma potranno differire nei dettagli al fine di coprire nuovi
problemi e nuove situazioni.
Ad ogni versione viene dato un numero identificativo. Se il Programma
asserisce di essere coperto da una particolare versione di questa Licenza e “da
ogni versione successiva”, l’acquirente può scegliere se seguire le condizioni
della versione specificata o di una successiva. Se il Programma non specifica
quale versione di questa Licenza deve applicarsi, l’acquirente può scegliere una
qualsiasi versione tra quelle pubblicate dalla Free Software Foundation.
10. Se si desidera incorporare parti del Programma in altri programmi liberi le cui
condizioni di distribuzio ne differiscano da queste, è possibile scrivere all’autore del Programma per chiederne l’autorizzazione. Per il software il cui copyright è detenuto dalla Free Software Foundation, si scriva alla Free Software
Foundation; talvolta facciamo eccezioni alle regole di questa Licenza. La nostra
decisione sarà guidata da due finalità preservare la libertà di tutti i prodotti
derivati dal nostro software libero e promuovere la condivisione e il riutilizzo
del software in generale.
NON C’E’ GARANZIA
11. POICHE’IL PROGRAMMA E’ CONCESSO IN USO GRATUITAMENTE, NON C’E’ GARANZIA
PER IL PROGRAMMA, NEI LIMITI PERMESSI DALLE VIGENTI LEGGI. SE NON INDICATO
DIVERSAMENTE PER ISCRITTO, IL DETENTORE DEL COPYRIGHT E LE ALTRE PARTI FORNISCONO IL PROGRAMMA “COSI’ COM’E’, SENZA ALCUN TIPO DI GARANZIA, NE
ESPLICITA NE IMPLICITA; CIO’ COMPRENDE, SENZA LIMITARSI A QUESTO, LA GARANZIA IMPLICITA DI COMMERCIABILITA’ E UTILIZZABILITA’ PER UN PARTICOLARE SCOPO.
L’INTERO RISCHIO CONCERNENTE LA QUALITA’ E LE PRESTAZIONI DEL PROGRAMMA E
DELL’ACQUIRENTE. SE IL PROGRAMMA DOVESSE RIVELARSI DIFETTOSO, L’ACQUIRENTE
SI ASSUME IL COSTO DI OGNI MANUTENZIONE, RIPARAZIONE O CORREZIONE NECESSARIA.
12. NE IL DETENTORE DEL COPYRIGHT NE ALTRE PARTI CHE POSSONO MODIFICARE O RIDISTRIBUIRE IL PROGRAMMA COME PERMESSO IN QUESTA LICENZA SONO RESPONSABILI PER DANNI NEI CONFRONTI DELL’ACQUIRENTE, A MENO CHE QUESTO NON SIA
RICHIESTO DALLE LEGGI VIGENTI O APPAIA IN UN ACCORDO SCRITTO. SONO INCLUSI
DANNI GENERICI, SPECIALI O INCIDENTALI, COME PURE I DANNI CHE CONSEGUONO
DALL’USO O DALL’IMPOSSIBILITA’ DI USARE IL PROGRAMMA; CIO’ COMPRENDE,
SENZA LIMITARSI A QUESTO, LA PERDITA DI DATI, LA CORRUZIONE DEI DATI, LE PERDITE SOSTENUTE DALL’ACQUIRENTE O DA TERZI E L’INCAPACITA’ DEL PROGRAMMA A
INTERAGIRE CON ALTRI PROGRAMMI, ANCHE SE IL DETENTORE O ALTRE PARTI SONO
STATE AVVISATE DELLA POSSIBILITA’ DI QUESTI DANNI.
Le guide di Ancitel
87
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
FINE DEI TERMINI E DELLE CONDIZIONI
Appendice: come applicare questi termini a nuovi programmi
Se si sviluppa un nuovo programma e lo si vuole rendere della maggiore utilità
possibile per il pubblico, la cosa migliore da fare è estendere tale programma libero, cosicché ciascuno possa ridistribuirlo e modificarlo sotto questi termini.
Per fare questo, si inserisca nel programma la seguente nota. La cosa migliore
da fare è mettere la nota all’inizio di ogni file sorgente, per chiarire nel modo più
efficiente possibile l’assenza di garanzia; ogni file dovrebbe contenere almeno la
nota di copyright e l’indicazione di dove trovare l’intera nota.
<una riga per dire in breve il nome del programma e cosa fa> Copyright (C)
<anno> <nome dell’autore>
Questo programma di software libero; è lecito redistribuirlo o modificarlo secondo i termini della Licenza Pubblica Generica GNU come pubblicata dalla Free
Software Foundation; o la versione 2 della licenza o (a propria scelta) una versione
successiva.
Questo programma è distribuito nella speranza che sia utile, ma SENZA ALCUNA GARANZIA; senza neppure la garanzia implicita di NEGOZIABILITA’ o di APPLICABILITA’ PER UN PARTICOLARE SCOPO. Si veda la Licenza Pubblica Generica
GNU per avere maggiori dettagli.
Questo programma deve essere distribuito assieme ad una copia della Licenza
Pubblica Generica GNU; in caso contrario, se ne può ottenere una scrivendo alla Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Si aggiungano anche informazioni su come si può essere contattati tramite posta
elettronica e cartacea.
Se il programma è interattivo, si faccia in modo che stampi una breve nota simile
a questa quando viene usato interattivamente:
Orcaloca versione 69, Copyright (C) anno nome dell’autore
Orcaloca non ha ALCUNA GARANZIA; per dettagli usare il comando `show g’.
Questo software libero, e ognuno libero di ridistribuirlo secondo certe condizioni;
usare il comando `show c’ per i dettagli.
Gli ipotetici comandi “show g” e “show c” mostreranno le parti appropriate della
Licenza Pubblica Generica. Chiaramente, i comandi usati possono essere chiamati
diversamente da “show g” e “show c” e possono anche essere selezionati con il
mouse o attraverso un menu comunque sia pertinente al programma.
Se necessario, si deve anche far firmare al proprio datore di lavoro (per chi lavora
come programmatore) o alla propria scuola, per chi è studente, una “rinuncia al
copyright” per il programma. Ecco un esempio con nomi fittizi:
Yoyodinamica SPA rinuncia con questo documento ad ogni diritto sul copyright del
programma `Orcaloca’ (che svolge dei passi di compilazione) scritto da Giovanni
88
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Smanettone.
<firma di Primo Tizio>, 1 April 3000
Primo Tizio, Presidente
I programmi coperti da questa Licenza Pubblica Generica non possono essere
incorporati all’interno di programmi proprietari. Se il proprio programma è una
libreria di funzioni, può essere più utile permettere di collegare applicazioni proprietarie alla libreria. Se si ha questa intenzione consigliamo di usare la Licenza
Pubblica Generica Minore GNU (LGPL) invece di questa Licenza.
05 - European Union Public License
Verso una “public license” targata EU
Anche l’Unione Europea sta studiando la possibilità di una “public license” e sul
sito15 IDABC, Paneuropean e-government services si possono trovare ulteriori
informazioni in proposito.
Per ulteriori informazioni su attività nel settore del Software Open Source ‘OSS’
fact sheet.
EU Public Licence: join the debate
All interested parties are now invited to join the online discussions on the EUPL
at the eGovernment Observatory’s forum. Comments regarding the principle of
a European open source software licence and the specific wording of the draft
text are particularly welcome16.
EUPL’s documentation
●
●
●
●
Study into Open Source Licensing of software developed by The European
Commission (PDF) http://europa.eu.int/idabc/servlets/Doc?id=21197
Introductive comments (PDF) http://europa.eu.int/idabc/servlets/Doc?id=21198
Preamble (PDF) http://europa.eu.int/idabc/servlets/Doc?id=21201
Draft EUPL (PDF) http://europa.eu.int/idabc/servlets/Doc?id=21203
The IDA Open Source Migration Guidelines - November 2003
These guidelines have been designed to help public administrators decide
whether a migration to OSS should be undertaken and describe, in broad technical terms, how such a migration could be carried out. They are based on practical experience of a limited number of publicly available case studies, and cover
a wide range of management and technical concerns.
IDA Open Source Migration Guidelines (PDF)
http://europa.eu.int/idabc/servlets/Doc?id=1983
IDA Open Source Migration Guidelines (OpenOffice.org format)
15) http://europa.eu.int/idabc/en/document/2623/5585#eupl
16) http://forum.europa.eu.int/public/irc/ida/egov/newsgroups?n=europa.ida.egov.egovernment
Le guide di Ancitel
89
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Comparative Spreadsheet and the relevant Explanatory Notes (EN)
Comparison Spreadsheet (Microsoft Excel format)
Comparison Spreadsheet (OpenOffice.org format)
Explanatory Notes (PDF)
Feasibility Study
Condivisione di software a codice sorgente aperto (PDF)
Study into the use of OSS in the public sector
The ‘Study into the Use of Open Source Software in the Public Sector’ was conducted by Unisys Belgium following a call for tender issued in the frame of the IDA
Programme. This study entails three components:
●
The OSS fact sheet gives an overview of the situation in the spring of 2001 and
an assessment of availability and potential use of OSS based solutions, by software category, as well as a selection of about 100 typical OSS solutions;
●
The second part of the study focuses on OSS usage and experience made in six
European countries (Belgium, France, Spain, Germany, Italy, Sweden) and in the
European Union administration;
●
The third part gives an overview of the OSS market structure, with opportunities and issues related to the use of OSS solutions.
The Study
1. Study into the use of OSS in the Public Sector - OSS Fact sheet (PDF)
2. Study into the use of OSS in the Public Sector - Use of the Open Source in the Europe (PDF)
3. Study into the use of OSS in the Public Sector - The Open Source Market Structure (PDF)
4. Study into the use of OSS in the Public Sector - Annex: OSS alphabetical list and software
identification (PDF)
Articles
IDA issues Open Source Migration Guidelines - IDA Report 20 - December 2003
Policy makers meet to propose actions to improve software use - IDA Report 16 December 2002
IDA Work programmes
Migration
Guidelines
The
HAM
work
programme
2004
-
PDF
(p.79)
The
HAM
work
programme
2003
-
PDF
(p.53)
OS
Observatory
Open
Source
&
Pooling
Software
IDA Work Programmes
90
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
06 - CECILL LA LICENZA PER IL SOFTWARE LIBERO DELLA RICERCA FRANCESE
CeCILL et les logiciels libres 17
Les logiciels libres ont aujourd’hui un rôle important dans le monde de la
recherche scientifique. Dans le monde de l’entreprise et des administrations, ils
tiennent une place de plus en plus importante. Cependant, leur diffusion sous des
licences de source américaine comme la GNU GPL pose certaines questions de
droit, engendrant des incertitudes qui peuvent dissuader des entreprises ou des
organisations d’apporter leurs contributions aux logiciels libres.
Pour apporter une meilleure sécurité juridique, tout en conservant au mieux
l’esprit de ces licences, le CEA, le CNRS et l’INRIA ont lancé un projet de rédaction
de contrats de licences de logiciels libres de droit français.
Le CEA, le CNRS et l’INRIA viennent ainsi d’élaborer CeCILL, la première licence
qui définit les principes d’utilisation et de diffusion des logiciels libres en conformité avec le droit francais, reprenant les principes de la GNU GPL.
Cette licence a vocation à être utilisée en particulier par les sociétés, les organismes de recherche et établissements publics français et plus généralement par
toute entité ou individu désirant diffuser ses résultats sous licence de logiciel libre,
en toute sécurité juridique. CeCILL est aussi tout à fait adaptée pour des projets
internationaux.
A la une
La version 2 de CeCILL est disponible depuis le 21 mai. Cette version est le
résultat d’une série de consultations et de la prise en compte des remarques de la
communauté des Logiciels Libres, notamment en provenance de l’AFUL, de l’APRIL
et de la FSF que nous tenons à remercier pour leurs contributions. La traduction
anglaise a été grandement améliorée et elle a maintenant la même valeur juridique que le texte français (les deux versions française et anglaise font également
foi). C’est le changement majeur, qui devrait faciliter l’adoption de CeCILL dans les
projets internationaux.
●
Acronyme pour Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre).
●
Licence libre de droit français compatible avec la licence GNU GPL.
●
Texte de la licence en langue française dans sa version 2: en HTML, en texte simple.
●
Texte de la licence en langue anglaise dans sa version 2: en HTML, en texte simple.
●
Texte de la licence en français dans sa version 1: en HTML, en texte simple, en PDF.
●
Traduction anglaise de la version 1: en HTML, en texte simple, en PDF.
17) http://www.cecill.info/
Le guide di Ancitel
91
APPENDICE 3
NORMATIVA DI RIFERIMENTO PER OSS
92
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
NORMATIVA COMUNITARIA
Direttiva 2004/48/CE del Parlamento Europeo e del Consiglio del 29 aprile 2004
sul rispetto dei diritti di proprietà intellettuale (Testo rilevante ai fini del SEE)
GAZZETTA
UFFICIALE N.
L 157
DEL
30/04/2004
Rettifica della direttiva 2004/48/CE del Parlamento europeo e del Consiglio,
del 29 aprile 2004, sul rispetto dei diritti di proprietà intellettuale (GU L 157
del 30.4.2004)
GAZZETTA
UFFICIALE N.
L 195
DEL
02/06/2004
Proposta di direttiva del Parlamento europeo e del Consiglio relativa alla
brevettabilità delle invenzioni attuate per mezzo di elaboratori elettronici/* COM/2002/0092 def. - COD 2002/0047 */
GAZZETTA
UFFICIALE N.
C 151 E
DEL
25/06/2002
Direttiva 2001/84/CE del Parlamento europeo e del Consiglio, del 27 settembre 2001, relativa al diritto dell’autore di un’opera d’arte sulle successive
vendite dell’originale
GAZZETTA
UFFICIALE N.
L 272
DEL
13/10/2001
Direttiva 2001/29/CE del Parlamento europeo e del Consiglio, del 22 maggio 2001, sull’armonizzazione di taluni aspetti del diritto d’autore e dei
diritti connessi nella società dell’informazione
GAZZETTA
UFFICIALE N.
L 167
DEL
22/06/2001
Direttiva 93/98/CEE del Consiglio, del 29 ottobre 1993, concernente l’armonizzazione della durata di protezione del diritto d’autore e di alcuni diritti
connessi
GAZZETTA
UFFICIALE N.
L 290
DEL
24/11/1993
Direttiva 93/83/CEE del Consiglio, del 27 settembre 1993, per il coordinamento di alcune norme in materia di diritto d’autore e diritti connessi applicabili alla radiodiffusione via satellite e alla ritrasmissione via cavo
GAZZETTA
UFFICIALE N.
L 248
DEL
06/10/1993
Direttiva 92/100/CEE del Consiglio, del 19 novembre 1992, concernente il
diritto di noleggio, il diritto di prestito e taluni diritti connessi al diritto di
autore in materia di proprietà intellettuale
GAZZETTA
UFFICIALE N.
Le guide di Ancitel
L 346
DEL
27/11/1992
93
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
Direttiva 91/250/CEE del Consiglio, del 14 maggio 1991, relativa alla tutela
giuridica dei programmi per elaboratore
GAZZETTA
UFFICIALE N.
L 122
DEL
17/05/1991
Piano di azione e-EUROPE 2005-2002
DECISIONE del Consiglio del 16 marzo 2000
RISOLUZIONE del Parlamento e del Consiglio del 13 ottobre 1998
Accordi GATT/TRIPs
Trattati OMPI
Convenzione di Berna
Trattato di Nizza
Computer Software Amendment Act del 1980 (USA)
NORMATIVA ITALIANA
DECRETO PRESIDENZA CONSIGLIO MINISTRI
31 Maggio 2005
Razionalizzazione in merito all’uso delle applicazioni informatiche e servizi
ex articolo 1, commi 192, 193, e 194 della legge n. 311 del 2004
G.U. 18.06.2005 N. 140
DIRETTIVA PRESIDENZA CONSIGLIO MINISTRI
Dipartimento per l’Innovazione e le Tecnologie
19 dicembre 2003
Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche
amministrazioni.
G.U. 07.02.2004 N. 31
DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI
11 Luglio 2001, n.338
Regolamento di esecuzione delle disposizioni relative al contrassegno
della Società italiana degli autori e degli editori (S.I.A.E.) di cui all’articolo
181-bis della legge 22 aprile 1941, n. 633, come introdotto dall’articolo 10
della legge 18 agosto 2000, n. 248, recante nuove norme di tutela del
diritto d’autore.
G.U. 22.08.2001 N. 194
LEGGE
18 Agosto 2000, n.248
Nuove norme di tutela del diritto di autore.
G.U. 04.09.2000 N. 206
94
Le guide di Ancitel
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI
10 Febbraio 1999
Adeguamento dei diritti fissi spettanti alla Società Italiana Autori ed
Editori (S.I.A.E.) riguardanti il registro pubblico speciale per i programmi
per elaboratore.
G.U. 30.09.1999 N. 230
DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI
6 Agosto 1997, n.452
Regolamento recante approvazione del capitolato di cui all’articolo 12,
comma 1, del decreto legislativo 12 febbraio 1993, n. 39, relativo alla locazione e all’acquisto di apparecchiature informatiche, nonché alla licenza
d’uso dei programmi.
G.U. 30.12.1997 N. 302
DECRETO LEGISLATIVO
15 Marzo 1996, n.205
Modificazioni al decreto legislativo 29 dicembre 1992, n. 518, in materia
di tutela giuridica dei programmi per elaboratore.
G.U. 24.04.1996 N. 96
DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI
3 Gennaio 1994, n.244
Regolamento concernente il registro pubblico speciale per i programmi
per elaboratore.
G.U. 22.04.1994 N. 93
DECRETO LEGISLATIVO
12 Febbraio 1993, n.39
Norme in materia di sistemi informativi automatizzati delle amministrazioni pubbliche, a norma dell’art. 2, comma 1, lettera mm), della legge 23
ottobre 1992, n. 421.
G.U. 20.02.1993 N. 42
DECRETO LEGISLATIVO
29 Dicembre 1992, n.518
Attuazione della direttiva 91/250/CEE relativa alla tutela giuridica dei programmi per elaboratore.
G.U. 31.12.1992 N. 306 Suppl. Ord.
LEGGE 19 Dicembre 1992, n.489
Disposizioni in materia di attuazione di direttive comunitarie relative al
mercato interno.
(…anche su Tutela giuridica programmi per elaboratore)
G.U. 21.12.1992 N. 299
Le guide di Ancitel
95
Guida Open Source: Guida pratica per strategie e servizi Open Source di e-Government nella P.A. locale
LEGGE 20 Giugno 1978, n.399
Ratifica ed esecuzione della Convenzione di Berna per la protezione delle
opere letterarie ed artistiche,firmata il 9 settembre 1886, completata a
Parigi il 4 maggio 1896,riveduta a Berlino il 13 novembre 1908,completata
a Berna il 20 marzo 1914,riveduta a Roma il 2 giugno 1928,a Bruxelles il
26 giugno 1948,a Stoccolma il 14 luglio 1967 e a Parigi il 24 luglio
1971,con Allegato.
G.U. 02.08.1978 N. 214 SUPPL. ORD.
Codice Civile- DISPOSIZIONI IN MATERIA DI DIRITTO D’AUTORE Artt. 2576-2583
D.Lgs. Lgt. 20 luglio 1945, n. 440- Proroga dei termini per la protezione delle
opere dell’ingegno e dei prodotti tutelati dalla L. 22 Aprile 1941, n. 633.
L. 6 febbraio 1942, n. 95- Disciplina tributaria degli atti relativi all’esercizio del diritto d’autore a norma della legge 22 aprile 1941, n. 633, e determinazione del diritto demaniale.
L. 22 aprile 1941, n. 633- Protezione del diritto d’autore e di altri diritti connessi al
suo esercizio e Regolamento d’esecuzione.
GAZZETTA UFFICIALE 16.07.1941 N.166
96
Le guide di Ancitel