Bulgaria Open. Italia, qualche passo dietro

Abbandoniamo per un attimo il nostro excursus teorico/generale sul mondo dell’open per dedicarci a un tema di attualità, che però ha addentellati piuttosto interessanti anche per quanto riguarda il discorso sull’open, in particolare sull’open PA. La Bulgaria ha adottato una variante alla propria legge sulla pubblica amministrazione digitale (simile al nostro CAD, ma scritto meglio), per introdurre il principio che tutto il software sviluppato per conto e a spese della pubblica amministrazione deve in principio essere open source e sviluppati su un repository pubblico.

La legge bulgara

Non leggo il bulgaro. Una volta tanti anni fa tentai di scrivere in bulgaro senza conoscere la lingua, non fu facile. Mi baso dunque su traduzioni non ufficiali (in inglese). Ma quello che si legge mi piace. Ci sono gli elementi che vorrei ci fossero anche in una legge italiana (ci torneremo a breve). L’art. 58 a tradotto recita (doppia traduzione, beware!)

Nel predisporre incarichi tecnici e funzionali per appalti pubblici per sviluppare, aggiornare o implementare sistemi informativi e servizi informatici, le pubbliche amministrazioni devono inserire i seguenti requisiti:
1. Quando l’oggetto del contratto include lo sviluppo di programmi per computer:
a) i programmi per computer devono rispettare i criteri per essere open source software [codice a sorgente aperto, libero, ndr]
b) tutti i diritti d’autore e i diritti connessi sui programmi, il loro codice sorgente, il disegno delle interfacce e i database che sono oggetto del contratto dovranno essere assegnati al committente in pieno, senza limitazioni [ai diritti] d’uso, modificazione e distribuzione
c) lo sviluppo dovrà essere effettuato su repository gestiti dall’Agenzia come previsto dall’Art. 7c punto 18
[…]

Questo significa che non solo il software dovrà avere una licenza approvata OSI (almeno questo è il significato correntemente utilizzato per “open source”), e quindi rispettare anche le quattro libertà del software libero (vedi mio articolo introduttivo). Significa non solo, inoltre, che il copyright relativo (almeno della parte sviluppata appositamente per la pubblica amministrazione) sarà attribuito alla pubblica amministrazione e da questa dunque liberamente rilicenziabile, compatibilmente con le clausole copyleft del software in entrata. Significa anche che tutti potranno direttamente accedere al codice e scaricarselo, vedere i rami di sviluppo, eventualmente fornire patch, se interessati.

In altre parole, un riuso di fatto, molto più efficace, diretto e integrale di quello previsto in Italia (ci arriviamo).

La legge, inoltre, fa un passo in avanti, parlando di interfacce aperte, interoperabilità, accesso in open format e open data.

In altre parole, una buona disposizione, semplice, diretta, efficace, senza grandi spazi di aggirabilità (non come la nostra? ci arriviamo, ho detto!).

La legge Italiana

La legge Italiana, be’, è un po’ la tela di Penelope. Occupiamoci degli articoli 68 e 69 del Codice dell’Amministrazione Digitale.

Scelta delle soluzioni

L’articolo 68 è troppo lungo per riportarlo tutto, il testo attuale è disponibile sul sito AgID. Chi scrive ha fatto parte della commissione tecnica che ha elaborato le linee guida per l’attuazione, cui rimando per ogni approfondimento. Si articola nei seguenti punti:

  • Comma 1: definisce le modalità di acquisizione del software della pubblica amministrazione, includendo anche open source, riuso, sviluppo ad hoc. C’è dentro pure l’acquisizione di servizi in cloud, che tecnicamente c’entra come il cavolo a merenda e la cui definizione è imprecisa (ci si dovrebbe riferire al Software as a Service pubblico), ma non pretendiamo (è stato incluso in un emendamento spuntato un po’ per caso in sede di conversione di un decreto legge dell’era Monti, decreto legge che aveva introdotto un sostanziale miglioramento dell’art. 68). Non c’è (in questo comma, ancora) un ordine di preferenza. Non sono neppure sicuro sia un elenco esaustivo. Non sono, infine, neppure sicuro serva a granché.
  • Comma 1 bis: precisa che per procedere all’acquisizione, occorre fare una valutazione comparativa tra tutte le soluzioni in astratto possibili. Elenca anche i criteri che debbono essere usati. Senza questa valutazione comparativa, ogni scelta di acquisizione sarebbe illecita. La valutazione comparativa non si sostituisce alle regole sull’evidenza pubblica delle gare, previste invece dal Codice degli appalti.
  • Comma 1 ter: qui c’è, invece, un ordine di preferenza. Per prima cosa vanno valutate le soluzioni open source/software libero oppure in riuso e solo qualora sia impossibile trovare soluzioni che siano confacenti, allora si può procedere alle altre soluzioni. “Impossibile”, stando alle linee guida, che lo stesso comma 1 ter affida ad AgID e che ho contribuito a stilare, significa che c’è un giudizio di insufficienza in almeno una macro-area definita come essenziale. Affida anche ad AgID il compito di fornire, su richiesta, un parere sul rispetto dei criteri, da parte di chi fosse interessato.
  • Comma 2: prevede che tutte le soluzioni devono rispettare l’interoperabilità e la cooperazione operativa. Tenetelo presente, perché dopo vi racconto cose interessanti. Inoltre, si prevede che la rappresentazione dei dati deve essere in almeno un formato aperto (idem).
  • Comma 2 bis: affida ad AgID il compito di raccogliere informazioni sulle best practice attraverso la formazione di una banca dati.
  • Comma 3: definisce cosa si intende per “formato aperto”.
  • Comma 4: affida ad AgID il compito di tenere e aggiornare un elenco di formati aperti.

