Creative Commons – Bausatzsystem für Lizenzen

Wenn jemand ein Werk schafft, so hat derjenige auf dieses Werk ein Urheberrecht. Ein solches Werk könnte z.B. ein Foto oder ein Musikstück sein. Wenn dieses Foto nun anderen Menschen zur Verfügung gestellt werden soll, wird es kniffelig. In Deutschland wäre es nicht einmal möglich auf das eigene Urheberrecht zu verzichten. Stattdessen können Nutzungsrechte an dem Werk eingeräumt werden. Es muss also ein Lizenzvertrag zwischen dem Urheber und den Nutzern geschlossen werden.

Möchte der Urheber nun noch bestimmte Einschränkungen wird es noch kniffliger. Schließlich ist es nicht unbedingt einfach, etwas juristisch sicher (und einfach) zu definieren. Bei der Lösung dieses Problems kommt Creative Commons ins Spiel.

Creative Commons

Bei den Creative Commons-Lizenzen handelt es sich um eine Art Bausatzsystem für Lizenzen. Dieser Bausatz setzt sich aus den Komponenten BY, SA, NC und ND zusammen. BY beschreibt die Notwendigkeit der Namensnennung bei Nutzung des Werkes. Im Gegensatz zu den anderen Komponenten ist die Namensnennung immer verpflichtend. Die Komponente SA beschreibt die Weitergabe unter gleichen Bedingungen. Das bedeutet, wenn ein Werk unter der Creative Commons-Lizenz CC-BY-SA genutzt wird, so muss das daraus entstehende Werk unter der gleichen Lizenz veröffentlicht werden.

Die NC-Komponente definiert, dass das Werk nicht kommerziell genutzt werden darf. Zum Beispiel darf ein Musikstück, welches unter der Lizenz CC-BY-NC lizenziert ist, privat gehört werden, aber es darf nicht genutzt werden, um es in einem Werbespot einzubinden. Die letzte Komponente ist ND, welche definiert, dass es keine Derivate von dem betreffenden Werk geben darf. Als Nutzer kann ich somit das beispielhafte Musikstück hören, darf aber keinen Remix im Rahmen dieser Lizenz erstellen.

Die Bausteine können kombiniert werden. So könnte ein Werk unter der Lizenz CC-BY-ND oder unter der Lizenz CC-BY-NC-SA veröffentlicht werden. Bestimmte Kombinationen scheiden allerdings aus; so wäre die Kombination CC-BY-ND-SA nicht zielführend, da eine Weiterverbreitung abgeleiteter Werke unter der gleichen Lizenz der Bedingung, das keinerlei Derivate von dem Werk erstellt werden dürfen widerspricht.

Mit dem License Chooser geht die Wahl der passenden Bausteine im Browser leicht von der Hand. Bei der Nutzung sollten die Lizenzbedingungen entsprechend beachtet werden. Fehler werden meist bei der Namensnennung gemacht. Creative Commons definiert diese Pflicht in dem Commons (die gekürzte und für normale Menschen verständliche Form der Lizenz) so:

Namensnennung — Sie müssen angemessene Urheber- und Rechteangaben machen, einen Link zur Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Diese Angaben dürfen in jeder angemessenen Art und Weise gemacht werden, allerdings nicht so, dass der Eindruck entsteht, der Lizenzgeber unterstütze gerade Sie oder Ihre Nutzung besonders.

Je nach genutzter Version der Lizenzen ist dies mehr oder weniger kompliziert, wie der Artikel bei iRights näher beleuchtet.

Neben diesen Lizenzen existieren einige weitere Lizenzen aus dem Creative Commons-Universum wie die CC0, welche es ermöglicht die Nutzungsrechte so freizugeben, dass das Werk praktisch Public Domain ist und somit der Gemeinschaft uneingeschränkt zur Verfügung steht. Wichtig ist es bei der Nutzung darauf zu achten, das sich Creative Commons nicht für jedes Werk eignet, so wird von der Lizenzierung von Software unter Creative Commons-Lizenzen expliziert abgeraten. Hier existieren bessere Lizenzen wie die GPL, die Apache- oder die MIT-Lizenz.

Zugriff auf MAMP-Logs

MAMP (Mac, Apache, MySQL und PHP) ist ein Paket zum lokalen Betrieb eines Webservers für Test- und Entwicklungszwecke. Neben der ursprünglichen Version für macOS, existiert mittlerweile auch eine Version für Windows. Bei der Entwicklung von Software z.B. einer PHP-Anwendung ist es hilfreich die Logs der einzelnen Bestandteile von MAMP nutzen zu können. Unter macOS befinden sich die Logs in dem Ordner:

/Applications/MAMP/logs/

In diesem Ordner sind eine Reihe von Dateien zu finden. Die einzelnen Logdateien tragen folgende Dateinamen:

