Digital Media in Italia

Un'iniziativa per interrogarci sul ruolo dell'Italia
e per programmare il nostro futuro

  

 

Specifiche funzionali, azioni normative e governance 

Per la realizzazione della proposta dmin.it

  

 

Il presente documento è stato redatto da Digital Media in Italia (dmin.it), un gruppo interdisciplinare, aperto e senza scopo di lucro che ha l’obiettivo di definire e proporre aree di intervento che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno globale “digital media”.

I professionisti che partecipano a dmin.it mettono a disposizione le proprie competenze, visioni ed esperienze a titolo personale, pertanto quanto riportato nel documento non impegna in alcun modo le aziende e le organizzazioni all’interno delle quali i singoli professionisti operano. 

Digital Media in Italia: http://www.dmin.it 

  

Rilasciato con licenza Creative Commons Attribuzione - Non commerciale 2.5

15 marzo 2007


Executive summary

Con questo documento Digital Media in Italia (dmin.it) definisce:

  1. Le specifiche funzionali

  2. Le regole di governance

  3. Gli interventi normativi

richiesti per rendere concretamente realizzabili le tre proposte di sistemi iDRM, dell’accesso alla rete a larga banda e di pagamento per digital media[1] contenute nel documento pubblicato il 15 settembre 2006 [1] avente per obiettivo la massimizzazione della circolazione dei digital media per portare alla piena realizzazione dei benefici insiti nel processo di convergenza digitale e per fare dell’Italia un paese di riferimento nel settore.

Su questo documento si basano quattro documenti di richieste:

  1. Richiesta di piattaforma DRM e pagamento elettronico per sperimentazione

  2. Richiesta di proposte di tecnologie e soluzioni

  3. Richiesta di commenti alla governance dei sistemi dmin.it

  4. Richiesta di commenti agli interventi normativi

pubblicate il 15 marzo 2007 per la realizzazione del piano di lavoro dmin.it nel 2007. 

Indice

Executive summary................................................................................................................................. 3

Indice..................................................................................................................................................... 3

1      Introduzione.................................................................................................................................... 5

2      DRM interoperabile........................................................................................................................ 6

2.1          Obiettivi ed ambito............................................................................................................... 7

2.2          Requisiti............................................................................................................................... 7

2.2.1        Requisiti giuridici.............................................................................................................. 8

2.2.2        Requisiti tecnici................................................................................................................ 9

2.2.3        Le componenti base del sistema..................................................................................... 10

2.3          Processo di scelta della tecnologia...................................................................................... 11

2.4          Azioni normative................................................................................................................ 12

2.5          Governance....................................................................................................................... 13

2.5.1        Aspetti generali.............................................................................................................. 13

2.5.2        Aspetti giuridici.............................................................................................................. 14

2.5.3        Obiettivi del Trust Model di iDRM................................................................................. 14

2.5.4        Processo di certificazione............................................................................................... 15

2.5.5        Processo run-time legato al consumo di contenuti........................................................... 16

2.5.6        Schema legale/normativo/contrattuale............................................................................. 16

2.5.7        Considerazioni sugli economics di sistema...................................................................... 17

3      Accesso interoperabile alla rete a larga banda................................................................................ 18

3.1          Obiettivi ed ambito............................................................................................................. 18

3.2          Requisiti tecnici.................................................................................................................. 19

3.2.1        Accesso d’utente........................................................................................................... 19

3.2.2        Interfacce e protocolli tra operatori................................................................................ 19

3.3          Processo di scelta della tecnologia...................................................................................... 20

3.4          Azioni normative................................................................................................................ 20

3.5          Governance....................................................................................................................... 21

4      Sistemi di pagamento flessibili ed interoperabili............................................................................... 21

4.1          Obiettivi ed ambito............................................................................................................. 21

4.2          Requisiti............................................................................................................................. 22

4.2.1        Requisiti generali............................................................................................................ 22

4.2.2        Requisiti tecnici.............................................................................................................. 23

4.2.3        Le componenti base del sistema..................................................................................... 23

4.3          Processo di scelta della tecnologia...................................................................................... 24

4.4          Azioni normative................................................................................................................ 24

4.5          Governance....................................................................................................................... 24

4.5.1        Aspetti generali.............................................................................................................. 24

5      Bibliografia................................................................................................................................... 25

6      Terminologia................................................................................................................................. 25

Annex A – Contesto giuridico del DRM................................................................................................ 26

Annex B – Tecnologie per catene del valore.......................................................................................... 31

Annex C – Casi d'uso........................................................................................................................... 34

C.1         Distribuzione di contenuti non protetti.................................................................................. 34

C.2         Sistema di compensazione alternativo.................................................................................. 35

C.3         Distribuzione internet per tutti.............................................................................................. 36

C.4         Distribuzione su DTT.......................................................................................................... 37

C.5         Distribuzione su Satellite..................................................................................................... 37

C.6         IPTV................................................................................................................................. 38

C.7         WebTV............................................................................................................................. 38


1          Introduzione

Questo documento è stato preparato ed è pubblicato da Digital Media in Italia (dmin.it), un gruppo interdisciplinare, aperto e senza scopo di lucro che ha l’obiettivo di definire e proporre aree di intervento che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno globale “digital media” ed è la naturale continuazione del documento “Proposte di azione per dare all'Italia una posizione leader nei digital media” pubblicato 15 settembre 2006 [1].

In tale documento dmin.it identificava tre aree su cui è necessario operare, in modo coordinato, per favorire il raggiungimento degli obiettivi di dmin.it: i servizi di produzione, distribuzione e consumo di contenuti, i servizi di rete a larga banda ed i servizi di pagamento indicando, per ognuna delle aree, specifiche linee di azione, individuando i necessari aspetti tecnologici, economici e normativi, ed analizzando infine i vantaggi che ne conseguirebbero per la comunità nazionale.

In questo documento sono invece raccolte:

  1. Le specifiche funzionali

  2. I sistemi di governance

  3. Gli interventi normativi

richiesti per rendere concretamente realizzabili le tre proposte di sistemi iDRM, dell’accesso alla rete a larga banda e di pagamento.

Su questo documento si basano le seguenti richieste pubblicate il 15 marzo 2007:

  1. Richiesta di piattaforma DRM e pagamento elettronico, avente per obiettivo di rendere disponibile alla comunità dmin.it una o più piattaforme per sperimentare le opportunità offerte da piattaforme iDRM e pagamento elettronico di e valutarne gli eventuali vincoli;

  2. Richiesta di proposte di tecnologie e soluzioni da utilizzare da parte della comunità dmin.it per specificare e rendere disponibili in software aperto (Open Source Software) le tecnologie necessarie per realizzare i tre sistemi dmin.it delineati nella proposta [1];

  3. Richiesta di commenti alla governance dei sistemi dmin.it

  4. Richiesta di commenti agli interventi normativi

È opportuno notare che la realizzazione in software aperto non deve essere pensata come una realizzazione di un sistema iDRM completo ma solo come realizzazione della parte che permette di esercitare le specifiche.

La tabella qua sotto contiene la roadmap che dmin.it intende seguire per giungere a pubblicare, il 15 dicembre 2007:

Nella tabella sottostante le date sono indicative, salvo la data finale che è tassativa

Tab. 1 – Roadmap per la realizzazione delle proposte dmin.it

aaaa

mm

gg

Milestone

 

mar

15

  • Approvazione e pubblicazione sul sito dmin.it delle “Specifiche funzionali, azioni normative e governance per la realizzazione della proposta dmin.it”

  • Emissione di

  • Richiesta di piattaforma sperimentale (mock up) con

  • Funzionalità iDRM

  • Sistemi di pagamento flessibili ed interoperabili secondo l’approccio dmin.it

  • Richiesta di tecnologie/soluzioni

  • Richiesta di commenti su regole di governance

  • Richiesta di commenti e proposte di azione normativa

 

apr

30

Messa a disposizione della comunità dmin.it di uno (eventualmente più di uno) mock up idealmente funzionanti su PC, set top box, PDA ecc.

 

mag

31

Raccolta delle risposte alla

  • Richiesta di tecnologie/soluzioni

  • Richiesta di commenti su regole di governance

  • Richiesta di commenti su e proposte di azione normativa

 

giu

15

Presentazione e valutazione delle proposte tecniche

 

giu

30

Inizio redazione specifiche tecniche

 

lug

31

Ulteriore emissione di

  • Richiesta di commenti su sistemi di governance

  • Richiesta di commenti su e proposte di azione normativa

 

set

30

Raccolta delle risposte alle ulteriori richieste del 21 luglio

  • Richiesta di commenti su sistemi di governance

  • Richiesta di commenti/proposte di azione normativa

 

dic

15

Pubblicazione di

  • Specifiche tecniche, inclusi i test di conformità

  • Sistemi di governance

  • Intenventi normativi

 

2          DRM interoperabile

Con la specifica di un sistema DRM interoperabile (iDRM) dmin.it persegue l’obiettivo di creare un mercato che copre l’intera comunità nazionale in cui

  1. Chi crea contenuti abbia gli strumenti per accedere a forme di distribuzione in modo controllato con bassa soglia di accesso con la speranza di ottenerne eventualmente un beneficio

  2. Chi si trova all’altro estremo delle catene del valore abbia la possibilità di accedere a qualsiasi contenuto pubblicato in Italia utilizzando un dispositivo di consumo disponibile sul libero mercato

  3. Chi svolge un ruolo di intermediazione possa attuarlo sulla base di specifiche pubbliche di accesso alla catena del valore.

Per raggiungere questo obiettivo dmin.it definisce le specifiche tecniche, le caratteristiche operative del sistema di governance e le possibili azioni normative che sono necessarie per rendere operative le piattaforme tecnologiche che consentano a coloro che operano in Italia di creare, far funzionare e partecipare a catene del valore di digital media che permettono l’accesso ai servizi e l’uso dei contenuti di tali catene mediante apparati realizzabili a partire da specifiche pubbliche e quindi disponibili agli acquirenti sul mercato aperto.

2.1        Obiettivi ed ambito

L’iDRM perseguito da dmin.it deve possedere le seguenti caratteristiche: 

  1. Specificato compiutamente e pubblicato

  1. Capace di supportare i più diversi modelli di business

  1. Adottato a livello nazionale dall'autorità pubblica

  2. Realizzabile da chiunque

  3. Con possibilità da parte di chiunque di

2.2        Requisiti

La specifica iDRM non è la specifica di una soluzione DRM per un particolare problema, ma deve permettere l’interoperabilità tra realizzazioni diverse della specifica iDRM 

  1. In un dato ambito (ad esempio in un contesto di IPTV)

  2. Idealmente fra ambiti diversi (internet, broadcasting digitale, mobile, ecc.).

 Con il punto 2. si intende, ad esempio, la possibilità tecnica di spostare sul proprio terminale di TV mobile un programma registrato su un hard disk dopo essere stato ricevuto da un canale televisivo. La possibilità legale naturalmente dipende dal fatto che si abbiano o si siano acquisiti i permessi per farlo.

 In questa sezione sono dati i requisiti generali di natura giuridica e tecnica che sottendono la specifica iDRM. Si consiglia anche la lettura dell’allegato A che inquadra in modo più generale la tematica del contesto giurico del DRM e dell’Allegato B che dà una sommaria descrizione delle funzionalità e delle principali tecnologie richieste da una catena del valore realizzata secondo la modalità iDRM.

2.2.1        Requisiti giuridici

Tra i benefici attesi dall’adozione del sistema iDRM vi è il ripristino di un miglior clima di fiducia tra imprese e consumatori e la maggiore efficienza del mercato. L’interoperabilità di per sé moltiplica le possibilità di accesso e fruizione dei digital media gestiti mediante DRM. Tuttavia, l’interoperabilità non è da sola sufficiente. Occorre che la concorrenza tra diverse tecnologie che concorrono a formare l’iDRM possa instaurarsi anche su parametri attinenti alla “qualità giuridica” (in particolare, il rispetto dei diritti e degli interessi degli utenti finali). In un contesto in cui gli utenti di digital media possono scegliere DRM con restrizioni tecnologiche di livello commensurabile agli obiettivi da raggiungere, processi di negoziazione trasparenti e bidirezionali (cioè capaci di allargare il ventaglio delle scelte dell’utente rispetto al “prendere o lasciare” tipico della contrattazione standardizzata), nonché un monitoraggio della fruizione meno invasivo della privacy, il mercato potrebbe essere orientato verso una concorrenza virtuosa nella quale accanto al prezzo e ad altri parametri qualitativi figuri la “qualità giuridica” del DRM.

A questo scopo, coloro che intendono rispondere alla richiesta di soluzioni iDRM devono tener conto dei requisiti di natura giuridica più oltre esposti in quanto la conformità ai principi delle soluzioni e delle tecnologie proposte è uno dei presupposti per la loro accettazione ed introduzione nello standard iDRM.

I sistemi di DRM si fondano su linguaggi denominati Rights Expression Languages (RELs) i quali sono deputati ad esprimere in linguaggio comprensibile al computer i permessi e le condizioni relativi  all’utilizzo di un contento (se esso può essere copiato, stampato, ridistribuito ecc., dove e con quali dispositivi può essere fruito, ecc.). Lo stato attuale di queste tecnologie non consente di incorporare nel REL l’elasticità (e l’ambiguità) tipica di un principio di diritto (ad esempio, il principio secondo cui il diritto d’autore protegge solo l’opera creativa, o quello in base al quale il diritto d’autore protegge solo la forma in cui è espressa l’opera dell’ingegno e non l’idea che vi è racchiusa). Al massimo è possibile tradurre in linguaggio informatico regole giuridiche (rudimentali) di dettaglio. Il che, peraltro, pone l’ulteriore problema di dover scegliere un sistema giuridico territorialmente limitato (per ipotesi, copyright statunitense o diritto d’autore italiano?), per porre regole tecnologiche a vocazione globale (i digital media, più di altri beni, sono destinati a viaggiare attraverso le frontiere statali). Inoltre, i computer sono capaci solo di interpretazioni univoche delle regole espresse in REL, mentre gli attori del diritto (uomini) interagiscono in base ad interpretazioni plurime (spesso contrastanti) dei principi giuridici.

 Dunque, la strada di una valutazione preventiva della conformità delle tecnologie ai principi appare obbligata (anche se nient’affatto agevole). Pertanto si vogliono stimolare proposte che sfruttino i margini di plasmabilità della tecnologia DRM al fine di incentivare l’incorporazione nell’iDRM di regole e processi di negoziazione orientati agli interessi degli utenti. Ad esempio, i principi che incentivano l’incorporazione nel DRM di procedure che rendano gestibile (almeno parzialmente) per via tecnologica la fruizione di eccezioni e limitazioni (come quella attinente alla copia privata) al diritto d’autore.

 Nel seguito sono dati alcuni principi giuridici (indicati con RG) che una proposta di tecnologia o soluzione DRM deve soddisfare per poter essere considerata

RG 1 Rispetto delle libertà fondamentali, del diritto alla riservatezza e del diritto alla protezione dei dati personali

  1. La soluzione e le tecnologie iDRM proposte devono rispettare le libertà fondamentali garantite dalla Costituzione ad esempio la riservatezza ed il diritto alla protezione dei dati personali.

  2. La soluzione e le tecnologie iDRM proposte devono richiedere il minimo uso di dati personali e di dati identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune modalità che permettano di identificare l’interessato solo in caso di necessità.

  3. La soluzione e le tecnologie iDRM proposte devono permettere che un utilizzatore possa permettere l’utilizzo, eventualmente contro contropartita, di alcuni dei propri dati, nel rispetto delle norme del d.lgs. 30 giugno 2003 n. 196, codice in materia di protezione dei dati personali.

RG 2 Atti negoziali

  1. La soluzione e le tecnologie iDRM proposte devono essere dotate di funzionalità che consentono all’utente di compiere atti negoziali attraverso le componenti poste sotto il controllo dell’utente medesimo

RG 3 Misure tecnologiche di protezione

  1. La soluzione e le tecnologie iDRM proposte devono:

  2. Essere conformi alle norme europee ed italiane;

  3. Incorporare funzionalità che consentano all’utente di fruire delle eccezioni o limitazioni al diritto d’autore ed ai diritti connessi con riguardo ai contenuti digitali che ricadono nell’ambito di applicazione della legge 22 aprile 1941 n. 633, protezione del diritto d'autore e di altri diritti connessi al suo esercizio;

  4. Incorporare funzionalità che consentano all’utente di poter essere costantemente informato sul funzionamento delle medesime misure tecnologiche di protezione e sul loro eventuale aggiornamento;

  5. Ridurre al minimo i rischi attinenti alla sicurezza dei sistemi informativi di operatori ed utenti;

  6. Consentire di escludere le misure tecnologiche di protezione ove l’attore della catena del valore che distribuisca digital media mediante iDRM non intenda applicarle ovvero la legge non ne preveda l’applicazione.

RG 4 Funzionalità di disattivazione

  1. Le tecnologie iDRM devono essere dotate di funzionalità che consentano all’utente di poter in ogni momento disattivare e rimuovere legittimamente le componenti iDRM installate sul proprio dispositivo, eventualmente al costo di non più poter fruire i contenuti gestiti mediante quelle particolari componenti o, al limite, con conseguenze sul piano contrattuale, cioè inadempimento, ma mai l’impossibilità “fisica” di disinstallare quel che si è precedentemente installato sul proprio dispositivo.

2.2.2        Requisiti tecnici

La soluzione e le tecnologie iDRM proposte devono inoltre soddisfare i seguenti requisiti, generali e funzionali, di tipo tecnico, indicati con RT.

RT 1 Requisiti generali

La soluzione e le tecnologie iDRM proposte devono permettere

  1. La realizzazione di catene del valore che implementano una vasta gamma di modelli di business, ad esempio quelli dell’Annesso C

  2. L’utilizzazione della stessa tecnologia, eventualmente aumentata o diminuita, per

  1. Lutilizzazione delle sole funzionalità richieste da una data catena del valore

  2. L’aggiunta di nuove funzionalità nel caso in cui queste siano richieste da nuove catene del valore

RT 2 Requisiti funzionali

La soluzione e le tecnologie iDRM proposte devono permettere

  1. L’espressione unitaria e flessibile dei vari dati che si riferiscono ad una data risorsa (identificativi, metadati, licenze, informazione usata dal sistema iDRM ecc.)

  2. L’identificazione delle varie entità (dati di cui al punto 1., dispositivi, utenti ecc.) che sono utilizzate in una catena del valore

  3. L’autenticazione (cioè la dimostrazione dell’identità) e la gestione (e.g. rinnovo certificati) dei dispositivi usati nelle catene del valore

  4. L’espressione in un linguaggio interpretabile da una macchina

  1. L’ottenimento da parte di un dispositivo del codice necessario per eseguire una data funzionalità (ed esempio un algoritmo di cifratura)

  2. La gestione di gruppi di dispositivi e di utenti (domini)

  3. La possibilità per due attori di una catena del valore di negoziare i termini delle licenze che essi possono scambiare (ad esempio contenuto contro dati d’uso)

  4. La comunicazione tra dispositivi in una catena del valore mediante opportuni protocolli.

2.2.3        Le componenti base del sistema

Una qualsiasi catena del valore ha bisogno di dispositivi per permettono agli utenti della catena del valore di svolgere il proprio ruolo. Seppur con funzionalità talvolta un po’ diverse a seconda della catena del valore, i seguenti dispositivi sono in genere richiesti

  1. Dispositivo per generare contenuti e licenze

  2. Dispositivo per registrare le varie entità (contenuti, dispositivi, utenti) che sono utilizzate in una catena del valore

  3. Dispositivo che distribuisce licenze

  4. Dispositivo che distribuisce codice eseguibile iDRM

  5. Dispositivo per gestire gruppi di dispositivi o di utenti (domini)

  6. Dispositivo per fruire di contenuti iDRM

La figura sottostante rappresenta le relazioni tra i vari dispositivi in una catena del valore

Fig. 1 – Dispositivi in una catena del valore

Nella figura

  1. I dispositivi di colore giallo hanno la funzione di dare un identitificativo a dispositivi o contenuti

  2. Il dispositivo di colore blu è utilizzato per creare le strutture dati che accompagnano le risorse

  3. I dispositivi di colore verde hanno la funzionalità di fornire i tipi diversi di dati

  4. I dispositivi di colore rosso sono dispositivi per il consumo dei contenuti

  5. Il dispositivo di colore viola serve per la gestione dei domini

  6. Il dispositivo di color porpora è un dispositivo non secondo la specifica iDRM.

2.3        Processo di scelta della tecnologia

iDRM richiede specifiche scelte tecnologiche. Trattandosi di tecnologie che saranno alla fine recepite in processi normativi nazionali è essenziale che il processo di scelta sia assolutamente aperto ed equo  per tutti i partecipanti e che il risultato sia utile.

In linea con l’approccio utilizzato da molti organismi di normalizzazione, il processo di scelta delle tecnologie che verranno a far parte della specifica iDRM sarà basato sul seguente processo:

Emissione di un bando in cui si richieda a chiunque disponga di tecnologie ritenute adatte per la specifica iDRM con i requisiti di cui ai punti 2.2 sopra di proporle

Valutazione delle proposte da parte di una commissione di esperti costituita con regole da definire

Scelta delle tecnologie/soluzioni fatta analizzando la rispondenza ai seguenti requisiti

  1. Livello di flessibilità. Capacità delle tecnologie/soluzioni di supportare

  1. Livello di completezza. Questo criterio è ispirato dal fatto che il lavoro richiesto per l’integrazione delle tecnologie ed il tempo richiesto per assicurare un livello sufficiente di fiducia nelle specifiche così integrate scoraggeranno l’adozione di tecnologie “isolate”, cioè non parte di una soluzione “completa”, quando invece una soluzione completa esista.

  2. Livello di apertura. Questo criterio intende verificare che le tecnologie/soluzioni proposte non abbiano dei “buchi neri” in cui conoscenze richieste per la realizzazione sono in realtà trattenute dal proponente. Al proponente sarà quindi richiesto di fornire una dichiarazione in tal senso. Se la dichiarazione si rivelerà non fedele le eventuali tecnologie/soluzioni proposte ed accettate saranno escluse.

  3. Realizzazione open source. Questo criterio è, in parte, una risposta al punto precedente in quanto se le tecnologie/soluzioni sono realizzate in software aperto si può controllare che tutto quanto serve per una realizzazione è effettivamente stato fornito. Il codice associato ad una proposta, con una licenza “business friendly” giudicata accettabile dalla commissione esaminatrice dovrà essere fornito dal proponente entro un tempo stabilito dalla commissione stessa.

  4. Natura delle tecnologie. Questo criterio serve a valutare se le tecnologie/soluzioni sono “aperte” nel senso che sono già parte di uno standard, sia de jure che de facto, oppure se siano chiuse. È chiaro che il primo caso è preferibile in quanto si è di fronte ad un risultato di un processo che ha visto la partecipazione aperta di più attori, ma il secondo caso è a priori ammissibile, ovviamente a patto che siano soddisfatte tutte le altre condizioni con la garanzia che il risultato finale porti dell’apertura della tecnologia attraverso la specifica iDRM.

  5. Situazione brevettuale. La situazione più desiderabile è ovviamente quella in cui le tecnologie/soluzioni siano prive di proprietà intellettuale, ma è a priori ammissibile che sia richiesto l’uso di brevetti, ovviamente alle condizioni del punto successivo.

  6. Condizioni di licensing (se richiesto). Questo criterio si articola nei due casi seguenti

  1. Livello di assistenza. Questo criterio si riferisce alla disponibilità da parte del proponente di assistere eventuali realizzatori nella comprensione delle tecnologie/soluzioni nelle prime fasi dell’utilizzo della tecnologia una volta accettata.

Integrazione delle tecnologie in una specifica completa. Questo verrà attuato nella seconda metà dell’anno 2007.

2.4        Azioni normative

dmin.it propone che un operatore che sia titolare di diritti nella distribuzione dei contenuti in una catena del valore debba supportare la tecnologia iDRM senza l'obbligo di replicare il modello di business che l’operatore usi per un'eventuale tecnologia DRM proprietaria (pDRM), purché l'offerta con iDRM non sia discriminatoria nei confronti dell'offerta con pDRM. Le seguenti azioni normative sono quindi richieste

Gli obblighi dell’uso dell’iDRM si applicano agli attori della catena del valore che operano sui contenuti. Gli obblighi di uso dell’iDRM offerto come servizio aggiuntivo al trasporto ad una terza parte, si estendono anche a chi trasporta i contenuti, se in posizione dominante

I contenuti a cui si applica l’azione normativa sono

  1. Coperti da diritto d’autore

  2. Coperti da diritti connessi (e.g. alcune trasmissioni radio e TV)

  3. Non normati (e.g. foto private)

  4. Della pubblica amministrazione

Il legame tra gli attori di una catena del valore è dato da un contratto

Un operatore che sia titolare di diritti di messa a disposizione dei contenuti in un punto della catena del valore deve supportare la tecnologia iDRM, senza l'obbligo di replicare il modello di business che l’operatore usi per un'eventuale tecnologia pDRM, purché l'offerta con iDRM non sia discriminata dall'offerta con tecnologia pDRM

I sistemi di delivery a cui si applica l’azione normativa sono

  1. Canali radio broadcast per bande terrestre e satellite

  2. Rete fissa di telecomunicazioni

  3. Cavo coassiale

  4. Rete telefonica mobile

  5. IP su radio (WiFI ec..)

2.5        Governance

La governance del sistema iDRM ha il compito di garantire che il sistema sia amministrato nell’interesse di tutte le parti coinvolte.

2.5.1        Aspetti generali

La governance parte dal presupposto che esista una specifica iDRM con le seguenti caratteristiche

La specifica iDRM è sviluppata

a.       In risposta ad una richiesta a cui tutti hanno potuto rispondere

b.      In un contesto aperto

c.       Sulla base di criteri dichiarati a priori, in particolare

                                 i.        La tecnologie necessarie per realizzare la specifica iDRM devono essere, nell’ordine

  1. Libere da proprietà intellettuale di altri

  2. Utilizzabili senza pagamento di royalty

  3. Utilizzabili a condizioni “giuste, ragionevoli e non discriminatorie” (FRAND)

La specifica iDRM è disponibile

a.       In forma testuale

b.      Sotto forma di codice sorgente aperto (Open Source Software) utilizzabile anche per scopi commerciali con una licenza “business friendly” (ad esempio Mozilla)

La specifica iDRM in forma testuale e la specifica iDRM in forma di codice sorgente sono funzionalmente equivalenti

La specifica iDRM contiene gli strumenti per verificare che una data realizzazione è conforme alla specifica iDRM

La specifica iDRM è adottata dall’autorità pubblica che ne determina gli obblighi d’uso

La specifica iDRM è gestita da un sistema di governance che, tra l’altro,

a.       Ha il compito di rendere la specifica iDRM pubblicamente disponibile

b.      Gestisce l’evoluzione della specifica iDRM per

                                 i.            Correggere eventuali errori

                               ii.            Tener conto di nuovi requisiti

                              iii.            Restare competitiva nei confronti dell’evoluzione tecnologica

c.       Promuove l’adozione di nuove versioni della specifica iDRM da parte dell’autorità pubblica

d.      Funge da punto di raccolta delle condizioni di licenza delle tecnologie di cui sono disponibili solo licenze a condizioni FRAND

2.5.2        Aspetti giuridici

Qualora rilevanti il sistema di governance deve sostenere i seguenti principi

  1. La certificazione di realizzazioni dello standard iDRM è subordinata alla valutazione di conformità ai principi giuridici.

  2. Le informazioni sul funzionamento delle tecnologie iDRM sono pubblicate, in una forma comprensibile ad un utente di medie abilità informatiche su un sito Web agevolemente accessibile a chiunque ed indipendenti dal sistema operativo/piattaforma adottato dall’utente

  3. L’utente di tecnologie iDRM deve poter agevolmente accedere alle informazioni di cui al punto 2.

  4. Le informazioni di cui al punto 2. sono rese, mediante apposite tecnologie, agevolmente accessibili a utenti diversamente abili.

  5. Ogni licenza gestita da un sistema iDRM deve essere resa disponibile all’utente del dital media al quale è associata la medesima licenza anche in lingua italiana.

2.5.3        Obiettivi del Trust Model di iDRM

Il sistema di governance del sistema iDRM necessita di un Trust Model per far sì che ogni attore della catena del valore, ed in particolare un produttore/fornitore di contenuti, sia convinto che tutti gli altri attori, ad esempio fornitori di servizio, produttori di dispositivi, fornitori di tecnologie di sicurezza ecc. sono affidabili come business partner, e quindi invogliarlo a far sì che i loro contenuti digitali siano disponibili al mercato, che altrimenti non esisterebbe senza contenuti. Questo non solo per i grandi fornitori di contenuti, ma anche in modo specifico i piccoli content provider ed i prosumer, che sono il nuovo mercato che si può aprire in Italia grazie all’iDRM.

Da questo discende la necessità che il Trust Model sia articolato in modo da rendere fattibili tecnicamente e sostenibili economicamente cicli di business molto diversi fra loro. Si può pensare infatti di avere livelli diversi di “sicurezza di sistema” a cui corrispondono in generale costi implementativi diversi, adatti ai diversi segmenti di mercato, e che sono tenuti a rispettare rigorosamente un principio di gerarchie di livello, nel senso che eventuali semplificazioni introdotte ai livelli meno critici non possano in alcun modo costituire una minaccia per la sicurezza dei livelli più sensibili. Ciò si potrebbe tradurre nel vincolo realizzativo per cui un dispositivo che ottempera ai requisiti di un livello di sicurezza inferiore non può accedere a contenuti per i quali sia richiesto possedere carattertistiche più stringenti. Tali contenuti potranno naturalmente essere fruibili su dispositivi di livello di sicurezza superiore.

Evidentemente questo requisito, oltre ad avere un impatto sull’aspetto tecnologico del problema risulta essere soprattutto un problema di contrattualistica e di gestione degli oneri economico-implementativi a carico dei singoli attori, gestione che deve essere adatta o adattabile ai diversi contesti. Infatti i costi di ingresso e permanenza nell’ecosistema devono essere costruiti in modo tale da rendere percorribile un cammino di ingresso nel business anche da parte del piccolo produttore/fornitore di servizio, e non costituire una barriera tale da consentire l’ingresso nel mercato solo ai grandi attori.

Il Trust Model di iDRM si organizza attorno a tre componenti base:

  1. Il processo di accettazione ed integrazione nel sistema iDRM di qualunque dispositivo gestisca i contenuti o le licenze

  2. Il processo run-time legato al comportamento dei dispositivi legati al consumo di contenuti, che riguarda principalmente la verifica delle licenze e la gestione delle anomalie riscontrate nei dispositivi, con tutti i livelli di escalation necessari

  3. Lo schema legale/normativo/contrattuale che lega i diversi attori fra di loro, attribuisce le responsabilità e garantisce il sistema nei confronti dei danni che possono derivare da comportamenti “malicious” di clienti finali e di attori stessi.

Di queste tre componenti vanno definiti:

2.5.4        Processo di certificazione

L’accettazione ed integrazione nel sistema iDRM di un dispositivo (hardware o software) si basa sul seguente processo:

2.5.5        Processo run-time legato al consumo di contenuti

Il processo run-time legato al consumo di contenuti, che riguarda principalmente la verifica delle licenze e la gestione delle anomalie riscontrate, con tutti i livelli di escalation necessari deve tener conto dei seguenti elementi:

