Prendo spunto da questo articolo del WP. Si sente ogni tanto dire che chi produce software dovrebbe essere ritenuto responsabile dei difetti dei suoi prodotti allo stesso modo in cui sono responsabili i produttori, ad esempio, di pneumatici. L’obiezione, che condivido, è che il software è troppo complesso per utilizzare le stesse logiche di prodotti enormemente più semplici e stabilizzati. Tuttavia, non credo che chi ha comportamenti come quello citato nell’articolo debba farla franca. In quel caso in realtà si tratta di servizi e non di software, ma il principio è simile, e cioè che tutto quello che riguarda l’ICT sembra essere un Far West in cui conta solo quanto sei veloce con la pistola: vale per il software, per i servizi, per le licenze. Ebbene, se è vero che non si può punire un’azienda perché il software ha dei bachi, sicuramente la si può, e la si deve punire se ha delle pratiche che il rischio di avere difetti lo aumentano, o che aumentano il rischio che quei difetti causino danni. Ad esempio, è ragionevole che scappi qualche validazione di input: non è ragionevole che il problema venga trascurato metodicamente. Oppure, se è vero che ci sono dei tempi tecnici per la produzione di patch, non deve comunque essere a discrezione del produttore prolungare quei tempi a piacere. Naturalmente, esattamente come un pneumatico può essere certificato solo per determinate velocità, un software può essere limitato ad attività “non critiche”. Ma a quel punto dovrebbe essere sanzionabile chi il software lo usa per offrire servizi critici e causa dei danni, esattamente come ad un automobilista non è permesso montare pneumatici inadatti “perché costano meno” e poi causare incidenti perché non reggono lo sforzo. E, mi dispiace per alcuni progetti open source, indicare un prodotto come beta vita natural durante e poi vantarsi del suo utilizzo per servizi importanti, non vale.
Che dire del software rilasciato gratuitamente da qualcuno che non è un’azienda con una capacità finanziaria di gestire eventuali richieste di danni? Vorrà dire che potrà avere un uso hobbistico: se qualcuno lo usa per offrire servizi critici, allora possono cominciare a girare i soldi necessari per fornire la copertura necessaria. Del resto, è così anche negli altri settori: non è che se uno produce formaggio artigianalmente anziché industrialmente, si può permettere di intossicare la gente impunemente. E ripeto, il problema non è produrre software perfetto: il problema è che se si produce software da utilizzare per servizi di una certa criticità, allora la gestione deve essere all’altezza. Se poi il software è sviluppato con cura e ciononostante ha un difetto, non è un problema: dopotutto è nella natura del software.
Naturalmente lo stesso vale per i servizi: chi offre servizi nel modo descritto nell’articolo del WP deve diventare responsabile di eventuali danni dati da attività di phishing legata al loro sito, perché è chiaro che hanno creato le condizioni perché l’utente non potesse distinguere un messaggio buono da uno cattivo, e questo in barba alle pratiche indicate da tutti per gestire queste comunicazioni. Ho l’impressione che in questo modo, tante cattive pratiche sparirebbero molto rapidamente 😉
