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”.
MadBob 