Aufzucht und Pflege eines Eclipse-Projekts

The Making of an Eclipse Project: Intellectual Property

Achim Lörke

Was steckt eigentlich hinter einem Eclipse-Projekt? Welche Entscheidungen sind zu treffen, welche Bedingungen zu erfüllen, wie läuft das alles? Das Eclipse-Jubula-Team berichtet in loser Folge über seine Erfahrung beim Open Sourcing von Jubula [1]. Dabei geht es nicht nur um Technik, sondern auch um Strategien, Abläufe und schwierige Entscheidungen.

Die Eclipse Foundation wird von kommerziellen Interessen geprägt. Sowohl die Entscheidungsgremien, speziell das Board of Directors, als auch die Committer werden zu einem sehr hohen Anteil aus Firmen bestückt. Somit ist die Nutzbarkeit von Software unter der Eclipse Public License (EPL) in kommerziellen Produkten ein Teil des Selbstverständnisses der Foundation. Wie unterscheidet sich dann das Vorgehen bei der Eclipse Foundation [2] von z. B. der Apache Software Foundation? Beide Lizenzen erlauben die kommerzielle Nutzung und erzwingen nicht die Weitergabe von darauf basierender Software. Bei Eclipse wird allerdings sehr viel Wert auf die Überprüfung von Urheberrechten gelegt. Der gesamte Entwicklungsprozess enthält Maßnahmen zur Wahrung der Rechte aller Beteiligten. Hierzu gehören viele Schritte, gegebenenfalls. Genehmigungen und Rückfragen, die jeweils projektspezifisch zu klären sind. Im Folgenden liegt der Fokus auf dem IP-Test und unseren Erfahrungen damit.

Wie geht es los?

Ein Eclipse-Projekt startet normalerweise mit einer Codeübergabe. Je nach Historie kann es sich um eine Menge Code handeln. Die so genannte Initial Contribution [3] wird an einen Eclipse Bugzilla-Eintrag gehängt und ist somit öffentlich sichtbar. Für Jubula war das ein 18 Megabyte großes zip-Archiv mit Quellcode und Dokumentation, sichtbar als Bug 332855 [4]. Damit ist allerdings die öffentliche Sichtbarkeit auch schon am Ende. Alle weiteren Schritte erfolgen in IPZilla, einem speziell für IP-Verwaltung aufgesetzten Bugzilla bei der Eclipse Foundation. Der Zugriff auf IPZilla ist zur Zeit nur Committern, Projektleitern und den Mitgliedern des IP-Teams der Foundation erlaubt. Daher gibt es für die folgenden Schritte leider keine Links auf Beispiele, sondern nur auf die entsprechenden Vorgaben. Der nächste Schritt erscheint redundant: Es wird in IPZilla ein Eintrag mit einem Verweis auf den Bugzilla-Eintrag angelegt und die Initial Contribution auch hier hinterlegt. Danach erfolgt sehr schnell (unter einer Stunde) eine erste automatische Prüfung: Lässt sich alles entpacken, sind keine geschachtelten jar- oder zip-Dateien vorhanden, sind bestimmte Texte vorhanden (Copyright, Lizenz) bzw. nicht vorhanden (Schimpfworte, „prohibited“, …)? Sollten hier Probleme auftreten, müssen sie vor den nächsten Schritten behoben werden. Für Jubula war das allerdings nicht der Fall.

Überholspur oder Kolonne?

Nun muss man das IP-Team bitten, die Contribution tatsächlich zu untersuchen. Dabei stehen zwei Vorgehensmodelle zur Verfügung:

  1. Die gesamte Contribution wird auf IP-Korrektheit überprüft, bevor sie auf den Eclipse-Servern öffentlich verfügbar gemacht wird. Bevor diese Prüfung nicht abgeschlossen ist, kann also die SCM- und Build-Infrastruktur auf eclipse.org nicht benutzt werden.
  2. Es wird die so genannte Parallel IP [5] benutzt. Dabei wird eine Eingangskontrolle durchgeführt, die offensichtliche Probleme identifiziert. Sobald diese behoben sind, können die Dateien in eines der Sourcecode-Management-Systeme eingespielt werden. Wählt ein Projekt diesen Weg, ist es damit automatisch im Incubation-Status [6] und muss das entsprechende Logo benutzen (Abb. 1). Der Incubation-Status muss bei Downloads von Eclipse-Servern immer genannt werden. Parallel dazu wird der genaue IP-Test durchgeführt. Dessen Bestehen ist eine notwendige Bedingung, um den Incubation-Status zu verlassen.

Abb. 1: Eclipse-Incubation-Logo

Jubula hat die Parallel IP gewählt, um die Quellen möglichst schnell verfügbar zu machen und den Build-Prozess zügig auf die Eclipse-Server zu verlagern.

Die vorläufige Begutachtung begann drei Tage nach dem Vorliegen aller Voraussetzungen und dauerte auch drei Tage. Danach lagen 20 Anmerkungen und Änderungswünsche vor. Einige der Anmerkungen waren trivial, andere führten uns zu kleinen Schlampigkeiten in unserem Quellstand. Die folgenden Beispiele sollen als Überblick dienen:

  • Kommentare, die Textstücke wie „Copy“, „Copied“, „Borrowed“, „Adapted“ enthielten
  • Vergessene Referenzen auf dem nicht mehr benutzten Lizenzserver in der Dokumentation
  • Fehlende EPL License Header
  • Icons ohne klares Copyright (z. B. in den Metadaten)
  • Ähnlichkeiten von Klassen- und Methodenname mit anderen OSS-Projekten

Etwa zwei Drittel der Probleme waren durch eine Erklärung aus der Welt zu schaffen. Man muss sich dabei klar machen, dass das IP-Team eher eine juristische Ausbildung hat und daher für aus Entwicklersicht triviale Dinge eine Erklärung benötigt. Für einige Anzeigefunktionen stellte sich heraus, dass sie auf Lizenzen beruhten, die nicht EPL-konform sind. Diese Teile wurden entfernt oder ersetzt, da sie auf einfachen JavaScript- oder CSS-Dateien basierten, die nur eine „hübschere“ Anzeige erstellt haben. Nach fünf Tagen konnten wir eine zweite Contribution bereitstellen, die keine der Probleme mehr enthielt, und nach einer weiteren Woche war die vorläufige Prüfung erfolgreich abgeschlossen.

So aufgeschrieben klingt der ganze Prozess recht kurz und schmerzlos. Dazu muss man sagen, dass die kurzen Antwortzeiten seitens des IP-Team gegebenenfalls nicht allgemeingültig sind, da die IP-Tests für Projekte, die am Release-Train teilnehmen, bevorzugt bearbeitet werden. Wir hatten auch im Voraus uns schon bekannte IP-Probleme identifiziert und gelöst (Stichwort „Hibernate“, siehe nächste Ausgabe), damit der tatsächliche Test schneller laufen konnte. Nach dieser vorläufigen Prüfung konnten die Dateien in das Repository auf git.eclipse.org abgelegt werden. Die endgültige Prüfung reihte sich in die lange Warteschlage der Indigo-Projekte ein und wurde zwei Monate später erfolgreich abgeschlossen.

Geschrieben von
Achim Lörke
Kommentare

Schreibe einen Kommentar

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