2.5.6        Schema legale/normativo/contrattuale

Lo schema è basato sui seguenti punti:

Lo schema di riferimento che si configura fra i diversi soggetti è quindi il seguente:

 

Fig. 2 – Modello di Riferimento del Trust Model di iDRM

2.5.7        Considerazioni sugli economics di sistema

L’Autorità Centrale (AC) è una organizzazione “no profit”, costituita con un capitale iniziale che deriva dal versamento dei soci fondatori, il cui funzionamento si basa su un meccanismo di ricopertura dei costi. Per condurre le verifiche tecniche necessarie per il funzionamento del sistema iDRM, AC organizzerà un proprio Laboratorio Accreditato di certificazione (LA) interno. Il “costo” della singola istanza del certificato di conformità è determinato da LA ed approvato da AC sulla base del principio di ricopertura costi, fatto a livello di bilancio da un anno all’altro. Il processo, che deve essere in grado di supportare una eventuale espansione del numero dei LA che operano per la AC, potrà essere oggetto di ulteriore studio nel corso dello sviluppo dell’iniziativa.

Il sistema di sicurezza garantito dalla AC deve rispondere a requisiti di affidabilità in grado di soddisfare sia i più esigenti fornitori di Contenuti Premium, con inevitabili costi implementativi di un certo rilievo, e sia fornitori di contenuti anche di dimensioni contenute, fino al profilo prosumer. È necessario pertanto che la governance del sistema iDRM sia progettata per essere in grado di differenziare gli impegni economici a carico dei diversi soggetti in funzione del livello di sicurezza che gli aventi diritto desiderano garantire per i propri prodotti, al fine di garantire un adeguata possibilità di sviluppo anche al mercato dei piccoli produttori.

La figura successiva indica a titolo di esempio un possibile schema dei flussi che intercorrono fra gli attori in relazione alle dipendenze di responsabilità (frecce nere) e relativi corsi economici che possono svilupparsi in caso di effrazione del sistema.

Fig. 3 – Possibile schema dei flussi fra operatori nel sistema iDRM

3          Accesso interoperabile alla rete a larga banda

3.1        Obiettivi ed ambito

Dmin.it prevede la più ampia libertà per un operatore di rete a larga banda di offrire accesso bundled e/o unbundled alla sua rete con caratteristiche tecniche di sua scelta contemperato dal diritto di un “utente” della rete che può essere sia un fornitore di contenuti, sia un intermediario e sia un utente finale di richiedere ed ottenere da un operatore di rete a larga banda il puro accesso “service-agnostic” alla "big Internet“ con le caratteristiche tecniche già offerte dall’operatore a condizioni non discriminatorie nei confronti delle altre offerte dell’operatore.

Inoltre gli operatori di rete a larga banda devono garantire l’interoperabilità dei servizi di rete concordando e fornendo specifici livelli di qualità di servizio (QoS) ai punti di peering così da fornire agli utenti della rete opportuni livelli di QoS.

3.2        Requisiti tecnici

3.2.1        Accesso d’utente

Requisiti essenziali di servizio di accesso a “big Internet”, “service agnostic sono:

  1. Assegnazione statica o dinamica di almeno un indirizzo IP “pubblico”;

  2. Nessuna limitazione sul numero di port numbers (TCP, UDP) utilizzabili;

  3. Nessun filtraggio selettivo del traffico su base:

Inoltre sono servizi indispensabili:

  1. Risoluzione dei nomi (DNS);

  2. Mail forwarding (SMTP).

Allo stato attuale non viene presa in considerazione la compatibilità con IPv6.

Requisiti opzionali sono funzionalità di:

  1. Accesso “premium” per specifiche direttrici di traffico;

  2. Multicast e/o streaming (con controllo della banda utilizzata e prioritizzazione del traffico)

3.2.2        Interfacce e protocolli tra operatori

Per quanto riguarda il peering, la specifica BGP-4 definisce in dettaglio come devono comportarsi gli operatori al punto di interconnessione, sia questo di tipo 1:1 sia di tipo NxN. La pubblicazione delle policy di peering adottate, ad esempio nel Data Base mantenuto da RIPE-NCC per quanto riguarda l’Europa, è garanzia di ulteriore trasparenza, nonché strumento utile per la manutenzione delle reti.

Qualora l’operatore offra servizi con QoS, area ancora non consolidata, lungo la catena end-to-end devono essere soddisfatti i seguenti requisiti:

  1. Più classi di servizio in numero prefissato (in dipendenza dalla tecnologia adottata);

  2. Mantenimento dei livelli di servizio previsti da ogni classe lungo tutta la catena, dal nodo sorgente al nodo destinazione;

  3. Equivalenza delle classi di servizio di ogni operatore alla frontiera di peering;

  4. Uniformità di QoS per il traffico di una classe di servizio, indipendentemente dalle caratteristiche del traffico (indirizzi sorgente/destinazione, port number, applicazione);

  5. Responsabilità del controllo di flusso al nodo sorgente.

 Inoltre devono essere specificati i Service Level Agreement (SLA) che gli operatori sottoscrivono al fine di rendere interoperabili i loro servizi di QoS. Tali SLA potranno essere diversi nel caso di

  1. Peering “privato”, cioè attraverso un collegamento diretto;

  2. Peering “pubblico”, cioè realizzato presso un Network Access Point (NAP).

3.3        Processo di scelta della tecnologia

Per quanto riguarda il servizio di base, accesso ad Internet, esistono standard aperti consolidati da tempo, mentre per quanto riguarda il peering tra operatori, esistono standard aperti che sono stati aggiornati più volte sulla base delle esperienze concrete nelle configurazioni più complesse. Sebbene non ottimale (il controllo del routing asimmetrico è ancora gestito in modo euristico) non è proponibile, né necessario, ipotizzare scelte tecnologiche diverse.

Non esiste invece una tecnologia consolidata per quanto riguarda l’interoperabilità dei servizi di QoS tra operatori. Allo stato attuale i servizi di trasporto con QoS garantita sono realizzati solo all’interno del dominio amministrativo di un operatore.

In ambito IETF sono stati specificate alcuni protocolli specifici per la realizazione di servizi di trasporto su IP con QoS garantita (ad esempio DiffServ, IntServ o Label Switching). Oggetto del processo di scelta della tecnologia è l’estensione di uno di questi all’interconnessione tra operatori.

Il processo di scelta dovrà essere realizzato secondo queste linee:

  1. Costituzione del gruppo di valutazione

  2. Formalizzazione delle specifiche ottimali richieste

  3. Scelta della tecnologia considerando:

3.4        Azioni normative

Le azioni normative dovranno coprire i seguenti aspetti:

Offerta non discriminatoria

Obblighi di peering

Misurazioni

Autoregolamentazione

3.5         Governance

Il sistema di accesso aperto richiede che sia definita una governance. Occorre quindi specificarne

4          Sistemi di pagamento flessibili ed interoperabili

4.1        Obiettivi ed ambito

dmin.it prevede che un operatore, compatibilmente con le norme bancarie, possa offrire servizi di “account”, interoperabili con i servizi offerti da altri operatori, che non siano direttamente monetari (quindi sotto forma di punti, crediti ecc.) per transazioni collegate all’uso di digital media. Le transazioni sono effettuate tra “account” in cui ogni “account” si appoggia su uno o più strumenti di pagamento ad incasso garantito, ad esempio conto corrente, carta di credito, carta prepagata, domiciliazione bancaria, borsellino elettronico ecc. Per diminuire i costi la sincronizzazione di un “account” con il suo circuito di appoggio non è effettuata ad ogni transazione ma su base periodica oppure a richiesta

Finalità ultima della proposta di servizi di pagamento è di allargare l'accesso dei sistemi di pagamento online alla fascia giovane della popolazione residente in Italia che, pur rappresentando il target principale dei digital media, rimane esclusa dall'uso dei tradizionali sistemi di pagamento online e risulta, invece, implicitamente incentivata a fruire di servizi, quasi mai legali, di downloding da reti p2p.

4.2        Requisiti

4.2.1        Requisiti generali

I servizi di pagamento devono soddisfare i seguenti requisiti:

Facilmente accessibili alla fascia giovane della popolazione

a.       Disponibilità di account virtuali appoggiati a sistemi tradizionali di pagamento e/o incassi definibili e gestibili dai legittimi intestatari (p.e. genitori);

b.      Uso di unità di valore non direttamente monetaria (p.e. punti, credits);

c.       Convertibilità in euro su base periodica dei saldi positivi e negativi degli account espressi in unità non monetaria sui sottostanti sistemi di pagamento e/o incassi;

Senza garanzie bancarie

a.       Gli eventuali insoluti al momento della conversione dei saldi negativi da unità non monetaria ad euro non devono richiedere garanzie bancarie;

b.      Annullabilità degli acquisti di digital media il cui pagamento sia rimasto insoluto;

c.       Disponibilità di servizi centralizzati di segnalazione di frodi/insoluti;

Capace di supportare qualsivoglia modello di business, in particolare

a.       Il valore dei digital media è riconosciuto dagli inserzionisti pubblicitari;

b.      Il valore dei digital media è riconosciuto dagli utenti;

c.       Il valore dei digital media è riconosciuto con un sistema ACS (Alternative Compensation System);

d.      Il valore dei digital media è riconosciuto attraverso una qualsiasi modulazione dei tre precedenti modelli di business;

Capace di supportare qualsivoglia attore di qualsiasi catena del valore

a.       Creatori/produttori

b.      Intermediari

c.       Utenti finali/consumatori

Adottati a livello nazionale dall'autorità pubblica ed integrato con iDRM e con l’accesso alla ed uso della rete a larga banda

Realizzabili ed erogabili da chiunque soddisfi i requisiti normativi e di legge

Con possibilità da parte di chiunque di

a.       Ottenere certificazione di conformità dei servizi di pagamento

b.      Erogare servizi di pagamento certificati a terze parti.

4.2.2        Requisiti tecnici

La soluzione e le tecnologie proposte devono contenere:

La definizione e l'identificazione univoca di tutti gli attori coinvolti nelle varie catene del valore:

a.       Persone fisiche: consumatori/utenti finali

b.      Persone giuridiche:  creatori, intermediari

c.       Erogatori dei servizi di pagamento o VASP (Virtual Account Service Provider)

d.      Erogatori di servizi comuni: servizi di utilità comune all'intero sistema (p.e. servizi di segnalazione di frodi ed insoluti all'interno del sistema)

La definizione di virtual account

a.       Ogni persona fisica/giuridica può essere l'intestatario di uno o più virtual account erogati da uno o più VASP

b.      I virtual account si appoggiano a sistemi tradizionali di pagamento e/o incasso

