Navigando nel sito di Forum PA ho trovato un altro convegno su un argomento che è di grande interesse per il nostro corso: Tra cooperazione e competizione: la sintesi necessaria per la diffusione dell’open source, a cura di Roberto Galoppini, esperto in materia (dal sito Forum PA)
In informatica, open source (termine inglese che significa sorgente aperto) indica un software rilasciato con un tipo di licenza per la quale il codice sorgente è lasciato alla disponibilità di eventuali sviluppatori, in modo che con la collaborazione (in genere libera e spontanea) il prodotto finale possa raggiungere una complessità maggiore di quanto potrebbe ottenere un singolo gruppo di programmazione. L’open source ha ovviamente tratto grande beneficio da Internet. Alla filosofia del movimento Open Source si ispira il movimento Open content: in questo caso ad essere liberamente disponibile non è il codice sorgente di un programma ma contenuti editoriali quali testi, immagini, video e musica. In tempi recenti, attualmente, l’Open Source tende ad assumere rilievo filosofico, consistendo in una nuova concezione della vita, aperta e refrattaria ad ogni oscurantismo, che l’Open Source si propone di superare mediante la condivisione della conoscenza
La condivisione del codice fino agli anni Settanta
A partire dagli anni Cinquanta, e soprattutto negli anni Sessanta, è stato possibile riusare lo stesso codice e distribuirlo anche se in modo oggi ritenuto piuttosto artigianale, ovvero con nastri e schede perforate. Questo fenomeno diventò evidente soprattutto quando si affermò il vantaggio di usare una stessa porzione di codice, il che presupponeva di avere macchine uguali e problemi simili. Fino a tutti gli anni Settanta, anche se in misura decrescente, la componente principale e costosa di un computer era l’hardware, il quale era comunque inutile in assenza di software. Da ciò la scelta dei produttori di hardware di vendere il loro prodotto accompagnato da più software possibile e di facilitarne la diffusione, fenomeno che rendeva più utili le loro macchine e dunque più concorrenziali. Il software, tra l’altro, non poteva avvantaggiare la concorrenza in quanto funzionava solo su un preciso tipo di computer e non su altri, neanche dello stesso produttore. L’introduzione dei sistemi operativi rese i programmi sempre più portabili, in quanto lo stesso sistema operativo veniva offerto dal produttore di diversi modelli di hardware.
La presenza di sistemi operativi funzionanti per macchine di differenti produttori hardware ampliava ulteriormente le possibilità di usare lo stesso codice in modo relativamente indipendente dall’hardware usato. Uno di questi sistemi operativi era Unix, iniziato nel 1969 come progetto all’interno di un’impresa delle telecomunicazioni, la AT&T. Una famosa causa antitrust contro la AT&T le vietò di entrare nel settore dell’informatica. Questo fece sì che Unix venisse distribuito ad un prezzo simbolico a buona parte delle istituzioni universitarie, le quali si ritrovarono ad avere una piattaforma comune, ma senza alcun supporto da parte del produttore. Si creò spontaneamente una rete di collaborazioni attorno al codice di questo sistema operativo, coordinata dall’Università di Berkeley, da dove sarebbe poi uscita la versione BSD di Unix, che diventa da un lato un centro di sviluppo ed innovazione, dall’altro è la base di partenza per numerosi fork.
La nascita del software proprietario
Considerato che la condivisione del codice è nata insieme all’informatica, piuttosto che di origini dell’Open Source potrebbe essere più appropriato parlare, invece, di origine del software proprietario, ed esaminare il contesto storico in cui questa origine ha avuto luogo. L’utilità principale delle licenze restrittive consiste nella possibilità di rivendere un programma più volte, se necessario con alcune modifiche purché non rilevanti. Questo presuppone che esistano clienti diversi con esigenze simili, oltre che l’esistenza di più computer sul quale poter far eseguire il programma. Queste condizioni cominciano a determinarsi negli anni Sessanta, grazie al fatto che esisteva un maggior numero di utilizzatori con esigenze standardizzabili come lo erano quelle delle organizzazioni economiche nell’area della contabilità, la logistica o delle statistiche. L’introduzione dei sistemi operativi rese inoltre possibile l’utilizzo dello stesso programma anche su hardware differente aumentando così le possibilità di riutilizzo dello stesso codice e dunque l’utilità nell’impedire la duplicazione non autorizzata dei programmi. La suddivisione della AT&T in 26 società, le cosiddette BabyBell, permise alla AT&T di usare logiche prettamente commerciali nella distribuzione del suo sistema operativo UNIX, innalzando notevolmente i costi delle licenze e impedendo la pratica delle patch. Il 1982 fu anche l’anno della divisione delle diverse versioni commerciali di Unix, portate avanti dai singoli produttori di hardware. Questi ultimi, effettuando delle piccole modifiche alla propria versione del sistema operativo, impedirono ai propri utenti l’utilizzo di altri sistemi, facendo in modo che i programmi scritti per la propria versione di Unix non funzionassero su versioni concorrenti.
Gli anni Ottanta: Stallman, la Free Software Foundation e l’innovazione dei PC
Al MIT la sostituzione dei computer fece sì che i programmatori - fra i quali Richard Stallman che sarebbe diventato il portabandiera del free software - non potessero accedere al sorgente del nuovo driver di una stampante Xerox per implementarvi una funzionalità gradita in passato: la segnalazione automatica che vi erano problemi con la carta inceppata. Contemporaneamente, società private cominciarono ad assumere diversi programmatori del MIT, e si diffuse la pratica di non rendere disponibili i sorgenti dei programmi firmando accordi di non divulgazione (in inglese: NDA, ovvero Non-Disclosure Agreement). In questo contesto Stallman si rifiutò di lavorare per una società privata e fondò nel 1985 la Free Software Foundation (FSF), una organizzazione senza fini di lucro per lo sviluppo e la distribuzione di software libero. In particolare lo sviluppo di un sistema operativo completo, compatibile con UNIX, ma distribuito con una licenza permissiva, con tutti gli strumenti necessari altrettanto liberi. Si tratta del progetto nato l’anno precedente, ovvero GNU, acronimo ricorsivo per contemporaneamente collegarsi e distinguersi da UNIX, ovvero “GNU’s Not UNIX”. «L’obiettivo principale di GNU era essere software libero. Anche se GNU non avesse avuto alcun vantaggio tecnico su UNIX, avrebbe avuto sia un vantaggio sociale, permettendo agli utenti di cooperare, sia un vantaggio etico, rispettando la loro libertà.» Tale progetto, finanziato dalla FSF, venne pertanto prodotto da programmatori appositamente stipendiati. I principali contributi vennero da Stallman stesso: il compilatore gcc e l’editor di testo Emacs. Furono sviluppate anche altre componenti di sistema UNIX, alle quali si sono aggiunte applicazioni per veri e propri giochi. Questi programmi furono distribuiti per circa 150$ che oltre a coprire i costi di riproduzione garantivano un servizio di supporto al cliente.
L’unica condizione era che tutte le modifiche eventualmente effettuate su tali programmi venissero notificate agli sviluppatori. Nacque così la GNU General Public License (GPL), il preambolo del cui manifesto comincia con: « Le licenze per la maggioranza dei programmi hanno lo scopo di togliere all’utente la libertà di condividerlo e di modificarlo. Al contrario, la GPL è intesa a garantire la libertà di condividere e modificare il free software, al fine di assicurare che i programmi siano “liberi” per tutti i loro utenti. » Gli anni Ottanta sono caratterizzati da alcuni eventi importanti, tra i quali l’introduzione nel mercato di quello che verrà chiamato Personal Computer (PC), ovvero un elaboratore con un proprio processore concepito per essere utilizzato da un solo utente alla volta. Il prodotto di maggior successo, il PC della IBM, si differenziava dai progetti precedenti in quanto non utilizzava componenti IBM, ma sia per il software che per l’hardware si affidava alla produzione da parte di terzi. Ciò rese possibile da un lato ad altre imprese di clonare il PC IBM, abbattendone notevolmente i costi, dall’altro permise a parecchie società di produrre dei software applicativi standard, in concorrenza gli uni con gli altri, basandosi su un unico sistema operativo, anche se inizialmente i principali produttori di software erano identificabili con prodotti per specifiche applicazioni. Il notevole ampliamento del mercato rese possibili economie di scala e si instaurò una sorta di sinergia tra quelli che sarebbero diventati i principali attori del settore: il produttore dei processori Intel e il produttore del sistema operativo e di applicativi per ufficio Microsoft. La maggiore potenza dei processori rese possibile lo sviluppo di programmi più complessi, la maggiore complessità degli applicativi e del sistema operativo richiesero processori più potenti instaurando in un certo modo un circolo vizioso di aggiornamenti continui. Sia il sistema operativo che gli applicativi furono caratterizzati fin da subito dall’essere destinati ad utenti con conoscenze informatiche relativamente scarse e dall’avere licenze d’uso strettamente commerciali, vietando da un lato agli utenti di farne delle copie, dall’altro agli sviluppatori di vedere o modificare il codice. Sempre negli anni Ottanta vennero introdotte le workstation, ovvero un sistema basato su terminali (i client) e computer centrali (i server). Si tratta di sistemi derivati concettualmente dai mainframe e basati essenzialmente su sistemi operativi UNIX proprietari. L’hardware stesso varia sul lato server dai mainframe ai PC, mentre su lato client vengono impiegati soprattutto i PC. Ciò favorì lo sviluppo di software sia per i client, utilizzati spesso da persone con scarse conoscenze informatiche, che per i server, il cui funzionamento viene solitamente garantito da personale informatico particolarmente qualificato.
Gli anni Novanta: Internet, Linux e la Open Source Definition
Benché Internet avesse visto la luce già negli anni Settanta, è soltanto agli inizi degli anni Novanta, con la diffusione del protocollo HTTP e la nascita dei primi browser, che Internet cominciò ad essere diffuso prima in ambito accademico e poi in modo sempre più capillare anche tra semplici privati. All’inizio degli anni Novanta, il progetto GNU non aveva ancora raggiunto il suo obiettivo principale, mancando di completare il kernel del suo sistema operativo (HURD). Per sopperire a tale mancanza William e Lynne Jolitz riuscirono ad effettuare il porting di UNIX BSD su piattaforma Intel 386 nel 1991. Purtoppo negli anni successivi tale porting si trovò ad affrontare problemi di natura legale che ne ritardarono temporaneamente lo sviluppo, ma nello stesso anno, l’insoddisfazione riguardante alcuni applicativi di Minix, un sistema Unix su una piattaforma PC, il desiderio di approfondire le proprie conoscenze del processore Intel 386, scelto in quanto di minor costo e di maggiore diffusione rispetto alle piattaforme hardware per le quali erano disponibili sistemi operativi Unix, e l’entusiasmo per le caratteristiche tecniche di Unix stimolarono Linus Torvalds, studente al secondo anno di informatica presso l’Università di Helsinki, a sviluppare un proprio sistema operativo, imitando le funzionalità di Unix, su un PC con un processore Intel 386. Torvalds distribuì il proprio lavoro tramite Internet e ricevette immediatamente un ampio riscontro positivo da parte di altri programmatori, i quali apportarono nuove funzionalità e contribuirono a correggere errori riscontrati. Nacque così il kernel Linux, il quale fu distribuito fin da subito con una licenza liberale. Internet dal canto suo, rende possibile la comunicazione tra persone molto distanti in tempi rapidi e a basso costo. Inoltre rende possibile la distribuzione di software direttamente dalla rete, riducendo ulteriormente i costi di duplicazione e le difficoltà a reperire il software stesso.

