Zum Inhalt springen
Logo von nextlevels
Projekt anfragen
Zurück zum Wiki

Sustainable Use License (Fair-Code)

Die Sustainable Use License ist eine von n8n im März 2022 veröffentlichte Softwarelizenz, die den Quellcode offen zugänglich macht, die Nutzung aber auf eigene interne Geschäftszwecke sowie nicht-kommerzielle und private Zwecke beschränkt — sie ist damit der bekannteste Vertreter des von n8n geprägten Lizenzmodells Fair-Code und ausdrücklich keine Open-Source-Lizenz im Sinne der Open Source Initiative.

Der Begriff taucht in der Praxis fast immer im selben Moment auf: Ein Unternehmen will ein Automatisierungs-, Datenbank- oder Suchsystem selbst betreiben, liest „Source Code auf GitHub" und schließt daraus „also Open Source, also darf ich alles". Genau diese Gleichsetzung trifft bei Fair-Code nicht zu. Die Unterscheidung ist keine Haarspalterei unter Lizenzjuristen, sondern entscheidet darüber, ob ein geplantes Geschäftsmodell — etwa eine gehostete Automatisierungsplattform für Kunden — überhaupt zulässig ist.

Was „Fair-Code" bedeutet — und was es nicht ist

Fair-Code ist selbst keine Lizenz. Die Initiative hinter faircode.io beschreibt es ausdrücklich als Software-Modell, unter das mehrere konkrete Lizenzen fallen. Die Definition nennt vier Merkmale: Die Software ist grundsätzlich kostenlos nutzbar und darf von jedem weitergegeben werden, ihr Quellcode ist offen einsehbar, sie kann von jedem in öffentlichen wie privaten Communitys erweitert werden — und sie ist von ihren Autoren kommerziell eingeschränkt.

