Issuu on Google+

Profili giuridici e tecnologici delle Cloud Application

Dott. Gabriele Riccò


1 Aspetti Giuridici del modello Cloud. Premessa

Aspetti giuridici nelle Cloud Application sono sicuramente molteplici e possono riferirsi a discipline del diritto e del diritto dell’informatica quali privacy, riservatezza, segreti industriali. Esistono numerosi elaborati che prendono in considerazione tali aspetti. Ciò che invece, chi vi scrive, ha l’ambizione di analizzare, é il sistema di garanzie e di regole che è alla base della fruizione di tale tecnologia. Mi riferisco alle clausole di adesione ai servizi cloud, i cosiddetti “Cloud Service Agreements (CSA)” che tipicamente il fornitore di servizi Cloud, sottopone all’accettazione dell’utente e che questi deve accettare per fruire del servizio. Tale sistema costituisce l’ultima barriera per la fruizione dei sevizi stessi. Una sorta di prendere o lasciare dell’era tecnologica. Ultimo ostacolo imprescindibile di difesa e unico strumento di tutela telematica, che il fornitore di servizi Cloud si trova a dover interporre tra i propri servizi e il fruitore finale degli stessi. Nonché strumento di possibile dissuasione delle intenzioni del potenziale cliente.


1.2 Aspetti Giuridici: I Cloud Service Agreements (CSA). Possiamo definire i Cloud Service Agreements come un accordo contrattuale, tra un'organizzazione fornitrice di servizi cloud e un fruitore degli stessi servizi (privato o organizzazione). E’ forse il componente più critico nella valutazione del servizio di cloud computing e quindi deve essere esaminato attentamente prima di decidere di instaurare un rapporto con il fornitore di servizi Cloud. I Cloud Service Agreements (CSA) devono descrivere chiaramente i servizi forniti, ma soprattutto le garanzie (ed eventuali limitazioni di garanzia) stabilendo quindi “de residuo”, le responsabilità e i diritti di ciascun interlocutore. La corretta redazione di tali accordi, deve ispirarsi naturalmente al principio di “bona fides” e correttezza. Richiede un’approfondita indagine delle componenti di maggiore delicatezza sotto il profilo giuridico. A partire naturalmente dalle garanzie fornite a riguardo delle informazioni trasmesse e memorizzate. In primo luogo, occorre stabilire, fino a che livello, attraverso le clausole CSA, il fornitore di Cloud si obbliga a proteggere le informazioni cedutegli dal proprio cliente.


In linea generale, a parere di chi scrive, dovrebbero essere adottate, almeno le stesse garanzie che il fornitore adotta all’interno della propria organizzazione per la salvaguardia dei dati, cosiddetta “condizione di reciprocità nella garanzia delle informazioni Cloud”. “Tutto ciò che vale per noi internamente, deve valere anche per il mio cliente”, potrebbe essere il criterio ispiratore del fornitore di Cloud. Questo approccio può consentire non solo un valido metodo tecnico, ma anche una buona strategia commerciale e una valida difesa in eventuale sede giurisdizionale. In questo contesto devono essere allargate tutte le garanzie previste nell’ambiente “Lan”, a tutti coloro che fisicamente hanno accesso ai dati in ottica di accesso su infrastruttura Cloud. Seguendo il medesimo concetto, quindi, dove risiederanno fisicamente le informazioni, saranno estese le strategie in caso di accessi non autorizzati. Se la condizione di reciprocità è rispettata, anche per ciò che riguarda la gestione degli accessi da chiunque effettuati, nonché la cancellazione di dati, le copie illecite o la rimozione di dati effettuati da parte del fornitore o dai dipendenti della società stessa, potranno avere una risposta adeguata, in quanto le medesime policy sono stabilite per la gestione delle informazioni all’interno della rete locale.


Sempre a proposito di garanzie, và considerato che la maggior parte di fornitori o provider di servizi Cloud, offrono i loro servizi attraverso server condivisi. Particolare attenzione quindi, va tenuta affinché le informazioni di una azienda non vadano inavvertitamente “mescolate” con quelle di altre. In questo senso la clausola CSA deve essere non solo presente, ma molto chiara e inequivocabilmente garantista, nei confronti del cliente. Vanno quindi ancor più affinati, da parte del fornitore di servizi Cloud, i piani di verifica della separazione dei dati e i corretti privilegi di accesso, nonché una strategia di controllo periodico degli stessi. La previsione di una specifica CSA è da riservare ad un aspetto di natura prettamente giuridica, e cioè nel caso di sequestro o perquisizione o di atti giudiziari simili, ad opera dell’autorità giudiziaria. Qualsiasi strategia venga implementata occorre che questa non prescinda dall’ottica di un servizio cloud e quindi ipoteticamente distribuito, anche in differenti giurisdizioni. Il CSA dovrà includere una specifica previsione per mantenere la riservatezza rispetto ai segreti industriali e commerciali dell’azienda che fruisce del servizio. Sarà quindi espressamente contemplata la previsione che l’informazione non perderà mai il suo “status” di informazione riservata in qualunque punto dell’architettura Cloud essa


venga distribuita e in qualsiasi processo essa venga coinvolta o utilizzata. La memorizzazione di segreti industriali e commerciali comporta un ulteriore rischio dal punto di vista giurisdizionale. In particolare quando la legge riguardante i segreti stessi, sia memorizzata in una giurisdizione meno protettiva della giurisdizione dove l’utente si trova fisicamente. Ad aggravare tale rischio vi è il fatto che l’identificazione dell’ubicazione della rete Cloud non è sempre facilmente verificabile perché multi segmentata e soggetta a modifiche. Allo stesso modo i CSA dovrebbero prevedere il concetto non solo di “comunicazione segreta”, ma anche di “comunicazione riservata”. Pensiamo in generale una comunicazione tra avvocato e assistito, questo rapporto sarebbe certamente compromesso se condiviso da terze parti. Anche i comportamenti sulle politiche di backup sono rilevanti al fine della presente analisi. Il salvataggio e lo stoccaggio di informazioni è sicuramente da contemplare nella redazione dei CSA. In particolare occorre porre attenzione a diverse casistiche che possono verificarsi in tale prospettiva. Partendo dal backup effettuato come copia di sicurezza da utilizzarsi nel caso di dati persi o compromessi, al backup


necessario in caso di sostituzione dell’hardware o del servizio, al backup effettuato anch’esso in outsourcing tramite tecnologia Cloud. Nondimeno l’aspetto legato alle interruzione del servizio riveste un’argomentazione importante all’interno della presente analisi. Per coloro che utilizzano un’infrastruttura Cloud si presenta di fondamentale importanza l’aspetto della continuità del servizio che si può bene riassumere nel concetto di “perpetuità del servizio”, ossia assenza pressoché totale di interruzioni. L’interruzione comporta a livello aziendale un’immediata perdita di operatività, perdita di opportunità e di conseguenza mancate opportunità di guadagno. E’ quindi opportuno che i fornitori di servizi Cloud, contemplino all’interno dei CSA le garanzie necessarie che diano risposte a tali evenienze più o meno fisiologiche dell’architettura informatica intesa nella sua generalità. Il fornitore dovrà quindi almeno prevedere la possibilità di accesso ad altri collegamenti paralleli ed avere sperimentato un’interruzione di servizio e pianificato la strategia di uscita. Al fine di garantire adeguatamente la continuità dei servizi và prevista e garantita la trasferibilità a provider alternativo. Da tutto ciò occorre tenere conto dei casi di forza maggiore (guerre, attentati, interruzione di energia elettrica, ecc) anche se, a parere di chi


scrive, dovrebbe essere prevista la possibilità di recupero anche in tali scenari con corrette politiche di “Disaster recovery”. In ultima analisi anche le policy che definirei di “fine rapporto” dovranno stabilire chiaramente, se e per quanto tempo, le informazioni rimarranno presenti sui supporti del fornitore di tecnologia Cloud Clausole di esclusione nei punti sopra trattati dovrebbero essere valutate con estrema curo, soprattutto dalle utenze aziendali, visto che riguardano aspetti fondamentali del rapporto fra utente e fornitore di servizi Cloud affidabile. Il recente caso Wikileaks ha aggiunto ulteriori elementi di discussione a tale proposito. In primis quando il fornitore di servizi Cloud decide di interrompere il servizio, per violazione delle CSA da esso stabilite ed accettate dal fruitore. In quest’ottica, a parere di chi scrive, esplode macroscopicamente la necessità di una regolamentazione che vada al di là dell’insieme di regole e garanzie stabilite da ciascun fornitore, ciò che è necessario è un quadro normativo internazionale di disciplina comune. Forse una sfida che il diritto (internazionale ?) potrebbe cogliere per iniziare realmente un percorso giuridico condiviso a livello sovrannazionale.


