Frei, aber gefesselt: Die Java-Falle

von Richard Stallman

---

Wenn Ihr Programm Freie Software ist, ist das grundsätzlich ethisch ‑ aber es gibt eine Falle, bei der Sie auf der Hut sein müssen. Ihr Programm, obwohl an sich frei, kann durch unfreie Software, von der es abhängt, eingeschränkt werden. Da das Problem bei heutigen Java-Programmen am auffälligsten ist, nennen wir es die Java-Falle.

Ein Programm ist Freie Software, wenn deren Nutzer bestimmte entscheidende Freiheiten haben. Diese sind grob gesagt: das Programm ausführen, den Quellcode untersuchen und ändern, den Quellcode und Binärdateien erneut distribuieren und verbesserte Versionen bereitstellen (siehe Freie Software. Was ist das?). Ob ein bestimmtes Programm in Quellcodeform freie Software ist, hängt ausschließlich von der Bedeutung seiner Lizenz ab.

Ob das Programm aber in der freien Welt genutzt werden kann, genutzt von Menschen die beabsichtigen in Freiheit zu leben, ist schon eine komplexere Frage. Dies hängt nicht allein von der Lizenz des Programms selbst ab, weil kein Programm isoliert funktioniert. Jedes Programm hängt von anderen Programmen ab. Ein Programm muss beispielsweise kompiliert oder interpretiert werden und hängt damit von einem Compiler oder Interpreter ab. Wenn in Bytecode kompiliert, hängt es von einem Bytecode-Interpreter ab. Außerdem benötigt es zur Ausführung Bibliotheken und kann auch andere separate Programme aufrufen, die in anderen Prozessen ausgeführt werden. All diese Programme sind Abhängigkeiten. Abhängigkeiten sind möglicherweise notwendig, damit das Programm überhaupt ausgeführt wird, oder sind möglicherweise nur für bestimmte Funktionen notwendig. So oder so, ohne die Abhängigkeiten kann das Programm ganz oder teilweise nicht ausgeführt werden.

Wenn einige der Abhängigkeiten eines Programms unfrei sind, bedeutet das, dass das ganze oder ein Teil des Programms nicht auf einem völlig freien System ausgeführt werden kann ‑ es ist in der freien Welt unbrauchbar. Sicher, wir könnten das Programm zwar weiterverbreiten und Kopien auf unseren Rechnern haben, aber das nützt nicht viel, wenn es nicht ausgeführt werden kann. Dieses Programm ist zwar Freie Software, aber praktisch durch eigene unfreie Abhängigkeiten gefesselt.

Dieses Problem kann in jeder Art von Software auftreten ‑ in jeder Programmiersprache. Beispielsweise ist ein freies Programm, das nur unter Microsoft Windows läuft, in der freien Welt eindeutig unbrauchbar. Aber Software, die unter GNU/Linux läuft, kann ebenfalls unbrauchbar sein, wenn sie von anderer unfreier Software abhängig ist. In der Vergangenheit waren Motif (bevor wir LessTif hatten) und Qt (bevor seine Entwickler es zu Freie Software machten) Hauptursachen dieses Problems. Die meisten 3D-Grafikkarten funktionieren nur vollständig mit unfreien Treibern, die dieses Problem ebenfalls verursachen. Aber die Hauptquelle dieses Problems ist heute Java, weil Menschen, die Freie Software schreiben, oft meinen, Java sei sexy. Verblendet von der Anziehungskraft der Sprache, übersehen sie das Problem der Abhängigkeiten und tappen in die Java-Falle.

Suns Java-Umsetzung ist unfrei. Die Standard-Java-Bibliotheken ebenfalls. Wir haben zwar freie Java-Umsetzungen, wie den GNU Compiler for Java (GCJ) und GNU Classpath, aber sie unterstützen noch nicht alle Funktionen. Wir haben noch einiges an Aufholarbeit zu leisten.

Wenn Sie ein Java-Programm auf Suns Java-Plattform entwickeln, laufen Sie Gefahr nur noch Funktionen von Sun zu nutzen, ohne es zu bemerken. Bis Sie das herausgefunden haben, können Sie diese schon monatelang benutzt haben, und das Ganze umzuschreiben könnte weitere Monate dauern. Sie könnten dann sagen, „Es ist zu viel Arbeit, um anzufangen.“ Dann wird Ihr Programm in die Java-Falle getappt sein ‑ unbrauchbar in der freien Welt.

