La proprietà intellettuale sui dati: scenari e problematiche della derivazione e integrazione di dataset

Estratto dal libro “Software licensing & data governance. Tutelare e gestire le creazioni tecnologiche” (Apogeo Editore, settembre 2020); opera liberamente riproducibile nei termini della licenza Creative Commons Attribution – Non Commercial – Share Alike 4.0 International.

Sommario: 1. I concetti di “derivazione” e “integrazione” nel mondo delle banche dati – 1.1. Derivazione – 1.2. Integrazione – 2. Scenari più frequenti di integrazione e derivazione tra banche dati – 2.1. Integrazione di dataset preesistenti – 2.2. Semplice rielaborazione matematica di dati provenienti da dataset preesistenti – 2.3. Il particolare caso della mera validazione di dati – 2.4. Dataset realizzati attraverso un processo di modellazione di dati prelevati da un dataset preesistente – 2.5. Rappresentazione grafica del contenuto di un dataset.

--- Scarica la versione PDF di questo contenuto: da Zenodo; da SlideShare ---

________________________________________

1. I concetti di “derivazione” e “integrazione” nel mondo delle banche dati

1.1. Derivazione

Buona parte dei problemi in tema di licenziamento e riutilizzo di dati deriva dalle clausole che limitano/condizionano l’attività di realizzazione di database “derivati” (ne parleremo meglio quando tratteremo licenze come la Open Database License e le Creative Commons con clausola share alike).

Il concetto di “opera derivata” proviene infatti dal diritto d’autore classico, cioè il diritto d’autore applicato alle opere creative in senso pieno: tipici esempi di opere derivate sono la traduzione di un testo letterario, il remix di un brano musicale, l’adattamento cinematografico di un’opera teatrale. La realizzazione di una banca dati “nuova” partendo da una banca dati preesistente comporta un’attività diversa, che quindi, per essere correttamente inquadrata dal punto di vista giuridico, necessita di essere definita in modo molto preciso a livello contrattuale (appunto nelle licenze d’uso applicate).

Al contrario di quanto accade con le opere dell’ingegno tutelate dal diritto d’autore (comprese le banche dati con carattere creativo), per le quali si parla spesso di “derivazioni”, “elaborazioni creative” e “opere derivate”, non è chiaro se si possa applicare la categoria della derivazione ai database tutelati da mero diritto sui generis. Ciò è dovuto al fatto che tra i diritti esclusivi del costitutore di banca dati non vengono annoverati i diritti relativi alle classiche forme di derivazione e rielaborazione (come per esempio la traduzione, il riassunto, l’adattamento ad altro media, il riarrangiamento musicale); bensì, più propriamente, viene annoverato solo un diritto di impedire attività di estrazione e reimpiego di dati dal database (per la precisione di parti sostanziali del database).

1.2. Integrazione

Dobbiamo poi mettere a fuoco il concetto di integrazione tra database poiché in effetti “integrare” un database non creativo all’interno di un altro database non creativo è un’operazione diversa rispetto all’integrazione di due testi letterari o di due pacchetti software. Si tratta in sostanza di riversare i dati di un database all’interno di un altro autonomo database, rendendo le due masse di dati non più distinguibili, e lasciare che poi il database risultante venga diffuso, utilizzato, consultato come un “tutt’uno”. Ma non si ha una vera e propria “contaminazione” stilistica e creativa come appunto avviene con altri tipi di opere.

Non a caso, nel mondo dei database non creativi rilasciati, a volte il problema della compatibilità tra licenze si risolve tenendo i dataset separati e facendo in modo che l’utilizzatore possa interrogarli attraverso un’unica interfaccia software (realizzando così quella che nell’ambito software abbiamo chiamato “mera aggregazione”).

