"Licenze Open Source e Pubblica Amministrazione Approcci e casi d'uso"

1. Licenze Open Source e Pubblica Amministrazione
Approcci e casi d'uso
Sebastiano Lomuscio
Roma, 27 Settembre 2010

2. 2
Il contesto attuale: Open Source nella pa
Le licenze più diffuse
Il sourcing
Casi d'uso
Agenda

3. 3
Forte spinta all'automazione dei processi amministrativi ed alla diffusione
delle informazioni
Riduzione della disponibilità di budget per IT ( investimenti in IT della PA
-4,3% rapporto Assinform 2010),
Disponibilità “culturale” ad esaminare l'adozione di componenti open source
Disponibilità sul mercato del know how necessario ad operare con soluzioni
“Open”
Larghissima disponibilità di prodotti “Open” maturi
Buona disponibilità di fornitori di “manutenzione base” di pacchetti Open
(Red Hat, Novell, Ubuntu, Oracle (mysql ?) )
Normativa favorevole all'adozione di soluzioni Open (Direttiva del 19
dicembre 2003, legge n. 296 del 23 dicembre 2006, codice
dell'amministrazione digitale del marzo 2005 )
Largo numero di progetti positivamente completati in ambito PA locale
Progetto Trio della regione Toscana,
progetto SIPA della regione Puglia
Contesto: Open source nella PA

4. 4
La differente collocazione delle componenti Open nelle infrastrutture IT, le differenti
licenze applicabili e la disponibilità di player nel mercato del “supporto” impongono
l'adozione di approcci differenziati che vanno dalla Fruizione alla Collaborazione
OS da adottare in
piattaforme di gestione
sistemi e reti
1
AsisChange
2
OS di informatica individuale
(Browser, Posta elettronica,
strumenti Office)
OS orientato all’utente IT
professional (back office
tool)
4
OS da integrare in soluzioni
applicativo/gestionali per
l’utente business
3
Contesto: segmentazione e adozione
SEMPLICE
FRUIZIONE
PARTE ATTIVA
COMMUNITY OS
RIUSO
Pubblicato
Riservato
Condivisione
-
Personalizzazione
Change
Integrazione
Adottato
AS
IS
1
2
3
4
Adottato
da
altri

5. 5
GPL V2 (es. linux, moodle, cvs)
la GPL è classificabile come "persistente" e "propagativa"
La modifica di una parte del codice comporta l'acquisizione della
medesima licenza.
Posso modificare e tenere per me la modifica ma se la distribuisco ad
altri, questa deve essere accompagnata dai sorgenti
es. codice realizzato con librerie staticamente linkate e coperte da
licenza GPL non può divenire closed source
L'autore della modifica ne rimane proprietario ma non può sottrarsi dal
rispetto della licenza che si propaga al suo lavoro derivato
La GPL non è in contrasto con la normativa sul diritto d'autore: la
proprietà intellettuale dell'opera rimane all'autore, il quale cede i
diritti di copia, diffusione, modifica, sfruttamento economico ecc.
Il rispetto “etico” della GPL comporta per le organizzazioni la
necessità di rapportarsi attivamente con la community
contribuendo al miglioramento del software
Le licenze più adottate: GPL

6. 6
LGPL (es. openCMS )
la LGPL è classificabile come "persistente" e "parzialmente propagativa"
è pressoché identica alla GPL tradizionale tranne nel vincolo relativo al
limite di utilizzo di librerie statiche all'interno di applicazioni non-open
es. codice realizzato con librerie staticamente linkate e coperte da
licenza LGPL può divenire closed source
La modifica di una parte del codice coperto da LGPL continua ad essere
coperta da LGPL.
Posso quindi realizzare moduli aggiuntivi che richiamano (includendo)
parti del codice coperto da LGPL estendendone le funzioni e
mantenerne la proprietà.
Non sono tenuto a distribuire il mio codice sorgente nel caso di
cessione ad altre organizzazioni.
Non sono “eticamente” obbligato a collaborare con la community
se non modifico il core del prodotto
Le licenze più adottate: LGPL

7. 7
Apache (es. apache, maven, etc )
Compatibile con la GPL V3 e non la GPL V2
Legata al framework di prodotti del webserver apache
Php
Simile alla LGPL
MySql
Licenca GPL per progetti Open
licenza commerciale per uso Enterprise o inclusione in prodotti chiusi
Mozilla Public License (es Firefox)
È una licenza con un debole approccio copyleft (codice sorgente o parti
possono essere incluse in prodotti “closed”)
Non è compatibile con la GPL
BSD
È una licenza che prevede la clausola pubblicitaria (software sviluppato
dai laboratory berkeley...) come vincolo.
Il codice puo' essere incluso in prodotti closed
Non è compatibile con la GPL
Le licenze verticali

