Citaat | Parket bij de Hoge Raad 29 mei 2015
Onder 2.1.33 Parket bij de Hoge Raad 29 mei 2015
Een alinea uit Parket bij de Hoge Raad 29 mei 2015, ECLI:NL:PHR:2015:729.
Deze uitspraak geeft volgens mij nog geen finale duidelijkheid (buiten redelijke twijfel) over de vraag hoe dat dan zit in de context van indexeringssites als TPB. Bij positieve beantwoording van de hiervoor bij onderdeel Ia voorgestelde prejudiciële vraag of TPB meedeelt aan het publiek past het blokkadebevel wel naadloos in Telekabel Wien. Dan maakt TPB immers zelf openbaar met gebruikmaking van de diensten van de providers en moeten die providers in beginsel een blokkadebevel van TPB kunnen krijgen. Zolang dat niet is uitgemaakt of negatief wordt beslist, geldt dat niet zonder meer. Het kost enige spankracht van het denken om dat helder te zien, maar in de pleitnota in cassatie van Ziggo c.s. in 3.8 wordt het denk ik op juiste wijze op scherp gezet: “Wat Brein wil is één “dienst” verbieden waarmee geen inbreuk wordt gemaakt, alleen maar omdat die dienst kan vergemakkelijken dat vervolgens met een andere “dienst”, die ongemoeid wordt gelaten, wel inbreuk wordt gemaakt”. Ik ben er bepaald niet zeker van of op grond van de gegeven ruime uitleg in Telekabel Wien van “inbreuk” ook zonder dat sprake zou zijn van meedelen door TPB een op art. 8 lid 3 van de richtlijn te baseren blokkadebevel van TPB mogelijk is, op grond van de door Brein bepleite redenering: er is dan immers toch sprake van “inbreuk” op het internet. Dat lijkt op gespannen voet met de bedoeling van de Nederlandse wetgever te komen, als je de parlementaire geschiedenis van art. 26d Aw tot je laat doordringen. Overigens is dat bij positieve beantwoording van de bij onderdeel Ia te stellen prejudiciële vragen niet beslissend, want art. 26d Aw moet richtlijnconform worden uitgelegd.
Zelf controleren
Voor dit citaat hoeft niemand Bron op zijn woord te geloven. Het document dat rechtspraak.nl publiceerde, staat op https://bron.page/api/v1/blobs/cb6e89026e84502023e937372685fdc7e2a60df44634417f5caff0c063bbfabd. Wie het ophaalt en de SHA-256 ervan berekent, krijgt cb6e89026e84502023e937372685fdc7e2a60df44634417f5caff0c063bbfabd, en de alinea staat in dat document op bytes 88114 tot 90032.
$ curl -s https://bron.page/api/v1/blobs/cb6e89026e84502023e937372685fdc7e2a60df44634417f5caff0c063bbfabd | shasum -a 256