Java-Experten setzen hohe Erwartungen in Oracle

Stefan Ueberhorst ist Redaktor bei unseren deutschen Schwesterpublikation "Computerwoche".

"Java zählt neben Solaris zu den zwei Schlüsselbereichen, die uns zur Übernahme von Sun bewogen haben", erklärte Oracle-CEO Lawrence Ellison am 20. April, als der Kauf öffentlich wurde. Auf Java basiere das umfangreiche Portfolio der Oracle Fusion Middleware, des zurzeit am schnellsten wachsenden Geschäftssegments seines Unternehmens. Damit übernimmt Oracle nicht nur die Rechte an Java als Marke, sondern auch die Verantwortung für die weitere Gestaltung einer Plattform, die sich mit vielen Millionen Entwicklern schon lange als Gegenpol zur Microsoft-Welt positioniert, im Gegensatz zu dieser aber seit einiger Zeit Open Source gestellt ist.

Es mag ein gutes Zeichen sein, dass die Java- und Open-Source-Community bislang vergleichsweise unaufgeregt auf den bevorstehenden Wechsel reagiert hat. Suns Softwareportfolio werde unter der Aufsicht von Oracle wahrscheinlich schneller und besser weiterentwickelt, als dies bei Sun mit den dort gegebenen Ressourcen möglich war, meint etwa Richard Seibt, ehemaliger Geschäftsführer von IBM Deutschland und jetziger Vorstandsvorsitzender der Open Source Business Foundation. Seine Organisation sei zwar überrascht gewesen, dass die ursprünglich geplante Übernahme durch IBM scheiterte, ebenso darüber, wie schnell Oracle reagiert habe. Doch Seibt ist sicher, dass ein Hersteller mit derartiger Softwarekompetenz sorgfältig mit Java und MySQL umgehen werde und die Software bei Oracle gut aufgehoben sei.

Ähnlich zuversichtlich äussert sich Ralph Müller, Direktor der europäischen Eclipse Foundation, in der Oracle strategisches Mitglied ist, während Sun seine Teilnahme an der Organisation bislang verweigerte. Grosse Hoffnung setzt Müller insbesondere auf das OSGi-Komponentenmodell, das ursprünglich aus dem Embedded-Bereich von Settop-Boxen stammt und sich dort als Standard gegen Sun durchgesetzt hat. Es beschreibt im Prinzip ein Komponenten-Management-System oberhalb der Virtual Machine, das die Komponenten, so genannte Bundles/Packages aus Anwendungen und Diensten, dynamisch verteilt, startet, löscht und remote betreibt.

Inzwischen wurde der OSGi-Einsatz auf Desktop- und Enterprise-Plattformen ausgedehnt. Zu den namhaften Referenzimplementierungen zählen "Felix" von der Apache Software Foundation, insbesondere aber "Equinox" von Eclipse. Die Organisation hatte sich im Jahr 2003 für OSGi entschieden, nachdem beschlossen worden war, Eclipse 3.0 auf eine Plug-in-basierende Struktur umzustellen. Jetzt verweist Müller nicht ohne Stolz darauf, dass man Equinox nicht nur in IBM Websphere und Oracles (Bea) Weblogic, sondern künftig auch in SAP Netweaver und damit in allen namhaften Java-Applikations-Servern findet. Da die Java-Spezifikationen selbst kein vergleichbar einheitliches Komponentenmodell für alle drei Bereiche Client, Server und Embedded vorhalten, ist seine Hoffung gross, dass Oracle, selbst Mitglied des Industriekonsortiums OSGi Alliance, den Standard in den Java Community Process einbringen könnte. Idealerweise würde ein OSGi-konformer Bundle-Mechanismus auch auf Skriptsprachen wie Javascript und damit bis hin zu Browser-Anwendungen ausgedehnt.

Suns Weigerung, das OSGi-Modell für die Modularisierung von Java selbst zu verwenden, steht stellvertretend für ein Problem, das der Hersteller offenbar mit arbeitsteiliger Entwicklung hat. Sun habe oft das Bedürfnis, Entwicklungen, die in der Open-Source-Welt bereits vorhanden sind, für die Java-Welt noch einmal neu zu erfinden, moniert Stefan Tilkov, Geschäftsführer von innoQ, einem auf Softwarearchitekturen und Entwicklung spezialisierten Beratungshaus. Prominentes Beispiel sei das Java Development Kit (JDK), Suns Implementierung der Java-Spezifikationen und die wohl am weitesten verbreitete Java-Entwicklungsumgebung. Sie war bis vor wenigen Jahren zwar kostenlos, aber Closed Source.

Ende 2006 gab Sun bekannt, eine Open-Source-Version des JDK (OpenJDK) unter der GNU General Public License veröffentlichen zu wollen, was dann im ersten Halbjahr 2007 auch geschah. Der Vorgang an sich wurde von der Java-Community begrüßt. Für Diskussionsstoff sorgte allerdings, dass unter dem Dach von Apache mit "Apache Harmony" bereits ein Open-Source-JDK entstanden war, das von Java-Kennern als sehr gut gelungen eingestuft, von Sun dagegen anfangs nur belächelt wurde. Daraufhin begannen die Machtspielchen in der Form, dass Sun die für ein Java-Produkt notwendige Zertifizierung verweigerte und Apache im Gegenzug nahezu alle Abstimmungen im Java Community Process (JCP) boykottierte.

