Software e responsabilità da prodotto: il caso del Boeing 737 MAX 8
di Pier Giorgio Chiara
L’applicabilità del regime di responsabilità da prodotto difettoso al software
La Direttiva 85/374/CEE, nata nelle intenzioni del legislatore europeo come strumento armonizzatore della normativa degli Stati membri in materia di responsabilità per danno da prodotti difettosi[i], ricalcando in larga parte lo schema statunitense[ii], è stata recepita dal legislatore italiano con il D.P.R. del 24 maggio del 1988, poi abrogato dalla successiva entrata in vigore, il 23 Ottobre 2005, del D. Lgs. n. 206/2005 (“Codice del Consumo”).
Il paradigma della disciplina fa perno attorno ad una speciale forma di responsabilità oggettiva[iii]del produttore per i danni cagionati dal suo prodotto[iv].
I problemi sorgono quando il danno che si è verificato è stato cagionato da un prodotto basato su un software (embedded software).
In primo luogo, è da stabilirsi se un programma informatico possa essere considerato “prodotto”, ai sensi della normativa europea, ovvero se non sia più opportuno catalogarlo come servizio. A favore di una esclusione dall’inquadramento giuridico fornito dalla disciplina comunitaria vi è la tesi per cui il software sia immateriale. Parte della dottrina, infatti, sostiene che la Direttiva non si applichi a tali realtà[v], dal momento che l’elettricità – bene immateriale – è esplicitamente inserita nel novero dei prodotti di cui all’articolo 2, inferendo pertanto che le altre cose immateriali siano escluse dall’ambito di applicazione della normativa per via del principio unius inclusio est alterius exclusio[vi]. L’argomento circa la tangibilità del software, soprattutto negli anni a cavallo del secondo millennio, veniva fatto derivare dalla distinzione tra il materiale di supporto ospitante il programma (prima il cd. floppy disk, quindi il CD-ROM) e il contenuto stesso, vale a dire l’informazione contenuta nelle linee di codice: nella prima ipotesi, una certa dottrina, supportata dalla Commissione europea[vii], effettuava un giudizio positivo circa la materialità, mentre nel secondo caso si negava la materialità e quindi la natura stessa di prodotto[viii]. Pertanto, seguendo questa corrente, la Direttiva avrebbe trovato campo di applicazione quando il danno risultante fosse stato causato da un difetto del medium di archiviazione; ove l’informazione stessa fosse risultata “difettosa” -per usare i termini del legislatore europeo, per quanto difficilmente si possano immaginare estendibili a tali entità- invece, non ci sarebbe stata possibilità di estendere le soluzioni dello strumento europeo al caso di specie[ix].
Tuttavia, è più verosimile che un danno si verifichi a latere del supporto ospitante: con il progredire della scienza informatica, il software è distribuito sempre di più online e via download, pertanto secondo il ragionamento della dottrina sopra citata non potrebbe rientrare nella definizione di prodotto[x]. Di più, la vera importanza del software risiede non tanto nel supporto attraverso cui l’informazione è veicolata, piuttosto nell’informazione stessa, rappresentante la totalità del valore del codice[xi]. Secondo questo filone interpretativo, dunque, il software in quanto tale sarebbe immateriale, e pertanto ricadrebbe fuori dallo scopo della Direttiva. Questa teoria sposa soprattutto la corrente statunitense[xii], mentre si potrebbe argomentare che la tendenza europea è quella di catalogare come prodotto il software, ancorché distribuito via download[xiii].
Voce minoritaria di dottrina, invece, suggerisce che nei casi in cui il software non possa essere chiaramente distinto dal bene materiale che lo incorpora, la Direttiva dovrebbe trovare applicazione e il software dovrebbe essere considerato come un prodotto, stante la complessa ed inestricabile relazione con il bene[xiv]. Questa considerazione solleverebbe diversi interrogativi nel campo della robotica avanzata: laddove la componente software, determinante la condotta del robot, sia basata su algoritmi di machine learning[xv] o deep learning[xvi], è molto probabile che sorgano sensibili difficoltà in tema di prevedibilità[xvii], uno dei criteri in uso presso le Corti, sia di common law che di civil law[xviii], per la determinazione del nesso causale[xix].
Giova notare come molte corti di common law abbiano applicato la legge contrattuale dell’Uniform Commercial Code in casi concernenti il software, mentre mai gli strumenti di responsabilità da prodotto difettoso, nel campo della responsabilità extracontrattuale, sono stati applicati ai produttori per un software “difettoso”[xx].
In conclusione, in Europa, un commento definitivo circa lo status giuridico del software potrebbe essere imprudente prima di una chiara determinazione della Corte di Giustizia europea circa l’ambito di applicazione della Direttiva da una parte e la conformità della ricezione dello strumento comunitario da parte degli Stati Membri dall’altra[xxi].
Il requisito della difettosità
Parlare di difettosità, nel campo del software, potrebbe essere fuorviante. La Direttiva, all’articolo 6, definisce difettoso il prodotto quando non offre la sicurezza che ci si può legittimamente attendere tenuto conto di tutte le circostanze, tra cui: la presentazione del prodotto, l’uso al quale il prodotto può essere ragionevolmente destinato, il momento della messa in circolazione del prodotto. Al comma secondo, invece, è inserita una presunzione assoluta di non difettosità per il solo fatto che un prodotto più perfezionato sia stato messo in circolazione successivamente ad esso.
La nozione di difetto pertanto è costruita attorno gli standards di sicurezza del prodotto, avendo riguardo delle attese legittime circa il suo utilizzo. La norma, secondo Monateri, istituirebbe una definizione relazionale, piuttosto che strutturale[xxii]. Parallelamente, negli USA tale requisito è determinato sulla sola base dell’aspettativa del consumatore medio: non trova pertanto applicazione il c.d. risk-utility test[xxiii]. Così, anche in Europa, tale test dovrebbe essere oggettivo in quanto rivolto ad un pubblico generico[xxiv], facente parte però della comunità di riferimento del prodotto sotto indagine[xxv], e non di converso basato sulle generiche e soggettive aspettative di un consumatore[xxvi]. Vi sono vari standards aventi lo scopo di guidare i professionisti nella valutazione della qualità del software, come ISO/IEC 25010[xxvii], secondo cui la qualità di un programma deve essere valutata secondo diversi parametri tra cui: adeguatezza funzionale (functional suitability), efficienza della performance (performance efficiency), compatibilità (compatibility), utilizzabilità (usability), affidabilità (reliability), sicurezza(security), manutenibilità (maintainability) e trasferibilità(portability)[xxviii]. Soprattutto in settori caratterizzati da un’esponenziale evoluzione come quelli della robotica e dell’artificial intelligence(da qui in avanti AI), potrebbe passare un lasso significativo di tempo prima che gli attori possano fare affidamento su standard adeguati per provare la difettosità[xxix].
In aggiunta, le caratteristiche dei big data (ossia volume, velocità, varianza e veridicità) pongono serie difficoltà nell’ottenimento di elevati standard di sicurezza[xxx]e, nonostante sia stata riconosciuta la necessità di una conoscenza più approfondita del fenomeno in campo ingegneristico[xxxi], purtuttavia una certa dottrina è pessimista sul fatto che vi sia, allo stato dell’arte, una profonda ricerca scientifica in grado di comprendere, dedurre, specificare, analizzare ed infine validare requisiti qualitativi[xxxii].
Altro aspetto di complicazione può provenire dalle tecniche algoritmiche di machine learning[xxxiii] e di deep learning[xxxiv]. È, infatti, da determinarsi se possano portare a risultanze differenti rispetto a quelle che uno poteva legittimamente attendersi: in questo, tali applicazioni potrebbero aprire delle crepe nella nozione tradizionale di difetto.
Inoltre, un altro dato rilevante nella trattazione della difettosità del software, (rectius: quando l’operatore finale sperimenta un fallimento), è la qualità del data-set. Sembra infatti difficile estendere l’interpretazione del testo della Direttiva ai potenziali effetti di dati unfair, imbalanced o biased[xxxv]. Ancora, la qualità del prodotto finale, misurata in termini quantitativi circa i bugs verificatisi, è anch’essa influenzata dalla qualità dei dati che vengono processati[xxxvi].
Ulteriore elemento di riflessione è la mancanza di una definizione precisa circa cosa debba intendersi per software fault: tecnicamente, potrebbe intendersi per guasto/difetto un’imperfezione strutturale che possa portare all’eventuale insuccesso del sistema[xxxvii]. Secondo la ricerca portata avanti da Munsona, un numero sorprendente di segnalazioni riportate come difetti del codice è risultato invece essere un difetto a livello di design: “the design implements the specification and the code implements the design”[xxxviii]. Se da una parte è d’uso comune chiamare bug[xxxix] ogni mancato raggiungimento, da parte delle prestazioni del software, delle legittime aspettative del consumatore, d’altra parte il vero bug è il fallimento del software nel conformare le proprie operazioni alle aspettative di chi l’ha creato[xl]. Molti dei bug segnalati sono, in verità, la corretta ed attesa combinazione tra hardware e software, ma non rappresentano ciò che l’operatore finale si attende: pertanto, secondo una certa dottrina, possono essere considerati difetti (fault) ma non guasti (failure)[xli].
Tali problematiche legate al design tendono ad apparire nella fase del testing. In questa fase, ci sono sostanziali differenze rispetto ai prodotti tradizionali[xlii]: è molto difficile, anziché no impossibile tastare un programma in modo esaustivo[xliii]. I test, infatti, non potendo provare in maniera assoluta che non vi siano bug all’interno del programma, si limitano ad evidenziare l’esistenza di un problema che rilevano[xliv].
L’interrogativo centrale e decisivo, pertanto, ruota attorno all’incertezza circa quale sia il test necessario per determinare la difettosità del design di un algoritmo, dal momento che tale dimostrazione risulterebbe inevitabilmente per essere una prova diabolica per la parte attrice[xlv]. Che, in caso di applicazione della Direttiva, avrebbe questo fardello.
Pertanto, dovrebbe essere presa in considerazione l’eventualità di una responsabilità per danni generati da software “difettosi”, siano essi incorporati (nel caso della robotica) o meno, basata su una diversa nozione di difettosità.
Il caso del Boeing 737 Max 8
Il drammatico incidente aereo occorso in Etiopia il 10 marzo scorso ha sconvolto l’opinione pubblica; è infatti il secondo Boeing 737 Max 8 – gioiellino del big player statunitense – che precipita appena dopo il decollo nell’arco di pochi mesi. La prima tragedia è avvenuta in Indonesia, il 29 ottobre 2018.
La valutazione giuridica, in tema di responsabilità extracontrattuale, del caso avverrà secondo gli schemi del tort law statunitense, visto e considerato che l’azienda ha il proprio quartier generale a Chicago, Illinois. Lungi dall’analizzare le diverse e ulteriori questioni in tema di giurisdizione che potrebbero emergere in un’ottica di conflicts of laws di puro diritto internazionale privato, stante la vocazione transnazionale dell’azienda e considerato, peraltro, che gli incidenti sono occorsi in Paesi al di fuori degli USA, una breve valutazione sul caso pratico può essere d’aiuto per ragionare in ottica operativa circa un caso pratico, recente e di difficile interpretazione e catalogazione di faulty software. Allo stato dell’arte, infatti, le prime informazioni che trapelano sono decisamente orientate verso questo inquadramento[xlvi]. Se infatti il focus di questo lavoro è prevalentemente euro-centrico, il problema di policy sollevato da questo caso è indubbiamente trasversale e comune ai paradigmi statunitense ed europeo, che pure operano dietro regole in parte diverse.
Al dramma umano si somma un interrogativo giuridico, che stinge nell’etica. Infatti, Boeing è unanimemente riconosciuto come leader del settore, e maggior esportatore nordamericano[xlvii], al punto da fregiarsene nell’homepage del proprio sito web senza troppi giri di parole: “Boeing is the world’s largest aerospace company and leading manufacturer of commercial jetliners, defense, space and security systems, and service provider of aftermarket support”[xlviii]. La questione etica, prima ancora che giuridica, sembra possa essere articolata in due sotto-insiemi: da una parte l’incredulità circa la leggerezza, apparente, con cui un big-player del settore abbia permesso ai suoi velivoli di volare con un sistema che già aveva condotto ad una tragedia, dall’altra – come sembra – la drammatica lotta dei piloti, tagliati fuori dal sistema, contro il software.
Infatti, l’autorità competente della regolazione aerea statunitense aveva allertato, a seguito del primo incidente indonesiano, le compagnie aeree, sulla scorta dell’allarme lanciato da Boeing, di un possibile difetto (flaw) nel software MCAS[xlix], programmato per essere una misura di sicurezza ulteriore, ironia della sorte, in situazioni relativamente critiche: trattasi di un software anti-stallo, pensato “per abbassare automaticamente il muso dell’aereo quando l’angolo di attacco, ovvero l’angolo tra il flusso d’aria e l’ala, fosse risultato troppo elevato, comportando il rischio di stallo aerodinamico”[l], dovuto ad un posizionamento diverso dei motori. L’allarme lanciato da Boeing, per quanto doveroso, è da leggersi anche alla luce della scelta fatta dall’azienda stessa, all’uscita dei nuovi modelli sul mercato, di non informare i piloti circa i cambiamenti effettuati sul sistema di controllo: come riportato dal Wall Street Journal, Boeing era preoccupata dal fatto di sovraccaricare eccessivamente, e inutilmente, i piloti di informazioni e dati tecnici da cui difficilmente avrebbero tratto qualche utilità (sic!)[li]. Dopo il primo disastro, ovviamente Boeing è corsa ai ripari, allertando le compagnie aeree che i sensori dell’angolo di attacco MAX avrebbero potuto non funzionare correttamente, che questo malfunzionamento avrebbe potuto dirigere il muso dell’aereo verso terra ma anche che i piloti avrebbero potuto evitare il problema in sicurezza escludendo il sistema dalle operazioni di comando, passando quindi ad una conduzione manuale[lii].
Ciononostante, la tragedia si è consumata nuovamente, con la medesima dinamica.
Non sembra assurdo parlare, quasi in termini fantascientifici con sfumature apocalittiche, di una sfida uomo-macchina. Che disgraziatamente è stata vinta dai calcolatori in entrambe le occasioni.
Il rapporto preliminare delle autorità etiopi non menziona, per ovvie esigenze di prudenza politica, in modo esplicito il sistema anti-stallo MCAS, “ma come fanno notare diversi esperti la descrizione della dinamica ricorda proprio lo scontro uomo-software del volo Lion Air indonesiano”[liii]. In entrambi i casi i problemi sono iniziati pochi istanti dopo il decollo: il sensore esterno (l’angolo di incidenza) riceveva e trasmetteva informazioni sbagliate, facendo sì che il muso puntasse verso il basso perché il sistema anti-stallo MCAS elaborava informazioni sbagliate[liv]. Il rapporto esclude qualsiasi problema ai motori.
Conclusioni
Se da una parte è vero che il vasto panorama dottrinale risultante dalla trattazione del tema sia caotico, è pur vero anche che la Commissione Europea ha istituito un gruppo di lavoro[lv]per stabilire se e in quale portata gli istituti della Direttiva sulla responsabilità da prodotto difettoso siano ancora efficaci, rilevanti e coerenti nel contesto delle c.d. tecnologie digitali emergenti[lvi].
Pertanto, in attesa che il rapporto finale del gruppo di lavoro, istituito dalla Commissione europea circa la tenuta degli strumenti del 1985 nel contesto attuale ove l’innovazione tecnologica aumenta esponenzialmente, venga sottoposto al vaglio di Commissione, e quindi Parlamento e Consiglio europeo, ogni commento risolutorio sul punto sembrerebbe futile ancorché accurato, dal momento che il diritto positivo nel prossimo futuro potrebbe essere diverso da quello che ha disposizione oggi il giurista europeo.
Bibliografia:
[i]Imponente la letteratura in tema, cfr. Kelly P., Attree R. (a cura di), European Product Liability, Butterworths, Londra, 1992.
[ii]Cfr. sul punto Fairgrieve, D. et al., Product Liability Directive, in Machnikowski, P., (a cura di), European Product Liability – An Analysis of the State of the Art in the Era of New Technologies, Intersentia, 2016, 19; vedi anche Avvocato Generale Tesauro, G., nel caso C-300/95, Commissione vs Regno Unito, 1997, ECR I-2649; vedi anche Owen, D., Products Liability Law, St. Paul: West, 2005, 3-4
[iii]Cfr.sul punto Monateri, P.G., Manuale della Responsabilità Giuridica, Utet, Torino, 2001, 510 ss: la disciplina europea non precluderebbe il regime generale di responsabilità delineatosi negli anni precedenti, in quanto ex art. 127 del Cod. Consumo le sue stesse “disposizioni non escludono né limitano i diritti attribuiti al danneggiato da altre leggi”. Tale inquadramento risulta quindi fondato sullo schema della responsabilità oggettiva ma, non realizzandosi i suoi presupposti, la materia rimane regolata dai principi generali della responsabilità civile.
[iv]Art. 114, D. Lgs. 6 settembre 2005, n. 206; vedi anche Art. 1, Direttiva 85/374/CEE del Consiglio del 25 luglio 1985.
[v]Wuyts, D., The Product Liability Directive – More than two decades of defective products in Europe, Journal European Tort Law, 5; vedi anche Alhelt, K., The Applicability of the EU Product Liability Directive to Software, Comparative and International Law Journal South Africa, 2001, 200.
[vi]Contra cfr. Wagner, G., Robot Liability, in Lohsse, S., Schulze, R., Staudenmayer, D., (a cura di), Liability for Robotics and in the Internet of Things: Munster Colloquia on Eu Law and the DigitalEconomy, Hart Nomos, 2019, 36: l’autore sostiene come il legislatore europeo avesse in realtà una concezione estremamente ampia di bene mobile, non limitata agli oggetti materiali. L’inclusione dell’elettricità, secondo Wagner, è un semplice esempio e che, a fortiori, il software rappresenti un esempio ancora migliore: “on this view, the PLD, already in its current form, does apply to software “products”. This expansive view, that applies Art. 2 of the Directive in a functional way, excluding only real estate and services, is preferable. The Directive should not be limited in scope to old-school products”.
[vii]Anche la Commissione Europea, infatti, si è espressa positivamente circa la natura di prodotto del software ove contenuto su un medium materiale: si veda la risposta della Commissione alla richiesta scritta, in data 15 novembre 1988, di Gijs De Vries, (89C 114/76), OJ C114/42
[viii]Cfr. Triaille, J., The EEC Directive on Product Liability and its Application to Databases and Information, Computer Law and Practice, 1991, 219; si veda anche Alhelt, K., The Applicability of the EU Product Liability Directive to Software, op. cit., 200
[ix]CosìLloyd, I. J., Information Technology Law, Oxford University Press, 2008, 514-515: nel common-lawla vexata quaestio se il software comporti la resa di un servizio o la vendita di un prodotto è risolta con l’applicazione del cd. essential nature test. Un contratto viene esaminato, case by case, per stabilire se il software, in quello specifico caso, si riferisca ad una vendita o ad una fornitura di servizi. Cfr. caso St Albans District Council v ICL, [1996], soprattutto la domanda posta alla Corte da Sir Glidewell.
[x]Cfr. sul punto Zollers, F. E., et al., No More Soft Landings for Software: Liability for Defects in an Industry That Has Come of Age, Santa Clara High Technology Law Journal, 2005, 749.
Contra si vedano Cahn, A., Produkthaftung fur verkorperte geistige Leistungen, NJW 2899, 1996, 2904 e Spindler, G., Verschuldensunabhangige Produkthaftung im Internet, MMR 119, 1998, 121
[xi]Cfr. sul punto Fairgrieve, D., et al., Product Liability Directive, op. cit., 47-49: “it could be argued in parallel that the acceptance of that defective [or flawed] information as such could give rise to liability of the producer of that information would be in line with an effective application of the Directive in a way that is favourable to the interests of consumers.”
[xii]Cfr. sul punto Chopra, S., e White, L. F., A Legal Theory for Autonomous Artificial Agents, University of Michigan Press, 2011, 136
[xiii]Cfr. sul punto Wagner, B., et al., Research Handbook on Human Rights and Digital Technology: Global Politics, Law and International Relations, Edward Elgar Publishing, 2019, 281: “the recent case law of CJEU on the exhaustion of the distribution right in software under copyright law may indicate that the courts tend to liken immaterial forms of distribution to material forms, which may also indicate a certain openness to an equal treatment in other areas of the law”. Si veda sul punto il caso C-128/11 Oracle v. UsedSoft [2012] OJ C287/10
[xiv]Cfr. sul punto Link, K.-U., e Sambuc, T., Federal Republic of Germany in Kelly, P., e Attree, R., (a cura di), European Product Liability, op. cit., 157
[xv]Per una lettura più approfondita sul tema vedere Alpaydin, E., Introduction to Machine Learning, The MIT Press, 2010; Surden, H., Machine Learning and Law, Washington Law Review, 2014, 89 ss; Sartor, G., L’Informatica Giuridica e le Tecnologie dell’Informazione, Giappichelli, Torino, 281-283
[xvi]Per una lettura più approfondita in merito si veda Goodfellow, I., Bengio, Y., e Courville, A., Deep Learning, The MIT Press, 2016, 8-12
[xvii]Cfr. sul punto Gianti, D., Il Nesso di Causalità come Elemento della Fattispecie di Responsabilità Aquiliana in Causazione e Giusitificazione del Danno, a cura di, Monateri, P. G., Gianti, D., Balestrieri, M., Giappicchelli, 2016, 45-46. Dal punto di vista del diritto italiano, la causalità c.d. “giuridica”, che deve sussistere tra l’illecito dannoso che è stato causato e il concreto danno economico subito a seguito di questo da un particolare soggetto, è determinata dall’articolo 1223 c.c., prevedendo la sola risarcibilità dei danni che sono “immediati e diretta conseguenza dell’evento dannoso”. Le Corti, con il passare del tempo, hanno affinato diversi criteri per dare significato alla lettera dell’articolo: i due criteri più in uso, per determinare l’immediatezza e la diretta conseguenza” sono la normalità e la prevedibilità.
[xviii]Imponente la letteratura sul tema; si vedano in particolare: Harper, F. V.,et al., On Torts, Aspen Publishers, 2009, §20.5; Prosser, W. L., Handbook on the Law of Torts, West Publishing Company, 1971, 271; Dobbs, D. B., The Law of Torts, West Group, 2000, 447. In modo del tutto similare a quanto avviene nelle Corti di civil law, nelle Corti di common lawla ragionevole prevedibilità della conseguenza dannosa di un fatto è essenziale per stabilire la causalità (proximate cause or scope of liability), attraverso il cd foreseeability test: qualora uno si fosse trovato nella posizione di poter ragionevolmente prevedere la conseguenza dannosa scaturente dal fatto illecito, e purtuttavia, potendo prevenirla, non avesse agito, per ciò stesso sarebbe chiamato a risponderne. Si vedano, sul punto, i casi Wagon Mound and Overseas Tankship (U.K.) vs Morts Dock and Engineering Co. e Doughty vs Turner Manufacturing Co. Ltd(1964)
[xix]Sul punto si veda il lavoro diBathaee, Y., The Artificial Intelligence Black Box and the Failure of Intent and Causation, Harvard Journal of Law and Technology, 31, 2018
[xx]Cfr. sul punto Kim, S., Crashed Software: Assessing Product Liability in Software Defects in Automated Vehicles, Duke Law and Technology Review, 2018, 311; si veda anche Sprague, R. D., Software Products Liability: Has Its Time Arrived?, Western State University Law Review, 1991, 137-141.;si veda infine Reutiman, J. L., Defective Information: Should Information be a “Product” Subject to Products Liability Claims?,Cornell Journal of Law & Public Policy, 2012, 185: “those courts that have determined whether computer software is a ‘good’ under the Uniform Commercial Code have struggled to apply a tangible–intangible distinction and have reached conflicting conclusions. Such courts have tended to focus on the service-like aspects of a software sale as compared to the tangible aspects of the software medium”.
[xxi]Si vedano Lloyd, I. J., Information Technology Law, op. cit., 562 e Alhelt, K., The Applicability of the EU Product Liability Directive to Software, op. cit., 203
[xxii]Cfr. sul punto Monateri, P.G., Manuale della Responsabilità Giuridica, op. cit., 520: “la difettosità del prodotto dipende dall’orizzonte di attese legittime sulla sua sicurezza rispetto al suo utilizzo. È chiaro quindi come tale nozione sia affatto diversa da quella di difetto che opera in ambito contrattuale ex artt. 1494 e 1512 c.c.”.
[xxiii]Si vedano sul punto Werro, F., e Palmer, V. V., The Boundaries of Strict Liability in European Tort Law, Carolina Academic Press, 2004, 43 e Howells, G., Comparative Product Liability, Dartmouth, 1993, 36: “a general criticism of consumer expectation test is that they do not give an objective standard against which the product should be judged”.
[xxiv]Cfr. sul punto Alpa, G., e Bessone, M., La Responsabilità del Produttore, Giuffré Editore, Milano, 1999, 340
[xxv]Cfr. sul punto Frignani, A., La Direttiva CEE sulla Responsabilità da Prodotto e la sua Attuazione in Italia in Assicurazioni, 1987, 121 ss
[xxvi]Si vedano sul punto Fairgrieve, D., et al., Product Liability Directive, op. cit., 51 e Monateri, P.G., Manuale della Responsabilità Giuridica, op. cit., 520
[xxvii]Versione aggiornata della precedente ISO/IEC 9126; disponibile al link: https://www.iso.org/standard/35733.html
[xxviii]Cfr. sul punto Huang, F., et al., What Software Quality Characteristics Most Concern Safety-critical Domains?, IEEE International Conference on Software Quality, Reliability and Security Companion, 2018, 635
[xxix]Si veda, sul punto, The IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software, 1988
[xxx]Cfr. sul punto Noorwali, I., et al., Understanding Quality Requirements in the Context of Big Data Systems, IEEE 2nd International Workshop on BIG Data Software Engineering, 2016, 76: “big data characteristics are causing serious difficulties to achieve high system quality standards for security, performance, scalability, privacy and other quality requirements”.
[xxxi]Cfr. sul puntoMadhavji, N. H., et al., Big Picture of Big Data Software Engineering: With example research challenges,Proceedings of First International Workshop on BIG Data Software Engineering, 2015, 11-15
[xxxii]Id., 77
[xxxiii]Vedi supra nota 15
[xxxiv]Vedi supra nota 16
[xxxv]Cfr. sul punto Bachmann, A., eBernstein, A., Software process data quality and characteristics – a historical view on open and closed source projects, in Proceedings of the joint international and annual ERCIM workshops on Principles of software evolution, 2009, 119 ss
[xxxvi]Cfr. sul puntoBachmann, A., e Bernstein, A., When process data quality affects the number of bugs: Correlations in software engineering datasets, in 7th IEEE Working Conference on Mining Software Repositories, 2010, 9
[xxxvii]Cfr. sul puntoMunsona, J. C., et al., Software faults: A quantifiable definitionin Advances in Engineering Software, 37, Elsevier, 2006, 327
[xxxviii]Id., 328-329: “If this problem first manifests itself in the code, it is still not a code fault. It is a fault in the program specification or a specification fault. The software design may not implement the software requirements specification”.
[xxxix]Leggenda vuole che il termine bug sia stato per la prima volta usato nel 1946 quando Grace Hopper stava lavorando nel laboratorio computazionale di Harvard. Ricollegò un errore che si era verificato ad una falena intrappolata nelle staffette della macchina. Vedi a http://www.agnesscott.edulriddle/women/hopper.htm
[xl]Cfr. sul punto Zollers, F. E., et al., No More Soft Landings for Software: Liability for Defects in an Industry That Has Come of Age,op. cit., 750
[xli]Id.
[xlii]Cfr. sul punto Munsona, J. C., et al., Software faults: A quantifiable definitionin Advances, 328
[xliii]Si veda Brooks, F. P., No Silver Bullet. Essence and Accidents of Software Engineering, Computer Magazine, 1987: l’autore sostiene come possa non esserci una facile soluzione per i problemi legati all’ingegneria del software, descrivendo due diverse tipologie di complessità rinvenibili. “Essential complexity is inherent and nothing can remove it. In contrast, accidental complexity is created by programmers and can be dealt with. The accidental complexity of writing and optimizing machine code can be dealt with by programming in high-level languages that require fewer lines of code and have very strong checking routines that test the operation of module interfaces and help to minimize syntax and semantic errors”.
[xliv]Si veda ancora Zollers, F. E., et al., No More Soft Landings for Software: Liability for Defects in an Industry That Has Come of Age,op. cit., 751 ss
[xlv]Cfr. sul punto Borghetti, J.-S., How can Artificial Intelligence be defective?, in Lohsse, S., Schulze, R., Staudenmayer, D., (a cura di), Liability for Robotics and in the Internet of Things: Munster Colloquia on Eu Law and the DigitalEconomy, Hart Nomos, 2019, 64
[xlvi]Si vedano, sul punto,Pascus, B., What to know about the Boeing 737 Max 8, the plane that’s crashed twice in 5 months, CBS News, 12/03/2019; Pfeifer, S., US regulator set to warn new Boeing 737 may have faulty software, Financial Times, 7/11/2018; Glanz, J., et al., After a Lion Air 737 Max Crashed in October, Questions About the Plane Arose, The New York Times, 3/02/2019
[xlvii]Le stime della compagnia si attestano intorno ai 150 paesi raggiunti dai propri prodotti; cfr.https://www.boeing.com/company/
[xlviii]Cfr. sul punto la sezione general information disponibile al link: https://www.boeing.com/company/
[xlix]Cfr. sul punto Pfeifer, S., US regulator set to warn new Boeing 737 may have faulty software, Financial Times, 7/11/2018
[l]Si veda Russo, F., Perché Boeing ha installato sul 737 Max 8 il software che avrebbe causato due disastri, AGI esteri, 13/03/2019
[li]Si veda Pasztor, A., e Tangel, A., Boeing Withheld Information on 737 Model, According to Safety Experts and Others, The Wall Street Journal, 13/11/2018
[lii]Si veda Davies, A., Boeing Plans to Fix the 737 Max Jet with a Software Update, Wired, 13/03/2019
[liii]Si veda Berberi, L., Boeing 737 Max caduto, i piloti hanno lottato 6 minuti contro il computer, Il Corriere della Sera, 4/04/2019
[liv]Id.
[lv]La valutazione della Direttiva è iniziata nel giugno 2016; ha preso quindi in considerazione la Risoluzione del Parlamento europeo, del febbraio 2017, con indicazioni circa le norme di diritto privato applicabili nel campo della robotica. Il report finale dello studio per la valutazione per la valutazione della Direttiva è stato approvato dalla Commissione nel febbraio 2018.
[lvi]Cfr. sul punto il documento istitutivo il gruppo di lavoro della commissione, disponibile a: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52018SC0157&from=GA
Autore:
