dalla presentazione di Convivium @unisalento, 23 maggio 2023

Perché F/LOSS?

Scegliere il F/LOSS (Free/Libre Open Source Software) comporta costi diversi rispetto al software proprietario, che è la scelta imperante in ambito pubblico e privato. Tutti questi costi hanno in comune il fatto di spingerci, in quanto persone e gruppi, a non dare per scontato il mondo così com'è. Il F/LOSS ci impone di esercitare la nostra immaginazione, esige un costante impegno per potersi materializzare in sistemi concreti. Come vedremo, al di là della semplice etichetta, comporta la promozione della diversità biotecnica, la presa in carico delle relazioni di potere fra le varie componenti di un sistema tecnico (umane, elettromeccaniche, informatiche, ecc.), la valutazione delle risorse impiegate e, in generale, un ampliamento dello sguardo dalla singola interazione con un software al vasto mondo circostante, con tutte le implicazioni del caso.

Sono costi opportunità, come direbbero gli economisti, perché "non esistono pasti gratis"? Sono pungoli per non impigrirci nella reiterazione coatta di automatismi comportamentali tossici?

Come che sia, vogliamo raccontarvi perché a noi piace buttarla in F/LOSS.

Nethood e C.I.R.C.E.

Nethood è un'associazione con base a Zurigo che si occupa di gettare ponti fra spazi digitali e spazi analogici. C.I.R.C.E. è un gruppo di affinità che fa ricerca sulle convivialità elettriche, perché avere a che fare con la tecnologia ci cambia, ci modifica, ci trasforma. Comporta trasformazioni psicofisiche, come quelle patite dai compagni di Ulisse, trasformati in maiali. Insieme alla tecnologia si vede il mondo in maniera diversa.

Nethood e C.I.R.C.E. collaborano in varie forme, fra cui anche nel progetto H2020 EUCOMMEET, nel quale si vuole dare la possibilità a piccoli gruppi (una decina di persone) di confrontarsi su argomenti di interesse pubblico, come la crisi climatica, mediante videoconferenze e forum testuali. Nethood, con la collaborazione di C.I.R.C.E., provvede alla piattaforma per questo progetto, si occupa della parte tecnica.

Noi operiamo con il Free Software, che si traduce con software libero. In inglese, free significa sia gratuito, come "birra gratis"; sia libero, come "libertà": questo secondo aspetto è quello che ci interessa. Questa libertà non è gratuita, ha dei costi. Ne abbiamo individuati tre, dei costi generativi, che sono utili per sviluppare una serie di pratiche e procedure trasformative, trasformazioni in senso conviviale. Infrastruttura, privacy, fiducia.

Infrastruttura

Il primo costo della libertà del software è quello dell'infrastruttura.

Quando abbiamo a che fare con il software proprietario non ce ne preoccupiamo, perché attiviamo un meccanismo di delega a più livelli. Su quale infrastruttura gira il software? Chi è il proprietario? Come è organizzata, come funziona? Questa infrastruttura è equa? Collima con le nostre scelte etiche oppure no? Queste domande rimangono inespresse e irrilevanti quando si opta per il software proprietario.

Da simili deleghe a proposito dell'infrastruttura possono discendere incongruenze importanti.

Magari stiamo portando avanti un progetto che promuove la partecipazione cittadina e l'orizzontalità, avvalendoci però di un'infrastruttura pesantemente gerarchizzata. Forse le macchine che impieghiamo per far discutere le persone di riuso, riciclo ed energie rinnovabili sfruttano fonti fossili estremamente inquinanti.

Invece quando scegliamo il software libero non possiamo ignorare l'infrastruttura, è necessario prenderla in considerazione, comprendere ed eventualmente decidere come è organizzata, sapere chi decide a proposito del suo funzionamento e così via.

La libertà è una questione di relazione, si stabiliscono relazioni più o meno libere. Si compiono delle scelte che consentono di ampliare i margini di libertà. Le variazioni possibili sono tante e complesse, entrano in gioco molti parametri. Nel caso dell'infrastruttura tecnica, si può optare per un cloud pubblico (Microsoft Azure e Amazon AWS sono i due più noti), sul quale far girare software libero. Quell'infrastruttura però non è sotto il nostro controllo; perciò per aumentare la coerenza fra mezzi e fini potremmo cercare un altro cloud.

Nel caso di un progetto finanziato dall'unione europea come EUCOMMEET abbiamo scelto di appoggiarci all'infrastruttura pubblica del GARR, la rete italiana della ricerca. GARR gestisce un cloud che è già di proprietà pubblica. Progetto pubblico, infrastruttura pubblica, software libero. In Europa esistono altre reti analoghe, federate fra loro, che possono costituire un'alternativa concreta rispetto al public cloud che non è affatto pubblico.

