Google: copyright, c'è motore e motore

Una squadra legale di BigG è intervenuta nel corso del processo in appello contro il search engine canadese IsoHunt. Si teme la possibile estensione di un'eventuale condanna a motori di ricerca legali come quello di Mountain View

Roma – Un’amicizia forse preziosa, offerta di recente ad una corte d’appello californiana. Una squadra legale di Google ha così fatto la sua comparsa nel corso del secondo atto di un processo infuocato, scatenato ormai cinque anni fa dagli alti rappresentanti della Motion Picture Association of America (MPAA).

Alla sbarra era finito Gary Fung, fondatore e CEO del celebre motore di ricerca canadese IsoHunt. Un search engine dedicato esclusivamente alla ricerca di file torrent , spesso sfruttati dagli utenti del web per la condivisione di contenuti in violazione delle norme a tutela del copyright.

I rappresentanti legali di BigG cercheranno allora di contribuire alla definitiva formulazione della sentenza in appello, in seguito al ricorso presentato dagli avvocati di IsoHunt. Un giudice di primo grado aveva infatti emanato un’ingiunzione permanente volta all’ eliminazione della stragrande maggioranza dei contenuti indicizzati .

Lo stesso Fung aveva però sottolineato come non ci fossero particolari differenze tra il suo motore di ricerca e quello della Grande G. Un assunto adottatto anche dai legali di The Pirate Bay : entrambi i search engine si limiterebbero a restituire agli utenti contenuti presenti altrove.

Google non aveva mai sentito la particolare esigenza di intervenire in questo tipo di processi, cercando di rimanerne fuori il più possibile. Già i rappresentanti di IFPI avevano spiegato alla difesa di The Pirate Bay come Google collabori ogni giorno alla tutela online del diritto d’autore.

Ma questa volta l’azienda di Mountain View ha deciso di diventare amica della corte . In primis perché interessata alle potenziali implicazioni del caso nella generale interpretazione – e relativa applicazione – del cosiddetto safe harbor . Ovvero del porto sicuro per gli intermediari garantito dal famigerato Digital Millennium Copyright Act (DMCA).

Potrebbe sembrare un intervento favorevole alle future sorti di IsoHunt, e invece no . I legali di Google hanno sottolineato come il search del torrentismo sia da considerare a tutti gli effetti un servizio pirata . Responsabile – anche se in maniera indiretta – della violazione sistematica del diritto d’autore.

Quello che preoccupa realmente Google è la possibile estensione di una sentenza favorevole a MPAA. In ballo ci sarebbe il delicato equilibrio tra protezione del copyright e la necessità di innovare a livello tecnologico . In sostanza, filtri e forbici potrebbero mettere a rischio servizi leciti come YouTube.

E qui l’interesse di Google è evidente, in prossimità dell’appello del caso scatenato dai legali del colosso Viacom. Il conglomerato mediatico aveva presentato il suo ricorso dopo la vittoria in primo grado del Tubo, ritenuto non responsabile delle violazioni commesse dai suoi utenti.

Pare che IsoHunt non abbia particolarmente gradito l’intervento di BigG, che pure è accorso in parte a difesa del search engine . La questione safe harbor – e quindi DMCA – dovrebbe essere trattata in maniera separata da quella relativa all’incitamento alla violazione del copyright .

In altre parole, BigG ha sottolineato come IsoHunt sia certamente colpevole perché più volte indifferente alle richieste di rimozione effettuate dai signori del copyright . Ma la negazione del porto sicuro per gli intermediari non dovrebbe essere direttamente collegata con l’accusa di incitamento volontario alla violazione del diritto d’autore.

