L’Unione europea mette a rischio il software open source

Lo scorso 11 aprile la Python Software Foundation ha lanciato un allarme sulle conseguenze di due norme che la UE si appresta a varare: il Cyber Resilience Act e il Product Liability Act. Sarebbe a rischio, secondo i creatori del linguaggio che fa funzionare una miriade di servizi internet e potenzia lo sviluppo del machine learning, il modello di sviluppo basato sulla condivisione del codice e delle informazioni.

Il Cyber Resilience Act (CRA) e il Product Liability Act (PLA) sono due normative europee di prossima emanazione che rivoluzioneranno il mondo della sicurezza e dello sviluppo software. Sulla carta, sono provvedimenti animati da buone intenzioni: stabiliscono —il primo— che i fornitori di apparati digitali devono garantire, tra l’altro, la sicurezza dei prodotti che vendono eseguendo dei test di vulnerabilità e rendendoli disponibili; e —il secondo— che chi produce software sia responsabile per i danni causati dal “prodotto” (il perché del virgolettato sarà chiaro fra poco). Tuttavia, come sempre accade in questioni giuridiche, il diavolo è nei dettagli e una lettura più attenta di CRA e PLA rivela enormi criticità, alcune delle quali riguardano direttamente il modello di sviluppo software che rientra nell’acronimo FLOSS (Free and Libre/Open Source Software), alla base dell’intero ecosistema digitale nel quale viviamo e senza il quale The Internet non si sarebbe sviluppata al livello che conosciamo.

L’articolo 16 del CRA, rileva la Python Software Foundation, stabilisce che “A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of the product with digital elements shall be considered a manufacturer for the purposes of this Regulation”. Di conseguenza, ragiona la PSF, qualsiasi programmatore che contribuisce allo sviluppo di un software il cui uso è regolato dal licenze libere diventa, giuridicamente, un produttore e dunque responsabile “a prescindere” anche se non viene pagato per il lavoro che ha svolto per la comunità. Questa conclusione, si deve aggiungere, è rinforzata dalla lettura dell’articolo 4 del PLA secondo il quale per “prodotto” si intendono anche l’elettricità, i file per la fabbricazione digitale e il software; e  “fabbricante” identifica chi  sviluppa, produce o fabbrica un prodotto per uso proprio.

Dunque assegnare la responsabilità a ogni sviluppatore —scrive la PSF— creerebbe meno sicurezza, non più. Lasciare singoli sviluppatori e/o con scarse risorse in una posizione giuridicamente dubbia quando contribuiscono a repository pubblici … quasi certamente li scoraggerebbe. Solo chi vende abbastanza software o combinazioni software/hardware da assorbire le conseguenze della responsabilità da prodotto potrebbero continuare a operare alla luce del sole. I miglioramenti per gli utenti e i benefici per la sicurezza condivisa della collaborazione globale sul software sarebbero accessibili solo agli sviluppatori che lavorano per conto di poche grandi aziende. La crescita e l’innovazione sarebbero soffocate.

Il problema è reale, ma la soluzione proposta dalla PSF —non considerare tout court “produttore” ai fini del CRA/PLA chi contribuisce allo sviluppo di FLOSS ma non lo utilizza commercialmente— non risolve il difetto strutturale di queste normative: l’ambiguità nel modo di definire giuridicamente il software.

Per capire le conseguenze di questa ambiguità è necessario partire da una considerazione: i FLOSS sono basati sul principio che il codice sorgente di un programma deve essere accessibile e modificabile da chiunque, e che chiunque accede e modifica il codice sorgente deve rendere disponibili le modifiche alle stesse condizioni. Questa è la cosiddetta “caratteristica virale” dei FLOSS che, pur variando a seconda del tipo di licenza prevista dagli sviluppatori, garantisce l’evoluzione e il miglioramento dei programmi.

Il FLOSS —come in generale il software— non viene “venduto” ma concesso in licenza con la clausola “as is”, in italiano si direbbe “visto e piaciuto” e senza alcuna garanzia. Questo approccio è ragionevole per “prodotti” gratuiti e dei quali è disponibile il codice sorgente; chi decide di usarlo, infatti, ha la possibilità di verificare eventuali problemi o criticità prima di farlo funzionare. Al contrario, quando il software è “proprietario” (cioè viene concesso in licenza solo nella sua versione “funzionante”, senza il “progetto”) la clausola “visto e piaciuto” è meno giustificabile —anzi, non lo è affatto. Qualsiasi prodotto, infatti, deve rispettare degli standard di sicurezza e incolumità delle persone e non può essere commercializzato se questi standard non sono rispettati.