2 Aspetti Tecnologici

2.1 Modello Property Software (pag 13). 2.2 Modello Free Software (pag. 20).

2.3 Modello Web Application (Cloud). Il terzo modello che si è imposto, di fatto, fra i modelli di produzione e distribuzione del software è senza ombra di dubbio il modello delle Web Application e della tecnologia Cloud (letteralmente On the Cloud, “fra le nuvole”). Tale modello rappresenta l’essenza dell’assenza di barriere fisiche e tecnologiche per lo sfruttamento e l’utilizzo del software. Tutto è indipendente dalla piattaforma di sviluppo, dal sistema operativo utilizzato, dai requisiti hardware presenti sulla macchina, dal software utilizzato per la navigazione sulla rete. L’unica condizione è la connessione alla rete Internet di qualsiasi tipologia. Il prodotto software si trasforma in un servizio software dove tutto è dematerializzato,

senza

connessione e accesso.

supporto,

senza

installazione,

solo


L’analisi del presente modello inizia dove i sistemi precedenti presentano i limiti più evidenti che sono stati esaminati in precedenza. Il termine Cloud è una metafora che deriva dalla forma del disegno con cui si è soliti rappresentare in astratto un diagramma della rete di computer. Il realtà la tecnologia cloud rappresenta quanto di più moderno esiste attualmente, per la distribuzione non solo di applicazioni ma di intere infrastrutture di servizi hardware e software. La caratteristica fondante del sistema è data dal fatto che coloro che distribuisco un’applicazione cloud possono non essere i proprietari delle infrastrutture fisiche, evitando quindi gli investimenti di capitale necessari alla creazione della piattaforma. I servizi vengono solo consumati, ma la struttura appartiene ad altri, spesso in condivisione. E’ proprio grazie alla condivisione che questa tecnologia può offrire in fase di distribuzione delle applicazioni, ingenti risparmi in termini economici. La concorrenza di applicazioni garantirà sempre un utilizzo massimizzato della infrastruttura condivisa. Il cloud computing offre un’estensione apparentemente infinita di risorse di calcolo prontamente disponibili, in genere all'interno di un


centro dati. Questa piattaforma, permette di eliminare, la necessità di investimenti hardware iniziali. Il consumo delle risorse infrastrutturali, può essere organizzato, fra diverse grandezze e basato sull’effettivo utilizzo (“pay-as-you-go”), sulla quantità di dati movimentati oppure ancora sul numero di accessi al sistema (CAL), eliminando la quasi totalità dei costi di start up. Il cloud computing, rappresenta un concetto molto ampio, dove possono essere individuate diverse categorie, possiamo distinguere: Public Cloud. Dove la struttura di servizi rivende la propria infrastruttura a chiunque ne faccia richiesta. Private Cloud. Dove un’infrastruttura privata fornisce servizi ad un numero limitato di utenti. La Private Cloud è stata pensata come una espansione del network aziendale e del proprio data center. Hybrid Approach. Questo approccio rappresenta un mix fra l’adozione di soluzioni locali e soluzioni di cloud computing. Altra distinzione che possiamo effettuare è sulla base del servizio offerto: (IAAS) “Infrastrutture as a Service”: dove un fornitore fornisce le risorse hardware in remoto. Le risorse vengono utilizzate a richiesta (on demand). I clienti spesso beneficiano di API (Application Programming Interface) da cui possono controllare diversi parametri.


