WordPress-Themes und die GPL

Das Content Management System WordPress ist unter der GPL lizenziert und damit stellt sich die Frage, ob Themes unter WordPress ebenfalls unter der GPL lizenziert sind? Die kurze Antwort: Themes müssen unter der GPL lizenziert werden. Im Detail können bei der Frage allerdings Abstufungen vorgenommen werden. Die GPL definiert eine Reihe von Freiheiten:

Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck (Freiheit 0).

Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.

Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2).

Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.

Da die PHP-Dateien eines Themes die unter der GPL lizenzierten Schnittstellen von WordPress nutzen, muss das Theme ebenfalls unter der GPL lizenziert werden. Das Theme läuft niemals für sich alleine, sondern benötigt zwingend die entsprechenden WordPress-Schnittstellen. Sobald ein Theme distribuiert wird, muss es unter der GPL lizenziert werden.

Mit Themes lässt sich das Aussehen der Webseite anpassen

Mark Jaquith, einer der Entwickler von WordPress drückte das Ganze wie folgt aus:

Theme code necessarily derives from WordPress and thus must be licensed under the GPL if it is distributed.

Der Einwand, welcher ab und an vorgebracht wird, das mit einem GPL-Theme kein Geld verdient ist dabei haltlos. Die GPL verbietet es nicht mit GPL-Software Geld zu verdienen. So kann ein Ersteller eines Themes die Themes verkaufen. Natürlich könnte nun ein Käufer das Theme anderweitig bereitstellen, allerdings kann der Nutzer bei vielen Erstellern Updates der Themes und Support dazu kaufen. Dies stellt einen Mehrwert gegenüber eine Theme da, welches eventuell schon veraltet ist.

Theoretisch können WordPress-Themes unter unterschiedlichen Lizenzen angeboten werden. Dies war beim Theme Thesis der Fall. Hier sind sämtliche PHP-Dateien unter der GPL lizenziert, während CSS- und JavaScript-Dateien proprietär sind. Interessant wird es bei Lizenzbedingungen, des Theme-Erstellers, welche gegen die GPL verstoßen. Technisch betrachtet dürften solche Themen nicht mit WordPress genutzt werden.

WordPress ist nicht das einzige System, bei welchem sie die Rechtslage so darstellt, so erklärt die FAQ des Content Management Systems Drupal:

Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later. You are not required to distribute them at all, however. (See question 8 below.)

Wie sieht, es in dem Fall aus das ein Theme erstellt wurde und dieses Theme auf der eigenen Webseite genutzt wird? Muss dieses Theme nun unter GPL bereitgestellt werden? Die Antwort darauf ist nein. Der Grund hierfür ist das, wenn ich ein unter GPL lizenziertes Produkt ausliefere, ich den Quelltext dazu veröffentlichen muss. Allerdings liefert WordPress keine Themes, sondern Webseiten aus. Deshalb muss der Quelltext des Themes nicht bereitgestellt werden. Wäre dies der Fall wären z.B. alle Dokumente welche mit LibreOffice erstellt werden auch unter der GPL lizenziert werden. Dazu noch einmal Mark Jaquith:

No. The GPL is triggered by distribution. Work-for-hire for a client is not distribution. In this case, they would have the copyright on the code. Distributing it would be up to them. As long as they didn’t distribute it, the GPL wouldn’t kick in. Your clients needn’t worry.

Dump einer MediaWiki-Installation erstellen

Wer eine Wiki mit der freien Software MediaWiki betreibt und einen Dump derselben erstellen möchte, kann hierfür eines der Werkzeuge nutzen, welches bereits mit der MediaWiki-Installation mitgeliefert wird. Im Ordner maintenance findet sich für diese Zwecke das PHP-Skript dumpBackup.php:

php dumpBackup.php --full > dump.xml

Mit dem Befehl wird die komplette Wiki, inklusive der Historie jeder Seite, gesichert und in den Dump geschrieben. Soll nur der aktuelle Stand der Wiki gesichert werden, so kann hierfür der Parameter current genutzt werden:

php dumpBackup.php --current > dump.xml

Für eine komplette Sicherung der Wiki sollte nicht nur der Dump, sondern auch der Ordner images gesichert werden.

Matomo-Berichte per Cronjob generieren

Matomo ist eine freie Software zur Webanalytik. Früher war Matomo unter dem Namen Piwik bekannt. Wenn Matomo Berichte auf der Weboberfläche anzeigt, so werden diese vorher generiert. Geschieht dies beim Aufruf der Berichte, kann dies, vor allem bei größeren Berichten, zu Problemen führen, da der Server entsprechend viel Zeit für die Erstellung benötigt und dies sich auf die Ladezeit der Weboberfläche auswirkt.

Die Archivierung bei der Anzeige im Browser sollte deaktiviert werden

