SuperPlane und Forklift im Evidence-Gate: Messwerte, Lizenz und offene Fehler

Zwei Projekte tauchten zuletzt in Newslettern auf: SuperPlane, das Issues über einen Agenten zu Pull Requests macht, und Forklift, das virtuelle Maschinen von VMware, oVirt, OpenStack, Nutanix und Hyper-V nach KubeVirt migriert. Wir haben beide nach unserem OSS-Evidence-Gate geprüft. Das Gate verlangt Quellen, die dem Projekt widersprechen dürfen: Issue-Tracker, Lizenzdateien, Commit-Daten, Workflows. Installiert haben wir keines von beiden.

Open Core bedeutet: Ein quelloffener Kern steht unter einer anerkannten Lizenz, weitere Funktionen liegen im selben Repository oder daneben unter einer eigenen Lizenz, die Nutzung oder Weitergabe einschränkt. Bei SuperPlane steht die Engine unter Apache 2.0 und das Verzeichnis ee/ unter einer Enterprise-Lizenz. Für den Betrieb zählt, welche Dateien im ausgelieferten Binary landen.

Messwerte vom 09.11.2026

Messträger ist die GitHub-REST-API (api.github.com), Branch main, Messdatum 09.11.2026. Das 30-Tage-Fenster beginnt am 10.10.2026 nach Committer-Datum.

Die Trailer-Zählung sucht in Signed-off-by und Co-authored-by nach SuperPlane Agent, Cursor und Claude. Sie zeigt, wer als Mitwirkender eingetragen ist, und sagt nichts über den Anteil geschriebenen Codes. Alle 207 Bot-Commits von SuperPlane tragen zusätzlich den SuperPlane-Agent-Trailer. Zusammen sind es 346 von 492 Commits (70,3 %); die letzten 100 Commits (29.10. bis 08.11.) liegen bei 74 %. Bei Forklift sind 181 der 198 markierten Commits Dependency- und Bundle-Updates des Red-Hat-Build-Bots red-hat-konflux[bot], also Build-Automatik. Agent-Trailer (Cursor, Claude) tragen nur 17 Commits.

Gegenüber den Newsletter-Zahlen ergibt sich: SuperPlane hat 9.301 statt 8.800 Sterne, 78 statt 83 Contributors und 81 Releases wie genannt. Forklift hat 213 Sterne wie genannt, 69 statt 71 Contributors und ein Release wie genannt. Die Sterne dienen nur als Nachsatz: SuperPlane 701 Forks und 12 Watcher, Forklift 122 Forks und 6 Watcher. Eine Empfehlung leiten wir daraus nicht ab.

Zu den Releases: Forklift hat ein GitHub-Release (v2.12.1 vom 30.06.2026), aber 72 Tags bis v5.0.0 vom 28.10.2026. Die 81 SuperPlane-Releases zählen mehrere Komponenten mit (CLI, Fleet-Manager, Runner), das neueste Hauptrelease ist v1.0.0 vom 27.10.2026, 13 Tage alt.

SuperPlane: Lizenz und Tracker

Die LICENSE-Datei beginnt mit dem Satz, dass Dateien in /ee der SuperPlane Enterprise Edition License unterliegen, danach folgt der Apache-Text. Das README nennt nur Apache 2.0, GitHub meldet NOASSERTION. Die ee/LICENSE erlaubt die Nutzung für Self-Hosting nur mit Zustimmung zu den Nutzungsbedingungen und einer gültigen Enterprise-Lizenz; Kopieren und Ändern zu Entwicklungs- und Testzwecken ist ohne Lizenz erlaubt.

Die ee/README beschreibt, dass der Enterprise-Code immer im Binary steckt und Funktionen erst laufen, wenn die Installation eine Lizenz hat. Laut Dokumentation prüft SuperPlane die Lizenz offline. Lizenzpflichtig sind Custom Roles, Gruppen und GitHub-Enterprise-Hosts. Der Billing-Code liegt ebenfalls unter ee/ und läuft immer; Nutzungskosten werden auch bei abgeschaltetem Billing aufgezeichnet. Ob der Produktivbetrieb ohne Enterprise-Lizenz zulässig ist, entscheiden wir hier nicht. Das wäre beim Hersteller schriftlich zu klären.

Von 158 offenen Issues kommen 139 von neun Konten mit Collaborator- oder Contributor-Status, also aus dem eigenen Backlog. 19 stammen von acht Außenstehenden. 24 Issues tragen das Label bug. Drei lesen sich wie Befunde zum Kernversprechen: #8641 (die Planung verwirft den Plan still und meldet Erfolg), #8631 (Agent-Läufe committen Workspace-Skills in den Pull Request) und #9186 (Factory-Commits ohne DCO-Sign-off). Offen ist auch #8123 „Support GitLab workspaces". Im Verzeichnis pkg/integrations gibt es github, gitlab und bitbucket, aber kein Gitea; unser Git-Server ist Gitea (git.senn-gruppe.com). Die 2.655 geschlossenen Issues sagen nichts über Behebungen, 326 davon sind „not planned".