Mauro Vecchio

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • MacBoy scrive:
    Ma...
    Come funziona? Viene distribuito codice oggetto o c'è una compilazione JIT?Cioè funziona solo su x86 o potenzialmente su tutte le architetture?
    • Googler scrive:
      Re: Ma...
      E tu lo chiedi qui? (rotfl)
    • bubba scrive:
      Re: Ma...
      - Scritto da: MacBoy
      Come funziona? Viene distribuito codice oggetto o
      c'è una compilazione
      JIT?codice oggetto direi
      Cioè funziona solo su x86 o potenzialmente su
      tutte le
      architetture?Native Client modules are operating system independent, not (yet) proXXXXXr independent. Therefore, you must compile separate versions of the Native Client module for x86-32-bit, x86-64-bit, and other instruction sets.Siccome l'SDK fa uso di gcc, in teoria si puo compilare per le tante architetture supportate... ma niente e' pronto in tal senso. Il native client e' poi dentro Chrome (che NON so su quante arch esista... ma immagino ci sia solo per x86)
      • MacBoy scrive:
        Re: Ma...
        - Scritto da: bubba
        Native Client modules are operating system
        independent, not (yet) proXXXXXr independent.
        Therefore, you must compile separate versions of
        the Native Client module for x86-32-bit,
        x86-64-bit, and other instruction
        sets.
        Siccome l'SDK fa uso di gcc, in teoria si puo
        compilare per le tante architetture supportate...
        ma niente e' pronto in tal senso. Il native
        client e' poi dentro Chrome (che NON so su quante
        arch esista... ma immagino ci sia solo per
        x86)Allora mi sembra una cosa decisamente inutile e poco "web".Se voglio un'applicazione nativa che gira solo sul mio computer, non mi serve farla girare dentro un browser. Preferisco anche le API native, grazie.
        • pippO scrive:
          Re: Ma...
          - Scritto da: MacBoy
          - Scritto da: bubba

          Native Client modules are operating system

          independent, not (yet) proXXXXXr independent.

          Therefore, you must compile separate versions of

          the Native Client module for x86-32-bit,

          x86-64-bit, and other instruction

          sets.

          Siccome l'SDK fa uso di gcc, in teoria si puo

          compilare per le tante architetture
          supportate...

          ma niente e' pronto in tal senso. Il native

          client e' poi dentro Chrome (che NON so su
          quante

          arch esista... ma immagino ci sia solo per

          x86)

          Allora mi sembra una cosa decisamente inutile e
          poco
          "web".
          Se voglio un'applicazione nativa che gira solo
          sul mio computer, non mi serve farla girare
          dentro un browser. Preferisco anche le API
          native,
          grazie.Presto telefona SUBITO a google, un genio come te non possono farselo scappare :D
  • ech3l0n scrive:
    Dopo Microsoft e gli ActiveX...
    Speriamo che in Google tengano sempre BEN PRESENTE la dura lezione che noi tutti abbiamo subìto quando Microsoft introdusse gli ActiveX nel proprio browser...
    • Nome e cognome scrive:
      Re: Dopo Microsoft e gli ActiveX...
      Ovvero? Che errore non dovrebbe commettere?
      • banca scrive:
        Re: Dopo Microsoft e gli ActiveX...
        - Scritto da: Nome e cognome
        Ovvero? Che errore non dovrebbe commettere?virus in autoplay (anche se per gli utonti non è necessario)
    • collione scrive:
      Re: Dopo Microsoft e gli ActiveX...
      la sandbox di nacl è fatta molto bene e le limitazioni sono davvero pesantinessun software che gira sotto native client può accedere a componenti del sistema operativo
      • KaysiX scrive:
        Re: Dopo Microsoft e gli ActiveX...
        ...a meno che qualcuno riesca ad implementare degli Human Handled Objects (HHO -
        H20) con cui superare le difese del native Client (NaCl)Sarebbe una soluzione geniale... ;)
      • iRoby scrive:
        Re: Dopo Microsoft e gli ActiveX...
        - Scritto da: collione
        nessun software che gira sotto native client può
        accedere a componenti del sistema operativoMmmhh :/Però c'è da dire che ormai molta della vita di un individuo si svolge in rete, e il browser è la sua finestra sulla rete.Penso a quelle parti del browser che un software malevolo per Native Client potrebbe accedere: password di siti, dati nei form, cookie, ecc. Anche un key logger nel browser.
    • hp sucks scrive:
      Re: Dopo Microsoft e gli ActiveX...
      una trollata andata a male:innanzi tutto andava fatta sulla notizia originale ai tempi(google fa il native client) e non la notizia derivata ( google migliora il native client)e poi non si può dire "dopo m$ speriamo che qualcuno non faccia gli stessi errori" m$ è l'errore, se fa qualcosa .. stai pur sicuro che l'errore c'è (window vista, xp, seven, otten, .net, .not, word, excel eccetera) se neghi m$ neghi anche l'errore!
Chiudi i commenti