Een lezer vroeg me:
Pinterest laat derden plaatjes publiceren op hun site. Maar ze bieden de plaatjes ook via embedlink aan. Dat betekent dat ik ze dus op mijn site kan zetten, zonder dat ik ze zelf hoef te hosten. Welke positie heb ik als de maker van dat plaatje vervolgens bij mij komt klagen dat zijn auteursrecht is geschonden?
Enige tijd terug blogde ik al over Pinterest: zij zijn niet aansprakelijk voor de foto’s die hun gebruikers (pinners?) bij hen hosten. De pinners zelf zijn dat wel natuurlijk, want zij kopiëren en herpubliceren die foto’s op de site van Pinterest. Maar hier gaat het om een net iets ander stukje: met een speciaal knopje kun je plaatjes die op Pinterest staan, embedden in je eigen blog of site.
In al wat oudere rechtspraak werd nog wel eens aangenomen dat het embedden (inline linken) van een foto vanaf andermans site tot auteursrechtinbreuk leidde. De rechtbank Rotterdam vond het in 2004 bijvoorbeeld een inbreuk om foto’s te tonen op een forumpagina “door middel van een zogenoemde deep-link”. En in 2007 vond de rechtbank Haarlem het inbreuk omdat “[h]et werk immers als onderdeel van een ander werk weergegeven [is]”.
In 2010 werden we verrast door het Gerechtshof Den Bosch dat oordeelde dat “betrekkelijk eensgezind aangenomen [wordt] dat een embedded link wel een openbaarmaking inhoudt.” Maar waar die eensgezindheid uit blijkt, ik weet het nog steeds niet.
Mede vanwege deze uitspraken is Buma/Stemra enige tijd geleden gaan roepen dat embedden van Youtubemuziek je B/S-betalingsplichtig maakt. Ik weet niet of de situaties echt vergelijkbaar zijn: bij embedden van Youtube is immers duidelijk de Youtube-player zichtbaar. Daarmee is die player niet “onderdeel van een ander werk”.
Ik denk dat dit argument ook opgaat bij het embedden van Pinterest-collecties. Die worden in de layout en vormgeving van Pinterest opgenomen, en zijn zo duidelijk een stukje dat van Pinterest afkomstig is. Pas als je individuele plaatjes direct gaat embedden (met je eigen <img src=”http://pinterest.com/example.jpg”>) zou je in de situatie terechtkomen waar deze rechtspraak over ging.
Arnoud
Ik heb nooit begrepen waarom embedden apart toestemming vereist. De compositie van de pagina vindt pas plaats op het moment dat de eindgebruiker er om vraagt, op het systeem van de eindgebruiker, en met elementen die op dat moment van de oorsprongelijke server komen die dus nog onder controle staan van iemand die ze rechtmatig ter beschikking stelt. Indien een partij embedden niet wenst heeft hij dus de keuze dat embedden te verhinderen door simpel weg de plaatjes niet te overhandigen. Alweer een overduidelijk geval van dat mensen de techniek niet begrijpen: embedden is niets anders dan een referentie naar. Als er een gewone link had gestaan was er niets aan de hand geweest (al is het natuurlijk doodeenvoudig om zo’n gewone link automatisch om te zetten naar een embedded plaatje, kijk maar wat er gebeurd als je een link in facebook toevoegd.
Een vergelijkbaar scenario is denkbaar met geluid. Ik zou een typisch muziekprogramma kunnen maken door eenvoudig weg de plaatjes aan elkaar te praten, en daarna te zeggen: ze nu plaatje X op. Ervan uitgaande dat 90% van de populaire plaatjes al bij gebruikers op hun eigen PC staan, zou ik, in plaats van dit zeggen, die instructie mee kunnen sturen in computer-leesbaar formaat, waarop de computer van die eindgebruiker het plaatje ook daadwerkelijk afspeeld vanuit de persoonlijke collectie van de luisteraar. Ik zend zelf helemaal geen muziek uit, hoef dus niets af te dragen aan de “rechthebbenden”, al is het eindresultaat voor de eindgebruiker hetzelfde: een DJ die een reeks plaatjes aanelkaar praat… Waarom zou je opeens moeten betalen omdat de informatie in computer leesbaar formaat is, en de eindgebruiker gebruik maakt van die informatie.
Bij embedden middels een aangeboden player volg ik je, maar bij dieplinken van plaatjes is het lastig. Ik kan technisch niet (met zekerheid) detecteren of een request op een plaatje op mijn site een dieplink is of niet. Referrer kun je proberen maar biedt geen zekerheid.
Verder is de discussie in zoverre relevant als A een plaatje embedt vanaf de site van B terwijl C de auteursrechten op het plaatje heeft. Dan kan B toestaan wat hij wil, de rechten van C spelen ook een rol.
@2: En dan is het raar dat bij auteursrecht iemand die te goeder trouw handelt toch verantwoordelijk wordt gehouden voor de inbreuk.
De redenatie daarachter is vast dat het moeilijk te achterhalen is wie de oorspronkelijk ‘boosdoener’ is en auteursrecht anders niet te handhaven is. Juist bij embedden is het echter heel eenvoudig om de hoster te vinden en te achterhalen of die toezeggingen waartoe hij geen recht heeft.
Het punt is dat embedden gewoon en referentie is, compleet met de instructie erbij “zoek dit plaatje nu daar-en-daar op en toon het hier” die door de ontvangende partij wordt uitgevoerd, dus helemaal niet door de verzendende partij. Als we het in mensentaal zeggen is het toegestaan, zeggen we exact hetzelfde in machineleesbare taal dan is het plotseling verboden. Wat nu als computers mensentaal steeds beter gaan begrijpen?
Het verschil tussen “deeplinken” en gewoon linken kan niemand uitleggen, waarschijnlijk betekend het gewoon “elke link die ik niet wens, maar te beroerd ben om te blokkeren of te leren hoe ik dat moet doen.” De referer header biedt inderdaad geen zekerheid, maar je kunt eenvoudig unieke links uitsturen die maar eenmalig of voor een IP adres geldig zijn, zodat links naar dat materiaal niet werken. (Al zijn referer headers goed genoeg om het grootste probleem van embedden, het gebruik van jouw resources zonder dat je daar voordeel bij hebt effectief op te lossen. Ik doe het zelf ook op mijn site.)
Jouw voorbeeld laat al zien hoe absurd de jurisprudentie op dit gebied is.
Dat concept geldt voor de meeste client-server systemen en feitelijk voor heel internet. Als je die redenatie doortrekt dan is het hacken van een computer ook niet strafbaar, de instructie werd helemaal niet door de verzendende partij (hacker) uitgevoerd maar door de ontvangende partij (computer). Feit is dat de instructie door de verzendende partij (hacker, webbouwer) is opgesteld en mijns inziens vindt op dat moment de rechtshandeling plaats.
Omgedraaid: als deeplinken altijd legaal is dan betekent dat dat de volledige auteursrecht-discussie kan worden omzeild door elk systeem wat uploaden en deeplinken toestaat te misbruiken voor het hosten van illegale content die op een andere plek wordt getoond (ge-embed). Mijns inziens vindt het feitelijke hosten van een image dan ook plaats door het systeem waar de <img src=…> code staat, en is de locatie van het feitelijke plaatje irrelevant. (Voor de bijdehandjes onder ons kan dit concept worden doorgetrokken in geval van een iframe of andere embedding).
Referrer check biedt meer zekerheid dan je vanuit de techniek intuitief denkt. Kort gezegd kan je wel detecteren dat een request een deeplink is. Je kan alleen niet detecteren dat het GEEN deeplink is. Het probleem is inderdaad dat de referrer leeg kan zijn als gevolg van client-instellingen, proxy filters of protocol-restricties (https) en het onzeker is of er gedeeplinked wordt of niet. Maar indien de referrer niet leeg is en ook niet matched met je eigen host, kan je server-side wel degelijk constateren dat er sprake is van deeplinken. False positives, waarbij er geen sprake is van deeplinken maar je script dit wel denkt, zijn vrijwel niet mogelijk, en dat biedt mogelijkheden. Zolang je een lege referrer maar fail-open afhandelt (toch plaatje tonen) is er niks aan de hand.
Voor iemand die deeplinkt is dit voldoende maatregel om hem van deeplinken te weerhouden. De deeplink-detectie zal inderdaad niet 100% werken en soms een false negative geven bij een lege referrer (in dat geval wordt het gedeeplinkte plaatje toch getoond), maar in 90% van de gevallen werkt deze wel en ziet de eindgebruiker geen plaatje. Een eindgebruiker kan dit altijd omzeilen door zijn referrer leeg te laten, maar de eerste website die een instructie ‘beste gebruiker, als je images wilt zien dien je de referrer uit te zetten’ acceptabel vindt, moet ik nog tegenkomen.
@5:”Feit is dat de instructie door de verzendende partij (hacker, webbouwer) is opgesteld en mijns inziens vindt op dat moment de rechtshandeling plaats.” Ja maar als de instructie luidt “Een leuk plaatje bij deze post, klik hier.” En de link opent het plaatje in een apart venster dan mag het wel. Ook al link je direct naar de url van het plaatje en niet naar een pagina waar het opstaat. Het is raar dat als je dat plaatje dan embed het ineens anders is. Beide zijn instructies om een plaatje te bekijken en de één mag en de ander niet.
Nog los van het feit dat ik toen ik nog FF gebruikte een addin had die plaatjes al liet zien als ik over de link hoverde. Het is vanaf daar een kleine stap naar een addin die plaatjes links clientside embed. En dan mag het opeens weer wel …
Het blijft gewoon tot vreemde situaties leiden. Het is een stuk eenduidiger om gewoon te stellen dat alleen degene die een plaatje op een server heeft gezet openbaar maakt en embedden geen openbaar maken is. Dan zorg je verder zelf maar als rechten hebbende dat je embedden onmogelijk maakt en eis je van licentienemers dat zij dat ook doen. Dat zorgt voor helderheid wie waar voor verantwoordelijk is en voorkomt het risico dat je opeens een brief met een of andere vordering krijgt en een dure gang naar de rechter om duidelijkheid daarover te verkrijgen.
Als ik zeg ‘een interessant artikel, klik hier’ en het artikel opent op de oorspronkelijke site, dan mag het wel. En als ik zeg ‘hier is een leuk artikel’ en ik type het daaronder over, dan mag het niet. Het is raar, dezelfde tekst, en als ik ernaar link is er niets aan de hand, en als ik het overtype dan is het foute boel.
En het ís ook raar. Daarom is de term ‘nieuwe openbaarmaking’ bedacht. En dan gaat de context waarin je iets toont ineens een rol spelen.
NB ik vind het onhandig dat elke discussie over de technische werking van het internet beinvloed wordt door ‘jamaar ik heb een Firefox plugin en die..’. Die plugin gedraagt zich niet conform de RFC’s en je kan dan betogen dat degene die de content publiceerde daar geen rekening mee hoeft te houden. Ik ben dus geneigd om te zeggen “dat telt niet, vriend”.
Het onderliggende probleem hier is, net als bij het cookies-verhaal, dat de wetgeving gemaakt wordt door mensen die A) Geen verstand hebben van internet, en B) er op een obstinate manier geen verstand van willen hebben. Dit leidt tot wetgeving die door mensen die wel iets weten van de onderliggende techniek absurd wordt gevonden, en waar ze dan omheen werken (Wat mogelijk weer een tegenreactie oproept, enz.), of die de technische infrastructuur dusdanig ondermijnen dat feitelijk handhaving van die wetgeving het einde van het internet of de technologie zou betekenen. Natuurlijk kun je “gedogen” en alleen ingrijpen als iets je tot last wordt, maar dat is een bewijs van politieke onmacht en neigt naar willekeur, allebei dingen die je niet graag wil hebben in een rechtsstaat.
Dit zie je ook met allerlei aspecten van het handhaven van het auteursrecht. Omdat private systemen nu de capaciteit hebben de complete catalogus van grote uitgevers in enkele minuten te delen, is het niet meer mogelijk het traditionele auteursrecht te handhaven, tenzij je de onderliggende technologie zelf in de ban doet. Zelfs in een land als Noord-Korea breekt de technologie nu door het zeer strakke net heen, ondanks draconische straffen. Je ziet steeds meer voorstellen voor extreme wetgeving die zo’n beetje met alle burgerrechten korte metten maken om toch maar dat auteursrecht te handhaven, en die gaan allemaal niet werken, tenzij je ook compleet afstand wil doen van de techniek en alle erbij horende voordelen…
@7: Als je het overtypt, dan maak je een kopie op jouw server en heb je inderdaad een nieuwe openbaarmaking. Ik denk niet dat iemand je daar ooit in zal tegenspreken.
Het idee bij embedden is dat juist geen nieuwe kopie maakt, maar iets dat al beschikbaar is op het internet binnen jouw pagina weergeeft. En dit doe je niet door het er zelf neer te zetten, maar door jouw gebruiker het op te laten halen op de oorspronkelijke plek waar het openbaar gemaakt is. De redenatie dat dit een openbaarmaking is is krom en het gevolgd van digibeten die wetten maken die niet aansluiten op hoe het internet werkt.
Het gevolg is onduidelijkheid die totaal niet nodig is.
Je kan plugins natuurlijk cheaten en je niet aan de standaard houden noemen. Maar het is vaak genoeg gebeurd dat plugin functionaliteit later geintegreerd wordt in de browser.
Het doel van het voorbeeld is meer om te laten zien wat een vreemde situatie het is. Embed de maker van een webpagina een plaatje in plaats van dat hij een link gebruikt, dan mag het niet. Embed de gebruiker een plaatje met hetzelfde eindresultaat is er niets aan de hand.
Wat dat in de hand werkt is dat deze functionaliteit uiteindelijk gewoon naar de browser verplaatst worden en dat website makers links toevoegen die met een browser optie omgezet kunnen worden in embeded content. Het is dan de gebruiker die in zijn internet opties aangeeft dat hij waar mogelijk wil embedden en opeens hebben we geen probleem meer? Wederom een vreemde situatie.
Het enige wat eenduidig en niet vaag is, is openbaarmaking koppelen aan de persoon die het werk op een server zet. En die persoon zelf verantwoordelijk te laten zijn voor het wel of niet toestaan van embedden.
Het idee bij embedden is dat juist geen nieuwe kopie maakt, maar iets dat al beschikbaar is op het internet binnen jouw pagina weergeeft.Ik snap wel wat embedden is hoor. Maar overtypen past ook in de definitie ‘iets dat al beschikbaar is op het internet binnen jouw pagina weergeeft’. Mijn punt is dat embedden een shortcut is, een technisch truukje. Als embedden technisch niet bestond (stel dat een img src altijd een relatief pad zou moeten hebben) zou je een kopie van de image/film moeten maken.
Als er een HTML element bestond waarmee je overtypen kon vermijden door naar een andere URL, offset en lengte te verwijzen, waarbij het effect was dat die bytes op de plek van de tag in het huidige document werden ingevoegd, een soort supergetarget iframe, dan zou overtypen ook nooit meer hoeven. Dus als ik zo’n tag ontwikkel en ik krijg hem in de browsers, dan zijn meteen wereldwijd alle auteursrecht-discussies van de baan?
Dat zit een beetje in de trant van ‘een rechter die een uitspraak doet snapt niets van internet’. Ik houd daar niet zo van. Ik denk dat de meeste wetten die hiermee te maken hebben prima technisch zijn getoetst en ik vind het argument ‘het is niet in mijn straatje en ik snap het wel dus de wetgever/rechter snapt het niet’ erg kinderachtig. Misschien zegt de wetgever / rechter wel eens met gestrekt been ‘jammer dan joh’ om op voorhand al wat bijdehandjes buitenspel te zetten.< copybytes src="http://blog.iusmentis.com/2012/06/15/" startbyte="1024" length="20" />Anyway, mijn betoog was dat ik vind dat context wel degelijk een rol mag spelen in een auteursrechtelijke discussie* en ik vind de term ‘nieuwe openbaarmaking’ zeker niet perfect. Maar ik denk wel dat het het dichtste in de buurt komt bij iets wat een goede basis kan zijn voor het bepalen van inbreuk.
Als je mijn of andermans betoog krom wilt noemen dan mag dat, maar beargumenteer dat dan alsjeblieft.
Dan hebben we wel degelijk een probleem. Als zulke functionaliteit wijdverbreid is zal de intentie van de webmaster eerder als opzet betiteld worden.
*)NB dat betekent helemaal niet dat ik in het kamp Tim Kuik of BUMA/STEMRA te vinden ben. Maar er zijn genoeg situaties waarin embedden absoluut wel inbreuk kan betekenen.
Volgens mij is de fundamentele kwestie wie er verantwoordelijk is voor de handelingen die door een computerprogramma worden verricht. In dit geval is het computerprogramma een HTML-pagina (een IMG tag is immers een soort instructie aan een computer om een plaatje binnen te halen en weer te geven).
Misschien moet je het zo zien: * verschillende mensen doen handmatig bepaalde handelingen * als gevolg van die handelingen samen starten er automatische processen * de gevolgen van die automatische processen zijn soms ongewenst (bijv. auteursrechtinbreuk)
Ik denk dat die ‘daders’ die de gevolgen hadden kunnen voorzien verantwoordelijk zijn.
Er zijn wel problemen met dit concept: * Er zijn combinaties waarbij geen van de ‘daders’ de gevolgen had kunnen zien, omdat niemand had kunnen voorzien wat de anderen deden. * Wat je wel en niet kunt voorzien is erg rekbaar. Je kunt als website-maker nog wel voorzien dat een IMG tag leidt tot het automatisch binnenhalen en weergeven van een plaatje, maar het komt niet zo vaak voor dat iemand een plug-in gebruikt waarmee gewone hyperlinks ook zichtbare plaatjes opleveren. Dit is dus niet te voorzien, totdat iedereen wel zo’n plugin gaat gebruiken. * Moet je alleen automatische processen kunnen voorzien, of ook de handelingen van andere mensen? Ik denk dat je wel handelingen van goedbedoelende mensen moet voorzien (bijv. iemand die gewoon jouw website bezoekt), maar niet van kwaadwillenden (bijv. hackers of mensen die jouw plaatjes deeplinken). Of in ieder geval: bij kwaadwillenden zijn die kwaadwillenden toch de hoofdverantwoordelijken.
Ondanks dat er volgens mij (na lang nadenken) toch wel iets valt te zeggen voor de uitspraken van deze rechters, vind ik de gevolgen toch enorm bizar en vervreemdend. Ik denk dat dit aantoont dat het auteursrecht eigenlijk niets te zoeken heeft op het internet.
Volgens mij is de fundamentele kwestie wie er verantwoordelijk is voor de handelingen die door een computerprogramma worden verricht. In dit geval is het computerprogramma een HTML-pagina (een IMG tag is immers een soort instructie aan een computer om een plaatje binnen te halen en weer te geven).
Misschien moet je het zo zien: * verschillende mensen doen handmatig bepaalde handelingen * als gevolg van die handelingen samen starten er automatische processen * de gevolgen van die automatische processen zijn soms ongewenst (bijv. auteursrechtinbreuk)
Ik denk dat die ‘daders’ die de gevolgen hadden kunnen voorzien verantwoordelijk zijn.
Er zijn wel problemen met dit concept: * Er zijn combinaties waarbij geen van de ‘daders’ de gevolgen had kunnen zien, omdat niemand had kunnen voorzien wat de anderen deden. * Wat je wel en niet kunt voorzien is erg rekbaar. Je kunt als website-maker nog wel voorzien dat een IMG tag leidt tot het automatisch binnenhalen en weergeven van een plaatje, maar het komt niet zo vaak voor dat iemand een plug-in gebruikt waarmee gewone hyperlinks ook zichtbare plaatjes opleveren. Dit is dus niet te voorzien, totdat iedereen wel zo’n plugin gaat gebruiken. * Moet je alleen automatische processen kunnen voorzien, of ook de handelingen van andere mensen? Ik denk dat je wel handelingen van goedbedoelende mensen moet voorzien (bijv. iemand die gewoon jouw website bezoekt), maar niet van kwaadwillenden (bijv. hackers of mensen die jouw plaatjes deeplinken). Of in ieder geval: bij kwaadwillenden zijn die kwaadwillenden toch de hoofdverantwoordelijken.
Ondanks dat er volgens mij (na lang nadenken) toch wel iets valt te zeggen voor de uitspraken van deze rechters, vind ik de gevolgen toch enorm bizar en vervreemdend. Ik denk dat dit aantoont dat het auteursrecht eigenlijk niets te zoeken heeft op het internet.