Il documento analizza l'importanza e il funzionamento del software open source nella pubblica amministrazione italiana, evidenziando vantaggi come il contenimento dei costi e la non dipendenza da fornitori unici. Viene discussa la differenza tra modelli di licenza open source e proprietaria, insieme a normative e direttive che incoraggiano l'uso del software open source nelle istituzioni pubbliche. Inoltre, vengono citati vari esempi di applicazioni software e le risorse online disponibili per l'acquisizione di software open source.

1. CSBNO:Comune di Busto Garolfo: Seminari Informagiovani: 27-5-2004
Il software Open Source
Roma, Forum PA, 13/5/2004
Andrea Giacomelli

2. Sommario
Perché serve il software
Che cosa significa “software open source”
Ciclo di vita di un software
Software “a codice sorgente aperto”
Cosa fa la PA
Cosa dicono “loro”
Conclusioni

3. Perché serve il software (I)
Contenuto
Esigenza: scrivere una lettera tono
ortografia
impaginazione
Macchina
da scrivere
con foglio
Corso di dattilografia (può aiutare)

4. Perché serve il software (II)
Contenuto
Esigenza: scrivere una lettera tono
ortografia (meno)
Computer impaginazione (meno)
stampante
sist. Operativo
sw elaborazione testi
corso sist op
corso elab testi
manuale stampante
Corso di dattilografia (può aiutare)
Esigenza: scrivere mille lettere al giorno…ecc.

5. Definizione canonica
Nasce nella sua formulazione attuale nel 1985
Richard Stallman (MIT, Boston), con la Free
Software Foundation.
Idea di base:
Impedire la libera circolazione del software, o più in generale delle
innovazioni tecnologiche, è un grave impedimento alla maturazione e
al procedere della ricerca e della tecnologia stessa.
Concetto di “copyleft” in contrapposizione al tradizionale “copyright”:
•il copyright tende a tutelare il diritto d'autore anche attraverso
limitazioni all'accesso della conoscenza
•il copyleft intende tutelare il più generale diritto della collettività a
fruire dei prodotti dell'innovazione.

6. La General Public license...
O GPL, definita dalla FSF per l’utilizzo del proprio software
Il software viene essere rilasciato completo di
•codici sorgenti
•informazioni necessarie per la compilazione.
Il cliente può:
•duplicare/installare copie multiple, all'interno della propria
organizzazione, del software acquisito senza oneri aggiuntivi;
•modificare/estendere il software acquisito a suo piacimento, oppure
inglobare il software acquisito in altri sistemi di sua proprietà;
•commercializzare le estensioni realizzate oppure i sistemi di sua
proprietà includenti il software acquisito. In tal caso, però, è vincolato
a utilizzare la GPL: dovrà cioè fornire il codice sorgente delle
estensioni realizzate

7. Attenzione
La GPL non prescrive in nessun caso che il software debba essere
ceduto gratuitamente.
Dunque il software open source non è affatto un'alternativa al
software commerciale
Il modello OSS non preclude la presenza di
•distribuzione commerciale
•fornitori di valore aggiunto
•servizi di supporto.
È più corretto definire l'OSS come alternativa al modello di licenza
proprietario (closed source), in cui:
•l'accesso al codice sorgente non è concesso
•il fornitore del software mantiene i diritti sul proprio prodotto e
vende all'utente una "licenza d'utilizzo", temporanea o illimitata, che
consente l'uso del prodotto, ma non implica in nessun modo che
l'utente acquisisca la proprietà del software.

8. Etimologia
Open-source software
=
Software “a codice sorgente aperto”
Esempio di sorgente
use strict;
use Win32::OLE;
use Win32::OLE::Const 'Microsoft Word';
my $Word = Win32::OLE->new('Word.Application', 'Quit');
# $Word->{'Visible'} = 1; # if you want to see what's going on
$Word->Documents->Open('C:TEMPbci.doc')
|| die("Unable to open document ", Win32::OLE->LastError());
my %b_dp = $Word->ActiveDocument->{BuiltinDocumentProperties};
foreach my $prop ( keys %b_dp ) {
print $prop . " " . %b_dp->{$prop}->{'Name'} . "n";
print $prop . " " . %b_dp->{$prop}->{'Value'} . "n";
}

