Leg-git! Usare git per progetti legali

Il programma git (minuscolo) è stato creato da Linus Torvalds apposta per gestire e governare lo sviluppo collaborativo di Linux, il software al centro della famiglia di sistemi operativi più diffusa al mondo e probabilmente il più grande progetto software di sempre. Si può usare git per documenti legali (contratti, leggi)? La risposta è sì.

Cos’è git

Git è un programma che, tra le molteplici cose che fa, gestisce le revisioni. Word lo fa allo stesso modo? No, lo fa molto, molto peggio. Git gestisce le revisioni di gruppi di lavoro di migliaia di sviluppatori, in modo gerarchico, distribuito, documentato, creando branch illimitate. È infatti un “distributed version control system” (sistema distribuito di controllo di versioni). Git funziona su testo semplice (plain text). Un progetto git è una directory dove sono ospitati i file di quel progetto. Tipicamente questa directory è un clone di un identico (o quasi) progetto online. La copia online (sia essa pubblica o privata) viene chiamata “upstream” (indica dunque flusso in salita). Lo sviluppatore quando decide di creare un file, lo crea localmente. Esso poi passa attraverso diversi stati, ma per quello che qui ci serve, l’ultimo è “commit”.

Commit significa “mi affido a”; i file vengono modificati localmente, ma non tutte le modifiche vengono condivise appena salvate. Quando lo sviluppatore è soddisfatto di un pezzo di modifiche operate, tramite il commit non solo segnala che la modifica è pronta ad essere condivisa, ma comunica a tutti cosa è stato modificato: infatti, ogni commit ha un suo commento (obbligatorio), oltre a contenere l’informazione di chi ha operato la modifica. Ogni commit viene registrato secondo una linea temporale tendenzialmente non alterabile (i commit successivi “modificano” quelli precedenti). Viene inoltre registrato chi ha operato quel commit. In questo modo è possibile risalire allo stato di un progetto come si presentava ad ogni specifico commit e chi ha apportato ogni singola modifica. Esiste infatti un comando git blame (“do la colpa”) che fa sì che dato un determinato file, è possibile sapere chi ha contribuito a quel particolare pezzo, quando e con quale commit.

Ma non tutti i commit di chiunque finiscono nel progetto “vero”. Se chi opera il commit ne ha sufficienti diritti, la modifica potrebbe essere registrata senz’altro. Ma tipicamente quando i progetti hanno più sviluppatori, solo alcuni decidono cosa va nel codice “buono” e cosa no. In ogni caso, tipicamente la “copia buona” non viene toccata se non quando i tempi sono maturi, mentre tutti i commit arrivano su una versione di lavoro. La divisione di queste versioni si chiama “branching”. Si creano infatti branch (rami) diversi che contengono lo stato del progetto a seguito di alcuni commit, mentre altri commit saranno in altri branch e ciascuno non interferirà con gli altri, sino a che non sarà il momento di metterli assieme. Il lavoro di importare le modifiche dai branch di lavoro a quello “buono” si chiama merge (e il comando è git merge).

Con questa modalità, chiunque ha il diritto di modificare il codice come gli aggrada. Poi le sue modifiche potranno essere proposte upstream e ‒ se ritenute valide ‒ incorporate nel progetto. Git riesce a tenere traccia di tutte queste modifiche, anche se apportate contemporaneamente da più persone, senza che nessuno rovini il lavoro di altri, seguendo ciascuno un ramo diverso ed avendo qualcuno a governare questa complessità attraverso il merge.

Git in ambito legale: le basi

È evidente che questo processo è molto simile a due situazioni che in campo legale vedono più soggetti operare su uno stesso documento legale: la legge e un contratto. Per la legge il processo è molto simile: un soggetto propone un testo, un altro propone di cambiarlo, tramite un emendamento. Questo emendamento viene discusso e se approvato viene incorporato. Si potrebbe usare git per questo.

Follia?

No, in realtà c’è già chi lo fa. Nel District of Columbia (lo Stato che contiene Washington, la capitale) il processo legislativo è già non solo affidato a git, ma addirittura reso pubblico, per cui chiunque può fornire una patch a un testo. Ne parla Ars Techinca in un suo post. In questo caso, una semplice correzione. Nulla impedisce che correzioni più sostanziose vengano fornite da un ristretto gruppo di utenti registrati (sia legislatori che gruppi di interesse), rendendo così trasparente chi abbia fornito quale parte del testo. Il sito dove è ospitata la legislazione del District of Columbia è questo.

Git per redigere collaborativamente contratti

