World-Office: How a Rust Rewrite Fixes Euro-Office's Inherent Problems
đ©đȘ Auf Deutsch lesen~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.
In March 2026, a consortium of European tech companies including Nextcloud, IONOS, and Proton launched Euro-Office, a fork of ONLYOFFICE intended to give Europe a sovereign office suite. Within days, ONLYOFFICE accused the project of AGPLv3 licence violations. The dispute ended an eight-year partnership between Nextcloud and ONLYOFFICE, and left Euro-Office carrying a codebase that its own backers described as having contributions that are "impossible or greatly discouraged."
World-Office (codeberg.org/World-Office) is the response. Rather than continue patching a legally contested fork, the project is rewriting the entire office suite from scratch in Rust. Nine thousand C++ files have already been replaced by 25 crates. Here is what happened, and why it matters for anyone deploying document editing infrastructure.
Euro-Office launched in March 2026 as a collaborative effort by Nextcloud, IONOS, Proton, and several other European technology companies. It is a fork of ONLYOFFICE, the web-based office suite built by Ascensio System SIA. To be clear: this is not a LibreOffice fork. ONLYOFFICE and LibreOffice share no code. ONLYOFFICE's core is written in C++, with a JavaScript web frontend, and its native document format is OOXML.
The fork happened because ONLYOFFICE's upstream development had stagnated and the European consortium wanted a genuinely open, community-governed alternative. The problem: they inherited the codebase and the licensing terms, and both were problematic.
ONLYOFFICE distributes its source under AGPLv3 with additional terms attached via Section 7 of the licence. These additional clauses require downstream users to retain the ONLYOFFICE product logo and include a trademark disclaimer. Euro-Office stripped these additional terms from their fork, arguing that AGPLv3 Section 7 explicitly permits the removal of "further restrictions" that a licensor adds beyond the standard AGPLv3 grant.
ONLYOFFICE disagrees. They argue the licence is "conditional and indivisible," meaning that removing any part of it, including the Section 7 additions, triggers automatic licence termination. Bradley M. Kuhn, one of the original AGPL authors, has reportedly supported Euro-Office's reading of Section 7. No court has ruled on the matter.
| Aspect | ONLYOFFICE's Position | Euro-Office's Position |
|---|---|---|
| Section 7 additions | Integral, indivisible from the licence | "Further restrictions" removable under AGPLv3 §7 |
| Stripping logo/trademark clauses | Triggers automatic termination | Permitted by the licence text itself |
| Legal status of the fork | Violation of licence terms | Fully compliant with AGPLv3 |
| Expert opinion | None cited publicly | Bradley M. Kuhn (AGPL author) reportedly agrees |
For enterprises, the practical upshot is simple: until a court rules, deploying Euro-Office carries unresolved legal risk. That alone makes it unsuitable for production use in regulated environments.
Beyond the licensing mess, Euro-Office inherited a codebase with serious structural problems. The numbers tell the story.
Core C++ layer: 10,385 files in core/ alone. The codebase uses 31 multiple inheritance hierarchies. DesktopEditor contains 263 virtual dispatch methods. The desktop application ships a 200MB Chromium Embedded Framework (CEF) binary plus Qt dependencies just to render a native window.
Web frontend: AMD/RequireJS for module loading, which means no tree-shaking. Backbone.js and jQuery for UI, which means no component model. Grunt for build tooling, which has been effectively dead since 2017. No TypeScript anywhere. The frontend architecture dates from roughly 2014, and it shows.
Build system: CMake orchestrates the C++ build, pulling from 22 separate repositories. Contributing requires navigating this multi-repo setup, understanding the proprietary build conventions, and working around the lack of any meaningful test infrastructure.
Euro-Office themselves acknowledged that contributing to the codebase is "impossible or greatly discouraged." When the project's own backers describe it this way, the code is the problem, not the community.
World-Office takes a fundamentally different approach. It is not a fork of Euro-Office or ONLYOFFICE. The C++ source is kept only as a reference implementation. Everything is being rewritten in Rust from scratch.
The project lives on Codeberg at codeberg.org/World-Office and uses a tri-licence model: MIT at the repository level, AGPL-3.0-or-later for individual Rust crates, and an optional commercial licence for users who need it.
| Metric | C++ (Euro-Office) | Rust (World-Office) | Ratio |
|---|---|---|---|
| Core files | 10,385 | 25 crates | 415:1 |
| OOXML parser | 3,387 files | 1 crate (wo-ooxml) | 3,387:1 |
| Test count | Minimal | 470+ | N/A |
| Desktop runtime | 200MB CEF + Qt | ~10MB Tauri 2.0 WebView | 20:1 |
The OOXML parser compression is worth pausing on. Three thousand three hundred and eighty-seven C++ files to parse Office Open XML, replaced by a single Rust crate. That is not simplification for its own sake. OOXML is genuinely complex, with thousands of pages of specification. The C++ implementation spread that complexity across thousands of files because it had no coherent module system. Rust's crate and module system lets World-Office organise the same parsing logic hierarchically within one crate, with submodules handling each major OOXML part (wordprocessing, spreadsheet, presentation, drawing).
World-Office replaces nearly three decades of C++ dependency accumulation with pure-Rust alternatives:
| C++ Dependency | Purpose | Rust Replacement |
|---|---|---|
| ICU (International Components for Unicode) | Unicode and i18n | icu4x |
| FreeType | Font rendering | ttf-parser |
| OpenSSL | TLS/crypto | rustls |
| 26 other vendored C++ libraries | Various | Pure Rust equivalents |
This matters operationally. Every vendored C++ library is a supply chain liability: separate build systems, separate patch cycles, separate CVE tracking. Pure Rust dependencies compile with cargo, have unified version management, and cross-compile trivially to WASM targets.
Three properties make Rust the right choice for an office suite rewrite, beyond the usual memory-safety talking points.
Memory safety for untrusted input. Document parsers are the textbook use case for memory-safe languages. OOXML files, legacy .doc formats, and spreadsheet archives are all complex binary and XML structures received from untrusted sources. The history of CVEs in office suite parsers is long and painful. Rust eliminates entire classes of these vulnerabilities at compile time.
WASM is a first-class target. A browser-based office suite needs to run in WebAssembly. Rust compiles to WASM natively with no extra toolchains or Emscripten hacks. World-Office targets WASM for both the browser editor and the Tauri-based desktop application. The same Rust codebase produces both.
Cargo replaces the multi-repo nightmare. One Cargo.toml workspace replaces CMake across 22 repositories. Dependency resolution, build orchestration, test running, and publishing are all handled by a single tool. For contributors, the onboarding goes from "clone 22 repos and pray" to "cargo build."
The rewrite is not a line-by-line translation. Several fundamental architectural shifts are happening.
Multiple inheritance becomes traits and composition. Those 31 multiple inheritance hierarchies in the C++ code are replaced by Rust trait objects and struct composition. This is more verbose but makes the inheritance graph explicit and prevents the diamond problem that plagued the C++ codebase.
No raw pointers. The C++ codebase uses raw pointers extensively for document node trees, format conversion pipelines, and UI state management. Rust's ownership system forces these into explicit lifetime annotations or reference-counted wrappers, making the data flow legible.
Test-first with FormatRoundtrip. World-Office introduces a FormatRoundtrip trait that every format parser implements. It parses a document, serialises it back, parses the output again, and compares the trees. This gives consistent cross-format testing with generated test documents. The crate suite currently has 470+ tests, most of them property-based or roundtrip tests.
Build profiles with LTO and codegen-units=1. Release builds use Link-Time Optimisation with a single codegen unit. This produces larger compile times but significantly smaller and faster binaries. For an office suite that needs to start quickly, the trade-off is worth it.
Forty-nine commits in eight days. Roughly 90% of the C++ has been replaced by Rust equivalents. The remaining work centres on DesktopEditor (~5,000 files) and Common (~2,000 files), which handle the native application shell and shared utilities.
What is already done:
wo-renderer, 125 tests)wo-fonts, 36 tests)axum for web-office integrationthiserror for error types, axum for all HTTPThe project uses Rust Edition 2024, which gives access to the latest language features including gen blocks for async generators and improved trait solving. This is not a conservative choice. It signals that the project is optimising for the long term, not backwards compatibility with older toolchains.
If you are running document editing infrastructure, whether self-hosted or cloud, the Euro-Office/ONLYOFFICE situation affects you directly. Here is what to consider.
Licence risk is real. If you are running Euro-Office in production, you are exposed to an unresolved AGPLv3 dispute. No court has ruled. The legal ambiguity does not resolve itself. If ONLYOFFICE's reading prevails, every Euro-Office deployment is technically unlicensed. Audit your stack now.
Supply chain complexity is a cost. Twenty-two repositories, 29 vendored C++ libraries, CMake build orchestration, and a Grunt-based frontend is not a maintainer-friendly stack. Every security patch requires coordinating across multiple build systems. Every dependency update is a multi-day effort. This is technical debt that compounds.
WASM changes the deployment model. A pure Rust office suite that compiles to WASM means the same binary runs in the browser, on the desktop via Tauri, and on the server. One build pipeline, one test suite, one deployment artifact for three platforms. If your team is currently maintaining separate builds for web and desktop document editing, this is a meaningful simplification.
Test coverage is not optional. Four hundred and seventy tests with roundtrip validation is a baseline, not a final number. But it is 470 more than the C++ codebase had. For anyone responsible for uptime in document processing pipelines, having a test suite that validates format parsing end to end is the difference between catching a regression in CI and catching it in production.
World-Office is early stage. The core editors are not yet feature-complete against ONLYOFFICE. But the architectural decisions are sound, the licensing is unambiguous, and the contribution model is straightforward. For teams evaluating sovereign office suite options, it is worth watching. The code is at codeberg.org/World-Office.