* 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?

* 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.)

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?)

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-

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.