21/05/2008. Introduzione al sorgente aperto. Introduzione al sorgente aperto AGENDA PUBBLICA AMMINISTRAZIONE & OPEN SOURCE

Transcript

1 AGENDA 1 PUBBLICA AMMINISTRAZIONE & OPEN SOURCE Ing. Alessandro Vinciarelli Introduzione al sorgente aperto Normativa di riferimento L Osservatorio Open Source del CNIPA Le esperienze delle pubbliche amministrazioni Le licenze software Campi di applicazione dell Open Source Panoramica di soluzioni a sorgente aperto 2 Introduzione al sorgente aperto Introduzione al sorgente aperto Senza la disponibilità del codice sorgente di una applicazione non è possibile apportare modifiche correttive e aggiornamenti migliorativi del software Soprattutto nei momenti iniziali in cui Internet cominciò a svilupparsi gli attori della rete iniziarono a scambiarsi codici sorgenti di applicazioni che potevano essere utili allo sviluppo della stessa rete internet 3 esigenza naturale di scambiare informazioni e renderle disponibili ad altri 4 1

2 Introduzione al sorgente aperto Introduzione al sorgente aperto Per come è nato il concetto di sorgente aperto i primi beneficiari (gli unici interessati) da questo nuovo meccanismo di sviluppare software Enti di ricerca Università Per molti anni l Open Source rimase quindi uno strumento nelle mani di persone volenterose, in grado però di contribuire allo sviluppo della nascente Internet e della società tecnologica a cui oggi siamo abituati 5 La forza del sorgente aperto è quindi questa capacità di collaborazione e partecipazione collettiva che, attraverso lo studio e l applicazione di più persone interessate può raggiungere due obiettivi differenti 1. Sviluppare applicazioni e protocolli solidi, condivisi e verificati a fondo in funzione delle esperienze e delle conoscenze di ognuno dei partecipanti 2. Sviluppare applicazioni e protocolli specializzati, adatti a rispondere al meglio allo specifico ambiente per i quali sono stati implementati A loro volta disponibili a specializzazioni ancora più profonde 6 Punto 1) Solidità e sicurezza Pregi e difetti, una prima valutazione Un ruolo fondamentale è giocato dalla sicurezza: L OS permette di analizzare a fondo l architettura di una applicazione e focalizzare l attenzione su aspetti di sicurezza Errori (bug) Codici maliziosi (backdoor) I bug sono presenti in ogni codice. Con il sorgente aperto: Vengono individuati più bug Vengono risolti più bug Vengono risolti i bug più velocemente 7 La sicurezza è solo uno degli aspetti di valutazione del concetto di software Open Source VANTAGGI Autonomia tecnologica Accesso alla tecnologia Sviluppo incrementale Sviluppo professionale Riduzione dei costi SVANTAGGI Assenza di garanzia Incertezza di manutenzione Assenza di supporto 8 2

3 VANTAGGI SVANTAGGI Autonomia tecnologica Assenza di garanzia L assenza di un proprietario del software rende l utilizzatore indipendente da un singolo fornitore Solitamente i prodotti Open Source nascono senza la possibilità di contestare in alcun modo la presenza di Accesso alla tecnologia errori che determinano problemi ed eventualmente Per la natura stessa del OS la tecnologia è accessibile all intera comunità danni Sviluppo incrementale Incertezza di manutenzione Grazie alla disponibilità del sorgente non è necessario Non è necessariamente vero che un software venga sviluppare ogni volta nuovi prodotti seguito indefinitivamente e che vengano rese Sviluppo professionale disponibili nuove versioni aggiornate La necessità di collaborare su uno stesso progetto migliora lo schema e le modalità di sviluppo del progetto Assenza di supporto Riduzione dei costi Spesso il supporto, a meno di quello offerto in Generalmente le soluzioni OS hanno costi molto limitati modalità autonoma dalla comunità, non è garantito rispetto ad una soluzione proprietaria 9 10 Il trend del sorgente aperto Trend Web Server Apache L uso di software e ambienti Open Source è in lenta e continua ascesa, anche in ambito aziendale e per le soluzioni business critical L interesse mostrato verso molti prodotti (principalmente di fascia base, ec. S.O., browser, applicazioni per Internet) mostra come l Open Source sia destinato a competere (e in acluni casi sostituire) con diverse soluzioni proprietarie ESEMPI??? server Linux, l'80% dei server dei grandi distributori di contenuti e servizi; web server Apache, ospita il 75% dei siti mondiali; database (MySql, Postgre) in rapida ascesa application server Apache Tomcat, è il più usato browser Firefox, in costante crescita server di posta (Exim, sendmail, postfix, qmail), la maggior parte dell' mondiali

