Zijn WordPress themes GPL?

| AE 2785 | Intellectuele rechten | 10 reacties

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

Deel dit artikel

  1. Toch kan ik me wel een beetje vinden in hun argumenten:

    * The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called * They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. * As works of authorship, they are designed only to be combined with WordPress into a larger work.
    De logica van een WordPress theme is inderdaad minimaal. Zo minimaal dat het al erg lastig zou worden om te bepalen of het ene theme nou wel of niet een afgeleid werk van een ander theme zou zijn. Dit is dus eigenlijk een andere discussie: een niet-GPL WordPress theme zou niet zozeer een GPL-violatie zijn omdat de auteurs van WordPress dat vinden, maar omdat het een afgeleid werk zou zijn van bijvoorbeeld Twenty-Eleven, het standaard WordPress theme.

    Die minimale logica zorgt er verder inderdaad voor dat de functionaliteit van de theme afhangt van de implementatie van de WordPress functies. Ik vind de WordPress functies die je vanuit een theme aanroept niet zozeer een API, maar eerder callback functies of hooks, waarbij het theme hooguit bepaalt hoe de content in de HTML wordt geplaatst, of op welk moment. Dit is een erg WordPress-theme-specifiek argument wat voor plugins al een stuk minder zou opgaan.

    En tot slot blijkt uit die hele specifieke callback functies ook weer dat het onmogelijk is dat een theme op zichzelf staat. Een theme is specifiek voor WordPress op dezelfde wijze als een Senseo pad (of clone) specifiek voor een Senseo apparaat is gemaakt.

    Kortom ik kan hun redenatie best wel begrijpen. WordPress themes zijn geen API client die als zelfstandig proces draait en waarbij de API calls maar een klein deel van de functionaliteit zijn. Ze worden geladen en aangeroepen door WordPress, zijn vrij dun qua logica, en zijn er echt sterk mee verstrengeld.

    Aan de andere kant een leuke gedachtenoefening: wat als ik een CMS maak wat exact dezelfde functienamen gebruikt, dit closed source maak maar de API publiceer, en vervolgens themes voor dit CMS bouw en buiten de GPL om publiceer. Waarbij ik vertel dat mijn CMS ook WordPress themes aankan en heel misschien andersom ook wel het geval zou kunnen zijn. Of vindt WordPress hun API ook auteursrechtelijk beschermd?

  2. @Richard: WordPress zegt:

    * They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call.
    Dat is onzin (niet gebaseerd op wet of jurisprudentie) en gelet op de recente uitspraak van Advocaat Generaal Bot eerder een argument om ze niet-afgeleid te verklaren.
    De logica van een WordPress theme is inderdaad minimaal. Zo minimaal dat het al erg lastig zou worden om te bepalen of het ene theme nou wel of niet een afgeleid werk van een ander theme zou zijn.
    De standaardoplossing in het auteursrecht is om het deel wat opgelegd wordt door de omgeving niet-creatief te verklaren, daarmee wordt het niet beschermd door het auteursrecht. Thema’s worden alleen door het auteursrecht beschermd waar het gaat om het creatieve deel van hun inhoud.

    Jouw gedachtenexperiment is interessant. Volgens EUropees recht is een API (mogelijk) auteursrechtelijk beschermd, maar mag je hem gebruiken om interoperabiliteit mogelijk te maken. Het interoperabiliteitsargument haalt een algemene verplichting om plugins onder een specifieke licentie te verspreiden onderuit. (N.B. Wanneer een plugin gelinkt wordt met een bibliotheek kan de licentie op de bibliotheek verspreiding van het gecombineerde werk beperken.)

  3. @Derk, niemand kan eisen dat een werk onder de GPL beschikbaar wordt gemaakt. Auteursrechthebbenden op GPL code waarop een werk gebaseerd is kunnen een verspreidingsverbod van het inbreukmakende werk vorderen. (Verspreiding is slechts toegestaan onder GPL voorwaarden: volg de GPL voorwaarden of verspreid niet, de keus is aan de maker van het afgeleide werk.) De GPL ontwikkelaar kan ook naar de rechter stappen om verspreiding van thema’s of plugins te verbieden, maar de kans is groot dat de rechter zijn claim zal afwijzen. (Zie bovenstaande discussie.)

    Er kunnen contractrechtelijke aanspraken van de klant op haar leverancier zijn met betrekking tot hoe software geleverd wordt, maar dat zou per concreet geval apart beoordeeld moeten worden. (Wat heeft de leverancier beloofd?)

  4. Zie ook de discussie naar aanleiding van deze reactie onder een oude blogpost.

    Het lijkt mij dat het GPL-begrip “derivative work” niet breder kan zijn dan het begrip “geheele of gedeeltelijke bewerking of nabootsing in gewijzigden vorm, welke niet als een nieuwe, oorspronkelijk werk moet worden aangemerkt” van art. 13 Aw. Dit kan zeker niet als je de GPL zoals Mathfox opvat als een verzameling voorwaarden voor verspreiding van het werk (waar ik het volledig mee eens ben), want in dat geval wordt de GPL per definitie beperkt door de reikwijdte van het auteursrecht.

    Voor een derivative work moet je dus zoveel uit het oorspronkelijke werk overnemen, dat je inbreuk maakt op het auteursrecht van dat werk. Het oorspronkelijke werk is hier de WordPress-code. Voor een derivative work zul je dus stukken uit die code gekopieerd moeten hebben die niet volstrekt triviaal zijn, en die ook niet volledig functioneel bepaald zijn (bijv. het aanroepen van een API).

    Nou ja, ik ben het dus eens met wat hierboven al wordt gezegd 😉

    -edit Arnoud: excuses namens het spamfilter dat je van 3 t/m 6 december liet zitten-

  5. Om de vraag iets algemener te maken zal ik een theme als een configuratiefile beschouwen. Is je eigen configuratie van software die je gebruikt een van die software afgeleid werk?

    Dat de taal (vorm en betekenis) van de configuratie heel sterk wordt bepaald door de software waar de configuratie voor is lijkt me daarvoor inderdaad geen sterk argument (maar goed, ik ben geen jurist).

    Een sterker argument lijkt me zulke configuraties zelf al met de software worden meegeleverd en je eigen configuraties daar vaak uit zullen worden afgeleid.

    Een ander punt is dat in een theme vaak een boel eigen creativiteit en arbeid zit, meer dan bij andersoortige softwareconfiguraties. Als je maar genoeg verandert aan je kopie van de Mona Lisa is het echt geen Mona Lisa meer. En er is geen magische grens van Mona-Lisaheid.

  6. Vind dit geen sterk argument van WordPress. Volgens hun ‘logica’ is een programma dat op Windows draait dus ook een ‘afgeleide van Windows’. Of een programma dat op een computer draait is een afgeleide van die computer. Is een auto die op een weg rijdt een afgeleide van die weg? Je kunt beargumenteren dat die weg is aangelegd om auto’s op te laten rijden. Het feit dat WordPress het bestaansrecht voor het thema vormt, betekent niet dat je dat kunt omdraaien en dat WordPress iets te zeggen heeft over het thema.

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS