World-Office: Wie ein Rewrite in Rust die inhärenten Probleme von Euro-Office behebt
🇬🇧 Read in English~9 min read
DevOpsOpen Sourcerustworld-officeeuro-officeonlyofficeopen-sourcerewritelicensingagpl
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Im März 2026 startete ein Konsortium europäischer Tech-Unternehmen, darunter Nextcloud, IONOS und Proton, Euro-Office – einen Fork von ONLYOFFICE, der Europa eine souveräne Office-Suite verschaffen sollte. Innerhalb weniger Tage beschuldigte ONLYOFFICE das Projekt jedoch, gegen die AGPLv3-Lizenz zu verstoßen. Der Streit beendete eine achtjährige Partnerschaft zwischen Nextcloud und ONLYOFFICE und hinterließ Euro-Office mit einer Codebasis, deren eigene Unterstützer die Beiträge als „unmöglich oder stark entmutigend“ bezeichneten.
World-Office (codeberg.org/World-Office) ist die Antwort darauf. Anstatt einen rechtlich umstrittenen Fork weiter zu patchen, schreibt das Projekt die gesamte Office-Suite von Grund auf in Rust neu. Neuntausend C++-Dateien wurden bereits durch 25 Crates ersetzt. Hier ist die Geschichte dahinter und warum dies für jeden, der eine Infrastruktur zur Dokumentenbearbeitung einsetzt, von Bedeutung ist.
Euro-Office wurde im März 2026 als Gemeinschaftsprojekt von Nextcloud, IONOS, Proton und mehreren anderen europäischen Technologieunternehmen ins Leben gerufen. Es handelt sich um einen Fork von ONLYOFFICE, der webbasierten Office-Suite von Ascensio System SIA. Um Missverständnisse zu vermeiden: Dies ist kein LibreOffice-Fork. ONLYOFFICE und LibreOffice teilen keinen Code. Der Kern von ONLYOFFICE ist in C++ geschrieben, mit einem JavaScript-Web-Frontend, und das native Dokumentenformat ist OOXML.
Der Fork entstand, weil die Upstream-Entwicklung von ONLYOFFICE stagnierte und das europäische Konsortium eine wirklich offene, community-gesteuerte Alternative wollte. Das Problem: Sie übernahmen die Codebasis und die Lizenzbedingungen, und beides erwies sich als problematisch.
ONLYOFFICE vertreibt seinen Quellcode unter der AGPLv3 mit zusätzlichen Bedingungen in Abschnitt 7 der Lizenz. Diese Zusatzklauseln verpflichten Downstream-Nutzer dazu, das ONLYOFFICE-Produktlogo beizubehalten und einen Markenhafter (Trademark Disclaimer) einzufügen. Euro-Office entfernte diese zusätzlichen Bedingungen aus ihrem Fork mit dem Argument, dass Abschnitt 7 der AGPLv3 explizit die Entfernung von „weiteren Einschränkungen“ erlaubt, die ein Lizenzgeber über die Standard-AGPLv3-Gewährung hinaus hinzufügt.
ONLYOFFICE widerspricht. Sie argumentieren, die Lizenz sei „bedingt und unteilbar“, was bedeute, dass die Entfernung eines beliebigen Teils, einschließlich der Ergänzungen in Abschnitt 7, zur automatischen Beendigung der Lizenz führe. Bradley M. Kuhn, einer der ursprünglichen AGPL-Autoren, hat Berichten zufolge die Interpretation von Euro-Office zu Abschnitt 7 unterstützt. Ein Gericht hat bisher nicht über die Angelegenheit entschieden.
| Aspekt | Position von ONLYOFFICE | Position von Euro-Office |
|---|---|---|
| Ergänzungen zu Abschnitt 7 | Integral, unteilbar von der Lizenz | „Weitere Einschränkungen“, entfernbar unter AGPLv3 §7 |
| Entfernung von Logo/Marken-Klauseln | Löst automatische Beendigung aus | Durch den Lizenztext selbst erlaubt |
| Rechtlicher Status des Forks | Verstoß gegen Lizenzbedingungen | Vollständig konform mit AGPLv3 |
| Expertenmeinung | Keine öffentlich genannt | Bradley M. Kuhn (AGPL-Autor) stimmt Berichten zufolge zu |
Für Unternehmen ist das praktische Ergebnis simpel: Bis ein Gericht entschieden hat, birgt der Einsatz von Euro-Office ein ungeklärtes rechtliches Risiko. Allein das macht es für den produktiven Einsatz in regulierten Umgebungen ungeeignet.
Abgesehen vom Lizenzchaos übernahm Euro-Office eine Codebasis mit schwerwiegenden strukturellen Problemen. Die Zahlen sprechen eine deutliche Sprache.
C++-Core-Layer: 10.385 Dateien allein in core/. Die Codebasis nutzt 31 Hierarchien mit Mehrfachvererbung. DesktopEditor enthält 263 virtuelle Dispatch-Methoden. Die Desktop-Anwendung liefert ein 200 MB großes Chromium Embedded Framework (CEF) Binary plus Qt-Abhängigkeiten aus, nur um ein natives Fenster zu rendern.
Web-Frontend: AMD/RequireJS für das Modul-Loading, was bedeutet: kein Tree-Shaking. Backbone.js und jQuery für die UI, was bedeutet: kein Komponentenmodell. Grunt als Build-Tool, das seit 2017 praktisch tot ist. Nirgendwo ist TypeScript zu finden. Die Frontend-Architektur stammt etwa aus dem Jahr 2014, und das merkt man.
Build-System: CMake orchestriert den C++-Build und zieht Daten aus 22 separaten Repositories. Beiträge erfordern das Navigieren durch dieses Multi-Repo-Setup, das Verständnis proprietärer Build-Konventionen und das Arbeiten ohne eine nennenswerte Test-Infrastruktur.
Euro-Office selbst räumte ein, dass Beiträge zur Codebasis „unmöglich oder stark entmutigend“ seien. Wenn die eigenen Unterstützer eines Projekts es so beschreiben, liegt das Problem im Code, nicht in der Community.
World-Office verfolgt einen grundlegend anderen Ansatz. Es ist kein Fork von Euro-Office oder ONLYOFFICE. Der C++-Quellcode wird nur als Referenzimplementierung beibehalten. Alles wird von Grund auf in Rust neu geschrieben.
Das Projekt ist auf Codeberg unter codeberg.org/World-Office zu finden und nutzt ein Tri-Lizenz-Modell: MIT auf Repository-Ebene, AGPL-3.0-or-later für einzelne Rust-Crates und eine optionale kommerzielle Lizenz für Nutzer, die diese benötigen.
| Metrik | C++ (Euro-Office) | Rust (World-Office) | Verhältnis |
|---|---|---|---|
| Core-Dateien | 10.385 | 25 Crates | 415:1 |
| OOXML-Parser | 3.387 Dateien | 1 Crate (wo-ooxml) | 3.387:1 |
| Test-Anzahl | Minimal | 470+ | N/A |
| Desktop-Runtime | 200MB CEF + Qt | ~10MB Tauri 2.0 WebView | 20:1 |
Die Kompression des OOXML-Parsers verdient eine kurze Pause. Dreitausenddreihundertsiebenundachtzig C++-Dateien, um Office Open XML zu parsen, ersetzt durch ein einziges Rust-Crate. Das ist keine Vereinfachung zum Selbstzweck. OOXML ist tatsächlich komplex, mit tausenden Seiten an Spezifikationen. Die C++-Implementierung verteilte diese Komplexität auf tausende Dateien, weil sie kein kohärentes Modulsystem besaß. Das Crate- und Modulsystem von Rust ermöglicht es World-Office, dieselbe Parsing-Logik hierarchisch innerhalb eines Crates zu organisieren, wobei Submodule die jeweiligen Hauptteile von OOXML (Textverarbeitung, Tabellenkalkulation, Präsentation, Zeichnung) übernehmen.
World-Office ersetzt fast drei Jahrzehnte an C++-Abhängigkeitsakkumulation durch Pure-Rust-Alternativen:
| C++ Abhängigkeit | Zweck | Rust-Ersatz |
|---|---|---|
| ICU (International Components for Unicode) | Unicode und i18n | icu4x |
| FreeType | Font-Rendering | ttf-parser |
| OpenSSL | TLS/Krypto | rustls |
| 26 weitere vendored C++-Bibliotheken | Verschiedenes | Pure Rust Äquivalente |
Das ist betrieblich relevant. Jede vendored C++-Bibliothek ist ein Risiko für die Supply Chain: separate Build-Systeme, separate Patch-Zyklen, separates CVE-Tracking. Pure Rust-Abhängigkeiten werden mit cargo kompiliert, haben ein einheitliches Versionsmanagement und lassen sich trivial für WASM-Targets cross-kompilieren.
Drei Eigenschaften machen Rust zur richtigen Wahl für den Rewrite einer Office-Suite, abgesehen von den üblichen Argumenten zur Speichersicherheit.
Speichersicherheit für nicht vertrauenswürdige Eingaben. Dokumenten-Parser sind das Lehrbuchbeispiel für speichersichere Sprachen. OOXML-Dateien, alte .doc-Formate und Tabellenkalkulations-Archive sind komplexe Binär- und XML-Strukturen aus nicht vertrauenswürdigen Quellen. Die Geschichte der CVEs in Office-Suite-Parsern ist lang und schmerzhaft. Rust eliminiert ganze Klassen dieser Schwachstellen bereits zur Kompilierzeit.
WASM als First-Class-Target. Eine browserbasierte Office-Suite muss in WebAssembly laufen. Rust kompiliert nativ zu WASM, ohne zusätzliche Toolchains oder Emscripten-Hacks. World-Office setzt WASM sowohl für den Browser-Editor als auch für die Tauri-basierte Desktop-Anwendung ein. Dieselbe Rust-Codebasis produziert beides.
Cargo ersetzt den Multi-Repo-Albtraum. Ein einziger Cargo.toml-Workspace ersetzt CMake über 22 Repositories hinweg. Dependency Resolution, Build-Orchestrierung, Testausführung und Publishing werden alle von einem einzigen Tool gehandhabt. Für Mitwirkende ändert sich das Onboarding von „klone 22 Repos und bete“ zu „cargo build“.
Der Rewrite ist keine Zeile-für-Zeile-Übersetzung. Es finden mehrere grundlegende architektonische Verschiebungen statt.
Mehrfachvererbung wird zu Traits und Komposition. Die 31 Mehrfachvererbungs-Hierarchien im C++-Code werden durch Rust-Trait-Objekte und Struct-Komposition ersetzt. Das ist zwar wortreicher, macht den Vererbungsgraph aber explizit und verhindert das „Diamond Problem“, das die C++-Codebasis plagte.
Keine Raw Pointers. Die C++-Codebasis nutzt extensiv Raw Pointers für Dokumenten-Knotenbäume, Formatkonvertierungs-Pipelines und das UI-State-Management. Rusts Ownership-System zwingt diese in explizite Lifetime-Annotationen oder reference-counted Wrapper, was den Datenfluss lesbar macht.
Test-First mit FormatRoundtrip. World-Office führt einen FormatRoundtrip-Trait ein, den jeder Format-Parser implementiert. Er parst ein Dokument, serialisiert es zurück, parst die Ausgabe erneut und vergleicht die Bäume. Dies ermöglicht konsistentes Cross-Format-Testing mit generierten Testdokumenten. Die Crate-Suite verfügt derzeit über 470+ Tests, die meisten davon sind property-basierte oder Roundtrip-Tests.
Build-Profile mit LTO und codegen-units=1. Release-Builds nutzen Link-Time Optimisation mit einer einzigen Codegen-Unit. Dies führt zu längeren Kompilierzeiten, aber zu deutlich kleineren und schnelleren Binaries. Für eine Office-Suite, die schnell starten muss, ist dieser Trade-off lohnenswert.
Neunundvierzig Commits in acht Tagen. Etwa 90 % des C++-Codes wurden durch Rust-Äquivalente ersetzt. Die verbleibende Arbeit konzentriert sich auf DesktopEditor (~5.000 Dateien) und Common (~2.000 Dateien), welche die native Application Shell und gemeinsame Utilities handhaben.
Was bereits erledigt ist:
wo-renderer, 125 Tests)wo-fonts, 36 Tests)axum für die Web-Office-Integrationthiserror für Fehlertypen, axum für alles HTTPDas Projekt nutzt die Rust Edition 2024, was Zugriff auf die neuesten Sprachfeatures ermöglicht, einschließlich gen-Blöcken für Async-Generatoren und verbessertem Trait-Solving. Dies ist keine konservative Entscheidung. Es signalisiert, dass das Projekt auf langfristige Optimierung setzt und nicht auf Abwärtskompatibilität mit älteren Toolchains.
Wenn Sie eine Infrastruktur zur Dokumentenbearbeitung betreiben, egal ob self-hosted oder in der Cloud, betrifft Sie die Euro-Office/ONLYOFFICE-Situation direkt. Hier ist, was Sie berücksichtigen sollten.
Das Lizenzrisiko ist real. Wenn Sie Euro-Office produktiv einsetzen, sind Sie einem ungeklärten AGPLv3-Streit ausgesetzt. Es gibt kein Gerichtsurteil. Die rechtliche Mehrdeutigkeit löst sich nicht von selbst auf. Sollte die Interpretation von ONLYOFFICE prevailen, ist jede Euro-Office-Installation technisch gesehen unlizenziert. Prüfen Sie Ihren Stack jetzt.
Supply-Chain-Komplexität ist ein Kostenfaktor. Zweiundzwanzig Repositories, 29 vendored C++-Bibliotheken, CMake-Build-Orchestrierung und ein Grunt-basiertes Frontend sind kein Maintainer-freundlicher Stack. Jeder Security-Patch erfordert die Koordination über mehrere Build-Systeme hinweg. Jedes Dependency-Update ist ein mehrtägiges Unterfangen. Das sind technische Schulden, die sich aufsummieren.
WASM ändert das Deployment-Modell. Eine Pure-Rust-Office-Suite, die zu WASM kompiliert, bedeutet, dass dasselbe Binary im Browser, auf dem Desktop via Tauri und auf dem Server läuft. Eine Build-Pipeline, eine Test-Suite, ein Deployment-Artefakt für drei Plattformen. Wenn Ihr Team derzeit separate Builds für Web- und Desktop-Dokumentenbearbeitung pflegt, ist dies eine erhebliche Vereinfachung.
Testabdeckung ist nicht optional. Vierhundertsiebzig Tests mit Roundtrip-Validierung sind eine Basis, keine Endzahl. Aber es sind 470 mehr, als die C++-Codebasis hatte. Für jeden, der für die Uptime in Dokumentenverarbeitungs-Pipelines verantwortlich ist, macht eine Test-Suite, die das Format-Parsing End-to-End validiert, den Unterschied aus, ob eine Regression in der CI oder erst in der Produktion entdeckt wird.
World-Office befindet sich noch in einem frühen Stadium. Die Core-Editoren sind gegenüber ONLYOFFICE noch nicht feature-complete. Aber die architektonischen Entscheidungen sind fundiert, die Lizenzierung ist eindeutig und das Beitragsmodell ist unkompliziert. Für Teams, die souveräne Office-Suite-Optionen evaluieren, lohnt es sich, das Projekt zu beobachten. Der Code ist unter codeberg.org/World-Office zu finden.