La diffusione dei CD-Rom come supporto privilegiato di raccolte di software rese possibile il fenomeno delle cosiddette distribuzioni. Linux può essere considerato come il primo vero progetto “open source” cioè come il primo progetto che faceva affidamento essenzialmente sulla collaborazione via Internet per progredire; fino ad allora, infatti, anche i progetti di software libero come Emacs erano stati sviluppati in maniera centralizzata seguendo un progetto prestabilito da un ristretto numero di persone, in base cioè ai principi ’standard’ di ingegneria del software. Si assumeva valida anche per i progetti open source la ‘legge di Brooks’, secondo cui “aggiungere sviluppatori a un progetto in corso di implementazione in realtà rallenta il suo sviluppo”, legge che ovviamente non è applicabile a un progetto di sviluppo open source.
Agli inizi degli anni Novanta, l’idea delle licenze liberali era rappresentata soprattutto da Richard Stallman e la sua FSF, ovvero le licenze liberali per eccellenza erano la GPL e la LGPL che però venivano ritenute “contagiose”, in quanto a partire da un codice licenziato con la GPL qualsiasi ulteriore modifica deve avere la stessa licenza. Le idee stesse di Stallman venivano viste con sospetto dall’ambiente commerciale statunitense, il che non facilitava la diffusione del software libero. Per favorire dunque l’idea delle licenze liberali nel mondo degli affari, Bruce Perens, Eric S. Raymond, Ockman e altri cominciarono nel 1997 a pensare di creare una sorta di lobby a favore di una ridefinizione ideologica del software libero, evidenziandone cioè i vantaggi pratici per le aziende e coniarono il termine “Open Source”. Ciò anche al fine di evitare l’equivoco dovuto al doppio significato di free nella lingua inglese, visto che spesso veniva interpretato come “gratuito” invece che come “libero”. L’iniziativa venne portata avanti soprattutto da parte di Raymond che, in occasione della liberalizzazione del codice sorgente di Netscape, voleva utilizzare un tipo di licenza meno restrittivo per le aziende di quanto fosse il GPL. La scelta a favore dell’Open Source da parte di alcune importanti imprese del settore come la Netscape, l’IBM, la Sun Microsystems e l’HP, facilitarono inoltre l’accettazione del movimento Open Source presso l’industria del software, facendo uscire l’idea della “condivisione del codice” dalla cerchia ristretta nella quale era rimasta relegata fino ad allora. Venne cioè accettata l’idea che l’open source fosse una metodologia di produzione software efficace, nonostante nel suo famoso saggio La Cattedrale e il Bazaar, Eric S. Raymond avesse esplicitamente criticato i tradizionali metodi di ingegneria del software, metodi che fino a quel momento avevano dato buoni frutti. Va notato come i primi programmi ‘liberi’, come il GCC, seguivano ancora il modello a cattedrale; solo successivamente progetti come EGCS adottarono il modello a bazaar.
L’audizione alla Commissione Cultura della Camera italiana
Nel 2007 il tema dell’open source è stato portato autorevolmente presso il Parlamento italiano. La commissione cultura della Camera ha ascoltato, nella forma di una audizione, il prof. Arturo Di Corinto, il dott. Massimiliano Gambardella e Stefan Umit Uygur, unitamente a Richard Stallman e a Bruce Perens in una audizione ufficiale dalla commissione cultura della Camera dei deputati. Anche convegno Condividi la conoscenza ha tentato di allargare la base di adesione del mondo accademico sull’ open source e sull’Open content con l’obiettivo di fare ascoltare la propria voce anche dal mondo politico.
La Commissione per il software open source nella Pubblica Amministrazione
Sempre nel corso del 2007 presso il Ministero per le Riforme e le Innovazioni nella Pubblica Amministrazione è stata istituita la Commissione Nazionale per il software Open Source nella PA. Il Decreto Ministeriale istitutivo della Commissione (16 maggio 2007), a firma del Ministro Nicolais, ha definito tre obiettivi prioritari:
1) un’analisi dello scenario europeo ed italiano del settore;
2) la definizione di linee guida operative per supportare le Amministrazioni negli approvvigionamenti di software open source;
3) un’analisi dell’approccio open source per favorire cooperazione applicativa, interoperabilità e riuso.
I lavori della Commissione, presieduta dal prof. Meo, si sono svolti essenzialmente in modalita’ on line supportati dall’Osservatorio OSS del CNIPA. Si sono svolte anche attivita’ di audizione, in particolare la Commissione ha supportato l’organizzazione del Convegno Open Source Open Ideas for Public Administration - OSPA 2008 primo e unico momento in Italia di incontro e confronto tra PA, imprese e universita’. Nell’aprile 2008 la Commissione ha prodotto una prima bozza di Relazione.
Il Codice dell’Amministrazione digitale
Il Codice dell’Amministrazione digitale è stato emanato con Decreto legislativo del 7 marzo 2005, n. 82, pubblicato sulla G.U. n. 111 del 16 maggio 2005, a seguito della delega al Governo contenuta all’articolo 10 della legge 29 luglio 2003, n. 229 (Legge di semplificazione 2001). Il Codice è entrato in vigore il 1 gennaio 2006. Esso ha lo scopo di assicurare e regolare la disponibilità, la gestione, l’accesso, la trasmissione, la conservazione e la fruibilità dell’informazione in modalità digitale utilizzando con le modalità più appropriate le tecnologie dell’informazione e della comunicazione all’interno della pubblica amministrazione, nei rapporti tra amministrazione e privati. In alcuni limitati casi, disciplina anche l’uso del documento informatico nei documenti tra privati. Nel 2006, pochi mesi dopo l’entrata in vigore, il Codice è stato oggetto oggetto di una serie di correttivi, disposti con il decreto legislativo 4 aprile 2006, n. 159 la cui emanazione era stata autorizzata dalla medesima legge-delega n. 229 del 2003. Il decreto correttivo, oltre a modificare in diversi punti l’articolate del decreto 82/2005, traspone nel “corpus” del Codice l’intero testo già contenuto nel Decreto legislativo n. 42 del 2005 (contestualmente abrogato), disciplinante il Sistema Pubblico di Connettività e la Rete Internazionale delle Pubbliche Amministrazioni.
Il Codice dell’Amministrazione Digitale si compone oggi di 92 articoli, suddivisi in 9 capi intitolati rispettivamente:
• “Principi generali”,
• “Documento informatico e firme elettroniche; pagamenti, libri e scritture”,
• “Formazione, gestione e conservazione dei documenti informatici”,
• “Trasmissione informatica dei documenti”, “Dati delle pubbliche amministrazioni e servizi in rete”,
• “Sviluppo, acquisizione e riuso di sistemi informatici nelle pubbliche amministrazioni”,
• “Regole tecniche”,
• “Sistema pubblico di connettività e rete internazionale della pubblica amministrazione”,
•”Disposizioni transitorie finali ed abrogazioni”.
Si tratta in parte di disposizioni già presenti nella normativa previgente, talvolta riportate alla lettera, talvolta riprese con sostanziali modifiche, in parte di norme emanate ex novo in questa sede. Rientrano nella prima categoria, per esempio, le norme sulla firma digitale e sui certificatori (trasposte dal Testo Unico n. 445 del 2000, ove sono state abrogate). Sono da ascriversi invece alla seconda categoria, in particolare, le norme di principio sul diritto all’uso delle tecnologie nei rapporti con la pubblica amministrazione, e le disposizioni sui siti internet istituzionali. L’emanazione del Codice ha suscitato impressioni contrastanti presso gli osservatori e presso la dottrina giuridica. Da un lato, vi sono coloro che ne hanno accolto positivamente l’uscita, considerandolo un importante atto di riordino della materia. Dall’altro lato, una parte (non minoritaria) della dottrina, si è mostrata alquanto scettica sulla effettiva portata innovativa del decreto, per diverse ragioni. In primo luogo, perché - sostengono i critici - il codice conterrebbe numerose enunciazioni di principio, spesso piuttosto solenni, senza accompagnarle però con disposizioni operative che ne consentano la concreta attuazione. In secondo luogo, perché avrebbe scorporato un assetto normativo che già era organico: la disciplina del documento informatico, secondo tale opinione, trovava infatti la propria sede naturale nel “testo unico sulla documentazione amministrativa” (DPR 445/2000), dove l’atto elettronico era disciplinato contestualmente all’atto cartaceo in un regime di perfetta alternativa tra i due supporti. Infine, secondo la dottrina più scettica, con il “codice” sarebbe degenerato l’intento iniziale di usare l’informatica come strumento per la semplificazione amministrativa, facendo diventare la digitalizzazione un fine a sé stante, sottovalutando i rischi di un passaggio non sufficientemente graduale dal cartaceo all’elettronico, primo fra tutti l’acuirsi del digital divide fra cittadini dotati di confidenza con lo strumento informatico, e cittadini che per ragioni sociali o anagrafiche hanno difficoltà a rapportarsi telematicamente con l’amministrazione.
Legge finanziaria 2007: articolo 1, commi 892 e 895 (Interventi per la società dell’informazione e sostegno agli investimenti innovativi negli enti locali)
Il comma 892 stanzia, per il triennio che va dal 2007 al 2009, la spesa di 10 milioni di euro per ogni anno, vale a dire, 30 milioni di euro. Durante la discussione e l’approvazione del Disegno di Legge sulla Finanziaria per il 2007, il Senato della Repubblica ha modificato il comma 892 e ha introdotto i tre commi successivi al fine di promuovere investimenti specifici negli enti locali e di prevedere procedure concertate con gli organismi consultivi degli enti territoriali per la loro erogazione. L’
attuazione degli interventi in questione è demandata ad un decreto di natura non regolamentare del Ministro per le Riforme e le Innovazioni nella Pubblica Amministrazione, da emanarsi entro quattro mesi dalla data di entrata in vigore del provvedimento in esame, con il quale saranno individuate le azioni da realizzare sul territorio nazionale, le aree destinate alla sperimentazione e le modalità operative e di gestione di questi progetti.
Il comma 895 dispone che, nel valutare i progetti che debbono essere finanziati (di cui al comma 892), verrà data priorità a quelli che usufruiscono o sviluppano applicazioni software a codice aperto. Si intende, in sostanza, dare la possibilità alle amministrazioni pubbliche di poter utilizzare, liberamente, in cooperazione, i codici sorgente dei software affinché le innovazioni nella Pubblica Amministrazione possano essere rese disponibili e riutilizzabili attraverso un sito web apposito.
Linee guida per il riuso delle applicazioni informatiche nelle Amministrazioni pubbliche
Nel 2004 il CNIPA ha costituito un gruppo di lavoro incaricato di studiare la possibilità di sviluppare la pratica del riuso tra le amministrazioni centrali e di indicare le condizioni migliori per favorirne la diffusione. I risultati del lavoro del gruppo sono stati riportati nel documento “Riusabilità del software e delle applicazioni informatiche nella pubblica amministrazione - Rapporto del gruppo di lavoro - giugno 2004”, del quale è disponibile anche un rapporto di sintesi. Visti i positivi risultati raggiunti, a dicembre del 2004, il gruppo di lavoro è stato trasformato in un Centro di competenza.
I compiti iniziali assegnati al Centro di competenza sono:
− elaborare ulteriori indicazioni metodologiche e pratiche che consentano alle amministrazioni di prendere in considerazione l’opzione di riuso del software esistente o di impostare lo sviluppo di software applicativo facilmente riusabile;
− definire ed alimentare uno strumento di raccolta della conoscenza sul patrimonio applicativo disponibile e riusabile, sostanzialmente un “catalogo”
delle applicazioni riusabili.
Il Centro svolge inoltre una funzione di catalizzatore per lo sviluppo del riuso, offrendo consulenza alle amministrazioni, favorendo la diffusione e la conoscenza delle applicazioni riusabili e delle migliori esperienze, svolgendo un ruolo di mediazione tra amministrazioni che riusano, promuovendo e coordinando iniziative di riuso in ambiti specifici.
Le linee guida, parte 1 costituiscono la prima parte del quadro metodologico sul riuso e sono dedicate a fornire indicazioni alle amministrazioni che intendano sviluppare progetti di riuso di applicazioni informatiche esistenti. La parte 2 delle linee guida, non ancora disponibile, sarà dedicata alle indicazioni per la realizzazione di applicazioni riusabili. Le linee guida propongono alle amministrazioni il metodo e disegnano un percorso operativo articolato in varie fasi per lo sviluppo di un progetto di riuso. Alle distinte fasi sono associati alcuni strumenti operativi (Catalogo delle applicazioni, Check list per la valutazione di adeguatezza, Abaco per la valutazione della convenienza economica, ecc.).
La metodologia e gli strumenti rappresentano un primo contributo del CNIPA sulla tematica relativamente poco esplorata del riuso del software nella PA; hanno quindi un carattere evolutivo e saranno progressivamente integrati ed aggiornati in relazione alla graduale diffusione della pratica del riuso tra le amministrazioni.
Il documento è articolato in 7 capitoli:
− l’Introduzione, dedicata all’illustrazione delle fasi del metodo proposto in cui si richiamano le principali fattispecie di riuso possibili;
− i Capitoli dal 2 al 6, dedicati alla illustrazione delle varie fasi di un progetto di riuso secondo il metodo proposto;
− l’Appendice, contenente riferimenti normativi e bibliografici ed altra documentazione di riferimento.
Il concetto di riusabilità, secondo la definizione dell’IEEE1, indica il grado con cui un modulo o un’altra componente software può essere riusato in uno o più di un programma software. Il riuso del software è un concetto applicabile all’insieme delle componenti del prodotto software, definito come “l’insieme di programmi, procedure, regole, documenti, pertinenti all’utilizzo di un sistema informatico”. Nel documento si fa riferimento quindi al riuso delle applicazioni informatiche inteso come la possibilità di riutilizzare un prodotto software e/o sue componenti realizzate da o per conto di una amministrazione pubblica nell’ambito di uno o più sistemi informativi di altre amministrazioni pubbliche.
Nella progettazione delle linee guida si è tenuto conto del contesto caratteristico delle amministrazioni centrali. Peraltro le linee guida disegnano un metodo e propongono strumenti che sono disponibili e possono essere utilmente adottati da tutte le amministrazioni pubbliche.
Per una lettura completa del documento: