© Helder Almeida, 123Rf

Einmal entwickeln und auf allen möglichen Systemen laufen lassen – passend zum Schwerpunkt dieser Ausgabe erklärt der Recht-Artikel diesmal die lizenzrechtlichen Auswirkungen.

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.

Template: Java

Eine Programmiersprache verfolgt einen ganz anderen Ansatz: Den auf einem beliebigen System erstellten Quellcode übersetzt ein Compiler in Bytecode, der dann auf beliebigen Zielsystemen, für die ein passender Interpreter verfügbar ist, ausgeführt wird. Wenn dann auch die Oberflächen noch identisch aussehen oder sich nahtlos ans Zielsystem anpassen, handelt es sich um die konsequenteste Form plattformübergreifender Programmierung.

Das Urgestein der Multi-Plattform-Programmierung ist sicherlich Java, das – ursprünglich von Sun Microsystems entwickelt und lange Zeit streng gehütet – inzwischen auch unter die freie Lizenz GPL gestellt ist. So ganz frei ist Java damit allerdings noch nicht, denn Sun behielt das Recht am Markennamen und damit auch an der Referenzimplementierung. Es geht darum, was richtiges Java ist und was nicht. Neben der offiziellen Java-Runtime [4] hat sich die Community-gepflegte Open-JDK-Umgebung [5] zum Vorreiter in Sachen Entwicklung gemausert und bietet vieles, was Suns Runtime-Environment nicht schafft. Andererseits laufen viele Java-Programme zuverlässig nur mit der originalen Version, unter anderem so publikumswirksame Anwendungen wie etwa bestimmte Onlinebanking-Applikationen.

Nach einigem Hin und Her ist Oracle nun auch auf das Open JDK umgeschwenkt und nutzt es als Standard-Runtime-Umgebung. Blöd nur, dass es neben dem Open JDK auch weitere freie Runtimes gibt, etwa die des Apache-Harmony-Projekts [6], die schon allein deswegen von entscheidender Bedeutung ist, weil Android darauf aufsetzt. Und zum plattformneutralen Programmieren gehört eben die Ausrichtung auf damit angetriebene mobile Geräte. Was als “echtes” Java verkauft wird, muss daher nicht unbedingt auch auf Android laufen. Und was auf Android läuft, kann damit nicht immer als standardkonformes Java bezeichnet werden (Abbildung 2).

Abbildung 2: Was auf Android-Geräten läuft, muss nicht immer standardkonformes Java sein, und was echtes Java ist, muss nicht auf Android laufen. Quelle: Samsung

Lizenztechnisch ein großer Unterschied: Die offizielle Java-SE-Plattform wird unter dem Oracle Binary Code License Agreement [7] vertrieben, die anderen sind echte freie Software. Für den Entwickler kein (Lizenz-)Problem, er darf Java-Programme nach Belieben in Form von freier Software oder auch als proprietäre Closed-Source-Anwendungen vertreiben. Die Runtime dient nur dem Programmablauf und färbt lizenzrechtlich nicht auf das Programm selbst ab. Auch die verlinkte Standardbibliothek darf ohne Reue sowohl in freie als auch in “kommerzielle” Software eingebunden werden. Für die gibt es nämlich – auch wenn die Lib unter der GPL steht – eine Ausnahme, sodass man sie auch in proprietärer Software nutzen darf.

Das Problem beim Einbinden freier Software lösen die Entwickler zusätzlicher Bibliotheken unterschiedlich: Steht die Library unter der LGPL, färbt diese beim Linken nicht ab, auch wenn der Quellcode der Library anzubieten ist. Eine GPL Linking Exception [8] können der oder die ursprünglichen Entwickler per Erlaubnistext in die Lizenz aufnehmen, um ebenfalls das Abfärben beim Linken zu verhindern. Das bekannteste Beispiel dafür – neben der Java-Klassenbibliothek – ist GNU Classpath [9], eine freie Implementierung der Java-Standardbibliothek. Wer das Abfärben der GPL oder anderer freier Lizenzen erhalten will, stellt seine Bibliotheken einfach ohne solche Ausnahmeregelung unter GPL oder die jeweilige Lizenz.

Plattformspezifisch

Wer seine Anwendungen zwar nur einmal entwickeln, aber für die verschiedenen Zielplattformen separat ausliefern möchte, hat viel Arbeit vor sich. Am einfachsten geht’s noch mit Skriptsprachen, die für die grafische Oberfläche auf Toolkits aufsetzen. Bei der Bezeichnung Toolkit fällt einem auch gleich Tk ein, das nicht nur mit Tcl, sondern auch mit den etwas populäreren Sprachen wie Perl, Python oder sogar mit der Bash nutzbar ist.

Der große Vorteil dieser Kombinationen: Alle Programme sind frei. Der Vorteil für den Entwickler ist aber auch der Nachteil für den Verkäufer, denn mit Klartext-interpretierten Skriptsprachen lässt sich in der Regel kein Geld verdienen. Zudem ist die Ausführung so langsam, dass man bei umfangreicheren Applikationen selbst auf neuesten Rechner-Boliden nicht guten Gewissens darauf setzen kann.

Grafikbibliotheken gibt es aber auch für kompilierte Sprachen. Das bekannteste Beispiel ist Qt [10], das es in einer kostenlosen und freien sowie in einer kommerziellen Version gibt: Wer selbst feie Software schreiben will, darf die freie Variante nutzen, wer kostenpflichtige Closed-Source-Programme schreiben oder aus anderen Gründen seinen Quellcode nicht offenlegen will, für den gibt es die kommerzielle Variante.

Qt steht von Nokia als Qt/X11 für die Linux/Unix-Desktops, als Qt/Windows für die Microsoft-Schiene und als Qt/Mac für Apple-Anwendungen zur Verfügung. Natürlich ist Qt in erster Linie für die C++-Programmierer interessant, es gibt aber auch Implementierungen für C, Python, Perl und mehr. Die nötigen Libs für einfache grafische Oberflächen sind bereits enthalten.

Grafikbibliotheken

Wer auf andere, eigenständige Grafikbibliotheken setzen muss, der findet zum Beispiel in Cairo [11] etwas Plattformübergreifendes für 2-D-Grafiken und mit Mesa [12] eine 3-D-Bibliothek, die allerdings in erster Linie für das X-Window-System entwickelt und dort am besten einsetzbar ist. Cairo steht unter der LGPL und ist daher auch in kommerziellen Anwendungen nutzbar, Mesa steht unter der MIT-License und ist damit sowohl in kommerzieller Software nutzbar als auch zur GPL kompatibel.

Fazit

Wer möglichst plattformneutral programmieren will oder muss, ist lizenztechnisch nur mit Webanwendungen auf der sicheren Seite. Sollen die Anwendungen distribuiert werden, ist Java nach wie vor – oder wieder – erste Wahl, sind Systemintegration und einheitliches Look&Feel damit immer noch am besten gewährleistet. Und das Prinzip “Compile once, run everywhere” ist auch noch die komfortabelste Variante für den Entwickler.

Wenn es um native (Desktop-)Anwendungen geht, bietet Qt eine weitreichende und für Entwickler freier Software kostenlose Möglichkeit auch bei plattformübergreifendem Development lizenzrechtlich die passende Variante zu wählen, doch die Zielplattformen sind gegenüber Java eingeschränkt.