Per fare un esempio in metafora, integrare due dataset differenti è come miscelare due diversi tipi di cereali: da un lato abbiamo la confezione di fiocchi d’avena, dall’altro la confezione di riso soffiato, e li versiamo entrambi in un unico contenitore. Otteniamo così un mix che contiene sia fiocchi d’avena sia riso soffiato dal quale è difficile e poco pratico dividere di nuovo i due tipi cereali. Scriveremo sul contenitore “mix di fiocchi d’avena e riso soffiato”, che, seguendo sempre il senso della metafora, corrisponde alla classica avvertenza con i credits in cui indichiamo le due diverse fonti dei dati che sono state integrate in questo nuovo dataset derivato. Se però per qualche ragione contingente abbiamo necessità di poterli sempre separare anche a posteriori (per esempio, nostro figlio è intollerante ai fiocchi d’avena), non possiamo far altro che avere un contenitore che comunque abbia al suo interno due vaschette separate in cui da una parte possiamo mettere i fiocchi d’avena e dall’altra il riso soffiato. All’atto pratico, quando vorremo versare i cereali nella scodella, potremo comunque versarli insieme mescolandoli nella scodella; ma quando invece dovremo preparare la colazione per nostro figlio, potremo prendere solo i cereali dalla vaschetta del riso soffiato.

Uscendo dalla metafora, l’intolleranza di nostro figlio, che appunto ci obbliga a tenere separati i cereali anche se vengono conservati in un unico contenitore, corrisponde a una questione di incompatibilità tra i due database; incompatibilità che potrà essere derivante dalle rispettive licenze oppure dalla natura non omogenea dei dati.

2. Scenari più frequenti di integrazione e derivazione tra banche dati

2.1. Integrazione di dataset preesistenti

Come primo scenario poniamo quello in cui Tizio realizza il Dataset A con il numero dei casi di morbillo registrati nel 2015 in tutti i comuni della Provincia Autonoma di Bolzano. Caio realizza un autonomo Dataset B il numero dei casi di morbillo registrati nello stesso anno nei comuni della Provincia Autonoma di Trento. Sempronio vuole realizzare un Dataset C con il numero di tutti i casi registrati nel 2015 nella Regione Trentino-Alto Adige suddivisi per comuni e dunque può farlo semplicemente aggregando Dataset A e Dataset B in un più ampio Dataset C. In Dataset C i dati vengono riorganizzati secondo un criterio diverso. I due dataset originari perdono quindi i loro “confini” e si fondono in un nuovo e autonomo dataset.

Questa attività di integrazione fa sì che il Dataset C debba essere considerato come un dataset derivato contemporaneamente da Dataset A e da Dataset B. Di conseguenza Sempronio dovrà ottenere il permesso per l’attività di integrazione sia da Tizio sia da Caio; oppure, qualora i due dataset originari siano rilasciati con una licenza pubblica, dovrà verificare se le due licenze consentono quella specifica attività e se sono tra esse compatibili. Sempronio dovrà infatti rispettare sia le condizioni della licenza di Dataset A, sia le condizioni della licenza di Dataset B.

Diversa però sarebbe la situazione se Sempronio si limitasse a diffondere Dataset A e Dataset B in un unico file di archiviazione (tipo ZIP), mantenendoli tecnicamente separati e indicando per ciascuno la titolarità del copyright e la licenza applicata. In questo caso si verificherebbe quella che comunemente chiamiamo “mera aggregazione” e non saremmo di fronte a un’attività di derivazione/integrazione, dato che il file ZIP non costituisce un dataset a sé e Dataset A e Dataset B rimangono separati. Ovviamente anche in questo caso Sempronio dovrebbe ottenere da Tizio e da Caio un permesso anche per la sola ripubblicazione dei dataset originari (che è comunque un’attività riservata) o verificare se tale attività è consentita dalle rispettive licenze.

2.2. Semplice rielaborazione matematica di dati provenienti da dataset preesistenti

Tizio realizza il Dataset A con i livelli di polveri sottili registrati da apposite centraline posizionate in tutti i comuni d’Italia e che rilevano il dato ora per ora, ottenendo così 24 valori per ciascun comune. Caio utilizza i dati contenuti nel Dataset A per realizzare un Dataset B più semplificato che non fa altro che dare un valore medio giornaliero per ciascun comune, quindi da 24 valori per comune si passa a 1 valore per comune. Questo valore è ottenuto senza un’apprezzabile attività intellettuale bensì attraverso un banale calcolo matematico (una media), impostato automaticamente e scevro da un intervento intellettuale/creativo apprezzabile. Il Dataset B non contiene un’estrazione vera e propria dei valori del Dataset A perché nel Dataset B non si trovano valori presenti nel Dataset A, e dal Dataset B non è possibile risalire ai valori più dettagliati del Dataset A. Da un lato quindi verrebbe da pensare che il Dataset B non riproduce dati contenuti nel Dataset A; dall’altro lato tuttavia il Dataset B rappresenta comunque una forma di “reimpiego” di una parte sostanziale del dataset così come definito dall’art. 7, co. 2 dalla Direttiva 96/9/CE.

