MadBob

A seguito di un toot di Stefano Maffulli – attuale direttore di Open Source Initiative, già recentemente citato su queste pagine – ho avuto modo di articolare un breve scambio di messaggi. Terminato senza particolari conclusioni, ma da cui ho tratto qualche riflessione non molto confortante.

Il riassunto spannometrico dell’argomentazione di Maffulli – in quella sede sostenuta anche da Luis Villa, che non è proprio l’ultimo degli scappati di casa – è che la nascente definizione di “Open Source AI” debba necessariamente includere in modo esplicito i parametri previsti dalla (già esistente, per quanto ancora in costante divenire) normativa vigente in tema di AI. Di fatto, estendendo formalmente i requisiti già iscritti nelle regolamentazioni per aggiungere quel che concerne strettamente l’attribuzione della qualifica “Open Source”.

La domanda sottoposta tra le righe: è davvero indispensabile che la suddetta definizione sia legata e vincolata a leggi che devono comunque, a prescindere, essere applicate da chiunque – open o non open che sia il prodotto finito – e che comunque variano sia da Paese a Paese che nel tempo? La risposta erogata tra le righe: si, perché sinora ci è andata bene, ma un giorno qualcuno potrebbe non fare più eccezioni dedicate al modello open e pretendere che le regole siano puntualmente applicate anche in questo contesto.

L’implicito riferimento è al Cyber Resilience Act, la stringente regolamentazione europea sulla cyber sicurezza che ha fatto molto discutere negli scorsi mesi per la sua incompatibilità con le dinamiche proprie del modello di sviluppo collaborativo e più in generale con l’oramai universalmente consolidata pratica di attingere a piene mani dal patrimonio collettivo di codice libero disponibile online. In quel frangente, la massiccia mobilitazione di community, organizzazioni, stakeholders pubblici e privati ha permesso di introdurre ampie ed abbondanti eccezioni nel testo della direttiva, che nella formulazione attuale esonera gli sviluppatori (ed i contributor occasionali, ed i distributori) da oneri legali e burocratici per imputarli ai fornitori commerciali. Ma la scampata sorte dello sviluppo open source – che qualcuno già dava poco verosimilmente per “spacciato” nel Vecchio Continente – ha comunque posto la collettività di fronte a nuovi dubbi esistenziali (come se già non ce ne fossero abbastanza). Un po’ sulle effettive responsabilità morali dei developer che pubblicano con leggerezza codice potenzialmente non sicuro, e un po’ sulla tolleranza degli organi legislativi nei confronti di un modello produttivo essenziale per gran parte dell’impianto industriale contemporaneo ma troppo “fluido” per essere normato, monitorato, e per essere oggetto di vincoli e restrizioni.

In virtù della crescente attenzione dei suddetti organi governativi nei confronti dell’ancor più crescente impatto delle tecnologie digitali, e dunque della progressiva necessità di porre limiti, identificare responsabilità e interdire comportamenti dannosi, qualcuno inizia – a torto o a ragione – a domandarsi quanto ancora possano essere accettate delle deroghe specifiche per il modello open source. Che da una parte viene romanticamente narrato come un innocuo passatempo da smanettoni, ma dall’altra parte è di fatto un processo oramai pressoché inalienabile del moderno apparato produttivo, il quale deve dare garanzie e risposte certe.

Per quanto possa comprendere queste titubanze, ho delle perplessità sulla possibilità di iscrivere nome e regole dentro la definizione stessa di “open source”. Ufficialmente dal software open non ci si aspetta neppure che debba funzionare (“the software is provided ‘as is’, without warranty of any kind” è una formula canonica di qualsiasi licenza), proprio perché essendo – per definizione – pubblicamente accessibile e modificabile da chiunque non è possibile pretendere che l’autore debba (e possa) essere anche solo conscio di qualsiasi utilizzo, qualsiasi alterazione, qualsiasi uso ed abuso del proprio codice; figuriamoci se uno sviluppatore, per poter legittimamente dichiarare il proprio software “open source”, dovesse non solo fornire delle garanzie universali ma essere pure certificato e vidimato.

