[LG-SW] 3. Linee Guida sul riuso del Software (art. 69)

Consultazioni pubbliche LG acquisizione e riuso di software per la pa
1

Collegamento:
https://lg-acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/latest/riuso-software.html

Contenuto:
3. Linee Guida sul riuso del Software (art. 69)
3.1. Introduzione e contesto normativo
3.2. Modello di riuso
3.3. Developers Italia e la ricerca di software in riuso
3.4. Processo di messa a riuso del software sotto licenza aperta
3.4.1. Scelta di uno strumento di code hosting
3.4.2. Registrazione del software aperto su Developers Italia
3.4.3. Responsabilità connesse al rilascio
3.5. Licenze aperte e scelta di una licenza
3.5.1. Contesto
3.5.2. Licenze per il software aperto
3.5.3. Scelta di una licenza
3.6. Rilascio di software esistente sotto licenza aperta
3.7. Sviluppo di software ex-novo
3.7.1. Rilascio di nuovo software sotto licenza aperta
3.7.2. Acquisizione della titolarità di software sviluppato ex-novo
3.8. Manutenzione di un software da parte dell’amministrazione titolare
3.8.1. Titolarità del codice sviluppato in fase di manutenzione
3.8.2. Rilascio sotto licenza aperta delle modifiche
3.8.3. Supporto alle amministrazioni che riusano
3.8.4. Software non ancora rilasciato sotto licenza aperta
3.9. Riuso di un software o utilizzo di un software Open Source
3.9.1. Utilizzo di software a riuso o Open Source
3.9.2. Modifiche ad un software a riuso o Open Source

2

Come discusso in una web conference con alcune Regioni e Città metropolitane, moderata da Alessandro Ranellucci del Team Trasformazione Digitale, sarebbe utile includere nel materiale da porre in riuso anche tutto quello che software non è. Studi, analisi di processo, studi di fattibilità, valutazioni comparative ex art. 68 CAD, ecc., in pratica tutto ciò che contiene contributi di pensiero a valore aggiunto ma che poco si presta ad essere accolto in un repository di code hosting.

3

3.4.3. Responsabilità connesse al rilascio
L’amministrazione titolare del software non contrae alcun obbligo specifico legato al rilascio: non è infatti necessario fornire alcuna garanzia sul software, supporto tecnico o a livello utente, né tantomeno supportare economicamente le amministrazioni che riusano il software nei costi o nelle procedure di adozione.

Il paragrafo è certamente corretto, e si richiama ai tipici testi a termine delle piu comuni licenze software.
Suggerirei una unica eccezione in cui la PA sia resa responsabile dell’eventuale pronta notifica a mezzo Sistema di ticketing di malfunzionamenti e vulerabilità e fallimenti critici.

4

nel capitolo 3.8.2 viene usato il termine “repositorio”. Non so neanche se come traduzione sia corretta, in ogni caso, a mio avviso meglio mantenere il termine “repository” già introdotto nei capitoli precedenti. Eventualmente si potrebbe inserire nel glossario (cap. 1.7) una definizione dei termini “repository” e “code hosting”.

5

Nel capitolo 3.6 si sottolinea che gli obblighi valgono anche per i software preesistenti, compresi i software dismessi da meno di 5 anni.
Ma se un software è dismesso anche solo da un anno, anche se di proprietà dall’Amministrazione, quasi certamente non esiste più un contratto di manutenzione in essere e pertanto, il rispetto di quanto previsto all’Allegato B per la pubblicazione potrebbe non essere più realizzabile, se non a fronte di una nuova spesa da parte dall’Amministrazione per operare un adeguamento “documentale” su un sistema non più in uso. Ovviamente, il problema aumenta man mano che ci si avvicina ai 5 anni indicati come limite.
Per quanto sia auspicabile recuperare tutto l’esistente, andrebbe forse esplicitato meglio cosa fare in questi casi limite. Potrebbe essere ammissibile la pubblicazione di quello che è disponibile, anche se non nella forma richiesta, che non richieda ulteriori investimenti?

6

Nel capitolo 3.8.2 non è chiaro se è obbligatorio da parte dall’Amministrazione attivare il tipo di supporto previsto all’ultimo paragrafo (e poi descritto dettagliatamente nell’Allegato C). Questo aspetto, ancorché auspicabile, ha una ricaduta economica importante sui contratti di manutenzione e l’obbligatorietà potrebbe essere una grossa criticità per un’Amministrazione proprietaria di un software (o parte di un software) anche in considerazione di quanto previsto dal capitolo 3.4.3, dove si dice che non è obbligo fornire alcun supporto tecnico.

7

