Wie is nou eigenlijk eigenaar van onze website?

Een lezer vroeg me:

Een paar jaar terug hebben we een website laten bouwen door een professioneel bureau. Recent heb ik een ander bureau ingeschakeld om wat wijzigingen te maken en een forum toe te voegen. Maar na oplevering zegt het oude bureau dat de nieuwe site inbreuk maakt op hun auteursrechten (copyrights)! Zij zouden alle rechten hebben en ik had hen het onderhoud en de uitbreidingen moeten laten doen.

Klopt dat? We hebben toch betaald voor de site en het ontwerp, dan is het toch onze site en mogen wij toch zeker wel zelf bepalen wie het onderhoud gaat doen?

Het bureau heeft waarschijnlijk gelijk, maar dat hangt allemaal vrijwel volledig af van wat er precies in het contract (en de bijgehorende algemene voorwaarden) staat.

Hoofdregel van het auteursrecht/copyright is namelijk dat wie het maakt, de rechten heeft. De website is hier door het bureau gemaakt, en dus hebben zij daarop de rechten. Daar is eigenlijk maar één uitzondering op: als in het contract staat dat de auteursrechten naar de opdrachtgever gaan (soms staat er “eigenaar wordt”, dat vind ik twijfelachtig).

Wie betaalt, is auteursrechtelijk compleet irrelevant.

De opdrachtgever krijgt alleen een gebruiksrecht voor de site zoals door hen opgeleverd. Wat dat gebruiksrecht precies omvat, hangt af van het doel van de site en wat er zoal tijdens het offertetraject is gezegd. Is er bijvoorbeeld gesproken over “makkelijk zelf aanpassen” van layout of teksten via een handige WYSIWYG-editor, dan heeft de opdrachtgever het recht die layout of teksten aan te passen. Maar is er niets gezegd, dan zou ik zeggen dat je niet zelf zomaar van alles mag wijzigen. Goed, typefouten waarschijnlijk wel, maar een hele nieuwe layout niet.

Dit betekent ook dat je niet zomaar als opdrachtgever een ander bedrijf mag inschakelen om de site te laten verbouwen. Je zult daarvoor toestemming moeten krijgen van de oude ontwerper, en het is nog maar de vraag of je die zult krijgen.

Ik zou dus altijd adviseren om in zo’n opdracht op te laten nemen dat het eigendom van de site overgaat naar de opdrachtgever, of op zijn minst dat onderhoud door de opdrachtgever zelf mag worden gedaan, dan wel door een door hem gekozen hulppersoon.

Arnoud

62 reacties

  1. Hoe zit het met auteursrecht als een medewerker in tijd van de baas een site maakt?

    Ligt het recht dan bij de medewerker of bij het bedrijf?

    Er van uit gaande dat er niets expliciet geregeld is. Is dat evt expliciet anders te maken?

    En is dit hetzelfde met software die je laat maken?

  2. @Franc: de werkgever krijgt het auteursrecht op alles dat de werkgeverwerknemer maakt binnen het dienstverband. Het gaat dus niet om of het onder werktijd was of dat de werklaptop werd gebruikt, maar om de vraag of dit “voor het werk” was. Wat je in het weekend op je eigen PC programmeert als handig scriptje voor je werk, is van je werkgever. Omgekeerd is die roman die je onder werktijd als portier typt, gewoon van jou.

    Zie ook Wie heeft het auteursrecht op een werk? en In eigen tijd gemaakte software kan toch van uw baas zijn.

    @Erik: het CMS is door een derde gemaakt, maar je krijgt een licentie van hem of haar dat je het CMS mag inzetten. De CMS-eigenaar kan geen rechten uitoefenen tegen de content die je erin zet. Voor templates idem dito. Het aanpassen van het CMS of de templates zelf mag echter alleen als erbij staat dat het mag. Open source CMSen mag je altijd aanpassen, maar er zijn templates op internet te koop waarbij wijzigen aparte toestemming vereist.

  3. Ik wist dat als er niets is afgesproken over overdracht van de rechten, de opdrachtgever niet zomaar zonder toestemming een ander bedrijf mag inschakelen om aanpassingen te doen. Maar -even een zijstraatje- wat als jij bijvoorbeeld je zolder laat vertimmeren door klusbedrijf A, en na verloop van tijd besluit je klusbedrijf B in te schakelen om hier weer iets aan te verbouwen? Is dat niet eenzelfde situatie?

    Oftewel, zouden er rechten rusten op een in opdracht gemaakte zolderkamer? Zo ja, klopt het dan dat je hier zonder dat daar iets over is afgesproken, niet zelf aan zou mogen klussen (of een ander bedrijf in mogen schakelen)? Zo nee, waarin verschilt deze situatie dan van het bouwen van een website?

  4. Daar is eigenlijk maar ??n uitzondering op: als in het contract staat dat de auteursrechten naar de opdrachtgever gaan (soms staat er ???eigenaar wordt???, dat vind ik twijfelachtig).
    Ik zou dus altijd adviseren om in zo???n opdracht op te laten nemen dat het eigendom van de site overgaat naar de opdrachtgever, of op zijn minst dat onderhoud door de opdrachtgever zelf mag worden gedaan, dan wel door een door hem gekozen hulppersoon.

    Ik zou dus gewoon zorgdragen voor een schriftelijke overdracht van de auteursrechten/IP met wellicht nog een bijzin waarin staat waarom: ‘opdat opdrachtgever zelfstandig wijzigingen kan doorvoeren op de het geheel wat samen de website vormt, waaronder maar niet beperkt tot: de html, de php, de css files, de (video)beelden van de site.

    Eigenaar worden van een site vind ik zelf wat gevaarlijk. Je zou bij een dispuut nog kunnen beweren dat hier gaat om eigendom van een licentie op de site omdat auteursrechten expliciet schriftelijk moeten overgedragen en dat doet die zin wellicht net niet.

  5. Het verschil is dat het klusbedrijf geen auteursrecht op de zolderkamer kan claimen, en het webdesignbedrijf wel.

    Maar waarom rust daar geen auteursrecht op dan? Een aannemer of timmerman moet toch ook zijn creativiteit aanwenden om een zolderkamer te realiseren?

  6. @Pelle: Dat is hooguit creativiteit binnen een operationeel proces. Indien deze aannemer of timmerman een tekening maakt die bijzonder creatief is – dan – is er wellicht sprake van creativiteit die auteursrechtelijke bescherming kan genieten. Maar dat is veelal niet het geval. Voor een architect geldt dat al veel sneller. Maar die – ontwerp – ook echt iets. Volgens mij is de grondregel nog steeds dat er sprake kan zijn van creativiteit als het ontwerp het eigen kenmerk van de ontwerper bevat. Een pure grafische uitwerking van feitelijke handelingen is dat niet.

  7. Als ik dit zo lees dan vind ik het hoog tijd worden dat de auteurswetgeving op websites beperkt wordt in duur… (maximaal 3 jaar zou genoeg zijn IMO gezien de snelle ontwikkelingen op het web)

    Het klinkt namelijk erg als “ik ben best tevreden met de website maar niet meer met het bedrijf dat het ontworpen heeft” en als ondernemer zit je dus tegen wil en dank vast aan dat bedrijf als je wat kleine aanpassingen wil hebben (dit bedrijf zal hier waarschijnlijk van zal profiteren door hoge tarieven te rekenen, ik doe slechts een aanname)

    Dat kan toch nooit de bedoeling zijn?

  8. “Maar waarom rust daar geen auteursrecht op dan? Een aannemer of timmerman moet toch ook zijn creativiteit aanwenden om een zolderkamer te realiseren?”

    Hangt er vanaf in hoeverre je een stempel van de maker in het werk kan ontdekken. Elke timmerman zal een plankje op dezelfde manier inkloppen, dus daar komt weinig creativiteit bij kijken. Als de timmerman echter zelf het plankje ontwerpt en er allemaal tierelantijntjes aan toevoegt, dan kom je al meer in de richting. Dan moet je je alleen wel afvragen of de goede man geen timmerman van beroep is, maar binnenshuisarchitect.

  9. @antigoon @martin Dat gaat voorlopig echt niet gebeuren. Maar je het als kopende partij ook wel een onderzoeksplicht. Als jij offertes vraagt bij bedrijven met als eis dat je de source er bij wil dan wijzen ze je echt meteen af als klant. Mogelijk vragen ze wat meer. Dus het is ook gewoon je werk goed doen als koper.

    1. Ze wijzen je niet noodzakelijkerwijs allemaal af. Er zullen best wel bedrijven zijn die de open source gedachte ondersteunen, en software maken zien als dienstverlening. Open source heeft ook voordelen, zoals het vrij kunnen gebruiken van een groot aantal libraries en producten. Misschien dat het enig zoeken vergt.

  10. Heu, er staat in mijn laatste reactie een foutje. Ik bedoelde te zeggen dat ontwikkelaars je echt niet gelijk afwijzen als je als eis stelt dat je de broncode erbij wil en dat je die ook zelfstandig mag aanpassen.

  11. De opmerking “Elke timmerman zal een plankje op dezelfde manier inkloppen, dus daar komt weinig creativiteit bij kijken.” kan je een op een toepassen op HTML (zeg maar de spijkers en de hamer). Daar is nagenoeg geen creativiteit voor nodig.

    De afbeeldingen en look en feel wel. Maar die is meestal gebaseerd op de huisstijl van een bedrijf, dus heb je wat mij betreft te maken met een gedeeld auteursrecht (Logo en kleuren bij originele bedrijf, positioneren en overige afbeeldingen bij webbouwer.)

    Is het een dynamische website, ligt het wel weer anders volgens mij… Al kan je daarover discussi?ren denk ik.

  12. @Pelle en @Arnoud (#4 en #5) Het verschil tussen een timmerman die een zolder timmert en een web designer die een website bouwt zit hem erin dat auteursrechten zitten op het ontwerp ervan, niet op de uitvoering. Wie een boek schijft is de auteur, niet de uitgever die het boek vervolgens drukt. Een timmerman bouwt volgens een ontwerp en dat ontwerp is meestal bedacht door de huis-eigenaar zodat de eigenaar auteur is van het ontwerp. (Als de eigenaar alleen zegt: “leef je uit!” dan is toch de timmerman weer de auteur.) Bij web design heb je vaak een klant die wel een idee heeft van wat ze willen hebben, maar is er geen ontwerp. De web designer begint dan met een ontwerp en legt dit regelmatig voor om eventueel correcties door te voeren. De web designer is dan de auteur. Natuurlijk is er in geval van loondienst niet een persoon maar bedrijf de auteur, omdat de persoon ter compensatie loon ontvangt en de auteursrechten voor werk-gerelateerd werk bij de werkgever liggen.

  13. @Mark Berck, als je gebruik maakt van een huisstijl, dan maak je dus gebruik van auteursrechtelijk materiaal afkomstig van een andere auteur. Je hebt dan zelfs de kans dat jij niet de rechten hebt om dit materiaal te gebruiken in de site die je voor je opdrachtgever ontwerpt! En dat kan best vreemde situaties opleveren. 🙂 Die situatie ligt weer anders als de auteursrechten van jouw site bij de opdrachtgever liggen, omdat hij wel de rechten heeft om die logo’s te gebruiken.

    Stel, ik ontwerp een logo en wat code volgens de CC-NC-ND licentie. Deze mag dus niet commercieel worden gebruikt en er mogen ook geen afgeleide werken van gemaakt worden. Het plaatje wordt populair en een bedrijf koopt bij mij een speciale licentie die hen -en hen alleen- het recht geeft om dat plaatje te gebruiken voor hun commerciele omgeving. Dat is dus een recht dat alleen zij hebben. Als zij dan aan jou vragen om dat plaatje aan te passen en te verwerken in een commerciele site voor hen dan krijg jij dus nooit de auteursrechten op dat werk. Jij hebt hooguit de CC-NC-ND licentie waardoor je dus geen afgeleid werk mag bouwen onder je eigen rechten. Maar werk je namens je opdrachtgever dan kun je wel rechtmatig aan het werk maar liggen de rechten bij je werkgever. (En afhankelijk van hun contract met mij mogelijk ook deels bij mij.)

    (Grappig eigenlijk dat ik zo een plaatje kan weggeven zonder dat anderen er verder iets mee kunnen doen. De CC-NC-ND is dan ook een redelijk gehate licentie onder de CC’s…)

    Ten minste, dat vermoed ik. Arnoud corrigeert mij wel als ik het mis heb. 🙂

  14. Is ieder huis niet per definitie door een architect getekend/nagerekend? Ik heb altijd begrepen dat het niet anders mag. Wat maakt dan het verschil tussen een huisje in een vinex wijk (zeker in VINEX wijken worden die huizen echt wel door professionele architecten ontworpen) en een one-off Mies van der Rohe?

    Mag een huis ontworpen door Mies van der Rohe of Gerrit Rietveld niet worden veranderd tot 70 jaar na zijn dood, behalve met toestemming van zijn erfgenamen? Indien het een huis met inrichting betreft, mag je dan de bank niet op een andere plek zetten of een TV toevoegen?

  15. Wat nou als er een CMS met bijbehorende website opgeleverd is door een stagiaire? Die later claimt copyright te hebben om dat hij de website in eigen tijd had gebouwd. Maar dat nooit aangegeven had bij de verschillende opleveringen van de website. Overigens een stage die niet op locatie werd uitgevoerd.

  16. @arnoud

    Hoe zit dat als je handjes inhuurt van een web design buro? “Ik wil mensen die voor mij een CMS bouwen” Heb je dan wel het eigendom. Is er een standaard tekst/contract waarmee je dit kunt regelen, dat je als bedrijf het eigendom krijgt.

  17. @Michel: een stagiair wordt meestal ingehuurd onder een arbeidscontract voor korte tijd. Dan is volgens de wet alles dat die in het kader van de stage maakt, eigendom van het bedrijf.

    @Franc: nee, alleen maar “voor mij een cms” laten bouwen geeft je niet het auteursrecht op dat CMS. Je moet echt expliciet opnemen “Alle auteursrechten op de geleverde materialen gaan hierbij over naar opdrachtgever” en zorgen dat dat ondertekend wordt ook.

  18. Ik zie dat een aantal mensen in deze reacties opperen tot overdracht van de rechten. Hier wordt zo te lezen vrij makkelijk over gedacht. Bedenk wel dat webbouwers (waaronder ikzelf) hiervoor gemiddeld 1 tot 1,5 keer de initiele ontwikkelprijs rekenen. Vraag ik dus voor een standaard site normaal 1.500 euro, en wil jij de rechten hebben zodat je later een ander bedrijf er mee aan het werk kan zetten, dan vraag ik er minimaal 3.000 euro voor. Hetzelfde als je niet de gemaakte website in je portfolio mag opnemen van de klant; exposure moet je afkopen. Dat is normaal zo’n 10% van het initiele ontwikkelbedrag.

    @Arnoud hier nog een vraag op; als ik een site bouw in een open source CMS, ik steek hier een design in die ik heb gemaakt en programmeer er verder niets qua custom functionaliteiten bij; in hoeverre heb ik dan auteursrecht op het geheel? Soms voelt het alsof ik geld vraag voor iets wat ik niet heb gemaakt (het CMS). Als ik daarbij nou veel aanpassingen in de code heb moeten doen dan vind ik het een ander verhaal. Vaak laat ik bij zulke projecten de kosten voor de rechten alleen berekenen over de kosten voor het design, dat vind ik dan wel zo fair. Maar zou het juridisch kunnen om het dan over het totaalbedrag te berekenen?

  19. @Peter: juridisch gezien moet je kijken naar jouw creatieve inbreng. Welke items heb j?j gemaakt, welke aanpassingen heb j?j doorgevoerd en wat is daarvan terug te vinden in het eindresultaat? De code van het CMS kun jij bijvoorbeeld niet claimen, want daar heb je niets van gemaakt. De aanpassingen in het frontend template zijn wel van jou, aangenomen dat dat creatieve aanpassingen waren (kleurkeuze, layout, etc) en niet slechts functioneel (vertaling van trefwoorden naar Nederlands, kleurschema aangepast volgens wens klant).

    Ik weet dat designers zo’n afkoopsom vragen, maar als je v??raf dit item op tafel legt dan valt er vaak best te onderhandelen. Pas nadat het werk af is vragen om afkoop is niet zo slim want dan sta je heel zwak als klant. En anders is er nog de marktwerking: er zijn ook webbouwers die gratis of goedkoper dan jij hun rechten afstaan.

    (Wel vind ik dat je als webbouwer een onbeperkte licentie terug moet krijgen zodat je het gemaakte nog wel elders in kan zetten, mits het natuurlijk niet te veel lijkt op het resultaat voor deze opdrachtgever.)

  20. @Arnoud, laten we het interessanter maken! Als programmeur heb ikzelf een library ontwikkeld die ik voor alles gebruik waar ik aan werk. De code hiervan geef ik niet vrij maar deze kan wel onderdeel worden van projecten waar ik aan werk. Omdat ik deze code heb ontwikkeld in mijn eigen tijd, voor ik aan een project ben begonnen is er geen twijfel over mogelijk dat ik de auteur ervan ben. Maar als ik dan werk aan een project in opdracht van bedrijf X, waarbij X de auteursrechten houdt op de code van het product, is het dan nog verstandig om deze library aan dit project toe te voegen? Of moet ik dat gewoon zien alsof ik bedrijf X gewoon een licentie geef op deze code en dat de rest van de code die ik voor hen schrijf op hun naam staat?

  21. Wim, ik zou altijd zwart op wit laten vastleggen dat jij eigenaar bent en blijft van jouw bibliotheek en aan je opdrachtgever een licentie verstrekken. Dit is om te voorkomen dat het onder de clausules van het conract waaronder je werkt gaat vallen.

  22. Tja, contractueel vast laten leggen. Da’s lang niet altijd even eenvoudig, vooral voor hen wiens werk tevens hun hobby is. 🙂 En voor mij als thuis-werker zelfs nog extra lastig omdat ik duidelijk een onderscheid moet maken tussen werk-data en prive-data. (Heb een aparte, virtuele schijf voor werk-data.) Bij de vraag wie nou de eigenaar is van een website komt natuurlijk nog veel meer bij kijken. Vaak heeft een bedrijf al een website waarvan onderdelen worden meegenomen naar de nieuwe site. Bij een CRM website denk ik dan al gauw aan foto’s, afbeeldingen en logo’s die van allerlei bronnen afkomstig kunnen zijn. Maar ook stukken code van de oude site kunnen zijn meegenomen in de bouw van de nieuwe site, indien het gaat om functionaliteit die mee moet. Ald de nieuwe site daarna nogmaals op de schop moet dan wordt het wel een enorm breiwerk van auteursrechtelijk materiaal waarvan niemand eigenlijk de juiste auteur kan bepalen.

    Mijn ervaring is dat bedrijven eigenlijk nooit code weggooien maar gewoon voor eeuwig bewaren voor als “het ooit nog nodig is”. Zo kun je opeens werken aan een project waar zo’, 15 jaar aan code zit verwerkt afkomstig van de eigen (voormalige werknemers en van andere partijen. Als in de coe ook nog een open-source code is gebruikt, wordt het nog complexer.

    Even nog iets anders… In broncode staat vaak commentaar met een verwijzing naar de licentie en de auteur. Bedrijven die dergelijke broncode gebruiken willen dit commentaar wel eens verwijderen uit de bronbestanden omdat het zo rommelig staat. En soms plaatsen ze gewoon hun eigen commentaar op deze plaats en claimen ze zelf de eigenaar te zijn van de code. (Ongeacht de licentie waaronder ze de code verkregen hebben want dit gebeurt ook met commerciele libraries die inclusief broncode worden geleverd.) Na verloop van tijd zijn er werknemers weggegaan en weer bijgekomen en zijn er programmeurs die niet de herkomst van deze code kunnen bepalen. De code kan dan al 10 jaar of ouder zijn en dan is al snel onduidelijk of de auteur eigenlijk nog achterhaald kan worden. Wat vaak ook nog voorkomt is dat de auteur van de code deze niet eens meer verkoopt en een ander vak is gaan zoeken. Of het bedrijf waaronder hij de licentie voor de code heeft verkocht of weggegeven is failliet of opgeslokt door een ander bedrijf. Zo werk ik zelf aan projecten waarbij een deel van de code door de ware auteur ruim 10 jaar geleden voor het laatst is aangepast. De vraag is dan hoeveel moeite je uiteindelijk moet doen om voor alle code bij te blijven houden wie de echte auteur is van die code? Want na vele jaren wordt het echt een ondoorzichtige brij…

    1. Normaal gesproken hoor je een overzicht bij te houden van alle werken van derden die je gebruikt, en onder welke licenties dat gebeurd. Toen ik nog aan productontwikkeling voor een grote multinational werkte, werd dat ook netjes gedaan. Een document van zo’n tien bladzijden met van elke library die werd gebruikt een verwijzing naar de licentie en waarom die toestond dat we die mochten gebruiken en meeleveren. Omdat het pakket niet open source was, mochten libraries onder de GPL niet mee, LGPL soms wel.

      Bedrijven die dat niet doen zijn nalatig en maken groot risico ongewild inbreuk te maken op auteursrechten.

  23. Wim, als je op contractbasis werkt zijn het een paar regels in het contract: [Wim ten Brink] zal voor [opdrachtgever] ontwikkelen [project]; het auteursrecht op deze code zal na betaling van [de eindfactuur] aan [opdrachtgever] overgedragen worden. Bij onwikkeling van bovengenoemde software kan [Wim ten Brink] gebruik maken van de door hemzelf ontworpen programmabibliotheken [bieb]. [Wim ten Brink] verleent hierbij toestemming aan [opdrachtgever] om deze bibliotheken te gebruiken in het kader van [project] en verleent toestemming aan [opdrachtgever] om de bibliotheekcode te (laten) wijzigen. Het gebruik van de bibliotheekcode buiten [project] en verdere verspreiding van deze code is niet toegestaan.

    Het verwijderen van licentieinformatie uit broncode is dom (en in sommige landen zelfs illegaal). Ik raad je aan om zo goed mogelijk bij te houden wie de auteur (en wat zijn licentie) is; en de broncode is een hele goede plek om dat te doen. (Houd ook je eigen grote wijzigingen bij.) Wanneer die informatie weggegooid is, wordt het een enorme klus om die te reconstrueren (voor zover dat mogelijk is.) Er zijn een aantal programma’s die je kunnen helpen met het vinden van Open Source fragmenten, maar die zijn verre van perfect.

    Het is over het algemeen niet relevant om per regel bij te houden wie de auteur (of rechthebbende) is, het gaat er om dat het totaal aan licenties voor een produkt past bij de verkoopcondities.

  24. Mathfox en Arnoud, het kan nog lastiger worden als de broncode intern vele malen is aangepast. Ik programmeer veel in Delphi (Pascal) en voor deze ontwikkel-omgeving zijn veel open-source libraries maar ook commerciele libraries ontwikkeld die allemaal inclusief broncode geleverd worden. Omdat Delphi nu al zo’n 16 jaar op de markt zit is er dus ook hele oude code voor beschikbaar vanuit diverse bronnen. Code die nog prima werkt met de nieuwste Delphi versies, hoewel men soms wel enkele kleine aanpassingen zal moeten maken. Natuurlijk is het verwijderen van licentie-informatie uit bronbestanden dom, en zou men goed moeten bijhouden waar de code vandaan komt en wat er intern aan gewijzigd is. De praktijk bij kleine bedrijven is echter anders, omdat men dan vaak geen documentatie bijhoudt en soms ook overtollige documentatie verwijdert. En gezien de leeftijd van sommige stukken code wordt code ook nog eens door diverse werknemers onder handen zijn genomen die op dit moment misschien niet eens meer bij het bedrijf werken.

    Aan de andere kant, als je als bedrijf een licentie hebt gekregen op een stuk broncode, en deze broncode alleen maar intern gebruikt, waar kan dan uiteindelijk het probleem zitten? Ik heb de broncode namelijk in licentie met daarbij het recht om deze te wijzigen. (Waarbij open-source soms iets meer restricties oplevert omdat de open-source licentie besmettelijk kan worden voor afgeleide werken.)

    In deze zaak van de originele post is de situatie echter iets anders. Men heeft de site opgeleverd maar geen licentie verleend om hierop grote aanpassingen te mogen maken. De maker van de site behoudt dus het onderhouds-recht. Bij Delphi broncode ligt het vaak iets anders, omdat men de broncode meelevert zodat de klant deze zelf aan hun eigen behoeftes verder aan kunnen passen. De klant heeft dan meer rechten. En de maker van de broncode ontwikkelt gewoon door op hun eigen code en levert daar gewoon updates van en dan is het aan de klant de taak om de upgrades van de maker te verwerken in hun eigen systeem. Maar bij deze website zat kennelijk alleen een gebruikers-licentie en hadden ze een apart onderhouds-contract erbij. Men heeft dus het bedrijf onder de verkeerde voorwaarden de site laten aanleveren. (Maar het zou vele malen duurder geweest zijn als het het beter hadden geregeld.)

  25. Ook voor copy writers en SEO’s geldt dit voor de HTML content en HTML (meta)tags/attributes. Ik heb SEO-contracten gezien waar aanpassing van de content, adwords en meta/title tags niet alleen de leveraar vrijstelt van enig oplevering/resultaatmeting, maar zelfs een soort van “boete” uitdeelt om de content en tags weer terug te plaatsen in de originele staat.

    Ik snap zeker dat je als leveraar van geSEOde content niet wil dat een klant zomaar je werk teniet kan doen, en dan probeert de matige resultaten op jouw rekening te zetten, maar ik zou ook als webmaster nooit aan die contractuele bepalingen vast willen zitten. Geef dan gezond advies: “zulke wijzigingen kunnen de resultaten belemmeren” en laat de partij een transparant onderhoudscontract tekenen.

    Horen er bij auteursrecht en “eigenaar zijn” van een website niet meer dingen dan alleen het opeisen van onderhoudswerk? Een online bedrijf dat klant is onder deze regelingen kan een juridisch conflict krijgen met een ander bedrijf over de website en de inhoud. Dan moet je er toch ook staan als “eigenaar” van de website als er een rechtszaak van komt? Ik noem een belastingadviseur die een website heeft gekocht bij iemand die volledig eigenaar wil blijven, en ook de SEO teksten heeft geschreven (en daarbij foutieve informatie heeft gegeven oid)

    Hoe staat het met je merk (en merkinbreuk) als iemand anders eigenaar is van je complete huisstijl (van logo, tot online websites en geprinte visitekaartjes)? Ik vind dat maar een rare situatie waar een bedrijf zich dan in bevind. Wil je dan een nieuwe richting op en minder gebruik gaan maken van de oude site, dan moet je eerst je oude rechten afkopen.

    Of je huurt een externe SEO consultant in, of een inhouse-SEO en je wijzigt het een en ander aan een site, dan moet je dat dus eerst afstemmen met het website development bedrijf en websitedesign bureau? En dan heeft natuurlijk het website development bedrijf ook een SEOer in dienst en wil dat je deze afneemt, en de webdesigner is het niet eens met de plaatsing van een breadcrumb.

    Ook het niet mogen implementeren van plug-ins en uitbreidingen (zoals een forum) op een vaak opensource framework vind ik erg cru. Een forum plaatsen op een site pleegt toch geen inbreuk op de oude site? Gewoon van code op een server en een link in het menu. Dit is juist de sterkte van die frameworks en een reden om dat te kiezen: portability van development en uitbreidbaarheid via plug-ins en extensions.

  26. Ik vind eigenaarschap ook maar eng. Zoiezo erg lastig om rekening te houden met alle juridische zaken rondom internetrecht.

    • Bouw je nu wel of geen applicatie met cookies zonder toestemming?

    • Maak je nu wel of niet gebruik van buiten-EU tracking software die niet is ingesteld op europese wetten?

    • Je algemene voorwaarden zitten achter een floepvenster en zijn dus nietig. Is een webdeveloper hier niet deels voor verantwoordelijk?

    • Valt je applicatie onder de Wet Bescherming Persoonsgegevens en wat zijn je verantwoordelijkheden als database beheerder?

    • Ga je werkelijk al je 3000 mensen uit je emailbestand een mail sturen om te vragen of ze zich willen herinschrijven voor de nieuwsbrief, om zo te voldoen aan een nieuwe email-wet? En weet je uberhaupt van het bestaan af van een nieuwe wet op e-mail?

    • Een ieder kan een “user generated content” forum of blog neerzetten. Maar slechts weinigen weten de juridische verantwoordelijkheden van beheer of hebben geen admin rollen.

    • Een concurrentie onderzoek op nieuwe zoektermen voor een online marketeer? Eerst checken of de termen geen trademark zijn, in welke landen ze zijn geregistreerd, waar de serverlocatie is, correct gebruik van ® en ™ in pagina titels.

  27. Ik vraag mij nog iets af… Je laat een website bouwen door een professioneel bureau, zoals in de post genoemd. Dit bureau is vervolgens de eigenaar van de site. Maar nadat je de site enkele weken in gebruik hebt genomen krijg je door een ontwerpfout in de site dat deze door een hacker wordt overgenomen die je gehele klantenbestand leegrooft, al jouw data wist en de site vervangt met een malware webpagina die alle tweeduizend bezoekers infecteert met een vervelende Trojan waar ze niet van af lijken te komen.

    Ben je dan als bedrijf verantwoordelijk of kun je in dat geval een schadeclaim indienen bij datzelfde professionele bedrijf?

    Ofwel, als zo’n bedrijf claimt de eigenaar te zijn, zijn ze dan ook verantwoordelijk voor schade die ontstaat door het in gebruik nemen van die site?

    En wat als de site de privacy-wetgeving overtreedt? Dus geen hacker maar alleen alle klantgegevens die open en bloot op het Internet worden doorgegeven als je het truukje eenmaal kent. Wie is er dan verantwoordelijk? (En copyright-schendingen?)

    Het lijkt mij dat je in deze situaties blij moet zijn dat je niet zelf de eigenaar bent omdat je dan de verantwoording voor schade en overtredingen door kunt schuiven naar dat professionele bedrijf. Als dat niet zou kunnen dan zie ik geeneens voordelen in het inhuren van zo’n professional.

  28. @Wim: zo’n hack is mogelijk te zien als wanprestatie van de bouwer, immers je mag verwachten dat een website niet zomaar gehackt kan worden. Maar dat hangt sterk af van het soort hack, met name of deze bekend was en of er een eenvoudige tegenmaatregel was. Ook kan het goed zijn dat in de algemene voorwaarden het nodige beperkt is op het gebied van schadeclaims. Of dat rechtsgeldig is, is niet in het algemeen te zeggen.

    Voor schade als gevolg van gebruik van de site is de bouwer moeilijk aansprakelijk te stellen. Die kan immers moeilijk be?nvloeden wat de gebruiker doet met de site. Wellicht als er dingen zijn die hij had moeten melden, bv. “kies een sterk wachtwoord” of “geen adressen toevoegen aan het mailingbestand zonder expliciete opt-in he!”

  29. En wat als de maker (niet de gebruiker) van de site ook plaatjes heeft toegevoegd waar hij geen rechten op had? Maakt het dan uit als de maker daarbij aangeeft dat de gebruiker deze plaatjes eerst door eigen afbeeldingen moet vervangen voor de site in gebruik wordt genomen? Dat lijkt mij ook een wanprestatie maar het is de gebruiker die een aanklacht krijgt wegens het gebruik van copyrighted materiaal en de gebruiker wordt dan gedwongen de site aan te passen. Maar als Bob de Bouwer dit niet toestaat, zoals in de post, dan mag alleen Bob die aanpassingen doen. Op wiens kosten moet dat dan gebeuren? En wie betaalt de schadeclaim dan? Is dit ook contractueel vast te leggen dat Bob hier niet aan schuldig is?

  30. Als de maker auteursrechten schendt door plaatjes te uploaden, lijkt hij me daarvoor aansprakelijk. En zo’n aansprakelijkheid is moeilijk uit te sluiten in algemene voorwaarden. Het is al heel snel ‘opzet’, want je moet actief een plaatje van internet plukken en uploaden. En schade door opzettelijk of grof nalatig handelen is niet te disclaimen in je algemene voorwaarden.

    De gebruiker krijgt de claim maar kan die dus doorsturen naar de bouwer.

    (Als de gebruiker zelf aangeeft ‘gebruik die en die plaatjes’, dan wordt het natuurlijk anders. Of als de gebruiker zegt “geen zorgen, ik regel de rechten”.)

  31. Beste Arnoud en overige bezoekers van deze site, ik was op zoek naar antwoorden betreffende de vraag van eigenaar betreffende een website en de daaraan gekoppelde onderdelen (in dit geval met name de teksten, photo’s, de inhoud van de gekoppelde DB (in principe ook de teksten), de html/php code en de domeinnaam).

    Wat me opvalt is dat de antwoorden en reacties in deze vraag, mijns inziens, vrij haaks staan op de antwoorden en reacties die op een post van circa een jaar geleden hier op het blog zijn geplaats (http://blog.iusmentis.com/2009/10/06/wie-is-de-eigenaar-van-een-website-2/). Misschien dat ik zaken verkeerd interpreteer, maar is nu de opdrachtnemer (het bedrijf dat in opdracht een website maakt) of de opdrachtgever de eigenaar van de door mij genoemde onderdelen van een website?

  32. De opdrachtnemer heeft de auteursrechten, tenzij er schriftelijk is vastgelegd dat de opdrachtgever die zal krijgen. Volgens mij staat dat ook zo in die blog uit 2009.

    Het kan wel zo zijn dat de opdrachtnemer niet zomaar eenzijdig van alles kan verbieden, bijvoorbeeld door ineens de site offline te halen met een beroep op zijn auteursrecht. De opdrachtgever heeft bepaalde contractuele rechten.

  33. Hallo Arnoud,

    bedankt voor de snelle reactie. Zoals gezegd, het zal ermee te maken hebben dat ik juridische kennis ontbreek en dus zaken misschien verkeerd interpreteer. Als ik het goed begrijp is dus in het geval van de domeinnaam de opdrachtgever de eigenaar (tenminste zo interpreteer ik de eerste drie reacties op de eerder genoemde post), echter de code van de site is eigendom van de opdrachtnemer? Hoe zit het dan met de teksten en plaatjes? Over het algemeen worden deze toch aangeleverd door de opdrachtgever, deze zou dan toch eigenaar hiervan moeten blijven, dus ook in het geval dat deze in een database (van het CMS) opgeslagen worden?

    Alvast bedankt voor verdere reacties.

  34. Bij teksten, plaatjes, software en eigenlijk alle andere onderdelen van een website (behalve de domeinnaam) geldt dat degene die het maakt, de rechten daarop heeft. De domeinnaam is van degene op wiens naam deze geregistreerd is.

    Meestal worden teksten etc. van een website gemaakt door de opdrachtnemer. Die is daar dan auteursrechthebbende (“eigenaar”) van. Teksten en andere dingen die de opdrachtgever heeft gemaakt, blijven natuurlijk van hem. En foto’s die je van elders inkoopt, blijven van de originele maker.

    Waar het vooral om gaat, is dat je geen eigenaar wordt doordat je betaalt voor de site.

  35. Hallo Arnoud,

    wederom bedankt voor de snelle reactie. Een en ander begint nu duidelijk voor me te worden. Een laatste vraag. In dit specifieke geval was het zo dat bezoekers van de website zich konden registreren. Hoe zit het met deze gegevens?

    Om je even wat achtergrond informatie te geven: Een klant van ons is in conflict met zijn vorige/huidige webdesigner en wil graag de huidige website overzetten en opnieuw laten ontwerpen door ons. De huidige webdesigner wil echter de website niet vrijgeven en heeft toegang tot de bestanden en de database afgesloten. Dat we de huidige code van de site niet krijgen is op zich geen probleem, wat echter wel van belang is zijn de teksten en photo’s die bij de webshop horen (en ook de gegevens van de geregistreerde gebruikers). De inhoud van de webshop is gevuld door de klant, er is daarbij alleen gebruik gemaakt van het CMS van de huidige/vorige webdesigner. Mijn vraag is hoe ik onze klant het beste kan adviseren hierin en wat zijn juridische positie in deze is.

    Ik zie je reactie graag tegemoet.

  36. Precies hetzelfde: dit zijn onderdelen van een website, daarvoor geldt dat degene die ze maakt, de rechten daarop heeft. Elke gebruiker is dus rechthebbende op zijn eigen reacties.

    De site heeft wel een gebruiksrecht om de reacties/bijdragen te publiceren in de context van de site.

    De vraag over toegang is een hele andere: het is niet eenvoudig om te eisen dat je een kopie krijgt van een werk waar jij het auteursrecht op hebt. Als je zelf de bronbestanden kwijt bent, dan kun je niet zomaar van een ander eisen dat die daar een kopie van geeft. Je moet dan het contract erop naslaan om te zien of er een mogelijkheid is om zo’n kopie op te eisen.

  37. Het lastige van websites is dat er vaak meerdere eigenaren zijn van alles wat er getoond wordt. Het domein is van persoon X, de code achter de site van persoon Y, de plaatjes van persoon Z, de commentaren van personen R, S, T, U en V en de server waar alles op draait van persoon P. Oh, en de software die draait op de server is van persoon O, en de software die gebruikt is om de site mee te ontwikkelen is van de personen M en N. En zo heb ik al het halve alfabet gebruikt aan personen die deels eigenaar zijn van onderdelen die voor de site zijn gebruikt. Als web-administrator is het dus best lastig om te zorgen dat je alle licenties op orde hebt. Alleen, vaak worden licenties domweg over het hoofd gezien. Het is immers een administratieve bezigheid die verder niets bijdraagt aan de werking van de site. Het is een beetje als het documenteren van broncode binnen een project. Veel ontwikkelaars besteden daar ook bar weinig tijd aan, simpelweg omdat het tijd kost en geen voordeel heeft zodra de code is opgeleverd. Maar ja, zonder documentatie is het voor ontwikkelaars lastiger om nieuwe code toe te voegen aan een project, zeker als de ontwikkelaar niet degene is die het gebouwd heeft. En bij licenties kan een site gewoon platgelegd worden indien blijkt dat een van de licenties niet klopt. Het is dus wel verstandig om dit alles op orde te hebben…

  38. De opdrachtgever krijgt alleen een gebruiksrecht voor de site zoals door hen opgeleverd. Wat dat gebruiksrecht precies omvat, hangt af van het doel van de site en wat er zoal tijdens het offertetraject is gezegd. Is er bijvoorbeeld gesproken over ???makkelijk zelf aanpassen??? van layout of teksten via een handige WYSIWYG-editor, dan heeft de opdrachtgever het recht die layout of teksten aan te passen. Maar is er niets gezegd, dan zou ik zeggen dat je niet zelf zomaar van alles mag wijzigen. Goed, typefouten waarschijnlijk wel, maar een hele nieuwe layout niet. Dit betekent ook dat je niet zomaar als opdrachtgever een ander bedrijf mag inschakelen om de site te laten verbouwen. Je zult daarvoor toestemming moeten krijgen van de oude ontwerper, en het is nog maar de vraag of je die zult krijgen.”

    Afgezien van de vraag of het verstandig management is: kan de opdrachtgever dit omzeilen door een andere website te (laten) maken en deze op een nieuwe domeinnaam te (laten) zetten, waardoor de onderneming wel een vernieuwde website heeft, maar niet op de zelfde domeinnaam?

  39. Hoe zit het dan met de verkoop van een website?

    Stel: Ik laat een website bouwen met als doel deze commercieel te exploiteren. De website wordt groter en er ontstaan inkomsten vanuit advertenties. Op een gegeven moment wil ik de website verkopen aan een geïnteresseerde partij.

    Ben ik dan als verkoper verplicht een percentage af te staan aan de websitebouwers en is het überhaupt wel toegestaan? Of gaan de rechten op de code automatisch door naar de nieuwe partij?

    1. Dat hangt af van wat je in je contract hebt vastgelegd. Als er niets over vermeld is dan kun je aannemen dat de site gewoon doorverkocht kan worden zonder dat de bouwer daar een aandeel van krijgt. Zolang jijzelf maar geen eigen kopie ervan houdt. Een beetje zoals je een huis verkoopt, eigenlijk. Het ontwerp ervan is van de architect maar het fysieke huis is jouw eigendom en dat kan jij aan een ander verkopen.

      Wel moet je daarbij de regels van de bouwer erbij meeleveren. Zo kan de architect hebben bepaald dat je geen dakkapel mag bouwen op je huis. Dat staat dan in het contract en dat contract gaat mee naar de nieuwe eigenaar. Die mag dat dan namelijk ook niet…

      Maar ik ben geen jurist… 🙂

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.