Der letzte Punkt ist der entscheidende. Er ist auch der, an dem sich das Modell von Open Source trennt. Die Open Source Initiative definiert in ihrer Open Source Definition unter Punkt 6 („No Discrimination Against Fields of Endeavor"), dass eine Lizenz niemanden davon ausschließen darf, die Software in einem bestimmten Tätigkeitsfeld einzusetzen — ausdrücklich auch nicht im kommerziellen Bereich. Eine Klausel, die die Nutzung auf „interne Geschäftszwecke" begrenzt, ist mit dieser Definition nicht vereinbar. n8n selbst zieht diese Konsequenz und bezeichnet das eigene Produkt konsequent nicht als Open Source, sondern als Fair-Code.

Die Lizenzen, die unter Fair-Code fallen

faircode.io listet mehrere bestehende Lizenzen als fair-code-konform, darunter die Business Source License (BSL/BUSL) von MariaDB, die Commons Clause in Kombination mit einer OSI-anerkannten Lizenz, die Confluent Community License, die Elastic License 2.0, die Server Side Public License (SSPL) von MongoDB sowie die Sustainable Use License. Als Projekte, die kompatible Lizenzen einsetzen, werden unter anderem Airbyte, CockroachDB, Elastic, HashiCorp, MongoDB, Sentry und n8n geführt. Zwischen der Fair-Code-Initiative und diesen Organisationen besteht laut der Seite keine Verbindung — die Liste ist eine Einordnung, keine Mitgliedschaft.

Der Wortlaut der Sustainable Use License

Die Lizenz ist bewusst kurz gehalten und in einfachem Englisch verfasst. Der relevante Abschnitt heißt schlicht „Limitations" und steht im LICENSE.md des n8n-Repositorys. Sinngemäß übersetzt sagt er: Man darf die Software nur für die eigenen internen Geschäftszwecke oder für nicht-kommerzielle beziehungsweise private Nutzung verwenden und verändern. Weitergeben oder Dritten zur Verfügung stellen darf man sie nur kostenlos und zu nicht-kommerziellen Zwecken. Lizenz-, Copyright- und sonstige Hinweise dürfen weder verändert noch entfernt oder verdeckt werden; die Nutzung der Marken des Lizenzgebers richtet sich nach dem anwendbaren Recht.

Davor steht eine erstaunlich weitreichende Rechteeinräumung: eine nicht-exklusive, lizenzgebührenfreie, weltweite, nicht unterlizenzierbare und nicht übertragbare Lizenz, die Software zu nutzen, zu kopieren, zu verbreiten, verfügbar zu machen und abgeleitete Werke davon zu erstellen — jeweils unter den genannten Einschränkungen. Dazu kommen eine Patentlizenz mit einer üblichen Retorsionsklausel (wer dem Lizenzgeber Patentverletzung vorwirft, verliert seine Patentlizenz sofort), eine Weitergabepflicht für die Lizenzbedingungen selbst, eine Kennzeichnungspflicht für modifizierte Kopien, ein Gewährleistungs- und Haftungsausschluss sowie eine Kündigungsregelung.

Diese Kündigungsregelung ist in der Praxis wichtiger, als sie aussieht: Wer die Software lizenzwidrig nutzt, verliert die Lizenz automatisch. Weist der Lizenzgeber auf den Verstoß hin und wird dieser innerhalb von 30 Tagen abgestellt, lebt die Lizenz rückwirkend wieder auf. Ein erneuter Verstoß nach einer solchen Wiederherstellung führt dagegen zur automatischen und dauerhaften Beendigung.

Wo die Grenze konkret verläuft

Die Trennlinie liegt nicht zwischen „kostenlos" und „kostenpflichtig", sondern zwischen eigener Nutzung und Weiterverwertung der Software als Produkt. Unproblematisch ist danach der Betrieb im eigenen Unternehmen, auch in einem Konzern mit mehreren tausend Mitarbeitenden, auch für Prozesse, mit denen das Unternehmen Geld verdient. Problematisch wird es, wenn die Software selbst zum Gegenstand des Angebots wird — etwa als gehostete Instanz, die man Dritten gegen Entgelt zur Verfügung stellt.

Bemerkenswert ist, was die Sustainable Use License gegenüber ihrem Vorgänger ausdrücklich freigegeben hat. n8n stand bis zum 17. März 2022 unter Apache 2.0 mit Commons Clause. In der Ankündigung des Lizenzwechsels nennt Gründer Jan Oberhauser zwei Änderungen: Die Definition der erlaubten Nutzung wurde von „verkaufen" auf „interne Geschäftszwecke" präzisiert — und die Beschränkung für Beratungs- und Supportleistungen wurde vollständig aufgehoben. Wer also für Kunden n8n-Workflows oder eigene Nodes baut und dafür Honorar nimmt, braucht dafür keine gesonderte Vereinbarung mehr. Als Basis für den Lizenztext diente, mit Zustimmung von Elastic, die Elastic License 2.0.

Abgrenzung: Open Source, Fair-Code und Source-Available

Die Begriffe werden im Marketing regelmäßig vermischt. Die folgende Übersicht ordnet die gängigen Modelle nach dem, was sie tatsächlich erlauben:

Modell / LizenzQuellcode einsehbarKommerzielle EigennutzungAls gehosteter Dienst weiterverkaufbarOSI-konform
Permissiv (MIT, Apache 2.0)jajajaja
Copyleft (GPL, AGPL)jajaja, unter Offenlegungspflichtenja
Sustainable Use License (Fair-Code)jaja, für interne Geschäftszweckeneinnein
Elastic License 2.0jajaneinnein
Business Source License (BSL/BUSL)jaja, mit Nutzungsgrenzenein, bis zum Change Datenein
Server Side Public License (SSPL)jajanur bei Offenlegung des gesamten Service-Stacksnein

Alle Zeilen unterhalb der Copyleft-Zeile fallen unter den Sammelbegriff source-available: Der Code ist lesbar, die Nutzung aber vertraglich begrenzt. Fair-Code ist eine Teilmenge davon mit einer spezifischen Haltung — der Autor behält sich die Kommerzialisierung als gehosteter Dienst vor, gibt aber alles andere frei.

Warum Anbieter dieses Modell wählen

Das Motiv ist selten ideologisch, sondern wirtschaftlich. Ein Open-Source-Projekt, das erfolgreich wird, kann von einem Cloud-Hyperscaler übernommen, als Managed Service verpackt und verkauft werden, ohne dass ein nennenswerter Teil des Umsatzes bei den Entwicklern ankommt. Die Fair-Code-Initiative formuliert das als „ökonomische Entkopplung" zwischen denen, die die Arbeit leisten, und denen, die daran verdienen. Die Sustainable Use License schließt genau diese Lücke: Wer die Software kommerziell als Dienst anbieten will, muss an den Verhandlungstisch.

Der Preis dafür ist real. Projekte unter Fair-Code verlieren den Zugang zu Distributionen, die nur OSI-konforme Lizenzen aufnehmen, sie fallen aus vielen Open-Source-Förderprogrammen heraus, und in Ausschreibungen mit einer harten „Open Source"-Anforderung sind sie formal nicht zulässig. Ob dieser Tausch aufgeht, hängt am Geschäftsmodell — eine allgemeingültige Antwort gibt es nicht.

Was das für Mittelständler im Self-Hosting bedeutet

Für die überwiegende Mehrheit der Unternehmen, die eine solche Software selbst betreiben, ändert die Lizenz praktisch nichts. Relevant wird sie an wenigen, klar benennbaren Stellen:

  • Interner Betrieb ist gedeckt. Eigene Server, eigene Workflows, eigene Mitarbeitende, eigene Daten — das ist der Kernfall, für den die Lizenz geschrieben wurde. Unternehmensgröße und Gewinnabsicht spielen dabei keine Rolle.
  • Beratung und Implementierung sind erlaubt. Eine Agentur darf für Kunden Workflows entwickeln und dafür Honorar berechnen. Diese Beschränkung ist 2022 entfallen.
  • Der Multi-Mandanten-Fall ist der kritische. Sobald eine Instanz betrieben wird, deren Nutzung Dritten als Leistung verkauft wird, verlässt man den erlaubten Bereich. Wer so etwas plant, braucht eine kommerzielle Vereinbarung mit dem Hersteller.
  • Enterprise-Funktionen sind separat lizenziert. Bei n8n gilt das für alle Quelldateien mit .ee. im Dateinamen oder .ee im Verzeichnisnamen — diese stehen nicht unter der Sustainable Use License, sondern erfordern eine gültige Enterprise-Lizenz.
  • Nur der Hauptbranch ist lizenziert. Inhalte anderer Branches als master sind laut LICENSE.md ausdrücklich nicht lizenziert. Wer aus einem Feature-Branch baut, sollte das wissen.

Alles jenseits dieser Grundfälle — Konzernstrukturen mit rechtlich selbstständigen Tochtergesellschaften, Joint Ventures, White-Label-Konstruktionen — sollte im Einzelfall juristisch geprüft werden. Die Lizenz definiert „your company" zwar über Kontrollverhältnisse, die Subsumtion des konkreten Sachverhalts ist damit aber nicht erledigt.

Realbeispiel: n8n

n8n ist das Referenzprojekt der Sustainable Use License — der Lizenztext liegt im Hauptrepository des Projekts, und n8n-Gründer Jan Oberhauser ist zugleich einer der Initiatoren von faircode.io. Die Workflow-Automatisierungsplattform lässt sich vollständig selbst hosten, der Code ist einsehbar, eigene Nodes lassen sich schreiben und veröffentlichen. Daneben betreibt n8n eine eigene Cloud-Variante und verkauft Enterprise-Lizenzen — die Monetarisierungsschiene, die die Lizenz freihält.

Weitere Projekte mit fair-code-kompatiblen Lizenzen sind unter anderem Airbyte und Nango (Elastic License 2.0), CockroachDB und Sentry (Business Source License) sowie MongoDB (SSPL). Die Sustainable Use License selbst steht laut n8n ausdrücklich auch anderen Projekten zur Verwendung offen.

Risiken und Missverständnisse

Das größte Missverständnis ist die Verwechslung mit Open Source — mit der Folge, dass Unternehmen ein Produktvorhaben aufsetzen, das die Lizenz nicht deckt, und das erst merken, wenn Vertrieb und Roadmap schon stehen.

Das zweite Risiko ist struktureller Natur und lässt sich an der jüngeren Branchengeschichte ablesen: Lizenzen ändern sich. Elastic wechselte 2021 von Apache 2.0 zu SSPL und Elastic License 2.0, woraufhin AWS Elasticsearch als OpenSearch forkte. HashiCorp stellte 2023 Terraform und weitere Produkte auf die Business Source License um; die Community antwortete mit OpenTofu. Redis wechselte im März 2024 vom BSD-Modell zu RSALv2/SSPLv1 — wenige Tage später startete unter dem Dach der Linux Foundation der Fork Valkey. Bemerkenswert ist die Gegenbewegung: Elastic ergänzte 2024 AGPLv3 als zusätzliche Lizenzoption, und Redis stellte Redis 8 im Mai 2025 ebenfalls unter AGPLv3.

Die Lehre daraus ist nicht „Fair-Code ist gefährlich", sondern schlichter: Die Lizenz eines strategisch wichtigen Systems ist eine Variable, keine Konstante. Wer eine Plattform tief in seine Prozesse einbaut, sollte wissen, wie teuer ein Wechsel — auf einen Fork, auf ein kommerzielles Abo, auf ein anderes Produkt — im Ernstfall wäre.

Ein drittes, häufig übersehenes Detail: Fair-Code-Lizenzen sind keine Standardverträge mit jahrzehntelanger Rechtsprechung. Begriffe wie „internal business purposes" sind im deutschen Recht nicht etabliert und im Zweifel auslegungsbedürftig. Für Grenzfälle ist eine anwaltliche Einschätzung die einzig belastbare Antwort.

Ausblick

Die Auseinandersetzung zwischen OSI-konformer Offenheit und wirtschaftlich abgesicherten Zwischenmodellen ist nicht entschieden. Auf der einen Seite hat die Fork-Reaktion des Marktes gezeigt, dass restriktive Lizenzwechsel teuer werden können; auf der anderen Seite haben mehrere Anbieter nachträglich AGPL-Optionen ergänzt, ohne ihre kommerziellen Einschränkungen an anderer Stelle aufzugeben. Für Anwender heißt das vor allem: Die Lizenzfrage gehört in die Evaluierung, und zwar vor der Architekturentscheidung, nicht danach.

Häufige Fragen

Ist n8n Open Source?

Nein. Der Quellcode ist offen einsehbar, aber die Sustainable Use License beschränkt die Nutzung auf interne Geschäftszwecke sowie nicht-kommerzielle und private Nutzung. Weil die Open Source Definition der OSI solche Nutzungsbeschränkungen ausschließt, bezeichnet sich n8n selbst nicht als Open Source, sondern als Fair-Code.

Darf ein Unternehmen Software unter der Sustainable Use License kommerziell nutzen?

Ja, für die eigenen internen Geschäftszwecke — auch dann, wenn damit Umsatz erwirtschaftet wird. Untersagt ist, die Software selbst gegen Entgelt an Dritte weiterzugeben oder als gehosteten Dienst anzubieten.

Darf eine Agentur Beratung und Implementierung abrechnen?

Ja. Die Beschränkung auf Beratungs- und Supportgebühren, die in der früheren Kombination aus Apache 2.0 und Commons Clause enthalten war, wurde mit dem Wechsel zur Sustainable Use License im März 2022 aufgehoben.

Worin unterscheidet sich die Sustainable Use License von der SSPL?

Die SSPL erlaubt grundsätzlich auch das Anbieten als Dienst, verlangt dafür aber die Offenlegung des gesamten zum Betrieb nötigen Service-Stacks unter derselben Lizenz — eine Bedingung, die in der Praxis kaum erfüllbar ist. Die Sustainable Use License untersagt diesen Fall direkt, ohne Umweg über eine Offenlegungspflicht.

Was passiert bei einem Lizenzverstoß?

Die Lizenz endet nach ihrem Wortlaut automatisch. Wird der Verstoß binnen 30 Tagen nach einer Mitteilung des Lizenzgebers abgestellt, lebt sie rückwirkend wieder auf; ein weiterer Verstoß danach beendet sie automatisch und dauerhaft. Wie sich das im konkreten Fall nach deutschem Recht auswirkt, ist im Einzelfall juristisch zu prüfen.

Weiterführende Artikel