Par. 3.2

  • le attività ed i costi relativi all’analisi di riuso devono essere comunque considerati tra le voci di costo del TCO. A volte l’analisi di software in riuso e open source può risultare molto oneroso.

Par. 3,3

  • rispetto alla registrazione su Developers Italia e l’inserimento nel relativo motore di ricerca, per adeguare e rendere comunque operativo il sistema sarebbe comunque utile verificare se anche a livello di singolo repository sia ipotizzabile/introducibile un sistema di metadazione utile a permettere una identificabilità tramite i motori interni e/o i motori di ricerca generici.

Par. 3.4

  • si ritiene essenziale segnalare che la licenza va identificata e confermata in corso di sviluppo, NON in fase di pubblicazione: in fase di pubblicazione potrà prodursi una soluzione già pronta in ragione delle corrette modalità di sviluppo adottate fin dalla sua prima progettazione.

Par. 3,5,2

  • circa l’indicazione di scegliere una licenza aperta tra quelle certificate OSI, ci si chiede se non sia produttivo introdurre anche un criterio, da seguire ove possibile, anche di tutela dell’investimento pubblico a vantaggio di tutti in quanto tale, ovvero che massimizzi l’apertura anche delle evoluzioni - in ottica precompetitiva - tramite una preferenza verso soluzioni copyleft (anche debole).

Par. 3,5,3

  • scelta licenza AGPL per soluzioni utilizzate via rete: perché in questo caso non si reputa adatta la licenza EUPL, che pure - se bene inteso - include nel concetto di redistribuzione anche la messa a disposizione tramite soluzioni a distanza (v. le definizioni: “Distribuzione e/o Comunicazione: la vendita, la cessione a titolo gratuito, il prestito, la locazione, la distribuzione, la comunicazione, la trasmissione o qualsiasi altro atto finalizzato a mettere copie dell’opera a disposizione di altre persone fisiche o giuridiche, o fornire loro accesso alle sue funzionalità essenziali, on-line o off-line”).?

Par. 3,6

  • rispetto all’indicazione di andare a operare anche con riferimento alle soluzioni già pubblicate a riuso secondo le precedenti previsioni del 69 CAD, si suggerisce una soluzione più articolata. Infatti, è assai probabile che rilasciare in open source soluzioni già sviluppate da una PA e già oggi attivamente offerte a riuso secondo i modelli di riuso (sostanzialmente, accordi tra PA) originariamente predisposti non sia esente da costi. È utile quindi valutare di introdurre un distinguo, partendo dal già suggerito censimento degli applicativi, da condursi però non solo al fine di identificare le soluzioni trasferibili in open source, ma anche di definire una stima dei costi relativi. Ciò, al fine di poter effettuare una cernita delle soluzioni rispetto a cui si ritenga utile e/o opportuno effettuare il relativo investimento. Rispetto poi alle soluzioni ad oggi già pubblicate ovvero messe a riuso, nel loro complesso, sarebbe necessario, in altri termini ed in base ai riscontri dedotti dal suddetto censimento, introdurre una modalità alternativa di gestione, utile a preservare, quantomeno, l’attuale messa a disposizione di applicativi per le altre PA (piuttosto che proporne solo il ritiro dal riuso o la loro trasposizione in open source). Ad esempio, potrebbe ipotizzarsi che possa essere conservata una offerta di riutilizzo, non più giuridicamente basata sul 69 CA, ma sostanzialmente configuratesi come una sorta di invito a sottoscrivere accordi di collaborazione ex art. 15 della l. 241/90, ovvero “riusi” rappresentati e sostenuti dall’accordo negoziale stesso, riconducibile ai vecchi modelli di riuso (che potrebbero semplicemente mutare “rubrica” da accordi di riuso ex 69 CAD a accordi ex 241/90). Rispetto a questi, il censimento potrà invece evidenziare quelle soluzioni su cui la PA intende effettivamente investire per “convertirle” in open source, costituendo al contempo il razionale della scelta complessiva;
  • in questo senso, quando si indicano i criteri di esclusione di un software esistente (in regime corrente) da pubblicare in licenza open source oltre al criterio temporale di non superare i 5 anni di vetustà è opportuno definire dei criteri di valutazione costi/benefici da parte della singola pubblica amministrazione, in quanto - come sopra accennato - la pubblicazione del software esistente potrebbe richiedere un adattamento non sostenibile da parte della amministrazione stessa.

Par. 3,7,1

  • rispetto all’invito a sviluppare direttamente sullo strumento di code hosting selezionato, si richiama l’attenzione sul fatto che potrebbe essere da verificare l’opportunità di tale scelta, posto che, pur essendo senz’altro la più trasparente, ma non si è certi che sia anche la più corretta ed opportuna in tutti i casi (di solito non si sviluppano beta locali con rilasci progressivi una volta consolidati un minimo?).

