Mi rendo conto che sia un messaggio un po’ forte, ma è la prima cosa che m’è venuta in mente già dopo aver letto il primo paragrafo di un fresco articolo sul tema dal più diffuso giornale italiano: “Qualcuno fermi le software-house“. Pensiero inevitabilmente consolidato man mano che la lettura procedeva, fino alla tragicomica (perché c’è da ridere e piangere allo stesso tempo) conclusione.
L’autore, infatti, parte snocciolando una serie di problemi che imputa tout court al creatore dei relativi software: <<questi eventi non sono stati provocati “dal” software ma da chi lo ha pensato, realizzato e fatto funzionare>>. Se da una parte assolve il software e i computer in cui tali nefaste problematiche si siano verificate (come riportato nel paragrafo introduttivo), dall’altra non mostra il benché minimo dubbio: è chi ha creato il software ad averle provocate! Come se, insomma, si fosse trattato di un diabolico piano ordito dai programmatori.
Prosegue impavidamente affermando che il software dovrebbe essere sviluppato <<seguendo regole di sicurezza>>, che ovviamente si astiene dal riportare o anche vagamente accennare.
Purtroppo la cosa peggiore è che probabilmente non sa che in letteratura (informatica) non esiste né una definizione oggettiva di “sicurezza” (lo metto appositamente tra virgolette) né tanto meno metriche / strumenti che siano in grado di stabilire che un determinato software sia “sicuro” (sempre tra virgolette) ed eventualmente quanto / in che misura.
Conoscenza che, invece, ha ben chiara chi abbia effettuato un percorso di studi che sia passato dalla Teoria della Computabilità (ossia il fondamento stesso dell’informatica) e alcuni suoi teoremi che, se noti, avrebbero stroncato sul nascere certe affermazioni che etichettare come discutibili sarebbe già fargli un complimento.
Che il problema di fondo sia la scarsa o mancanza di conoscenza in materia si evidence anche dall’audace affermazione seguente: <<Mentre case, automobili, elettrodomestici e strumenti di lavoro sono sottoposti a regole ferree, non è così per i programmi>>. Per puro caso (!) lavoro già da 6 anni per un’importante azienda automotive europea (inizialmente da Senior Developer/QA, poi come Principal QA Engineer, e di recente come Operational Manager) relativamente allo sviluppo dei nostri sistemi di infotainment che… sono fatti da programmi! Sì, proprio ciò di cui si lamenta l’autore! E posso affermare con assoluta certezza come il software non soltanto sia parte essenziale delle automobili (quindi non esclusivamente delle nostre), ma diventa sempre più importante. Oltre al fatto che, per quanto lo sviluppo sia controllato e sottoposto a tantissime revisioni, può capitare che non sia esente da difetti (bug). D’altra parte parliamo di programmi costituiti da decine e decine di milioni di righe di codice, e sfido l’autore a svilupparli con tutte le “regole ferree” che vuole e a rilasciarli senza il benché minimo bug…
Con ciò posso confutare immediatamente anche quanto scrive successivamente: <<la costruzione di software è sostanzialmente priva di responsabilità. Dunque, la vita, l’incolumità e la tutela dei diritti delle persone sono affidate a prodotti largamente sottratti a qualsiasi controllo>>. No, caro il mio autore, è l’esatto contrario: il software è largamente sottoposto a controlli prima di arrivare in produzione! Controlli che sono ovviamente proporzionali alla criticità dell’ambito di impiego.
E continua ancora cercando di smantellare uno dei cardini della giurisprudenza in materia: <<Qualche acuto giurista rileverà certamente che la UE e l’Italia considerano il software un’opera dell’ingegno e che, quindi, non si può parlare di responsabilità da prodotto>> con susseguenti strampalati accostamenti a libri o quadri ed esempi che dovrebbero provare la sua tesi (“dimenticando” che anch’essi possano presentare difetti), ossia che il software, in quanto mero prodotto di cui i consumatori fruiscono, dovrebbe essere gravato da (intrinseche) responsabilità nel caso presentasse dei difetti.
Il problema fondamentale di tali affermazioni è che risulta piuttosto evidente che egli non si sia cimentato nella scrittura di software, per lo meno di una certa complessità / caratura nonché con sufficiente esperienza, altrimenti avrebbe già maturato, da parecchio tempo, la consapevolezza che, sì, invece: il software è frutto dell’ingegno di chi lo realizza. Dunque ha (evito il condizionale) tutti i titoli per essere trattato come tale dalla giurisprudenza, al pari di qualunque altra opera facente capo alle altre arti note.
Sì, perché scrivere codice è anche un’arte: il codice ha pure una propria estetica, che deriva dal modo in cui quello sviluppatore concepisce la risoluzione dei determinati problemi che gli si sono presentati davanti. D’altra parte se la gente, istruzione obbligatoria alla mano, è in grado di scrivere un tema o una letterina a babbo natale (visto il periodo), non è che tutti diventino scrittori o poeti, e magari affermati. La capacità di scrivere non implica, logica elementare alla mano, che chiunque possa arrivare a tali livelli. E lo stesso si applica, né più né meno, alla programmazione.
Sempre in tema di logica non può certo sfuggire la fallacia di quanto successivamente riportato: <<Dunque, applicando il Duck Test, se il software è fatto come un prodotto, funziona come un prodotto ed è usato come un prodotto, allora è un prodotto>>. Infatti il software continua a rimanere un’opera dell’ingegno nonostante possa (ma non è!) essere realizzato, funzionare, e usato come prodotto. La sua proprietà d’essere opera dell’ingegno, insomma, non verrebbe meno soltanto per questo.
D’altra parte l’assunzione di base risulta già sbagliata, poiché il software non viene realizzato come prodotto, in quanto non esiste un “ricettario” da cui pescare, dei meccanismi, o degli strumenti che, utilizzati in precisi nonché prevedibili modi (come potrebbe essere la catena di produzione di una fabbrica) diano come risultato uno specifico programma da realizzare. Magari fosse così (semplice)!
Devo dire che, però, concordo con quanto poi affermato su un ben preciso argomento. Sembrerebbe, a suo dire, che l’UE si stia muovendo per legiferare in materia di responsabilità soltanto quando si tratti di software di intelligenza artificiale, esentando tutti gli altri tipi di software. Personalmente sono totalmente in disaccordo perché nessun software, in quanto tale, dovrebbe prevedere automaticamente delle responsabilità per eventuali danni.
Ciò precisato, torno immediatamente a dissentire sul passaggio successivo: << Ciò che conta è, in altri termini, se un software è sviluppato in modo da ridurre il rischio di causare danni oppure no. Il “come” è del tutto irrilevante>>. Il come è, invece, assolutamente rilevante, perché le buone pratiche (che vengono già ampiamente utilizzate nell’industria del software) non sono affatto sufficienti per poter fornire granitiche certezze/garanzie sull’assenza di difetti che possano portare a danni (di qualunque misura).
Non ci sono e non ci potranno essere, perché è la già citata Teoria della Computabilità a dimostrarlo, a meno che l’autore non trovi il modo di smantellare i (purtroppo per lui) solidissimi teoremi che ne sono alla base. La matematica, di cui l’informatica è figlia (ne è una branca, infatti), non potrà mai e poi mai essere messa in discussione, con buona pace dell’autore. Anche qui, però, la cosa più importante sarebbe capire in che modo un software andrebbe sviluppato per avere meno danni (o nessuno), ma l’autore ha deciso di tralasciare ogni riferimento o dettaglio in merito.
Il quale, comunque, imperterrito afferma che le software house userebbero <<il diritto al segreto garantito dalla normativa sulla proprietà intellettuale per sottrarsi non solo e non tanto alle responsabilità per i danni causati dai loro prodotti, ma dai maggiori costi che lo sviluppo di software sicuro implicherebbe>>. Premesso che la tutela delle proprietà intellettuali sia sacrosanta, parecchie aziende hanno processi di audit del software che sviluppano, i quali sono conformi agli standard industriali (ISO). Diverse si appoggiano anche a ditte esterne di esperti che analizzano il codice alla ricerca di vulnerabilità; ciò perché, banalmente, il fatto che un software sia chiuso (non visionabile da chiunque) non implica che soltanto l’azienda che lo sviluppa ne abbia accesso. Infine, ritorna col mantra dello sviluppo di software “sicuro”, di cui però, come già detto all’inizio, non esiste alcuna definizione in letteratura (e ciò tanto per cominciare)…
Mi sento, però, di rincuorare l’autore quando afferma che: <<Fino a quando i danni causati dai malfunzionamenti dei software sono frutto di errori umani si configura sempre una responsabilità per negligenza (che poi sia praticamente impossibile da dimostrare, è un altro discorso)>>. Da programmatore di lunga data (40 anni) nonché vasta e variegata esperienza posso tranquillamente affermare che i bug (difetti) nel software che scriviamo sono certamente… frutto di nostri errori. Errori umani, dunque. Perché, da esseri umani quali siamo, commettiamo errori quando scriviamo programmi, poiché il processo creativo (ed è il motivo per cui programmare è e rimane opera dell’ingegno!) che porta alla scrittura di codice non può in nessun modo essere imbrigliato in sistematici processi meccanici i cui risultati siano garantiti esser privi di difetti. Tra l’altro e se, come candidamente afferma, tali errori siano impossibili da dimostrare (e qui ha senz’altro ragione!), allora di che staremmo a parlare? Perché lamentarsi? Non ha alcun senso!
Ma ecco che dal cilindro arriva poi quella che, a suo dire, dovrebbe rappresentare la soluzione: <<Solo l’accesso ai codici sorgenti e alla documentazione di sviluppo consentirebbe di capire se ci sia e dove sia l’errore, ma soprattutto se ci si trova di fronte a un errore o alla deliberata scelta di rilasciare un prodotto pericoloso>>. La classica, banale, nonché alquanto comune tesi (sbagliata, ovviamente) che l’apertura dei sorgenti (e documentazione) sarebbe, di per sé, condizione necessaria per poter appurare la presenza di errori. Decenni di ingegneria inversa e migliaia di bug trovati analizzando i binari (e non i sorgenti!) non hanno insegnato nulla all’autore (che comunque non è il solo a sostenere questa stramba tesi della necessità dell’apertura dei sorgenti). Ma da programmatore sono decisamente più curioso di sapere in che modo il solo accesso ai sorgenti possa consentire di discernere che il software fosse stato appositamente rilasciato con pericolosi difetti: questo è, al momento, un mistero della fede (dell’autore)…
D’altra parte è lo stesso che si smentisce subito dopo: <<i software sono composti da centinaia di migliaia o addirittura milioni di righe di codice, anche potendo avervi accesso e potendo permettersi di sostenere i relativi costi, difficilmente si otterrebbero informazioni utili a far valere il proprio diritto>> (il grassetto è mio). Per cui caliamo un velo pietoso…
Ed essendo in chiusura, ecco che tira fuori l’asso che aveva custodito nella manica, ossia La Soluzione Finale: <<Una soluzione pratica e a costo zero sarebbe applicare anche allo sviluppo di software quella responsabilità per attività pericolosa inizialmente prevista (e poi eliminata) per il trattamento dei dati personali. Invertendo il cosiddetto “onere della prova”, si deve soltanto provare di avere subito un danno a causa di un software, mentre spetta al produttore, pardon all’“autore” la dimostrazione di avere fatto tutto il possibile per evitare il danno>>. Quindi e siccome quanto aveva finora snocciolato era (ed è) impossibile da realizzare (oltre che insensato, aggiungo io), l’autore non trova niente di meglio da proporre che scardinare uno dei principi cardine di scienza, coscienza, e giurisprudenza: l’onere della prova. Dunque il produttore del software dovrebbe, in principio, essere ritenuto già colpevole di eventuali millantati difetti del suo prodotto, a meno che non sia lui a dimostrare il contrario. Con ciò possiamo davvero chiudere baracca e burattini, perché abbiamo toccato il fondo.
Ma, proprio perché siamo arrivati al capolinea, non poteva mancare la classica ciliegina sulla torta, con una fallacia logica da manuale (la falsa dicotomia): <<se l’idea di innovazione che si ha in mente è inondare il mercato di prodotti mal funzionanti e ridurre chi li usa a inconsapevoli collaudatori o, più spesso, cavie, senza volersi nemmeno fare carico degli effetti avversi. Se, invece, progresso significa migliorare la qualità della vita del maggior numero possibile di persone, allora quella che spesso viene presentata come “innovazione” è soltanto avidità da soddisfare a qualsiasi costo, inclusa la messa in pericolo della vita umana>>. Il mondo, insomma, è o bianco o nero, per come lo concepisce l’autore. Per lui l’innovazione o è soltanto dare il via libera a prodotti malfunzionanti oppure migliorare la vita delle persone: non ci sono altre possibilità! Inutile rimarcare che il mondo, e la logica, funzionino ben diversamente.
A motivo di ciò posso affermare che non essere d’accordo con lui non equivale, infatti, a essere automaticamente dalla parte degli avidi o di chi addirittura metterebbe in pericolo la vita della gente. Anche qui, non trova niente di meglio da fare che un po’ di “sano” terrorismo psicologico per indurre gli sventurati lettori a mettersi dalla sua parte senza se e senza ma. Le sue tesi erano talmente “solide” da aver evidentemente bisogno di un altro aiutino…