2.3. Il particolare caso della mera validazione di dati

Quello della mera validazione dei dati contenuti in un Dataset preesistente è uno scenario molto interessante e abbastanza ricorrente in ambito scientifico. Ipotizziamo che Tizio realizzi il Dataset A con il livello di pericolosità sismica di una determinata faglia in dinamica storica, con tutti gli eventi sismici registrati negli ultimi cento anni. Caio analizza i dati presenti in Dataset A per procedere a una loro validazione tecnico-scientifica basata sulla sua maggiore esperienza nel settore e sulla base di altri dati fondamentali (per esempio: le caratteristiche del terreno) e pubblica un Dataset A-bis sostanzialmente identico, ma validato; cioè senza alcun intervento sui dati ma solo con l’indicazione che il dataset è stato da lui validato. Oppure semplicemente nel Dataset A-bis Caio riporta una colonna aggiuntiva con l’indicazione dei dati validati e dei dati non validati.

È un caso giuridicamente interessante perché comunica efficacemente la differenza tra il diritto d’autore classico e il diritto sui generis sulle banche dati. Se parlassimo di un testo letterario o di un’opera musicale (cioè di opere tutelate da diritto d’autore), un intervento di validazione che non modifica l’opera in modo percepibile non potrebbe in alcun modo portare a un’opera derivata. Nel caso delle banche dati invece anche la mera attività di verifica di un database rientra nelle attività rilevanti ai fini della Direttiva 96/9/CE. L’art. 7, co. 1, precisa infatti che il costitutore di una banca dati non creativa è titolare del diritto sui generis “quando il conseguimento, la verifica e la presentazione del contenuto di una banca dati attestino un investimento rilevante sotto il profilo qualitativo o quantitativo”. A ben vedere, dunque, anche la semplice aggiunta di una colonna in una tabella di cento colonne rappresenta un’attività di reimpiego del dataset; attività che, benché possa risultare marginale a livello quantitativo, ha indubbiamente rilevanza sul piano qualitativo poiché va a modificare il concept generale del dataset, il suo valore e la sua possibilità di essere utilizzato da più utenti.

2.4. Dataset realizzati attraverso un processo di modellazione di dati prelevati da un dataset preesistente

Altro scenario abbastanza diffuso, che crea spesso fraintendimenti, è quello dell’attività di modellazione: mi riferisco ai modelli di previsione utilizzati per le previsioni meteo, per il calcolo del rischio sismico, per fornire proiezioni in finanza. Il modello è sostanzialmente un procedimento matematico che, a fronte di alcuni dati input, restituisce un output che appunto è la previsione/proiezione. Il modello quindi è più simile a software (opera tutelata dal diritto d’autore) e a un’espressione matematica (che teoricamente non potrebbe essere tutelata con diritto d’autore, ma più propriamente con l’applicazione del segreto industriale). A ogni modo, il modello è qualcosa di idealmente separato dai dati che esso “macina”, è un’opera dell’ingegno a sé stante. Ne consegue che il titolare dei diritti sul modello può essere un soggetto diverso da quello che realizza la banca dati da cui il modello estrae informazioni per fornire i suoi output. Ci si chiede quindi se vi sia un rapporto di derivazione tra i dataset input e il dataset prodotto dal modello come output; ma anche se vi sia un rapporto di derivazione tra i dataset input e il modello in sé. Lo focalizziamo meglio ponendo uno scenario ipotetico.

