Die Kolumne berichtet aus der Perspektive des GNU-Projekts und der FSF über Projekte und aktuelle Geschehnisse aus dem Umfeld freier Software. Dieser Ausgabe beleuchtet die Konsequenzen beim Einsatz kommerzieller JREs, zeigt Alternativen auf und berichtet zudem über Neues aus der FSFE.

Abbildung 1: Java erfreut sich auch in der Welt freier Software großer Beliebtheit. Jedoch schränkt der Einsatz von kommerziellen Runtime-Environments die Verteilbarkeit der Programme ein.

Willkommen zu einer neuen Ausgabe der Brave GNU World. Diese Ausgabe beschäftigt sich im Schwerpunkt mit dem Aspekt der Freiheit in der Java-Programmierung und Alternativen zu proprietären Runtime-Environments.

Freiheit in Ketten?

Als ich in einer der letzten Ausgaben die Mindmapping-Software Freemind vorstellte, erhielt ich zum Teil recht wütende E-Mails. Der Grund für den Proteststurm lag in meiner Behauptung, dass das Tool – wie viele andere – unreflektiert auf einer unfreien Java-Implementation aufsetzt und somit die Freiheit der Software gefährdet. Tenor zahlreicher Zuschriften war, dass Java zwar nicht frei sei, aber auch nicht unfrei. Sicherlich gibt es unterschiedliche Abstufungen der Freiheit, jedoch sind die Java-Implementationen von Sun und IBM nach der Definition freier Software beide unfrei. Daran ändert auch die Tatsache nichts, dass es zu diesen Implementationen Umgebungen und zusätzliche Bibliotheken gibt, die wiederum unter einer freien Lizenz stehen. Wer ein bisschen mit den Fingern wackeln kann, sprengt damit nicht die Ketten, in die er geschlagen ist.

Die Zusammenhänge erklärt Richard Stallman in seinem Artikel “Free But Shackled – The Java Trap”[5]. Diese Java-Falle schnappt immer genau dann zu, wenn ein Entwickler glaubt, die proprietären Implementationen seien frei genug oder kein Problem.

In der Java-Falle

Einige Distributionen denken sogar darüber nach, die freien Java-Implementationen von ihren CDs zu entfernen, da zahlreiche Programme nur mit den unfreien funktionieren. Zudem gibt es rechtliche Probleme, wie das Debian-Projekt richtig feststellt[6]: Die Runtime-Lizenz von Sun erlaubt keine gemeinsame Verbreitung mit Alternativen – das Unternehmen geht also aktiv gegen eine Verbreitung von freiem Java-Umgebungen vor.

Damit behindert freie Software, die von Suns JRE abhängig ist, effektiv die Entwicklung von Alternativen und zwingt die Distributoren in die Entscheidung zwischen der Aufnahme des Programms ohne die für seine Benutzung notwendige Umgebung oder den aktiven Boykott freier Alternativen. Die erste Lösung ist offensichtlich nutzlos, die zweite ist aus der Perspektive freier Software nicht akzeptabel.

Auswege

Entwickeln Programmierer dagegen konsequent ausschließlich auf den freien Java-Implementationen, bietet das einen Ausweg aus der Java-Falle. So vermeiden sie es, aus Versehen Funktionen einzusetzen, die nur in den proprietären Implementationen vorhanden sind. Ein solches Verhalten erfordert jedoch Einsicht in die Existenz der Falle und den Willen, sie zu umgehen. Als Resultat der proprietären Java-Lizenzpolitik, hauptsächlich durch Sun, müssen Java-Entwickler viel vorsichtiger beim Einsatz der Programmiersprache sein. Eine dauerhafte Lösung des Problems gelingt nur dann, wenn Sun die freien Java-Implementationen zum Standard erhebt oder seine Lizenzpolitik diesbezüglich ändert. Das lehnte Sun jedoch erst kürzlich wieder ab.

Aus diesem Grund bekommen die freien Java-Implementationen ein besonderes Gewicht und Entwickler verwenden viel Energie darauf, sie voranzubringen. Folglich hat sich in den letzten Jahren in diesem Bereich viel getan. Neben Projekten wie GCJ zur Kompilierung von Java-Code und Projekten für virtuelle Maschinen wie Kaffe ist der Funktionsumfang der zur Verfügung stehenden Bibliotheken besonders wichtig.

GNU Classpath