(Paas) “Platform as a Service”: è un insieme di software e strumenti di sviluppo ospitato sui server del provider. Gli sviluppatori possono creare applicazioni utilizzando le API (Application Programming Interface) del provider e comprendono una ricca serie di funzionalità, anche per operare con database relazionali. (SaaS) “Software as a Service”: é rappresentato dall’universo delle applicazioni fornite come servizio, tipicamente tramite Internet. Numerosi esempi includono le applicazioni aziendali (CRM/ERP), di comunicazione e strumenti di collaborazione (come ad esempio e-mail e Web conferencing), è il mercato più ampio fra i modelli proposti in precedenza. In questo caso il provider consente al cliente di utilizzare solo le sue applicazioni. Il software interagisce con l'utente attraverso una interfaccia utente. Buona parte delle cosiddette applicazioni 2.0 possono, sotto diversi aspetti, essere ricondotte a questa ultima tipologia. Nei primi anni 2000 viene esteso il concetto di SAAS (Software As a Service) riprendendo ed integrando il concetto di ASP (Application Service Provider). E’ questo ultimo modello, che costituisce l’oggetto di analisi del presente trattato dal punto di vista giuridico.


1.1 Modello Property Software Il software proprietario si basa essenzialmente sullo sfruttamento economico derivante dall’esercizio del diritto d’autore, in cui sono ricomprese tutte le facoltà esclusive e indipendenti, in ordine alla forma e al modo di sfruttamento del software, di cui si detiene la titolarità. Storicamente, l’idea della tutela giuridica del software, è stata proporzionale, ai crescenti interessi economici, che si andavano a formare attorno al mercato del software stesso. La funzione che si andava delineando, è sta quella di creare diritti di sfruttamento, in modo da garantire da una lato, un profitto al titolare e dall’altro, incentivare il miglioramento dell’intero mercato del software e soprattutto tutelare ed incoraggiare gli investimenti compiuti per la sua realizzazione. Lo sviluppo del software può avvenire sia da parte di soggetti singoli, ma più spesso da imprese, le quali mettono a disposizione le proprie risorse per lo sviluppo stesso e in entrambi i casi deterranno poi i diritti di proprietà intellettuale. E’ dallo sfruttamento di tali diritti, che il detentore trarrà le risorse necessarie per migliorare il progetto, apportare aggiornamenti periodici e per proporre prodotti software


sempre più competitivi, realizzando il modello di business tipico del software proprietario. I diritti di proprietà intellettuale e di sfruttamento commerciale possono dunque appartenere a uno o più soggetti siano questi imprese, enti o soggetti individuali. La diffusione dei personal computer ha portato all’affermazione del bene software quale prodotto di massa e come tale, la forma contrattuale più rispondente a questo fenomeno di distribuzione su larga scala, è la licenza d’uso. Quest’ultima infatti non investe problematiche riguardanti la titolarità dei diritti, ma solo il godimento degli stessi. Il rilascio o utilizzo attraverso licenza, è basato su un contratto. Per contratto di licenza d’uso si intende quel contratto attraverso il quale “il licenziante, concede al licenziatario, il godimento personale derivante dall’utilizzo del software stesso, per un periodo determinato o indeterminato e dietro pagamento di un corrispettivo una tantum o periodico”. A seconda delle modalità di diffusione possiamo distinguere diverse forme di licenze d’uso: Contratti di licenze a strappo (Shrink Wrap Licence), nate per rendere più rapide le transazioni commerciali e dell’impossibilità di utilizzare


la forma scritta per le relative transazioni. In tali casi, il supporto in cui è incluso il software, è racchiuso dal licenziante/produttore in un involucro, che reca al suo esterno le condizioni generali del contratto. Il contratto stesso si perfeziona, nel momento in cui l’utente apre l’involucro, senza che sia necessario apporre alcuna firma. I contratti di licenza shareware (o trial), i quali prevedono la cessione gratuita, per un periodo di prova, del software al fine di valutarne le funzionalità e corrispondenza alle proprie esigenze. L’utilizzo può essere sottoposto a limiti temporali e/o di funzionalità, al termine del periodo di prova il programma diventa non utilizzabile oppure mantiene accessibili solo alcune funzionalità. Il contratto di licenza freeware, nel quale il godimento del software è concesso esclusivamente a titolo gratuito, previa semplice richiesta dell’utente. Il contratto di licenza OEM (Original Equipment Manufacturer), é fra i contratti esaminati, quella che attribuisce una maggiore convenienza, da un punto di vista economico, per l’utente finale. I produttori di software infatti, concludono spesso accordi con i produttori di hardware, ai quali hanno attribuito l’autorizzazione a precaricare, tipicamente sull’hard disk dei computer i loro sistemi software (dapprima sistemi operativi ed ora anche applicativi). La particolarità