4 Caso PA Quali vantaggi Oltre a quanto detto, per la Pubblica Amministrazione sono da evidenziare due altri aspetti positivi dell uso di sorgenti aperte: Interoperabilità, sia tra le PA italiane che con eventuali rapporti fuori dal territorio nazionale Grazie all uso di standard aperti e condivisi Che ad ogni modo garantisce la differenziazione dei servizi a livello della singola PA Riusabilità, legata alla possibilità di evolvere e riutilizzare applicazioni in esercizio presso altre amministrazioni Grazie alla condivisione del codice (che potrebbe addirittura portare al vantaggio di una riusabilità delle procedure e degli aspetti logistici e organizzativi Legata alla propensione dei software Open Source di essere più longevi rispetto a quelli proprietari 13 Caso PA Quali vantaggi Costi (circa 922,529 Ml Euro nel 2004) Il risparmio può essere reinvestito per acquisiti altri servizi, oppure servizi di supporto, assistenza o personalizzazione ma NON licenze Solitamente infatti, nel caso di software proprietario, il fornitore sviluppa (con costi elevati) la soluzione e (con altrettanti costi) effettua la manutenzione Spesso la manutenzione non è ad hoc, ma general pourpose per tutte le piattaforme o i software Se è necessario cambiare il fornitore si deve acquistare nuovamente ogni prodotto 14 NORMATIVA DI RIFERIMENTO Normativa di riferimento 15 Decreto legislativo 7 marzo 2005, n. 82, art. 68, comma 1, lettera d) - Codice dell amministrazione digitale. G.U. 16 maggio 2005, n Supplemento Ordinario n. 93 Decreto legislativo 4 aprile 2006, n Disposizioni integrative e correttive al decreto legislativo 7 marzo 2005, n. 82, recante codice dell amministrazione digitale. G.U. 29 aprile 2006, n Supplemento Ordinario n. 105 Direttiva del Ministro per l innovazione e le tecnologie 19 dicembre Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni. G.U. 7 febbraio 2004, n. 31 Decreto del Ministro per l innovazione e le tecnologie 31 ottobre Istituzione della Commissione per il software a codice sorgente aperto - open source - nella Pubblica Amministrazione. Legge 24 novembre 2000, n. 340, art Disposizioni per la delegificazione di norme e per la semplificazione di procedimenti amministrativi - Legge di semplificazione G.U. 24 novembre 2000, n

5 Direttiva 19 dicembre 2003 Direttiva 19 dicembre 2003 Sviluppo ed utilizzazione dei programmi informatici da parte delle P.A. Finalità: le Pubbliche Amministrazioni devono tenere conto dell offerta sul mercato di una nuova modalità di sviluppo e diffusione di programmi informatici, definita open source in un quadro di equilibrio, di pluralismo e di aperta competizione. 17 Analisi comparativa delle soluzioni Le P.A. acquisiscono programmi informatici a seguito di una valutazione comparativa tra le diverse soluzioni disponibili sul mercato: sviluppo di programmi informatici ad hoc riuso acquisizione di programmi informatici di tipo proprietario acquisizione di programmi informatici a codice sorgente aperto acquisizione mediante combinazione delle precedenti modalità Le P.A. valutano quale soluzione risulta più adeguata mediante comparazioni di tipo tecnico ed economico, tenendo conto anche del costo totale di possesso delle singole soluzioni e del costo di uscita. 18 Direttiva 19 dicembre 2003 Direttiva 19 dicembre 2003 Criteri tecnici di comparazione Particolare rilievo riveste l attività di valutazione comparativa tra diverse soluzioni software. Anzitutto si nota che i criteri utilizzati per i software proprietari non sempre si adattano ai software OS: occorre una metodologia specifica. In particolare si hanno le seguenti caratteristiche: età del prodotto motivazione degli sviluppi organizzazione della community di sviluppo penetrazione del mercato disponibilità di documentazione e qualità della stessa integrabilità del prodotto con altri software 19 Ad ognuna delle caratteristiche occorre assegnare un peso ottenuto tramite questionari, esperienze personali, percezione, etc. Nel quantificare ciascun peso entrano in gioco variabili legate alle specifiche del progetto, alle caratteristiche dell amministrazione ed al contesto generale Tale peso contribuisce alla determinazione del punteggio per ogni soluzione software presa in esame. La metodologia proposta verrà affinata sulla base dell esperienza 20 5

6 Direttiva 19 dicembre 2003 Le P.A. privilegiano soluzioni informatiche che: a) basandosi su formati dei dati e interfacce aperte e standard, assicurino l interoperabilità e la cooperazione applicativa b) garantiscano la disponibilità del codice sorgente per ispezioni e tracciabilità (anche nel caso di codice proprietario) E compito del CNIPA promuovere l attuazione della direttiva, nonché fornire adeguato supporto alle amministrazioni. 21 L Osservatorio Open Source del CNIPA Le esperienze delle pubbliche amministrazioni 22 6

