All posts by Studio Legale DG

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à?”.

Contratti Bancari

By | Pillole di... | No Comments

Cass. Civ. Sez. I  Ord. 28 Novembre 2018 n. 30822

In tema di contratti bancari, il correntista che agisca in giudizio per la ripetizione dell’indebito, è tenuto a fornire la prova sia degli avvenuti pagamenti che della mancanza, rispetto ad essi, di una valida “causa debendi”, per cui il medesimo ha l’onere di documentare l’andamento del rapporto con la produzione di tutti quegli estratti conto, relativi all’intero periodo del rapporto, che evidenziano le singole rimesse suscettibili di ripetizioni in quanto riferite a somme non dovute.
Con questa sentenza la Corte di Cassazione affronta la distribuzione dell’onere della prova nelle controversie tra banca e correntista, soffermandosi sull’utilizzo del criterio c.d. saldo zero.

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

SOCIETÀ

By | Pillole di... | No Comments

SOCIETÀ – Di capitali – Società per azioni (nozione, caratteri, distinzioni) – Costituzione – Modi di formazione del capitale – Limite legale – Delle azioni – In genere accordo tra soci uno dei quali si obblighi a manlevare l’altro delle eventuali conseguenze negative del conferimento effettuato in società mediante l’attribuzione di un diritto di vendita c.d. put della partecipazione sociale a prezzo predeterminato – Liceità e meritevolezza degli interessi – Sussistenza.

Cass.  Civ. Sez. I Ord. 4 Luglio 2018, n. 17498

E’ lecito e meritevole di tutela l’accordo negoziale concluso tra i soci di una società azionaria, con il quale l’uno, in occasione del finanziamento partecipativo così operato, si obblighi a manlevare l’altro dalle eventuali conseguenze negative del conferimento effettuato in società, mediante l’attribuzione del diritto di vendita (c.d. “put”) entro un termine dato ed il corrispondente obbligo di acquisto della partecipazione sociale a prezzo predeterminato, pari a quello dell’acquisto, pur con l’aggiunta di interessi sull’importo dovuto e del rimborso dei versamenti operati nelle more in favore della società.

Compensatio lucri cum danno

By | Pillole di... | No Comments

Sulla questione se dall’ammontare dei danni risarcibili dal danneggiante debba essere detratta l’indennità assicurativa derivante dall’assicurazione contro i danni che il danneggiato abbia percepito in conseguenza del fatto illecito, si confrontano due orientamenti.
Le Sezioni Unite della Suprema Corte di Cassazione – 22 maggio 2018 n. 12565 – confermano il divieto di cumulo di indennizzo assicurativo e risarcimento del danno  affermando che il danno da fatto illecito deve essere liquidato sottraendo dall’ammontare del danno risarcibile l’importo dell’indennità assicurativa derivante da assicurazione contro i danni che il danneggiato-assicurato abbia riscosso in conseguenza di quel fatto.

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/

Trasporto – perdita della merce – mittente – azione risarcitoria – onere probatorio.

By | Pillole di... | No Comments

La Suprema Corte di Cassazione (cfr. sezione IV civile – ordinanza 12 gennaio 2018 n. 702) ha affermato, e non constano precedenti negli esatti termini, che qualora il mittente agisca nei confronti del vettore per il risarcimento del danno patito in conseguenza della perdita della merce trasportata, sul primo incombe soltanto l’onere di provare la perdita del carico e il suo valore, ma non anche di aver indennizzato il destinatario della merce per il mancato arrivo della stessa; spetterà invece al vettore dimostrare che il mittente aveva già percepito dal destinatario il prezzo della merce poi andata perduta e che quest’ultimo non gliene ha chiesto la restituzione.

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

Tutele legali delle soluzioni informatiche: Contratto eula, Brevetto, Copyright

By | News | No Comments