risiede nel fatto, che tali software, seguono la vita del componente hardware e non possono essere né distribuiti, né caricati o eseguiti su hardware diversi da quello a cui sono stati originalmente legati, una sorta di “simbiosi tecnologica” tra hardware e software. In generale, inoltre, per quanto riguarda l’ulteriore aspetto dell’estensione della licenza, questa è normalmente circoscritta ad un solo elaboratore, ma nella pratica commerciale si è affermato l’impiego delle cosiddette “licenze multiple” o di quelle “aggiuntive”, che consentono l’installazione e l’utilizzo del software su più terminali. La distribuzione del software proprietario tramite licenza, non esaurisce i tipi contratti di diffusione del software, per completare il quadro è necessario definire il contratto ad oggetto informatico e il contratto di sviluppo software. Il contratto ad oggetto informatico è quel contratto che ha ad oggetto beni o servizi informatici. La dottrina si è pronunciata in questo ambito per affermare che i contratti ad oggetto informatico non costituiscono una nuova categoria di contratto dotati di una disciplina tipica, bensì, costituiscono un tipo di contratto atipico. In aggiunta a ciò elaborazioni giurisprudenziali e dottrinali hanno riscontrato in


questa tipologia di contratti le caratteristiche secondo alcuni, del contratto misto o innominato e secondo altri, del contratto collegato. Il problema principale, che si pone con riguardo ai contratti misti, è quello di stabilire a quale disciplina giuridica siano essi sottoposti. I principali criteri usati sono due: il primo detto “dell’assorbimento”, che prevede che tali contratti debba applicarsi per analogia, la normativa

del

contratto

prevalente.

Il

secondo

detto

della

“combinazione”, stabilisce che si dovrebbero osservare le norme specifiche di ciascun elemento di ogni tipo, per quanto fra loro compatibili. Il contratto di sviluppo software è un contratto in cui un professionista o una software house assume l’obbligazione relativa allo studio, sviluppo e realizzazione di un software personalizzato in base alle specifiche esigenze del committente. Si tratta di un contratto a titolo oneroso e di un’obbligazione di risultato, dove lo sviluppatore è responsabile della rispondenza del prodotto alle richieste del committente. Anche in questo schema contrattuale, come per i precedenti e più in generale per il modello property software, ciò che viene distribuito è l’eseguibile, raramente infatti viene distribuito il codice sorgente.


Dal punto di vista del modello di business, il software proprietario fonda la propria caratteristica principale, sul ciclo di aggiornamento e sui tempi di ritorno degli investimenti effettuati. I tempi stimati, fino a qualche anno fa, erano nell’ordine dei tre, quattro anni ma nella competizione di mercato attuale, questi tempi sono drasticamente cambiati. Attualmente, a una software house di livello medio/grande, è richiesto un rilascio di versione massimo ogni anno, anno e mezzo, questo sia per ragioni di rientro economico ma anche per ragioni di marketing. Questo significa sforzi economici e di innovazione molto ingenti ed il mercato molto selettivo che ne deriva, costituisce primo quadro delle negatività legate a tale modello. Occorre altresì considerare, che i costi di rilascio dell’applicativo pacchettizzato, incidono sul prezzo di vendita finale che si cerca di rendere sempre minore. La documentazione a corredo dei pacchetti software assai cospicua fino a qualche anno fa, è ora quasi completamente inesistente o dematerializzata oppure ancora affidata a una comunità di esperti che producono libri, spesso a pagamento. L’accanimento implementativo a cui sono sottoposti i software e la ricerca spasmodica di nuove funzionalità, si scontra con una sempre maggiore difficoltà di tutela delle implementazioni stesse. Le violazioni brevettuali alle quali vanno incontro quotidianamente le


nuove versioni di software sono all’ordine del giorno e se è anche vero che spesso si risolvono in accordi commerciali, è altrettanto vero che sono valori da considerare in una strategia economica di alto livello.


