Focus no image

Published on giugno 25th, 2009 | by Administrator

0

Sistemi DRM e movimenti del software free ed open source

drm open source free softwaredi Antonio Florio

Alla richiesta di soluzioni DRM non “aggirabili” rispondono non solo gli sviluppatori di sistemi proprietari, ma anche alcune comunità Open Source, che attraverso i c.d. DRM Open hanno come obiettivo quello di risolvere alcune delle problematiche legate al mondo dei sistemi DRM. Tale iniziativa ha ulteriormente diviso il mondo del Free Software e quello dell’Open Source, determinando una pesante reazione del primo con la redazione di una nuova versione della licenza GPL, successivamente ridimensionata da alcuni suoi importanti rappresentanti.

DRM E SOFTWARE LIBERO

I sostenitori del Free Software parlano del DRM in termini di Digital Restrictions Management [1] contrapponendolo alla filosofia del Software Libero. Questa contrapposizione non sarebbe una questione solamente ideologica, dato che un sistema DRM può essere utilizzato in concreto per limitare la libertà degli utenti delle opere digitali. Il fatto, poi, che il software DRM sia Open Source non risolverebbe il problema, anzi, se il metodo di sviluppo Open Source garantisce maggiore affidabilità e stabilità del software, il DRM OS rappresenterebbe una “gabbia più robusta” con la quale imprigionare le libertà degli utenti.

DRM E OPEN SOURCE

Il movimento Open Source si mostra, rispetto ai problemi posti dai sistemi DRM, ulteriormente “aperto” ed equilibrato, considerando tali tecnologie uno strumento neutro (per la gestione delle regole relative all’utilizzazione delle opere digitali) che di per sé non lede alcun diritto o libertà, ma che può essere programmato in modo tale da favorire i titolari dei diritti a discapito degli utenti (soggetti entrambi protetti dalla legge) [2].

Anche se alcune funzionalità proprie dei sistemi DRM (in particolare del c.d. Trusted Computing – TC che ne rappresenta l’evoluzione più negativa) cercano di limitare o impedire il “controllo completo” sui sistemi informatici da parte degli utenti, la possibilità di “incorporare nelle opere digitali regole giuridiche” [3], attraverso sistemi DRM, merita di essere approfondita e sviluppata.

Uno standard DRM Open Source, il cui funzionamento sia, quindi, di pubblico dominio, in quanto legato al suo codice sorgente aperto al mondo, permetterebbe, quindi, di proteggere i diritti d’autore risolvendo, almeno in parte, i problemi legati ai sistemi DRM proprietari e garantendo a chiunque la possibilità di proteggere le proprie opere digitali, adattando eventualmente il sistema alle proprie esigenze.

Ovviamente il solo fatto che il codice sorgente di un software DRM sia disponibile a tutti non rappresenta la panacea a tutti i mali legati a tali tecnologie. Senza dubbio, conoscere il funzionamento del sistema DRM, come interagisce con i vari devices e tratta i dati personali, rappresenterebbe una maggiore garanzia per gli utenti/consumatori sia in relazione alle possibili utilizzazioni dell’opera, sia contro eventuali funzioni occulte che potrebbero porre in pericolo la loro privacy e i loro “dispositivi”.

Dal punto di vista tecnologico l’aspetto più importante legato ai sistemi DRM OS è certamente la soluzione del problema dell’interoperabilità.

I sistemi di DRM e di CAS (Conditional Access System) attualmente in circolazione permettono solo di legare le licenze ai dispositivi. Diviene necessario, però, realizzare dispositivi più flessibili che consentano di assegnare le licenze agli individui in base alla loro identità o al ruolo che rivestono in una organizzazione.

I sistemi DRM Open perseguono anche l’obiettivo di separare la gestione dei diritti dal sistema di protezione dei contenuti e di separare l’identità e i servizi di autenticazione dai dispositivi hardware proprietari, l’apertura del codice, inoltre, aumenta la flessibilità dei prodotti e degli standards [4].

GPLv3 E DRM

Mentre il movimento Open Source ha formalizzato le proprie idee sul codice aperto in una vera e propria definizione “The Open Source Definition”, la filosofia del software libero, invece, non ha una vera e propria definizione, ma si rifà alla GNU General Public License, c.d. GPL, la licenza realizzata dalla Free Software Foundation [5] nel 1989 per la circolazione del sistema operativo GNU [6].

