La direttiva del Ministro per l’innovazione e le tecnologie del 19 dicembre 2003 obbliga ogni amministrazione a valutare il software open source quando acquisisce un sistema e a preferire soluzioni che gestiscano almeno un formato dati aperto. Per il portale di una Provincia la partita si gioca nei criteri di progetto, prima ancora che nel codice: la base tecnologica deve essere documentata, riusabile e senza vincoli proprietari sui dati che pubblica.

Contesto normativo

Tre atti, tutti già in vigore o approvati, fissano il perimetro.

La direttiva Stanca del 19 dicembre 2003 (Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni) elenca in ordine di preferenza quattro opzioni per l’acquisizione: sviluppo su misura, riuso di programmi già realizzati da altre amministrazioni, acquisto di licenze proprietarie, acquisizione di programmi open source. Introduce inoltre, per la prima volta, clausole contrattuali che favoriscono il riuso e la gestione di almeno un formato aperto.

La legge 9 gennaio 2004 n. 4 (Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici) e il suo regolamento attuativo, il DPR 1 marzo 2005 n. 75, impongono requisiti di accessibilità ai siti delle amministrazioni e prevedono un responsabile dell’accessibilità per ogni ente centrale, con la verifica affidata al CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione). Il decreto ministeriale con i requisiti tecnici dettagliati — l’Allegato A — non è ancora uscito alla data di queste note: il riferimento operativo resta quindi le WCAG 1.0 (Web Content Accessibility Guidelines) del W3C, del 1999.

Il Codice dell’amministrazione digitale (D.Lgs. 7 marzo 2005 n. 82) è stato approvato ma entra in vigore il 1° gennaio 2006. Gli articoli 68 e 69 consolidano i principi della direttiva: una valutazione comparativa che pesa il costo complessivo e il grado di apertura di formati e interfacce, e l’obbligo di mettere a disposizione delle altre amministrazioni il software sviluppato per la PA. Conviene progettare il portale già in linea con quel testo.

Architettura di riferimento

Lo stack tipico per un portale di questo tipo è quello noto come LAMP: GNU/Linux come sistema operativo, Apache come server HTTP, un database relazionale (MySQL o PostgreSQL), un linguaggio applicativo lato server (PHP, Perl o Python). Sono tutte componenti distribuite con licenze approvate dalla Open Source Initiative, ognuna con il codice sorgente disponibile e nessun canone di licenza per nodo.

Apache 2.0 regge il fronte HTTP, con mod_rewrite per URL leggibili e stabili nel tempo — non è un requisito secondario per un ente che deve garantire la persistenza degli atti pubblicati. Perché i singoli uffici provinciali possano redigere e aggiornare le pagine senza passare ogni volta dal fornitore, serve un sistema di gestione dei contenuti (content management system): nel mondo open source sono ormai maturi prodotti come Plone (su Zope), Typo3, Mambo, Drupal e PHP-Nuke, con modelli di workflow e di permessi adatti a una redazione distribuita su più assessorati e settori.

Il livello di presentazione va tenuto separato dal contenuto. Con marcatura XHTML 1.0 servita da fogli di stile CSS 2 si rispettano i punti di controllo WCAG 1.0 — alternative testuali alle immagini, struttura dei titoli, contrasto, indipendenza dal dispositivo — e si modifica il template senza toccare i dati. La separazione semantica è la condizione tecnica perché l’accessibilità si possa verificare, invece di aggiungerla a posteriori.

Il punto critico: i dati, non solo il software

L’attenzione finisce spesso sulla licenza del software. Il vincolo più duraturo per un ente, però, è il formato in cui i dati vengono prodotti e archiviati. Un portale può girare su stack libero e pubblicare comunque le delibere in un formato proprietario il cui parser è in mano a un solo fornitore: il documento resta leggibile finché esiste quel software, in contrasto con l’obbligo di gestire almeno un formato aperto introdotto dalla direttiva del 2003.

La scelta tecnica coerente è produrre gli atti in formati con specifica pubblica: HTML per i contenuti web, PDF per i documenti destinati alla stampa e all’archiviazione, XML per i flussi strutturati (bandi, albo pretorio, dati di bilancio). L’OpenDocument Format è stato approvato come OASIS Standard il 1° maggio 2005 ed è una strada percorribile per i documenti d’ufficio; manca ancora la ratifica come standard ISO/IEC, in corso alla data di queste note. Il criterio è verificabile: un formato è adeguato quando esiste almeno un’implementazione indipendente capace di leggerlo dalla sola specifica.

Conseguenze per l’ente

Adottare uno stack open source per un portale provinciale produce conseguenze misurabili su tre piani.

Sul costo, l’assenza di canoni di licenza per nodo sposta la spesa dalle licenze ai servizi — installazione, personalizzazione, manutenzione — che restano sul territorio e si possono rinegoziare a ogni rinnovo, senza il vincolo del fornitore unico della piattaforma.

Sull’indipendenza tecnologica, il codice sorgente disponibile consente all’ente di cambiare fornitore di servizi senza riscrivere il portale: la condizione richiesta dall’articolo 69 del Codice — sorgenti più documentazione, sotto licenza aperta — è anche la condizione che rende un appalto contendibile.

Sul riuso, un portale rilasciato con licenza aperta lo possono riutilizzare altre Province con esigenze analoghe, coerentemente con la seconda opzione della direttiva Stanca. Il riuso funziona solo se accompagnato dalla documentazione di installazione e configurazione: senza, il codice c’è ma in pratica non si riusa.

Limiti

Queste note descrivono criteri di progetto, non garanzie di risultato. Uno stack libero non rende accessibile un sito di per sé: l’accessibilità WCAG 1.0 dipende dalla marcatura che produce il CMS e dalle scelte redazionali, e va verificata caso per caso, tanto più finché manca il decreto con i requisiti tecnici nazionali. Il quadro normativo è in movimento: il Codice dell’amministrazione digitale entra in vigore solo a gennaio 2006, e la lettura operativa degli articoli 68 e 69 andrà osservata sul campo. La durata nel tempo, infine, dipende dalla manutenzione: un portale open source abbandonato invecchia come qualsiasi altro, e il sorgente disponibile non sostituisce un contratto di manutenzione attivo.

Un portale provinciale costruito su questi criteri — stack LAMP, CMS per la redazione distribuita degli uffici, formati aperti per gli atti — è quello realizzato da noze per la Provincia di Teramo, descritto nell’insight: https://www.noze.it/insights/portale-provincia-teramo/.

https://www.funzionepubblica.gov.it/ — Ministro per l’innovazione e le tecnologie, direttiva 19 dicembre 2003 https://www.gazzettaufficiale.it/eli/id/2004/01/17/004G0015/sg — Legge 9 gennaio 2004, n. 4 https://www.gazzettaufficiale.it/eli/id/2005/05/03/005G0097/sg — DPR 1 marzo 2005, n. 75 http://web.archive.org/web/2005/http://www.cnipa.gov.it/ — CNIPA, Osservatorio open source (archivio 2005) http://www.w3.org/TR/WAI-WEBCONTENT/ — W3C, Web Content Accessibility Guidelines 1.0 (1999) http://www.w3.org/TR/xhtml1/ — W3C, XHTML 1.0

Immagine di copertina: Diagramma che scompone lo stack LAMP nei suoi quattro strati: Linux come sistema operativo, Apache come web server, MySQL come… — diagramma di ScotXW, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:LAMP_software_bundle.svg