8. 8
Il sourcing
L'adozione di un componente open in una PA che normalmente si affida al
mercato per gli sviluppi del suo patrimonio IT comporta interventi sulla
documentazione di gara:
è possibile indicare esplicitamente il prodotto adottato: l'adozione di una
licenza Open non comporta distorsione del mercato.
Deve essere prestata attenzione alle eventuali incompatibilità tra licenze
e mandato ricevuto dall'amministrazione.
E' necessario individuare le modalità di supporto su tutte le componenti
adottate.
Vanno disciplinate le modalità di interazione con la community.
È importante delineare i livelli di servizio attesi sulle varie componenti
(sviluppi ad hoc, evoluzioni di moduli core di prodotti OS, etc)
Vanno individuate le professionalità più adeguate ad operare in questo
contesto.
E' strategico delineare un servizio di verifica e certificazione delle nuove
versioni rilasciate nella community prima della loro adozione.

9. 9
OSat0OSat0
OSatxOSatx
Aggiornamenti svolti dal Fornitore
OSat0-txOSat0-tx
Il componente OSa (modulo “core”) viene adottato AS IS o è integrato ad altre
componenti open tramite applicazioni indipendenti e sviluppate ad-hoc;
il fornitore garantisce nel tempo l'adeguamento dell'applicazione alle evoluzioni
del “core” prelevandole dalla community
Ilfornitore si limita alla segnalazione di eventuali bug alla community
Non vi sono problemi di compatibilità tra le licenze adottate: mi limito all'uso
CommunityApplicazione
Consip negli ultimi quattro anni ha sviluppato diverse soluzioni basate su OS
Scenari di sourcing: modello utilitaristico

10. 10
OSbt0OSbt0
OSbtxOSbtx
OSbt0OSbt0
OSbtxOSbtx
P1P1 P2P2
Adozione totale del paradigma OS: il “core” OSb viene personalizzato (P1 e P2) e reimmesso nella
Community (versione OSb v.1). Il Fornitore deve garantire l’allineamento verso MEF/Consip e
verso la Community.
Il riversamento delle modifiche alla community supera il mero rispetto della licenza d'uso ed è
finalizzato a garantire continuità di servizio, economicità di gestione ed evoluzione tecnologica
Aggiornamenti svolti dal Fornitore
Community
OSb v.1
Applicazione Osb v.1
Scenari di sourcing: modello aperto

11. 11
OSdto txOSdto tx
Aggiornamenti svolti dal Fornitore
OSdt0 txOSdt0 tx
Aggiornamenti svolti per conto di
Consip/MEF
C1C1 C2C2
OSdtxOSdtx
C1C1 C2C2
Il componente OSc (modulo “core”) viene adottato AS IS. Vengono sviluppate le componenti
esterne C1 e C2 di proprietà del MEF che svolgono funzioni addizionali rispetto al “core” dando
origine all'applicazione OSc V.1.
I moduli C1 e C2 possono essere distribuiti alla Community PA nel pieno spirito della condivisione
e del riuso.
In tale modalità Consip ha già realizzato una piattaforma di Content Management System che si
avvale del software OpenCMS, opportunamente integrato con componenti sviluppate per conto del
MEF: OpenCMSP@
Applicazione OSd v1 Community PA
Community
OSdtxOSdtx
Scenari di sourcing: modello misto (1)

12. 12
OSct0OSct0
Aggiornamenti svolti dal Fornitore
OSct0OSct0
Rilascio da parte del Fornitore di
sviluppi svolti per conto di
Consip/MEF
OSc V.1
Community
Il componente OSc (modulo “core”) viene adottato ed evoluto nella sua componente P1.
Vengono inoltre sviluppate le componenti esterne C1 e C2 di proprietà del MEF che svolgono
funzioni addizionali rispetto al “core” dando origine all'applicazione OSc V.1.
P1 viene rilasciato in community all'atto della distribuzione in accordo alla licenza d'uso
C1 o C2 (in quanto non assoggettati alla licenza di P1) possono essere rilasciati ad una community
più ristretta (es. La community delle PA) o essere rilasciate in analogia al modulo P1
Applicazione Osc V.1
C1C1 C2C2
OSctxOSctx
Scenari di sourcing: modello misto
P1P1