Als Lösung bietet es sich an die Aufgabe, der Berichterzeugung und Datenaggregierung, an einen Cronjob auszulagern. Dazu muss im ersten Schritt die Crontab-Datei geöffnet werden:

sudo -u www-data crontab -e

Ich die sich öffnende Crontab-Datei wird nun folgende Zeile eingetragen:

*/15 *    * * *   php /var/www/example/matomo/console core:archive > /dev/null

Nachdem die Crontab-Datei gespeichert wurde, wird der Task zur Archivierung und Erstellung der Berichte alle 15 Minuten automatisch gestartet. In den Matomo-Einstellungen unter System -> Allgemeine Einstellungen findet sich der Punkt Archivierungseinstellungen. Hier muss die Archivierung im Browser deaktiviert werden. Damit werden Berichte in Matomo nun per Cronjob erzeugt und beeinflussen die Ladezeiten der Weboberfläche nicht mehr.

ownCloud und Nextcloud

Mit ownCloud gab es ab 2010 eine Lösung Daten in der Cloud zu lagern, welche nicht bei einem dritten Dienstleister, wie z.B. Dropbox, hinterlegt werden mussten. Im Gegensatz zu anderen Lösungen aus der damaligen Zeit ließ sich ownCloud relativ unkompliziert auf einem einfachen Webspace, welcher über PHP und eine Datenbank verfügte, installieren. Einige Jahre entwickelte sich ownCloud prächtig, bis es zu Meinungsverschiedenheiten über die Ausrichtung von ownCloud kam. Darauf hin verließen Frank Karlitschek, der Hauptentwicker von ownCloud, und einige weitere Entwickler die Firma ownCloud GmbH und spalteten das Projekt unter dem Namen Nextcloud ab.

Eine ownCloud-Installation wird zu Nextcloud migriert

Damit lief die Entwicklung der beiden Lösungen eine Weile parallel, wobei die Community und ein Großteil der Entwicklerkapazitäten gefühlt in Nextcloud steckten. Vor ein paar Tagen kündigte die ownCloud GmbH an, seine Architektur komplett umzustellen, womit die ursprüngliche ownCloud wohl tot ist und Nextcloud der mehr als legitime Nachfolger ist.

Ideentool wird zu Wryte

2014 veröffentlichte ich die erste Version meines Ideentools. Dabei handelte es sich um ein Werkzeug für Autoren welches unterschiedlichste Generatoren für Namen, Charaktere und ähnliches anbot. Im Laufe der Jahre kamen viele Generatoren hinzu, allerdings wirkte die Technik hinter dem Ideentool mittlerweile etwas angestaubt.

Das alte Ideentool

Im Zuge einiger Überlegungen entstand schlussendlich ein neues Projekt mit dem Namen Wryte. Der Fokus von Wryte ist ein wenig anders als der des Ideentools. So sollte Wryte internationalisierbar sein, also für unterschiedlichste Sprachen zur Verfügung stehen. Daneben sollte das Thema Schreiben etwas weiter gefasst werden, so soll es einmal um das Schreiben im Sinne eines Autoren und Schreiben im Sinne einer Entwicklers gehen.

Hintergrund hierfür war, das ich neben dem Schreiben auch entwickle und jeweils bestimmte Tools für beides immer wieder benötige. Deshalb sind die Werkzeuge in Wryte in zwei Personas unterteilt, einmal für Autoren und einmal für Entwickler.

Ein weiteres Ziel von Wryte war die Unterstützung und Integration in mobile Systeme. So kann die App unter iOS und Android auf den Homescreen gelegt werden und fühlt sich so wie eine native App an.

Wryte ersetzt das Ideentool

Technisch wurde die Architektur sinnvoller gestaltet. Während das Ideentool eine wilde Ansammlung von JavaScript– und PHP-Schnipseln war, wurde Wryte architektonisch in eine REST-API und die eigentliche Frontend-Applikation zerlegt. Die API soll in den nächsten Monaten öffentlich dokumentiert werden, sodass diese auch von anderen genutzt werden kann. Für die API wurde eine Swagger-Datei geschrieben und mittels dieser ein Server-Stub für das Slim Framework erzeugt. Die Frontendanwendung ist eine HTML5-App und kann im Gegensatz zum Ideentool auch auf mobilen Systemen sehr gut genutzt werden. Technisch basiert sie auf dem Framework 7-Framework.

Unter iOS kann die App auf den Homescreen gelegt werden

Zu finden ist Wryte unter wryte.net. Im Gegensatz zum Ideentool, fehlen noch einige Generatoren wie der Charakter- und Geheimnisgenerator, einige Fantasienamengeneratoren und die Generatoren für Titel und Verwandtschaftsverhältnisse. Die meisten dieser Generatoren sollen in den nächsten Wochen und Monaten hinzugefügt werden.