c.       Più virtual account possono appoggiarsi allo stesso sistema di pagamento e/o incasso di appoggio

La definizione delle disposizione di pagamento e di incasso

a.       Ogni virtual account può ricevere/emettere pagamenti/incassi destinati/provenienti da altri virtual account

La specifica dei protocolli e delle strutture dati scambiati tra gli attori del sistema di pagamento

4.2.3        Le componenti base del sistema

Lo schema di riferimento del sistema di pagamento di dmin.it è rappresentato dalla Fig. 4.

Fig. 4 – Uno schema di riferimento del sistema di pagamento

Nella figura l’utente 1 offre contenuti che l’utente 2 è interessato ad acquistare. Terminata la fase di negoziazione l’utente 2 chiede al proprio fornitore di servizi di account 2 di accreditare l’ammontare convenuto di “punti” all’utente 1 via il fornitore di servizi di account 1 dell’utente 1.

Alla fine del mese (ad esempio) l’utente 1 chiede al proprio fornitore di servizi di account 1 di sincronizzare il suo account con, ad esempio, il proprio conto corrente.

4.3        Processo di scelta della tecnologia

Il processo di scelta dovrà essere realizzato secondo queste linee:

  1. Costituzione del gruppo di valutazione

  2. Formalizzazione delle specifiche ottimali richieste

  3. Scelta della tecnologia considerando:

4.4        Azioni normative

Le azioni normative sono ancora in conrso di studio.

4.5        Governance

La governance del sistema iDRM ha il compito di garantire che il sistema sia amministrato nell’interesse di tutte le parti coinvolte.

4.5.1        Aspetti generali

La governance parte dal presupposto che esista una specifica iDRM con le seguenti caratteristiche

La specifica è sviluppata

a.       In risposta ad una richiesta a cui tutti hanno potuto rispondere

b.      In un contesto aperto

c.       Sulla base di criteri dichiarati a priori, in particolare

                                 i.        La tecnologie necessarie per realizzare la specifica devono essere, nell’ordine

Libere da proprietà intellettuale di altri

Utilizzabili senza pagamento di royalty

Utilizzabili a condizioni “giuste, ragionevoli e non discriminatorie” (FRAND)

La specifica è disponibile

a.       In forma testuale

b.      Come Reference Implementation (RI) rilasciata con licenza OSI compliant (Open Source Initiative) e business friendly

La specifica in forma testuale ed in forma di codice sorgente sono funzionalmente equivalenti

La specifica contiene gli strumenti per verificare che una data realizzazione è conforme alla specifica

La specifica è adottata dall’autorità pubblica che ne determina gli obblighi d’uso

La specifica è gestita da un sistema di governance che, tra l’altro,

a.       Ha il compito di rendere la specifica pubblicamente disponibile

b.      Gestisce l’evoluzione della specifica per

                                                   i.      Correggere eventuali errori

                                                 ii.      Tener conto di nuovi requisiti

                                                iii.      Restare competitiva con lo sviluppo della tecnologia

c.       Promuove l’adozione di nuove versioni della specifica iDRM da parte dell’autorità pubblica

d.      Funge da punto di raccolta delle condizioni di licenza delle tecnologie di cui sono disponibili solo licenze a condizioni FRAND

5          Bibliografia

[1] dmin.it, Proposta di azioni per dare all'Italia una posizione leader nei “digital media”, 2006/09/13: http://www.dmin.it/proposta/index.htm

[2] S. Bechtold “Value-centered design of Digital Rights Management”, INDICARE Monitor: http://www.indicare.org/tiki-read_article.php?articleId=39

[3] Deirdre K. Mulligan e Aaron Burstein “Implementing Copyright Limitations in Rights Expression Languages (2003)”: http://crypto.stanford.edu/DRM2002/mulligan_burstein_acm_drm_2002.doc

6          Terminologia

Il significato dei termini principali usati in questo documento sono:

AC

Autorità Centrale

ACS

Alternative Compensation Systems

Autenticare

(un dispositivo) dimostrarne l’identità

Catena del valore

Un insieme di intermediari, uniti per realizzare un modello di business, e collegati tra di loro e con gli autori e gli utenti finali. Gli intermediari svolgono funzioni a valore aggiunto a cui possono corrispondere transazioni

Digital media

Forma di creazione, distribuzione e consumo di contenuti resa possibile dal fatto che i contenuti stessi sono espressi in forma di bit trasportabili da varie tipologie di protocolli sulle reti numeriche, elaborabili da dispositivi programmabili e fruibili attraverso una vasta gamma di tecnologie

iDRM

DRM interoperabile: L’insieme di specifiche tecniche, caratteristiche del sistema di governance e azioni normative richieste per rendere operative piattaforme tecnologiche che consentano a coloro che operano nell’ambito della legislazione italiana di creare, operare e partecipare a catene del valore di digital media che permettano l’accesso ai servizi e l’uso dei contenuti di tali catene mediante apparati realizzabili a partire da specifiche pubbliche

Intermediario

Un qualunque utente di una catena del valore al di fuori di autore/esecutore/produttore e utente finale

LA

Laboratorio Accreditato

NAP

Network Access Point

REL

Rights Expression Language

SLA

Service Level Agreement

TPM

Technical Protection Measure

Annex A – Contesto giuridico del DRM

Sebbene il Digital Rights Management (DRM) sia un complesso sofisticato di tecnologie che si presta a varie finalità connesse alla gestione delle informazioni espresse in forma binaria, esso finora è stato inteso e regolamentato essenzialmente come uno strumento per rafforzare la protezione dei diritti di proprietà intellettuale (in particolare, del diritto d’autore) sui contenuti digitali. Per lo stesso fenomeno, l’oggetto dei DRM è per lo più stato sempre ritenuto coincidente con quello dei diritti di proprietà intellettuale digitale. La tecnologia DRM è però neutra e si può applica altrettanto bene a contenuti non soggetti a diritto d’autore; ad esempio contenuti nell’ambito di un’impresa.

Le grandi imprese titolari di diritti d’autore su contenuti digitali (software, testi, musica, film, ecc.) hanno fatto leva sulle misure tecnologiche di protezione, dette in inglese: Technical Protection Measures (TPM), incluse nei sistemi di DRM per estendere il controllo sui medesimi contenuti oltre il livello garantito alle stesse dalle leggi sulla tutela delle opere dell’ingegno. Molti paesi economicamente avanzati, inoltre, forniscono una tutela giuridica delle TPMs che è in massima parte collocata nell’ambito delle leggi sul diritto d’autore. La prima rilevante forma di tutela giuridica internazionale delle misure tecnologiche di protezione si deve ai World Intellectual Property Organization Treaties del 1996. I legislatori statunitense ed europeo hanno dato attuazione al mandato internazionale emanando rispettivamente il Digital Millennium Copyright Act (DMCA) del 1998 e la direttiva 2001/29/CE del Parlamento europeo e del Consiglio del 22 maggio 2001, relativa all’armonizzazione di taluni aspetti del diritto d’autore e dei diritti connessi nella società dell’informazione (la direttiva è stata attuata in Italia con d.lgs. 9 aprile 2003, n. 68, il quale ha profondamente modificato la l. 22 aprile 1941, n. 633 sulla protezione del diritto d’autore e di altri diritti connessi al suo esercizio; si vedano in particolare gli art. 102-quater, che definisce e disciplina le “efficaci misure tecnologiche di protezione”, 71-quinquies, sul rapporto tra eccezioni e misure tecnologiche, 71-sexies, sul rapporto tra copia privata e misure tecnologiche, e 171-ter sulle conseguenze penali per “il traffico” di tecnologie principalmente finalizzate all’elusione di misure tecnologiche).

Semplificando notevolmente, il nucleo comune delle norme derivate dai trattati WIPO sta nel triplice divieto di:

  1. Elusione delle misure tecnologiche poste a protezione dei diritti sulle opere;

  2. Produzione o diffusione di tecnologie “principalmente finalizzate” all’elusione delle TPMs;

  3. Rimozione o alterazione delle informazioni sui diritti annesse alle opere.

Si tratta di normative assistite anche da severe sanzioni penali. I problemi che esse pongono sono oggetto di una vasta letteratura giuridica ed economica. In questa sede è essenziale rilevare che le normative non costituiscono regolamentazioni organiche del DRM, ma piuttosto discipline minimali di alcuni risvolti relativi all’uso (e alla “violazione”) di alcune componenti del DRM (TPM ma anche di gestione dei diritti).

Di fatto la regolamentazione del DRM è una regolamentazione volta a sanzionare l’utilizzatore che “forza” il blocco tecnologico e non prevede invece cautele “a monte” per assicurare la congruità di tale blocco tecnologico rispetto al bene da proteggere.

Ne è prova anzi tutto il fatto che la modalità più comune di sfruttamento delle TPM consiste nel tradurre in restrizioni tecnologiche dell’accesso e dell’uso del contenuto quanto stabilito nei contratti di licenza d’uso all’utente finale (in inglese: End User License Agreement o EULA). Tali contratti di licenza d’uso sono condizioni generali di contratto, cioè contratti standardizzati valevoli per una serie indeterminata di destinatari. Le condizioni generali di contratto pongono ben note questioni di tutela giuridica dell’accettante (si pensi all’art. 1341 del codice civile sulla disciplina delle condizioni generali di contratto, e alle norme sulle clausole vessatorie nei contratti con i consumatori ora contenute negli art. 33 e ss. del d.lgs. 6 settembre 2005, n. 206, codice del consumo). La trasposizione della contrattazione standardizzata nel contesto digitale (ed in particolare nel contesto di Internet) complica i problemi di tutela del contraente accettante. Infatti, mentre nella negoziazione ordinaria le difficoltà possono essere risolte dalle parti, il DRM non ha sovente la flessibilità necessaria ad accettare modifiche all’EULA successive alla sua implementazione, ma rientra fra le cose tecnicamente realizzabili.

Se pertanto l’utilizzatore ritiene di poter validamente porre in essere un certo tipo di uso nonostante una clausola contrattuale lo vieti in quanto, per qualche motivo, tale clausola sarebbe non applicabile, è possibile che il DRM diventi ostativo alla più corretta applicazione del contratto. Si pone pertanto il problema di comprendere se la violazione del DRM in un caso del genere sia legittima ovvero di realizzare un sistema sufficientemente flessibile da poter accettare modifiche successive all’implementazione delle policies dell’EULA di riferimento.

