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 äußert 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. Große 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.
OSGi für Java
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 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 groß, 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.
Das Rad neu erfinden
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 Java Community Process 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.
Sparc/Solaris – wie lange noch?
Anhaltende Spekulationen über die Zukunft der Sun-Hardware veranlassten Oracle-Chef Lawrence Ellison kürzlich zu dem Versprechen: "Wir werden definitiv nicht aus dem Hardwaregeschäft aussteigen." Das überrascht zunächst einmal wenig, ist die Sparc-Solaris-Kombination doch eine häufig anzutreffende Systemplattform insbesondere in der Finanz- und Telekommunikationsbranche. Solchen Kunden gilt es Sicherheit zu vermitteln, zumal laut Ellison mehr Oracle-Datenbanken auf dieser Rechnerarchitektur laufen als auf irgendeiner anderen. Und nicht zuletzt: Hier rechnet sich die Sun-Akquisition aufgrund des Wartungsgeschäfts schon kurzfristig.
Auf längere Sicht dürften jedoch Zweifel an Ellisons Zusicherung angebracht sein. Noch zwei Wochen vor der Übernahmeankündigung am 20. April erklärte Oracles Corporate Chief Architect Edward Screven, sein Unternehmen würde es begrüßen, wenn Linux zum Standard-Betriebssystem in Rechenzentren avanciere. Damit befindet er sich in guter Gesellschaft, denn schon 2003 äußerte IBMs Softwarechef Steve Mills, er könne das Ende der AIX-Entwicklung sehen. Gemeint war die Reduktion der Betriebssysteme auf die der Großrechner und die der x86-Standardplattformen.
Betriebssysteme stellen im Prinzip keinen Wettbewerbswert mehr dar, sondern nur noch einen Kostenfaktor, bestätigt Richard Seibt von der Open Source Business Foundation. Der Markt für Betriebssysteme werde sich aufgrund der Oracle-Sun-Fusion noch mehr konsolidieren, da Kunden für ihre Plattformentscheidung eine langfristige Strategie wünschten, und die sei im Sparc-Solaris-Umfeld nicht mehr gegeben. Seibt geht von einem gesicherten Support über einen Zeitraum von zehn bis 15 Jahren aus, danach würde es ihn nicht wundern, wenn Oracle den Service einstellen würde. Wer also heute eine Plattformentscheidung zu treffen hat, wird eher in Richtung Linux tendieren, als mit Sparc-Solaris neu zu starten.
Wo Java greift
Oracle nennt "Fusion Middleware" seinen zurzeit am schnellsten wachsenden Geschäftsbereich. Dabei handelt es sich um eine Familie vorintegrierter Middleware-Produkte, die weitgehend auf Java basieren. Das Spektrum reicht von Portalen und Tools für das Prozess-Management über Anwendungsinfrastruktur und Entwicklerwerkzeuge bis hin zu Business Intelligence. Im Einzelnen listet Oracle unter Fusion Middleware:
Application Server,
Business Intelligence,
Business-Process-Management,
Collaboration Suite,
Content-Management,
Data Hubs,
Data Integration,
Developer Tools,
EDA Suite,
Identity-Management,
Portal,
Service Delivery Platform,
SOA Suite,
Webcenter.
Lizenzen und ihre Konsequenzen
Schließlich lohnt sich ein Blick auf das Lizenzmodell. Im Bereich der Java-Plattform gilt überwiegend die GNU General Public License (GPL) und damit deren CopyleftRegelung. 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, heißt 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.
Die EPL ist trennschärfer
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
Fazit
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.