Zeit für Geschenke: Zwei TCKs für Eclipse
Oracle vergab im Mai zwei TCK-Lizenzen an die Eclipse Foundation. Was auf den ersten Blick wie ein Geschenk aussieht, ist eigentlich gar keins. Und überhaupt sind die zwei Lizenzen nur ein Tropfen auf den berühmten heißen Stein. Aber der Reihe nach...
- Markus Eisele
Oracle vergab bereits im Mai zwei TCK-Lizenzen an die Eclipse Foundation. Erst in den letzten Tagen sind die Meldungen auch wirklich verbreitet worden. Was auf den ersten Blick wie ein Geschenk aussieht, ist eigentlich gar keins. Und überhaupt sind die zwei Lizenzen nur ein Tropfen auf den berühmten heißen Stein. Aber der Reihe nach...
Technology Compatibility Kit
Im Rahmen des Java Community Process (JCP) werden sowohl Java als Sprache, als auch die verschiedenen Plattformen (Java SE, Java EE, Java ME) weiterentwickelt. Zu jedem JSR (Java Specification Request) gehören neben einer EG (Expert Group) ein Haufen Dokumente und natürlich auch eine Referenzimplementierung (RI) sowie ein entsprechendes TCK (Technology Compatibility Kit).
Das TCK kann gegen Implementierungen ausgeführt werden und prüft sie auf Einhaltung der Spezifikation. Es ist also die in Code gegossene Variante des Spezifikationsdokuments. Typischerweise besteht das Kompatibilitätskit aus Testfällen und einem "Test Harness", mit dem sie ausgeführt werden können. Dass es für jeden JSR ein TCK geben muss, schreibt der JCP vor.
Somit gibt es mindestens genauso viele TCKs wie JSRs im Netz – zumindest theoretisch ist das so. Praktisch gibt es nicht viele offene und verfügbare TCKs. Neben JBatch, CDI und Bean Validation fallen mir aktuell nicht mehr ein. Allein für Java EE sind es aber mindestens 28 Spezifikationen. Die Mehrzahl der TCKs steht leider unter Verschluss bei Oracle. Aber warum? Der Grund dafür ist, dass die TCKs auch als Hilfsmittel für Zertifizierungen verwendet werden. Kann ein TCK gegen eine Implementierung eines JSRs korrekt und ohne Fehler ausgeführt werden, ist diese sozusagen konform.
Was bedeutet plattformkompatibel?
Mit der Plattformkompatibilität wirbt es sich hervorragend. Die Java-EE-Kompatibilitätsliste ist ein Who-Is-Who im Server-Markt. Wer dort nicht drauf steht, hat eigentlich keine Chance wahrgenommen zu werden. Nur Apache Tomcat ist hier eine bekannte Ausnahme. Aber wie sieht jetzt der Weg zur Zertifizierung wirklich aus? Für Java EE gibt es die Java EE Compatibility Test Suite (CTS), die vermutlich nicht viel mehr als die Summe aller einzelner TCKs sein wird – gesehen hab ich sie nicht. Um darauf Zugriff zu bekommen, muss man Lizenznehmer von Oracle werden.
Und genau an dieser Stelle wird es teuer. Wie teuer genau, weiß ich nicht. Hat man bezahlt, kann man über die Java Partner Engineering Website das CTS bekommen. Einzige andere Alternative ist das sogenannte Compatibility Testing Scholarship Program, über das Non-Profit-Einzelpersonen oder -Organisationen ein CTS beantragen können. Ein Review-Board entscheidet dann über die Vergabe einer Lizenz. Ein PDF erklärt wie genau das funktioniert. Neben der Apache Software Foundation haben diverse andere Organisationen und Einzelpersonen Zugriff auf einzelne TCKs und CTS bekommen.
TCK für EclipseLink
Laut Pressemeldung von Anfang Mai demonstriert Oracle sein "Engagement für Java-Entwickler und die Open-Source-Gemeinschaft" durch die Vergabe von zwei TCKs sowie damit verbundene Support Leistungen an die Eclipse Foundation. Das Augenrollen beginnt bei EclipseLink. War das nicht die RI für JPA? Die machen quasi ihr TCK selber, oder? Warum brauchen die eine Lizenz?
Es ist nicht so einfach: Hinter EclipseLink steckt eigentlich TopLink. Wer die Geschichte von TopLink kennt, weiß, dass dies ein vergleichsweise altes Produkt ist, das vor der Übernahme durch Oracle WebGain gehört hat. WebGain war ein starker Eclipse Supporter und 2002 auch im Board of Directors vertreten. Nur fünf Jahre nach der Übernahme durch Oracle wurde TopLink an die Eclipse Foundation gespendet und hat seitdem dort sein Zuhause. EclipseLink steht unter der EPL 1.0. Das Projekt selber enthält kein TCK. Eine schwierige Situation für eine RI. Schaut man auf die Liste der Committer, wird es spannend. 30 Personen und nur einer ist nicht von Oracle. Warum glaube ich, dass dieses Team auch das TCK hat und sogar mit entwickelt? Streng genommen haben sie damit also gegen eine Lizenzregel von Oracle verstoßen. Mit der Scholarship-Lizenz ist hier meiner Meinung nach lediglich rechtlich etwas gerade gebogen worden.
TCK für Virgo
Aber bei Virgo ist doch alles besser, oder? Da steckt doch wirklich guter Wille dahinter, oder? Vielleicht. Virgo ist der frühere Spring dm server, der von SpringSource an Eclipse gespendet wurde. Schaut man wieder auf die Liste der Committer ist das Bild leicht anders als bei TopLink. Hier steht leider nicht einfach nur SAP hinter jedem Namen. Es ist ein vergleichsweise paritätisch besetztes Team von SAP, Pivotal und Tasktop Technologies. Bei letzteren ist der frühere COO von SpringSource Neelan Choksi nun COO und Rod Johnson als Berater an Board. Oracle wird VMWare wohl kaum etwas schenken. Also muss hier doch SAP die treibende Kraft sein. Tatsächlich ist Virgo auch schon Java EE 6 zertifiziert. Allerdings unter anderem Namen. Die SAP NetWeaver Cloud hat ihr Angebot für das Java EE 6 Web Profil auf Virgo aufgebaut. Also hat SAP wohl eine Lizenz von Oracle erworben und Virgo damit quasi schon einmal zertifiziert. Vermutlich hat hier ein Kostenfuchs beschlossen, dass es günstiger sein wird, die jährlich anfallenden Lizenzgebühren nicht zu Zahlen und direkt das Virgo-Projekt beim Scholarshop-Programm angemeldet. Das hat in diesem Fall sogar positive Auswirkungen. Nicht nur die kommerzielle Cloud-Lösung hat damit die Web-Profil-Zertifizierung, sondern es wird vermutlich recht kurzfristig auch eine neue EE 7 zertifizierte Virgo-Variante für jedermann geben. Hier hat sich das Kostenbewusstsein eines Großkonzerns tatsächlich für die Open-Source-Gemeinde ausgezahlt.
Aber ist jetzt wirklich alles besser?
Es sind zwei weitere TCKs an zwei Projekte bereitgestellt worden. Blickt man zurück auf die Gesamtzahl der verfügbaren TCKs, ist das ernüchternd. Zumal es sich auch in diesem Fall um an Regeln gebundene Überlassungen handelt. Die vergebenen TCKs dürfen nicht öffentlich verfügbar gemacht werden und stehen somit auch eigentlich nur den Teams zur Verfügung. Eine längliche Diskussion auf der JPA-Mailing-List aus dem letzten Jahr hat die Problematik dieses Ansatzes gut verdeutlicht. Auch wenn der JCP mit den Änderungen durch den JSR-348 die bisher geltenden, sehr strengen Regeln etwas aufweicht, so ist noch länger nicht damit zu rechnen, dass die TCKs allen Interessierten zur Verfügung stehen. In der Summe schadet dies der Qualität der Spezifikationen. Definitiones-Lücken werden zu spät gefunden und nicht ausreichend getestete Bereiche von RIs führen zu unschönen Fehlern. Im Rahmen des JSR 358 wird an der nächsten Version des JCP-Regelwerkes gearbeitet. Ein flankierendes Java.net Projekt macht die Diskussionsunterlagen öffentlich zugänglich. Und auch hier kann jeder mitdiskutieren und seine Meinung kundtun. Die Observer Mailinglist steht jedem java.net-Nutzer zur Verfügung. Wer wissen möchte, wie beispielsweise CloudBees, RedHat und IBM zum Thema Nutzungsrechte stehen, der wird auf der Präsentationsseite fündig. Oracle selber will mit Standard-TCK-Lizenzmodellen zukünftig wie folgt vorgehen:
"TCKs for all future JSRs must be made available for certification and branding purposes under one or more of the Approved Open-Source Licenses and/or a Standard Commercial TCK License. The TCKs for all future non-Umbrella JSRs must be made available to all participants in the relevant RI open-source project under a standard JCP Community TCK License."
(Quelle: Oracle's Proposal for JSR 358, PDF, Seiten 15+16)
Das wäre ein Schritt in die richtige Richtung und würde der Open-Source-Gemeinschaft tatsächlich weiterhelfen. Geschenke hin oder her: Es muss sich grundsätzlich etwas ändern, wenn es besser werden soll. ()
