[Discussioni]Filosofia (was: Cara commissione Meo...)

[Alfonso Fuggetta]

> 1- Pacchetti vs. Software Custom.
> Grazie alla esauriente definizione (e avendo a disposizione 
> mio figlio proprio di tre anni ;-) ho compreso la differenza.
> A questo punto il problema permane pero': alla base 
> dell'acquisto di software c'e' uno studio di fattibilita' 
> dove viene deciso se esiste un pacchetto utile allo scopo o 
> occorre fare sviluppare l'applicazione custom.
> Quali "paletti" ha chi compie questo studio?

Mi scusi, ma in tutto il resto dell'universo mondo chi mette I paletti? Ogni amministratore è responsabile di ciò che fa nello svolgimento della propria missione sia che compri software che moto BWM o Ducati per la Polizia. Per di più, nel bene e nel male (a volte ahimè molto), in Italia c'è l'AIPA e il min dell'innovazione che dovrebbero fare da regia e controllo. Non per niente tutte le gare della PA centrale passano dall'AIPA. So bene che l'AIPA ha fatto anche molti errori, ma in tutti I settori ci sono persone che fanno errori in buona o cattiva fede (vedi discorso sulle deleghe più avanti nella mail).

> Se esiste un magnifico pacchetto proprietario a sorgente 
> chiuso che gestisce egregiamente le elezioni politiche nella 
> repubblica delle banane e in quella dei kiwi, il nostro 
> consulente della P.A. chiamato a preparare il capitolato per 
> l'automatizzazione delle elezioni politiche in Italia puo' 
> caldeggiarne l'acquisto perche' meno oneroso rispetto allo 
> sviluppo di un sistema ex-novo a sorgente aperto o 
> all'adattamento di un sistema aperto esistente?
> Per me no. 

Premesso che anche il pacchetto proprietario deve essere verificabile (ma ne parliamo dopo), può essere benissimo che in un caso di questo tipo si reputi opportuno non acquisire software su licenza e preferire l'acquisto di software custom. Oppure si contratti una licenza più forte che includa un accesso più "forte" al codice sorgente (potrebbe essere GPL oppure proprietario con una licenza ad hoc che renda disponibile in forma non esclusiva il codice alla PA). Dire che si possono comprare pacchetti proprietari, non vuol dire che è obbligatorio comprarli. Parte del "value" (for money) potrebbe essere proprio il livello di tutela percepito dai cittadini. La vostra interpretazione di value è riduttiva. Ci era ben chiaro che in alcuni casi il value non è semplicemente una questione di soldi. Ma questo è ovvio anche agli economisti.

> Abbiamo solo spostato il problema dalla definizione dei 
> diversi tipi di software ai vincoli per l'utilizzo di uno o 
> dell'altro tipo.

Questa è la sua opinione. Ovvio che è facile dire tutto open source oppure non se ne fa niente. È una soluzione iper-radicale che secondo me è incompatibile con il mondo reale.

> 2- Value for Money.
> Ottimo come slogan, ma rimango dubbioso.
> Anche perche' ai valori tengo molto... noi filosofi si sa...
> Mi pare che siano in gioco diverse visioni dei valori. Da un 
> lato i valori sono efficienza ed economicita' della gestione 
> della macchina pubblica dall'altro la tutela dei diritti dei 
> cittadini. Sono per carita' tutti elementi positivi ma nel 
> mio modo di vedere le cose i diritti vengono al primo posto 
> poi l'efficienza e l'economicita'.

Ma perchè mai la seconda esigenza deve essere necessariamente in contrapposizione con la prima? Se compro un pacchetto è lo posso verificare non ho ottemperato alla sua esigenza?

> Occorre definire i paletti, l'ho gia' detto e qui mi 
> ripeterei ma occorre anche definire bene il concetto di 
> apertura del sorgente: chi puo' leggere i sorgenti, chi li 
> puo' utilizzare e per farci cosa, quale e' il prezzo per 
> poterli usare, se il sorgente e' completo o parziale, quali 
> diritti ha la P.A. e il cittadino sul sorgente.

