Gaia Bottà

USA, gli avvoltoi del copyright pagheranno

Accusati di operare in violazione della privacy e di molestie telefoniche nel proporre accordi per presunte violazioni del copyright, Rightscorp e l'industria che assiste tendono la mano ai presunti pirati. Pur di non essere riconosciuti colpevoli

Roma - Battono le reti del file sharing alla ricerca di opere condivise illegalmente e di indirizzi IP da rastrellare, affinché siano identificati con l'intestatario della connessione Internet, al quale viene proposto un accordo per chiudere paventate controversie con i detentori dei diritti. Gli intermediari della tutela del diritto d'autore, di cui Rightscorp rappresenta uno dei soggetti più attivi, sono da tempo tenuti sotto osservazione dalla giustizia di mezzo mondo per il loro controverso modus operandi, che prevede l'attribuzione di responsabilità ad un indirizzo IP e non ad un individuo, che prevede una pressione sui presunti pirati che ha il retrogusto dell'estorsione. Proprio le pratiche con cui si è rivolta ai netizen per sollecitare i risarcimenti hanno costretto Rightscorp a risarcire coloro che sono finiti nella sua rete.

Era il 2014 quando diversi utenti californiani si erano rivolti alla giustizia per denunciare Rightscorp e i detentori dei diritti che serve, fra cui Warner e BMG, per l'illiceità delle attività di identificazione degli indirizzi IP, le modalità minacciose e sfiancanti con cui si propongono gli accordi per scongiurare l'apertura di un contenzioso.

Ora, a più di un anno dall'avvio della class action, gli utenti, Rightscorp e i detentori dei diritti le cui opere sono state tracciate sulle reti P2P hanno raggiunto un accordo stragiudiziale che potrebbe archiviare ogni contenzioso, sia quelli in materia di violazione del diritto d'autore, sia quelli relativi agli sconfinamenti operati da Rightscorp. L'industria del copyright, pur non ammettendo alcuna colpevolezza, ha accettato di mettere da parte i sospetti sollevati nei confronti di 2059 netizen con le indagini di Rightscorp, di interrompere i contatti con coloro che non abbiano dato il proprio consenso e di offrire ai soggetti identificati una compensazione per il disturbo: 450mila dollari al netto delle spese legali.
Si tratta di un disturbo condannabile ai sensi del Telephone Consumer Protection Act (TCPA), che protegge i cittadini statunitensi dalle molestie telefoniche, come le chiamate automatiche con voce pre-registrata, i messaggi in segreteria telefonica e le telefonate da parte di operatori umani con cui sono stati tempestati i numeri degli abbonati identificati dagli ISP a partire dagli indirizzi IP segnalati da Rightscorp o i netizen che abbiano contattato Rightscorp a seguito della notifica di violazione a mezzo email. Se la legge fissa i risarcimenti a 500 dollari a favore del danneggiato, triplicabili in caso di condotta grave, Rightscorp e i detentori dei diritti sborseranno 100 dollari a favore di ogni cittadino raggiunto dalle comunicazioni che ne faccia richiesta.

Il cittadino della Rete, inoltre, dovrà dichiararsi non responsabile di alcuna violazione del diritto d'autore: in questo modo le accuse nei suoi confronti verranno deposte. È questo, secondo i detentori dei diritti, l'aspetto più conveniente dell'accordo per i cittadini statunitensi che hanno aderito alla class action: "Rightscorp ha identificato 126.409 presunti atti di violazione, che avrebbero potuto tradursi in risarcimenti tra i 94,8 milioni di dollari e i 19 miliardi di dollari". Cifre a cui detentori dei diritti e gli intermediari al loro servizio hanno rinunciato, pur di scrollarsi di dosso l'accusa di aver agito illegalmente.

