IBM drängt Sun zur Freigabe von Java

Wird Bob Sutor sein Ziel jemals erreichen? Wird Sun Java freigeben? Sicherlich bewegt sich Sun in diese Richtung. Nach Meinung von Gingell hat Sun erkannt, dass es eine Möglichkeit finden muss, um Java durch Open Source-Organisationen wie die Apache Software Foundation lizenzieren zu lassen. Gleichzeitig sagte Gingell auch, dass Sun beabsichtige, den Quellcode von Java freizugeben. Allerdings sei dies kein einfacher Prozess, da Sun nicht die Rechte am gesamten intellektuellen Eigentum aller JSRs besitzt. Aus den gleichen Gründen, warum das Unternehmen den Quellcode von Solaris nicht freigeben kann, ist Sun anscheinend auch rechtlich nicht in der Lage, Java in Open Source umzuwandeln. Das Unternehmen arbeitete derzeit daran, die juristischen Hürden aus dem Weg zu räumen.

Selbst wenn Java zu einer Open Source werden sollte, bleibt Suns Position zum Thema der Kompatibilität jedoch unverändert. Und genau an dieser Stelle spielt das Vetorecht eine Rolle. Das Unternehmen befürchtet, dass Javas Prinzip „einmal geschrieben, auf jedem System auszuführen“ in Mitleidenschaft gezogen werden könnte, wenn Sun die Entwicklungen nicht genau beobachtet. Diese Sorge könnte berechtigt sein. Trotz der aktuellen Lizenzierungsstruktur von Java startete Microsoft einen Vorstoß und veröffentlichte eine Java Virtual Machine (sowie die dazugehörigen Entwicklungstools), mit deren Hilfe die Entwickler von JVM-basierten Anwendungen Zugriff auf Dienste im Betriebssystem Windows erhielten. Aus technischer Sicht wurde es damit möglich, JVM-basierte Anwendungen zu erstellen, die ausschließlich auf Windows ausführbar sind.

Sun-Führungskräften zufolge ist dieser Mangel an Portabilität bis heute in der Java-Version des Yahoo! Instant Messenger (YIM) erkennbar. In der alten Microsoft JVM für Windows läuft der Yahoo!-Client reibungslos, während er in Suns JVM für Windows überhaupt nicht läuft. (Yahoo! wollte sich diesbezüglich nicht äußern.) Für Anwender von Windows XP ist es unmöglich, den YIM für Java zu starten. Windows XP enthält keine JVM mehr, die Microsoft JVM steht nicht mehr zum Download auf Microsofts Website bereit, und Suns JVM kann hier auch nicht weiterhelfen.

Sun verklagte Microsoft, und die beiden Unternehmen einigten sich später außergerichtlich.

Aber damit waren Suns Probleme noch nicht zu Ende. Im letzten Jahr stellte IBM eine bedeutende Menge von Code für eclipse.org zur Verfügung, eine Open Source-basierte Organisation, die die Schaffung der integrierten Entwicklungsumgebung (IDE) Eclipse überwacht. Nach Angaben von Sun verletzt auch diese IDE das Java-Prinzip „einmal geschrieben, auf jedem System auszuführen“. Sun sieht es lieber, wenn Java-Entwickler sich an NetBeans, die von Sun gebilligte IDE halten.

Auch aus anderen Gründen hat Sun die Realisierbarkeit von Eclipse öffentlich angezweifelt. Zum einen behauptet Sun, dass bestimmte Strings mit der Common Public License (CPL) von Eclipse verknüpft seien. Zum anderen stellt Sun in Frage, ob IBM Eclipse tatsächlich auf dem neuesten Stand halten wird. Richard Stallman von der Free Software Foundation zufolge, erfüllt die CPL von IBM jedoch tatsächlich die Anforderungen für eine kostenlose Softwarelizenz. Und IBM hat gerade ein Update für das Eclipse Toolkit veröffentlicht.

Eclipse.org verletzt keinerlei Lizenzbestimmungen von Java, da sie überhaupt keine Java-Lizenz besitzt. Sun kann daher nichts anderes tun als abzuwarten, ob die Java-Entwickler Eclipse gegenüber NetBeans bevorzugen oder nicht. Sollte dies der Fall sein, könnte das für Sun ein Zeichen darstellen, dass es zu sehr an Java festhält und dass, entgegen der Hoffnungen von Sun bezüglich der Zukunft von Java, die Entwickler flexiblere Tools bevorzugen. Andererseits könnte es sich bei einer Migration der Entwickler zu Eclipse aber auch um die Anziehungskraft einer Open Source-IDE handeln, hinter eine enorme Marketingmacht (IBM) steht.

Wie auch immer, sollte sich Eclipse als bevorzugte IDE herausstellen, ist klar, dass die Entwickler hinsichtlich der Bedrohung für die Portabilität von Java durch Eclipse nicht annähernd so besorgt sind, wie dies bei Sun der Fall ist. Vorausgesetzt dass IBM bereit ist, alles daranzusetzen, um Sun die Kontrolle über Java zu entreißen – indem Suns eigene Versprechungen gegen Sun eingesetzt werden und indem neue Open Source-Unternehmen gegründet werden, die Suns Kontrolle über Java unterlaufen – fragte ich Sutor, ob IBM angesichts der Größe seines eigenen Portfolios an geistigem Eigentum nicht etwas scheinheilig handelte. In diesem Punkt fand ich schließlich doch noch eine gewisse Gemeinsamkeit zwischen Sutor und Gingell: Beide stimmen darin überein, dass die mit dem geistigen Eigentum beschäftigten Anwälte ihrer Unternehmen ihr ganz eigenes Verständnis davon haben, wie das Geschäftsergebnis einer Firma zu schützen sei. Für Sutor und Gingell besteht die Herausforderung darin, andere in ihren Unternehmen für die Idee zu begeistern, dass aus offenen Standards und Open Source-Konzepten resultierendes Wachstum einen genauso großen, wenn nicht sogar größeren Einfluss auf das Ergebnis eines Unternehmens haben kann.