Per lo sviluppo e i backup, Nethood si è data anche un'altra opportunità, una scelta di ancora maggiore prossimità, ovvero un server collocato presso L200, la sede zurighese dell'associazione in centro città. Qui abbiamo installato Lennon, un piccolo server adeguato all'associazione e alle sue necessità. Lennon ci sta dando grandi soddisfazioni, in suo onore abbiamo riadattato una famosa canzone, la trovate qui https://docs.mazizone.net/basics/about#imagine-the-song

Come si vede, rispondere alle domande relative all'infrastruttura porta alla ribalta molte possibilità differenti, con diversi gradi di difficoltà. Ogni scelta comporta vantaggi e svantaggi. Un piccolo server può guastarsi, qualcuno può accidentalmente strappare i cavi di connessione, ma d'altra parte è più direttamente sotto il nostro controllo e sotto la nostra responsabilità. Diventa chiaro che l'infrastruttura non è un mero supporto per i nostri progetti, ma un attore a parte intera. Una metafora a nostro parere azzeccata è quella del cibo: un conto è coltivare un pomodoro nell'orto sotto casa, un altro affidarsi a coltivatori biologici che conosciamo, un'altra ancora a prodotti derivati dall'agricoltura industriale che troviamo sul mercato al prezzo più conveniente.

In maniera analoga, dal public cloud, ospitato sui server lontani nei datacenter di una multinazionale, all'infrastruttura davvero pubblica di GARR (a livello nazionale, ma potrebbe concretizzarsi su scala più piccola, regionale, cittadina, di quartiere), fino alla cantina di L200, il primo costo del free software ci pone davanti alla scelta e alla cura dell'infrastruttura.

Per un approfondimento, si veda: Carlo Milani, Panayotis Antoniadis, Reti bio-organiche

Privacy

La privacy è un costo difficile da evidenziare. Nei progetti europei, come in molte altre situazioni, viene ripetuto spesso che è tutto in regola perché sono stati predisposti i moduli per il consenso informato degli utenti, per la protezione dei dati e la gestione degli stessi. Eppure, è un fatto, appoggiarsi al software proprietario "made in US" è perlopiù una scelta non conforme al GDPR, il Regolamento Generale per la Protezione dei Dati in vigore in Europa. le cose stanno così da alcuni anni, legalmente almeno a partire dal pronunciamento Schrems II del 16 luglio 2020. Noi non siamo legalisti, ma è importante ricordare che i comitati etici dei progetti dovrebbero a rigore rifiutare di avallare l'impiego di software e infrastrutture non conformi al GDPR. Per un approfondimento, https://pillole.graffio.org/pillole/la-corte-europea-invalida-laccordo-privacy-shield-sul-trasferimento-dei-dati-europei-e-declassa-gli-usa

Lo stesso vale per i dati delle scuole di ogni ordine e grado, università; nella pubblica amministrazione, sia in Italia che nel resto d'Europa. La situazione è a dir poco imbarazzante, il GDPR viene disatteso nella stragrande maggioranza dei casi a causa, in primo luogo, dell'impiego del software proprietario. La questione della privacy comporta attualmente un enorme carico burocratico, specialmente nel caso dei progetti europei per i quali spesso si chiede l'intervento di avvocati ed esperti legali. Una tipica strategia consiste nel mettere a punto documenti per il consenso informato per cui gli utenti vengono coinvolti in un esperimento, non in un progetto con prodotti che stanno sul mercato; in questo modo è possibile aggirare il GDPR, dal momento che vengono considerate eccezioni, esenti dal rispetto delle regole. Difficile è anche comprendere esattamente chi è responsabile per la privacy, concretamente, al di là della burocrazia. Di fatto, l'impiego di software chiusi delle multinazionali globali viola la privacy. In un certo senso, la riservatezza, il rispetto della privacy, costerebbe troppo, proprio nel caso dei progetti finanziati dall'Unione Europea.

Il F/LOSS è in grado di fornire maggior privacy rispetto al software proprietario. Dal momento che il software è aperto allo scrutinio, è possibile per chiunque vedere se ci sono problemi sulla gestione e trasferimento dei dati personali, cosa impossibile con il software proprietario. Il costo sta invece nella scelta di fiducia: ci fidiamo del software e dell'infrastruttura di una multinazionale oltreoceano, oppure del software fatto da persone che firmano pubblicamente ciò che fanno, che gira sui server di un ente pubblico?

Fiducia