9. GPL e non solo
*Motosoto License
*Academic Free License
*Mozilla Public License 1.0 (MPL)
*Apache Software License
*Mozilla Public License 1.1 (MPL)
*Apache License, 2.0
*Naumen Public License
*Apple Public Source License
*Nethack General Public License
*Artistic license
*Nokia Open Source License
*Attribution Assurance Licenses
* OCLC Research Public License 2.0
*BSD license
*Open Group Test Suite License
*Common Public License
*Open Software License
*CUA Office Public License Version 1.0
*PHP License
*EU DataGrid Software License
*Python license (CNRI Python License)
*Eiffel Forum License
*Python Software Foundation License
*Eiffel Forum License V2.0
*Qt Public License (QPL)
*Entessa Public License
*RealNetworks Public Source License
*Fair License
V1.0
*Frameworx License
*Reciprocal Public License
*GNU General Public License (GPL)
*Ricoh Source Code Public License
*GNU Library or "Lesser" General Public
*Sleepycat License
License (LGPL)
*Sun Industry Standards Source
*Lucent Public License (Plan9)
License (SISSL)
*Lucent Public License Version 1.02
*Sun Public License
*IBM Public License
*Sybase Open Watcom Public License
*Intel Open Source License
1.0
*Historical Permission Notice and
*University of Illinois/NCSA Open
Disclaimer
Source License
*Jabber Open Source License
*Vovida Software License v. 1.0
*MIT license
*W3C License
*MITRE Collaborative Virtual Workspace
*wxWindows Library License
License (CVW License)
*X.Net License
*Zope Public License
*zlib/libpng license

10. Come “si chiude” il sorgente
E come nasce un applicativo
ESIGENZA
PROGETTAZIONE
SVILUPPO
SORGENTE COMPILATORE
ESEGUIBILE
(per dato S.O.)
S.O.
HW
PRODOTTO
(applicazione,
manuali
ecc)

11. (continua)
PRODOTTO
(applicazione,
manuali DISTRIBUZIONE
ecc)
SCATOLA SITO WEB
INSTALLAZIONE ACCETTAZIONE LICENZA
REGISTRAZIONE
ESEGUIBILE (S.O.)
documentazione
UTILIZZO
S.O.
HW

12. Quadro completo
ESIGENZA
SORGENTE
PROGETTAZIONE COMPILATORE ESEGUIBILE
(per dato S.O.)
SVILUPPO S.O.
PRODOTTO
HW (applicazione,
manuali
ecc)
DISTRIBUZIONE
SCATOLA SITO WEB
ACCETTAZIONE LICENZA
INSTALLAZIONE
REGISTRAZIONE
•ESEGUIBILE
•(per dato S.O.)
•documentazione
UTILIZZO
UTENTE
CONTENTO ?
S.O.
HW

13. Cambiamenti nel tempo
ESIGENZA
SORGENTE
PROGETTAZIONE COMPILATORE ESEGUIBILE
(per dato S.O.)
SVILUPPO S.O.
PRODOTTO
HW (applicazione,
manuali
ecc)
DISTRIBUZIONE
SCATOLA SITO WEB
ACCETTAZIONE LICENZA
INSTALLAZIONE
REGISTRAZIONE
Nuovo S.O. ? •ESEGUIBILE
•(per dato S.O.)
•documentazione UTENTE
Nuovo HW ? UTILIZZO
CONTENTO ?
S.O.
nuova esigenza ? HW

14. Opensource per gli utenti
•Il cliente non è “prigioniero”
•Dipendenza da “bachi” non aggiustati (“known
problem…will be fixed in next release”)
•Il supporto può essere acquistato da altri a costo
minore
•La convenienza si ha anche per prodotti sviluppati
“in casa”
•Questioni legali - licenze

15. Opensource per gli affari
•Affidabilità, dovuta al metodo di revisione
•Convenienza per i produttori di software
Velocità di sviluppo
Minori costi strutturali
•Convenienza per i venditori di software
Vicinanza al cliente
Mercato più ampio

16. “Le fonti” dove reperire il
software
http://metalab.unc.edu/pub/Linux/!INDEX.html
http://www.perl.com/perl
http://www.python.org.
http://sourceforge.net
http://freshmeat.net
http://www.opensourcedirectory.org
In Italia ?