La potenziale redditività economica da valutare in vista dello sviluppo di nuove soluzioni informatiche è fortemente influenzata dalle possibilità di sfruttamento di tali soluzioni in esclusiva da parte dello sviluppatore direttamente; ovvero del committente che lo abbia commissionato e ne abbia acquisito i diritti di utilizzo. Ecco una guida sulle misure principali da prendere a questo scopo.
Alle protezioni informatiche interne, quali password, chiavi proprietarie o di recente i controlli via internet da remoto, le tutele più propriamente legali hanno una importanza notevole e la loro attuazione può coinvolgere aspetti diversi tra i quali non è facile districarsi e scegliere.
Le Start-up/PMI partono da un’idea innovativa che, talvolta, ha l’ambizione di rivoluzionare un settore con la forza della creatività, delle competenze tecnologiche e dell’entusiasmo e questo deve far sì che proteggere le soluzioni informatiche innovative mediante strumenti per la tutela della proprietà intellettuale, permette alle Start-up/PMI di alzare delle barriere solide contro i potenziali concorrenti e fornisce il tempo necessario a sviluppare i progetti da un punto di vista commerciale. Senza contare che un’adeguata protezione dell’innovazione renderà la Start-up/PMI più appetibile per chiunque abbia interesse ad investire sul loro business model.
Ad esempio per lo sviluppo di nuove soluzioni software la prima barriera è normalmente costituita dal contratto di licenza comunemente denominato EULA che, essendo predisposto dallo sviluppatore ed accettato dall’utilizzatore per adesione, di solito tramite spunta per accettazione all’atto della installazione, è sottoposto a limitazioni legali nel caso le previsioni in esso contenute siano limitative dei diritti dell’utilizzatore ovvero delle responsabilità dello sviluppatore, in base all’art. 1341 del codice civile italiano in tema di cosiddette clausole vessatorie e del Codice del consumo (d.lgs. 206/2005), in caso l’utilizzatore finale possa essere qualificato come consumatore.
Una attenta formulazione dei termini di licenza risulta quindi molto opportuna in ogni caso.
Le barriere di protezione legale sono costituite dal marchio, dal brevetto e dal copyright (diritto d’autore).
Il marchio, corrispondente al nome commerciale, garantisce una difesa relativa, e soltanto nei casi in cui il nome attribuito alla soluzione informatica ne richiami specificamente la funzione ed acquisti una notorietà sufficiente ad identificare la soluzione stessa.
Normalmente, in caso di denominazioni di fantasia, la protezione è piuttosto debole ed è facile per i potenziali concorrenti violare i diritti dello sviluppatore usando una denominazione commerciale diversa.
La protezione brevettuale è senza dubbio la più forte, ma, nel caso delle soluzioni informatiche, anche la più problematica.
Innanzitutto perché l’attuale legislazione in materia in Europa rende difficile, in linea di principio, la brevettabilità delle soluzioni informatiche, e in secondo luogo a motivo dei costi abbastanza proibitivi, considerata la attuale vita utile media dei prodotti di queste soluzioni informatiche.
Sotto il primo aspetto, l’articolo 52, paragrafo 2, punto c) della Convenzione sulla Concessione dei Brevetti Europei (EPC) in vigore dal 1977 esclude ad esempio la brevettabilità del software, precisando tuttavia al successivo paragrafo 3 che tale esclusione si riferisce al software “in quanto tale”.
E il successivo articolo 53 non elenca in effetti il software tra le invenzioni non brevettabili in assoluto, mentre l’articolo 54 richiede la novità e il 57 la idoneità ad avere applicazione industriale.
Le Linee Guida dell’Ufficio Brevetti Europeo (EPO), pubblicate il 1° giugno 1978 su questo tema e successivamente ampliate e modificate, tendono ad escludere dalla possibilità di protezione ad esempio i software che siano riconducibili a procedimenti matematici o logici anche complessi ma che non comportino una effettivo risultato tecnico-pratico.
La interazione con la macchina su cui il programma funziona può invece costituire oggetto di brevetto se il risultato ottenuto porta un contributo tecnico allo stato dell’arte.
Come si vede, la distinzione è molto sottile e solo un attento esame preliminare può portare a utili indicazioni.
L’aspetto dei costi può essere poi determinante, in quanto l’attuale sistema comporta comunque depositi separati nei diversi stati dell’Unione, con il rischio che il brevetto venga concesso in alcuni paesi e negato in altri, con conseguenti procedure contenziose anch’esse a costi notevoli.
Secondo calcoli della stessa Commissione Europea, i costi della richiesta di protezione brevettuale per i 13 paesi principali dell’Unione Europea corrisponderebbero a circa 130.000 Euro nell’arco di vent’anni.
Un sistema unitario per tutta l’Unione Europea è stato predisposto con la Convenzione di Lussemburgo sul brevetto comunitario (CBC), la quale tuttavia non è ancora entrata in vigore a motivo delle resistenze opposte da alcuni Stati Membri. La attuazione di tale convenzione porterebbe ad una notevole semplificazione, accentrando le procedure e portando una sensibile riduzione dei costi a circa 35.000 euro nell’arco di durata ventennale del brevetto.
La sopra descritta situazione in Europa non si discosta molto in sostanza da quella internazionale, in particolare con quella degli Stati Uniti.
L’orientamento generale restrittivo verso la brevettabilità ad esempio sempre del software trova appunto motivo nella onerosità e costi delle relative procedure, circostanza che favorirebbe le grandi multinazionali a scapito degli sviluppatori indipendenti e in genere delle Start-up/PMI.
L’indirizzo si è orientato fin dall’origine verso la normale tutelabilità delle soluzioni informatiche secondo le norme del diritto di autore, non escludendo tuttavia la brevettabilità in principio, ma solo per casi determinati.
Ed effettivamente la tutela fornita ad esempio dal diritto di autore (copyright) sul codice sorgente costituente la base del software è sicuramente la più immediata e meno costosa, anche se certamente non estesa a tutti gli aspetti vulnerabili.
Secondo la legislazione in vigore in Italia, il semplice deposito nell’apposito Registro presso la SIAE della copia un programma su supporto ottico (CD o DVD), unitamente alla dichiarazione modello 349, e con il pagamento di un diritto fisso e imposte per circa 260 euro, garantisce la data di priorità, i diritti di paternità dell’opera per i dati relativi e per la durata della vita del depositante e per ulteriori 70 anni nell’ambito del territorio italiano.
Il deposito può essere effettuato anche in prevenzione, per opere non ancora pubblicate o utilizzate, per la durata di 5 anni prorogabili per un successivo uguale periodo.
E’ da notare che la tutela accordata alle soluzioni informatiche sotto questo profilo è parificata a quella accordata ad opere letterarie, nel senso che il principale requisito richiesto non si riferisce alla novità o funzionalità, ma invece alla originalità e unicità dell’elaborato.
La protezione, rispetto al brevetto, è quindi da un lato più ristretta, in quanto strettamente collegata alla forma ed alla espressione usata, dall’altro molto più ampia perché riferita al modo personale di espressione dell’autore, alla sua creatività.
Il listato di un programma, ad esempio, viene limitato dal linguaggio tecnico utilizzato, ed è quindi meno libero di quello letterario, ciononostante il modo di esplicitazione è unico, non perché nuovo ma perché originale.
Chiedendo a un certo numero di programmatori la redazione di un codice che porti ad un certo risultato, si otterranno infatti listati sicuramente diversi, ma ognuno di essi sarà originale e unico, e quindi protetto come tale.
D’altro lato, la compilazione del listato mirante a limitare lo sviluppo di software simili dovrà essere formulato in modo tale da comprendere nel complesso le possibili espressioni di istruzioni equivalenti, allo scopo specifico di evitare forme di plagio funzionale da parte di terzi.
Anche tali aspetti sono stati ampiamente elaborati in sede di giurisprudenza e criteri abbastanza univoci risultano stabiliti a fini di riferimento preventivo.
Da notare infine che in caso di cessione dei diritti su opere protetta a norma del diritto d’autore, a seguito di vendita o cessione dei diritti di utilizzazione (licenza) oppure implicitamente in quanto sviluppata su commissione o in qualità di dipendente, il diritto morale di paternità dell’opera spetterà comunque all’autore persona fisica ed ai suoi eredi, come pure il diritto di opporsi a modifiche o alterazioni che siano lesive dell’onore o della reputazione dell’autore.
Ultimo aspetto da considerare è che la tutela del diritto di autore riconosciuta in Italia si estende automaticamente a tutte le nazioni aderenti alla Convenzione di Berna del 1886, più volte modificata e ampliata, e da ultimo a quasi tutte le nazioni mondiali, in forza dell’accordo TRIPS, promosso dalla organizzazione mondiale del commercio (WTO) e facente riferimento alla stessa Convenzione di Berna.

Articolo pubblicato su:
www.agendadigitale.eu/mercati-digitali/tutele-legali-delle-soluzioni-informatiche-contratto-eula-brevetto-copyright-le-norme-da-sapere