In questa pagina vengono condivise in forma riassuntiva ed in lingua italiana le obbligazioni civilistiche e amministrative a cui devono attenersi tutti i soggetti pubblici che operano modifiche al software GlobaLeaks.
Spesso accade che delle pubbliche amministrazioni, direttamente tramite società IT in-house o mediante contratti esterni, decidano di personalizzare il software GlobaLeaks, apportando delle modifiche al codice sorgente, impiegando e redistribuendo quindi l’edizione software modificata in molteplici modalità quali ad esempio:
- Redistribuendolo il software modificato (dietro compenso o gratuitamente) o le sole modifiche al software
- Avviando per se’ stessi un servizio IT SaaS di Whistleblowing
- Avviando, in favore di terzi, servizi IT SaaS di Whistleblowing
Per IT SaaS (Software as a Service) si intende la messa in opera, raggiungibile e fruibile attraverso un browser web, del software GlobaLeaks.
Esistono molteplici regole a cui i soggetti che effettuano quanto su descritto devono attenersi, e sono così suddivisibili:
- Obbligazioni civilistiche per rispettare i diritti di copyright (o meglio di copyleft, per tutelare la libertà del software come “bene comune”)
- Obbligazioni amministrative e operative per rispettare il CAD (Codice Amministrazione Digitale) e le relative Linee Guida sul Riuso del Software
- Obbligazioni tecniche-operative per consentire il rispetto delle Misure Minime di Sicurezza ICT emesse dall’Agenzia dell’Italia Digitale da parte di chi impiega il software modificato nonché le “Linee guida per lo sviluppo del software sicuro” cui devono attenersi i soggetti che materialmente modificano il software
Qualora non vi sia la piena comprensione e conseguente rispetto delle obbligazioni di cui sopra, il più delle volte non per dolo ma per dinamiche di ridotte tempistiche di rilascio e/o budget di sviluppo software sottodimensionati, le pubbliche amministrazioni e/o i soggetti terzi coinvolti per l’esecuzione potrebbero trovarsi in condizioni di irregolarità procedurale e/o amministrativa e/o legale dovendo in seguito aumentare i costi progettuali per l’adeguamento alla compliance.
Questo documento fornisce una linea guida per facilitare la compliance all’interno dei progetto di riuso. Per qualunque delucidazione o chiarimento è possibile condividere dubbi e/o richieste di chiarimento e/o suggerimenti su come migliorare le condizioni di licenza sul Forum GlobaLeaks.
Rispetto del diritto d’autore (obbligazioni civilistiche)
Il Software opensource GlobaLeaks è rilasciato con una licenza libera, cioè la AGPL 3.0 della Free Software Foundation (approvata OSI) specificamente disegnata per le applicazioni web, che tutela il mantenimento della libertà nel tempo del software, ne regola le modalità di apporto dei contributi comunitari, di redistribuzione nonché di rispetto dell’attribuzione dei diritti d’autore agli sviluppatori software.
Ai fini delle regole di riuso è importante sapere che la licenza AGPL 3.0 comporta i seguenti principali obblighi:
- Qualunque utente che interagisca con il software, tramite un browser, deve potere disporre dell’accesso ai codici sorgenti in esecuzione sul server, inclusivi di tutte le eventuali modifiche apportate
- Qualunque edizione venisse redistribuita deve riportare in modo esplicito e ben evidenziato l’attribuzione dei diritti di autore secondo quanto previsto dalla licenza d’uso
- Qualunque edizione venisse redistribuita non può essere licenziata con diverse licenze software (possono esserlo le sole modifiche apportate, laddove la licenza libera usata fosse compatibile per l’integrazione).
Il primo punto è rivolto a scoraggiare lo sfruttamento, tipicamente per finalità commerciali (ma non esclusivamente), del software libero apportando modifiche allo stesso che non saranno redistribuite come bene comune.
Il secondo punto è rivolto a scoraggiare la redistribuzione del software, tipicamente con minori modifiche, senza che vi sia una evidenza pubblica della edizione originale su cui questo è stato basato.
Il terzo punto è rivolto a mantenere l’integrità dell’insieme di diritti e libertà garantite dal software, consentendo tuttavia il licensing con altra licenza compatibile delle sole modifiche apportate, espressamente indicando i singoli artefatti oggetto di modifica.
A tal proposito la licenza d’uso del software GlobaLeaks prevede l’applicazione di due ulteriori estensioni consentite dalla AGPL 3.0 per tutte le modifiche software, schematizzate in seguito:
Appropriate Legal Notice alla clausola 7. comma b.:
- Obbligo di mantenere nella intestazione della interfaccia web la dicitura “Powered by GlobaLeaks” con un collegamento ipertestuale al sito del progetto software “https://www.www.globaleaks.org” .
Modified Material Notice alla clausola 7. comma c.:
- Obbligo di indicare nella interfaccia web un collegamento ipertestuale che consenta all’utente finale di accedere ai codici sorgenti della edizione software modificata.
- Obbligo di indicare nella edizione modificata nella interfaccia web la versione del software su cui l’edizione derivata si basa e la sua data di rilascio
- Obbligo di indicare nella interfaccia web, laddove l’edizione software rilasciata sia più vecchia di 6 mesi rispetto alla ultima versione corrente rilasciata del software, un disclaimer su possibili problematiche di sicurezza derivanti da tale disallineamento/mancato aggiornamento.
Le obbligazioni di cui sopra si applicano tanto alle edizioni di software modificate redistribuite sotto forma di codici sorgenti quanto sotto forma di servizio gestito (SaaS: Software as a Service).
Software con licenza AGPL 3.0 non può essere oggetto di re-licensing, se non per espressa azione da parte del 100% dei detentori dei diritti d’autore.
In caso di violazioni sarà cura dei detentori dei diritti d’autore notificare gli enti e/o le società in violazione, al fine di preservare la libertà del software nei principi della licenza AGPL 3.0 che fornisce 60 giorni di tempo per l’adeguamento (salvo diversi accordi).
Il Foro Competente definito dai detentori dei diritti d’autore è Milano. I detentori dei diritti d’autore proporranno ricorso alla Camera Arbitrale di Milano, seguendo un percorso volto ad evitare inutili azioni civili, disponibili ad eleggere in propria rappresentanza avvocati affiliati alla Free Software Foundation Europe e/o altri giuristi che che da tempo operano (anche pro-bono), a difesa della tutela del software libero.
I detentori dei diritti d’autore del software si rendono disponibili a fornire autorizzazioni esplicite rivolte alla applicazione di varianti di applicazione delle obbligazioni di cui sopra, laddove ci si trovi nella condivisione degli obiettivi sociali per i quali è stato realizzato GlobaLeaks nonché in presenza del pieno rispetto delle logiche di contribuzione aperta e collaborativa proprie dei progetti opensource (come da best practice indicate nella Guida alla Modifica di software opensource preso a riuso o di terzi di Agid).
Come ulteriore nota informativa, in considerazione della diffusione d’uso della licenza EUPL 1.2 nella pubblica amministrazione, condividiamo come la lista di compatibilità distribuita dalla commissione europea, specifica la non fattibilità di effettuare “re-licensing” sotto EUPL 1.2 di un software libero basato su AGPL 3.0, mentre consente il contrario (cioè un software EUPL 1.2 può essere “re-licensed” sotto AGPL 3.0).
Redistribuzione del software modificato in Riuso (obbligazioni amministrative)
Le pubbliche amministrazioni devono, secondo quanto stabilito dall’art. 69 Comma 2 del CAD (Codice delle Amministrazione Digitali) rilasciare i software sviluppati in riuso, rendendoli disponibili agli altri enti e a tutto il pubblico in generale.
Fare riuso non significa semplicisticamente “pubblicazione del codice sorgente” ma richiede il rispetto di precise linee guida operative, definite nelle Linee Guida sul Riuso del Software dell’Agid.
In particolare quando si modifica un software opensource di terze parti, con l’obiettivo di adattarlo alle proprie esigenze, sono previste particolari procedure rivolte a massimizzare il contributo dell’ente al progetto opensource principale nel Allegato D: Guida alla presa in riuso di software open source .
Le Regole di Riuso servono per una sensibile riduzione dei costi di manutenzione evolutiva e correttiva per tutta la PA, evitando rischi di lock-in eventualmente praticati in modo ostile da parte di fornitori tramite operatività tecnica che normalmente sfugge alla comprensione di chi si occupa di appalti dal punto di vista prettamente legale e/o amministrativo (es: creare duplicazioni di basi di codice, non allinearle all’ultima versione, adoperare stili di programmazioni disomogenei rispetto al progetto originario, modificare il cuore del software in modo non modulare tale da rendere difficile la reintegrazione delle modifiche, non documentare le modifiche in modo orientato a favorire ulteriori contributi di terzi, integrare librerie con licenze software non libere, etc).
E’ necessario contribuire in modo produttivo e coordinato con il progetto opensource sulla base del quale si effettuano modifiche, arricchendone le funzionalità secondo i paradigmi di programmazione del progetto originario, interagendo con i maintainer per condividere le modalità di contribuzione, impiegare i sistemi di sviluppo collaborativo da questi messi a disposizione, evitare di creare duplicazioni di rilasci software che seguano percorsi di evoluzione diversi fra loro.
Qualora non vengano seguite le linee guida riuso, si va a determinare un danno erariale per la PA, è dovuto un intervento della Corte dei Conti, come definito dal protocollo di collaborazione Team Trasformazione Digitale e Corte Dei Conti. Il ragionamento è semplice, non seguire le linee guida di acquisizione e riuso di software non determina una riduzione, ma un aumento dei costi derivanti da ciò che riguardano le modalità tecniche-operative di progettazione, deployment, manutenzione correttiva, evolutiva nonché di contributo distribuito e collaborativo a tali processi di produzione di conoscenza bene comune.
Fare riuso secondo le linee guida Agid, riduce in modo drastico il TCO (Total Cost of Ownership), con un impatto significativo di riduzione dei costi di manutenzione evolutiva e correttiva, oltreché dei costi di adozione per le PA che volessero adoperare tale software come utenti finali.
Si suggerisce di interagire in modo aperto sin dalla definizione preliminare delle analisi di progetto con il sistema di sviluppo collaborativo GlobaLeaks, di postare sul forum la propria idea/esigenza di miglioramento/modifica così da consentire alla comunità una collaborazione efficiente, aggregando gli sforzi di sviluppo in una direzione comune impiegando assieme il sistema di sviluppo Github, nel rispetto delle prassi di r&d opensource, ribadite dalle linee guida Agid.
Misure Minime di Sicurezza ICT (obbligazioni tecniche-operative)
Le PA sono tenute al rispetto delle Misure Minime di Sicurezza ICT, come da Circolare 18 Aprile 2017 n 2/2017 implementando numerose misure organizzative nonché tecniche-operative volte alla tutela del patrimonio informativo aziendale.
In relazione ai progetti di riuso di software, è doveroso sottolineare l’esigenza di compatibilità con le Misure Minime di Sicurezza ICT che prescrivono al controllo 4.5.1 del “Modulo di Implementazione” l’installazione degli aggiornamenti software delle applicazioni.
Laddove il software messo in riuso sulla base di GlobaLeaks fosse una edizione non più aggiornata/allineata alla edizione principale del software, tutti coloro che lo adottassero potrebbero trovarsi nella impossibilità di installare patch ed aggiornamenti, oltre a non beneficiare dei continui miglioramenti di sicurezza necessari ad affrontare le minacce di cybersecurity in continua evoluzione.
GlobaLeaks, dalla major version 3.0, dispone di un sistema automatico di notifica degli aggiornamenti disponibili, al fine di coadiuvare il rispetto delle Misure Minime di Sicurezza ICT.
Il responsabile della struttura per l’organizzazione, l’innovazione e le tecnologie, come indicato nel CAD (art. 17 ) o, in sua assenza, del dirigente designato, deve verificare la compliance dei software adottati dall’ente rispetto alla disponibilità degli aggiornamenti di sicurezza tanto intesi come manutenzione correttiva quanto come manutenzione evolutiva, privilegiando l’uso di edizioni software ampiamente diffuse, utilizzate e oggetto di test sicurezza informatica
Linee guida per lo sviluppo del software sicuro
GlobaLeaks implementa un processo di sviluppo del software sicuro, seguendo best practices internazionali, documentando tutte le scelte di design nonché implementative di dettaglio in documentazione oggetto di revisione pubblica.
Le PA che effettuano, o fanno effettuare, sviluppi software devono attenersi alle Linee Guida per lo Sviluppo del Software Sicuro e, in tal senso, rispettare il software development lifecycle di GlobaLeaks in tutte le proprie operatività di riuso.
Attraverso l’esecuzione del progetto inclusiva della integrazione delle modifiche apportate nella edizione principale del software, anche secondo quanto dettagliato nella Guida alla presa in riuso di software open source, è possibile rispettare le linee guida di cui sopra, coerentemente operando secondo gli standard di sicurezza del progetto GlobaLeaks.