17. Sourceforge
Communications 10291
Database 4174
Desktop Environment 2226
Education 2121
Games/Entertainment 9582
Internet 16398
Multimedia 8205
Office/Business 3322
Other/Nonlisted Topic 1657
Printing 302
Religion 183
Scientific/Engineering 6246
Security 1770
Sociology 226
Software Development 11196
System 13420
Terminals 408
Text Editors 1848

18. Sourceforge
Disponibilità “progetti” per sistema operativo
BeOS 442
MacOS 3570
Microsoft 20466
OS/2 136
OS Independent 20486
Other OS 1081
PDA Systems 748
POSIX 32471

19. Quali e quante applicazioni
•Musica
•fotografia digitale (image processing)
•web
•scrivere
•fare conti
•programmare

20. Gnumeric

21. Gphoto

22. G-iochetti

23. Gimp

24. Musica

25. Cose “strane”: VMWare

26. Cose “strane”: WINE

27. Cose “strane”: Linspire

28. Altre possibilità
Software Opensource sotto windows
Software che costa meno: quanto
potete/volete spendere ?

29. Opensource PA (1)
Direttiva in materia di sviluppo
ed utilizzo dei programmi informatici da parte delle Pubbliche
Amministrazioni (G.U. n. 31 del 7/2/2004)
Oltre alle esigenze “tecniche” specifiche, si deve valutare
•la trasferibilità ad altre Amministrazioni delle
soluzioni acquisite
•l'interoperabilità e la cooperazione applicativa tra le
amministrazioni
•la non dipendenza da un unico fornitore o da
un'unica tecnologia proprietaria
•la disponibilità del codice sorgente per ispezione e
tracciabilità
•la esportabilità di dati e documenti in più formati, di
cui almeno uno di tipo aperto

30. Opensource PA (2)
La rilevanza internazionale assunta dal fenomeno ha indotto il
Ministro per l'Innovazione e le Tecnologie a promuovere uno
studio sul software a codice sorgente aperto al fine di consentire
una corretta valutazione delle possibilità d'utilizzo nella PA.
La distribuzione ed evoluzione del software OS può infatti
determinare una serie di vantaggi in termini di:
•contenimento dei prezzi
•trasparenza e sicurezza
•non dipendenza da un unico fornitore
•elevata riusabilità
•accessibilità per le piccole realtà di sviluppo

31. Opensource PA (3)
•le PA non devono vietare né penalizzare l'utilizzo di pacchetti open source: il criterio
che deve valere al momento della selezione di una soluzione software è quello del
value for money.
•i software custom (e le personalizzazioni) devono essere di piena proprietà (non
necessariamente esclusiva) della PA. I contratti di outsourcing devono includere
opportune clausole di protezione.
•é necessario sostenere e facilitare il riuso dei software custom di proprietà delle PA, e
la disseminazione dei risultati e delle best practice tra tutte le PA del Paese.
•tutti i pacchetti proprietari acquisiti su licenza devono essere disponibili per ispezione
e tracciabilità da parte della PA. Le PA devono essere tutelate nel caso un fornitore di
pacchetti non sia più in grado di fornire supporto.
•i sistemi informativi delle PA devono interagire attraverso interfacce standard che
non siano vincolate ad un unico fornitore.
•i documenti delle PA sono resi disponibili e memorizzati attraverso uno o più formati.
Di questi almeno uno deve essere obbligatoriamente aperto, mentre gli altri, se
presenti, possono essere scelti a discrezione della PA tra quelli aperti o proprietari.
•il trasferimento del software custom e delle licenze dei pacchetti tra PA deve essere
libero da vincoli e favorito.
•é opportuno definire linee guida, strumenti di pianificazione e servizi di supporto ai
processi di procurement di prodotti software nelle PA. Ciò deve attuarsi attraverso la
valorizzazione ed il potenziamento delle competenze e delle risorse presenti sul
territorio.
•é necessario definire politiche di disseminazione per i progetti di ricerca e
innovazione tecnologica finanziati con fondi pubblici affinché vi sia maggiore riuso dei
risultati. La modalità open source può essere uno strumento utile da sperimentare per
diffondere prodotti software innovativi risultanti da tali progetti.

