Übersetzungen dieser Seite

Frei, aber gefesselt - Die Java-Falle

von Richard Stallman
12. April, 2004

Wenn Ihr Programm Freie Software ist, ist das grundsätzlich ethisch in Ordnung -- aber es gibt eine Falle, auf die Sie aufpassen müssen. Ihr Programm, obwohl es selber frei ist, kann durch unfreie Software, von der es abhängt, eingeschränkt sein. Da dieses Problem heutzutage vor allem bei Java-Programmen bekannt ist, nennen wir es die Java-Falle.

Ein Programm ist Freie Software, wenn seine Benutzer bestimmte entscheidende Freiheiten haben. Diese sind grob gesagt: Die Freiheit das Programm laufen zu lassen, die Freiheit die Quellen zu studieren und Änderungen vorzunehmen, die Freiheit, Quell- und Binär-Dateien zu vertreiben, und die Freiheit, verbesserte Versionen zu veröffentlichen. (siehe http://www.gnu.org/philosophy/free-sw.de.html.) Ob ein bestimmtes Programm Freie Software ist, hängt ausschließlich von der Bedeutung seiner Lizenz ab.

Ob das Programm aber in der Freien Welt verwendet werden kann, ob es von Leuten verwendet werden kann, die bewusst in Freiheit leben, ist schon eine komplexere Frage. Das hängt nicht von der Lizenz des Programmes selber ab, denn kein Programm läuft in Isolation. Jedes Programm hängt von anderen Programmen ab. Zum Beispiel muss ein Programm kompiliert oder interpretiert werden, somit ist es abhängig von einem Compiler oder Interpreter. Wenn es in Byte-Code kompiliert wird, hängt es von einem Byte-Code-Interpreter ab. Außerdem benötigt es Bibliotheken, damit es laufen kann, und es könnte andere Programme aufrufen, die in anderen, separaten Prozessen ablaufen. All diese Programme sind Abhängigkeiten. Abhängigkeiten, die notwendig sein könnten, damit das Programm überhaupt läuft, oder sie könnten nur für bestimmte Eigenschaften notwendig sein. So oder so, das ganze oder ein Teil des Programmes funktioniert nicht ohne diese Abhängigkeiten.

Wenn einige der Abhängigkeiten des Programmes unfrei sind, bedeutet das, dass das ganze oder ein Teil des Programmes nicht auf einem vollkommen freien System laufen kann -- es ist in der Freien Welt unbrauchbar. Natürlich, wir könnten das Programm zwar vertreiben und Kopien auf unseren Maschinen haben, aber das nützt wenig, wenn es da nicht läuft. Dieses Programm ist zwar Freie Software, aber es ist praktisch in Fesseln gelegt durch seine unfreien Abhängigkeiten.

Dieses Problem kann in jeder Art von Software auftauchen, in jeder [Programmier-]Sprache. Zum Beispiel ein freies Programm, das nur unter Microsoft Windows läuft, ist eindeutig unbrauchbar in der Freien Welt. Aber Software, die unter GNU/Linux läuft, kann ebenfalls unbrauchbar sein, wenn sie von anderer unfreier Software abhängt. In der Vergangenheit waren Motif (bevor wir LessTif hatten) und Qt (bevor seine Entwickler es zu Freier Software gemacht hatten) die großen Auslöser dieses Problemes. Die meisten 3D-Video-Karten funktionieren nur vollständig mit unfreien Treibern, was dieses Problem ebenfalls hervorruft. Aber die Hauptquelle dieses Problemes ist heutzutage Java, denn Leute, die Freie Software schreiben, finden Java oft sexy. Verblendet von der Anziehungskraft, die diese Sprache auf sie ausübt, übersehen sie das Problem der Abhängigkeiten und sie fallen in die Java-Falle.

Suns Implementation von Java ist unfrei. Blackdown ist ebenfalls unfrei; es ist eine Adaption von Suns proprietärem Code. Die Standard-Java-Bibliotheken sind gleichfalls unfrei. Wir haben zwar freie Implementationen von Java, wie zum Beispiel der GNU Compiler für Java (GCJ) und GNU Classpath, aber die unterstützen noch nicht alle Eigenschaften. Wir sind noch bei der Aufholjagd.

Wenn Sie ein Java-Programm unter Suns Java-Plattform entwickeln, sind Sie selber dafür verantwortlich, wenn Sie Sun-eigene Eigenschaften verwenden, ohne dass es Ihnen übehaupt auffällt. Zu der Zeit, wenn Sie dieses herausfinden, könnten Sie diese schon monatelang verwendet haben, und das Ganze umzuschreiben könnte wiederum Monate dauern. Sie könnten dann sagen: »Es wäre zu viel Arbeit, nochmal neu anzufangen.« Dann wird Ihr Programm in die Java-Falle gefallen sein; es wird in der Freien Welt unbrauchbar sein.

Der zuverlässige Weg, die Java-Falle zu vermeiden, ist, nur eine freie Implementation von Java auf dem System zu haben. Wenn Sie dann eine Java-Eigenschaft oder -Bibliothek verwenden, die Freie Software noch nicht unterstützt, werden Sie das unmittelbar herausfinden, und Sie können den Code sofort umschreiben.

Sun fährt damit fort, zusätzliche »Standard«-Java-Bibliotheken zu entwickeln, und die sind fast alle unfrei; in vielen Fällen sind sogar die Spezifikationen der Bibliothek ein Geschäftsgeheimnis [trade secret], und Suns jüngste Lizenz für solche Spezifikationen verbietet die Veröffentlichung von allem, das weniger als eine vollständige Implemetation der Spezifikation darstellt. (siehe http://jcp.org/aboutJava/communityprocess/JSPA2.pdf und http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html als Beispiele).

Zum Glück erlaubt diese Spezifikations-Lizenz die Veröffentlichung als Freie Software; andere, die diese Bibliothek erhalten, können bevollmächtigt werden, sie zu verändern und sind nicht verpflichtet, an der Spezifikation zu kleben. Aber diese Bedingung hat den Effekt, dass sie die Verwendung eines gemeinschaftlichen Entwicklungs-Modells zur Erstellung einer freien Implementierung verbietet. Die Verwendung dieses Modelles würde die Veröffentlichung von unvollständigen Versionen mit sich bringen, was denen, die die Spezifikationen gelesen haben, nicht erlaubt wird.

In der Frühzeit der Freie-Software-Bewegung war es unmöglich zu vermeiden, dass man von unfreien Programmen abhängig war. Bevor wir den GNU C-Compiler hatten, hing jedes C-Programm (frei oder nicht) von einem unfreien C-Compiler ab. Bevor wir die GNU C-Bibliothek hatten, hing jedes Programm von einer unfreien C-Bibliothek ab. Bevor wir Linux hatten, den ersten freien Kernel, hing jedes Programm von einem unfreien Kernel ab. Bevor wir Bash hatten, musste jedes Shell-Skript von einer unfreien Shell interpretiert werden. Es war unvermeidbar, dass unsere ersten Programme zunächst durch diese Abhängigkeiten behindert würden. Aber wir akzeptierten das, weil unser Plan auch beinhaltete, diese nach und nach zu befreien. Unser Gesamt-Ziel, ein selbstverwaltetes GNU-Betriessystem, beinhaltete freien Ersatz für all diese Abhängigkeiten; sobald wir das Ziel erreicht hätten, wären all unsere Programme befreit gewesen. Und so geschah es denn auch: mit dem GNU/Linux-System können wir nun diese Programme auf freien Plattformen laufen lassen.

Heute ist die Situation eine andere. Wir haben nun leistungsfähige freie Betriebssysteme und viele freie Programmier-Werkzeuge. Welche Arbeit Sie auch immer erledigen wollen, Sie können es auf einer freien Plattform tun; es gibt keinen Grund mehr, eine unfreie Abhängigkeit auch nur zeitweilig zu akzeptieren. Der Hauptgrund, warum heutzutage Leute in die Falle tappen, ist, weil sie nicht darüber nachdenken. Die einfachste Lösung für das Problem der Java-Falle ist es, den Leuten beizubringen, wie sie da nicht hinein fallen.

Um Ihren Java-Code vor der Java-Falle abzusichern, installieren Sie eine freie Java-Entwicklungsumgebung und benutzen Sie diese. Allgemeiner formuliert, was Sie auch immer für eine Sprache benutzen, halten Sie die Auge offen, und prüfen Sie den freien Status der Programme, von denen Ihr Code abhängt. Die einfachste Art, um zu überprüfen, ob das Programm frei ist, ist die, danach im Freie-Software-Verzeichnis zu suchen ( http://www.fsf.org/directory). Wenn ein Programm nicht in dem Verzeichnis ist, können Sie seine Lizenz(en) mit der Liste der Freien Software-Lizenzen vergleichen ( http://www.gnu.org/licenses/license-list.html).

Wir versuchen, die Java-Programme aus der Falle zu befreien. Also, wenn Sie die Sprache Java mögen, laden wir Sie ein, bei der Entwicklung von GNU Classpath zu helfen. Wenn Sie Ihre Programme mit dem GCJ Compiler und GNU Classpath ausprobieren, und über alle Probleme berichten, auf die Sie mit den Klassen, die bereits implementiert wurden, stoßen, ist das ebenfalls hilfreich. Wie auch immer, GNU Classpath zu vollenden, wird Zeit beanspruchen; wenn weiterhin mehr unfreie Bibliotheken hinzugefügt werden, werden wir möglicherweise niemals alle von den Neusten haben. Also bitte, legen Sie Ihrer Freien Software keine Fesseln an. Wenn Sie heute eine Applikation schreiben, schreiben Sie sie von Anfang an so, dass sie in freien Umgebungen läuft.

• The Curious Incident of Sun in the Night-Time
  
• Weitere Texte zum Lesen