Convegno 14.01.2019

By | News | No Comments

In data 14 Gennaio 2019 a Genova al Centro Culturale, Formazione e Attività Forensi Aula Convegni del Consiglio dell’Ordine degli Avvocati, CAMMINO – Camera Nazionale Avvocati per le persone, le relazioni familiari e i minorenni – della sede di Genova ha tenuto un convegno sull’argomento “Tavola Rotonda: Affido Condiviso, Mantenimento Diretto, Garanzia Bigenitorialità: decreto Pillon, un’illusione di parità?”.

GDPR, la difficoltà di raccordo tra vecchie e nuove norme

By | News | No Comments

Il cambio di paradigma introdotto dal GDPR nella protezione delle informazioni in rete e le difficoltà di raccordo tra le nuove norme e quelle preesistenti: il punto della situazione
Nel nostro Paese, nonostante le importanti novità introdotte dal GDPR in tema protezione della riservatezza dei dati in rete, si è preferito non abrogare e sostituire completamente il previgente Codice della Privacy del 2013 ma piuttosto modificarlo, adeguarlo e in parte eliminarlo, con il risultato di generare una certa difficoltà di raccordo tra le norme preesistenti e le nuove del GDPR.
Le difficoltà della protezione delle informazioni
Il contesto in cui queste novità si inseriscono è caratterizzato da due fattori incontrovertibili: la rapidità e l’invadenza delle recenti evoluzioni nel settore e la sempre maggiore facilità e velocità di trasferimento e distribuzione delle informazioni, anche in forma complessa e in quantità rilevanti, per il tramite di reti interne, private o pubbliche come Internet e il Web.
D’altra parte, l’accumulo e la concentrazione di un grande volume di informazioni nella disponibilità di soggetti che li raccolgono amplificano i rischi di accesso alle stesse da parte di chi non è autorizzato a disporne e perciò impone l’adozione di opportuni sistemi di protezione talvolta estremamente complessi e costosi.
Non va dimenticato che le reti informatiche sono per la loro stessa natura concepite allo scopo di condividere informazioni tra tutti i soggetti aventi accesso alla rete e che la esclusione dell’accesso da parte di taluni soltanto tra di essi comporta la creazione di sovrastrutture estremamente sofisticate e complesse, atteso che lo scopo è quello di evitare intrusioni dirette ad accedere ai dati che si vuole proteggere ma che sono e devono comunque essere presenti all’interno della stessa rete a disposizione degli utenti autorizzati a disporne.
La protezione della riservatezza dei dati messi in rete costituisce quindi da parecchio tempo una delle aree più delicate della legislazione nei singoli paesi e delle normative comunitarie europee, dalle quali però si può rilevare un recentissimo importante cambiamento di rotta, che corrisponde alla acquisita consapevolezza della impossibilità di adeguare le regole a tempo con gli sviluppi tecnici sempre più innovativi e pressanti.
L’entrata in vigore anche in Italia lo scorso 25 maggio 2018 del Regolamento (UE) 2016/679, noto come GDPR (ovvero General Data Protection Regulation), a due anni dalla sua approvazione da parte del Parlamento e del Consiglio Europeo, non ha avuto grande eco tra gli operatori, forse a motivo dei diversi temi politici in evidenza a quell’epoca nonché nella errata convinzione che solo con l’adozione della legislazione applicativa interna tramite decreto del governo gli effetti reali si sarebbero fatti sentire nel nostro paese.
Neppure la successiva emanazione del decreto di recepimento della nuova disciplina il 10 agosto scorso, pubblicato in Gazzetta Ufficiale il 4 settembre e quindi entrato in vigore 15 giorni dopo, il 19 settembre 2018, ha provocato grandi reazioni, se non tra gli addetti ai lavori, e questo anche perché un termine di grazia di otto mesi è stato esplicitamente previsto nel decreto stesso, nel corso del quale la applicazione delle sanzioni da parte del Garante dovrebbe “tenere in conto” la fase di prima applicazione delle nuove norme, in altre parole tenere la mano leggera in tema di sanzioni.
Sta di fatto però che sotto il regime del nuovo GDPR si è addossata ai singoli operatori, in qualità di titolari del trattamento ovvero in persona del Responsabile del trattamento, la piena responsabilità in merito al giudizio di adeguatezza delle misure di sicurezza adottate in concreto, avuto riguardo al tipo ed al livello di rischio che soltanto il particolare operatore è in grado di valutare e decidere.
Ciò non di meno, e nonostante le rilevantissime novità contenute nel soprammenzionato GDPR sia in tema di adempimenti che di regime sanzionatorio (hanno una portata senza precedenti e possono raggiungere nel massimo fino a 20 milioni di euro o fino al 4% del fatturato annuale di un’azienda), si è preferito non abrogare e sostituire completamente il previgente Codice della Privacy del 2013 ma piuttosto modificarlo, adeguarlo e in parte eliminarlo, con risultati non certo affidabilissimi sotto l’aspetto interpretativo.
Lo stesso Garante della protezione dei dati personali, nel pubblicare il testo coordinato del Codice della Privacy come risultante dopo le modifiche di adeguamento al GDPR europeo ha ritenuto di dover avvertire espressamente che “il presente testo coordinato è reso disponibile al solo scopo informativo e non ha valore ufficiale”, evidentemente a motivo delle numerose possibili contraddizioni e incongruenze riscontrabili.
La difficoltà di raccordo tra le norme preesistenti e le nuove contenute nel GDPR discende fondamentalmente appunto dalla differenza di impostazione generale cui si è fatto cenno sopra del criterio in base al quale viene riconosciuta la responsabilità, e quindi la applicazione delle eventuali sanzioni, in capo al soggetto che è in possesso di dati personali di terzi, e dei quali faccia uso in qualsiasi modo: archiviazione, organizzazione, elaborazione, gestione in genere.
Viene quindi lasciata all’operatore in possesso dei dati la valutazione dell’adeguatezza delle misure adottate in considerazione delle particolari condizioni in cui opera e delle modalità operative da lui scelte, e delle quali dovrà eventualmente dare conto nel caso un evento dannoso si verifichi.
Tale principio, denominato di ‘accountability’, con termine anglosassone non facilmente traducibile, ma reso dal legislatore italiano con la parola ‘responsabilizzazione’, riferita al titolare e al responsabile del trattamento (quest’ultimo divenuto non a caso di nomina obbligatoria e non più facoltativa come sotto la precedente disciplina) viene espresso chiaramente all’articolo 24 del Regolamento europeo in questi termini:
“Tenuto conto della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, nonché dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche, il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire, ed essere in grado di dimostrare, che il trattamento è effettuato conformemente al presente regolamento. Dette misure sono riesaminate e aggiornate qualora necessario.”
Viene quindi precisato nello stesso articolo che la eventuale adozione di codici di condotta ovvero di meccanismi di certificazione anche se debitamente riconosciuti e approvati non vale di per se ad escludere la responsabilità ma soltanto come uno degli elementi da valutare ai fini di escluderla.
E ancora, al successivo articolo 32 si dispone:
“Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio … “
e si aggiunge quindi una precisazione analoga a quanto esposto sopra riguardo a codici di condotta ovvero di meccanismi di certificazione eventualmente adottati.
Le obbligazioni imposte vengono quindi a sostituire i requisiti più spiccatamente formali previsti in precedenza, aggiungendo una responsabilità più estesa derivante dalle necessità valutate caso per caso e una giustificabilità delle scelte di sicurezza effettuate.
A completamento di quanto sopra, sono state introdotte altre prescrizioni assolute in ogni caso, quali l’obbligo di raccogliere e mantenere i dati in formato crittografato oltre ad ottenere il consenso ai trattamenti singolarmente per ciascuno di essi, con indicazione precisa delle finalità di raccolta e conservazione e con indicazione del Responsabile del trattamento.
Vengono prescritte inoltre modalità più esplicite quanto alla acquisizione dei consensi, escludendo accettazioni implicite o automatiche, e viene imposta l’archiviazione dei dati relativi con possibilità di accesso a tali dati da parte degli interessati.
Va infine sottolineato che la obbligatorietà del registro dei trattamenti previsto per le aziende con più di 250 dipendenti non esaurisce certamente le obbligazioni di responsabilizzazione per tale categoria di aziende, ma neppure esime le aziende più piccole, pur non tenute alla tenuta di tale Registro (a meno che non operino trattando dati c.d. cosiddetti sensibili), ad adeguare le misure di protezione in atto ai parametri di cui al nuovo GDPR.
Lo stesso Garante della Privacy propone un modello di registro semplificato ad uso PMI decisamente elementare e non molto complicato o impegnativo quanto alla regolare tenuta.
Sotto questo profilo è stato rilevato da parte della ICO, l’autorità che presiede alla protezione dei dati nel Regno Unito, che la tenuta di tale Registro, se ritenuta opportuna ed anche se non obbligatoria, può costituire in ogni caso un concreto sussidio per qualsiasi operatore nel campo di attività della gestione di dati al fine della valutazione della correttezza dei trattamenti effettuati in azienda e ciò in vista della dimostrazione della adeguatezza delle misure di protezione a norma del GDPR.

