L’avvocato risponde: la privacy

Questa settimana la rubrica di Linea Edp riguarda le licenze virali e la responsabilità, che può essere civile o penale, cui è sottoposto il titolare di trattamento dei dati personali oggetto della legge sulla privacy

La mia azienda rispetta il “disciplinare tecnico” sulle misure di
sicurezza per la privacy: siamo a posto?

m.polloni
Il
disciplinare tecnico, ovvero l’allegato B al Dlgs 196/2003 (Codice della
privacy) contiene le misure minime di sicurezza che un titolare di trattamento
(colui che tratta i dati) deve osservare per non incorrere in sanzioni penali.
Tuttavia il semplice rispetto di tali misure di sicurezza non è sufficiente a
garantire che nessuna conseguenza derivi dal trattamento di dati personali in
caso di eventi avversi.
Oltre che in responsabilità penale, infatti, il titolare del trattamento può incorrere in responsabilità civile, per il caso che il cattivo trattamento dei dati causi un danno (anche morale) all’interessato (colui al quale i dati si riferiscono). Per non incorrere in responsabilità civile, il titolare deve adottare misure di sicurezza “idonee”.



Se sappiamo quali sono le misure
minime
, quelle idonee non sono dettagliatamente descritte da nessuna norma in particolare. Il Codice prevede unicamente un riferimento generico e adattabile nel tempo a “tutto quanto è possibile fare per evitare il danno”. Dunque occorre rifarsi a concetti del tutto incerti, quale “lo stato della tecnica” o simili.
Tale incertezza appare intollerabile. Non è possibile avere
riferimenti precisi ai quali rifarsi? Non sono sicuro che la risposta piacerà ai
lettori. Effettivamente esistono norme standard o quantomeno documenti a cui
fare riferimento. In particolare a due di essi ci si può affidare come guida per
l’adeguamento: il British Standard 7799-Iso/Iec 27001:2005 e le linee guida di
sicurezza nei sistemi informatici redatta dal Cnipa (al tempo Aipa).



Attenzione, però, la sicurezza è
sempre
un concetto relativo, una funzione del risultato che si desidera ottenere, secondo parametri multipli. Ad esempio, ci si attende un grado di sicurezza di un certo tipo per i dati sensibili, di un altro tipo per i dati comuni. Differenti conseguenze si hanno per dati diversi, anche tra i non sensibili: il codice d’accesso dei servizi di home banking ha un diverso grado di “pericolosità” per l’interessato del numero di cellulare, ci si aspetta che il livello di protezione sia diverso, in quanto sarebbe antieconomico e inefficiente adattare ogni sistema di protezione a quello del dato più “pericoloso”.



Inoltre, i rischi da proteggere sono di più della semplice “sicurezza perimetrale”, ovvero escludere dai dati chi non deve accedervi. Un tipo di protezione spesso ignorata è quella della disponibilità dei dati, cioé la garanzia che chi deve accedere agli stessi lo possa fare nei tempi e nei modi previsti. Inoltre l’accuratezza dei dati (completezza, aggiornamento, correttezza) è un aspetto che spesso le norme sulla sicurezza trascurano, anche se sono fondamentali.
In questi casi ricorro a un esempio. Secondo una nota
definizione, il computer più sicuro sta in un bunker fatto di venti metri di
cemento armato, sottoterra, in una gabbia di Faraday (completa schermatura
elettromagnetica) senza porte d’entrata, spento e senza prese di corrente o di
rete. E anche così qualche dubbio c’é. Ma con esso, cosa possiamo fare? Questo
computer non è idoneo a trattare dati personali.



