Il software libero entra nei capitolati della pubblica amministrazione italiana come opzione tecnica da valutare, non più come curiosità accademica. La commissione che il Ministro per l’Innovazione e le Tecnologie ha istituito a gennaio 2003, presieduta da Angelo Raffaele Meo del Politecnico di Torino, ha esattamente questo mandato: capire se e come il codice sorgente aperto possa entrare nei sistemi informativi pubblici. Scrivo da chi costruisce soluzioni con software libero per i propri clienti, dopo una giornata passata a discuterne a Pisa.

Contesto

Il dibattito si è subito arenato sul confronto di costo: licenze proprietarie contro distribuzioni gratuite. È un terreno scivoloso. Il prezzo della licenza è una voce visibile, comoda da mettere in tabella, ma quasi mai pesa più del resto nel costo complessivo di un sistema informativo: migrazione dei dati, formazione, manutenzione, integrazione con quello che già gira valgono molto di più e c’entrano poco con il modello di licenza.

Inseguire il prezzo della licenza distoglie l’attenzione dalle due cose che pesano davvero per un’amministrazione: il controllo sui formati dei dati e il controllo sul codice che li elabora. Sono questi a stabilire se fra dieci anni quei dati saranno ancora leggibili e se quel servizio sarà ancora manutenibile da qualcuno che non sia l’unico fornitore di partenza.

Il problema del lock-in

Un’amministrazione che archivia atti, anagrafiche e fascicoli in un formato chiuso e non documentato lascia a un solo fornitore la decisione su quando, e a che prezzo, quei dati resteranno accessibili. Il vincolo non è contrattuale ma tecnico: anche a contratto scaduto, i dati restano in ostaggio del programma che li ha scritti.

Il software libero non scioglie questo nodo solo perché è libero. Lo scioglie quando porta con sé formati aperti e documentati e quando il sorgente è davvero a disposizione di un secondo fornitore. Sono due requisiti distinti. C’è software proprietario che salva in formati standard e software libero che usa formati propri, mal documentati. La licenza serve ma non basta: le garanzie concrete sono la specifica del formato e la leggibilità del sorgente.

Per la pubblica amministrazione questa distinzione pesa in modo particolare. Un privato che resta legato a un fornitore subisce un danno economico circoscritto. Un’amministrazione che perde l’accesso ai propri archivi compromette la continuità di un servizio dovuto ai cittadini, e lo fa con denaro pubblico.

Cosa offre il modello a sorgente aperto

Le licenze libere consolidate scrivono nero su bianco garanzie precise. La GNU General Public License, nella versione 2 del giugno 1991, obbliga chi distribuisce un programma o un suo derivato a rendere disponibile il sorgente sotto gli stessi termini. La famiglia BSD è più permissiva e consente la ridistribuzione anche in forma chiusa. La Open Source Definition, curata dalla Open Source Initiative dal 1998, fissa i criteri minimi perché una licenza si possa dire tale: ridistribuzione libera, sorgente disponibile, opere derivate ammesse, nessuna discriminazione sul campo d’uso.

Per un’amministrazione la conseguenza pratica è poter mettere a gara la manutenzione. Se il sorgente di un applicativo sta sotto una licenza libera, l’ente può affidare correzioni ed evoluzioni a un fornitore diverso da chi lo ha scritto, senza ripartire da zero. Non dipende più da un singolo soggetto, ma dalla competenza tecnica disponibile sul mercato.

Qui si apre uno spazio per le piccole e medie imprese italiane. Una PMI difficilmente regge il confronto con un grande fornitore sulle licenze proprietarie, dove vince la scala. Regge il confronto sulla manutenzione e sull’adattamento del software libero, dove vincono la conoscenza del dominio applicativo e la vicinanza al cliente. È un mercato di servizi, non di prodotti, e si gioca sulla competenza più che sui volumi. Proprio questa prospettiva delle PMI che costruiscono soluzioni professionali su software libero è quella che noze ha portato al convegno con la relazione «Open Source al lavoro: l’offerta delle PMI italiane» (https://www.noze.it/insights/convegno-oss-pa-pisa/).

Punto critico

Il rischio vero è che l’apertura resti sulla carta. Un ente può adottare un applicativo a sorgente aperto e ritrovarsi comunque legato a un solo fornitore, se quel sorgente è scritto in modo da risultare illeggibile a chiunque altro: nessuna documentazione, dipendenze non dichiarate, build che non si riproduce, configurazioni sparse e implicite. In quel caso la licenza è libera sulla carta, ma il lock-in tecnico resta intero.

Avere il sorgente è una condizione necessaria, non una garanzia. Perché dia i frutti attesi servono pratiche verificabili: documentazione del formato dati, procedura di build riproducibile, deposito del codice presso l’amministrazione e non solo presso il fornitore. Le circolari dell’allora AIPA sul riuso degli applicativi pubblici, dal 2001 in poi, andavano da questa parte: chiedevano che il software sviluppato con denaro pubblico fosse riutilizzabile da altri enti. E perché lo sia, prima ancora della licenza, il codice va messo nelle condizioni di essere riusato.

Implicazioni

In Europa alcuni esperimenti stanno mettendo alla prova queste ipotesi sul campo. La regione spagnola dell’Estremadura dal 2002 ha distribuito nelle scuole decine di migliaia di postazioni con una distribuzione GNU/Linux costruita su misura, gnuLinEx. La città di Monaco di Baviera in questi mesi sta conducendo uno studio per scegliere il successore della propria infrastruttura su Windows NT 4, e nella valutazione mette a confronto, in modo esplicito, un percorso proprietario e uno a software libero. Sono casi da seguire per i dati che produrranno, non da citare come prove già acquisite: i numeri veri su migrazione e manutenzione arriveranno negli anni, non nei comunicati.

Sul metodo è già emerso un punto utile. Nel 2002 il deputato peruviano Edgar Villanueva, rispondendo a una lettera di Microsoft sul disegno di legge per il software libero nella PA, ha spostato la questione sui principi: per un’amministrazione la disponibilità del sorgente, l’accesso ai dati e l’indipendenza dal fornitore sono requisiti di buon governo, e valgono a prescindere dal confronto di prezzo. È un’impostazione che regge meglio del calcolo sui costi di licenza, perché non dipende da come oscilla un listino.

Limiti

Non tutto si presta. Il software molto verticale, con pochi utenti e nessuna comunità di sviluppo alle spalle, difficilmente trova nel modello aperto i vantaggi di manutenzione distribuita che valgono per i componenti di base — sistema operativo, server, suite d’ufficio, basi di dati. Lì il vantaggio è netto e l’uso quotidiano lo conferma già. Per gli applicativi gestionali specifici la scelta va pesata caso per caso, sul singolo capitolato.

E resta aperta la questione delle competenze interne. Un’amministrazione che adotta software libero senza personale capace di leggere un capitolato tecnico, giudicare la qualità di un sorgente, pretendere documentazione e procedure di build, si limita a spostare la propria dipendenza da un fornitore a un altro. La leva non è la licenza: è la capacità dell’ente di esercitare il controllo che la licenza gli mette in mano.

Immagine di copertina: Illustrazione stilizzata di una testa di gnu con barba e corna, il logo del Progetto GNU — logo di Aurelio A. Heckert, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Heckert_GNU_white.svg