Articolo pubblicato su:

www.agendadigitale.eu/sicurezza/gdpr-la-difficolta-di-raccordo-tra-vecchie-e-nuove-norme

Software, le forme di cessione dei diritti: rischi e tutele contrattuali

By | News | No Comments

Tranne che nei casi in cui le soluzioni software vengano utilizzate da parte dello stesso soggetto che le ha sviluppate, la maggioranza delle modalità digitali per la soluzione di problemi operativi vengono in qualche modo messe a disposizione di altri soggetti che le sfruttano al fine del raggiungimento di determinati risultati specificamente voluti. Bisogna quindi essere ben consapevoli degli strumenti contrattuali utili alla tutela dei diritti e dei rischi connessi.
I soggetti utilizzatori instaurano quindi un necessario rapporto con lo sviluppatore, sia esso una persona fisica o una organizzazione imprenditoriale, avente carattere di esclusività fin dall’origine oppure di semplice facoltà condivisa con altri soggetti, anche se per usi diversi per ognuno di essi.
Nel primo caso l’intero diritto di proprietà della soluzione elaborata viene ceduto senza riserve, in maniera simile a quanto avviene per tutte le forme di vendita di un bene o di altra utilità nella sua interezza.
Nel secondo, invece, la proprietà rimane al cedente, essendo la cessione limitata all’uso del bene o dell’utilità, come avviene nei casi di qualunque locazione, salvo che, trattandosi di modalità operative digitali, la utilizzazione può essere anche contemporanea o congiunta da parte di un numero rilevante di soggetti.
Il legislatore Italiano nel 1992 con il D. Lgs. 29 Dicembre 1992 n. 518, in attuazione della Direttiva n. 91/250/CEE, ha equiparato alle opere dell’ingegno di carattere creativo che appartengono alla letteratura i programmi per elaboratori, ovvero il software, con la conseguenza che le problematiche connesse alla vendita dei software sono, pertanto, quelle relative alla cessione dei diritti di utilizzazione dell’opera di un autore, nei limiti e per gli effetti disciplinati dall’art. 2581 c.c., nonché dalla Legge 22 Aprile 1941 n. 633 sul diritto di autore come più volte modificata.
Ne consegue altresì che nella trattazione della cessione delle facoltà di utilizzazione delle modalità digitali innovative ed in genere di tutti i contratti di fornitura ad esse relative non può quindi prescindersi dall’analisi del contenuto di tali particolari opere dell’ingegno, perché attraverso tale analisi sarà più semplice comprendere il contenuto degli accordi che si vogliono stipulare nonché valutare i rapporti di forza tra le parti.
Trattandosi di cessioni aventi ad oggetto utilità o beni non materiali (salvo il supporto fisico eventuale, di valore solitamente trascurabile) non viene richiesta per legge alcuna formalità particolare, quindi un accordo verbale sarebbe sufficiente salvo la ovvia opportunità della conclusione di un contratto scritto.
Un caso particolare di acquisizione della proprietà è riferito a quanto elaborato da parte di un dipendente su incarico del proprio datore di lavoro, perché in tale ipotesi la proprietà di quest’ultimo è automatica per legge, a meno che ciò non sia stato espressamente escluso, senza necessità di una cessione formale (vedasi articolo 12 bis, introdotto nel 2017, della legge sul diritto d’autore).
E’ doveroso far notare che il termine “dipendente” va inteso in senso specifico e che pertanto quanto elaborato a seguito di incarico o commissione ma senza vincolo di subordinazione resta in proprietà del soggetto che lo ha elaborato, con libertà assoluta delle parti di attribuirne i diritti di proprietà e di sfruttamento nei modi e nei termini che credono, senza alcuna presunzione.
In ogni caso, ove la proprietà venga ceduta per intero, l’autore si spoglierà di ogni suo diritto, normalmente contro pagamento di un adeguato corrispettivo, restando così escluso da ogni successiva possibilità di controllo o di gestione della soluzione da lui elaborata.
L’unico diritto non cedibile, ma puramente morale e privo di valore economico, resta quello della paternità su quanto elaborato, in forza dell’articolo 20 della legge sopra citata, ossia il diritto ad esserne considerato e riconosciuto autore, oltre che, teoricamente, ad opporsi a deformazioni, mutilazioni o modifiche, anche se questo ultimo aspetto difficilmente potrebbe assumere rilevanza nel settore informatico, per ovvie ragioni di evoluzione e continuo adattamento.
Le cessioni limitate alla utilizzazione soltanto costituiscono la maggioranza dei casi, e la varietà delle possibili modalità è praticamente infinita oltre che liberamente negoziabile tra le parti.
Normalmente, le modalità digitali sviluppate ed elaborate da un soggetto vengono concesse in licenza d’uso a favore di altri soggetti che, appunto, le utilizzano, ed i limiti a tale uso possono essere temporali, spaziali, di ambito operativo, talvolta anche di piattaforma di sistema (si veda il caso Apple che non consente l’utilizzo dei propri sistemi operativi su macchine che non siano di propria fabbricazione).
In altri casi la licenza d’uso è implicita nell’acquisto della macchina, in quanto il fabbricante della stessa si è assicurato una licenza dallo sviluppatore con facoltà di cedere detta licenza agli acquirenti delle macchine vendute con il proprio marchio, con acquisizione automatica della licenza all’atto dell’acquisto, spesso senza neppure saperlo (cosiddette licenze OEM).
Si è detto che in questo ambito viene lasciata alle parti la più ampia libertà, e questa viene spesso abusata da parte degli sviluppatori ogniqualvolta la loro posizione predominante lo permetta, entro i limiti dettati in materia di clausole vessatorie.
Una delle poche facoltà che non possono in nessun caso essere negate all’utilizzatore-licenziatario sono la riproduzione di una copia di sicurezza per il caso di perdita o distruzione del supporto originariamente fornito, oltre alla “decompilazione” (spesso riferita come “reverse engineering”) al fine di risalire al codice sorgente dell’elaborato oggetto di licenza.
Tale ultima attività, normalmente vietata in quanto comportante accesso al codice sorgente e quindi al vero cuore dell’elaborato, è consentita soltanto per ottenere la interoperatività della soluzione informatica con altri strumenti software utilizzati dal licenziatario, il che tuttavia si verifica di solito soltanto nel caso che quest’ultimo abbia ampie risorse e necessità al riguardo, il che non si verifica con i normali utilizzatori finali. L’aspetto è comunque molto rilevante e le opportune cautele dovranno essere predisposte contrattualmente per disciplinarlo.
Esistono circostanze nelle quali il codice sorgente viene rivelato all’utilizzatore, o del tutto gratuitamente e senza vincoli di alcun genere (licenze di pubblico dominio) oppure con facoltà limitate e ben definite quanto alla modificabilità, integrazione in altre soluzioni di diversa provenienza, usi specifici e altro (licenza open source) nel qual caso si rientra nell’ambito della normale licenza, gratuita o a pagamento che sia.
Un ulteriore aspetto da non trascurare è la eventuale inclusione, nella soluzione elaborata e destinata alla cessione, di parti accessorie elaborate da terzi. Il classico esempio è costituito da librerie di dati, routines di conversione o di datazione o di localizzazione geografica.
Se le stesse sono di dominio pubblico ovvero di libero utilizzo generale il problema naturalmente non si pone, ma se la gratuità è prevista soltanto per utilizzi non commerciali oppure sussistono limitazioni o addirittura divieti, la cessione del pacchetto che li contiene può avere conseguenze estremamente negative.
Il recente caso del sistema di rilevazione delle velocità medie che ha coinvolto le autostrade italiane ne è un esempio (anche se nel caso esistevano aspetti di tutela brevettuale, di solito non presenti nel settore dell’informatica). A prescindere dalle circostanze materiali fisiche, il sistema di rilevazione ed elaborazione dei dati era stato considerato sia da parte degli utilizzatori che da parte di chi aveva loro concesso in licenza il sistema, come perfettamente legittimo, essendo per la maggior parte originale e specifico per l’uso particolare.
Ma la contestazione da parte di chi il sistema lo aveva elaborato per primo ha avuto come conseguenza il divieto di utilizzarlo per intero, con notevoli danni conseguenti, anche se la parte riconosciuta come protetta e non usabile costituiva una porzione quasi marginale dell’intero sistema.
Sono infine da menzionare le ipotesi in cui la soluzione informatica venga elaborata su istruzioni specifiche dell’utilizzatore, per cui, salvo non venga riservato al cedente il diritto di commercializzare in proprio e verso terzi la soluzione da lui sviluppata, ipotesi piuttosto rara, il committente del lavoro diviene proprietario del lavoro in via esclusiva.
A prescindere dalla qualificazione del rapporto (a grandi linee: appalto se lo sviluppatore è un’impresa o contratto d’opera se è un professionista) cambiano in tale caso le rispettive responsabilità, garanzie e diritti, ragione per cui la disciplina contrattuale adatta alla specificità della soluzione ceduta assume una importanza determinante.
E’ da notare che, mentre tali ipotesi di soluzioni personalizzate erano più comuni in tempi passati, sono oggi divenute più rare a causa della miriade di soluzioni informatiche disponibili sul mercato studiate e mirate a venire incontro alle esigenze più disparate.
Ma restano ancora piuttosto diffusi gli adattamenti di soluzioni commerciali comuni, che il cliente utilizzatore, specie se di dimensioni medio-grandi, come banche, società di assicurazione o industrie, vuole in qualche modo personalizzare per meglio adeguarlo alle proprie necessità o per facilitarne l’uso da parte dei dipendenti.
In tali casi, lo sviluppatore cedente dovrà assicurarsi la concessione della relativa licenza da parte dell’avente diritto, con facoltà di modifica e adattamento, ovvero l’acquisto di tale licenza da parte del cliente utilizzatore finale.
Si può osservare insomma che in generale il migliore sfruttamento commerciale delle soluzioni informatiche innovative non può prescindere da una adeguata tutela all’atto della sua cessione a terzi, tutela che può essere assicurata solo con una accurata scelta e formulazione dello strumento contrattuale più adatto, anche al fine di evitare esposizione a rischi operativi derivanti dall’utilizzo da parte del cessionario.