/Applications/MAMP/logs/apache_error.log 
/Applications/MAMP/logs/mysql_error_log.err
/Applications/MAMP/logs/nginx_access.log 
/Applications/MAMP/logs/nginx_error.log 
/Applications/MAMP/logs/php_error.log

Die Nginx-Log-Dateien tauchen nur auf, wenn Nginx als Webserver in den Einstellungen von MAMP verwendet wurde. In der Windows-Version befinden sich die Log-Dateien ebenfalls im log-Ordner, welcher sich wiederum im MAMP-Installationsordner befindet.

REST-APIs unter Apache und Nginx betreiben

Eine der wesentlichen Eigenschaften von REST-APIs bzw. RESTful-Webservices ist ihre Adressierbarkeit von Ressourcen. Wenn ich z.B. über eine API verfüge, welche mir Namen generiert, so kann es in dieser API unterschiedliche Ressourcen geben:

GET https://api.example.com/name/german/
GET https://api.example.com/name/polish/

Rufe ich nun eine der beiden Ressourcen mit dem HTTP-Verb GET auf so erhalte ich entweder einen deutschen oder einen polnischen Namen von dieser Beispiel-API. Für den Webserver ergibt sich allerdings das Problem, das der Ordner name und die entsprechenden Unterordner nicht existieren. Das einzige was in diesem Beispiel existiert ist eine index.php-Datei, welche unter der URL:

https://api.example.com/index.php

zu finden ist. Damit die REST-API ordnungsgemäß funktioniert, müssen die entsprechenden Aufrufe zur index.php-Datei umgebogen werden. Bei dem Webserver Apache kann dies über eine .htaccess-Datei mit folgendem Inhalt erledigt werden:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php?_url=/$1 [QSA,L]
</IfModule>

Diese Datei sollte dabei im gleichen Verzeichnis wie die Datei index.php liegen. Bei Nginx muss stattdessen die Konfiguration der Domain bzw. der Seite angepasst werden. Diese Konfigurationen sind unter /etc/nginx/sites-available/ zu finden. Dort muss folgende Konfiguration hinzugefügt werden:

try_files $uri $uri/ @rewrite;

location @rewrite {
	   rewrite ^/(.*)$ /index.php?_url=/$1;
}

Hinterlegt werden muss die Konfiguration in einem server-Block derselben. In diesem Fall würde die URL bzw. der Aufruf:

GET https://api.example.com/name/german/

intern in die URL:

https://api.example.com/index.php?_url=name/german/

umgeschrieben und vom Webserver geladen. Dadurch landen die Aufrufe wieder bei der Datei index.php und können verarbeitet werden.

Let’s Encrypt unter Ubuntu und Nginx einrichten

Vor einigen Tagen habe ich damit begonnen alle von mir betriebenen Webseiten auf TLS umzustellen. Dabei nutzte ich Zertifikate der Zertifizierungsstelle Let’s Encrypt. Let’s Encrypt ging dabei im letzten Jahr in Betrieb und liefert kostenlose Zertifikate für TLS. Die CA wird dabei unter anderem von der EFF und Mozilla unterstützt. Im Gegensatz zu anderen Lösungen ist der Prozess bei Let’s Encrypt hochgradig automatisiert, so das die Einrichtung schnell von statten geht.

Der offizielle Client hört dabei auf den Namen Certbot (früher Let’s Encrypt Client) und implementiert das ACME-Protokoll (Automated Certificate Management Environment) über welches der Prozess abgewickelt wird. Neben dem offiziellen Client gibt es viele weitere Clients welche das ACME-Protokoll implementieren. Um Let’s Encrypt unter Ubuntu zu nutzen, muss im ersten Schritt der Client installiert werden:

apt-get install letsencrypt

Nachdem der Client installiert wurde, kann mit der Erzeugung der Zertifikate begonnen werden. Im Gegensatz zu Apache wird unter Nginx die automatische Einrichtung nicht unterstützt. Aus diesem Grund werden nur die Zertifikate mit dem Client erzeugt. Dies geschieht mit dem Befehl:

letsencrypt certonly

Damit wird der interaktive Modus gestartet in welchem das Zertifikat erzeugt werden kann. Zuerst wird nach einer Mailadresse gefragt, mit welcher das Recovery in Notfällen möglich ist. Anschließend müssen die allgemeinen Geschäftsbedingungen akzeptiert werden. Nun wird nach den Domains gefragt, für welche ein Zertifikat erstellt werden soll. Hier kann man mehrere Domains per Komma bzw. Leerzeichen getrennt angeben – allerdings scheint dies in der aktuellen Version nicht zu funktionieren. Stattdessen wird nur für die erste angegebene Domain ein Zertifikat erzeugt. Standardmäßig benötigt Certbot während der Generierung der Zertifikate Zugriff auf den Port 80. Hintergrund für dieses Verhalten ist das der Client kurz einen Webserver aufsetzt um die Kommunikation mit der CA durchzuführen.

Abgelegt werden die erzeugten Zertifikate dabei im Ordner /etc/letsencrypt/. In diesem Ordner liegen neben den Stammzertifikaten auch die eigentlichen Zertifikate für die einzelnen Domains. Nun kann dieses Zertifikat in Nginx eingebunden werden. Dazu muss die Konfigurationsdatei der jeweiligen Seite (z.B. /etc/nginx/sites-available/example) geöffnet werden. Im ersten Schritt wurde dazu in der Konfiguration eine Weiterleitung eingerichtet:

server {
        listen 80;
        listen [::]:80;

        server_name .example.org;

        return 301 https://$host$request_uri$is_args$args;
}

Diese Weiterleitung sorgt dafür das eine Verbindung über unverschlüsseltes HTTP automatisch auf die verschlüsselte Variante umgeleitet wird. Weiter geht es mit der Konfiguration der verschlüsselten Verbindung:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        ...

Jedes erzeugte Zertifikat von Let’s Encrypt ist 90 Tage lang gültig, so das ein automatischer Prozess eingerichtet werden sollte um die Zertifikate automatisch zu erneuern. Mit dem Befehl:

letsencrypt renew --agree-tos

kann dabei der Erneuerungsprozess angestoßen werden. Möchte man das ganze ohne Risiko testen, so sollte der Parameter –dry-run angefügt werden.

letsencrypt renew --agree-tos --dry-run

Bei der Erneuerung der Zertifikate kann es nun vorkommen das man den Nginx-Server vorher beenden muss. Das ganze kann man in ein Skript gießen:

#!/bin/sh
service nginx stop
letsencrypt renew --agree-tos
service nginx start

Dieses Skript kann man nun zum Beispiel einmal in der Nacht per Cronjob ausführen. Der Client überprüft dabei ob eine Erneuerung notwendig ist und führt diese dann automatisch durch.

Befehlszeile mittels JewelCli unter Java auswerten

Die Methodensignatur der Standardeinsprungsmethode sieht unter Java wie folgt aus:

public static void main(String[] args)

Übergeben wird hierbei ein String-Array welches die Argumente der Befehlszeile enthält. Möchte man diese auswerten, kann man das natürlich von Hand machen. Alternativ kann man eine Bibliothek nutzen, welche einem diese Arbeit abnimmt. Eine dieser Bibliotheken ist JewelCli. JewelCli arbeitet auf Basis von Annotationen. Im ersten Schritt muss dazu ein Interface definiert werden:

public interface CommandLineOptions {
    @Unparsed
    List getFiles();

    @Option
    boolean isRecursive();

    @Option(defaultValue="localhost")
    String getDatabase();

    @Option(helpRequest = true)
    boolean getHelp();
}

In diesem Interface werden die verfügbaren Optionen über Annotationen definiert. So werden in den ersten zwei Zeilen die Unparsed-Optionen definiert. Das sind Optionen ohne Schlüssel, welche dann z.B. als Dateinamen interpretiert werden können. Die zweite Option welche im Interface definiert wird ist ein Schalter. So kann später in der Befehlszeile der Wert -recursive definiert werden, was sich auf den Wert der Rückgabe von isRecursive() auswirkt. Bei der dritten Option wird ein String übergeben welcher in der Befehlszeile mittels –database db.example.com definiert werden kann. Der Parameter ist dabei optional, so wird der Wert localhost angenommen, wenn der Wert nicht über die Befehlszeile definiert wurde. Die letzte Option dient der Implementation der Hilfe-Funktionalität. Wird der Parameter angegeben, so erzeugt JewelCli automatische die entsprechende Hilfsausgabe für die definierten Parameter. Daneben gibt es noch eine Reihe weiterer Nutzungsmöglichkeiten. Wenn das Interface definiert ist, ist der Großteil der Arbeit abgeschlossen. Nun muss die Auswertung der Parameter angestoßen werden:

CommandLineOptions result;

try {
    result = CliFactory.parseArguments(CommandLineOptions.class, args);
}
catch (ArgumentValidationException e)
{
    System.out.println(e.getMessage());
    return;
}

Dazu wird die Methode parseArguments der Klasse CliFactory genutzt, welche die Argumente unter Nutzung des definierten Interfaces auswertet. Schlägt dies fehl wird eine Exception ausgelöst und die Nachricht dieser auf der Konsole ausgegeben. Der Quelltext von JewelCli kann unter anderen auf GitHub bezogen werden. Lizenziert ist die Bibliothek unter der Apache-Lizenz und damit freie Software.