1.2 Modello Free Software Il secondo modello oggetto di analisi è il modello Free Software. Nella concezione originale elaborata dalla FSF (Free Software Foundation) è Free il software che garantisce le cosiddette 4 libertà fondamentali previste dalla “Free Software Definition” (FSD) (enumerate come la rappresentazione di un array di byte a base zero): (Libertà 0): Libertà di eseguire il programma. (Libertà 1) Libertà di studiare come funziona il programma e adattarlo alle proprie necessità. (Libertà 2) Libertà di distribuire copie in modo da aiutare il prossimo. (Libertà 3) Libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti, in modo che tutta la comunità ne possa trarre beneficio. L’opera di Richard Stallman fondatore del movimento Free Software è stata, all’inizio, quella di trovare il modo di tutelare gli utenti e garantire agli stessi il godimento delle libertà fondamentali. La sua idea è quella che, per rendere il software veramente libero, si doveva dichiarare il software protetto da copyright e poi garantire le libertà fondamentali attraverso la licenza. Egli afferma che “Gli sviluppatori


ricorrono al Copyright per rubare la libertà degli utenti, noi utilizziamo il Copyright per tutelare quella libertà”. Quindi software libero non significa possibilità di utilizzo in maniera indiscriminata, il software libero è comunque soggetto a licenza d’uso a differenza del software di pubblico dominio. La licenza quindi si dimostra il metodo più efficace per raggiungere gli scopi di tutela delle libertà fondamentali.. Proprio l’elaborazione della licenza, a cui è stato affidato il compito finale, di garantire legalmente a tutti gli utenti, le quattro libertà fondamentali, fu un’opera molto complessa e alla cui redazione contribuirono oltre a Richard Stallman e Eben Moglen anche diversi giuristi. Ciò che gli autori riuscirono a concepire, fu la licenza GNU GPL, veicolo attraverso il quale buona parte del software libero viene distribuito. E’ considerata proprio per questo suo contenuto garantista, una delle licenze più restrittive, poiché impone che ogni prodotto software derivato, venga a sua volta distribuito con la stessa licenza. Emerge così il concetto denominato Copyleft (a differenza di Copyright), spesso tradotto anche in “permesso d’autore” (a differenza di diritto d’autore), la cui caratteristica principale è quella di non permettere che vengano aggiunte restrizioni nelle modifiche successive del software. L’opera modificata, verrà distribuita


mediante lo stesso regime giuridico e generalmente sotto la stessa licenza dell’opera originaria. Così facendo infatti vengono preservate a favore degli utenti il godimento delle libertà fondamentali. Le prime applicazioni della licenza GPL hanno fatto emergere una problematica derivante da una caratteristica specifica della licenza: la cosiddetta “viralità”. Infatti la licenza GPL nella sezione 5 indica chiaramente che “I programmi coperti da questa licenza non possono essere incorporati all’interno di programmi non liberi. Occorre notare che il software per sua natura non è un’entità monolitica, bensì un’insieme eterogeneo di istruzioni di derivazione alquanto variegata, è quindi assai comune che uno sviluppatore necessiti di scorporare il pacchetto software e rielaborarne solo una parte oppure di fare interagire un software libero con un software proprietario. Questa sorta di integrazione fra software libero e non libero, può essere realizzata a mezzo della licenza LGPL (Lesser General Public Licence) che nel mondo della programmazione risulta molto utilizzata. Può essere considerata come una licenza GPL “attenuata”. Con tale licenza vengono di solito rilasciate le cosiddette librerie, parti di codice sorgente, che eseguono funzioni limitate e che per la loro caratteristica possono essere utilizzate ed implementate anche al di fuori del progetto per le quali sono state concepite. La licenza LGPL


permette di limitare la copertura offerta dalla licenza non a tutto il codice sorgente del progetto, ma solo a porzioni di codice. Cosicché, non è raro trovare software proprietari, che utilizzano librerie LGPL. Non dimentichiamo che, nella concezione del Free Software, l’elaborazione del software avviene da parte della comunità e non da risorse messe a disposizione dalle aziende produttrici come per il software proprietario. Una caratteristica insita nel modello Free Software che più di altre ha contribuito in maniera esponenziale allo sviluppo e diffusione dello stesso modello, é il cosiddetto Open Source ossia la possibilità di disporre del codice sorgente del software. Il termine Open Source venne coniato agli inizi del 1998 su iniziativa di alcuni importanti sviluppatori della comunità Free Software quali: Linus Torwalds, Tim O’Really, Eric Raymond. L’obiettivo era quello di rendere l’idea di software libero più accettabile all’ambiente commerciale, evitando le posizioni intransigenti di Stallman e contemporaneamente evitare l’equivoco della parola “free” (oltre che libro anche gratuito). La parola Source sottolinea il fatto che un software non è tanto l’eseguibile, ma il sorgente.