Par. 3.8

  • si deve chiarire molto bene il ruolo del Maintainer della soluzione software in quanto devono essere previsti tutti i costi di manutenzione, adeguamento e supporto alle amministrazioni che intendano riusare il software. Spesso una sola amministrazione non è in grado di sostenere tale onere (le attività di gestione di una community sono superiori alla “semplice” gestione di un software proprietario) e quindi si rischia la morte naturale del software, a meno che le amministrazioni interessate non si accollino parte degli oneri di gestione. Ovviamente accordi di co-sviluppo tra PA interessate può aiutare in tale senso.

Par. 3,8,3

  • l’affermazione “si richiede che le risorse interne o le aziende incaricate di tale manutenzione offrano un supporto” richiede una maggiore precisazione, per non apparire in contraddizione con la precedente affermazione per cui acquisito il codice (tanto più da un repertorio pubblico) lo sviluppo ulteriore è in teoria autonomo e svincolato da lock in; sotto questo profilo, appaiono inoltre rivestire ruoli molto diversi la presenza di soggetti – meglio ancora pubblici come le in house – in grado di fornire un supporto tramite accordi di collaborazione tra soggetti pubblici, rispetto alla presenza di soggetti di mercato in concorrenza tra loro. Al riguardo, peraltro, andrebbe meglio complessivamente approfondito il tema della community, il vero contesto in cui è possibile individuare soggetti in grado di fornire supporto nonché definire una roadmap condivisa e comune per le evoluzioni. In detto contesto meglio può quindi anche essere chiarito il processo di richiesta e supporto al maintainer da parte della amministrazione interessata al riuso, eliminando ogni ambiguità rispetto al tema relativo alla possibilità o meno, ed a quali condizioni, per una PA che riusa di potersi direttamente approvvigionare dal maintainer per il supporto.

Par. 3,9,1

  • in linea con quanto sopra detto, le linee guida appaiono troppo fornitore-centriche: condiviso e presupposto che il prodotto sarà scaricabile da pubblici e privati e la modalità migliore di iterazione potrà essere realizzata proprio attraverso gli strumenti stessi della piattaforma, i contatti di collaborazione a qualsiasi livello andrebbero presi non con il fornitore del caso in quanto tale, che potrebbe cambiare e che opera comunque su incarico di una PA, ma con quest’ultima, magari ciascuno come contributore e/o con il proprio fornitore, in questo contesto, peraltro, gli accordi di collaborazione ex art. 15 L. 241 sono una eventualità e una potenzialità, e non una necessità, nel momento in cui davvero la PA cedente avvia e gestisce efficacemente una community molti coordinamenti possono avvenire quasi spontaneamente tramite la piattaforma. Ed anzi, sotto detto punto di vista e rispetto a community ex ante, il vantaggio è che l’accordo può nascere da una collaborazione già avviata, ovvero già “testata” come conveniente e funzionante.
8

Da parte del Centro Hermes per la Trasparenza e Diritti Umani Digitali:

3.8.3 Supporto alle amministrazioni che riusano

Aggiungere:
Si raccomanda (MAY) la creazione di strumenti di supporto collaborativo, quali in particolare web forum e/o mailing-list, in cui le amministrazioni possano fornirsi supporto vicendevole ai fini di installazioni, configurazioni, personalizzazioni. La conoscenza generata tramite le discussioni sul forum consente la creazione di una knowledge-base collaborativa che coadiuva il meccanismo di auto-supporto, tipico dei progetti opensource comunitari.

11

Commenti alle Linee Guida su acquisizione e riuso di software per le pubbliche amministrazioni

Preparati da Avv. Marco Ciurcina e Avv. Carlo Piana per conto di Assoli ‒ Associazione per il Software Libero ‒ e FSFE ‒ Free Software Foundation Europe.

Algoritmo di scelta

Relazione tra le subfasi della fase 2

L’art. 68 comma 1-ter CAD in realtà non opera distinzioni tra le categorie del software in riuso e il software libero e le pone allo stesso ordine di preferenza. Nemmeno un criterio semantico porta a considerare una soluzione privilegiata rispetto all’altra: il termine “adeguati” utilizzato nel comma 1 si riferisce a tutti i casi trattati nel comma stesso.

Ove vi siano soluzioni sia di software libero sia di software in riuso, pare utile procedere a una valutazione comparativa rispetto a queste categorie, senza fermarsi a quella in riuso, se quella in software libero fosse più adatta e complessivamente migliore. Ad esempio, quella in software libero potrebbe avere una comunità più viva, oppure essere basata su un middleware o un’infrastruttura uguale a quella già adottata dalla PA, eccetera. Privarsi di questa possibilità in assenza di una norma che lo preveda espressamente è illegittimo in quanto contraddice i principi di economicità e di efficienza previsti al comma 1.