Die GitHub-Workflows sind überschaubar: eine Discord-Meldung bei geöffneten und geschlossenen Issues über ein Secret-Webhook und ein Stale-Job. pull_request_target kommt nicht vor. CI und Releases laufen über Semaphore (13 Dateien, zwei davon gelesen). Ob Fork-Pull-Requests dort Secrets sehen, ist eine Projekteinstellung, die wir vom Repo aus nicht sehen. Die Verzeichnisse productanalytics und telemetry in pkg/ haben wir nicht gelesen. Was eine selbst gehostete Instanz nach außen sendet, ist offen.

Forklift: Tracker und Workflows

Forklift steht unter Apache 2.0 (LICENSE-Datei gelesen). Das Projekt ist vier Jahre alt, die Dokumentationsseite beschreibt es als Upstream der Red-Hat-Variante Migration Toolkit for Virtualization (MTV). 35 der 245 Commits der letzten 30 Tage verweisen auf Tickets im Format MTV-nnnn. Vermutlich liegt ein Teil der Fehlerliste in einem Ticketsystem von Red Hat, das wir nicht eingesehen haben; die 85 offenen GitHub-Issues zeigen also nur einen Ausschnitt.

Davon sind 12 von einem Review-Bot angelegt, 53 haben keinen Kommentar, 63 sind älter als ein Jahr. Das Issue #7845 beschreibt einen Plan mit OVA-Quelle und skipGuestConversion: true, der als Succeeded endet, obwohl die Zielplatte leer ist. Es ist seit dem 31.07.2026 offen, hat keinen Kommentar und kein Label, kommt von einem externen Konto und ist nicht bestätigt. Als Prüfregel taugt es trotzdem: Bei einer Migration zählt die Prüfsumme der Zielplatte, nicht der Status Succeeded.

In den zwölf Workflows gibt es einen pull_request_target-Trigger (create-new-pr.yml). Er checkt keinen PR-Code aus und schreibt nur einen Kommentar. Seine Bedingung liest github.event.comment, das bei diesem Ereignis fehlt; vermutlich läuft der Job deshalb nie. Auffälliger ist myrotvorets/set-commit-status-action@master in run-osp-extended-tests.yml: eine bewegliche Fremd-Referenz, die das GITHUB_TOKEN erhält. Der Build-Pfad liegt in .tekton und .konflux, die wir nicht gelesen haben.

Was das für uns bedeutet

Wir betreiben Proxmox. In docs\inventory gibt es bei der Suche vom 09.11.2026 keinen Treffer für Kubernetes, KubeVirt, k3s oder OpenShift; im Inventar steht auch keine VMware-Umgebung. Wie sich eine VMware-Ablösung rechnet, steht in Proxmox nach VMware: die Lizenzrechnung 2026. Weitere Beiträge zu Virtualisierung und Betrieb sammelt der Hub Server, Proxmox und Netzwerk. Wer seine Plattform prüfen lassen möchte, findet das Angebot unter Leistungen.

Forklift: nicht übernehmen, weil es keinen Einsatzfall gibt. Neu bewerten, falls eine KubeVirt-Entscheidung ansteht. Der Abnahmetest wäre dann ein Prüfsummenvergleich der Zielplatte je VM.

SuperPlane: beobachten. Testen wir nur, wenn drei Bedingungen erfüllt sind: Gitea-Unterstützung ist im Code belegt, die Frage zu ee/ im Binary ist schriftlich beantwortet, und der Test läuft auf einer isolierten VM mit mitgeschnittenem ausgehendem Verkehr.

Weiterführende Quellen

• SuperPlane, Repository: github.com/superplanehq/superplane
• SuperPlane, Hauptlizenz: LICENSE
• SuperPlane, Enterprise-Lizenz: ee/LICENSE
• SuperPlane, Enterprise-Code im Binary: ee/README.md
• SuperPlane, Lizenzprüfung: enterprise-licensing.md
• SuperPlane, Issue zu GitLab: Issue 8123
• Forklift, Repository: github.com/kubev2v/forklift
• Forklift, Issue zur leeren Zielplatte: Issue 7845
• Forklift, Dokumentation Upstream und MTV: kubev2v.github.io
• Messdaten: GitHub-API SuperPlane und GitHub-API Forklift