La GPL è diventata, quindi, il simbolo della filosofia del Free Software, garantendo agli utenti le più estese libertà di utilizzazione del software, accesso al codice sorgente, modifica e distribuzione [7].

Dopo pochi anni dalla sua pubblicazione la GPL venne riveduta e corretta dai suoi ideatori, che realizzarono nel 1991 la più nota seconda versione, più nota in quanto rimasta in vigore per più di 15 anni.

Il 29 giugno 2007 la FSF ha rilasciato la terza versione della GPL, nata, a detta dei fondatori del Free Software, per fronteggiare lo sviluppo delle nuove tecnologie volte a limitare le liberta degli utenti. Partendo da queste premesse, la GPL si occupata anche dei problemi relativi ai brevetti software ed agli accordi diretti ad eludere le prescrizioni della licenza stessa tra le “software house proprietarie” e alcune società che sviluppano software libero (Collusive Practices) [8].

Per quanto attiene più nello specifico la materia dei DRM, Richard Stallman, l’ideatore del software libero, è stato da sempre un feroce oppositore di tali sistemi, auspicandone la definitiva scomparsa.

La prima bozza della GPLv3 descriveva i sistemi DRM come sistemi di “Digital Restrition Management” e sanciva che: “DRM is fundamentally incompatible with the purpose of the GPL, which is to protect user’s Freedom; therefore, the GPL ensure that the software it covers will neither be subject to, nor subject other works to, digital restriction from which escape is forbidden”.

Con questa previsione, la licenza si opponeva in modo completo ai sistemi DRM stabilendo addirittura che tali sistemi si ponevano in contrasto con gli stessi fini del software libero. In questo modo, intendeva colpire non solo l’utilizzo di sistemi DRM proprietari, ma anche i neonati DRM open source, che se formalmente potrebbero essere compatibili con le prescrizioni della GPL, idealmente, invece, ne rappresentano l’antitesi, limitando i diritti degli utenti sulle opere digitali.

La previsione riguardava oltre al software anche “other works”, sottolineando come la GPL venga utilizzata anche per garantire le libertà degli utenti su opere diverse dal software.

In base a quanto detto ed alla previsione contenuta nell’art. 3: “As a Free software license, this License intrinsically disfavors technical attempts to restrict users’ Freedom to copy, modify, and share copyrighted works”, si potrebbe affermare che la prima bozza della GPLv3 non era contraria a tutti i sistemi DRM, ma solo a quelli contenenti MTP o che, pur liberi da queste misure, violano i diritti garantiti agli utenti [9].

A causa della sua netta opposizione ai sistemi DRM, la GPLv3 I draft è stata contestata da buona parte della comunità del Free Software. Uno dei massimi esponenti di questa comunità, Linus Torvalds, il padre di Linux, ha subito escluso l’applicabilità della nuova versione al suo sistema operativo, continuando a preferire la seconda versione. Questa sua presa di posizione è stata dettata non solo da questioni ideologiche, per le quali un utente Linux deve poter far ciò che vuole con il proprio sistema, ma anche da questioni di ordine economico e politico [10].

La seconda bozza della GPLvIII cambiava completamente obiettivo, cessando di riferirsi ai DRM e alle Misure Tecnologiche di Protezione, per concentrarsi, sembrava, sul fenomeno del Trusted Computing (TC).

Prevedeva, infatti, che: “Some Computer are designed to deny users access to install or run modified versions of the software inside them. This is fundamentally incompatibile with the purpose of the GPL, which is to protect users’ Freedom to change the software. Therefore, the GPS ensures that the software it covers will not be restricted in this way”.

Nei sistemi di TC [11] è “la macchina stessa a decidere cosa potrà funzionare su di essa e cosa, invece, non sarà considerato “fidato” e perciò rifiutato” [12].

Sempre la II bozza della GPLv3 sanciva chiaramente che la distribuzione del codice sorgente (Corresponding Source) doveva includere anche le chiavi di decrittazione o autorizzazione eventualmente necessarie per installare e/o eseguire copie modificate del sorgente.

Mentre nella prima bozza della GPLv3 la terza Sezione era denominata “Digital Restriction Management”, nella seconda bozza la terza Sezione era intitolata “No denying users’ rights throught Technical Measures” e statuiva:

  • il divieto di metodi per la distribuzione che negano agli utilizzatori di “lavori coperti” dalla licenza GPL (essenzialmente software libero) l’esercizio dei diritti da questa garantiti;
  • l’impossibilità per un “lavoro coperto” dalla licenza GPL di costituire parte di una efficace Misura tecnologica di protezione (questa previsione intende colpire i sistemi DRM open source, sempre che, ovviamente, incorporino MTP);
  • la rinuncia, in caso di trasferimento di un “lavoro coperto”, ad ogni potere di vietare l’elusione di misure tecnologiche di protezione che include l’uso dei “lavori coperti” e di limitare operazioni o modifiche dei “lavori”, quali mezzi di tutela legale dei diritti dei terzi contro i lavori degli utenti.