Siccome proprio fessi non siamo, nel rapporto c'è scritto che il codice deve essere disponibile "senza artifizi". E credo che Microsoft il messaggio l'abbia capito bene. Mi chiedo se sia altrettanto chiaro a IBM, Sun, Oracle e SAP. D'altro canto nel momento in cui I principi che abbiamo proposto nel documento venissero tradotti in una norma o regolamento, a quel punto o siamo veramente repubblica delle banane oppure si devono adeguare. Anche perchè altri paesi stanno adottando misure simili.

> Per quanto riguarda i pacchetti:
> "Dal punto di vista della verificabilita'....rendere 
> possibile che il codice sorgente sia accessibile per le PA ai 
> soli fini della verifica di funzionamento". 
> A parte individuare *chi* effettivamente sia la PA (direttore 
> *che di informatica semmai non ne sa un tubo come 
> probabilmente un primo ministro*, tutto il personale, ditte 
> di consulenza esterne) rimane l'ottica di tutela della PA e 
> non del cittadino.

Il documento della commissione ovviamente deve essere poi declinato in norma. La struttura che fa le verifiche potrebbe essere l'AIPA o dipartimento per l'innovazione e le tecnologie. O una struttura di ricerca pubblica indipendente. Questo si può e deve discutere in sede di redazione della norma.

> Quel software puo' elaborare informazioni del cittadino 
> proprio relativi al suo
> *status* di cittadino. In molti casi (gli esempi eclatanti 
> sono le elezioni, l'informatica forense ma anche la gestione 
> dei dati sensibili) e' il cittadino che deve poter analizzare 
> i programmi e NON la PA che potrebbe essere la controparte in 
> un contenzioso sulla tutela dei diritti fondamentali.

Quando una PA compra cellulari, il cittadino verifica che il codice nella EPROM del cellulare che magari verrà utilizzato da manager pubblici per parlare di noi cittadini non contenga backdoor? Quando lei prende un treno, verifica il codice che controlla I semafori della ferrovia? Oppure se sale in aereo pretende di vedere il codice del sistema di controllo dell'aereo o del controllo del traffico? E se va in ospedale chiede di verificare il progetto della macchina della TAC o di vedere il codice del software che la controlla? Cambiando settore, lei controlla di persona che un farmaco non sia dannoso per la sua salute? Oppure si "fida" di ciò che dice l'istituto superiore di sanità? E quando sale su una macchina, fa le prove di resistenza delle sospensioni o delle barre di torsione per vedere che la macchina non causi incidenti. Non mi dica che nel caso della macchina volendo lo potrebbe fare, perchè è una scappatoia dialettica e non reale.

Nelle attività della società noi riusciamo a vivere perchè ci fidiamo delegando alcune attività ad altri nell'ambito di precise regole e contropoteri. È inevitabile. Ora è giusto che ci sia qualcuno che controlla e che ne risponda alla collettività, ma immaginare che tutti controllino tutto mi pare demagogico.
 
> Vorrei commentare anche la proposta di riservare alle PA il 
> diritto di accesso al codice sorgente quando il proprietario 
> non sia piu' in grado o non voglia mantenere il prodotto.
> Come giustamente si dice poche righe prima la disponibilita' 
> del sorgente non vuole dire automaticamente manutenibilita': 
> in questo caso per esempio l'apertura del codice sorgente 
> potrebbe rivelare una ingegnerizzazione del software talmente 
> scadente da rendere impossibile ogni ulteriore sviluppo.
> L'accesso al sorgente paga anche per questo.

Non capisco, lei dice che l'apertura del codice potrebbe rivelare che è inutile insistere. Benissimo, nel mio schema quando la PA riceverà il codice perchè il fornitore non è in grado di continuare, lei stessa (la PA) deciderà se andare avanti oppure se dire "I give up". Che differenza c'è tra quello che dico io e quello che dice lei?

