Lizenzfragen bei der plattformübergreifenden Programmierung

Programmierer sind faul, heißt es. Viele geben das sogar selbst offenherzig zu, aber immer mit dem Hintergedanken, dass es ja eher ein Zeichen für Intelligenz ist, sich unnötige Arbeit zu ersparen. Wer also schon bei der Software-Erstellung damit rechnet, dass seine Anwendungen nicht nur auf einem einzigen Zielsystem laufen werden, wer seine Software für möglichst viele verschiedene Systeme anbieten will, der setzt auf plattformneutrale Programmierung.

Erschwerend kommt hinzu, dass die Benutzer neben dem funktionalen Teil eine grafische Oberfläche erwarten, ja sogar als selbstverständlich voraussetzen. Einfach gelagerte Fälle, in denen es früher genügt haben mag, ein Bash-Skript aufzusetzen, das sich an den Posix-Standard hält, ein paar Hundert Zeilen Perl-Code oder ein Standard-C-Tool herzustellen, in dem vor der eigentlichen Arbeit die wichtigen Systemvariablen abgefragt und die Umgebung analysiert werden, gibt es nicht mehr. Es braucht Fenster, Schaltflächen und möglichst interaktive Grafikelemente, damit der Benutzer nicht nur schalten und walten kann, wie er will, sondern sich auch noch heimisch fühlt. Am besten, das Programm sieht so aus und lässt sich bedienen wie alles andere, was er auf seinem System kennt.

Alle können HTML

Der eine Ansatz, dies zu erreichen, ist eine Webanwendung. Moderne Browser können fast alles darstellen und bieten darüber hinaus auch hinreichende Sicherheit für Privatgebrauch und unternehmenskritische Anwendungen, und mit etwas Mühe bringt man seine Web-App sogar dazu, auf fast allen Browsern nahezu identisch auszusehen – was nicht nur für Corporate-Identity-Fetischisten mitunter wichtig ist. Dem stehen ein paar Nachteile gegenüber: Eine Webanwendung ist stets ein Fremdprogramm, sie integriert sich nicht in den Desktop und dem Nutzer vertraute Features wie Drag&Drop lassen sich kaum realisieren.

Lizenzrechtlich ist die Webanwendung dennoch die ideale Variante für jeden Entwickler: Weil lediglich die Darstellung der Daten über den Browser und dessen standardisierte Schnittstellen erfolgt, die eigentliche Datenverarbeitung jedoch der Server übernimmt, stellt sich hier erst gar nicht die Frage einer Weitergabe der Software und der damit verbundenen Lizenzprobleme.

Selbstverständlich lässt sich auch die Datenverarbeitung ganz oder teilweise auf den Benutzer-PC übertragen, etwa per Javascript, dann wird der Quellcode des Skripts jedoch im Klartext übermittelt. Das offenbart schon das erste Lizenzproblem: Javascript kann freie Software sein – oder nicht. Für den (Web-)Anwendungsentwickler stellen sich drei Fragen: Kann ich fremde (also von Dritten erstellte) Javascripts in meine Seite einbinden? Und wenn ja, unter welchen Voraussetzungen? Färbt ein GPL-Javascript auf meine Webanwendung ab, muss ich diese also unter eine freie Lizenz stellen? Welche Lizenz nutze ich am besten für meine eigenen Skripte?

Die erste Frage ist leicht beantwortet: Neben der bloßen Nutzung fremder Software liegt hier auch eine Verbreitung vor, weil der Javascript-Code übermittelt wird. Der Seitenbetreiber benötigt daher nicht nur ein Nutzungs-, sondern eben auch das urheberrechtliche Verbreitungsrecht für das "Programm". Handelt es sich bei dem Javascript-Code nicht lediglich um einen ganz trivialen Ansatz, schützt auch das Urheberrecht den Code, eine entsprechende Lizenz des ursprünglichen Programmierers ist erforderlich. Im Zweifel sollte man stets davon ausgehen, dass fremde Skripte nicht trivial sind, sondern die für das Urheberrecht erforderliche Schöpfungshöhe aufweisen. Wer also seinen Code nicht vollständig selbst entwickelt hat, sollte auf freie Software setzen, etwa Javascript-Dateien, die ausdrücklich unter die GPL oder LGPL gestellt sind.

Ist fremder Code nicht in eigene Skriptdateien eingebunden, sondern liegen diese etwa als separate ».js« -Dateien vor, wird das Abfärben der freien Lizenz in der Regel an der erforderlichen Bearbeitung oder Übernahme ins eigene Programm scheitern, das Skript bleibt damit ein unabhängiger Programmbestandteil. Damit tritt die Verpflichtung, die eigene Webanwendung vollständig unter die im freien Skript verwendete Lizenz zu stellen, nicht ein.

Die programmtechnische "Unabhängigkeit" wird aber mit zunehmender Verbundenheit dieses und gleich lizenzierter Skripte in der Web-App verschwinden, was letztlich doch wieder zur lizenzrechtlichen Abfärbung führt. Besteht die Web-App lediglich aus einem Container, in dem nahezu ausschließlich GPL-Skripte lagern, wird auch die Web-App unter die GPL zu stellen sein.

Nicht nur, um solche Probleme für die Community auszuschließen, sondern auch schon aus Überzeugung sollte der Programmierer daher freien Skripten auch bei der Eigenentwicklung den Vorrang geben. Unternehmenskritische Algorithmen und Daten sind ohnehin dem Server vorbehalten, womit auch die dritte Frage letztlich nur eine Antwort zulässt: Freie Programme oder Skripte sind auch hier mit Sicherheit die beste Wahl. Außerdem löst man damit das Problem, das beispielsweise die FSF als "Javascript-Trap" bezeichnet [1] und für das sie mit gleicher Feder Lösungsvorschläge aufzeichnet (Abbildung 1).

Abbildung 1: Hat die Javascript-Falle beschrieben, Richard Stallman.

Affero

Eine speziell für Webanwendungen gestaltete Lizenz ist die GNU Affero General Public License (AGPL, [2]). Sie gewährleistet die Freiheit für den Benutzer auch bei Software, die als Dienst über das Netz zur Verfügung steht. Weil mehr und mehr Anwendungen in Form von Software as a Service angeboten werden, die normale GPL dabei jedoch nicht greift, weil die Programme selbst ja nicht weitergegeben werden, hatte ursprünglich die Firma Affero [3] zusammen mit der FSF diese Lizenz entwickelt, die eine einfache Erweiterung der GPL darstellt.

Nach dieser Lizenz muss auch der Webapplikations-Anbieter die vollständigen Programmquellen verfügbar machen. Im Ergebnis die "bessere" GPL, ist diese Lizenz natürlich auch die beste Wahl für Webanwendungs-Entwickler. Für die derzeit aktuelle AGPL-Version 3 ist ausschließlich die Free Software Foundation verantwortlich.