Tutto bene? No, anzi, quasi niente. Sono regole, per farle rispettare occorrono incentivi: positivi (premi) e negativi (punizioni). Occorrono controlli, incluso quello giudiziale, dunque realizzare un contrasto di interessi. Gli uni e gli altri sono in pratica assenti. Per quanto riguarda il controllo giudiziale, le evoluzioni normative hanno fortemente disincentivato il contenzioso, non con procedimenti più agili e alternativi, ma semplicemente alzando le barriere.

Le regole sono poi fortemente discrezionali, e molto spesso l’inerzia dell’installato, se non proprio il lock-in del fornitore precedente, bloccano ogni margine. In casi meno virtuosi, interessi inconfessabili prendono parte alla scelta. Dunque i casi (e ce ne sono) di buona scelta sono più frutto di volontariato e coscienza degli operatori pubblici coinvolti, che un risultato delle norme e del sistema. Recentemente è stata instaurata una Commissione Parlamentare per indagare sul cattivo stato della digitalizzazione della PA in Italia, ne vedremo delle belle.

Riuso

L’articolo 69 prevede il riuso delle soluzioni realizzate per conto e a spese dell’amministrazione.

Semplice? Mica tanto. La legge è scritta in modo un po’ più efficace dell’art. 68, ma ci sono molte scappatoie.

Comma 1. Le pubbliche amministrazioni che siano titolari di programmi informatici realizzati su specifiche indicazioni del committente pubblico hanno obbligo di darli in formato sorgente, completi della documentazione disponibile, in uso gratuito ad altre pubbliche amministrazioni che li richiedono e che intendano adattarli alle proprie esigenze, salvo motivate ragioni.

Ci sarebbe da fare un trattato. “Che siano titolari”, vuol dire che la titolarità è una condizione del riuso. Nella legge bulgara la titolarità è un obbligo di risultato. Occorre che le altre pubbliche amministrazioni richiedano il riuso, sono salve non specificate “motivate ragioni”. “Programmi” qui si estende pacificamente a “moduli di programmi”.

Comma 2. Al fine di favorire il riuso dei programmi informatici di proprietà delle pubbliche amministrazioni, ai sensi del comma 1, nei capitolati o nelle specifiche di progetto è previsto ove possibile, che i programmi appositamente sviluppati per conto e a spese dell’amministrazione siano facilmente portabili su altre piattaforme e conformi alla definizione e regolamentazione effettuata da DigitPA, ai sensi dell’ articolo 68,comma 2.

Il significato è chiaro. Per riusare qualcosa, deve essere qualcosa di più o meno indipendente, altrimenti, se sono vincolato a uno stack molto preciso, ho difficoltà ad esercitare il diritto di riuso, perché mi porto in casa dipendenze molto specifiche. La norma è comunque del tutto programmatica. Fa riferimento al comma 2 dell’articolo 68 per i principi di interoperabilità.

Comma 3. Le pubbliche amministrazioni inseriscono, nei contratti per l’acquisizione di programmi informatici o di singoli moduli, di cui al comma 1, clausole che garantiscano il diritto di disporre dei programmi ai fini del riuso da parte della medesima o di altre amministrazioni.

Qui la legge fa una scelta piuttosto timida. Prevede una specie di obbligo di inserire condizioni per favorire il riuso. Ma nulla dice in caso non vengano inserite. Addirittura, nel caso in cui non si dica proprio niente. Una scelta coerente avrebbe previsto un’assegnazione automatica, salvo patto contrario, del codice sviluppato per conto e pagato dalla PA, come avviene ad esempio per i dipendenti, ex art. 12_bis_ Legge Diritto d’Autore. Ho visto personalmente casi in cui niente di tutto ciò è stato inserito nei contratti, con conseguenze molto deleterie.