Nasce così l’Open Source Initiative (OSI), un movimento parallelo al Free software. E’ proprio OSI che sviluppa la definizione di Open Source, l’Open Source Definition (OSD). Dunque la Open Source Definition non è un modello di licenza, bensì una serie di specifiche che caratterizzano una licenza Open Source. L’Open Source Definition si estrinseca in 10 sezioni, che da un lato confermano l’appartenenza ai cardini del movimento Free Software, dall’altro ne creano alcuni appositi per il concetto di Open Source. Al primo gruppo possiamo ricondurre la Sezione 1 (libertà di distribuzione), la sezione 2 (disponibilità codice sorgente), la sezione 3 (possibilità di modifiche e realizzare opere derivate), le sezioni 5 e 6 (divieto i discriminazione di persone o settori di applicazione). Alcune altre disposizioni sembrano allontanarsi dalle finalità della GPL, ad esempio la sezione 9 (rapporti fra diversi regimi di licenza) sezione 7 (trasposizione automatica degli effetti della licenza). L’OSI autorizza l’apposizione ufficiale del marchio registrato. Rileviamo quindi 4 criteri fondamentali di classificazione delle licenze software in base all’OD: 1. Possibilità che il codice venga miscelato con codice di matrice commerciale.


2. Possibilità che le modifiche al codice siano mantenute, quindi senza essere restituite all’autore originale. 3. Possibilità che il codice così realizzato venga liberamente rilicenziato da chiunque. 4. Permanenza di alcuni privilegi speciali sulle modifiche per chi detiene il copyright. L’analisi del presente modello si conclude con l’analisi di quelle che sono le critiche, che da più parti vengono attribuite a tale modello. Per quanto attiene al modello di business, il free software non può basare sul revenue delle licenze come accade per il software proprietario, ma su servizi, consulenze, personalizzazioni. La complessità dei progetti, fanno si che coloro veramente in grado di mettere le mani ad un progetto free software/open source, siano soggetti davvero molto competenti e difficilmente possono essere individuati in aziende medio/piccole. La community manca di efficienza e tempestività, specie per nuove funzioni o risposte a problematiche pratiche ed inoltre, non esiste un referente chiaro per modifiche o assistenza e manutenzione. I tempi di risposta della community sono spesso elevati, anche per quanto riguarda la personalizzazione i costi possono essere notevolmente alti. In conclusione questo modello di business tende a spostare i costi


dall’acquisto del software alla manutenzione del software e quindi, indirettamente, dal costo della licenza al costo del personale specializzato per la gestione.

Premessa. L’analisi dell’oggetto del presente trattato, inizia dall’esame dei modelli di produzione e distribuzione tradizionali del software, quali il Software Proprietario e il Free Software per poi proseguire con l’analisi di nuovo modello tecnologico e di fruizione, costituito dal modello delle Web Application (Cloud). Proseguendo si analizzeranno le implicazioni giuridiche di tale modello attraverso l’analisi dei modelli di condizione di fruizione dei servizi Cloud, le cosiddette policy Cloud Service Agreements (CSA).


Bibliografia 1

Prof Monica Palmirani – © Corso di Informatica Giuridica – Università degli studi di Bologna.

2

Robert McHale, Cloud Security and Privacy: A Legal Compliance and RiskManagement Guide, Part 2

3

Simone Aliprandi – Copyleft e open content l’altra faccia del copyright – Primaora Lodi

4

Marco Marandola - Il nuovo diritto d’autore Introcuzione a copyleft, open access e creative commons, – DEC milano 2005

5

Cristian Ercolano – I contratti ad oggetto informatico. Rivista “Il Nuovo diritto”

6

Wikipedia – Cloud Computing

N.B.: L’impaginazione è stata modificata per proporre, prima di tutto il resto, gli aspetti giuridici e tecnologici del modello di applicazioni Cloud, rispetto agli altri modelli.

Grazie per l’attenzione

Gabriele Riccò


Aspetti Giuridici e Tecnologici delle Cloud Application.