32. Opensource PA (4)
La Commissione ha, infine, auspicato l'impiego del software anche nei
progetti di e-government realizzati in occasione di futuri bandi di
finanziamento nazionale.
La possibiltà di acquisizione ed utilizzo di programmi informatici "open
source" é stata poi sostenuta nella direttiva del 18 dicembre 2003 del
Ministro Stanca pubblicata sulla G.U. del 7 febbraio 2004.
In ambito europeo la Commissione ha sostenuto la diffusione del software
OS sia attraverso il programma di ricerca IST che nel progetto IDA
(Interchange of Data between Administrations).
Nell'ambito del programma IDA sono state elaborate delle linee guida per
aiutare le amministrazioni a decidere quando ed in che modo adottare il
software "open source".
Le linee guida contengono suggerimenti utili su:
•gli ambiti in cui risulta maggiormente opportuno passare
all'utilizzo di un software open source;
•quali prodotti scegliere;
•quali passi seguire durante la migrazione.
Sul sito dell'IDA è stato inoltre allestito uno spazio dedicato all'attività di
"osservatorio" che ha appunto lo scopo di favorire lo scambio e la diffusione
delle best practices in Europa in materia di Open Source.
I vantaggi connessi alla diffusione e all'utilizzo del software a codice
sorgente aperto sono, infine, stati recentemente rilevati anche in un
rapporto dell'Unctad (Agenzia delle Nazioni Unite per lo Sviluppo) che
prende chiaramente posizione a favore del software libero come strumento

33. Tutto molto bello...ma si
usa, o no ?
MIUR Vari servizi
Regione Lazio Infrastruttura per portale
Regione Piemonte, centro supercalcolo Rete comunicazione tra 23 centri
formazione
AIPA - Scuola Sup. S.Anna, Pisa Gestione documentale
Prov. Asti Gestione iter Merloni
Prov. Cremona Vari servizi
Prov. Ferrara ……………...
Prov. Imperia
Prov. Lucca
Pescara
Pisa
Prato
Reggio Emilia
Treviso
Questi sono alcuni casi “pubblicizzati”, ma
c’è molto che non si vede (necessità o virtù)

34. Normativa
Direttiva 19/12/2003
"Sviluppo ed utilizzazione dei programmi informatici da parte delle Pubbliche Amministrazioni"
Nella scelta delle soluzioni informatiche offerte dal mercato le P.A. possono acquistare ed utilizzare anche
programmi «open source»
Indagine conoscitiva sul software Open Source (12/6/2003)
della Commissione per il software a codice sorgente aperto nella P.A.
Commissione per il software a codice sorgente aperto - "open source"- nella Pubblica
Amministrazione
Decreto Ministeriale del 31 ottobre 2002
Linee guida dell'IDA
Le Linee guida, elaborate nell'ambito del programma IDA (Interchange of Data between Administrations) della
Commisione europea
Il software Open Source (OSS)
Scenari e prospettive per la diffusione del software open source sono analizzati nel documento prodotto
dall'AIPA
Legge 340/2000 (Disposizioni per la delegificazione di norme e per la semplificazione di
procedimenti amministrativi – Legge di semplificazione 1999)
Art. 25: il software sviluppato per una pubblica amministrazione è di proprietà dell'amministrazione stessa e
può essere ceduto a titolo gratuito ad ogni altra p.a. che ne faccia richiesta, fermo restando per quest'ultima
l'obbligo di pagare il canone per l'eventuale servizio di manutenzione.

35. Svantaggi ?
Spesso definiti in termini di “TOTAL COST OF OWNERSHIP”
“Mercato instabile dell'OSS”
“Non essendo supportato da alcuna azienda non si hanno
garanzie che con il tempo si assista ad un reale
progresso piuttosto che ad un riutilizzo stagnate di
tecnologia obsoleta.”
Mancanza di formazione interna
Dovendo intervenire direttamente sui codici* è chiaro che
l'installazione e l'assistenza richiedono una competenza
elevata, il che vuol dire anche dipendenza
dall'assistenza esterna a costi spesso notevoli.
….che cosa dicono “loro” ?

36. Conclusioni
….riepilogando...

37. Riferimenti
http://www.fsf.org/
http://www.opensource.org/
http://www.innovazione.gov.it/
http://www.microsoft.com
Riviste
Mediamente

38. Grazie per l’attenzione
pibinko@tiscali.it