Lo stesso può avvenire per un contratto. In un contratto Tizio scrive una bozza, Caio la corregge e fornisce la sua versione. Se Tizio e Caio sono due avvocati che seguono il bon ton usato in tutto il mondo, la versione mostrerà chiaramente le modifiche, tramite la funzione di “track changes” (revisioni, detta anche “redline” in gergo), dove le parti cancellate sono marcate con una linea sovrascritta e quelle nuove sono in grassetto e in un colore diverso. Ciò è però lasciato al buon cuore e alla buona fede dell’altra parte. Inoltre, dopo un paio di iterazioni di questo processo (magari perché il documento va dall’avvocato alla parte, poi ancora all’avvocato, da questi all’altro avvocato, alla parte, eccetera), ci si ritrova con un documento praticamente illeggibile. Inoltre, trasmettendo questo documento avanti e indietro, si creano decine di copie, nessuno capisce qual è l’ultima, chi ha proposto cosa e quando, per identificarle si usano nomi di fantasia, insomma, un macello. Non è poi possibile modificare una parte del contratto che magari si è discussa e approvata, fino a che non si riceve la versione dell’altra parte (il processo di revisioni è seriale, non parallelo). Se poi le parti sono più di una, il flusso delle modifiche è tutto tranne che ovvio, spesso in queste situazioni vi sono incongruenze e sovrapposizioni, difficili da ridurre a sistema.

Con git questa cosa si può risolvere condividendo un progetto git su una piattaforma privata accessibile da tutte le parti coinvolte. Ne esistono online (Github è la più famosa, recentemente acquistata da Microsoft) e anche open source (Gitlab, ad esempio), che possono essere ospitate da un server privato accessibile via VPN per maggiore sicurezza.

Le parti a quel punto potranno avere ciascuna una propria branch in cui propongono le proprie modifiche. Alla fine le modifiche potranno essere accettate o rigettate in un merge senza perdere le informazioni di chi le abbia proposte. Tutta la storia delle revisioni rimane a futura memoria. Non solo, rimane a disposizione di tutte le parti, perché ne avranno fatto un clone locale.

Nessuna delle parti può impunemente modificare una parte senza che l’altra se ne accorga, perché esse sono verificabili e tutte le informazioni sono a disposizioni di tutti. Alterare la storia dei commit è sì possibile, ma git se ne accorge subito una volta che le modifiche vengono importate localmente (git pull).

Attualmente sto usando questo metodo con alcuni clienti attivi nello sviluppo software, e dunque usiamo uno strumento a loro familiare. Utilizzarlo per trattative richiederebbe invece qualcuno disposto a utilizzare lo strumento e a imparare a usarlo; servirebbero inoltre ulteriori accorgimenti e procedure per dare maggiore certezza a tutte le parti. Ci penseremo.

Strumenti

Questo punto è molto tecnico, può essere saltato. Dà un’idea di come si possa utilizzare git in pratica, quali strumenti sia consigliabile utilizzare, preferibilmente su una macchina Linux (perché, usate qualcos’altro?).

Git non gestisce bene i file binari. Word, LibreOffice, e simili usano file binari, anche se il formato attuale è un XML (ma è zippato). Libreoffice può in realtà usare un formato non zippato, ma essendo un XML piuttosto complesso, comprende moltissime informazioni non legate al contenuto. Lo uso in git, ma si perde assai dell’utilità dello strumento.

Il formato strutturato, ma sempre testo semplice, utilizzato dai più è Markdown. Markdown ha il pregio di essere leggibile anche da un essere umano che non conosca la sintassi, molto meglio di altri formati, come l’XML (nella sua variante nota come HTML, ad esempio, il formato di base del World wide web). Strutturato significa che gli elementi del testo non sono tutti uguali, si riesce a distinguere un’intestazione da testo di paragrafo, un elenco puntato o numerato, testo enfatizzato, una lista di definizioni, un rimando ipertestuale, eccetera, tutto scritto, senza levare le mani dalla tastiera. Markdown ha anche il vantaggio di essere il linguaggio preferito per la documentazione degli sviluppatori. Questo articolo è stato scritto in Markdown.

Essendo puro testo, qualsiasi editor di testi va bene. Io uso Atom, prodotto da Github, che ha il pregio di essere enormemente estensibile, ovviamente implementa le regular expression le quali sono incredibilmente potenti nel modificare il testo, non solo sostituendolo in blocco, ma anche riutilizzando parti già esistenti. Ciò meriterebbe un articolo a sé. Atom inoltre riconosce se la directory corrente è un progetto git, consentendo di fare commit e push direttamente all’interno dell’applicazione. Inoltre, per ciascun file modificato, consente vedere se il file è aggiunto alla coda per il commit (staged) e in ogni caso permette di visionare le modifiche operate rispetto all’ultimo commit di quel file.

Infine, consente di risolvere tutti quei casi in cui una stessa riga è stata modificata da due autori diversi, creando un conflitto di versioni che git non è in grado di risolvere autonomamente, evidenziando quale parte della singola linea è differente tra le due versioni.

Markdown di per sé non consente di fare riferimenti incrociati legati alle numerazioni di paragrafo, una cosa piuttosto semplice in LibreOffice (un po’ meno in Word). Entra pertanto in scena Pandoc e un suo modulo: pandoc-crossref. Pandoc è un programma che converte formati documentali in altri formati documentali. In questo caso, Markdown può essere convertito in ODF, Office, PDF, HTML, eccetera. Sfruttando la potenza degli script di Linux, anche tutti in una sola passata. Usando una sintassi abbastanza semplice, ogni intestazione in Markdown può avere un suo riferimento univoco. Un esempio della parte più complicata da leggere in un file Markdown così creato:

# Appointment {#sec:art_appointment}
[SOW]: #sec:art_appointment
[Committed Sprints]: #sec:art_appointment

Il carattere # all’inizio della riga significa che il paragrafo è un’intestazione. Essendovene uno, significa che è un’intestazione di primo livello (il livello più alto). La parte tra parentesi graffe non viene visualizzata nel documento finale convertito da Pandoc: Serve a pandoc-crossref per identificare univocamente questa intestazione, consentendo così i riferimenti incrociati (vedi oltre).

La seconda e la terza riga sono anch’esse funzionali ai riferimenti incrociati. Scrivendo nel testo [SOW], automaticamente Pandoc creerà un hyperlink a quella sezione. Dunque potrò cliccarci sopra e essere rimandato alla sezione sopra riportata.

La sezione introdotta dall’intestazione viene anche numerata. Pertanto io potrò inserire nel testo un riferimento incrociato numerale, così:

Secondo quanto affermato nell'[@sec:art_appointment]

Verrà convertito in

Secondo quanto affermato nell’articolo 6

Tutto questo armamentario non è strettamente necessario per poter lavorare sul documento. Se si conosce la sintassi, le modifiche possono essere effettuate con qualsiasi editor, salvo poi ricostruire il documento “finale” su un computer dotato dei necessari strumenti. Anche nel formato di testo, comunque, i riferimenti interni sono leggibili e univoci. Teoricamente, le parti potrebbero semplicemente firmare digitalmente il file Markdown, che sarebbe un contratto perfettamente leggibile e valido. E non più link interrotti!

Significato, non presentazione

Concludo con una considerazione sulle tecniche di redazione dei documenti. In venticinque anni in cui ho corretto documenti (legali e non) di almeno un paio di centinaia di collaboratori, clienti, controparti, noto salvo eccezioni un tratto comune.

WYSIWYG è una sciagura. Significa What You See Is What You Get. È il paradigma di Word e di tutti i wordprocessor creati e diffusi a partire dalla metà degli anni ’90. Ti fa vedere, mentre lo scrivi, come il tuo documento apparirà. Ciò viene abusato dai più, i quali non si curano tanto del cosa un particolare paragrafo o parte di esso rappresenta semanticamente, ma usano le formattazioni per rendere il documento bello alla vista, senza però alcuna struttura. Invece diverse rappresentazioni grafiche dovrebbero corrispondere a diverse funzioni del testo. Lo stesso uso del termine “grassetto” è indicativo. Il grassetto in realtà è un modo per dare enfasi, segnalare la particolare importanza del testo. In HTML si usava il tag <b>, mentre ora, con il web semantico, si usa <strong>. Andare a capo significa che quella parte di testo è finita e ne inizia un’altra. Un paragrafo vuoto è un non senso (in Markdown una riga vuota significa “nuovo paragrafo”). Lo stesso vale per l’intestazione del capitolo (ancora più importante), e per le intestazioni di livello gerarchicamente superiore e inferiore.

Markdown costringe a pensare a tutto questo funzionalmente, non tanto e non solo, e non principalmente, a come apparirà. La presentazione è in un foglio di stile separato. Ma quando si scrive un testo è importante sapere cosa si scrive e quale ruolo tale parte ha nel testo globale. Non cosa apparirà: quello è sovrastruttura, distrazione, eventualità. Tutti i formati puramente testuali hanno questa caratteristica e sono pensati per dare struttura, non apparenza, mentre si scrive. Il paradigma è dunque WYSIWYM: What You See Is What You Mean, quello che vedi è ciò che intendi.

Conclusioni

Ho iniziato con git per finire alla semantica dei testi dattiloscritti. Un bel salto! Ciò non toglie che, pur non essendo necessariamente questa la strada per scrivere testi legali in maniera più sensata, è importante pensare che un legale debba quantomeno esplorare strumenti tecnici più elaborati e potenti del semplice word processor.

Alcuni studi stanno già tentando la strada dell’intelligenza artificiale. Altri stanno ripensando a un modo di utilizzare basi di conoscenza per automatizzare e facilitare la scrittura di documenti legali. In Array abbiamo (Alberto Pianon, principalmente) sviluppato un progetto per automatizzare la due diligence nella compliance open source di progetti soprattutto per applicazioni embedded, con il quale offriamo ai clienti strumenti che possono implementare essi stessi.

Pensare di poter svolgere la professione come quasi tutti facevano negli anni ’90 non è più possibile. Occorre svegliarsi e trovare nuovi strumenti, nuovi modi per creare valore per i clienti. Questo è uno.

Ringrazio per i preziosi contributi gli Avvocati Alberto Pianon e Marco Ciurcina.