Viceversa, credo che la definizione in sé debba essere limitata alla sostanza propria: quattro libertà, e fine. Affinché tutti possano pubblicare quel che vogliono, senza lacci e lacciuoli, e continuare ad innovare senza chiedere il permesso a nessuno. E sia poi onere di chi sceglie di usare tali componenti in un contesto formale (ad esempio: quello commerciale) verificarne la conformità con le leggi vigenti. O, magari, adoperarsi per ottenere tale conformità, tramite contributi al codice o – più prosaicamente – finanziando lo sviluppo. E continuando a condividere lo sforzo del mantenimento con gli altri fornitori, finalizzato a conservare un reciproco vantaggio, come del resto ha sempre funzionato il modello in sé.

Può forse esistere il remoto rischio di una stretta legislativa sul modello open, che porti a dubbi e incertezze sulle sue dinamiche e possa minare la base del suo funzionamento ed incepparne alcuni meccanismi. Ma la sua istituzionalizzazione coatta, dettata da una visione esclusivamente economicistica dello stesso (quella per cui l’unica porzione dell’eterogeneo mondo open che conta è appunto quella di rilevanza commerciale e industriale, con tutti i relativi annessi legali), equivarrebbe alla certezza della sua fine. Perché non tutti i suddetti progetti di rilevanza industriale nascono a priori con questo fine, non tutto il codice libero viene pubblicato in prima istanza con l’obiettivo esplicito di essere integrato in soluzioni professionali da parte di terzi, e se davvero queste fossero condizioni sine qua non per poter pubblicare software lecitamente “open source” – ovvero: se, oltre alle già diffuse perplessità nel “regalare” il proprio codice, si sommasse pure l’obbligo di accollarsi oneri burocratici e legali – davvero dubito che qualcuno si prenderebbe ancora la briga di aprire un qualsiasi nuovo repository su GitHub. Azzerando quello che è uno dei massimi vantaggi competitivi del caotico modello aperto: la capacità di innovare – per dirla con le parole di Torvalds – “just for fun”.

Più o meno nello stesso momento in cui scrivevo che l’open source domina su pressoché ogni settore tecnologico, Stefano Maffulli – direttore di Open Source Initiative – si batteva il petto perché il medesimo movimento open source non è riuscito a cavalcare le due maggiori rivoluzioni digitali dell’ultimo decennio: il cloud ed il mobile.

La premessa è che il blog post sopra linkato ha l’intento primario di spiegare, contestualizzare e promuovere la campagna intrapresa da OSI per dare una definizione di “open source” nell’ambito di quella che è la terza rivoluzione digitale del decennio, la cosiddetta Artificial Intelligence, ma credo che valga la pena sviscerare un poco le posizioni espresse. Per smontare la tesi, e arrivare al punto.

Innanzitutto: quando parliamo di open source, stiamo parlando di software. Ovvero di un bene riproducibile all’infinito, a costo zero. E che pertanto può essere distribuito a tutti, senza oneri, per facilitarne l’adozione, accelerarne l’integrazione e – in ultima istanza – permettere la partecipazione attiva ed il miglioramento collettivo. Il successo sta essenzialmente tutto qui: nell’implementare un modello produttivo e industriale applicabile al mondo digitale, in cui non esistono materie prime, risorse, macchinari, operai o logistica, e dove pertanto non possono essere applicate le dinamiche canoniche di scarsità, approvvigionamento, economia di scala, capitalizzazione, surplus, e tutto quello che normalmente descrive dal punto di vista economico la produzione delle mele, dei tavoli, degli aerei o di qualsiasi altro prodotto.

