La rubrica di Linea Edp affronta i problemi legati all’utilizzo del software e la protezione del proprio nome sul Web
I produttori di software hanno l’obbligo di
adeguare i loro programmi in modo che siano conformi alle normative
vigenti?
p.basenghi
Il software, come tutti i prodotti, deve presentare
particolari caratteristiche al momento del suo rilascio o, come si dice
“essere conforme allo stato dell’arte”. Pertanto, di principio, evoluzioni
della normativa o dello stato delle cose non possono essere rilevanti se non
erano prevedibili al momento della consegna (per il software “su
misura”) o della vendita (per i programmi “pacchettizzati” ) del software. Tale principio, tuttavia, incontra diverse limitazioni.
Per quanto riguarda la normativa
esistente, essa comprende quella in via di entrata in vigore. Ad
esempio, è necessario che un software per la gestione di un sito Internet che
prevede l’iscrizione da parte degli utenti (con relativa indicazione di dati
personali) segua la normativa sulla privacy riguardo alla lunghezza e durata
delle password? Le regole tecniche sulle misure minime di sicurezza erano già
note e “ufficiali” ben prima dell’entrata in vigore delle stesse (peraltro più volte prorogata). Dunque, se il programma in oggetto fosse stato chiaramente destinato al trattamento di dati personali, il produttore non potrebbe giustificarsi affermando che la normativa (al momento del rilascio ma successivamente alla pubblicazione del codice della privacy) non prevedeva, ad esempio, un numero minimo di caratteri nella password.
Può darsi che con il passare del tempo
anche le situazioni di fatto possano mutare, rendendo il prodotto inadatto
all’uso cui era destinato. Il prodotto di per sé rimane perfettamente
funzionante, ma è inservibile (ad esempio, un registratore di cassa in lire).
L’esempio più chiaro in proposito è stato, storicamente, il cosiddetto
“millennium bug” , l’ipotizzato mancato funzionamento di programmi software al passaggio di millennio dovuto all’interpretazione errata di una data codificata a due cifre. Si trattava in larga parte di programmi scritti molti anni prima, quando non sembrava ipotizzabile che la loro vita utile potesse protrarsi alle soglie del nuovo millennio, ma anche di un evento tutt’altro che imprevedibile.
In casi più “normali”, poiché si tratta di
un “vizio” sopravvenuto, l’inquadramento è molto problematico, perché, o una cosa è viziata in origine o il suo buon funzionamento deve essere garantito per un certo tempo, per rendere rilevanti i vizi sopravvenuti.
La recente evoluzione normativa circa i
contratti con il consumatore ha introdotto la nozione di “difetto di
conformità”, ma anche questa non pare essere particolarmente calzante, in
quanto, nelle ipotesi fatte sopra, il bene è “conforme” a contratto.
Non pare, dunque, prospettabile una situazione in cui il produttore di software
“venduto” possa essere tenuto all’adeguamento del suo prodotto. Nemmeno
inquadrando la fattispecie come “appalto” (come sembra possibile nel
caso di software sviluppato ad hoc) le cose sembrano cambiare. Il concetto di
vizio nell’appalto è, infatti, assai vicino a quello della vendita: unicamente i
termini di prescrizione sono più lunghi per i vizi “occulti” , ma abbiamo visto che i vizi debbono sussistere all’origine.
Di vizi sopravvenuti si parla invece , normalmente, nei contratti di locazione. In tali contratti il rapporto è di durata, si paga un corrispettivo temporale per il godimento del bene, il locatore deve mantenere la cosa in stato di fruibilità. Per cui in tutti i casi in cui vi sia un canone (locazione di software, contratto di manutenzione evolutiva, realizzazione e sviluppo di siti Web) le modifiche necessarie per mantenere un sufficiente valore del bene o servizio concesso potrebbero rientrare nel rischio addossato allo sviluppatore, al manutentore, al gestore del servizio. Il quale, tuttavia, nel caso in cui la manutenzione dovesse divenire eccessivamente gravosa per l’imprevedibilità delle mutate condizioni di operatività, potrà opporre la risolvibilità del contratto per eccessiva onerosità sopravvenuta, ottenendo di svincolarsi dal contratto (restituendo eventualmente quanto percepito in eccesso) a meno che l’utilizzatore non offra di ricondurre le condizioni contrattuali a equità.
Posso proteggere il mio nome come dominio per gli indirizzi di posta
elettronica presso i siti più rinomati?
g.troiano
La
protezione del nome non avviene di per sé, ma in quanto espressione di
un’identità commerciale (tutela dell’investimento,
riconoscibilità/confondibilità, concorrenza sleale) o dell’identità personale,
diritto fondamentale della personalità umana. Si tratta, dunque e sempre, di
controbilanciare un diritto con quelli confliggenti di altri, tra i quali la
libertà di impresa e il libero uso dei mezzi di produzione. In ciò vi è una
netta diversità tra i nomi a dominio e gli identificativi della posta
elettronica.
I primi sono un bene pubblico
tendenzialmente scarso, che viene regolamentato tramite la concessione a un soggetto (registration authority) che ne cura l’utilizzo e si dota di alcuni principi in modo da risolvere potenziali conflitti di attribuzione tra più soggetti che possono aspirare a utilizzare quella particolare combinazione di caratteri con un’attinenza semantica al proprio nome, marchio, prodotto e così via. Le regole adottate vanno dal first come-first served, in cui avviene una redistribuzione solo in caso di contestazione (così per il dominio .com, ad esempio) a sistemi che prevedono la necessità di dimostrare la titolarità di un segno proteggibile coincidente con il dominio richiesto.
Gli identificativi di posta elettronica,
invece, sono gestiti in modo autonomo da soggetti privati che hanno ottenuto la
“concessione” di un nome a dominio e pertanto hanno la possibilità di assegnare
identificativi in modo assolutamente arbitrario, in quanto si tratta di una
combinazione di segni (la parte a sinistra del carattere @) che non è più
“pubblica”, ma segue l’assegnazione in via esclusiva del nome a
dominio. Per tale parte vale il principio della libera attività economica del
titolare del nome a dominio nell’assegnarli, o nel non assegnarli, a chi vuole
(il nome “dominio” suggerisce proprio tale potestà).
Solo nel caso di particolari nomi a
dominio (come quello delle città o delle sigle automobilistiche, tipo mi.it) si può ipotizzare che, per la natura pubblicistica dell’assegnazione, l’assegnatario rivesta la stessa posizione di una registration authority e debba osservare e imporre regole per l’assegnazione dei sottodomini (esempio: comune.milano.mi.it), così come degli identificativi degli utenti. Ciò vale ad esempio in Italia quando l’assegnazione viene affidata a un’autorità amministrativa o in base a una concessione per finalità pubbliche.
Comunque, il fornitore di servizi
Internet può essere considerato responsabile quando consenta di
utilizzare identificativi in modo abusivo a chi si sostituisca fraudolentemente
ad altri. Da qui l’auspicabilità che vi sia un certo controllo per provider
“pubblici” .
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
