Francesco Rampone
Presidente Associazione Blockchain Italia
Quest’opera è distribuita con Licenza
Creative Commons Attribuzione – Non commerciale – Non opere derivate 4.0 Internazionale
14 febbraio 2020
Linee guida AgID e il paradosso della forma scritta
1. Premessa.
C’è grande attesa per le linee guida dell’AgID.
Non ne capisco tuttavia il motivo poiché ci diranno solo quali soluzioni tecniche devono essere adottate per conferire valore giuridico agli smart contract. Indicheranno insomma alcuni aspetti tecnico-formali, ma non incideranno affatto sulla sostanza già decisa dal legislatore, ovvero che una dichiarazione espressa su una DLT ha un effetto probatorio maggiore di una comune email.
Il punto interessante, invece, almeno da una prospettiva legale, è decifrare il contenuto dell’art. 8-ter, comma 2, del Decreto Semplificazione 2018 (Decreto Legge 14 dicembre 2018, n. 135). Al riguardo ho sempre detto di non voler essere nei panni dei tecnici dell’AgID – e ora pare anche dei colleghi dell’Avvocatura dello Stato – che devono sbrogliare l’impossibile matassa consegnata dal legislatore[1].
Per capire che razza di problema hanno tra le mani, prima che siano pubblicate le linee guida che ci diranno come uno smart contract possa soddisfare la forma scritta (pare che siano in dirittura di arrivo), voglio prendere una posizione ed esprimere i miei dubbi sulla utilità e coerenza giuridica della norma.
2. Cosa è scritto nell’art. 8-ter del Decreto semplificazioni 2018.
Iniziamo ovviamente dalla definizione di smart contract adottata dal Decreto recante «Disposizioni urgenti in materia di sostegno e semplificazione per le imprese e per la pubblica amministrazione»:
«Si definisce “smart contract” un programma per elaboratore che opera su tecnologie basate su registri distribuiti e la cui esecuzione vincola automaticamente due o più parti sulla base di effetti predefiniti dalle stesse» (art. 8-ter, comma 2, primo periodo, enfasi aggiunta).
Da qui possiamo già dire che uno smart contract non è un contratto ma un programma per elaboratore; è cioè una sequenza di istruzioni rivolte ad una macchina, evidentemente scritte in un codice da questa eseguibile[2].
Quanto all’inciso «sulla base degli effetti predefiniti dalle stesse», poiché gli utenti, in genere, non partecipano alla stesura di uno smart contract prima di eseguirlo, né comprendono il significato del codice anche laddove potessero leggerlo, la “predefinizione degli effetti” deve essere intesa in senso restrittivo, come mera selezione delle variabili dello smart contract per indirizzare la sua esecuzione, proprio come la selezione sul pannello di un distributore automatico fa sì che questo eroghi il prodotto scelto[3].
Se l’art. 8-ter si fosse fermato qui, avremmo avuto poco da obiettare, a parte alcune considerazioni generali in ordine al crescente fenomeno della contrattazione di massa che relega sempre più il consumatore-utente ad un ruolo passivo nei confronti dei fornitori dei servizi della società dell’informazione[4].
Purtroppo però, l’art. 8-ter, è andato oltre, e così prosegue:
«Gli smart contract soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate, attraverso un processo avente i requisiti fissati dall’Agenzia per l’Italia digitale con linee guida da adottare entro novanta giorni dalla data di entrata in vigore della legge di conversione del presente decreto» (art. 8-ter, comma 2, secondo periodo, enfasi aggiunta).
Ebbene, la forma scritta è un attributo di un contratto ai sensi dell’art. 1325 c.c. e di altri atti indicati all’art. 1350 c.c., non di un programma per elaboratore! È qui che il ragionamento sotteso alla disposizione in commento diventa discontinuo, evidentemente viziato dal nomen, e quindi dall’aver erroneamente inteso lo smart contract come un contratto.
3. Il primo paradosso.
Questo il sillogismo espresso dalla norma:
- tutti gli smart contract sono programmi per elaboratore;
- gli smart contract (a certe condizioni) soddisfano la forma scritta;
- la forma scritta è attributo di atti e contratti[5];
quindi:
- i programmi per elaboratore sono atti e contratti, sono cioè atti umani o manifestazioni di volontà che assumono rilevanza per l’ordinamento giuridico.
Come si nota, la conclusione sub D) è paradossale. Tanto più se consideriamo un elemento niente affatto secondario, e cioè che il contenuto di uno smart contract non è quasi mai intellegibile alle parti e non può quindi costituire espressione della loro volontà: non può cioè essere nemmeno un atto umano, trattandosi semmai di un fatto, ovvero un elemento esterno che preesiste rispetto alla volontà e coscienza delle parti (è lontanamente paragonabile ad un modulo o formulario ex art. 1342 c.c. scritto in una lingua incomprensibile all’aderente). Come ho sottolineato molte volte, uno smart contract è un’istruzione rivolta ad una macchina e non un medium del dialogo tra esseri umani che invece si svolge sul differente piano del linguaggio naturale.
Sono certo che il ritardo dell’AgID nell’emanare le linee guida sia dovuto alla difficoltà di risolvere questo evidente paradosso che il legislatore ha consegnato loro delegandogli opportunisticamente il compito di risolverlo.
4. Una possibile via di uscita.
L’unico modo che l’AgID ha per uscire dall’impasse mi pare sia quello di dividere il problema in due. Da un lato considerando lo smart contract per quel che è, cioè una vending machine in forma digitale, un programma per elaboratore appunto, il quale non integrando alcuna volontà delle parti non pone un problema di forma scritta.
Dall’altro riconoscendo all’atto di esecuzione dello smart contract, consistente nella selezione degli elementi variabili da parte dell’utente, la natura di atto giuridico riconducibile alla volontà umana, questo sì esprimibile in forma scritta.
Ecco quindi che lo smart contract non può avere forma scritta in quanto non è un atto o un contratto, ma solo un ingranaggio digitale. Al contrario, forma scritta può averla la manifestazione di volontà delle parti in ordine alla determinazione degli effetti («effetti predefiniti dalle stesse», art. 8-ter, comma 2, primo periodo). Solo in questa fase di “riempimento” di contenuti specifici dello smart contract può intervenire un protocollo che conferisca forma scritta (art. 2702 c.c.) alla manifestazione di volontà dell’utente (o delle parti).
5. Il secondo paradosso.
Mi rendo conto che la soluzione sopra prospettata sarebbe solo una scappatoia, altrettanto incongruente quanto il sillogismo del paragrafo 3. Se dobbiamo infatti riconoscere – come effettivamente è – che l’utente ha di fronte una vending machine virtuale e che la sua manifestazione di volontà è limitata al più alle sole variabili da lui selezionate nello smart contract, dobbiamo allora riconoscere che l’art. 8-ter nella sua attuale formulazione estende la forma scritta anche ad elementi che non sono manifestazioni di volontà. Si finisce infatti per attribuire il requisito della forma scritta a cose (la vending machine, aka smart contract) o a fatti e comportamenti (la mera esecuzione di un programma per elaboratore). E questo, ancora non volta, è paradossale.
Mi chiedo perché mai il legislatore abbia sentito la necessità di scrivere l’art. 8-ter, peraltro inserendolo in modo improvvido in un provvedimento dal titolo così poco adatto.
____________________
[1] Segnalo che la mia diffidenza verso la norma in questione non pare essere avvertita in nessuno dei commenti di taglio giuridico che leggo sulle riviste specializzate (p.e.: agendadigitale.eu) che indugiano piuttosto sulla validazione temporale e sui soliti rinvii e analogie con le disposizioni del nel Codice dell’Amministrazione digitale, firma digitale ed elettronica avanzata.
[2] La definizione ancora valida e completa di programma per elaboratore è stata fornita nel 1984 dall’OMPI: «un insieme organizzato e strutturato di istruzioni in qualsiasi forma o su qualunque supporto capace, direttamente o indirettamente, di far eseguire o far ottenere una funzione o un compito o far ottenere un risultato particolare per mezzo di un sistema di elaborazione elettronica dell’informazione» (Working Group on Technical Questions Relating to the Legal Protection of Computer Software – Canberra, dal 2 al 6 aprile 1984). I programmi per elaboratore, se aventi carattere creativo, sono tutelati come opere dell’ingegno ai sensi della Convenzione di Berna sulla protezione delle opere letterarie ed artistiche ratificata e resa esecutiva con legge 20 giugno 1978, n. 399. È poi seguita la Direttiva 91/250/CEE, codificata successivamente con la Direttiva 2009/24/CE. Fonte nazionale sono invece gli artt. 1 e 2 della Legge 22 aprile 1941 n. 633 (Protezione del diritto d’autore e di altri diritti connessi al suo esercizio – LDA) e 64-bis e ss. Nota: sono programmi per elaboratore anche i lavori preparatori alla stesura del codice, ma si tratta di un aspetto che non rileva ai fini che qui interessano.
[3] Andrebbe invero distinto lo smart contract che governa il protocollo DLT da quello che esegue transazioni tra utenti attraverso la capacità computazionale del network. Nel primo caso possiamo anche immaginare che lo smart contract assuma la natura di manifestazione scritta dell’accordo collettivo che interviene tra i nodi partecipanti. In tal caso occorre ammettere che, essendoci contratto, il programma per elaboratore possa anche avere forma scritta. Non è però in tale limitata accezione che il legislatore ha evidentemente inteso il fenomeno.
[4] I problemi di ordine giuridico e sociologico in questo tipo di vincoli – nei quali cioè si prescinde dalla effettiva volontà delle parti per dare rilievo solo alla condotta tipica – sono allo studio da oltre un secolo e meriterebbero molti approfondimenti anche in merito alla tutela del consumatore relegato ad un ruolo passivo nel crescente fenomeno della contrattazione di massa, accelerato dalla società dell’informazione (G. Stella Richter, Contributo allo studio dei rapporti di fatto nel diritto privato, in Riv. trim. proc. civ., 1977, 154-155; C.A. Funajoli, I rappporti di fatto in materia contrattuale, in Annali dell’Università di Ferrara, 1952, I, 103; E. Betti, Sui cosiddetti rapporti contrattuali di fatto, in Jus, 1957, 353; L. Ricca, Sui cosiddetti rapporti contrattuali di fatto, Pubblicazioni dell’Istituto di Scienze Giuridiche, Economiche, Politiche e Sociali delta Università di Messina, Giuffrè, Milano, 1965; N. Lipari, Rapporti di cortesia, rapporti di fatto, rapporti di fiducia, in Studi in onore di G. Scaduto, Vol. II, Padova, 1970; V. Franceschelli, Premesse generali per uno studio dei rapporti di fatto, in Rass. Dir. civ., 1981, 662; Id., I rapporti di fatto. Ricostruzione della fattispecie e teoria generale, Univ. Trieste. Fac. Giuridica, Giuffrè, Milano 1984 L. Stanghellini, Contributo allo studio dei rapporti di fatto, Milano, 1997; F. Gazzoni, Manuale di diritto privato, ESI, 2017, 857; A. Cicu, Gli automi nel diritto privato, in Il Filangieri, n. 8, Milano, 1901 e di A. Scialoja, L’offerta a persona indeterminata ed il contratto concluso mediante automatico, Ed. S. Lapi, Città di Castello, 1902).
[5] Poiché l’art. 8-ter chiarisce che lo smart contract genera un vincolo tra le parti «sulla base di effetti predefiniti dalle stesse», è escluso che lo smart contract possa essere una dichiarazione di scienza o altro atto che prescinde dalla volontà dell’agente.