Der JCP ist von Politik geprägt, resümiert Tilkov, Sun hat hier sehr stark Eigeninteressen eingebracht, um die Kontrolle über die Plattform zu behalten. Der Berater sieht keinen Grund, weshalb Oracle genauso weitermachen sollte, und verspricht sich von der Übernahme Verbesserungen im JCP. Seine persönlichen Erfahrungen mit dem JCP bezeichnet Tilkov indes als sehr gut. InnoQ war in einen Java Specification Request (JSR) zu REST involviert und blickt hier auf eine erfreuliche Zusammenarbeit mit Sun-Experten zurück. Er habe die Hoffnung, dass diese Mitarbeiter, die stets an guten und offenen Lösungen interessiert gewesen seien und gerne mit der Community kooperiert hätten, unter der Führung von Oracle noch befreiter agieren könnten.

Schliesslich lohnt sich ein Blick auf das Lizenzmodell. Im Bereich der Java-Plattform gilt überwiegend die GNU General Public License (GPL) und damit deren Copyleft-Regelung. Diese besagt, dass im Fall einer Weitergabe an Dritte alle Modifikationen an einem unter der GPL stehenden Code offengelegt und ihrerseits unter die GPL gestellt werden müssen. Im Einzelfall kann es sein, dass der genaue Umfang des Copyleft nur sehr schwer zu bestimmen ist, so dass es immer wieder zu Unsicherheiten kommt, beobachtet Rechtsanwalt Martin Braun von der Frankfurter Kanzlei WilmerHale. Software, die unter Verwendung des Java Development Kit geschrieben wurde, steht nicht automatisch unter der GPL. Verwendet man zum Beispiel die GPL-geschützte Java-Runtime, heisst das normalerweise nicht, dass auch der eigene, in der Runtime laufende Code "GPL-infiziert" ist. Dies beträfe nur Veränderungen, die man an der unter der GPL stehenden Laufzeitumgebung selbst vornimmt. Eine gebräuchliche Faustformel ist laut Braun: Je mehr eigene Software (nur) über Standardschnittstellen kommuniziert und je weiter man von Links auf GPL-basierende Bibliotheken entfernt ist, desto unkritischer ist das Lizenzthema.

Sun hat lange gebraucht, um bei Java von der ursprünglich restriktiveren hauseigenen Lizenz schrittweise auf die GPL zu wechseln. Der "Hüter der Plattform" wollte sicherstellen, dass er auch unter der GPL die volle Kontrolle beibehalten würde. Ob Oracle an dieser Lizenzform etwas ändern kann oder will, steht noch in den Sternen. Tatsache ist jedoch, dass hinsichtlich kommerzieller Aspekte mit der Eclipse Public License (EPL) und der Apache License attraktive und ebenfalls weit verbreitete Lizenzformen als Alternativen zur Verfügung stünden.

So folgt auch die EPL dem Copyleft-Prinzip, ist laut Braun aber im Vergleich zur GPL trennschärfer. Die Bearbeitung und Übernahme von EPL-geschütztem Code bleibt Copyleft. Alles andere, was in eigenen Dateien enthalten ist, fällt nicht darunter. So lassen sich zusammengestellte Produkte zum Beispiel mit Eclipse-Plug-ins erstellen und unter einer eigenen Lizenz vertreiben, wobei nur der von Eclipse übernommene Code den Copyleft-Regelungen unterliegt.

Hinzu kommen Unterschiede bei der Übertragung von Rechten des geistigen Eigentums: Bei Eclipse verbleiben alle Rechte an einem Beitrag beim Urheber, der jeweils direkt an den Nutzer lizenziert. Anders im Java-Umfeld, wo Rechte an der Intellectual Property eines Beitrags zur Java-Plattform über ein "Contributor Agreement" eingeräumt werden müssen.

Die in vielerlei Hinsicht für Anwender sorgenfreieste Variante ist laut Braun die Apache License, die keine Copyleft-Regelung enthält: Apache stellt Open-Source-Code zur Verfügung und erlaubt es, sämtliche Modifikationen daran auch unter einer eigenen Lizenz weiterzugeben. Auch hier müssen allerdings einige Bedingungen eingehalten werden, unter anderem, dass der Ersteller der Software und die Apache Foundation nicht haften und die bestehenden Urheberrechtsvermerke auch im modifizierten Programm enthalten sein müssen

Unterm Strich sind sich die Experten weitgehend einig, dass ein weniger politisch geprägter Java Community Process, ein anderer Umgang mit dem geistigen Eigentum an Plattformbeiträgen und eventuell auch eine andere Lizenzform deutlich zur Attraktivität von Java beitragen und die Weiterentwicklung der Spezifikationen beschleunigen könnten - ohne dass Oracle gleich Wildwuchs und Kontrollverlust befürchten müsste.