Der zuverlässigste Weg die Java-Falle zu vermeiden ist nur eine freie Umsetzung von Java auf dem System zu haben. Dann, wenn Sie eine Java-Funktion oder -Bibliothek benutzen, die Freie Software noch nicht unterstützt, werden Sie das stehenden Fußes herausfinden und können diesen Quellcode sofort umschreiben.

Sun entwickelt weiterhin zusätzliche „Standard“-Java-Bibliotheken, und fast alle sind unfrei. In vielen Fällen ist sogar die Spezifikation einer Bibliothek ein Geschäftsgeheimnis, und Suns neueste Lizenz für diese Spezifikationen untersagt die Freigabe von nichts geringerem als einer vollständigen Umsetzung der Spezifikation (siehe Java Specification Participation Agreement und J2ME™ Personal Basis Profile Specification).

Glücklicherweise ermöglicht diese Lizenzspezifikation die Freigabe einer Umsetzung als Freie Software; anderen, die die Bibliothek erhalten, kann eingeräumt werden sie zu ändern und müssen sich nicht an die Spezifikation halten. Aber diese Bedingung bewirkt die Verwendung eines zusammenarbeitenden Entwicklungsmodells zu verbieten, um die freie Umsetzung zu erzeugen. Die Verwendung dieses Modells würde die Veröffentlichung von unvollständigen Versionen mit sich bringen, was jenen, die die Spezifikationen gelesen haben, nicht eingeräumt wird.

In den frühen Tagen 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 Betriebssystemkern, hing jedes Programm von einem unfreien Systemkern ab. Bevor wir Bash hatten, musste jedes Shell-Skript von einer unfreien Shell interpretiert werden. Es war unvermeidlich, dass unsere ersten Programme zunächst durch diese Abhängigkeiten behindert würden. Aber wir akzeptierten das, weil unser Plan beinhaltete diese nachträglich zu befreien. Unser oberstes Ziel ‑ ein im Wesentlichen alle zum Betrieb notwendigen Komponenten umfassendes (Self-Hosting) GNU-Betriebssystem ‑ beinhaltete freien Ersatz für all jene Abhängigkeiten; sofern wir das Ziel erreichten, würden all unsere Programme befreit. So geschah es: mit dem GNU/Linux-System können wir nun diese Programme auf freien Plattformen ausführen.

Heute ist die Situation eine andere. Wir haben nun leistungsfähige freie Betriebssysteme und viele freie Programmierwerkzeuge. Welche Aufgabe Sie auch immer erledigen wollen, Sie können es auf einer freien Plattform tun; es gibt keinen Grund, eine unfreie Abhängigkeit auch nur zeitweilig zu akzeptieren. Der Hauptgrund warum Menschen in die Falle tappen besteht heute darin, weil sie dabei nicht darüber nachdenken. Die einfachste Lösung des Problems ist den Menschen beizubringen dies zu erkennen und nicht hineinzufallen.

Um Ihren Java-Quellcode vor der Java-Falle zu schützen, installieren Sie eine freie Java-Entwicklungsumgebung und benutzen Sie sie. Welche Sprache auch immer Sie benutzen, halten Sie generell die Augen offen und prüfen Sie den freien Status der Programme, von denen Ihr Quellode abhängt. Am einfachsten, um zu überprüfen ob ein Programm frei ist, ist danach im Freie-Software-Verzeichnis zu gucken. Sollte ein Programm nicht aufgeführt sein, können die Lizenz(en) anhand Verschiedene Lizenzen und Kommentare <gnu.org/licenses/license-list.html> überprüft werden.

Wir versuchen die in die Falle getappten Java-Programme zu befreien. Wenn Sie also die Sprache Java mögen, laden wir Sie ein bei der Entwicklung von GNU Classpath zu helfen. Auch hilfreich ist Programme mit GCJ und GNU Classpath auszuprobieren und etwaige Probleme, die in bereits implementierten Klassen auftreten, zu berichten. Allerdings wird GNU Classpath’ letzter Schliff Zeit beanspruchen. Werden weiterhin mehr unfreie Bibliotheken geschrieben, werden wir möglicherweise niemals alle aktuellen haben. Legen Sie also Ihrer freien Software keine Fesseln an. Wenn Sie heute ein Anwendungsprogramm schreiben, schreiben Sie es, damit es von Anfang an in freien Umgebungen ausgeführt werden kann.

Siehe auch:

Richard Stallman, Supergute Tage oder Die sonderbare Welt von Sun 2006.