Altro esempio. Un ospedale che
tratti
erroneamente il dato “il paziente ha un’intolleranza alimentare” e prepari cibi incompatibili con il regime alimentare previsto può causare la morte di una persona, il che è sicuramente una conseguenza assai meno desiderabile del fatto che “si sappia in giro” del problema sanitario. Io, personalmente, preferirei avere tale dato tatuato sulla fronte, piuttosto che dipartirmi da questo mondo perché non è stata vista l’annotazione sulla scheda-pasto.
Dunque la sicurezza in termini di esclusione dall’accesso dei dati verso chi deve essere escluso non è tutto, a volte nemmeno l’aspetto più rilevante. Perciò, nel documento programmatico sulla sicurezza il titolare dovrà dimostrare di aver considerato il livello di pericolo per le varie categorie di eventi sui vari tipi di dati e aver adottato un approccio il più possibile adeguato per bilanciare opposte esigenze. Anche qui la parola d’ordine dovrebbe essere “ragionevolezza”, ma non sono sicuro che tale espressione abbia un qualche significato nel Bel Paese.



Ho sentito parlare di “licenze virali”. Sono pericolose?
p.soriano
“Licenze virali” è una pessima espressione, coniata in malafede. Si tratta di un cattivo modo di esprimersi, come usare il termine “hacker” per definire un malintenzionato che viola un sistema informatico per scopi illeciti (a seconda dei casi “cracker”, “defacer”, “script kid”).



Con “licenze virali” qualcuno si riferisce a licenze di diritto d’autore (soprattutto di software) che hanno la caratteristica di “propagare” necessariamente tutte o alcune delle proprie caratteristiche a prodotti derivati. Tale effetto propagativo viene sovente riferito alle licenze di software libero di tipo “copyleft” (vedremo poi che cosa è). Si tratta, però, di una caratterizzazione del tutto erronea. Il tipico effetto propagativo, infatti, è proprio di licenze di tipo “tradizionale”.
Esempio ne sono le licenze “Sdk” (Software development kit),
che consentono a uno sviluppatore di produrre software a partire da una
piattaforma di sviluppo. Molte licenze di questo tipo prevedono una royalty per
ogni copia venduta del programma sviluppato.



Dunque, anche il software derivato da una Sdk deve essere licenziato sotto un tipo di licenza che consenta il controllo del numero di copie acquistate dall’utente finale e di riferire al licenziante dell’Sdk tale numero, al fine di trarre dalle copie la royalty convenuta. Spesso si impone addirittura una licenza per l’utente finale (Eula) dettagliatamente definita.
Il copyleft funziona sostanzialmente nello stesso modo. Soltanto che, in luogo di imporre un’Eula compatibile con l’esazione di una royalty, il copyleft impone che l’opera derivata (si perdoni l’imprecisione) sia rilasciata sotto la stessa licenza originale o una compatibile, ovvero che rimanga software libero (da qui copy-left: “left” infatti è il contrario di “right”, “destra”, ma significa anche “lasciato, rimasto”).



Esattamente come nel primo caso, il
rilascio
sotto un particolare tipo di licenze è una condizione per soddisfare il copyright e adempiere alla licenza. Se qualcuno “per errore” incorpora o deriva software da un originale sottoposto a copyleft, non ne è “infettato”,
semplicemente commette un illecito contro il copyright dell’autore originale
perché usa l’opera al di fuori di ciò che gli è consentito. Dunque o cambia il
proprio prodotto per eliminare l’inconveniente, oppure ottiene il permesso dal
titolare di fare quello che ha in animo di fare.



Prendiamo MySql, un database
soggetto
alternativamente alla Gnu Gpl (la principale licenza di copyleft) o a una licenza “proprietaria”: chi intende derivare software da esso senza rilasciarlo sotto Gnu Gpl deve semplicemente acquistare una licenza “proprietaria”, senza nessuna “infezione”. Le licenze virali, dunque, semplicemente
non esistono.


L’esperto
Lo
studio Tamos Piana & Partners di Milano si occupa di campi innovativi del
diritto civile e amministrativo, tra i quali l’Information technology law e il
diritto del software, ma anche di appalti pubblici di servizi, di privacy e di
diritto sanitario. Attraverso un sistema a rete garantisce assistenza e
consulenza nei campi di interesse delle aziende e degli enti pubblici. Carlo
Piana è socio fondatore dello studio, membro italiano e fondatore di
euroITcounsel, circolo europeo di qualità di avvocati specializzati in
It&Tlc law, nonché parte del team legale della Free Software Foundation
Europe. Vanta un’esperienza più che decennale nel settore della tutela del
software. www.avvocatinteam.com

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome