
<HTML>

<HEAD>

<TITLE>[Discussioni] [NEWS] CNIPA, INPS e Riuso software nelle PA</TITLE>

</HEAD>

<BODY>

<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Mi permetto di inserirmi nella discussione sulla questione del riuso. Ho replicato a Cammozzo personalmente ma vorrei provare a darvi un contributo senza mediazione. Scrivo di getto e velocemente e spero perdonerete qualche semplificazione o approssimazione.<BR>

<BR>

La questione è per certi versi molto semplice e molto vecchia. Semplicemente fino ad oggi pochi ci hanno fatto caso.<BR>

<BR>

Le amministrazioni centrali (soprattutto ma non solo) acquistano per il 60% certo software custom. Cosa si intende?<BR>

<BR>

Un pacchetto è un programma che esiste e che viene acquisito tramite licenza (proprietaria o open source). Casi ovvi sono SAP, Office, Open Office, Linux, Windows, MacOS, ...<BR>

<BR>

Un software custom è un programma che viene acquisito attraverso un contratto di servizio che prevede, tipicamente, una attività di progettazione e sviluppo di una soluzione. Nel pubblico, tali acquisizioni sono soggette a gare o trattative sulla base di un capitolato, che definisce i requisiti del software da sviluppare. Nella PA centrale, da almeno 10 anni, l’AIPA e il CNIPA prevedono che nel caso di sviluppo custom, per il quale si paga di solito l’effort necessario allo sviluppo, il software sorgente sia di piena proprietà dell’amministrazione appaltante (che ovviamente ci può fare quello che vuole). Notate che chiedere in questa fase che il software sia open source, come spiego più avanti, è controproducente per l’acquirente perché limita la sua possibilità di azione: deve chiedere la piena proprietà.<BR>

<BR>

Ovviamente esistono i casi misti in cui parte del software è custom, parte a pacchetto e parte a pacchetto personalizzato. Bisogna ovviamente identificare i vari casi, gestendoli di conseguenza. Per esempio, se è vero che SAP è preso su licenza, le sue personalizzazioni che sono pagate come software custom devono essere di proprietà di chi paga (per esempio i programmi ABAP addizionali).<BR>

<BR>

La direttiva Bassanini del 2000 dice che ogni pubblica amministrazione "ha la facoltà" di dare alle altre amministrazioni il software di cui è proprietaria. Questo si applica tipicamente al software custom che, come visto, viene normalmente acquisito tramite gara d'appalto. Non si tratta quindi di "sofware proprietario" quanto di software sviluppato ad hoc per una amministrazione. E' la distinzione sulla quale abbiamo tanto insistito nella commissione Meo. <BR>

<BR>

Bassanini mi ha spiegato che il decreto stabilisce che una PA "ha la facoltà" e non "deve" perchè ci potrebbero essere dei problemi di incostituzionalità se si obbligasse una PA a cedere il software.<BR>

<BR>

Come scrivevo a Cammozzo, non so quali vincoli esistano dal punto di vista giuridico, ma credo che una pa non può "vendere". Può certamente essere che una PA decida di ridistribuire suo software via licenza GPL o addirittura public domain. Nel passato, cose di questo tipo sono state viste come il fumo negli occhi non tanto dai grossi produttori come Microsoft ma dalle software house che fanno i pacchetti applicativi perché così si riduce il loro mercato (dicono).<BR>

</SPAN><FONT SIZE="2"><SPAN STYLE='font-size:10.0px'> </SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>

Da molti anni, il software custom passa di fornitore in fornitore al momento del rinnovo dei contratti di manutenzione del software. Facciamo un esempio, nel 1995, il software del ministero dell’istruzione (parecchi milioni di linee di codice COBOL) era in gestione a Finsiel. Finsiel perse la gara per i servizi di manutenzione e il software passò al vincitore di allora, EDS. L’anno scorso scadeva il contratto EDS ed è stata fatta una nuova gara. Hanno vinto IBM, Finsiel e Engineering che hanno preso in consegna il software (sorgente). C’è stato un ricorso, e il TAR ha riassegnato il contratto a EDS.<BR>

<BR>

Esempi di questo tipo ce ne sono tanti.<BR>

<BR>

Come vedete, già oggi il software custom è dell’amministrazione e passa di fornitore in fornitore in funzione dei risultati delle gare.<BR>

<BR>

Ora il discorso del riuso.<BR>

<BR>

In commissione Meo si è riflettuto sul fatto che essendo così alta la quota di software custom, bisogna agire per far si che questa spesa sia ottimizzata. Quel che accade quasi sempre e che diverse amministrazioni si fanno rifare lo stesso software. Attenzione, ciò non è vero per una fetta molto grossa della spesa. In particolare, Ministeri di grazia e giustizia non ce ne sono tanti, per esempio. Quindi sarà dura riuscire a riusare o pacchettizzare il software per quel ministero: a chi potrei darlo? Quanti altri gestiscono gli stessi problemi? Ovviamente nessuno.<BR>

<BR>

Ma in altri casi, vedi per esempio il software per la gestione di una scuola, c’è la possibilità di riusare software custom e di trasformarlo, se c’è una adeguata standardizzazione, in pacchetto. <BR>

<BR>

Nel primo caso, serve che le amministrazioni “riusino”, cioè che verifichino la possibilità di usare soluzioni custom esistenti (nel caso non ci siano pacchetti) prima di rifare un nuovo sviluppo. <BR>

<BR>

Dal punto di vista delle aziende, esse (cioè i system integrator e le software house) sono da sempre abituate a “fare progetti” e sviluppare sofware custom che viene poi ceduto (o che dovrebbe essere ceduto se la PA non è fessa) all’acquirente. In alcuni casi è possibile prevedere una cessione non esclusiva (chi vende ha anch’esso la facoltà di riusare il software).<BR>

<BR>

Quindi non capisco il discorso di “un’economia parallela”. E’ il mercato del software come è sempre stato, anche se forse poco noto. Dove secondo me entra in gioco l’open source non è al momento della transazione tra PA e software house fornitrice, ma a valle. Quando una PA ha acquisito la proprietà di un software custom, tenendo conto che qualcuno non sarebbe molto contento (vedi commento di prima), potrebbe purtuttavia renderlo “open” per il mercato e le altre PA (magari con qualche meccanismo alla Mozilla o Community source per avere un coordinamento, ma di questo possiamo discuterne). Tra l’altro, questo potrebbe innescare un meccanismo di trasformazione del software custom in pacchetto. Notate che potrebbe addirittura renderlo public domain ed è per questo che limitarsi a dire open source in fase di acquisizione non ha senso.<BR>

<BR>

Già una volta dissi che secondo me sarebbe utile fare un incontro su questo tema perché credo servirebbe a chiarire parecchi problemi e fraintendimenti.<BR>

Non mi fu risposto nulla (a me piace confrontarmi e discutere anche se, secondo qualcuno, dico cazzate). Resto sempre a disposizione perché secondo me via mail non si riesce a discutere bene e soprattutto non si arriva ad una sintesi.<BR>

<BR>

Saluti,<BR>

<BR>

Alfonso</SPAN></FONT>

</BODY>

</HTML>