> 3- memorizzazione dei dati in formato aperto.
> Qui penso che tutto sia chiaro con le ultime precisazioni.
> Si intende che ogni dato (informazione o documento) 
> memorizzato, trasmesso o messo a disposizione dei cittadini 
> deve essere rappesentato in un formato standard aperto e 
> royalty free. 
> Le amministrazioni potranno mantenere copie dei dati in altri 
> formati anche proprietari (se lo riterranno opportuno o 
> comodo) fermo restando che in caso di incogruenze dovute alle 
> conversioni fa fede il contenuto espresso nel formato 
> standard aperto indicato nel capoverso precedente.
> Nel caso di piu' formati aperti royalty free occorre indicare 
> quello "ufficiale".
> Ho capito bene?

Direi di si. Non ho capito cosa vuol dire "ufficiale". Noi intendavamo almeno un formato open a discrezione della PA. Se qualcuno vuol usare HTML usi quello. Se altri vogliono usare OpenOffice, usino OpenOffice. Non so se sia ragionevole identificare "un" formato "ufficiale".

> Per i pacchetti proprietari che salvano in formati standard 
> (e.g. XML) occorre fare attenzione che non vengano usati 
> standard "estesi" ad arte ("piu' standard degli altri" come 
> direbbe Orwell). L'XML potrebbe contenere entro tag opportuni 
> parti proprietarie: l'XML e' solo un guscio libero.

L'abbiamo scritto. Deve essere presentato lo schema XML in modo che sia comprensibile.

> Il codice aperto (verso i cittadini non verso solo le P.A.) 
> e' una forma di garanzia. 

Ripeto, capisco ma mi chiedo come mai non si applichi con lo stesso rigore il suo approccio a tutte le altre situazioni critiche che non coivolgono software. A me sembra che questa sua esigenza, ultralegittima, sia un po' esasperata nei vostri discorsi. Ripeto ci sono decine di casi nella società civile dove un controllo viene delegato a una struttura che ha la responsabilità relativa. La delega è una delle regole base della società civile. È chiaro che ci devono essere meccanismi per verificare che le deleghe funzionino bene. Ma lo stesso problema vale, per esempio, per gli atti secretati di un processo. Perchè la Boccassini non vuol divulgare il fascicolo che ha secretato su Perugia? Per me potrebbe anche fare bene, ma o accetto di fidarmi della procura della repubblica di Milano oppure salta tutto.
 
> Sono convinto che questo secondo metodo aiuti la 
> riutilizzabilita' del codice fatto su richiesta della P.A., 
> non ci siano vincoli di dipendenza dal fornitore, ci sia il 
> massimo di trasparenza verso il cittadino e chiunque possa 
> controllare non solo la qualita' esteriore ma anche quella 
> strutturale/implementativa  del prodotto software.
> Il tutto non e' a costo zero, e' necessario un maggior 
> coordinamento, ci sono i costi naturali di ogni cambiamento 
> (know how e aggiornamento di processi
> produttivi) e non e' detto che alla fine ci sia un risparmio 
> netto economico.

Ma in cosa il report della commissione impedisce quello che dice lei? Come o già detto la vera differenza è che voi volevate dei "deve" o un "preferenziale" che secondo me non hanno senso.

> IBM molto citata in questi messaggi non sempre ha fatto un 
> buon servizio all'informatica. Il detto "nessuno ti 
> licenziera' mai per aver scelto IBM", tanto in voga fra i CED 
> manager dei decenni passati ha fatto preferire soluzioni 
> anche obsolete o improprie perche' proposte dalla real-casa 
> della grande scritta blu.

Benissimo, mi chiedo solo come mai quelli di IBM si portano sempre dietro qualcuno di Linux che pontifica benicendo la grande mamma big blue per la tante bellissime cose che fa sull'open source. Non fatemi dire cose che non posso dire :-) sulle audizioni che abbiamo fatto! L'unica cosa che fa IBM per l'open source è finanziare progetti che a lei servono per fare concorrenza a Microsoft. Tutto il suo software vero (secondo le loro parole, Linux non è un prodotto IBM, giustamente) è strettamente proprietario. E quando anche offrono prodotti su Linux sono prodotti proprietari. Non vi sentite un po' usati?

Alle sue ultime affermazioni credo di aver già risposto e non voglio farla troppo lunga. Però ribadisco che sarebbe utile fare un incontro di lavoro face to face dove discutere di queste cose. La mail fa schifo per questo tipo di discussioni. 

Alfonso