Lizenzwechsel bei Open-Source-Projekten: Was tun, wenn die UI-Library plötzlich Geld kostet?

Eigentlich wollte ich nur ein Routine-Update machen: Angular 21 auf 22, TypeScript auf 6.0, ein paar Pakete nachziehen. Dann stand ich vor einer Abhängigkeit, die es in der nächsten Major-Version nicht mehr unter MIT-Lizenz gibt. In diesem Beitrag zeige ich dir, was hinter solchen Lizenzwechseln steckt, welche Optionen du hast und wie ich das Problem in neun Angular-Projekten gelöst habe.

Was passiert ist

Wer kennt’s? Du startest ng update, die Migrationen laufen durch, und dann meldet npm einen Peer-Konflikt bei genau der Library, auf der dein halbes Frontend aufbaut. Bei mir war das PrimeNG.

Der Grund war diesmal kein technischer. PrimeTek hat angekündigt, dass künftige Major-Versionen von PrimeNG nicht mehr Open Source sind. Das GitHub-Repository wurde am 28. Juni 2026 archiviert, ab Version 22 gilt ein kommerzielles Lizenzmodell. Betroffen sind auch die React- und Vue-Varianten.

Ganz ohne kostenlosen Weg ist das neue Modell nicht:

Es gibt eine kostenlose Community-Lizenz für Einzelpersonen, Studierende, Non-Profits, nicht-kommerzielle Open-Source-Projekte und kleine Organisationen
Die Pro-Komponenten (unter anderem Charts, Editor, Scheduler) sind darin nicht enthalten und starten bei 599 USD pro Entwickler
Die bisherigen Versionen bis einschließlich v21 bleiben unter MIT-Lizenz nutzbar

Für ein kommerzielles Produkt wie DiLog heißt das trotzdem: Mit dem Sprung auf Angular 22 hängt eine zentrale Abhängigkeit an Lizenzbedingungen, die ich nicht selbst in der Hand habe.

Kein Einzelfall

PrimeNG ist nicht das erste Projekt, das diesen Weg geht. In den letzten Jahren hat sich ein Muster herausgebildet: Ein Unternehmen ändert die Lizenz, die Community forkt den letzten freien Stand.

Projekt	Jahr	Wechsel	Community-Fork
PrimeNG	2026	MIT → kommerziell (ab v22)	Optimus UI
Redis	2024	BSD → RSALv2 / SSPL	Valkey
Terraform	2023	MPL 2.0 → BSL 1.1	OpenTofu
Elasticsearch	2021	Apache 2.0 → SSPL / Elastic License	OpenSearch
MongoDB	2018	AGPL → SSPL	–

Interessant ist, was danach passiert ist: Sowohl Elasticsearch (2024) als auch Redis (2025) haben später wieder eine AGPL-Option ergänzt. Die Forks sind trotzdem geblieben.

Warum Projekte die Lizenz wechseln

So ärgerlich das als Anwender ist, die Motive sind nachvollziehbar. Hinter den meisten großen Open-Source-Projekten steht ein Unternehmen, das Entwickler bezahlen muss.

Fehlende Einnahmen: Millionen Downloads zahlen keine Gehälter. Support- und Template-Verkäufe tragen ein Team oft nicht dauerhaft
Konkurrenz durch Cloud-Anbieter: Bei Redis, Elasticsearch und MongoDB war das der Auslöser. Große Anbieter verkaufen die Software als Managed Service, ohne zur Entwicklung beizutragen
Investoren-Druck: Wer Wagniskapital aufgenommen hat, muss irgendwann Umsatz zeigen

Rechtlich ist so ein Wechsel möglich, weil der Hersteller die Rechte am Code hält oder die Lizenz es zulässt. Bei permissiven Lizenzen wie MIT darf jeder den Code in ein proprietäres Produkt überführen, also auch der ursprüngliche Autor.

Wichtig für dich: Ein Lizenzwechsel wirkt nie rückwirkend. Was einmal unter MIT veröffentlicht wurde, bleibt unter MIT. Genau das macht Forks überhaupt erst möglich.

Welche Optionen hast du?

Wenn eine deiner Abhängigkeiten die Lizenz wechselt, gibt es im Kern vier Wege:

Auf der letzten freien Version bleiben
- Kostet nichts und funktioniert sofort
- Du bekommst aber keine Sicherheitsupdates mehr und blockierst Framework-Updates. Bei mir hätte das bedeutet, auf Angular 21 festzusitzen
Die neue Lizenz akzeptieren
- Der einfachste Weg, technisch ändert sich nichts
- Prüfe genau, ob du unter eine kostenlose Stufe fällst und was passiert, wenn dein Team wächst oder sich die Bedingungen erneut ändern
Auf einen Community-Fork wechseln
- Die API bleibt weitgehend gleich, der Migrationsaufwand ist überschaubar
- Du wettest darauf, dass der Fork langfristig gepflegt wird
Auf eine andere Library umsteigen
- Die sauberste Lösung, wenn du der Library ohnehin entwachsen bist
- Bei einer UI-Library bedeutet das in der Regel, jedes Template anzufassen

Ich habe mich für den Fork entschieden. Die kostenlose Community-Lizenz würde für uns zwar passen. Mir ist aber das Risiko zu groß, dass sich die Bedingungen erneut ändern. Ein kompletter Wechsel der UI-Library hätte bei neun Angular-Projekten in keinem Verhältnis zum Nutzen gestanden.

Wie die Migration bei mir lief

Der Fork heißt Optimus UI und wird vom OpenNG-Kollektiv gepflegt. Er basiert auf PrimeNG v21, der letzten MIT-lizenzierten Version, und steht selbst wieder unter MIT.

Ein Detail solltest du kennen: Version 1 von Optimus UI ist ein umbenanntes PrimeNG für Angular 21. Die Unterstützung für Angular 22 kam erst mit Version 2. Als ich migriert habe, war sie bereits verfügbar.

Die eigentliche Umstellung übernimmt ein Schematic:

npm install @openng/optimus-ui
ng generate @openng/optimus-ui:migrate-from-primeng

Welche Versionsangabe du dabei brauchst, hängt von deiner Angular-Version ab. Die genauen Befehle stehen in der README von Optimus UI.

Die Icons habe ich bei der Gelegenheit komplett auf FontAwesome umgestellt. Für PrimeIcons gibt es mit @openng/icons zwar ebenfalls einen Fork, der die pi pi-*-Klassen beibehält. FontAwesome war bei mir aber ohnehin schon eingebunden und gefällt mir vom Design besser.

Der Lizenzwechsel war nicht die einzige Baustelle

So ein Major-Update kommt selten allein. Neben der UI-Library standen noch ein paar andere Dinge im Weg:

TypeScript 6.0 ist strenger. Für typlose Side-Effect-Imports waren Shims nötig
npm-Peer-Konflikte durch veraltete node_modules und Pakete, die nur Angular 21 erlaubten. Geholfen haben Clean-Installs und Versionssprünge
ESM-only-Pakete wie file-type 22 und cookie 2 vertragen sich nicht mit einem CommonJS-Backend. Die habe ich bewusst auf der Vorversion gehalten
bullmq 6 hat die Repeatable-Jobs-API entfernt, firebase-admin 14 erzwingt modulare Imports. Beides bedeutete Refactoring
SSR nach dem Deploy: Angular 22 lehnt unbekannte Hostnamen ab (hostname not allowed), bis die erlaubten Hosts konfiguriert sind

Im Vergleich dazu war die Migration auf Optimus UI der entspannteste Teil: Das Schematic lief sauber durch.

Was ich daraus mitnehme

Eine Open-Source-Lizenz ist eine Momentaufnahme. Sie gilt für die Version, die du heute installierst, und sagt nichts über die nächste.

Ein paar Dinge achte ich seitdem bei neuen Abhängigkeiten stärker:

Wer steht dahinter? Ein einzelnes Unternehmen kann die Lizenz jederzeit ändern. Bei Projekten unter dem Dach einer Stiftung ist das deutlich unwahrscheinlicher
Wie tief ist die Abhängigkeit verdrahtet? Eine UI-Library steckt in jedem Template. Je tiefer eine Abhängigkeit sitzt, desto genauer lohnt der Blick
Regelmäßig updaten. Wer mehrere Major-Versionen hinterherhängt, hat im Ernstfall zwei Probleme gleichzeitig

Wenn du selbst PrimeNG einsetzt, probier Optimus UI am besten in einem eigenen Branch aus. Und falls du schon migriert hast: Mich würde interessieren, wie es bei dir gelaufen ist.