Anche la seconda bozza, però, non era riuscita ad eliminare completamente le critiche mosse da quella parte della comunità del Free Software che non vede nei DRM un pericolo così grave. E’ stato necessario, quindi, giungere ad una terza bozza delle GPLv3 che ha introdotto delle previsioni più permissive rispetto alle c.d. technical restrictions.

Nel preambolo del terzo draft della GPLv3 il riferimento ai computers è stato esteso a tutti i devices: “Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so.”

La previsione sulle technical restrictions TR è stata spostata dalla prima sezione, relativa alla definizione di codice sorgente, alla sesta sezione, relativa alla distribuzione senza codice sorgente. Modifica introdotta per far fronte alle critiche relative alla previsione che ricomprendeva nella definizione di codice sorgente anche le chiavi crittografiche eventualmente necessarie per accedervi [13].

La sesta sezione ha limitato l’applicabilità delle technical restrictions ai prodotti di consumo [14] fornendo una nuova definizione di installation information: “Installation Information’ for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made”.

Questa definizione ha voluto assicurare che il funzionamento del codice oggetto modificato non sia impedito esclusivamente per il solo fatto della modifica.

Lo spostamento delle previsioni sulle technical restrictions ha portato alla necessaria eliminazione del primo paragrafo della terza Sezione, in quanto rappresentava un’inutile duplicazione, sia rispetto alla nuova previsione contenuta nella sesta sezione, sia rispetto al più generale divieto di “ulteriori restrizioni” contenuto nel terzo paragrafo della decima sezione: “you may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it”.

Nel IV paragrafo sono state introdotte due importanti modifiche: da una parte si precisa che il distributore rinuncia al potere di impedire l’elusione delle misure tecnologiche di protezione, solamente nella misura in cui tale elusione è effettuata nell’esercizio dei diritti riconosciuti dalla licenza con riferimento ad un “lavoro” coperto dalla stessa; dall’altra si è aggiunto che il distributore rinuncia a qualunque possibilità di limitare il funzionamento o la modifica del “lavoro”, quale meccanismo di tutela non solo dei diritti dei terzi, ma dei propri “diritti” riconosciuti dalle norme anti-elusione della disciplina sul copyright. Tale aggiunta è stata necessaria in quanto anche il distributore spesso ha il potere di azionare in giudizio le norme anti-elusione.

Nella versione definitiva della GPLv3, The Last call draft, viene modificato, rispetto al terzo draft, solo il titolo del terzo paragrafo, che non fa più riferimento alle misure tecnologiche, ma più in generale alle leggi anti-eluzione, che tutelano dal punto di vista legale le stesse misure: Protecting Users’ Legal Rights From Anti-Circumvention Law.

In conclusione, The Last call draft non contiene c1ausole contro i sistemi DRM, ma si occupa delle misure tecniche contenute nei devices, che impediscono agli utenti di esercitare le libertà concesse loro dalla stessa licenza [15], richiedendo al licenziante di fornire tutte quelle informazioni necessarie (installation information) per poter eseguire versioni modificate del software GPL sui devices dell’utente.

CONCLUSIONI: IL DRM È UN BENE O UN MALE?

I sistemi DRM possono avere effetti positivi e negativi per gli utenti/consumatori. Tali sistemi, infatti, oltre ai noti problemi relativi alla privacy, alla tutela dei consumatori ed alla compatibilità con alcune disposizioni del diritto d’autore, hanno permesso la creazione di nuovi modelli di mercato e la possibilità di prestare tutta una serie di nuovi servizi.

Attraverso i sistemi di gestione automatizzata dei diritti, l’industria culturale sta dando maggiore risalto alla personalizzazione dei contenuti offerti e alla differenziazione dei prezzi/licenze permettendo al consumatore di pagare un contenuto in proporzione all’effettivo utilizzo (es. l’acquisto on-line di un determinato brano musicale anziché dell’intero CD), inoltre si stanno creando le basi per la c.d. superdistribuzione, modello di mercato in cui chiunque si trasforma da utente a distributore dei contenuti (reseller).

