[LG-SW] Allegato E: Guida alla modifica di software Open Source di terzi

Collegamento:
https://lg-acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/latest/attachments/allegato-e-guida-alla-modifica-di-software-open-source-preso-a-riuso-o-di-terzi.html

Contenuto:
Allegato E: Guida alla modifica di software Open Source di terzi

  1. Modifica di software open source di terzi
  2. Modifica del codice sorgente
  3. Interazione con il maintainer del progetto originale
  4. Pubblicazione del codice

Stando alla lettera del testo, nell’interazione con il mantainer il fornitore dovrebbe utilizzare un account fornito da o aperto per conto dell’amministrazione.

Nel caso di interazione con community open source nella mia esperienza quando il fornitore si è già accreditato in passato come interlocutore affidabile presso la community, ottiene più facilmente attenzione e collaborazione presentandosi con la sua identità già nota alla community.

In questi casi sarebbe utile lasciare al fornitore la possibilità di utilizzare le proprie credenziali, imponendo naturalmente che ogni contributo in termini di codice, correzioni, pull request ecc. siano “etichettate” come fatte da “XYZ per conto dell’Amministrazione ABC”. L’accesso al repository sarà garantito anche ad un account dell’amministrazione, che potrà continuare a gestire o delegare ad altro fornitore alla scadenza del contratto.

stai parlando di fornitori in house (quindi organismi pubblici che potrebbero avere un loro accout) oppure fornitori privati?
in quali casi c’è un fornitore privato che ha già una community su un software realizzato su commissione di una PA? e se la PA decide di cambiare il mantainer (passando da un soggetto privato ad un altro)?

Par. 8,3

  • la modalità di contribuzione alla community originaria dovrebbe essere quella prioritaria quindi dovrebbe precedere anche in ordine logico l’attuale paragrafo 8,2.

Par. 8.4

  • sarebbe opportuno precisare come viene gestito il fork dal punto di vista della pubblica amministrazione.

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

Facendo seguito al commento relativo al punto 2 sui possibili comportamenti scorretti da parte di fornitori (e amministrazioni inconsapevoli o compiacenti) rispetto alla creazione di FORK, siamo a integrare richiesta di specificazione necessaria e ulteriore di questa sezione.

Allegato-E: 3. Interazione con il maintainer del progetto originale

L’amministrazione dovrebbe DOCUMENTARE tutte le interazioni con il maintainer in un apposito documento, così da fornire un chiaro riferimento rivolto alla integrazione delle modifiche nel software originario, e questo includere:

  • Ticket/Issues aperti
  • Discussioni da archivi di mailing list
  • Log di Chat (ove presenti archiviazioni di chat nel progetto originale)
  • Draft/design document di integrazione con il progetto per la sua estensione

L’esistenza di questa documentazione inerente gli sforzi del Fornitore a interagire con il Maintainer è necessaria ai fini di due diligence, cioè a consentire in seguito a tutte le terze parti di verificare che l’articolo 3 (Allegato-E) sia stato rispettato.

Questa forma di “audit log” comportamentale è necessario poiché il mancato rispetto di questo modus operandi può comportare un danno per le casse dello stato a seguito di un comportamento “malizioso” del Fornitore, quindi divenire parte di contenziosi civili o penali (ivi inclusi, ad esempio, interventi della corte dei conti o della giustizia civile).

Questo “audit log” dovrebbe divenire parte del README pubblicato di cui all’art 4 (Allegato-E).

Allegato-E: 4. Pubblicazione di codice open source non già a riuso

L’amministrazione dovrebbe evidenziare in modo chiaro in tutti gli elementi di comunicazione tecnica, quindi non solo nel file README, se il software in riuso è stato allineato o meno con il software opensource su cui è stato basato.

E’ fondamentale e rilevante che tutte le amministrazioni abbiano CHIARA COGNIZIONE E CONSAPEVOLEZZA che ogni contributo al “software in riuso” debba essere portato tramite gli strumenti del “software opensource” avendo l’amministrazione originale operato un intervento virtuoso secondo quanto indicato nell punto 4 (Allegato-E) .

Si ritiene NECESSARIO aggiungere l’obbligatorietà per i software in riuso, di un rendiconto con periodicità almeno annuale, relativo agli sforzi di integrazione relativi alle modifiche apportate per il progetto “in riuso” all’interno del “software opensource di terzi” .

Ciò è necessario affinché il Fornitore e l’amministrazione trovino più “conveniente” evitare il FORK (quindi disincentivare il fork) contribuendo e creando valore.

Questo rendiconto annuale di sforzi di reintegrazione delle modifiche nel software principale, al pari di quanto su indicato per il punto 3 (Allegato-E), può avere valenza ai fini giuridici laddove si ravveda un comportamento scorretto del fornitore e ci sia un contenzioso portato in giudizio (civile, amministrativo o penale).

Questo rendiconto dimostra l’intenzione di seguire un percorso virtuoso di reintegrazione e distribuzione del costo di manutenzione evolutiva e correttiva secondo la filosofia e modus operandi opensource.

Le caratteristiche minimali del rendiconto dovrebbero essere specificate, quali ad esempio:

  • Le analisi tecniche effettuate
  • Le discussioni ulteriori effettuare per la reintegrazione
  • I risultati conseguiti di reintegrazione
  • Le stopping issues

Confidiamo che siano introdotte queste esigenze di rendicontabilità del modus operandi e rendicontabilità periodica degli sforzi di integrazione delle modifiche nei software opensource di terzi, come incentivo al contributo alla tecnologia bene comune, disincentivo a “lock-in sostanziali” operati da fornitori e trasparenza dell’operato dei Fornitori.

@ggentili Mi stavo riferendo alla adozione di software open non rilasciato da PA, una delle due casistiche previste dal par.1 dell’allegato:

[…] software open source esistente, sia rilasciato da altre Pubbliche Amministrazioni italiane sia sviluppato e mantenuto da soggetti terzi

In questo caso individuare un fornitore già inserito e capace di “muoversi” nella community di riferimento può fare una grande differenza.