Il carcere per gli ingegneri è allarmismo sui DRM?

Quanta innocenza nelle parole del laureando ingegnere informatico che scrive a Punto-informatico. La parte che meglio descrive la sua innocenza è:

Attualmente i DVD-Video sono protetti da CSS, Content Scrambling System, basato sulla crittografia dei settori del DVD. L’algoritmo è stato spezzato grazie al Reverse Engineering di un software per la riproduzione, che contiene il DeCSS necessario a leggere il DVD. Una volta violato il CSS, è possibile tranquillamente copiarlo come non-protetto.

Il nocciolo del contendere sta tutto qui: il CSS è un algoritmo banale che è stato spezzato in poco tempo. Ma chi l’ha spezzato ha rischiato il carcere per aver rivelato la debolezza di una ‘misura tecnica di protezione’! E inoltre, non è vero che si possa copiare il codice deCSS dappertutto perché così facendo si infrangono le leggi.

Facciamo chiarezza: il problema di Treacherous Computing e Digital Restrictions Management non sono affatto un problema tecnico, ma sono principalmente un problema sociale e politico. Posso anche pensare che lo strumento tecnico sia neutrale, ma sono le leggi come IPRED e Urbani che tolgono la neutralità .

Perché allora le FSF hanno dichiarato guerra alle soluzioni tecniche, TC e DRM? Perché le FSF scrivono codice, non leggi. La comunità  non riesce (ancora) a farsi udire degnamente dai governi, ma nel frattempo il software libero è diventato utile alle industrie, agli affari. Allora usiamo lo strumento che abbiamo per fare leva e scardinare un sistema ingiusto e pure un po’ idiota, sbilanciato verso i privilegi dei distributori di musica e film.

Advertisements

2 thoughts on “Il carcere per gli ingegneri è allarmismo sui DRM?

  1. Stefano,
    so che bisognera’ discutere e che nulla e’ dato per scontato in queste cose. Per il momento mi sento di poter dire quanto segue. Tu dici che vuoi fare chiarezza e io sono d’accordo e ci provo, nel mio piccollo. Innanzitutto distinguiamo tra TC e DRM. Io posso parlare di DRM, di TC meno, perche’ non l’ho ancora studiato tanto approfonditamente da essere sufficientemente confidente di non dire stupidaggini. Poi, quando avro’ studiato per bene anche il TC forse potro’ dire qualcosa anche di questo.

    Sotto il DRM, distinguerei tra il tool e le licenze gestite dal tool. Cosi, giusto per rendere piu’ chiaro da che parte stiano i cattivi. Per me i cattivi stanno dalla parte di chi definisce le licenze, per te stanno (anche) dalla parte di costruisce il tool. E allora entro ulteriormente nel merito del tool e dico che hai ragione: ci sono DRM molto cattivi (ma anche molto stupidi) che sono proprietari e non interoperabili. Ma ci sono anche DRM che sono interoperabili e che in questo modo rispettano alcuni dei diritti tradizionali acquisiti nel tempo dai consumatori. Se poi oltre che interoperabili sono anche aperti, allora puoi metterci dentro il naso e verificare tutto cio’ che vuoi. Il resto dei diritti degli utenti/clienti/consumatori sono le licenze a stabilirlo. Io credo che le licenze della FSF e di CC (quelle che permettono) siano superiori rispetto a quelle che finiscono sotto il diritto d’autore tradizionale (quelle che escludono) e credo che grazie a questa superiorita’ intrinseca riusciranno nel medio e lungo periodo a prevalere. A dire la verita’ credo che un DRM interoperabile ed aperto possa persino contribuire ad una piu’ veloce affermazione delle licenze che permettono (mi piace molto la definizione di permesso d’autore di Antonella Beccaria).

    Beh, e’ solo un inizio di discussione. Ti prometto che prima o poi il TC me lo studio per bene…..

    Mimmo

    Like

  2. Sì, ma non mi spiego come fa un DRM interoperabile e software libero, il tool, a essere ancora efficace nel discriminare le licenze se consente (come dovrebbe) il cambio del codice del tool? Questo io non lo so spiegare. Per esempio, potrei modificare il tool per consentire l’esportazione del file dal formato di iTunes ad un ogg/vorbis senza altre informazioni. Che fine fa il DRM allora? È una ‘sola’?

    I casi sono almeno tre: o il tool è interoperabile ed è software libero, allora è inefficace nella gestione del DRM. Oppure il codice del tool, se modificato, non funziona (tramite il controllo dell’hardware TC)–e quindi non è più software libero. O, terzo caso, il codice del tool non consente un cambio di formato, quindi non è software libero. Queste sono le contraddizioni tecniche che non ho trovato spiegate da nessuna parte.

    Poi c’è invece l’avversione totale e incondizionata alle leggi sui DRM, come scrivo nel post. E lì sono certo che sei d’accordo con me. La strategia di FSF al momento è di usare il fattore tecnico, l’unica nostra leva, per scardinare il sistema legale.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s