In questo senso l’iDRM dovrebbe risultare vantaggioso in quanto:

  1. È redatto in OSS e quindi è più facile per un tecnico capirne il funzionamento;

  2. È progettato “da zero” con la partecipazione di tutte le parti in causa e quindi può supportare funzionalità che i sistemi DRM, tipicamente progettati da una sola parte, non hanno;

  3. È un DRM con varie modalità di funzionamento a seconda delle necessità degli attori: permissivo (ad esempio stile Creative Commons) oppure rigoroso.

Le questioni di maggior rilievo sono infatti connesse alla già accennata politica di estensione del controllo sui contenuti praticata, per mezzo del DRM, dalle grandi imprese titolari dei diritti di proprietà intellettuale. In tal senso, viene in questione il rapporto tra diritti di proprietà intellettuale e mercato, con specifico riferimento al diritto antitrust: è possibile che un controllo di utilizzo eccessivo per mezzo di DRM proprietari e non interoperabili da parte di soggetti titolari di una vasta gamma di diritti di proprietà intellettuale possa essere costruito dalle Autorità di settore come abuso di posizione dominante.

Il criterio da utilizzare per sindacare la legittimità di un DRM, in estrema sintesi, secondo il c.d. “Market-Oriented Approach” è quello della possibilità futura per contenuti digitali diversi e più innovativi di accedere al mercato: un DRM che crei una barriera all’entrata tale da escludere l’accesso a terzi con contenuti innovativi sarebbe da considerarsi anticompetitivo e, perciò, illegittimo ai sensi del diritto antitrust.

Lo stesso metodo si applica all’introduzione di nuove regole in materia. Il legislatore, sulla scorta degli insegnamenti del moderno diritto antitrust, è particolarmente sensibile a non creare regole che tutelino posizioni dominanti in materia di informazione digitale specie se non rientrante nell’ambito di applicazione del diritto d’autore.

La prassi delinea in tal senso differenti possibili scenari.

Scenario A

Un primo ventaglio di scenari deriva dalla traduzione in restrizioni tecnologiche delle clausole contrattuali entro quelli che sono i limiti imperativi (cioè, non derogabili mediante contratto) posti dalle leggi (diritto d’autore, diritto dei contratti, ecc.). Questo ventaglio di scenari costituisce normalmente la parte fisiologica del fenomeno. Le restrizioni contrattuali e tecnologiche costituiscono infatti il presupposto per l’applicazione di nuovi e variegati modelli di business (basati, ad esempio, su bundling e discriminazione dei prezzi). Ad esempio, una canzone può essere venduta per una fruizione priva di limitazioni oppure per un numero limitato di ascolti. Ai due contratti corrispondono domande e prezzi differenziati.

Queste pratiche commerciali rappresentano – in linea generale – un’espressione della libertà di impresa e delle nuove possibilità dischiuse dal DRM. Esse però non sono prive di problemi. È possibile che gli utenti dei contenuti digitali ed in particolare i consumatori non siano adeguatamente informati sul funzionamento del DRM e delle TPM, nonché sul contenuto del contratto e dunque acquistino qualcosa che non corrisponde esattamente ai loro “desiderata” e si trovino frustrati nel momento in cui cercano di esercitare quello che ritengono un proprio “diritto” (es. produrre una copia su supporto ottico di brano in formato liquido). Dunque, al fine di mantenere il fenomeno nella fisiologia, è necessario intervenire sulla trasparenza del processo di negoziazione e di conclusione dei contratti. Tale trasparenza dipende dal modo in cui sono concepite le componenti tecnologiche del DRM finalizzate alla gestione degli atti negoziali (ad esempio, i Rights Messaging Protocols o RMP) con cui è possibile allargare il margine di manovra dell’utente oltre la classica alternativa accetto o rifiuto le condizioni generali di contratto di cui è composta la licenza. V. ad esempio [2] e [3].

Esistono poi altri problemi legati a questo tipo di scenario. Le TPM incluse in sistemi di DRM possono essere adoperate per proteggere contenuti che sono privi dei requisiti posti dalla legge sul diritto d’autore per la tutela delle opere dell’ingegno. Ad esempio, un requisito è rappresentato dal carattere creativo dell’opera (una mera informazione non gode della protezione stabilita dalla legge sul diritto d’autore). Una TPM può essere finalizzata al controllo di un’informazione priva del requisito di creatività. In questo caso il DRM trae legittimità non più dalla legge ma esclusivamente dal contratto ed il contratto è stipulato tra le parti. In linea generale, infatti, il diritto dei contratti conferisce validità alla tutela negoziale dell’informazione (ad esempio, divieto di trasmettere a terzi l’informazione). Ovviamente, il contratto vincola solo le parti del contratto stesso e non i terzi. In altre parole, il terzo che venga lecitamente in “possesso” dell’informazione non è vincolato dal contratto e dalla clausola che restringe la circolazione dell’informazione. La traduzione in restrizioni contrattuali delle clausole finalizzate al controllo dell’informazione è – sempre in linea di massima – da considerarsi lecita. Tuttavia, un’applicazione diffusa di TPM alle informazioni prive di requisiti richiesti per la tutela delle opere dell’ingegno può trasformare di fatto un controllo di natura contrattuale in un controllo di natura reale (cioè valido nei confronti di tutti i potenziali fruitori delle informazioni). Sul piano giuridico, il terzo che viene lecitamente in possesso di un’informazione protetta da una TPM non è vincolato né dal contratto stipulato da altri soggetti, né dal rispetto della TPM. Egli in linea teorica potrebbe aggirare la TPM, ma di fatto la mancanza di conoscenze tecnologiche potrebbe impropriamente ed illegittimamente vincolarlo alla restrizione tecnologica con possibili ricadute di tipo antitrust che verranno approfondite al successivo punto.

Scenario B

La prassi ha poi messo in evidenza un secondo ventaglio di scenari che mostra il lato patologico dell’interazione tra DRM, contratto e leggi sulla proprietà intellettuale (in particolare, leggi di tutela giuridica delle TPM). Il controllo dell’informazione digitale può innescare contrasti potenziali con l’ordinamento giuridico o spingersi fino a palesi violazioni di legge. Si tratta di una materia complessa e densa di incertezze che conta ancora poche fattispecie giunte fino all’interpretazione di una corte di giustizia.

Si pensi tuttavia al caso Magill[2] in cui informazioni relative al palinsesto televisivo – non oggetto del diritto d’autore – venivano utilizzate come strumento per condizionare il mercato delle guide televisive bloccando accesso agli editori indipendenti che non avevano accordi commerciali con i grandi broadcaster. L’intervento dell’antitrust comunitario ha consentito l’accesso all’informazione.

L’analogia con quanto potrebbe accadere con informazioni di qualsiasi tipo a cui si applicasse un DRM non interoperabile e non regolamentato in maniera orientata al mercato. In questo senso si può qui anticipare che iDRM, correttamente inteso, è uno strumento di prevenzione dell’intervento antitrust, volto a configurare corrette dinamiche concorrenziali.

Un primo scenario delineato dalla prassi mostra dunque che l’interazione tra DRM, contratto e leggi sulla proprietà intellettuale in carenza di regolamentazione (o autoregolamentazione) specificamente formulata può essere utilizzata per conquistare o difendere posizioni monopolistiche (in particolare, per quanto concerne mercati collegati come la vendita al dettaglio delle piattaforme e degli applicativi).

Ad esempio, un produttore presente sia sul mercato delle console, sia su quello dei videogiochi utilizza il DRM per rafforzare tanto la posizione del mercato a monte (della produzione di console), quanto quello a valle (dei videogiochi). Le TPM incluse nel DRM applicato a console e videogiochi sono tecnologie chiuse protette da proprietà intellettuale (brevetto per invenzione). L’EULA e le TPM sono concepite in modo da impedire all’utente di utilizzare la console con videogiochi di altri produttori. Gli altri produttori di videogiochi non possono ottenere l’interoperabilità con la console, in quanto quest’ultima è protetta da brevetto. Si è verificato che imprese dedite alla produzione di tecnologia in grado di aggirare le TPM della console al fine di modificare le funzionalità di quest’ultima (rendendola, tra l’altro, interoperabile con videogiochi prodotti da terzi) siano state citate in giudizio dal produttore della console per violazione della legge che proibisce la produzione di tecnologie prevalentemente finalizzate all’elusione di TPM (art. 171-ter lett. f)-bis della legge n. 633 del 1941). Questo tipo di azioni potrebbe essere considerato un abuso della tutela giuridiche delle TPM finalizzato a distorcere la concorrenza.

La prassi ha poi messo in evidenza un secondo scenario nell’ambito del quale alcune componenti dei sistemi di DRM possono essere utilizzate per carpire in modo subdolo dati personali relativi al consumo dei contenuti digitali. Ha fatto scalpore una recente vicenda relativa alla messa in commercio di CD musicali dotati di sistemi di DRM i quali includevano alcune componenti in grado di autoinstallarsi sui computer degli utenti. Tali software sono stati additati come minacce alla privacy degli utenti ed alla sicurezza dei loro sistemi informatici. Inoltre, né le copertine dei CD, né le EULA dei software sembravano dare sufficienti informazioni sul funzionamento dei sistemi di DRM.

La diffusione di tecnologie chiuse e proprietarie e la descritta tendenza ad utilizzare l’interazione tra DRM, contratto e leggi sulla proprietà intellettuale per estendere il controllo sui contenuti digitali (anche a costo di porsi in contrasto con l’ordinamento giuridico) stanno ingenerando nei consumatori un sentimento di diffidenza verso il DRM e minando l’efficienza del mercato. Il sentimento di sfiducia matura in un ben noto contesto che annovera, tra le alternative di fatto praticabili, il file sharing in violazione della legge sul diritto d’autore. Dunque, a scenari di uso patologico del DRM si contrappongono altri scenari di illiceità. Questo in parte deriva dall’incapacità delle leggi statali di governare i meccanismi a vocazione globale che muovono le nuove dinamiche degli interessi legati alla produzione di informazione.

L’attuale contesto tecnologico è caratterizzato da uno straordinario pluralismo delle tecnologie e delle regole di riferimento. Si pensi alla distanza che separa i sistemi DRM chiusi e proprietari dal Free and Open Software ed in particolare dalla distribuzione di software basata sulla GNU General Public License. Questo pluralismo rappresenta – se opportunamente governato – un formidabile motore per l’accrescimento di informazioni, conoscenza e innovazione. In particolare, la concorrenza tra tecnologie (nonché tra modelli di regolamentazione differenti) è fonte di innovazione.

Occorre continuare a guardare alla proprietà intellettuale come un mezzo (uno dei tanti) per l’accrescimento di informazioni, conoscenza e innovazione. Essa perciò non dovrebbe essere conformata su una tecnologia o su un modello di business, ma dovrebbe invece rappresentare uno strumento flessibile che contribuisce a mantenere l’equilibrio dei vari interessi coinvolti ed il pluralismo delle tecnologie.