Comma 4. Nei contratti di acquisizione di programmi informatici sviluppati per conto e a spese delle amministrazioni, le stesse possono includere clausole, concordate con il fornitore, che tengano conto delle caratteristiche economiche ed organizzative di quest’ultimo, volte a vincolarlo, per un determinato lasso di tempo, a fornire, su richiesta di altre amministrazioni, servizi che consentono il riuso dei programmi o dei singoli moduli. Le clausole suddette definiscono le condizioni da osservare per la prestazione dei servizi indicati.

Clausola molto programmatica. “Possono inserire”, e ci mancherebbe che non lo possano fare. Alcune, in effetti, lo fanno. La clausola è poco interessante.

Morale? Il riuso è molto poco osservato. Anche qui, non si vedono grandi incentivi. Addirittura, le amministrazioni vedono, in tempi di ristrettezze, svantaggi poco giustificabili nell’investire tempo, soldi ed energie nel creare soluzioni che poi altre amministrazioni si portano in casa gratis, senza contribuire alcunché. Inoltre, per esperienza personale, si fa fatica a far accettare, su basi poco condivisibili, che invece di un riuso ad hoc, si condivida il codice come software libero, magari sotto una condizione copyleft, perché (orrore!) i privati potrebbero entrarne in possesso (di software per la pubblica amministrazione, magari sotto condizioni di copyleft forte); altre volte si obietta sul fatto che le licenze GPL sono in inglese, o ancora che non si preveda un foro competente. Questo è il livello (basso) di discussione su cui mi sono dovuto personalmente confrontare.

Sorpresa: abrogazioni!

«Che gelida manina, se la lasci riscaldare» — Giacomo Puccini, La Bohème

In un assetto normativo non proprio perfetto, ci si aspetterebbe che un intervento legislativo sistemasse le aporie e programmasse meglio gli interessi della pubblica amministrazione, introducendo efficienza, certezza del diritto, migliore assetto degli interessi. Insomma, ricercasse l’ottimo? Io sì, me lo aspetto. Ma le aspettative sono lì per essere deluse, in modo assolutamente lunare, da parte dell’attuale Governo.

In uno schema di decreto legislativo reso disponibile dal Governo, in attuazione di una delle riforme della Pubblica Amministrazione, scomparirebbero del tutto gli articoli 68 comma 2, 2bis e 4.

Perché? Formalmente non è dato saperlo. La Relazione illustrativa, all’articolo 65, parla solo della modifica dell’art. 68 comma 1 ter, rimanendo del tutto silente sulla ragione delle abolizioni. C’è il sospetto che anche qui una gelida manina provvidenziale abbia inserito le ulteriori abolizioni all’ultimo momento e senza un parere meditato degli uffici che hanno predisposto la modifica.

Anche per quanto riguarda la modifica del comma 1-ter, la motivazione è laconica e, scusate, stupida. La cito:

L’articolo 55 modifica l’articolo 68 del CAD in materia di analisi comparativa delle soluzioni, recando norme di coordinamento normativo e sistematico. In particolare, si sopprime la possibilità che i soggetti interessati chiedano all’Agid di esprimere il parere circa la modalità di svolgimento della valutazione comparativa delle soluzioni, essendo quest’ultima effettuata secondo modalità e criteri definiti dalla stessa Agid.

E allora? Appunto perché è AgID ad avere individuato i criteri, ha una competenza tecnica per offrire un parere. Il parere non è alternativo all’indicazione delle modalità di effettuazione della valutazione comparativa, la quale serve anche a vedere se non ci siano soluzioni in riuso e open source, ma presuppone che tali modalità siano state date e riguarda il loro rispetto. Francamente la logica di tale abolizione mi sfugge, se non per il fatto che s’intende rendere maggiormente assoluto il potere discrezionale e abolire un potenziale punto di moral suasion della PA verso il rispetto di regole che hanno ben poche sanzioni.

Le modifiche sono state contestate anche in maniera pubblica e in sedi istituzionali, si sta in questo momento verificando in sede parlamentare se dare indicazioni in senso contrario. Chissà perché, ma non sono molto fiducioso.

Conclusioni

La Bulgaria va avanti, noi, forse, indietro. Se va bene, stiamo fermi.

 

Facebook Comments

LEAVE A REPLY

Please enter your comment!
Please enter your name here