Mit GNU Classpath[7] entstand 1998 ein Projekt für die Entwicklung freier Java-Kernbibliotheken, die Brave GNU World berichtete im Juli 1999 zum ersten Mal über das Projekt[8]. Seit seiner Gründung erlebte das Projekt, das Geoff Berry, Jim Blair, Brian Jones, Paul Fisher, Aaron Renn und John Keiser gegründet haben, eine rasante Entwicklung. Sie konzentrierte sich zu Beginn auf die alternative virtuelle Maschine Japhar. Jedoch war allen Beteiligten von Anfang an klar, dass GNU Classpath später auch für andere Laufzeitumgebungen verfügbar sein sollte.

Im Jahr 2000 erfolgte der Zusammenschluss von GNU Classpath mit dem Libgcj-Projekt, das sich mit der Klassenbibliothek um den Java-Compiler der GNU Compiler Collection beschäftigt. Damit verdoppelte sich auch die Anzahl der aktiven Entwickler. In den Jahren 2001 und 2002 unterstützten immer mehr Laufzeitumgebungen Classpath – zu dieser Zeit noch überwiegend in der Forschung, aber auch in Produktionsumgebungen.

Zwei wesentliche Veränderungen gab es 2003: Einerseits integrierten die Entwickler der freien Java Virtual Machine (JVM) Kaffe[9] die Classpath-Unterstützung in ihr Projekt, zum anderen übernahm Mark Wielaard im Juni das Projekt als neuer Maintainer. Er analysierte Mitte August 2004 die Entwicklungsgeschwindigkeit des freien Projekts und veröffentlicht einige Ergebnisse dazu: So wuchs der Quellcode im letzten Jahr mit einem Tagesmittelwert von mehr als 190 Zeilen Code – Kommentare und Duplikate nicht mitgezählt. Im Schnitt arbeiten zwischen 20 und 50 Leute fortlaufend an dem Projekt, zwischen fünf und zehn von ihnen zumindest wöchentlich oder sogar täglich.

Der Schwerpunkt der Entwicklung liegt heute auf der GNU Compiler Collection (GCC), insbesondere dem GCJ sowie dem GIJ, einem Interpreter für Bytecode-Class- und -Jar-Dateien. Außerdem entwickeln die Developer an weiteren Werkzeugen zur Integration von Java-Code in andere Sprachen wie C und C++. Mittlerweile unterstützen mehr als 20 Umgebungen und Systeme GNU Classpath – von der bereits erwähnten Kaffe-JVM bis hin zu IKVM.Net, einem Java- und NET-Interoperabilitäts-Toolkit des Mono-Projekts.

Programmierern steht mit Eclipse heute ein gut konzeptionierter, objektorientierter Rahmen zur Verfügung, der die meisten Anforderungen typischer Anwendungen abdeckt. Die Unterstützung reicht bereits von abstrakten Datentypen bis zu grafischen Oberflächen, von niederstufigen Netzwerkabstraktionen zum Aufrufen oder Laden von Funktionen über das Netzwerk, von mathematischen Bibliotheken bis zum Zugriff auf Datenbanken.

Abbildung 2: Die Java-IDE unterstützt GNU Classpath, sodass Entwickler nicht auf die Vorzüge der Programmierung mit Hilfe einer grafischen Oberfläche verzichten müssen.

Umstieg auf freie Alternativen

Viele Entwickler setzen mittlerweile Classpath bei ihrer Arbeit ein. Tatsächlich bauen seit einiger Zeit auch nicht- triviale Anwendungen auf dem Projekt auf. Es überrascht daher nicht weiter, dass GNU Classpath selbst zum Großteil in Java geschrieben ist, obwohl die Integration mit dem Rest des GNU-Systems – beispielsweise mit der GNU-C-Bibliothek oder dem Toolkit GTK+ – teilweise in C implementiert wurde.

Die einzelnen Funktionen sind zum Teil sehr gut dokumentiert, trotzdem fehlt dem Projekt eine gute Übersichtsdokumentation. Das empfinden viele als ein wachsendes Problem. Die verbreitete Literatur über Java beschäftigt sich zumeist nur mit den proprietären Java-Umgebungen. Obwohl GNU Classpath vielfach zu dieser Dokumentation kompatibel ist, wären Beispielprogramme speziell für dieses Projekt und GCJ für Einsteiger sehr hilfreich. Hilfe ist hier sehr willkommen.

Lizenz

Natürlich steht GNU Classpath unter einer freie Lizenz, in diesem Falle unter einer an die General Public License (GPL) stark angelehnten Lizenz. Sie ist im Wesentlichen wortgleich, enthält allerdings eine Ausnahme, die dafür sorgt, dass sie nicht auf Java-Programme übergreift, die GNU Classpath benutzen. Es besteht also die Möglichkeit, auf der Basis von Classpath Software unter beliebigen Lizenzen zu schreiben.