Tizio realizza il Dataset A con le temperature registrate in una determinata zona negli ultimi tre giorni; Caio realizza un autonomo Dataset B con il tasso di umidità registrato nella stessa zona negli ultimi tre giorni; Sempronio realizza un autonomo Dataset C con la pressione atmosferica registrata nella stessa zona negli ultimi tre giorni. Mevio, ha realizzato un modello di calcolo che incrocia i dati presenti nei Dataset A, B e C e permette di creare un Dataset Z con la probabilità di precipitazioni nelle prossime ore in quell’area.

Dataset Z dovrà essere considerato come dataset derivato dai Dataset A, B e C? La risposta è positiva. Il modello di calcolo può generare i suoi output e andare così a popolare il Dataset Z solo con un’attività di estrazione e reimpiego di parti sostanziali dei Dataset A, B e C. Ne consegue che colui che “fa girare il calcolo” e pubblica il Dataset Z dovrà avere ottenuto le adeguate autorizzazioni da parte dei titolari dei diritti dei Dataset input. In alternativa, i tre dataset di input dovranno essere rilasciati con licenze pubbliche che autorizzano quell’attività e dovranno inoltre essere tra loro compatibili; quindi il Dataset Z dovrà rispettare le indicazioni di titolarità dei diritti (c.d. attribution) di tutti i tre database input e la licenza scelta per il Dataset Z dovrà comunque essere compatibile con tutte e tre le licenze dei dataset di input.

2.5. Rappresentazione grafica del contenuto di un dataset

Altro scenario molto frequente è quello della rappresentazione grafica dei dati contenuti in una banca dati: grafici, tabelle, mappe e tutte le altre forme di data visualization.

Mostrare una mappa con dei dati presi da un dataset crea un rapporto di derivazione? Indubbiamente si tratta di un’attività di “estrazione e reimpiego”; tuttavia bisogna ricordare che la direttiva del 1996 parla più propriamente di “estrazione e reimpiego di parti sostanziali” di una banca dati. Quindi la risposta al quesito diventa necessariamente “dipende”, perché va parametrata sul concetto di “parte sostanziale”.

Benché sia più rara, si verifica anche la situazione opposta: utilizzare una mappa per estrarre informazioni e realizzare una banca dati. Una mappa non è una banca dati in sé bensì un’opera grafica tutelata da un diritto d’autore in senso classico; ma se si tratta di una mappa che riporta dei dati e se la raccolta di questi dati ha comportato per il suo autore un investimento rilevante, allora l’autore deterrà anche il famigerato diritto sui generis e potrà impedirne attività di estrazione e reimpiego dei dati. Anche in questo caso, comunque, per rispondere è necessario valutare se si tratti davvero di una parte sostanziale della banca dati.

Altra variabile interessante da valutare nella rappresentazione di dati su mappa è l’aspetto - per così dire - informatico. Una mappa contenente dati può essere diffusa online come file raster, ma può anche essere rappresentata come un file vettoriale composto da una serie di “strati” trasparenti che idealmente si “appoggiano” su una mappa neutra. Nel caso della mappa raster ha in effetti senso chiedersi se vi sia un rapporto di derivazione tra la mappa e il dataset originario da cui sono tratti i dati rappresentati nella mappa. Nel caso di una mappa “a strati” in realtà la questione va considerata in modo diverso, poiché non è la mappa in sé a rappresentare i dati bensì i vari strati trasparenti che ad essa si sovrappongono; e la mappa rimane solo di sfondo. In questo caso quindi, a seconda di come viene impostata l’interfaccia utente che mostra i dati sulla mappa, è possibile mantenere separati i vari dataset facendo corrispondere a ciascuno di essi uno strato di dati.

A complicare lo scenario intervengono anche i testi delle varie licenze d’uso per banche dati che, come vedremo, spesso contengono una definizione di “opera derivata” più precisa. In particolare vedremo nei prossimi paragrafi che la licenza OdbL (licenza open appositamente pensata per le banche dati) fa una distinzione tra Derivative Database e Produced Work, e dalle due diverse fattispecie fa dipendere diversi effetti giuridici. Come avremo modo di approfondire, il caso della realizzazione di una grafica o di una mappa basata sui dati di una banca dati rilasciata con licenza ODbL è proprio l’esempio più classico di Produced Work.