Eccoci all'ultimo costo, il più importante fra quelli svelati dalla scelta del F/LOSS: la fiducia. Dobbiamo scegliere di chi fidarci. Potrebbe sembrare più logico fidarci di una multinazionale. L'argomento tipico è: che interesse ha un'azienda globale a sorvegliare un piccolo progetto o, a maggior ragione, un privato? A cui fa eco l'affermazione: "non ho nulla da nascondere". Certo può sembrare ragionevole, è più semplice affidarsi a una megastruttura che non si conosce, ma di cui non c'è ragione di diffidare, perché molto lontana dalla nostra vita concreta. D'altra parte, sappiamo bene quanto sia difficile instaurare relazioni di fiducia con persone vicine.

La questione della fiducia porta alla luce un costo fondamentale del software libero: il costo derivante dal cambiare abitudini. L'abitudine a un certo tipo di interazione genera automatismi comportamentali per cui non appena ci troviamo di fronte a sistemi anche solo leggermente differenti dal solito, la reazione più frequente è: "non funziona!". Verissimo: il software libero non funziona come il software proprietario, non ne è la copia esatta, anche se può svolgere le stesse funzioni in maniera analoga nella gran parte delle situazioni concrete e, in teoria, in qualsiasi situazione, se ci fosse un investimento adeguato.

Quando diciamo: "Gmail funziona" ("Gmail" si può sostituire con un qualsiasi software proprietario di largo o larghissimo uso), di solito sottoindentiamo che ci fidiamo del fatto che funzionerà nella maniera a cui siamo abituati, cioè che non tradirà le nostre aspettative. Il funzionamento in questione dipende anche da una sorta di omologazione. Infatti se accadesse che "non funziona", il primo pensiero probabilmente sarebbe "sono io che non sono in grado, Gmail funziona", nel senso che siccome funziona per miliardi di persone, il fatto che non funzioni nel nostro caso implica la nostra incapacità. In un certo senso, se quel software non funziona ci sorge il dubbio che siamo noi a non funzionare a dovere.

In un progetto in collaborazione con un'università britannica ci è stato chiesto di fornire un'alternativa F/LOSS a Zoom. Abbiamo optato per Jitsi meet, un sistema di videoconferenza con milioni di utilizzatori, ma ordini di grandezza meno di Zoom. La reazione del partner del progetto è stata: "non funziona". Verissimo: Jitsi non funziona come Zoom. Anche se avevamo installato un'istanza moderata (normalmente tutti gli utenti entrano in Jitsi con gli stessi poteri, senza gerarchie) e apportato diverse modifiche per riprodurre alcune delle caratteristiche di Zoom giudicate fondamentali, non era possibile renderlo identico. Da cui la reazione, assolutamente fondata, dal momento che rimarcava le aspettative disattese degli utenti.

Non è banale fidarsi di un sistema nuovo che rimpiazza ciò a cui siamo abituati. Infatti spesso accade che quando "non funziona" (come previsto, nella maniera consueta, a cui sono abituato), il primo pensiero generalmente è "ecco, quest'affare non è in grado di svolgere la funzione" (come previsto, nella maniera consueta, a cui sono abituato). Il costo della fiducia è, in senso profondo, il costo del cambiamento. Si verifica una sorta di ribaltamento, il mancato funzionamento è ora tutto a carico del sistema tecnico, come se l'umano non avesse alcun ruolo nel fallimento dell'interazione. Il rovesciamento è completo se proseguiamo il parallelismo: è il software che non è grado di comportarsi come Gmail (o qualsiasi altro a cui siamo abituati), nel senso che siccome funziona (forse) per poche persone (milioni? migliaia? centinaia? decine? in ogni caso, non miliardi!), il fatto che non funzioni (come Gmail) implica la sua incapacità. In un certo senso, se quel software non funziona (come previsto) ci sorge il dubbio che ci siamo fidati del sistema sbagliato, ovvero delle persone sbagliate, coloro che ci hanno fornito quel sistema strano, inconsueto, non abituale, che (ovviamente) non funziona a dovere.

Il costo della fiducia è anche il costo dell'usabilità. Rendere usabile un sistema significa provarlo e riprovarlo, testarlo. Abituarsi a quel sistema è un processo non scontato, soprattutto se vi sono delle aspettative pregresse, per quanto magari non del tutto consapevoli perché date per scontate. La familiarizzazione implica la necessità di prendersi cura dei sistemi tecnici. Implica che gli esseri umani non possano aspettarsi che il sistema funzioni automaticamente, senza alcun pensiero da parte loro, perché ogni automazione comporta molto pensiero, molta riflessione e applicazione. Con le macchine nulla può essere dato per scontato.

I tre costi della scelta del F/LOSS, infrastruttura, privacy e fiducia, portano alla luce le difficoltà delle interazioni con la tecnica, con gli esseri tecnici. Nulla può essere dato per scontato, tutto conta, così come contano le persone con cui ci accompagniamo, ciò che mangiamo, ciò che beviamo, allo stesso modo contano le macchine, gli esseri tecnici con cui decidiamo di avere a che fare.