18.07.2025 - Fachbeitrag

OpenVox - das neue Puppet Open Source

Ende 2024 hat Puppet by Perforce Puppet angekündigt, dass man Puppet Open Source nicht mehr weiterentwickeln wird. Stattdessen stellt man ein Produkt namens "Puppet Core" zur Verfügung, welches nicht mehr Open Source ist. Die Open Source-Community hat reagiert und ein neues Projekt mit dem Namen "OpenVox" innerhalb der Vox Pupuli Puppet Community erstellt.

Ein Gastbeitrag von Dozent & Puppet-Experte Martin Alfke (betadots GmbH)

Open Source und Business

In den letzten Jahren ist es mittlerweile mehrmals vorgekommen, dass Firmen, die hauptverantwortlich ein Open Source Projekt entwickelt haben, die Lizenzen einschränken. Die bekanntesten Beispiele sind Hashicorp (Terraform) und Redis. Hier hat sich nun auch Puppet eingereiht.

Als Puppet 2005 die Entwicklung angefangen hat, wurde die GPL Lizenz verwendet. Im Rahmen der VC-Runden und da man eine kommerzielle Anwendung um Puppet herum entwickeln wollte, wurde die Lizenz in 2011 zu Apache 2 geändert. In 2022 wurde Puppet von der Firma Perforce gekauft.

Das neue Puppet

Seit Anfang 2025 wird Puppet Open Source nicht mehr weiter entwickelt. Statt dessen stellt Perforce "Puppet Core" und "Puppet Enterprise" zur Verfügung. Zur Nutzung von Puppet Core muss man einer EULA zustimmen. Wenn man Module für Puppet Core entwicklen möchte, muss man einer Entwickler EULA zustimmen.

Was steht in diesen Lizenzvereinbarungen?

User EULA:

max. 25 Nodes kostenlos, wenn man mehr Systeme verwalten möchte, muss man eine Nutzungslizenz kaufen.
- 3.1: Each Managed Node in excess of twenty-five (25) requires the purchase of one subscription license for the applicable Software.
keine Fehleranalyse
- 2.2: Customer shall not: (i) reverse engineer or otherwise attempt to discover the source code or human readable data or underlying ideas or algorithms of the Software
kein Support
- 4.1: The Software does not come with a standard support services package for the Software

Developer EULA:

keine Public CI Pipelines
- 2.2 Developer may not use the Software other than for (i) publication to the Puppet forge, or (ii) for the Developer’s customer’s use only
Modul Veröffentlichungen nur auf der Puppet Forge, nicht auf GitHub
- 2.4 modules are created for (i) publication to the Puppet forge, or (ii) for the Developer’s customer’s use only

Insbesondere die Punkte der Developer EULA lassen es nicht zu, dass eine Community, die auf GitHub entwickelt und öffentliche Pipelines nutzt, diese Lizenzen akzeptieren kann.

Das Angebot von Perforce, dass die Community im Puppetlabs Namensraum auf GitHub entwickelt, wurde von der Community sehr bestimmt verneint, da Perforce die Admin-Rechte in diesem Namespace besitzt. Durch das sehr negative Verhalten von Perforce gegenüber der Community (Bannen der Community-Admins im Puppet Community Slack) konnte man Perforce nicht mehr vertrauen. Die Anfrage, den Namensraum an die Community zu übertragen, wurde mit Hinweis auf Namensrechte abgelehnt.

In den nächsten Treffen mit Perforce wurden Details besprochen. Auf manche Informationen wartet die Community nach mehr als 5 Monaten immer noch. Laut Paul Watzlawick gilt: "Man kann nicht, nicht kommunizieren". Daraus hat die Community den Rückschluss gezogen, dass Perforce nichts weiter tun oder antworten wird. Somit war allen klar, dass es einen Fork von Puppet geben wird.

Forks und Registered Trademarks

In Bezug auf Registered Trademarks wurde die Community darauf hingewiesen, dass man das Vorkommen des Namens "Puppet" entfernen muss. Nach der Rückfrage, ob dies auch die API-Schnittstelle (lib/puppet) betrifft, haben die anwesenden Techniker Schnappatmung bekommen und das Thema erst Mal gestoppt. Im nächsten Treffen wurde die Community informiert, dass die Namensrechte nur auf Softwarepakete und nicht auf API-Schnittstellen angewendet werden können.

Man hat sich entschieden, einen Weg analog zu MariaDB anzuwenden. MariaDB ist ein Fork von MySQL. Die Pakete haben andere Namen, aber die Executables und APIs sind unverändert.

Community und Business wollen Kompatibilität