Gaia Bottà
Notizie collegate
9 Commenti alla Notizia USA, gli avvoltoi del copyright pagheranno
Ordina
  • Apple è in difficoltà dopo la sentenza di un giudice di san francisco!
    http://www.repubblica.it/ambiente/2016/01/07/foto/...
    non+autenticato
  • Ormai ho capito come prenderli. Ogni volta che mi chiama qualcuno per proporre o minacciare, poso delicatamente la cornetta o lo smartphone a faccia in giù, e lo lascio parlare.
    Dopo cinque minuti, riattaccano. Feel the sound of silence, asshole!
    non+autenticato
  • Per questa gente ci vuole una punizione esemplare ed esecuzione pubblica.
    Dei loro soldi non ce ne frega niente: devono pagare con la loro testa!
  • - Scritto da: panda rossa
    > Per questa gente ci vuole una punizione esemplare
    > ed esecuzione
    > pubblica.
    > Dei loro soldi non ce ne frega niente: devono
    > pagare con la loro
    > testa!
    oppure una cosa piu' sottile...
    con ognuno di quei $100 restituiti, gli utenti dovrebbero comprarci una seedbox e poi sventolare uno screenshot.... travaso di bile e ricovero assicuratoOcchiolino
    non+autenticato
  • - Scritto da: panda rossa
    > Per questa gente ci vuole una punizione esemplare
    > ed esecuzione
    > pubblica.
    > Dei loro soldi non ce ne frega niente: devono
    > pagare con la loro
    > testa!
    naaahhh
    troppo poco prima un bel periodo di almeno un mese alla gogna... poi se una testa ce la avranno ancora.....
    non+autenticato
  • - Scritto da: panda rossa

    OT, tu che sei utente Linux de sempre, che mi dici di questo?
    https://bugzilla.kernel.org/show_bug.cgi?id=12309
    A me succede se infilo un chiavetta USB, a faccio un copia/incolla, seguito da un altro copia incolla*: risultato il sistema freeza completamente finché non finiscono tutti i flush dei dati.


    Pensavo capitasse solo a me oppure che fosse una roba che avrebbero corretto in un attimo e invece... scopro che 8 anni che è così e non si prospettano fix.

    Ci sono workaround?



    *
    L'OS dice che il primo è finito, in realtà so che sta ancora flushando perché ha cachato lo stream di dati da scrivere, ma io mica posso andare a fare le analisi della cache mentre uso un PC, mi fido dell'OS, ed in ogni caso due copia/incolla contemporanei su una periferica lenta non devono produrre un freeze totale di tutti i file system (compreso quello virtuale montato su RAM che praticamente non ha limiti di velocità!)
    non+autenticato
  • - Scritto da: linaro inesperto
    > - Scritto da: panda rossa
    >
    > OT, tu che sei utente Linux de sempre, che mi
    > dici di
    > questo?
    > https://bugzilla.kernel.org/show_bug.cgi?id=12309
    > A me succede se infilo un chiavetta USB, a faccio
    > un copia/incolla, seguito da un altro copia
    > incolla*: risultato il sistema freeza
    > completamente finché non finiscono tutti i flush
    > dei
    > dati.

    Non sapevo di questa cosa: devo approfondire.
    Ma capita con un DM in particolare o con tutti?

    > Pensavo capitasse solo a me oppure che fosse una
    > roba che avrebbero corretto in un attimo e
    > invece... scopro che 8 anni che è così e non si
    > prospettano
    > fix.

    Strano.
    Devo leggere con calma tutto quell'incartamento.

    >
    > Ci sono workaround?

    Intanto la copia di files, soprattutto se files di grosse dimensioni, e' meglio farla con l'apposito comando e non con un copia/incolla.

    La questione sembra dovuta al fatto che trattandosi di un device esterno lento, e file molto grosso e il tempo di copia e' piu' lungo.
    E in questo tempo gli vai ad accodare un altra copia, quando invece il device e' ancora busy.


    > L'OS dice che il primo è finito,

    No, non credo che l'OS dica che ha finito. Sara' il DM che ha messo in background la copia a dire che ha finito.
    Da linea di comando il cp finisce solo quando ha finito

    > in realtà so che
    > sta ancora flushando perché ha cachato lo stream
    > di dati da scrivere, ma io mica posso andare a
    > fare le analisi della cache mentre uso un PC, mi
    > fido dell'OS, ed in ogni caso due copia/incolla
    > contemporanei su una periferica lenta non devono
    > produrre un freeze totale di tutti i file system
    > (compreso quello virtuale montato su RAM che
    > praticamente non ha limiti di
    > velocità!)

    Il processo di schedulazione e' lo stesso a prescindere dai devices.
    Se si freeza lo schedulatore, evidentemente si freeza per tutti i FS.
    Potrebbe essere codice sviluppato quando le pennette USB erano al massimo di 1 GB, e adesso che ci sono pennette da 128 GB e BDRIP da copiare il problema sta emergendo.
  • - Scritto da: panda rossa

    > Non sapevo di questa cosa: devo approfondire.
    > Ma capita con un DM in particolare o con tutti?

    dubito che capiti sui server di Silicon Valley visto che lì hanno un I/O tale che consuma un HD in poche settimaneOcchiolino
    A me però succede sistematicamente con tre distro live diverse che mi capita di usare. Una è Mint a 64 bit e altre due sono a 32 bit.
    Ho tantissima RAM, quindi non c'è problema di swap o simili.
    All'inizio pensavo fosse un problema del mio hardware, ma poi pian piano ho capito che era tutto legato al file system.

    Può essere che il fatto che booto live peggiori le cose, ma dai commenti dei tizi di cui sopra direi che succede anche a chi ha l'installazione pulita su HD.


    > Intanto la copia di files, soprattutto se files
    > di grosse dimensioni, e' meglio farla con
    > l'apposito comando e non con un
    > copia/incolla.

    questo posso provarlo.

    > La questione sembra dovuta al fatto che
    > trattandosi di un device esterno lento, e file
    > molto grosso e il tempo di copia e' piu'
    > lungo.
    > E in questo tempo gli vai ad accodare un altra
    > copia, quando invece il device e' ancora
    > busy.

    questo è chiaro.
    Infatti se faccio il secondo copia/incolla dopo un tempo accettabile (quello dei flush reale dei dati, sicuramente), tutto gira senza problemi.



    > No, non credo che l'OS dica che ha finito. Sara'
    > il DM che ha messo in background la copia a dire
    > che ha
    > finito.

    eh certo, ma usando un desktop la finestrella è quello che mi suggerisce l'OS (ok in realtà è l'UI).
    Ho pensato anche che potrei monitorare la quantità di RAM che è in fase di commit, quando è vicina a zero vuol dire che il flush è finito, ma non è una cosa comoda

    > Da linea di comando il cp finisce solo quando ha
    > finito

    questo indubbiamente mi eviterebbe accavallamenti, ma nulla toglie che altri processi, di sistema o di applicazioni che ho lanciato, potrebbero scrivere sullo stesso stesso device in cui sto copiando, producendo lo stesso problema.


    > Potrebbe essere codice sviluppato quando le
    > pennette USB erano al massimo di 1 GB, e adesso
    > che ci sono pennette da 128 GB e BDRIP da copiare
    > il problema sta
    > emergendo.

    Avevo anche pensato di disabilitare la cache, in questo modo vedrei l'avanzamento (lento ma realistico) di ogni copia...

    boh, intanto ti ringrazio per la risposta
    non+autenticato
  • - Scritto da: panda rossa
    > Strano.
    > Devo leggere con calma tutto quell'incartamento.

    A passano altri 8 anni .... Rotola dal ridereRotola dal ridere