13. 13
Il MEF dispone di una piattaforma di versioning, build e deploy del
software sviluppato per le proprie applicazioni basata sulla integrazione
di diversi prodotti open source (CVS, PHP, Apache, maven, viewcvs,
cvsmonitor).
Il fornitore:
Non modifica in alcun modo le componenti Open impiegate nel
sistema
manutiene la componente applicativa di integrazione sviluppata ad
hoc garantendo il rispetto dei livelli di servizio contrattualizzati.
Sorveglia la community prelevando le nuove versioni dei prodotti di
base
Fornisce un supporto di primo livello per le anomalie sulle componenti
open interagendo con la community per la ricerca di eventuali
soluzioni e/o workaround.
Segnala i bug eventualmente rilevati nei prodotti
Casi d'uso: il sistema CMA

14. 14
Il MEF dispone di un portale documentale dedicato alla gestione dei
documenti tecnici di fornitura. Il motore documentale, basato sul prodotto
Open OWL Intranet engine, è stato oggetto di diverse modifiche ed
adattamenti alle necessità del MEF.
Consip:
Ha iscritto in community alcune sue risorse interne (come singoli
autorizzati) al fine di interagire con la community.
Ha dato mandato al fornitore di riversare in community le modifiche
operate su OWL.
Ha ottenuto dalla community l'approvazione delle modifiche e la loro
integrazione nel ramo di sviluppo.
Suggerisce alla community le possibili linee evolutive del prodotto
Collabora anche con un contributo economico alle evoluzioni di OWL,
rapportandosi direttamente con gli sviluppatori più attivi.
Il Fornitore:
Manutiene OWL garantendo al MEF i livelli di servizio concordati.
Casi d'uso: il portale documentale

15. 15
Il MEF dispone di una piattaforma di e-learning basata su un prodotto
proprietario non più adeguato alle esigenze di formazione.
Dopo una attenta fase di studio e di confronto la scelta è caduta su
Moodle, uno dei prodotti Open Source più diffusi al mondo per e-learning
su licenza GPL V2
L'adozione di Moodle ha comportato la definizione di vincoli “nuovi” in
sede di capitolato di gara:
Obbligando il fornitore ad aderire agli standard di programmazione
della community
Iscrivendo il personale addetto alla community e partecipando
attivamente ad essa per la segnalazione di bug o per il riversamento
dei moduli core modificati
Riservando al MEF la possibilità, per i nuovi moduli sviluppati, di
dare mandato al fornitore di effettuarne il riversamento nella
community.
Casi d'uso: il sistema di e-learning

16. 16
Il MEF ha adottato il prodotto OpenCMS per la realizzazione e gestione di
tutti i Siti Internet DT, DAG, G8 Finance, OCSE, SPT, Corte dei conti,
Dipartimento Politiche di Sviluppo, Consip, DIPE, Portale Acquisti in rete e
Intranet della Corte dei conti.
La necessità di adattare il CMS alle esigenze dell'amministrazione ha
portato allo sviluppo di moduli autonomi che interagiscono con OpenCMS.
L'intera soluzione è ad oggi oggetto di riuso da parte della Corte dei conti
comportandone quindi il riuso. Il modello di sourcing “misto” consente di:
Distribuire i soli moduli sviluppati ad hoc ad altre amministrazioni
Rendere possibile la creazione di una vera e propria community della
PA ove promuovere il “riuso” di tale soluzione.
Divenire catalizzatore di una più ampia collaborazione tra le
amministrazioni, finalizzata al miglioramento continuo della
soluzione.
Casi d'uso: OpenCMS

17. 17
SEBASTIANO LOMUSCIO
Direzione Infrastrutture IT – System Solutions
Mobile 3294106310 sebastiano.lomuscio@tesoro.it
RENZO FLAMINI
Direttore Infrastrutture IT – Focal point Consip sull'OS
Mobile 3280410934 renzo.flamini@tesoro.it
MARIA STELLA MAROTTA
Direzione Infrastrutture IT – Tecnologie e Innovazione e Centro di competenza OS
Mobile 3294106344 mariastella.marotta@tesoro.it
EMILIA OCCHIUTO
Direzione Sistemi Informativi – Responsabile Soluzioni e piattaforme Web (OPENCMSP@)
Mobile 3293807959 emilia.occhiuto@tesoro.it
Riferimenti