Si suggerisce che il fatto di individuare una soluzione in riuso potenzialmente adeguata non sia un punto di uscita dall’albero decisorio, ma dia comunque come esito il passaggio alla valutazione successiva, dovendosi ricercare se non vi siano soluzioni in software libero utilizzabili anche non appartenenti al dominio del riuso, per poi operare una valutazione comparata se più soluzioni passino l’uno o l’altro filtro.

Relazione tra la fase 2 e la fase 3

La fase 2 tiene conto di tutti i requisiti; a p. 16 delle Linee Guida si legge che

“eventuali costi di
personalizzazione, necessari ad assicurare la copertura di tutti i requisiti
funzionali e non funzionali, indispensabili e non indispensabili”).

La fase 3, invece:

  1. tiene conto di tutti i requisiti per la realizzazione ex-novo; infatti a p.
    19 si legge

“La Pubblica amministrazione, dopo aver individuato l’esistenza o meno di
una soluzione proprietaria confacente ai propri bisogni, elabora un documento
contenente un progetto di fattibilità contenente la stima delle attività, dei
costi e dei tempi da sostenere per la realizzazione di una soluzione ex-novo
che soddisfi completamente le esigenze indicate nel documento sull’analisi
dei fabbisogni così come descritto nella “Fase 1.1: Analisi del
fabbisogno”.”

  1. non tiene conto di tutti i requisiti per il software proprietario; infatti a p. 19 si legge

“assicurare la soddisfazione dei requisiti funzionali e non determinati
nella Macro fase 1, garantendo il soddisfacimento di quelli indispensabili,
con quelli indicati nella documentazione”.

Apparentemente, questo algoritmo può essere aggirato facilmente: è sufficiente prevedere nella fase 1 dei requisiti non indispensabili che non sono disponibili in nessuna soluzione in riuso e software libero per passare serenamente alla fase 3 saltando la 2 e quindi preferire software proprietario (che non deve soddisfare tutti i requisiti). C’è qualcosa da correggere. Per esempio, si può prevedere che se non esiste una soluzione proprietaria con tutti i requisiti previsti nella fase 1, si riapre la fase 2 valutando solo i requisiti indispensabili per software in riuso e software libero. Oppure si chiarisce che la valutazione make della fase 3 è limitata ai soli requisiti soddisfatti dalla migliore soluzione proprietaria e riguarda anche il caso in cui si personalizza del software in riuso o software libero.

Responsabilità

Si ritiene che vada posta più attenzione al tema della valutazione di conformità legale.

Qualsiasi attività di realizzazione di software soggetto a riuso determina obbligatoriamente una distribuzione. Pertanto, quando si commissiona software sviluppato ad hoc che comporti l’utilizzo di componenti di terze parti, occorre che il software “inbound” abbia condizioni di licenza o di titolarità compatibili con la licenza del software in uscita. Si suggerisce pertanto di prevedere che i contratti di appalto tengano conto di quanto sopra, obbligando il fornitore a svolgere la valutazione di conformità ed a documentarne gli esiti alla PA appaltante.

Anche chi riusa il software deve svolgere una valutazione di conformità, soprattutto se:

  1. chi riusa distribuisce il software, o
  2. il software che si riusa o le dipendenze di questo sono disponibili
    secondo i termini di licenze network copyleft.

Ma il problema della valutazione di conformità legale va gestito anche se non ci sono licenze copyleft. È necessario mantenere le copyright notices, accompagnare il codice con il testo delle licenze quando è richiesto, ecc…

Chi realizza software che viene rilasciato in riuso e chi riusa si deve porre il problema della valutazione di conformità legale e le Linee Guida dovrebbero dirlo chiaramente.

Si ritiene anche utile indirizzare gli enti a risorse di supporto nella realizzazione della valutazione e delle azioni da intraprendere (tools, specifiche come Openchain, ecc.).

Forse potrebbe essere utile prevedere una sorta di “certificazione”: se una PA svolge l’analisi, potrebbe documentare gli esiti della stessa analisi (nel portale developers?) perché siano disponibili alle altre PA.

Mutualizzazione dei costi

Riteniamo che un generico invito alle PA a collaborare per mettere a fattor comune scelte di sviluppo e licenza di nuove soluzioni sarebbe utile. Ci rendiamo conto che non è un risultato che può discendere dagli artt. 68 e 69 (questo è un problema delle norme, non delle Linee Guida) ma, anche senza intervenire sulle norme, si potrebbero costruire policy, incentivi e pratiche che favoriscono la collaborazione tra le PA per sviluppare e distribuire software libero utile a molte PA.

1 Mi Piace