Apache bläst zum Angriff … gegen Oracles Windmühlen?

Hartmut Schlosser

Gestern hatte die Apache Software Foundation ihre Kritik an Oracles TCK-Lizensierung wiederholt: Die Test-Kits enthalten Restriktionen, die nicht mit den offenen Prozessen der Apache-Foundation zu vereinbaren sind. Apaches Angebot an Oracle, gemeinsam an einer Verbesserung der TCKs zu arbeiten, blieb bisher zwar unbeantwortet. Doch haben sich einige Oracle-Mitarbeiter privatem zu Wort gemeldet.

Auf Twitter reagierte Bruno Borges, Produktmanager bei Oracle, mit einem „+1“ auf das Statement der Apachen. Er fügt indes hinzu, er wünschte sich, dass seine Stimme ausreichen würde – wohl eine Andeutung darauf, dass bei Oracle die Fraktion groß ist, die eine gegenteilige Meinung vertritt.

In einem Kommentar auf JAXenter.com meldet sich zudem Reza Rahman, Oracles GlassFish Evangelist, zu Wort. Er macht darauf aufmerksam, dass man zwischen dem Entfernen von Restriktionen und dem kompletten Open-Source-Stellen der TCKs unterscheiden müsse. Einem unbeschränkten TCK steht auch Reza positiv gegenüber:

One issue is an unrestricted TCK (which I think is what Bruno was expressing personal support for and I must say I too personally never really understood why the issue can’t be resolved properly).

Die Bereitstellung quelloffener TCKs allerdings sei weitaus problematischer. Er selbst ist gegen Open Source TCKs.

Another is an open source TCK (which is a far more questionable proposition that I really can’t agree with).

Nun stellt sich die Frage, was die Apache Foundation nun eigentlich fordert. Denn die gestrige Mitteilung kam insofern überraschend, als sie ohne aktuellen Anlass verfasst worden zu sein scheint. Zudem enthält sie wenig Neues und sticht in Wunden, die längst verheilt schienen: der alte Zwist mit Sun Anfang der 2000er, die Vereinbarung von 2002, die weder Sun noch Oracle wirklich interessiert hatte, die Aufgabe von Apache Harmony und das Verlassen des JCP im Jahr 2010.

Reza Rahman bemerkt, dass es der Apache Foundation immer um den Wegfall der TCK-Restriktionen gegangen sei – nicht um komplett quelloffene TCKs. Ohne dass die Apache Foundation diese Annahme bestätigt hätte – in der Community gibt es durchaus Mitglieder, die quelloffene TCKs begrüßen würden. So kritisierte beispielsweise Oliver Gierke (VMware) Anfang 2013 die große Kontrolle über die TCKs durch Oracle und weist in einem JAXenter-Interview auf Fehler bzw. Lücken in TCKs hin, die nicht einmal von den JSR Experten-Gruppen behoben werden können:

Die Expert Group hat bis zum finalen Release des JSR keinen Zugriff auf das TCK. Diesen bekommen auch nach dem Release auch nur Lizenznehmer. Zu diesem Zeitpunkt ist der JSR jedoch bereits komplett verabschiedet, und Probleme im TCK sind schwer zu identifizieren.   

Oliver bemerkt zudem, dass es durchaus quelloffene TCKs gibt: So steht das TCK für CDI beispielsweise unter der Apache 2.0 Lizenz. Nach diesem Beispiel alle TCKs quelloffen bereit zu stellen, befürwortet Gierke:

Dass das geht, zeigt, wie schon erwähnt, die CDI-Spezifikation. Das TCK gibt es bei GitHub [3]. Für jeden fork- und verbesserbar. Warum sollte das nicht für andere JSRs auch funktionieren?

Worum es der Apache Foundation in der TCK-Problematik jetzt auch immer geht – klar ist, dass sie sich mit dem Statement wieder ins Spiel bringt – bzw. bringen möchte. Denn man könnte feststellen, dass seit dem Rückzug der Apache Foundation aus dem JCP die Zustimmung zu Oracles Java-Handling deutlich gestiegen ist. Alle großen Player sind mit an Bord des reformierten JCP Exekutiv-Komitees – von IBM über SAP, RedHat, Twitter bis zur Eclipse Foundation. Außen vor steht allein die Apache Foundation – und das ist eine Situation, die die Apachen vielleicht sogar mehr wurmt als die Frage nach den TCKs.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.