La conformazione della proprietà intellettuale dipende solo in parte dalla legge. Un apporto fondamentale viene dall’interpretazione e dall’applicazione della stessa legge (ad esempio, da parte dei giudici).  

Annex B – Tecnologie per catene del valore

In questo annesso si analizza un esempio di catena del valore che essenzialmente replica una catena del valore del mondo analogico e si illustrano le tecnologie che sono potenzialmente richieste per realizzarne una versione tutta numerica.

La Fig. 5 data qua sotto contiene alcuni dei tipici attori di una catena del valore

Fig. 5 – Alcuni dei tipici attori di una catena del valore

 La tabella qua sotto dà una breve descrizione del ruoli indicati

Tab. 2 – Breve descrizione dei ruoli degli attori della catena

Attore della catena

Azioni compiute dall’attore

Autore

Produce un’opera

Istanziatore

Esegue l’opera (ad esempio cantante)

Produttore

Produce un’opera in forma finale

Fornitore di contenuti

Rende disponibile una gamma di contenuti

Fornitore di servizi

Rende disponibile una gamma di servizi (ad esempio aggregazione)

Utente Finale

Accede a servizi e consuma contenuti

 Un autore crea un’opera che è eseguita (“istanziata”) da un artista ed utilizzata da un produttore per farne un prodotto – tipicamente una combinazione di varie risorse (audio, video ecc.) – che sarà successivamente distribuito dai fornitori di contenuti e di servizi per essere infine fruito da un utente finale.

 Già nelle catene del valore tradizionali esisteva la necessità di dare un’identità alle varie entità che sono trattate dagli attori della catena del valore. Quando tali entità diventano bit che non sono più necessariamente associabili a qualcosa di fisico tale necessità è vieppiù sentita, anche perché alle entità sono associati o associabili una quantità di dati (metadati ed altro).

 Nelle catene del valore numeriche gioca quindi un ruolo importante la definizione di una struttura che possa flessibilmente tenere insieme risorse (eventualmente solo i link che portano ad esse), identiticativi, metadati ed altro di cui si dirà oltre.

 Un esempio importante di “altri” dati associabili alle entità sono le licenze. Queste permettono ad un utente della rete che ha diritti su un’entità di esprimere come un altro utente della rete può usare le risorse oggetto della licenza ed in quali condizioni. Un esempio di tale licenza può essere una particolare licenza Creative Commons espressa in una forma interpretabile da una macchina.

 Le licenze possono essere date ad un dispositivo (nel caso di un utente finale, il suo player MP3, ad esempio), ad un utente (rappresentato ad esempio dalla sua smart card) o ad un dominio. Questi sono raggruppamenti di dispositivi e di utenti.

 Perché un dispositivo (ad esempio un player) sia in grado di interpretare, senza intervento umano, una licenza potenzialmente in grado di esprimere tutte le complessità dei rapporti di business tra attori delle catene del valore, si richiede un opportuno linguaggio comunemente chiamato Rights Expression Language (REL). Tale linguaggio farà naturalmente riferimento a “verbi” (ad esempio “play”, “copy” ecc.) che dovranno essere opportunamente definiti. Ancora allo scopo di esprimere tutte le complessità dei rapporti di business tra attori delle catene del valore, è conveniente utilizzare  un’ontology espressa in Ontology Web Language (OWL).

 Un utente della catena del valore che interagisce con contenuti mediante un dispositivo genererà tipicamente dei dati (ad esempio “quante volte è stata sentita la canzone Papaveri e Papere” oppure “quante volte è stato letto il paragrafo 1.2.3 della proposta dmin.it”) chiamati “dati d’uso”. Questi possono avere un valore in sé e l’utente che li genera potrà decidere di dare ad altri utenti della catena del valore licenza di utilizzare tali dati d’uso. Infatti, mentre nei casi più comuni è il contenuto ad aver valore, sono concepibili casi in cui sono invece i dati d’uso ad aver più valore. Una tecnologia molto importante per la valorizzazione dei dati d’uso è quella che permette di “contare” in modo affidabile i vari eventi che corrispondono ad un uso.

 La licenza può essere parte integrale della struttura dati (cioè essere “in line”) oppure può essere referenziata (questo è in generale vero per qualunque componente della struttura). In alternativa il dispositivo a cui l’utente chiede di svolgere una certa funzione (ad esempio “play”, “copy” ecc.) può consultare il dispositivo del detenore dei diritti oer conoscere se quella funzione è ammissibile.

 I componenti della struttura, in particolare le risorse, possono essere in una forma che permette l’uso immediato o in forma protetta (cioè cifrata). Quindi la struttura deve essere in grado di convogliare altri titpi di dati quali le chiavi e altra informazione collegata. Oltre a questi altri tipi di dati la struttura deve poter convogliare anche codice eseguibile che il dispositivo può utilizzare per compiere varie elaborazioni sui dati ricevuti (ad esempio estrazione di informazione contenuta nel watermarking associato al file audio).

 Le modalità di trasporto della struttura di dati tra dispositivi sono essenzialmente due: attraverso file o stream. Il secondo caso è particolarmente importante nel caso in cui la struttura dati porti informazione che deve essere consegnata al dispositivo ricevente entro un certo tempo.

 Infine occorre ricordare che, prima di attuare il trasporto della struttura dati o addirittura indipendentemente dal trasporto stesso, i dispositivi hanno necessità di eseguire protocolli in conseguenza di istruzioni date dagli utenti dei dispositivi. Esempi possono essere il protocollo per ottenere la licenza per l’uso di un contenuto o per la creazione di un dominio di dispositivi o di utenti.

 In molti casi di catene del valore analogiche il ruolo del dispositivo è marginale e l’uso dei contenuti – libri, cassette, dischi ecc. – è regolato dalle leggi e dalle consuetudini. Lo stesso può avvenire anche per catene del valore numeriche (ad esempio vendita di file MP3 non protetti di Emusic).

 Questa modalità è però abbastanza limitativa dello spettro di possibilità offerto dalle tecniche numeriche. Coloro infatti che detengono diritti per contenuti di alto valore temono che il rilascio dei loro contenuti in forma non protetta porti ad un mancato guadagno molto significativo. Se tali contenuti sono però protetti (cifrati) è necessario che i dispositivi che convertono i contenuti in forma non cifrati siano certificati, cioè diano sufficienti garanzie di robustezza agli attacchi.

 Il modello iDRM offre la garanzia che chiunque abbia un dispositivo realizzato secondo le specifiche pubbliche ed abbia acquisito i necessari diritti possa accedere e fruire di un dato contenuto. Il modello però funziona solo se ci siano contenuti e cioè che gli aventi diritto abbiano rilasciato i loro contenuti fiduciosi che i dispositivi che li usano si comportino come atteso.

 La possibilità di avere un “certificato di garanzia di un dispositivo” è quindi una componente fondamentale del modello iDRM, tenendo presente che potrebbero benissimo esserci diversi “bollini” corrispondenti a diversi requisiti di robustezza per contenuti che richiedono appunto diversi requisiti.

 La governance del sistema iDRM richiede quindi che ci siano diverse “agenzie” che, sotto la sorveglianza del sistema di governance, possano emettere, ovviamente a valle di un’istruttoria tecnica, il “bollino” ai dispositivi di un certo modello.

 Similmente la governance richiede che i contenuti (rappresentati dalle strutture dati associati) siano univocamente identificati. Il processo di registrazione ed emissione di identificativi è attuato sotto la sorveglianza del sistema di governance e prevede l’esistenza di diverse “agenzie” che assegnano gli identitficativi all’interno di un name space loro assegnato.

 Lo stesso metodo può essere adottato nell’identificare in modo univoco i dispositivi.

Annex C – Casi d'uso

In questa parte del documento si descrivono alcuni casi significativi di utilizzo della proposta dmin.it.

C.1    Distribuzione di contenuti non protetti

Ci sono molti casi in cui aziende o individui hanno interesse a rilasciare contenuti su cui hanno diritti in modo tale che i destinatari possano usarli liberamente senza peraltro renderli di pubblico dominio. Esempi sono materiale publicitario, prologhi di film, canzoni rilasciate da una banda di cantinari o un filmino di un dilettante. Nel mondo analogico questo fatto era gestito interamente a livello legale, sia che i diritti in questione fossero da copyright/diritto d’autore sia da modalità alternative quali Creative Commons.

La base legale sottende chiaramente sia la distribuzione in forma analogica che in forma numerica. Ma le possibilità offerte da una distribuzione numerica possono essere potenziate dall’adozione di tecnologie che consentano alle macchine di gestire l’informazione relativa alla forma di distribuzione in modo automatico. Si può quindi pensare a licenze associate alle risorse (audio, video, testo ecc.) scritte in un linguaggio comprensibile da una macchina che corrispondano alle licenze scritte in linguaggio naturale – le sole ad avere valore legale. La macchina potrà essere predisposta ad agire solo in conformità a quanto prescritto dalla licenza, oppure soltanto a segnalare all’utente della macchina solo quello che la licenza si aspetta un utente possa fare ecc. Tutto questo naturalmente è slegato dal fatto che le risorse siano in chiaro (come ad esempio prescitto dalle licenze Creative Commons) oppure cifrate.

Questo caso d’uso, introdotto per primo dal Digital Media Project con il nome “Open Release” sta per diventare uno standard ISO con il nome “Open Release Multimedia Application Format”. In questo standard le risorse devono essere in chiaro.

Questa forma “elettronica” di rilascio di contenuti è chiaramente contigua ad altre forme di rilascio di natura più direttamente commerciale. Tra gli obiettivi di dmin.it c’è la definizione di tecnologie che consentano un passaggio graduale da queste forme aperte di rilascio di contenuti ad altre forme eventualmente più “restrittive” se così voluto dall’avente diritto.

Immaginiamo che Leonardo sia stato invitato a fare una presentazione ad una conferenza ma che all’ultimo minuto abbia un contrattempo che gli impedisca di partecipare. Invece di “tirare il pacco” Leonardo decide di mandare un audiovisivo con altri dati agli organizzatori della conferenza come “Open Release”. Il materiale sarà quindi dato prima ai partecipanti alla conferenza e poi, a conferenza terminata, a tutti. Leonardo potrebbe decidere che la licenza valida dopo la fine della conferenza sia una delle licenze Creative Commons (ad esempio la licenza usata per questa “proposta operativa”), mentre la prima licenza no perché gli organizzatori della conferenza temono troppe defezioni dalla conferenza.

