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.