Da Puppet als Produkt ohne Erweiterungen relativ sinnlos ist, hat man sich mit Perforce geeinigt, ein Language Steering Committee zu etablieren, in dem Inkompatibilitäten oder Neuerungen an der Puppet Programmiersprache oder Tools vorab besprochen werden sollen. Damit möchte man sicherstellen, dass Puppet Erweiterungen (Module) weiterhin voll funktionsfähig sind.

Was ist bisher gemacht worden?

Der erste wichtige Schritt sind public build pipelines für die Softwarepaketierung. Die Paketierung bei Perforce erfolgte grundsätzlich über private Jenkins Pipelines, bei denen unbekannt war, wie der Zusammenbau der Komponenten erfolgte. Es ist wichtig zu erwähnen, dass keine weiteren Änderungen vorgenommen wurden! Installation- und Configpfade sind identisch (/opt/puppetlabs und /etc/puppetlabs). Dadurch wird erreicht, dass man die Puppet Open Source Pakete einfach durch die OpenVox-Pakete austauschen kann. Weitere Anpassungen oder Änderungen sind nicht notwendig (Drop-In Replacement).

Die Puppet Container dürfen auf Grund der Namensrechte nicht weiterentwickelt werden. Stattdessen hat die Community auf die OpenVox-Implementierung migriert.

Im Rahmen des Erstellens der Softwarepakete hat man neue Betriebssysteme hinzugefügt:

EL 10
Ubuntu 24
Debian 12 und 13!

Die Unterstützung für Enterprise Betriebssysteme (Solaris, AIX, ...) steht aktuell nicht zur Verfügung. Hier braucht die Community Unterstützung durch Firmen, die entweder Hardware oder finanzielle Mittel zur Verfügung stellen.

Um Code gegen OpenVox testen zu können, wird OpenVox als Ruby Gem benötigt. Da OpenVox/Puppet Systeminformationen benötigt, musste auch Facter geforkt werden. Der neue Name lautet "OpenFact".

Wie geht es weiter

Nach und nach wird jedes Tool, welches für die Funktionalität von OpenVox/Puppet DSL benötigt wird, innerhalb der Vox Pupuli GitHub Organisation geforkt und weiterentwickelt.

Aktuell wird an 2 Stellen gearbeitet:

Ersatz für das PDK (Puppet Development Kit)
Fork von Puppet Bolt Orchestrierung

Außerdem überlegt man, ob man für die weitere Entwicklung die Lizenz ändern möchte. Als Idee wurde bisher AGPL in den Raum geworfen. Eine endgültige Entscheidung steht noch aus.

Andere Open Source Communities (Foreman, Debian, Arch Linux) haben bereits von Puppet auf OpenVox umgestellt oder sind dabei, die Umstellung vorzunehmen.

Sponsoring

Als Open Source Community möchte man gerne Non-Profit basierend arbeiten. Trotzdem muss man sicherstellen, dass:

die Community alles hat, was sie zum Arbeiten benötigt
Open Source-Entwickler von der Arbeit leben können

Für die notwendigen Arbeiten und die Verwaltung hat GitHub den Enterprise Account gesponsert. Die Universität Oslo hat einen Puppet gemanagten, dedizierten Kubernetes-Cluster für beliebige Arbeiten zur Verfügung gestellt. Die Vox Pupuli Community hat ein Bounty Program gestartet, bei dem man für vorab definierte Arbeiten Geld zur Verfügung stellt.

Fazit

Das teilweise irrationale Vorgehen von Perforce hat die Community zwar überrascht, aber auch für ein neues Momentum gesorgt. Viele ehemalige Community-Mitglieder sind wieder aktiv geworden.

Andere Communities unterstützen das Projekt. Es haben sich Firmen herauskristallisiert, die das Projekt durch Zeit und Geld unterstützen. Trotzdem ist das Thema Finanzierung auch für die Community noch ein großes Problem. Deshalb bittet die Community darum, das Projekt direkt oder mit Hilfe der unterstützenden Firmen finanziell zu fördern.

OpenVox und Puppet an der Heinlein Akademie

Für alle, die sich in Puppet und OpenVox fit machen möchten, bietet unsere Linux-Akademie übrigens auch in Zukunft zwei Schulungen für Puppet Einsteiger und Fortgeschrittene an. In den Schulungen können Sie von unserem Experten Martin Alfke aus erster Hand alles zu den aktuellen Entwicklungen rund um OpenVox lernen.

Sie möchten dabei sein?

ab 15.09.2025 OpenVox/Puppet Grundlagen (Berlin)
ab 19.11.2025 OpenVox/Puppet Entwickler (Berlin)

Expertise

Akademie

Consulting

Services