Hoe eenvoudig is het om je website met WordPress te bouwen?

wordpress-bible.pngJe eigen website in een handomdraai, zo stond enige tijd terug in een advertentie te lezen. Bouw je website met het professionele en gebruiksvriendelijke WordPress, zonder kennis van technologie of HTML ga je online. Met die belofte probeerde een hostingbedrijf klanten te werven. Een lezer maakte echter bezwaar bij de Reclame Code Commissie: het installeren van WordPress is zelfs voor een IT-er als klager lastig omdat adverteerder ook geen hulpmiddelen aanbiedt om de benodigde (onderliggende) MySQL database te installeren, aldus klager. Niks “in een handomdraai” dus. Hoe vriendelijk is WordPress?

Ik werk al jaren met de blogsoftware, en hoewel het zeker vriendelijk te noemen is, is het wel vriendelijk met een handleiding. Je moet weten waar het zit, dan is het logisch, en af en toe doet ‘ie raar en dan moet je een expert erbij halen om het draaiend te krijgen. Maar toegegeven, als enigszins gevorderde gebruiker doe je soms dingen die niet als logisch kunnen worden aangemerkt.

De advertentie was echter gericht op de beginner, de persoon die zonder kennis van HTML en dergelijke aan de slag wil. Immers, dit stond er:

Bouw je website met WordPress | Je eigen website in een handomdraai
Met het professionele en gebruiksvriendelijke WordPress bouw je naast een blog, eenvoudig je eigen website. Je hebt de keuze uit verschillende thema’s en uitbreidingsmogelijkheden. Zonder kennis van de technologie of HTML toch snel je website online! Doorloop het bestelproces en installeer WordPress op je hostingpakket. (…) De werking van externe plug-ins wordt niet gegarandeerd en we bieden geen inhoudelijke ondersteuning op de installatie of configuratie van Word Press

Het verweer luidde vervolgens dat het gebruik van WordPress eenvoudig is en “in een handomdraai” gebruikt kan worden. Maar installeren is natuurlijk wel een vereiste, dus hoe zit het met dat “doorloop het bestelproces en installeer”? Nou, dat leest u verkeerd:

Met de zin: “Doorloop het bestelproces en installeer wordpress op je hostingpakket” wordt niet gesuggereerd dat de installatie van ‘wordpress’ tijdens het bestelproces zal plaatsvinden.

Want de letterlijk geörienteerde lezer ziet dat hier twee ongerelateerde zaken toevallig in één zin staan: (1) doorloop het bestelproces en (2) installeer WordPress. Je krijgt immers een hostingpakket, en daar kun je best WordPress op installeren. Nee, dat gaat niet automatisch en zeker niet door ons. “Dat is een interpretatie die klager eraan geeft.”

Dit is dus waar de giecheltoets voor gemaakt is: leuk geprobeerd vriend, maar zo werkt het niet. Door ze naast elkaar te zetten, suggereer je een verband – in dit geval dus dat men bij het bestelproces een installatie van WordPress krijgt waarna men “in een handomdraai” deze kan gebruiken.

De Reclame Code Commissie is het eens met de klager. De gemiddelde consument zal denken dat hij met deze aanbieding direct met WordPress aan de slag kan gaan, en aangezien dat niet het geval is, is de reclameuiting oneerlijk in de zin van de Nederlandse Reclame Code.

Arnoud

Van wie is die website (met CMS)

Weer een regelmatig terugkerende kwestie: mensen laten een website bouwen, denken daar eigenaar van te zijn maar er blijkt een door de sitebouwer zelf ontwikkeld CMS achter te liggen. En artikel 18.3 van diens algemene voorwaarden bepaalt dat het eigendom daarvan “ten alle tijde” (sic) bij hem ligt. Ja, dat is rechtsgeldig ondanks die taalfout.

Hoofdregel uit het auteursrecht is dat degene die een werk maakt, de rechten daarop heeft. Ook als deze in opdracht werkt, hét grote misverstand bij online auteursrechten (oké, naast “het staat op internet en is dus vrij van rechten”). Als je dus een site laat bouwen, is die niet van jou. De site is van de ontwikkelaar en hij staat jou toe deze te gebruiken voor het doel dat in de offerte is benoemd, meer niet.

Natuurlijk kun je daar andere afspraken over maken in het contract. Een zin als “het (intellectueel) eigendom van de site ligt bij Klant” is genoeg, mits de passage ondertekend wordt en duidelijk is om welke site het gaat.

Dan is er nog één probleem: het contentmanagementsysteem oftewel CMS waarmee de site is gebouwd. Er zijn bergen opensourcecontentmanagementsystemen (zie plaatje) waarmee dit zou kunnen, maar menig ontwikkelbedrijf voelt de onbedwingbare neiging om toch zelf een CMS te bouwen. Goed, dat mag, maar het gevolg is wél dat je als klant alsnog vastzit aan dat ontwikkelbedrijf. Je zou haast gaan denken dat ze het erom doen.

De eigendom van het CMS opeisen kan, maar dan moet je wel een aparte bijzin opnemen “inclusief het achterliggende CMS” in die zin die ik daarnet noemde. Maar of de ontwikkelaar daarmee akkoord gaat, betwijfel ik. Hij kan dan immers het CMS aan niemand anders meer beschikbaar stellen. Mogelijk komt ie zelfs in de problemen met bestaande klanten die het CMS al gebruiken (hoewel dat op zich prima te regelen is met een licentie terug).

Dit probleem voorkomen kan maar op één manier: vooraf vragen met welk CMS de site gebouwd gaat worden en hoe het zit met eigendom daarvan. En dat behoort net zo’n logische vraag te worden als de verborgen gebreken bij huizen.

Arnoud

Zijn WordPress themes GPL?

wordpress-bible.pngEen lezer vroeg me:

Alweer een tijdje geleden speelde een discussie over het Thesis theme voor WordPress. Dat is een systeem voor layouts en uitbreidingen op het WordPress blogsysteem, dat eerst onder een gesloten (niet-open source) licentie beschikbaar was. WordPress zelf is GPL, en de auteurs daarvan eisten dan ook dat Thesis ook GPL moest worden. Eerst wilde Thesis dat niet, maar na na flink wat discussie hebben ze het uiteindelijk toch GPL gemaakt. Maar had dat nou echt gemoeten?

De open source licentie GPL eist dat “afgeleide werken”, bij ons “verveelvoudigingen in gewijzigde vorm” van hun code alleen maar verspreid mag worden onder diezelfde GPL. Je kunt geen afgeleid werk verspreiden onder een andere licentie. (Maar je hóeft je code niet te distribueren als je dat niet wil; wie dus voor zichzelf GPL code aanpast hoeft niets te delen.)

De vraag wat een afgeleid werk precies is, is al zo oud als de GPL zelf. De discussie over plugins op GPL code hebben we al een paar keer gehad, maar die voor themes nog niet.

Een theme is voor mij net wat anders dan een plugin. Een plugin is nieuwe code die inhaakt op de originele code, en de functionaliteit daarvan uitbreidt. Ik denk dat je een plugin dan ook wel als een afgeleid werk kunt zien, hoewel er in de GPL een uitzondering staat voor

If identifiable sections of [the modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

WordPress vindt dat dit een uitgemaakte zaak is: WordPress extensies en themes zijn altijd afgeleid van WordPress zelf, hoewel ze qua onderbouwing niet verder komen dan “Drupal zegt het veel beter dan wij” en Drupal niet meer zegt dan “Ja dat is zo”.

Als je kijkt naar hoe themes gebouwd worden, dan zie je dat ze een vrij standaard structuur volgen om de layout te definiëren en op bepaalde punten routines uit WordPress aanroepen (“plak hier de titel van de blog”, “doe dit voor tien blogberichten”, “zet hier de datum, in formaat mm-dd-jj”) zodat de bezoeker de juiste informatie in de juiste layout te zien krijgt. Ik zie niet hoe je dat kunt zien als een verveelvoudiging van de WordPress-code zelf. Het aanroepen van een functie maakt je code nog niet “afgeleid”.

Daar komt bij dat eind vorig jaar het Europese Hof van Justitie bepaalde dat user interfaces géén deel zijn van de copyright op de software zelf (en een theme is de realisatie van een interface). Toegegeven, dat ging over de vraag of het kopiëren van de interface een auteursrechtschending was, maar als het auteursrecht op de software zich niet uitstrekt tot de interface, waarom zou het dan wél gelden voor andermans interface?

Ik denk dan ook dat je pas van een afgeleid werk kunt spreken als de theme code kopieert of diep ingrijpt in WordPress zelf, bijvoorbeeld door het vervangen van core code. Een ‘gewoon’ theme is geen afgeleid werk.

Arnoud