Ovviamente tali nuovi scenari necessitano di tecnologie in grado di garantire sia i titolari dei diritti sui contenuti, sia gli utenti/consumatori e vedono gli standard tecnologici sembrano l’unica soluzione possibile per trovare un equilibrio tra queste due forze.

Anche la Commissione Europea è convinta che proprio nel DRM risieda la risposta da dare alla pirateria: “Per rendere la distribuzione digitale più sicura e sostenibile sono necessari sistemi efficaci di gestione digitale dei diritti atti a gestire e proteggere i contenuti digitali”16. Senza dimenticare uno dei maggiori problemi legati all’applicazione del DRM, l’interoperabilità, la Commissione aggiunge: “se tuttavia si teme una mancanza di interoperabilità o di standardizzazione dei sistemi di gestione dei diritti, a lungo termine la diffusione dei servizi e dei dispositivi per i contenuti digitali può risultare frenata”.

Il DRM quindi è un bene o un male? La riposta alla domanda sta in come vengono utilizzati questi sistemi.

Non bisogna dimenticare, infatti, che i sistemi DRM possono limitare fortemente molte libertà degli utenti/consumatori relative all’impiego dei contenuti digitali, alla libertà di scelta tra diversi distributori ed alla sfera privata degli individui.

Note

[1] R. STALLMAN, sopra citato.

[2] Qualcosa di simile ad un DRM è già incorporato nelle componenti tecnologiche alla base di alcune iniziative ispirate all’Open Source. Linus Torvalds ha aperto la possibilità di includere sistemi DRM nel sistema operativo Linux, che tral’altro già include un sistema integrato nel proprio kernel che prima di caricare qualsiasi modulo verifica se il modulo stesso è compatibile con la GPL. Nelle tecnologie per le licenze Creative Commons si ricorre al Resource Description Framework (RDF) ed al sistema di metadati Dublin Core per esprimere i permessi concessi al titolare del copyright in un linguaggio leggibile dal computer. Viene adoperato qualcosa di molto simile ad un Right Expression Language (REL) utilizzato per definire le regole di utilizzo nell’ambito dei DRM.

[3] R. CASO, Digital Rights Management. Il commercio delle informazioni digitali tra contratto e diritto d’autore, Trento 2006, par 1.7, Software open source e DRM pag. 49 (http://www.jus.unitn.it/users/caso/pubblicazioni/DRM/homeDRM.asp).

[4] ESEMPI DI DRM OPEN SOURCE:

OSS CHE UTILIZZANO DRM

[5] Piu precisamente da Richard Stallman ed Eben Moplen.

[6] The GNU Project was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system. Variants of the GNU operating system, which use the kernel called Linux, are now widely used; though these systems are often referred to as “Linux”, they are more accurately called GNU/Linux systems. GNU is a recursive acronym for “GNU’s Not Unix”; it is pronounced guh-noo, approximately like canoe.

[7] Anche se per la distribuzione gli utenti devono comunque rispettare le prescrizioni dalla licenza stessa.

[8] Vedi l’accordo tra Microsoft e Novel.

[9] Un sistema DRM che si limiti a gestire i diritti morali dell’autore sarebbe completamente compatibile con Ie previsioni della GPLv3 I draft.

[10] Applicando, infatti, una previsione anti-DRM a Linux, questo sarebbe stato esc1uso da buona parte del mercato dell’intrattenimento che utilizza proprio i sisterni DRM come strumento di gestione digitale dei diritti e come misura tecnologica di protezione. Senza considerare poi che 10 stesso sistema Linux prevede nel proprio Kernel un sistema che controlla la compatibilità con la GPLvII dei software.

[11] Stallman definisce i sistemi di Trusted Computing: “Treacherous Computing”.

[12] S. BISI, Brevi considerazioni sulla gpl v.3: profili giuridici, politici e tecnologici in Ciberspazio e diritto, 2006, fasc. 4 pag. 441 – 462.

[13] In questo modo e stato possibile anche introdurre delle previsione sulle “further restrictions” nei paragrafi 10 e 11.

[14] A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. [In cases of doubt concerning whether an item is a “consumer product”, the interpretation of the Magnuson-Moss Warranty Act, 15 U.s.e. 2301 et seq., shall provide the basis for interpretation, regardless of the choice of law determination for this License as a whole].

[15] Tivo-izzazione

Tags:


About the Author



Back to Top ↑