Quando parliamo di cloud e mobile, stiamo invece parlando di oggetti fisici. “Il cloud” è, come tutti sappiamo, “il computer di qualcun altro”, ed in quanto computer deve non solo essere costruito ma anche piazzato da qualche parte, continuamente alimentato con energia elettrica e connesso all’internet. “Il mobile” è una categoria di dispositivi embedded, ovvero primariamente agglomerati di componenti elettronici su cui incidentalmente è installato del software. Volenti o nolenti entrambi i contesti appartengono alla sfera dell’economia classica, in cui delle risorse (silicio, rame, alluminio: disponibili in quantità finita, dunque scarsi, dunque costosi) devono essere consumate per ogni singola unità prodotta o erogata. E ben difficilmente tali risorse – o meglio: l’onere richiesto per allocare queste risorse – può essere condiviso e distribuito.

Come dovrebbe essere fatto il “cloud open source”? Forse dovrebbe esistere una rete di server federati che espongono funzioni infrastrutturali comuni, che possano essere sfruttate liberamente da tutti? Esistono diversi esperimenti in tal senso, ma tutti di modesta diffusione proprio perché inevitabilmente basati sul presupposto che qualcuno si sobbarchi, volontariamente e spontaneamente, i costi operativi (storage, banda, computazione…) di tutti gli altri. E come dovrebbe essere formulato il “mobile open source”? Già esistono diverse alternative libere ai canonici Android e iOS, ma alla luce del fatto che queste richiedono un attivo e tutt’altro che banale impegno da parte degli utenti anche solo per essere installate non credo siano destinate ad andare molto più lontano di quanto Linux sia andato sul desktop; d’altro canto proprio la frammentazione delle piattaforme mobili ha creato l’esigenza di semplificare lo sviluppo delle applicazioni, ed anche qui le soluzioni open source sono, di fatto, l’unica opzione solida per un intero ramo dell’industria IT.

E come la mettiamo con la AI? Questa è una bella domanda, e sono lieto che OSI se la sia posta. Quando parliamo di AI ci riferiamo essenzialmente ad algoritmi (e dunque software, e dunque bla bla bla quello che ho scritto sopra) e – soprattutto? – a modelli dati, che a loro volta sono assets digitali duplicabili all’infinito. I quali hanno però un processo di genesi ben diverso rispetto al software: sono elaborazioni di dati e informazioni (immagini, testi, suoni…) distribuiti con una propria licenza, che può essere libera o meno (e determinano poi la licenza con cui il modello stesso potrà e dovrà essere distribuito e utilizzato da altri), ed in molti casi necessitano di grandi risorse computazionali (finite, scarse, costose) per essere non solo generati ma anche modificati ed estesi. Il blob binario infine derivato potrà poi essere distribuito pubblicamente, ma non c’è nessun valore aggiunto, e dunque nessuna motivazione, nel farlo: laddove il cardine del modello di sviluppo open source sta nella pubblica partecipazione – il prerequisito della quale è l’accesso al codice, da cui deriva l’effetto collaterale della gratuità – un modello dati fatto e finito non può essere collaborativamente modificato e perfezionato, se non intervenendo sulla base di dati da cui è stato generato. Motivo per cui le fonti di dati liberi, e persino le iniziative community appositamente nate per raccogliere dati collettivi con l’esatto scopo di alimentare modelli AI, non mancano, ma sta poi al singolo dispiegare la potenza computazionale (finita, scarsa, costosa) richiesta per macinarli ed ottenerne l’effettivo artefatto da dare in pasto al proprio algoritmo. Non so anticipare quale sarà il risultato di OSI nel suo compito di dare una definizione di “intelligenza artificiale open source”, ma non dubito che persone più intelligenti di me prenderanno in considerazione questi fattori; il rischio contrario è quello di partorire una versione ideologica, utopica, e pertanto inapplicabile e non credibile.

Inquadrando il fenomeno open source in una cornice economicista (materialista, e – diciamolo – persino un po’ marxista) diventa, a parer mio, più semplice determinarne il perimetro, prevederne le conseguenze, conoscerne i limiti, anticiparne i progressi. E comprendere dove è necessario, o semplicemente più conveniente, intervenire. L’open source descrive l’infinito, e l’infinito è il suo unico campo di applicazione; se è finito, non può essere open source.