Ma, e qui casca l’asino, dal 1991, da quando, cioè, fu emanata la direttiva 250, il software è qualificato giuridicamente come la Divina Commedia, cioè come “opera letteraria” sul presupposto che oggetto della tutela giuridica è la “modalità espressiva” —il codice sorgente— e non il risultato della sua “compilazione” —vale a dire il programma fatto e finito, pronto per essere usato.

La conseguenza di questa scelta è che nella UE il software non può essere brevettato e la sua commercializzazione non è soggetta alla responsabilità del produttore appunto perché, per la legge, i programmi sono come una poesia o un romanzo e non come una fresa a controllo numerico. Tuttavia, “prodotto” e “opera letteraria” sono due condizioni che non possono coesistere e quindi è quantomeno incoerente che CRA e PLA non prendano in considerazione questa differenza.

Su nessun libro è mai stato scritto che “non garantiamo che quest’opera possa soddisfare le necessità di tutti i lettori” o che “il suo utilizzo non è consentito in attività che possono mettere a rischio la vita umana”; così come per nessun progettista di macchinari è previsto il diritto di opporsi alla “mutilazione” dell’opera. Da un lato, dunque, è certamente corretto abbandonare l’idea —fuori dal tempo e dal mercato— che il software sia un’opera letteraria, ma va fatto in senso assoluto e non, come dice il PLA “ai fini di questo regolamento”. Nello stesso tempo, tuttavia, è anche necessario riconoscere l’importanza culturale ed economica del modello di produzione basato sulla condivisione del codice sorgente che, come dimostrano i fatti, è stato ed è ancora un elemento fondamentale per lo sviluppo della società dell’informazione.

Dunque, stabilito che il software dovrebbe essere qualificato come prodotto, più che “esentare” i programmatori dalla responsabilità di quello che inventano e costruiscono, sarebbe opportuno chiarire che la responsabilità nasce in funzione della possibilità per l’utente di accorgersi della presenza di difetti. In altri termini, non può esserci responsabilità da prodotto per chi sviluppa FLOSS se chi decide di servirsene la fa in modo “cieco” senza essere (ragionevolmente) certo di quello che sta facendo —principio, peraltro, già presente nel nostro Codice civile a proposito dei “vizi” della cosa venduta. Al contrario, dovrebbe esserci responsabilità totale, presunta e “oggettiva” nel caso di software proprietario perché l’acquirente non è messo in condizioni di sapere (ma soprattutto di dimostrare) l’esistenza di difetti e il loro collegamento con i danni provocati. Si potrebbe eccepire che è irrealistico chiedere agli utenti finali di farsi carico in autonomia della ricerca nei FLOSS di problemi e criticità, ma non è così.

Inoltre, è vero che non esistono software privi di difetti; ma è anche vero che non tutti i difetti generano danni e responsabilità. Dunque, la legge dovrebbe prendere in considerazione solo quei difetti che incidono sui diritti e le libertà fondamentali di individui, aziende e istituzioni. In pratica potrebbe essere attribuire un controllo del genere potrebbe essere eseguito, per esempio, da entità indipendenti che si assumono la responsabilità di attestare il livello di qualità e affidabilità dei FLOSS —ma anche dei software proprietari.

Un’altra possibilità sarebbe quella di considerare “prodotto” soltanto il software nella sua forma eseguibile, riservando ai soli sorgenti la tutela del diritto d’autore. In questo modo sarebbe chiara, in teoria, la differenza fra chi “crea” e chi “usa” o fa usare ad altri.

Nemmeno questa, come le precedenti, è una soluzione perfetta, ma dimostra che ci sono approcci alternativi che varrebbe la pena di esplorare, invece di scrivere norme poco attente al valore culturale e sociale di un grande progetto di condivisione del sapere come quello costruito sul lavoro di Richard Stallman, Bruce Perens, Eric Raymond e di tutti i “visionari” ai quali dobbiamo tutta la riconoscenza per avere contribuito a creare una parte importante della mondo in cui viviamo.

Probabilmente i parlamentari europei non sono consapevoli delle conseguenze che potrebbero derivare dalle norme che saranno chiamati ad approvare, ma non è ancora troppo tardi —c’è tempo, ricorda la Python Software Foundation, fino al 26 aprile— per chiedere loro di fermarsi un momento e ragionare, prima di decidere.