Articolo pubblicato su:
https://www.agendadigitale.eu/sicurezza/software-le-forme-di-cessione-dei-diritti-rischi-e-tutele-contrattuali/

Licenze software, le responsabilità in caso di danni: che dicono le norme

By | News | No Comments

Chi concede in licenza un bene immateriale, come sono tutti i prodotti informatici, ad eccezione del supporto sul quale sono distribuiti (anche se ciò tende a ridursi con il potenziamento dei collegamenti Internet che consentono la distribuzione on-line), è pienamente responsabile per le conseguenze negative che ne dovessero derivare. Concetto importante e spesso poco conosciuto, perché una lettura non troppo attenta di uno qualsiasi dei numerosi contratti di licenza d’uso per sistemi informatici o delle licenze software potrebbe indurre a credere che gli sviluppatori e i venditori di materiale del genere possano tranquillamente evitare preoccupazioni in merito agli eventuali danni derivanti dall’utilizzo dello stesso.
Il contenuto di tali contratti viene infatti strutturato, talvolta in maniera piuttosto ingenua, in modo tale da isolare completamente il venditore dall’utilizzatore: sembrerebbe quasi che, addirittura, la cessione a pagamento di una licenza d’uso non lasci poi a chi la usa nessuna possibilità di rivalsa, neppure se il prodotto fosse così scadente da non essere usabile.
Ma le cose, come detto, non stanno così. Vediamo perché e che c’è da sapere.
Va anzitutto notato che a norma della legge italiana tutte le clausole limitative di responsabilità o di divieto a sollevare eccezioni che siano state predisposte da uno dei soggetti, normalmente il venditore, oppure siano contenute in un testo prestabilito al quale l’altro soggetto possa soltanto aderire, non hanno effetto se non sono state approvate specificamente, separatamente dal contesto, e per iscritto.
I contratti conclusi con il classico clic di accettazione via internet ovvero tramite rottura del sigillo di una confezione del prodotto (cosiddetta licenza a strappo o shrink wrap) non comportano quindi limitazioni effettive di responsabilità anche se previste.
Ma se le norme sopra accennate valgono soprattutto in caso di distribuzione a privati, la cui protezione deriva altresì dalle disposizioni del Codice del Consumo e delle normative comunitarie in materia, anche le transazioni tra aziende sono soggette a normative piuttosto stringenti al fine della tutela dei contraenti.
Va osservato anzitutto che la clausola di divieto di cessione a terzi della licenza d’uso, spesso prevista, è stata messa in discussione in quanto in contrasto con la legislazione in tema di diritto d’autore, al quale le soluzioni software sono soggette, salvo casi particolari, e precisamente con il cosiddetto “principio di esaurimento” in materia, in base al quale la prima vendita di un bene in ambito comunitario esaurisce il diritto di distribuzione limitatamente alla copia, materiale o non, a suo tempo ceduta in uso e pertanto rivendibile (cfr. caso Oracle deciso nel 2009).
Ammessa la cedibilità, questa comporterebbe obblighi di garanzia a carico dello sviluppatore nei confronti del nuovo licenziatario, con effetti di prolungamento cui le principali software house hanno cercato di rimediare mediante licenze a tempo determinato oppure soluzioni software utilizzabili soltanto on-line su abbonamenti a tempo.
Altro principio rilevante è il divieto previsto dall’articolo 1229 del codice civile italiano circa la limitazione o la esclusione in sede contrattuale delle responsabilità nascenti da colpa grave, dalle quali pertanto lo sviluppatore non può esimersi in alcun modo.
Neppure da sottovalutare è l’interpretazione del contratto in caso di controversie e per il caso che il contratto come stipulato tra le parti non preveda soluzioni specifiche o quelle previste non siano utilizzabili.
Stante l’impostazione di figure contrattuali tipiche contenute nel codice civile italiano, l’interpretazione dei contratti di cessione di diritti su materiale informatico, atipici nella stragrande maggioranza dei casi, viene condotta in caso di dispute mediante riferimento a contratti tipici affini o equivalenti.
Il contratto di licenza d’uso, normale per le soluzioni informatiche, viene quindi parametrato, a seconda del suo prevalente scopo, come risultante dal suo effettivo contenuto, ai contratti, per esempio, tipici di locazione o vendita di bene immateriale oppure di appalto d’opera quando il sistema software sia stato sviluppato su specifiche disposizioni e per necessità indicate dall’utilizzatore.
Così, per esempio, se dovesse essere ritenuta prevalente la natura di locazione in un contratto di licenza, la responsabilità per i vizi eventuali non potrebbe comunque essere esclusa se gli stessi sono stati taciuti in malafede o rendano impossibile l’uso del bene oggetto di cessione in uso (cfr. articolo 1579 c.c.).
Mentre, se prevalente fosse riscontrata la natura di vendita, la sola malafede del cedente sarebbe sufficiente, a prescindere dalla possibilità di utilizzo (cfr. articolo 1490 comma 2 c.c.).
Oppure, con riferimento all’appalto, solo se i difetti riscontrati rendessero il software sviluppato inadatto all’uso dichiarato l’utilizzatore/committente avrebbe facoltà di risolvere il contratto con restituzione di quanto pagato, in ogni altro caso gli sarebbe solo consentito chiedere la eliminazione dei difetti o la riduzione del prezzo proporzionale al minore utilizzo (cfr. articoli 1668 e 2226 c.c.).
Possono anche incontrarsi casi non univoci, come quando, ciò che avviene di frequente, lo sviluppatore utilizzi programmi o parti di programmi esistenti (librerie, banche dati o altro) e di proprietà di terzi poi adeguatamente modificati o completati allo scopo di adattarli alle esigenze dell’utilizzatore.
In questi casi, a parte la necessità dello sviluppatore di garantire per sé o per l’utilizzatore il legittimo uso del materiale altrui, il contratto finale potrà essere qualificato come assimilabile alla vendita o all’appalto, con applicazione delle discipline di diritto relative, valutandone i contenuti da un punto di vista qualitativo e quantitativo.
La ripartizione delle responsabilità fino a questo punto considerata, come afferente il rapporto tra sviluppatore e utilizzatore dal punto di vista interno, si riflette necessariamente nella loro posizione riguardo a soggetti estranei a tale rapporto che siano coinvolti a qualsiasi titolo nella utilizzazione della soluzione informatica fornita.
Sotto questo aspetto vanno considerate prima di tutto le rivalse da parte dei soggetti acquirenti dei beni o dei servizi forniti dall’utilizzatore ed ottenuti tramite la soluzione informatica oggetto di contratto, per la quali lo sviluppatore potrà essere chiamato a rispondere.
Ma inoltre anche i danni a soggetti non legati a nessuna delle parti da legami contrattuali, considerato che sempre più di frequente vengono utilizzate connessioni a servizi di rete pubblici o privati, servizi che possono subire pregiudizio anche all’insaputa dell’utente, il quale non ha normalmente a disposizioni adeguate conoscenze o strumenti per evitarle.
Oltre ai numerosi casi di contraffazione e distribuzione di programmi noti e diffusi allo scopo di effettuare operazioni ignote all’utente inconsapevole, può verificarsi che l’errata progettazione del programma non sia sufficiente ad impedire accessi non voluti all’insaputa dell’utilizzatore.
Questo può avvenire quando il programma sia basato sulla acquisizione di parametri o di dati da fonti esterne in rete; in questo caso è evidente la responsabilità dello sviluppatore per i danni da disservizio o blocco dei server utilizzati, sempre che sia comprovata la mancata adozione degli accorgimenti adeguati ad evitare il malfunzionamento non voluto del programma.
Tale ultimo aspetto porta a considerazioni finali in tema di esigenze probatorie in caso di controversie riguardo il funzionamento di soluzioni informatiche.
In generale l’onere della prova del danno subito incombe sul danneggiato, ma spesso tale prova si limita alla esistenza del danno ed al nesso tra il danno e la soluzione software utilizzata, senza possibilità di accertare la causa effettiva perché i rimedi adottati con urgenza per limitare o impedire gli effetti dannosi hanno modificato di fatto la originale configurazione.
A questo, oltre che alla frequente inesistenza di indagini a priori sulla architettura generale del sistema al momento della installazione, va aggiunta la scarsa o limitata dimestichezza con settori informatici specifici da parte dei periti nominati in sede giudiziaria.
La redazione dei contratti di cessione, licenza e sviluppo su commissione di strumenti e soluzioni informatiche resta comunque un tema in divenire, in corrispondenza della espansione ed evoluzione continua dell’informatica e delle sue applicazioni, al quale le imprese dovrebbero dedicare la massima attenzione in vista delle potenziali esposizioni economiche.

Articolo pubblicato su:
www.cybersecurity360.it/legal/licenze-software-le-responsabilita-in-caso-di-danni-che-dicono-le-norme