7 VETRINA CASI DI STUDIO UNIVERSITÀ DI PADOVA La Vetrina raccoglie le esperienze delle Pubbliche Amministrazioni italiane nell'uso di software Open Source (eventualmente insieme a software proprietario) per le proprie esigenze. Le Pubbliche Amministrazioni riportano all'osservatorio dei casi di studio relativi alle esigenze incontrate e risolte, in tutto o in parte, con l'utilizzo di prodotti open source. Inoltre, se in ciò l'amministrazione si è avvalsa di uno o più partner (fornitori) questi vengono riportati, insieme ai servizi da essi offerti. Attraverso la Vetrina si vuole offrire alle P.A. uno strumento di ricerca evoluto sui precedenti casi di studio. 25 Obiettivo Sistema Informativo di Radiologia (RIS) Prodotti utilizzati Apache CUPS Eclipse Firefox Java Javascript MySQL PHP 26 CASI DI STUDIO REGIONE VENETO Obiettivo Portale e-learning progettazione architetturale e sistemistica, sviluppo moduli formativi, interoperabilità moduli formativi, sviluppo rete sociale Prodotti utilizzati: Apache Firefox Javascript Linux Moodle MySQL OpenLDAP PHP Squid 27 Le licenze Software 28 7

8 Software come bene intellettuale Copyright Il software è un insieme di istruzioni (digitali) che componendosi riescono ad offrire un certo numero di funzionalità Il concetto di scrivere il codice si avvicina a quello di scrivere una qualsiasi altra opera, rendendo il software un bene intellettuale Come qualsiasi altra informazione, quindi, il software è un bene immateriale Dovuta anche alla considerazione che per essere eseguito ha bisogno di un supporto e di una serie di strumenti utili alla sua esecuzione 29 In quanto opera intellettuale ogni software è di proprietà dell autore, che può esercitare i diritti previsti dalla legge Diritti d autore = Copyright Ogni persona che volesse usufruire delle funzionalità del software o volesse effettuare una qualsiasi azione su di esso deve chiedere permesso all autore Tale permesso viene definito una volta per tutte nella licenza che accompagna ogni software e che specifica per ogni azione quello che può o non può essere fatto (per non incorrere in violazioni, anche penali) 30 Limitazioni da Copyright Le libertà del software libero Solitamente le licenze insistono su specifici punti relativi ad un software, in particolare: Uso e installazione Es. Uso personale o commerciale Duplicazione e riproduzione Pirateria VS Backup Modifica Garantita solo parzialmente dall assenza di codice sorgente Secondo Richard Stallman e la Free Software Foundation da lui fondata, un software per poter essere definito libero deve garantire quattro "libertà fondamentali": Libertà di eseguire il programma per qualsiasi scopo (chiamata "libertà 0") Libertà di studiare il programma e modificarlo ("libertà 1") Libertà di copiare il programma in modo da aiutare il prossimo ("libertà 2") 31 Libertà di migliorare il programma e di distribuirne pubblicamente i miglioramenti, in modo tale che tutta la comunità ne tragga beneficio ("libertà 3") 32 8

9 Software Libero VS Open Source OSI e FSF I termini software libero e open source vengono usati per indicare quella che è sostanzialmente la stessa cosa, ma da punti di vista diversi Free Software: secondo la FSF di Richard Stallman il software deve essere libero non in quanto gratuito, ma per una questione etica e di principio. Il software libero è software rilasciato con una licenza che permette a chiunque di utilizzarlo e che ne incoraggia lo studio, le modifiche e la redistribuzione. Open Source: deenfatizza gli aspetti etici, fondando le proprie scelte e motivazioni su considerazioni di Sia la Open Source Initiative (OSI) che la Free Software Foundation (FSF) hanno valutato con propri criteri le licenze utilizzate per la distribuzione di software. 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. SITI WEB OSI : FSF : carattere tecnico-economico OSI FSF

10 Le principali licenze OS AGENDA Introduzione al sorgente aperto Normativa di riferimento L Osservatorio Open Source del CNIPA Le esperienze delle pubbliche amministrazioni Le licenze software Campi di applicazione dell Open Source Panoramica di soluzioni a sorgente aperto CAMPI DI APPLICAZIONE DELL OPEN SOURCE Attualmente il software OS è disponibile per ogni realtà applicativa Sistemi operativi Server applicativi Server web DBMS Software per internet (desktop e server) Software per l ufficio Software per la gestione dei file Archiviazione Trasferimento Prodotti Open Source Panoramica delle soluzioni a sorgente aperto Software di sicurezza informatica