Siccome sapere “quante persone guardano la presentazione” è informazione importante per conoscere l’interesse della comunità accademica al tema, Leonardo potrebbe spezzare la licenza in due. La prima è attaccata alle risorse mentre la seconda parte deve essere scaricata dal server di Leonardo sì da poter “contare” quante persone vogliono guardare la presentazione.

È naturalmente opportuno mettere in chiaro che, in un contesto di “Open Release” la licenza di per sé potrebbe essere irrilevante perché le risorse sono comunque liberamente accessibili. Anche se si può pensare ad una percentuale di irriducibili antisistema che vorranno guardare la presentazione direttamente, in questo modo aiutando Leonardo a raggiungere il suo obiettivo di far guardare la sua presentazione, è però pensabile che ci sia una massa di persone che sono invece ben disposte ad essere “guidate” dalla macchina che legge la licenza e che si riservano la libertà di decidere se e in quali condizioni trasgredire.

C’è poi naturalmente la seria obiezione che viene dal fatto che Leonardo potrebbe fare un uso improprio dell’informazione accumulata dal server. Anche qui però la tecnologia può venire in soccorso mettendo, insieme alla struttura di dati che accompagna le risorse, un’altra struttura dati interpretabile da un player “Open Release” istruita a mandare un messaggio a Leonardo con opportune indicazioni. Tale tecnologia prende il nome di event reporting di cui MPEG-21 già fornisce una versione standardizzata.

C.2    Sistema di compensazione alternativo

Parecchi hanno immaginato sistemi di distribuzione di contenuti basati sul pagamento di una “tassa” grazie alla quale sia possibile al probo cittadino di accedere a tutti i contenuti pubblicati per distribuzione su piattaforme digitali. Sistemi di questo tipo sono chiamati con il titolo di questo caso d’uso e, in inglese, Alternative Compensation Systems (ACS).

Questi sistemi sono dichiarati “semplici” na non lo sono affatto in quanto richiedono la costituzione di un’infrastruttura tecnologica di tutto rispetto. Sono anche dichiarati alternativi all’uso del DRM, mentre non richiedono TPM ed abbisognano di tecnologie DRM (management) non indifferenti.

Il lato positivo di una soluzione ACS sta nel dare ai cittadini italiani la possibilità di accedere, usare e condividere qualsiasi contenuto digitale senza rovinare la “user experience” del contenuto numerico con vari tipi di intrusioni tecnologiche.

In questo caso d’uso si studia come l’Italia potrebbe realizzare un sistema di compensazione alternativo una volta che la specifica iDRM sia stata adottata a livello nazionale.

  1. Lo stato costituisce o individua un’agenzia incaricata di ricevere informazione di uso dei contenuti rilasciati sul territorio nazionale

  2. Ogni autore/artista/produttore rilascia i suoi contenuti con una struttura dati associata che contiene anche tecnologia di “event reporting” in grado di notificare l’agenzia ed eventualmente gli aventi diritto ogni volta che il contenuto viene usato, il tutto firmato elettronicamente

  3. Tutti i dispositivi di consumo posti in vendita nel territorio nazionale sono certificati per interpretare la tecnologia di “event reporting”ed emettere correttamente l’informazione di consumo all’agenzia

  4. L’agenzia ridistribuisce i proventi delle tasse agli aventi diritto in proporzione al consumo dei contenuti stessi.

 Naturalmente ci sono una quantità di problemi pratici che devono essere affrontati per la realizzazione di un tale sistema, ad esempio quanti dati l’agenzia possa raccogliere e quale sia il loro uso. Questo è da collegare ad un’opportunità interessante, da valutare in combinazione con i sistemi di pagamento di dmin.it, e cio è che un utente possa concedere all’agenzia più dati di quanto sia strettamente necessario per scopi di ridistribuzione della tassa. Questa maggiore apertura, che non richiede affatto l’identitifazione della persona ma, ad esempio solo la tipologia della persona, potrebbe essere remunerata in punti.

C.3    Distribuzione internet per tutti

La distribuzione di contenuti con DRM non standardizzato ha svariati effetti

  1. Una catena del valore abbisogna di dispositivi capaci di gestire contenuti secondo un dato DRM

  2. I dispositivi per tuti i vari attori della catena del valore hanno un costo elevato perché non ci sono economie di scala

  3. Il costo della distribuzione dei dispositivi per l’utente finale è proibitivo a meno che il successo del dispositivo sia tale da creare a questo punto dei problemi

  4. Quindi solo grandi operatori possono per mettersi di distribuire contenuti con DRM proprietario

L’esistenza della specifica iDRM cambia tutti questi punti perché

  1. I dispositivi sono costruiti utilizzando le stesse tecnologie di base

  2. Invece di investire in dispositivi con tecnologie diverse per le stesse funzionalità l’industria può fare dispositivi con le stesse tecnologie per funzionalità diverse permettendo così un più ampio spettro di modelli di business

  3. I costi per dispositivi standard sono bassi

  4. Non è necessario occuparsi della distribuzione dei dispositivi all’utente finale in quanto questa può avvenire attraverso i normali canali della vendita al dettaglio

  5. Tutti, anche i piccoli operatori, possono permettersi di distribuire contenuti con iDRM.

Nel seguito viene illustrato come la banda di cantinari Nuova Cantina (NC), che sta avendo qualche successo con le sue canzoni, può tentare di venderle sul web con iDRM. La cosa può essere realizzata come indicato qua sotto:

NC ha un suo Account Virtuale con Nuova Moneta (NM), un fornitore di account virtuali

NC si dota di un programma informatico con le segenti funzionalità

a.       Cifra il file MP3 in forma finale

b.      Registra il file MP3 ad esempio con la SIAE

c.       Crea una struttura dati XML con metadati, event reporting, pointer al server di licenze ecc.

d.      Registra la struttura dati ad esempio con la SIAE

e.       Mette il tutto in vendita sul sito

Rosita, che vuole comperare il brano, ha

a.       Un WiFi PDA con player iDRM

b.      Un account con Piccola Moneta (PC) , un altro fornitore di account virtuali

Rosita

a.       Si scarica il brano con la struttura dati sul suo WiFi PDA

b.      Schiaccia play e le viene chiesto di pagare

c.       Paga sull’Account Virtuale di PM che notifica NM che notifica il server di licenze di NC (tutto questo è, naturalmente, trasparente a Rosita)

d.      Il player iDRM sul WiFi PDA prende la licenza dal server di licenze di NC e fa sentire il brano

C.4    Distribuzione su DTT

Marco è un laureato del DAMS che ha intravisto le opportunità offerte dall’ambiente creato dalla proposta dmin.it. Ha acquistato i diritti per l’uso di un’ora alla settimana da un fornitore di rete DTT ed ora regolarmente confeziona un programma televisivo di un’ora alla settimana approvvigionandosi, mediante l’acquisizione di diritti per la diffusione su DTT, di video autoprodotti dai vari siti italiani.

La catena del valore (quasi) completa potrebbe prevedere i seguenti attori con i relativi compiti.

Lucio

Crea uno short su “La pesca delle trote in alta montagna” un argomento che spera possa interessare Marco in un suo futuro programma

Luigi

Gestisce un sito dove sono caricati video autoprodotti su cui Lucio carica il suo short

Marco

È un aggregatore di video autoprodotti che viene a conoscenza dello short di Lucio e ne acquisisce i diritti

Mario

È un fornitore di accesso alla rete internet a larga banda “on demand” che Marco utilizza una volta alla settimana a condizioni dmin.it per trasmettere i suoi programmi a Muzio

Muzio

È un fornitore di accesso alla rete di distribuzione DTT da cui Marco ha acquistato accesso a 4 Mbit/s per un’ora alla settimana in un giorno ed un’ora stabilita. Muzio offre anche servizi di DRM-izzazione dmin.it che Marco utilizza

Neviano

È un fornitore di accesso alla rete internet a larga banda con cui Muzio ha fatto un contratto di fornitura a 100 Mbit/s a condizioni dmin.it

Nino

È un utente che non si perde mai l’ora di trasmissione dei programmi di Marco

Nereo

È un osservatore di trend dei programmi spontanei su DTT che acquisisce il diritto di accedere ed utilizzare i dati d’uso degli utenti

C.5    Distribuzione su Satellite

I soggetti sono analoghi a quelli del caso DTT: A, telespettatore in possesso di un dispositivo in grado di ricevere i canali diffusi in broadcast via satellite; B, fornitore/aggregatore di contenuti, che intende offrire su satellite, C operatore di rete o aggregatore/fornitore di contenuti presente sul mercato.

La modalità operativa sarà:

Le condizioni richieste sono le stesse del caso della DTT.

C.6    IPTV

I soggetti in questo caso saranno: A, sottoscrittore dei servizi di connettività e di IPTV di B, operatore di rete; C, operatore di rete con diritti sui contenuti x, che eroga ai propri clienti (di cui A non fa parte) in modalità IPTV.

Le modalità del servizio prevedono che inizialmente C chieda interconnessione con l’operatore B per i servizi di IPTV. Una volta realizzata l’interconnessione, il cliente A accede ai contenuti x attraverso le stesse forme e lo stesso device che utilizza quando usufruisce dei contenuti IPTV erogati in proprio da B. In ogni caso la qualità del servizio erogato sarà data dal minimo tra le QoS dei due operatori B e C.

È condizione necessaria per il servizio che il device utilizzato dal cliente A sia interoperabile rispetto a qualunque offerta di IPTV.

C.7    WebTV

Nella sua forma più generica si possono individuare 4 soggetti: A, cliente; B, operatore di rete, di cui A è cliente per i servizi di connettività; C, Content Provider con diritti sui contenuti x; D, operatore di rete, di cui C è cliente.

In questo caso occorre distinguere le modalità operative su due lati:

Oltre alla necessaria presenza di device basati su DRM interoperabili, è necessario che sia in essere una qualche forma di inteconnessione tra B e D (attraverso accordi di peering, oppure attraverso Internet ed operatori terzi). La QoS del servizio di accesso scelto da A deve essere “adeguata” al tipo di contenuto fornito da C. C deve poter ottenere a condizioni di mercato quanto gli è necessario per mettere in rete i propri contenuti. Nel caso di contenuti a pagamento il rapporto economico è comunque diretto tra A e C.



[1] In questo documento per "digital media" si intende “Forma di creazione, distribuzione e consumo di contenuti resa possibile dal fatto che i contenuti stessi sono espressi in forma di bit trasportabili da varie tipologie di protocolli sulle reti numeriche, elaborabili da dispositivi programmabili e fruibili attraverso una vasta gamma di tecnologie

[2] Sentenza 6 aprile 1995, Cause Riunite C-241 e 242/91 P, RTE e altri c/ Commissione (Magill)