Come già avvenuto il mese scorso in merito a un'altra consultazione pubblica (quella sul Piano Nazionale di Digitalizzazione del patrimonio culturale > VEDI), condivido qui le mie annotazioni sulla bozza di "Linee Guida recanti regole tecniche per l’attuazione del decreto legislativo 24 gennaio 2006, n. 36 e s.m.i. relativo all’apertura dei dati e al riutilizzo dell’informazione del settore pubblico" diffusa da AgID lo scorso 16 giugno. La bozza ufficiale soggetta alla pubblica consultazione è disponibile QUI.
Approfitto per ricordare che l'argomento è stato da me trattato con approccio divulgativo (e credo con un risultato apprezzabile) nel vademecum "Aspetti legali degli open data: la guida definitiva. Un’introduzione semplice e chiara su copyright, privacy, licenze e normativa di riferimento", realizzato per l’associazione onData nell’ambito della campagna #datibenecomune [scarica qui]. Per un ulteriore livello di approfondimento del tema, rimando invece al mio libro "Software licensing & data governance. Tutelare e gestire le creazioni tecnologiche" (Apogeo/Feltrinelli, 2020) disponibile online QUI.
Anche in questo caso, mi soffermerò principalmente sugli aspetti di mia più stretta competenza, cioè quelli relativi alla gestione della proprietà intellettuale, delle licenze d’uso e dei relativi metadati. Questi temi vengono trattati principalmente nel paragrafo "6.1. Licenze e condizioni di riutilizzo". Nella parte finale comunque dedicherò alcune righe ad altri paragrafi.
Come giudizio complessivo, il documento è molto dettagliato, ben strutturato e prende in considerazione tutti gli aspetti fondamentali della materia. Le tabelle e gli schemi sono chiari e molto utili per chiarire i concetti chiave. Devo quindi complimentarmi con gli autori del documento per il lavoro svolto. Forse in alcuni passaggi si poteva utilizzare una terminologia e una sintassi meno complesse per rendere il documento (che già tratta temi di per sé molto tecnici) più fruibile e comprensibile anche al lettore non addetto ai lavori. A mio avviso alcuni passaggi, probabilmente scritti con l'intento di dare conto del dibattito e delle problematiche che hanno portato a determinate scelte normative, rischiano di rendere le questioni più complesse di quanto siano in realtà. Dobbiamo invece tenere presente che questi documenti non sono articoli scientifici o white paper, bensì linee guida; dunque il loro principale obiettivo è quello di orientare le prassi e non quello si argomentare sui problemi teorici.
Un primo esempio di un eccessivo indugiare sul background teorico emerge a mio avviso quando il documento cerca di individuare le licenze più adatte per rilasciare open data. Mi pare vi siano troppe retrospettive sui vari scenari portati dalle diverse licenze, quando ormai da anni la direzione tracciata a livello sia normativo sia di comunità scientifica è quella delle licenze di mera attribuzione o i waiver di pubblico dominio. In altre parole, se è ormai assodato da anni che le licenze più adatte per fare open data sono la CC BY (o equivalenti) o anche i waiver come CC0, potrebbe risultare foriero di confusione per i lettori (e quindi controproducente ai fini degli obiettivi delle linee guida) riaprire "vecchie ferite ormai rimarginate" sui pro e i contro delle varie licenze. Per lo stesso motivo eviterei di riportare in auge licenze da tutti considerate inadeguate se non addirittura espressamente deprecate come la IODL 1.0.
Per fortuna, questo effetto viene comunque mitigato dai riquadri con le raccomandazioni, che in effetti semplificano molto i concetti in ottica operativa.
In compenso, pur con i vari approfondimenti sul background teorico, non trovo nel documento sufficienti considerazioni sulla peculiarità del diritto della proprietà intellettuale in materia di banche dati. Le principali difficoltà nel gestire le licenze open data derivano proprio dal fatto che il diritto sui generis creato con la direttiva 1996/9/CE ha dinamiche e meccanismi diversi rispetto alle altre categorie di opere dell'ingegno - per così dire - più classiche (testi, immagini, musiche). E infatti alcune licenze hanno richiesto una riscrittura proprio per considerare queste differenze (vedi il passaggio dalla versione 3 alla versione 4 delle Creative Commons). Per essere pignoli, anche il concetto di "opera derivata" utilizzato da buona parte delle licenze (con esclusione della ODbL che utilizza definizioni del tutto peculiari e proprio centrate sulle banche dati) mal si adatta all'ambito delle banche dati. Realizzare un dataset partendo da un altro dataset preesistente o integrando diversi dataset preesistenti è cosa ben diversa da rielaborare un'immagine per fare un'infografica o modificare un brano musicale per farne un remix dance. Invece la bozza delle linee guida in consultazione insiste con il concetto di "opera derivata" anche in ambito di banche dati.
Questo risvolto potenzialmente problematico va a sovrapporsi con un altro risvolto ben noto: la normativa open data e i vari documenti ufficiali sugli open data (comprese queste linee guida) utilizzano i concetti di "dati" e "documenti" (tra l'altro mettendoli spesso insieme, come un tutt'uno) che risultano estranei al diritto della proprietà intellettuale. Infatti, nella terminologia più corretta appartenente al diritto della proprietà intellettuale, abbiamo "banche dati" e non "dati" (i dati in sé infatti non sono oggetto di diritti esclusivi); inoltre il termine/concetto "documenti" non si riscontra nella legge italiana sul diritto d'autore (L. 633/1941). "Documento" tendenzialmente fa pensare a qualcosa che non richiede alcuno sforzo creativo/intellettuale, dunque rimane fuori dal campo d'azione del diritto della proprietà intellettuale; un documento ufficiale è tendenzialmente qualcosa che non ha alcuna tutela di diritto d'autore (si veda anche il laconico art. 5 L. 633/1941 dedicato agli "atti ufficiali") quindi non avrebbe comunque senso discutere su quale licenza applicarvi. Ma soprattutto bisognerebbe capire bene che cosa si intende per "documenti": nella definizione rientrano anche le immagini e le fotografie? Oppure la definizione coincide più o meno con quella di "atto ufficiale" richiamata dall'art. 5? Quesiti che io sollevo da tempo e che mai hanno avuto risposta né da parte del legislatore (il quale continua imperterrito con queste discrasie lessicali e concettuali) né da parte della giurisprudenza.
Non è solo una questione di "lana caprina" terminologica; infatti licenze che funzionano bene sulle banche dati (come la ODbL) non è detto che funzionino bene sui documenti o sulle immagini o sulle fotografie. Quindi avere ben chiaro di quale sia l'oggetto della licenza è fondamentale e cercare di fare di tutta l'erba un fascio non è detto sia la scelta più opportuna (forse la più comoda, ma non la più opportuna). Benché questo problema di confusione concettuale e terminologica sia figlio di scelte (sciagurate) di un legislatore poco attento e approssimativo, credo che gli autori delle linee guida dovrebbero tenerlo in considerazione e cercare di mitigarne gli effetti. Anzi, forse proprio queste linee guida potrebbero diventare il luogo adatto per fornire un chiarimento interpretativo su questo risvolto determinante.
Altro aspetto che non mi trova pienamente d'accordo è la priorità generale che si riserva alle soluzioni tipo CC BY a scapito di soluzioni tipo CC0/pubblico dominio. Pur rimanendo nei limiti comunque imposti dalla normativa vigente, a mio avviso bisognerebbe enfatizzare il ruolo del pubblico dominio e delle soluzioni per implementarlo. In particolare sarebbe opportuno sottolineare che, in tutti quei casi in cui i dataset o i documento sono di pubblico dominio (e questi casi sono molto più frequenti di quanto si voglia far credere), è più sensato e corretto utilizzare un public domain mark e non una licenza.
Mi trovo quindi in totale disaccordo con il seguente passaggio della bozza di linee guida:
In questo contesto, l’apposizione di una licenza, oltre a identificare e “definire” correttamente i dati aperti, costituisce uno strumento funzionale a garantire certezza circa l’effettiva riutilizzabilità di un dataset o database; certezza che costituisce un presupposto essenziale alla valorizzazione dell’informazione, specie nel settore pubblico. Seppure, quindi, in assenza di specifica licenza operi il principio dell’“open by default” previsto dall’art. 52 del CAD, SI RACCOMANDA di apporre sempre una licenza ai dataset pubblicati, in modalità tali da renderla facilmente individuabile e comprensibile.
Nessuno mette in dubbio la necessità di una maggior certezza (che l'open by default dell'art. 52 CAD in effetti non garantisce), ma non possiamo nemmeno negare che anche un public domain mark può garantire certezza in tutti quei casi in cui le opere, i dati o i documenti sono – grazie al cielo – di pubblico dominio. Si confonde la funzione della licenza (che è quella di regolamentare gli utilizzi delle opere) con la funzione dei metadati e delle tag semantiche (che invece è proprio quella di rendere più facilmente riconoscibile lo status giuridico di un'opera).
Invito quindi i redattori del documento a rendere più chiaro il concetto secondo cui NON HA ALCUN SENSO apporre una licenza (per quanto libera come la CC BY) su qualcosa che di per sé è già in pubblico dominio.
Se questa scelta è dettata dall'assurda ossessione per la citazione della fonte che molte pubbliche amministrazioni hanno, rimando a quanto già scritto a proposito delle linee guida sul patrimonio culturale. Anzi mi permetto di utilizzare un'espressione forte, non proprio elegante, ma indubbiamente efficace: trattasi più propriamente di "sega mentale". Una pubblica amministrazione che pubblica un dataset, magari un dataset a pubblicazione obbligatoria, con i dati sul livello di polveri sottili registrato durante l'anno NON ha alcun titolo giuridico per agire contro il giornalista o contro la start-up che dovesse omettere o sbagliare la citazione della fonte. Si confonde la buona prassi scientifica e giornalistica di citare le fonti correttamente con l'onere giuridico di citare l'autore di un'opera intellettuale. Facciamocene una ragione e capiamo una volta per tutte questa sfumatura. I dirigenti della PA dovrebbero fare un lavoro di psicoterapia per curare questa ossessione verso l'attribuzione della fonte e finalmente liberare il mondo da questa piaga delle licenze con obbligo di Attribuzione anche su dati che comunque devono essere esposti per un obbligo di legge. In tutti quei casi la scelta del CC0 o addirittura del public domain mark deve essere la priorità. Invito quindi gli autori delle linee guida a rivedere questi passaggi in tal senso.
Riguardo a quanto scritto nel paragrafo "3.1. Note di lettura del documento", cioè "DEVE o DEVONO, indicano un requisito obbligatorio per rispettare le linee guida" raccomando maggiore attenzione. Le linee guida sono documenti meramente orientativi e non pienamente normativi. Benché sia ormai molto diffusa, è assolutamente da deprecare la tendenza a considerare documenti di "soft law" come vere e proprie norme giuridiche; gli obblighi giuridici non sono contenuti e non possono essere contenuti in linee guida e circolari bensì appunto in norme giuridiche. A mio avviso quindi bisogna correggere quella frase come segue: "DEVE o DEVONO indicano un requisito obbligatorio per rispettare le norme giuridiche richiamate dalle presenti linee guida". Anche in questo caso, solo a chi non ha sufficiente cultura giuridica, questa può sembrare solo una pignoleria superflua.
A questo punto viene da chiedersi: perché chiamare questo documento "Linee Guida recanti regole tecniche per l’attuazione del decreto..." e non direttamente "Regole tecniche per l’attuazione del decreto..."? Così sarebbe indubbiamente più onesto e qualificherebbe questo documento non come "soft law" ma come "norma giuridica secondaria/attuativa".
Segnalo inoltre un refuso all'inizio del Capitolo 4: "il decreto legislativo n. 36/2016 che diventa, quindi, il riferimento normativo nazionale in tema di apertura di dati e riutilizzo del patrimonio informativo pubblico". Chiaramente il decreto è del 2006 e non del 2016. Sarebbe comunque importante correggere onde evitare che qualcuno sia tratto in inganno.
Commenti