Mark arbeitet gegenwärtig daran, jene Kernbibliotheken zu identifizieren, die stabil laufen und gut dokumentiert sind, sodass sie als Basis in die nächste GCC-Version 4.0 sowie in Kaffe und Mono eingehen können. Wer Interesse daran hat, die aktuelle Entwicklung um GNU Classpath zu verfolgen, erfährt alles Wichtige auf der Projektseite[10], die beinahe täglich von den Entwicklern auf den neusten Stand gebracht wird.

In Java entwickeln

Es gibt also immer mehr freie Software im Java-Bereich. Damit verschwindet auch die Notwendigkeit, Programme zu schreiben, die von proprietären Implementationen wie der Sun JRE abhängen. Vollständig freie Software in Java lässt sich seit einiger Zeit immer leichter implementieren, sodass – abgesehen von technischen Notwendigkeiten – kein Argument generell gegen den Einsatz von Java spricht.

In Zukunft geht es vielmehr darum, alte Projekte so schnell wie möglich aus der Abhängigkeit herauszuführen. Das fällt allerdings mit fortschreitender Entwicklung der betreffenden Projekte schwerer, da mitunter Funktionen zum Einsatz kommen, zu denen es kein freies Äquivalent gibt. Dann steht der Entwickler vor zwei Möglichkeiten: Er muss die Funktion anders implementieren – oder die Funktion beispielsweise in GNU Classpath integrieren.

Da Sun entschieden hat, dass die Freiheit der Java-Entwickler und -Anwender für das Unternehmen sekundär ist, liegt es an der Gemeinschaft von Entwicklern, Anwendern und Distributoren, eine Entscheidung zu treffen.

Neuigkeiten aus der FSFE

In dieser Ausgabe sollen nach langer Zeit mal wieder aktuelle Entwicklungen im Bereich der Free Software Foundation Europe[11] ins Blickfeld rücken. Zum einen verzeichnet die FSFE ein erfreuliches Wachstum. Das liegt daran, dass sie nicht allein in Europa aktiv ist, sondern als Teil eines globalen Netzwerks. Mit einigen Organisationen entwickelte sich ein so enger Kontakt, dass sie zu einer so genannten assoziierten Organisation werden. So erhielten drei Verbände offiziell diesen Status in Bezug auf die FSF Europe: Wilhelmtux in der Schweiz, Fundacion Via Libre in Argentinien und Vrijschrift.org in den Niederlanden. Aktuell arbeitet die FSFE mit elf weiteren Partner-Organisationen[12] in zehn Ländern zusammen.

Aufgrund der Tatsache, dass die FSFE in vieler Hinsicht als ungewöhnliche Organisation sehr spezielle Anforderungen und Aufgaben erfüllt, gibt es seit August 2004 eine Selbstverständniserklärung[13], die die Aufgabengebiete und selbst gesteckten Ziele der Free Software Foundation Europe umreißt.

Neben dieser inneren Stärkung und dem weiteren Wachstum der Organisation selbst beschäftigte sich die FSFE beispielsweise damit, der Europäischen Kommission die drohenden Gefahren einer Übernahme des DRM-Spezialisten Content-Guard durch Microsoft und Time-Warner zu erläutern und auf Seiten der Kommission gemeinsam mit dem Samba-Team die Freiheit des Samba-Projekts vor dem Europäischen Gerichtshof zu verteidigen.

Geistiges Eigentum

Gleichzeitig arbeitet die FSFE auf Ebene der Vereinten Nationen weiter, speziell mit Blick auf die World Intellectual Property Organization (WIPO). Im Umfeld dieser Organisation entstanden viele Verträge und Meinungen auf globaler Ebene, die sich heute negativ auf die Situation freier Software auswirken. Sie prägte außerdem die Debatte um Softwarepatente, auch der Digital Millennium Copyright Act (DMCA) der Vereinigten Staaten hat dort seine Wurzeln und ebenso die European Copyright Directive (EUCD) in der EU.

Die FSFE beantragte im letzten Jahr einen Platz als Beobachter zur WIPO. Diesem Antrag stimmten die Mitgliedsstaaten zu[14] und so darf die FSFE eine eigene Delegationen zu den Treffen entsenden. Der Zeitpunkt ist dabei sehr günstig, denn die Unruhe über die Rolle der WIPO gerade in Bezug auf die repressive Legislatur und deren Effekte auf alle Aspekte des Lebens wächst. So unterstützte auf Anregung der FSFE eine breite Koalition die viel beachtete Genfer Deklaration[15], die fordert, dass die Menschheit die WIPO zur “Weltorganisation für geistigen Reichtum” umgestalten sollte. (agr)