Una soluzione Open Source per il monitoraggio e la gestione della Cooperazione Applicativa Walter Ambu, Carlino Casari, Giorgio Follesa, Alessio Setzu, Luca Simbula CRS4 CSR {w.ambu, casari, gfollesa, simbula, a.setzu}@crs4.it SOMMARIO Negli ultimi anni, la possibilità di adottare soluzioni basate su software Open Source (OS) ha suscitato un interesse crescente da parte delle Pubbliche Amministrazioni. Questo articolo presenta un caso reale di integrazione di software Open Source nell'ambito del progetto SAR-SPCoop, sviluppato all'interno delle attività del CRS4-CSR 1. L'obiettivo principale del progetto SAR-SPCoop è la realizzazione di un sistema che consenta il monitoraggio e la gestione della Cooperazione Applicativa in ambito regionale, attraverso un insieme di servizi integrati all'interno di un'infrastruttura software OS. INTRODUZIONE Le Pubbliche Amministrazione (PPAA) mostrano un interesse crescente verso il fenomeno Open Source (OS) 2. In Italia, il dibattito risale alla fine del 2000 (art. 25 della legge 24 novembre 2000, n. 340), e oggi la finanziaria 2007 (comma 892, 895 e 896) promuove esplicitamente l'impiego di soluzioni OS nelle PPAA, stabilendo in particolare che nella valutazione dei progetti da finanziare destinati alla società dell'informazione, sia data priorità a quelli che utilizzano o sviluppano applicazioni software a codice aperto. I motivi per cui si auspica un maggiore utilizzo di sistemi OS a discapito di soluzioni proprietarie sono molteplici. Sicuramente le spese di adozione sono inferiori, dato che i costi di acquisizione e utilizzo dei prodotti OS sono nulli. Ma, nella valutazione di diverse soluzioni software, è più opportuno valutare il Total Cost of Ownership, che comprende non solo il costo delle licenze, ma anche altri costi nascosti come: costi di migrazione, formazione, personalizzazione, 1 Il CSR è un progetto del CRS4 finanziato dalla Regione Autonoma della Sardegna all interno dell Accordo di Programma Quadro per la Società dell Informazione (APQ_SI del 28 dicembre 2004). 2 In questo articolo si utilizzeranno indistintamente i termini Open Source, software aperto e libero e l'abbreviazione OS, intendendo sempre software aperto e libero. installazione, gestione etc., che vanno valutati caso per caso. Una motivazione sicuramente a favore dell'os è la maggiore indipendenza dai fornitori. L'utilizzo di software proprietario crea un vincolo molto forte tra produttore e consumatore, rendendo difficile e costoso il passaggio da un fornitore ad un altro. Il software OS facilita questo processo, consentendo alle PPAA di scegliere le aziende a cui affidare il supporto dei propri prodotti con maggiore libertà. Un'attenzione particolare meritano gli aspetti riguardanti gli standard aperti e liberi. Da una parte è necessario puntualizzare che Open Source non significa necessariamente Open Standard: possono infatti esistere prodotti OS che non utilizzano standard aperti, e prodotti proprietari che invece li rispettano perfettamente. D'altra parte, è indiscutibile che il mondo OS favorisca la diffusione di standard aperti, anche come effetto collaterale di una strategia di mercato che cerca di scardinare il monopolio di alcuni prodotti proprietari basati su standard chiusi. Dal punto di vista strategico è importante che le PPAA utilizzino formati standard e aperti. L'utilizzo di standard favorisce l'interoperabilità tra sistemi eterogenei e lo scambio di dati tra le PPAA, inoltre gli standard aperti favoriscono inoltre l'indipendenza dai fornitori. Di fatto esistono ormai diversi esempi di prodotti OS che implementano e/o utilizzano standard aperti. Oltre alle opportunità appena descritte, che sono oggetto di discussione nella letteratura attuale, ne esistono anche altre, non meno importanti e che possono essere sfruttate sia dalle PPAA che dai soggetti privati. Una di queste è data dalla possibilità di integrare diversi prodotti OS per sviluppare soluzioni complete per l'utente finale. Ancora una volta è importante sottolineare che l'integrazione non è una prerogativa dei sistemi OS; infatti è possibile integrare tra loro prodotti sia OS che proprietari (purché le licenze lo consentano). Utilizzare solamente prodotti OS fornisce però tutte le opportunità e i vantaggi qui brevemente riassunti, senza le limitazioni e i vincoli tipici delle soluzioni proprietarie.
Il fenomeno è in crescita, e ormai moltissime organizzazioni pubbliche e private utilizzano soluzioni di questo tipo come nuovo modello di sviluppo del territorio (nel caso di PPAA) e come nuovo modello di business nel caso di aziende private. In particolare, la maturità crescente delle soluzioni OS disponibili favorisce questo approccio, consentendo l'implementazione di sistemi completi, sicuri e a costi contenuti. Esistono infatti diversi casi in cui la maturità dei sistemi OS ha raggiunto un livello più che soddisfacente, come ad esempio nel settore degli application server, dei database, dell'automazione d'ufficio e così via. I sistemi OS possono dunque offrire alle PPAA una valida alternativa alle soluzioni proprietarie tradizionali. Molti progetti OS, essendo conformi agli standard aperti, assicurano un elevato grado di interoperabilità e favoriscono il riuso. Il libero accesso al codice sorgente permette di modificare i prodotti OS per effettuare estensioni e personalizzazioni. Inoltre, tali prodotti possono essere adattati e integrati con altri sistemi, non necessariamente OS, per sviluppare architetture più ampie in cui ogni prodotto può essere visto come un modulo. L'obiettivo principale di questo articolo è presentare un caso reale di integrazione di software OS, realizzato nell'ambito del progetto CRS4-CSR. Lo scopo di questa esperienza è realizzare un'infrastruttura intranet, che integri un insieme di strumenti per il monitoraggio e la gestione dei sistemi per la Cooperazione Applicativa (porte di dominio, registro servizi, Single Sign On etc). La soluzione è stata realizzata integrando esclusivamente componenti OS. Il resto dell'articolo è organizzato come segue: prima di tutto sarà fornita una breve introduzione al Sistema Pubblico di Cooperazione. Sarà quindi illustrato il progetto SAR-SPCoop e i suoi obiettivi principali, la soluzione proposta e l'architettura. Inoltre sarà descritto in dettaglio il processo di integrazione seguito, quindi una breve discussione del lavoro svolto e le conclusioni finali. IL SISTEMA PUBBLICO DI COOPERAZIONE Il Sistema Pubblico di Cooperazione (SPCoop) è il sottoinsieme del Sistema Pubblico di Connettività e Cooperazione (SPC) che include i sistemi di interoperabilità avanzata e di Cooperazione Applicativa. In particolare, per interoperabilità avanzata si intende un insieme di servizi idonei a favorire la circolazione, lo scambio di dati e informazioni, e l'erogazione fra le pubbliche amministrazioni e tra queste e i cittadini [4]. L'espressione Cooperazione Applicativa indica invece la parte finalizzata all'interazione tra i sistemi informatici delle pubbliche amministrazioni per garantire l'integrazione delle informazioni e dei procedimenti amministrativi [4]. E' importante notare che la specifica SPC include un secondo sottosistema, detto SPConn, che comprende i servizi di connettività ed interoperabilità di base. L'intera specifica SPC è stata formulata e rilasciata dal Centro Nazionale per l'informatica nella Pubblica Amministrazione (CNIPA) 3. Le amministrazioni cooperano attraverso l'erogazione e la fruizione di servizi applicativi; tali servizi vengono offerti dalla singola amministrazione attraverso un unico elemento (logico) del proprio sistema informativo denominato Porta di Dominio (PdD). Il dominio di un soggetto (pubblico o privato) della comunità dell'spc è l'insieme dei sistemi di cui il soggetto è titolare o responsabile. Il servizio applicativo opera sulla base di accordi tra almeno due soggetti (erogatore e fruitore), gli accordi devono essere inoltre formalizzati (Accordo di Servizio) e gestiti tramite i servizi infrastrutturali SICA (Servizi di Interoperabilità, Cooperazione ed Accesso). Gli Accordi di Servizio vengono registrati e mantenuti all'interno di un componente software chiamato Registro dei Servizi, che gestisce inoltre l'elenco dei soggetti e dei servizi. IL PROGETTO Il progetto ha due obiettivi fondamentali. Il primo è disporre di un sistema per il monitoraggio e la gestione della Cooperazione Applicativa regionale, il secondo è realizzare un'infrastruttura intranet di componenti software integrati che fornisca un punto di accesso centralizzato e unico per tutti i servizi, le applicazioni e le informazioni utili nell'ambito della Cooperazione Applicativa. In particolare, l'intranet deve permettere l'accesso ad una serie di strumenti web implementando meccanismi di autenticazione condivisi, mentre la gestione delle autorizzazioni e del controllo degli accessi può essere delegato alle singole applicazioni. La gestione e il monitoraggio della Cooperazione Applicativa devono avvenire come un insieme di servizi, integrati attraverso un'infrastruttura che funge da bus di integrazione, fruibili via web in modo trasparente per l'utente finale. Un altro aspetto del progetto di importanza notevole che va sottolineato riguarda la crescita delle competenze delle risorse umane coinvolte in un'area innovativa come quella della Cooperazione Applicativa. In questo senso, l'impiego del software OS, consentendo l'accesso e la modifica del codice sorgente, ha consentito di applicare e verificare, anche attraverso esempi pratici, in modo trasparente le direttive della specifica SPCoop emanate da poco più di un anno. E' importante notare che, essendo ad oggi molti requisiti non ancora definiti nel dettaglio, si è cercato 3 Per maggiori informazioni consultare il sito internet: http://www.cnipa.gov.it/site/it-it/
di sviluppare una piattaforma che fosse facile da gestire, manutenere, aggiornare e estendere. Soluzione Proposta La soluzione prevede l'utilizzo esclusivo di prodotti Open Source, che sono stati opportunamente modificati e integrati dal gruppo di Cooperazione Applicativa di CRS4-CSR. In particolare, si è scelto di integrare il motore japs (Java Agile Portal System) che funge da infrastruttura di integrazione con OpenSPCoop, e di adottare JOSSO come soluzione per il Single Sign On (SSO). La soluzione, sviluppata in ambiente Eclipse, fa uso di un Lightweight Directory Access Protocol (OpenLDAP), di un registro UDDI (JUDDI), di opportuni application server (TOMCAT e Jboss) e di un DBMS (PostgreSQL) 4. IL PROCESSO DI INTEGRAZIONE In questa Sezione sono descritte le fasi principali seguite durante il processo di integrazione. Prima di tutto sono stati individuati i componenti architetturali. Per ogni componente sono state valutate le alternative messe a disposizione dalla comunità OS al fine di individuare quella che soddisfacesse meglio le esigenze progettuali (ad esempio, sono stati privilegiate soluzioni OS che utilizzino tecnologie comuni, in modo da semplificare l'intero processo). In parallelo, sono state confrontate le licenze relative ai vari sistemi presi in considerazione. Una volta individuati, i singoli moduli sono stati studiati ed analizzati per mettere a punto le modalità di integrazione. In particolare, si è cercato di minimizzare le modifiche da apportare al codice sorgente di ogni modulo e contemporaneamente di mantenere i moduli disaccoppiati, tenendo presente che uno degli obiettivi è sviluppare una piattaforma semplice da modificare, aggiornare ed estendere. Alcuni di questi aspetti meritano ulteriori approfondimenti, per cui saranno trattati in dettaglio nelle Sezioni successive. Licenze Il primo passo da eseguire per integrare software proveniente dalla comunità OS è leggere le licenze. Il panorama di tali licenze è ampio, e non mancano i tentativi di categorizzarle in base alle loro caratteristiche. Per esempio, Masashi Ueda e Suematsu [6] hanno identificato ben 107 differenti licenze, suddivise in tre categorie principali. Come è noto, le principali organizzazioni che si occupano di promuovere il software OS sono la Open Source Initiative (OSI) 5 e la Free Software Foundation (FSF) 6. La prima ha definito ufficialmente il termine OS nel 1998, affermando che una licenza è conforme alla Open Source Definition se rispetta 10 criteri fondamentali, mentre la seconda classifica le licenze in base ai concetti di Free Software, copyleft, e in base alla compatibilità con la licenza GPL. Il dibattito sui due diversi sistemi di classificazione e certificazione esula dallo scopo di questo articolo, ma è importante sottolineare che i prodotti utilizzati per realizzare il sistema qui presentato sono tutti rilasciati sotto licenze certificate OSI o, alternativamente, sono per lo meno free software - compliant in base alla classificazione FSF. La tabella 1 riporta l'elenco completo dei prodotti che compongono l'architettura e le relative classificazioni OSI e FSF. Tabella 1. Licenze dei software OS utilizzate nel progetto. Certificazione OSI e classificazione FSF. Certificaz. Classificaz. Software Licenza OSI FSF Japs GPL SI GPL OpenSPCoop GPL SI GPL Josso BSD SI GPL PostgreSQL OpenLDAP JUDDI Tomcat Jboss Application Server BSD original OpenLDAP Public License 2.8 Apache License 2.0 Apache License 2.0 SI NO SI SI Free GPL Free Free LGPL SI GPL Componenti Software Inizialmente sono stati selezionati i componenti necessari alla realizzazione dell'infrastruttura software per la gestione e il monitoraggio della Cooperazione Applicata regionale. A tal proposito, è stata utilizzata la piattaforma OpenSPCoop, un progetto che mira a realizzare un'implementazione OS di tutti i componenti della specifica SPCoop v. 1.1 e a costruire attorno allo stesso progetto un'ampia comunità di utenti e sviluppatori esperti della specifica. La prima versione di OpenSPCoop è stata rilasciata il 27 Ottobre 2005, e la versione attuale è la 0.9b1, che fornisce l'implementazione completa della porta di dominio, del registro dei servizi e delle rispettive interfacce di amministrazione. OpenSPCoop è sviluppato 4 Per maggiori informazioni relative ai software open source citati si rimanda ai rispettivi siti web, e alla documentazione ufficiale di ognuno di essi. 5 Per maggiori informazioni consultare il sito internet: http://www.opensource.org/. 6 Per maggiori informazioni consultare il sito internet:http://www.fsf.org/.
utilizzando la seguente piattaforma OS: JBOSS, Axis, Juddi e WSS4J. Le interfacce di amministrazione sono delle applicazioni web, sviluppate utilizzando il framework Struts. Il registro dei servizi è implementato tramite un server JUDDI e un repository web. JUDDI è una implementazione Java della specifica UDDI (Universal Description, Discovery, and Integration) per i Web Services, e la scelta di tale tecnologia segue le indicazioni fornite dal CNIPA. JUDDI fornisce la funzionalità di indicizzazione delle informazioni contenute fisicamente nel repository web. La persistenza dei dati è invece affidata al DBMS PostgreSQL. PostgreSql è un progetto open source, nato nel 1996 con l'intento di creare un database enterprise-oriented, robusto e flessibile, sfruttando i noti vantaggi della pubblicità del codice sorgente, della gratuità dello stesso e di una grossa base di sviluppo. PostgreSQL è un database molto robusto e bene implementato, adatto alla gestione di grossi volumi di transazioni. La completa interfacciabilità e la logica di pulizia della base dati lo rendono decisamente consigliabile anche in contesti enterprise [3]. Per quanto riguarda la piattaforma di integrazione dei servizi di Cooperazione Applicativa si è scelto di utilizzare japs (Java Agile Portal System), un framework java basato su standard aperti, flessibile e modulare. Il framework offre inoltre un servizio di gestione dei contenuti (Content Management System) e consente la realizzazione di portali accessibili 7. Il framework japs è stato rilasciato sotto licenza GPL su SourgeForge. E' importante sottolineare che japs e OpenSPCoop condividono diverse tecnologie: dal database PostgreSQL al linguaggio di programmazione JAVA sino al framework Struts per l'implementazione delle interfaccie di amministrazione. In uno scenario come quello descritto è necessario garantire l'accesso ai servizi e alle applicazioni da un unico punto di accesso centralizzato. Per questo motivo si è deciso di integrare anche una modalità di autenticazione Single Sign On (SSO), realizzata utilizzando JOSSO (Java Open Single Sign-On). La scelta di JOSSO è stata dettata dalla sua aderenza a standard utilizzati all'interno del progetto. JOSSO è basato su J2EE e su JAAS (Java Authentication and Authorization Service) che centralizza la gestione dell'autenticazione degli utenti. Utilizza web services implementati tramite Axis e le interfacce grafiche sono scritte con Struts. JOSSO necessita di una Directory per memorizzare le informazioni relative ad utenti e ruoli, per cui è previsto il supporto del protocollo Lightweight Directory Access Protocol (LDAP). Come contenitore dei dati degli utenti (identity store) è stato scelto OpenLDAP, implementazione OS del protocollo LDAP, già testato con JOSSO. Gli application server utilizzati sono Tomcat, un JSP / Servlet Engine OS scritto interamente in Java, e JBOSS che è il più utilizzato application server Java a livello mondiale. A questo proposito è importante sottolineare che l'application server su cui si appoggia japs è Tomcat, mentre OpenSPCoop utilizza JBoss. Per ottenere una piattaforma unica si è deciso di avvalersi del solo application server Jboss, e quindi di migrare japs su quest'ultimo. L'integrazione dei diversi componenti è stata effettuata utilizzando Eclipse, IDE OS orientato alla massima espandibilità tramite il meccanismo dei plug-in. Architettura In questa sezione sarà descritta brevemente l'architettura software del sistema, in modo da fornire una visione d'insieme del progetto. La Figura 1 mostra i pricipali componenti della soluzione. In particolare, japs portal Engine funge da bus di integrazione dei servizi. Da notare che attualmente il Gestore degli Eventi non fa parte della soluzione, in quanto non è ancora stato rilasciato dalla community di OpenSPCoop. Figura 1: Servizi erogati e bus di integrazione. La Figura 2 mostra in dettaglio i componenti dell'architettura e ne evidenzia il flusso principale delle informazioni. Figura 2: Elementi Architetturali della soluzione. 7 Legge 9 gennaio 2004, n. 4 pubblicata in G.U. n. 13 del 17 gennaio 2004.
I componenti principali sono la piattaforma OpenSPCoop (che comprende sia la porta di dominio dei servizi applicativi che il registro dei servizi) e il sistema di gestione dei contenuti japs. Entrambi i sistemi si appoggiano su database PostgreSQL. Lo strato chiamato japs portal Engine gioca il ruolo di motore integratore dei servizi applicativi (CMS, Consolle di gestione SPCoop etc.), ed è quindi il cuore dell'architettura implementata. La Figura 2 mette inoltre in evidenza le tre diverse interfacce grafiche: le due di amministrazione della PdD e del Registro dei Servizi e quella del CMS. Ognuna delle tre interfacce grafiche si appoggia ad un meccanismo dedicato per l'autenticazione e l'autorizzazione degli utenti. Lo strato superiore dell'architettura garantisce la fruizione dei servizi da un unico punto di accesso realizzato utilizzando JOSSO. L'architettura generale è completata da un contenitore dei dati degli utenti basato su protocollo LDAP, ed in particolare sulla implementazione OS OpenLDAP. Pratiche di Sviluppo Nella realizzazione del progetto SAR-SPCoop non esistono dei requisti formali, essendo questi ultimi tutt'altro che stabili in quanto dipendenti da numerosi fattori tra cui l'evoluzione delle specifiche SPCoop e degli standard. Uno scenario di questo tipo, si sposa perfettamente con una metodologia di sviluppo di tipo Agile. In particolare, sono state adottate alcune pratiche di sviluppo che fanno parte di Scrum ed Extreme Programming (XP) [1], [2] tra cui: testing automatico, integrazione continua, programmazione a coppie, codice condiviso e progetto incrementale. Il testing del sistema prevede anche una fase per la verifica della corretta interazione tra i domini di Cooperazione Applicativa regionale, test che saranno eseguiti man mano che le implementazioni delle porte di dominio dei progetti regionali saranno date in carico a CRS4-CSR. La documentazione prodotta è quella strettamente necessaria al corretto svolgimento del progetto. A tale scopo si utilizza un wiki che viene aggiornato in continuazione e contemporaneamente allo sviluppo del sistema. DISCUSSIONE La realizzazione del progetto descritto nelle Sezioni precedenti permette di esprimere alcune considerazioni sull'utilizzo di componenti OS per l'implementazione di soluzioni software integrate. Queste considerazioni valgono sia nel contesto della pubblica amministrazione che in quello costituito dai soggetti privati. E' importante sottolineare che la scelta di software OS dovrebbe essere guidata dalla disponibilità o meno di componenti sufficientemente maturi. La letteratura recente ha proposto alcune metodologie per valutare la maturità del software OS, ma non esiste ancora una metodologia standard e ufficialmente riconosciuta. Per la realizzazione del progetto presentato in questo articolo non sono stati utilizzati criteri di selezione strettamente legati alla maturità intesa come stato ed età del software. Infatti, sia japs che OpenSPCoop sono progetti molto giovani, ed OpenSPCoop non è ancora giunto alla versione 1.0. D'altra parte OpenSPCoop rappresenta l'unica implementazione OS delle specifiche SPCoop, e japs è un progetto che nonostante la giovane età vanta già diversi casi di successo ed è in forte crescita. Sono stati invece utilizzati criteri basati sulla valutazione dell'interoperabilità e sulla possibilità di integrare ogni componente con altri sistemi. Tutto questo senza trascurare che ogni componente deve assolvere un ruolo specifico all'interno dell'architettura, e quindi deve implementare alcune funzionalità specifiche. I criteri di valutazione possono quindi essere formalizzati come segue: Funzionalità - Ogni componente deve implementare i requisiti tipici della categoria di prodotto a cui appartiene, o comunque prevedere l'integrazione con sistemi che implementano i requisiti mancanti; Architettura - L'architettura deve essere chiara, in modo da semplificare il processo di integrazione; Standard e Tecnologie - Devono essere largamente utilizzati standard aperti e tecnologie condivise; Attività - Bisogna privilegiare progetti in forte crescita, e che siano già stati utilizzati con successo; Feedback - In caso di necessità la comunità deve essere capace di fornire un rapido ed efficace supporto. E' importante sottolineare che il fattore che più di altri ha determinato la scelta di un'applicazione piuttosto che di un'altra è stato l'adozione di standard, ufficiali o de-facto, e di tecnologie condivise. Questa è infatti una condizione necessaria per garantire l'interoperabilità tra sistemi diversi a tutti i livelli. L'utilizzo di una soluzione completamente OS ha ovviamente permesso il risparmio dei costi delle licenze, e inoltre è stato possibile realizzare un'architettura complessa in poche settimane-uomo. E' difficile ipotizzare che si potesse ottenere una soluzione a costi inferiori attraverso software proprietario o, alternativamente, attraverso una soluzione ad-hoc sviluppata interamente. L'esperienza accumulata durante il progetto ha consentito al team coinvolto nello sviluppo di approfondire le proprie competenze sulle tematiche via
via affrontate, sia sul dominio del problema che dal punto di vista strettamente tecnologico. Una delle sfide aperte è riuscire a gestire l'evoluzione dei singoli componenti software. Infatti, utilizzare componenti in forte sviluppo significa che, presumibilmente, saranno spesso disponibili nuove versioni dei diversi pacchetti. E' stata dunque prestata particolare attenzione all'individuazione dei moduli software da modificare, cercando di massimizzare il disaccoppiamento tra i vari sistemi, onde evitare di dover ogni volta integrare da zero le nuove versioni, con un lavoro ripetitivo che mira al solo ripristino di funzionalità consolidate. CONCLUSIONI In questo articolo è stato descritto un caso pratico di integrazione di componenti software per la gestione e il monitoraggio della Cooperazione Applicativa regionale, visto come un insieme di servizi erogati attraverso un bus di integrazione. Sono state utilizzate applicazioni esclusivamente Open Source, e sono state privilegiate quelle che fanno ampio utilizzo di standard aperti e tecnologie condivise. In questo modo è stata sviluppata in brevissimo tempo e con costi limitati una soluzione completa, flessibile e modulare, che può essere velocemente estesa e aggiornata per rispondere alle esigenze future. Inoltre, tale soluzione ha permesso di incrementare il know-how del team coinvolto nel progetto, sia sul dominio del problema che sulle tecnologie adottate. La soluzione è attualmente in fase di test, e tra i lavori futuri è previsto, ovviamente, il rilascio in Open Source del sistema sviluppato. RIFERIMENTI BIBLIOGRAFICI [1] Beck, K. Extreme Programming Explained. Embrace Change. Addison-Wesley, Reading, MA. 1999. [2] Beck, K. and Andres, C. Extreme Programming Explained: Embrace Change - Second Edition. Addison-Wesley, 2004. [3] CNIPA. Rapporto conclusivo Gruppo di lavoro Codice sorgente aperto ( Open Source ). URL: http://www.cnipa.gov.it/site/_files/rapporto%20co nclusivo_oss.pdf [4] CNIPA. Sistema pubblico di cooperazione: Organizzazione. URL: http://www.cnipa.gov.it/site/it-it/ [5] Fuggetta A. Open source software - an evaluation. Journal of Systems and Software, 66, 1 (2003), 77-90. [6] Masashi Ueda, T. U. and Suematsu, C. A cluster analysis of open source licenses. In Proceedings of the 1st International Conference on Open Source Systems (OSS 2005) (Genoa, Italy, 2005), 50 53.