Software::Büro
OpenOffice.org und die Java-Falle
Free Software Foundation (FSF) und OpenOffice.org (OOo) suchen gemeinsam nach einer tragfähigen Lösung zur Beilegung eines Konflikts über die von Richard Stallman ausführlich beschriebene [a 0.8006]Java-Falle[/a], derzufolge sich das freie OOo ab Version 2.0 in zunehmenden Maße in proprietären Fallstricken verlieren wird.
Diese Einschätzung Richard M. Stallmans hatte einen Aufruf an die Community zur Folge, in der freie Entwickler zur Pflege und Weiterentwicklung eines OOo ohne proprietäre Java-Abhängigkeiten aufgerufen wurden. Die Konsequenz dieser Entwicklung liegt klar auf der Hand. OpenOffice.org würde sich zu einem Fork mit freien Java-Implementationen des GNU-Projekts entwickeln.
Der Hauptgrund für den Streit beider Lager liegt für den freien Autor Bruce Byfield vor allem in der Unterschiedlichkeit der Auslegung von "freier Software" in beiden Projekten. Während OOo aus Sicht der OOo-Community unter einer freien Lizenz vertrieben wird und damit per Definition frei ist, kritisiert die FSF, dass proprietäre Abhängigkeiten bei dieser Sichtweise zu Unrecht übersehen werden. Generell ist man bei der FSF nicht gegen Java als Programmiersprache, dennoch verweist man auf SUNs unklaren Kurs gegenüber Open Source und sich daraus ergebende zukünftige Probleme für freie Programme, die von SUNs Java abhängen.
Gegenwärtig scheinen sich sowohl auf Seiten des OpenOffice-Projekts als auch innerhalb der FSF die Stimmen zu mehren, die sich für eine konstruktive Lösung des Konfliktes einsetzen. Bei aller Unterschiedlichkeit in der Bewertung der Abhängigkeiten von SUNs Java wird die Möglichkeit eines Forks offensichtlich doch übereinstimmend als zweitbeste Lösung des Problems gesehen. Das diese Option ernsthaft zur Debatte stand, hat Byfield in einem Telefongespräch mit Stallman in Erfahrung bringen können: "Lasst uns den Code von OOo, der von SUNs Java-Plattform abhängig ist, umschreiben", waren die ersten Gedanken von Stallman zum Thema.
Nach einiger Diskussion zwischen Scott Carr vom OOo-Projekt und Stallman zeichnet sich offensichtlich eine Zusammenarbeit ab, die insbesondere darauf abzielt, OOo zu den entstehenden freien Java-Implementierungen des GNU-Projekts kompatibel zu machen. Gemeinsame Tests sollen die Kompatibilität von OOo und freien Java-Implementierungen zukünftig gewährleisten. Louis Suarez-Potts, derzeitiger Community-Manager bei OOo beschreibt die gegenwärtige Situation so: "Was wir gerade tun, ist... zu klären, wie OOo Java nutzt, warum und wie die FSF-Community helfen kann, OOo flexibler zu machen."
Bei allen sichtbaren Fortschritten, die beide Projekte bei der direkten Lösung des Problems verzeichnen können, bleibt vor allem auf Seiten von Stallman einige Skepsis zurück. Zwar sieht auch Stallman, dass einige Probleme durch die Diskussion direkt gelöst werden konnten. Dennoch stehen auch weiterhin noch zwei ungeklärte Probleme im Raum, die für den FSF-Gründer einer dringenden Lösung bedürfen. Zum einen ist die Idee, alle inkompatiblen Features zu freien Java-Implementationen als Bugs zu melden, für Stallman unzuverlässig. Hier fehlt es für ihn an einer vertrauenswürdigen, offiziell festgelegten Entwickler-Policy auf Seiten von OOo. Er befürchtet, dass das Melden von inkompatiblen Features als Bugs den OOo-Entwicklern das Interesse nehmen könnte, alles Mögliche zu versuchen, OOo optimal mit freien Java-Implementationen zum Laufen zu bringen. Zum anderen müsste die begleitende Dokumentation zu OOo einen Schwerpunkt auf die Verwendung freier Java-Implementierungen mit OOo legen: "Kommt die Dokumentation mit einem Hinweis darauf, wo und wie der Nutzer SUNs Java-Interpreter bekommt. Wir wollen keine Dokumentation, die Nutzern erzählt, freie Java-Implementationen nicht zu verwenden.
Zumindest im letzten Punkt scheint der Dissens vermeidbar, da sowohl Vorabversionen des Userguides von OOo2 als auch die begleitenden Installationsanweisungen Java mit keinem Wort erwähnen. Lediglich die Installation-FAQ auf den Websites des OOo-Projekts verweist noch direkt auf SUNs Java.
Ob der bisherige Kompromiss beide Seiten zufriedenstellen kann und ein Fork vorerst abgewendet ist, bleibt abzuwarten. In seiner bekannten Hartnäckigkeit besteht Stallman auf einer tragfähigen Lösung aller genannter Probleme, deren Lösung für ihn den Weg für eine wünschenswerte und dauerhafte Zusammenarbeit beider Projekte sicherstellen soll.
