Odoo und digitale Souveränität: Community, OCA, Ausstieg
Kurz gesagt
Mit Odoo Community auf einem eigenen Server sind Sie weitgehend unabhängig: Der Servercode steht unter der LGPLv3, Datenbank und Dateispeicher liegen bei Ihnen. Die Edition allein entscheidet das nicht; wo die Daten liegen, bestimmt die Betriebsart (eigener Server, Odoo.sh, Odoo Online). Die Enterprise-Apps (etwa Accounting, Studio) brauchen ein gültiges Abonnement; mit dem Vertragsende ist die Lizenz sofort widerrufen und die Nutzung der Enterprise-Edition einzustellen. Odoo Online erlaubt keine eigenen Module und zerstört wie die übrige Odoo-Cloud eine gekündigte Datenbank nach drei Wochen. Stand 14. Oktober 2026.
Das Wichtigste
- Servercode der Community Edition: Repository odoo/odoo, Branch 20.0, Lizenz LGPLv3.
- Enterprise-Add-ons sind nur mit gültigem Abonnement für die richtige Benutzerzahl nutzbar; mit dem Vertragsende ist die Lizenz sofort widerrufen und die Nutzung einzustellen.
- Datenbank und Filestore liegen nur bei Ihnen, wenn Sie auf einem eigenen Server hosten; die Sicherung aus dem Datenbankmanager enthält beide. Das entscheidet die Betriebsart, nicht die Edition.
- OCA-Module bleiben auf eigenem Server und auf Odoo.sh bei einem Hoster- oder Partnerwechsel nutzbar, solange eine Modulversion für Ihre Odoo-Version vorliegt; neben Enterprise-Add-ons muss zusätzlich ihre Lizenz mit der Odoo-Enterprise-Lizenz vereinbar sein. Auf Odoo Online sind sie nicht nutzbar.
- Odoo Online erlaubt keine eigenen Module und keine Apps-Store-Module; die Apps-Store-FAQ lässt dort nur Datenmodule ohne Python-Dateien zu. Eine gekündigte Cloud-Datenbank wird nach drei Wochen zerstört.
- Die OCA ist eine unabhängige Vereinigung mit Sitz in der Schweiz; ihre Projekte stehen unter OSI-zertifizierten Lizenzen.
Ausstieg ist eine Eigenschaft der Installation, keine Entscheidung am letzten Tag. Wer weiß, wo der Code liegt, wie Datenbank und Dateien gesichert werden und welche Fristen der Vertrag nennt, kann den Betrieb auch ohne Anbietervertrag fortführen. Dieser Artikel ordnet die vier Betriebsarten nach diesen drei Schichten und liefert die Prüfpunkte.
Woran die Unabhängigkeit hängt
Drei Schichten entscheiden darüber, wie stark Sie an den Hersteller gebunden sind.
Der Code: Der Servercode der Community Edition liegt im Repository odoo/odoo; die Lizenzdatei im Branch 20.0 nennt die GNU LGPL Version 3. Das Enterprise-Repository enthält laut Dokumentation nur zusätzliche Add-ons, der Server bleibt der Community-Code. Diese Add-ons dürfen nur mit gültigem Abonnement für die richtige Benutzerzahl genutzt werden; mit dem Vertragsende ist die Lizenz sofort widerrufen, und die Vereinbarung verpflichtet zur Einstellung der Nutzung von Enterprise-Edition und Cloud-Plattform (Abschnitt 3). Ein technischer Stopp der Add-ons folgt aus der Vereinbarung nicht.
Die Datenbank: Odoo nutzt PostgreSQL. Auf einem eigenen Server liegen Datenbank und Dateispeicher (Filestore) bei Ihnen; die Sicherung aus dem Datenbankmanager ist eine ZIP-Datei mit Datenbank-Dump und Filestore. Ob das so ist, entscheidet die Betriebsart, nicht die Edition: Auf einem eigenen Server installieren Sie Community oder Enterprise (die Dokumentationsseite On-premise beschreibt den Wechsel von Community zu Enterprise auf demselben Server), auf der von Odoo betriebenen Cloud liegt die Datenbank bei Odoo.
Der Vertrag: Auf Odoo Online und Odoo.sh entscheidet der Vertrag, was nach dem Laufzeitende bleibt. Nach einer Kündigung bleibt die Kundendatenbank drei Wochen deaktiviert und wird danach zerstört (Datenschutzerklärung, Fassung 24. September 2026); Odoo gibt die Kopien auf Ihre Wahl zurück oder löscht sie, soweit keine gesetzliche Aufbewahrungspflicht entgegensteht (Abschnitt 6.5 Buchst. h).
Was je Betriebsart mitgeht
Die Tabelle ordnet die vier Betriebsarten den drei Schichten zu (Stand 14. Oktober 2026, Quellen im Verzeichnis).
| Betriebsart | Code | Datenbank und Sicherung | Wechsel |
|---|---|---|---|
| Community auf eigenem Server | Servercode im Repository odoo/odoo (ZIP oder Git), LGPLv3; eigene Module in Ihrer Hand | PostgreSQL und Filestore bei Ihnen; Sicherung aus dem Datenbankmanager als ZIP mit Filestore | Wechsel auf einen anderen eigenen Server über die Sicherung, nach Odoo.sh über den Import der Sicherung (dort ist ein Enterprise-Abonnementcode nötig), nach Odoo Online über ein Support-Ticket; Versionswechsel mit OpenUpgrade |
| Enterprise auf eigenem Server | Kern wie Community; Enterprise-Add-ons nur mit gültigem Abonnement, Lizenz mit dem Vertragsende sofort widerrufen | wie Community; die Datenbank meldet den Ablauf, wenn das Abonnement nicht erneuert wird | Upgrade-Dienst verlangt eine Kopie der Datenbank (Abschnitt 4.3); für einen Wechsel nach Odoo Online zuvor alle nicht standardmäßigen Apps entfernen; nach dem Laufzeitende ist die Nutzung der Enterprise-Add-ons einzustellen |
| Odoo.sh | Kern wie Community; eigene Module im eigenen GitHub-Repository der Plattform; Enterprise-Abonnementcode nötig | Odoo betreibt die Datenbank; automatische Sicherungen mit Dump, Filestore, Protokollen und Sitzungen | Download im Reiter Backups; nach On-Premise über die Wiederherstellung der Sicherung, nach Odoo Online über ein Support-Ticket |
| Odoo Online | keine eigenen Module und keine Apps-Store-Module (die Apps-Store-FAQ lässt dort nur Datenmodule ohne Python-Dateien zu); Anpassungen ohne eigenen Code über Odoo Studio | Odoo betreibt die Datenbank; Download Backup als ZIP-Datei, bei zu großen Datenbanken nur über den Support | Nach On-Premise über Download Backup und Wiederherstellung, nach Odoo.sh über den Import der Sicherung; ein laufendes Abonnement und zu große Sicherungen laufen über den Odoo-Support; Zwischenversionen zuerst auf die nächste Hauptversion heben |
Ausstiegs-Checkliste je Edition
Die Prüfpunkte folgen den drei Schichten Code, Datenbank und Exportformate; arbeiten Sie sie ab, solange der Zugriff besteht.
Community auf eigenem Server
- Code sichern: Version und Branch notieren, den Stand aus odoo/odoo holen und eigene Module in ein eigenes Repository legen; damit liegt der laufende Code bei Ihnen.
- Datenbank prüfen: Im Datenbankmanager (/web/database/manager) ‣ Backup das Format zip (includes filestore) wählen und die Sicherung auf einem getrennten Server wiederherstellen; dafür ist das Master-Passwort nötig. Für den laufenden Betrieb empfiehlt die Dokumentation tägliche Sicherungen auf einen entfernten Archivserver.
- Exportformate festlegen: Klären Sie je Bereich, welche Datei Sie ohne Odoo lesen können müssen (Listenansicht öffnen, Einträge markieren, Aktionen (Actions) ‣ Export; Format Excel Workbook (.xlsx) oder Plain Text (.csv)). Solche Exporte ergänzen die Sicherung, sie ersetzen sie nicht.
Enterprise auf eigenem Server oder auf Odoo.sh
- Code trennen: Kern (Community) und eigene Module gehören Ihnen. Die Lizenz der Enterprise-Add-ons ist mit dem Laufzeitende sofort widerrufen, ihre Nutzung ist einzustellen; halten Sie fest, welche Apps betroffen sind (Editionsübersicht).
- Frist beachten: Die Vereinbarung verlängert sich automatisch, wenn nicht mindestens 30 Tage vor Laufzeitende schriftlich gekündigt wird. Sichern Sie vorher; auf Odoo.sh hält der Projektserver nur einen Monat Sicherungen (sieben tägliche, vier wöchentliche), die drei monatlichen sind nur über den Support erreichbar.
- Übergang planen: Der Upgrade-Dienst verlangt bei Selbstbetrieb eine Kopie der Datenbank (Abschnitt 4.3). Für den Wechsel auf einen eigenen Server laden Sie die Sicherung herunter und stellen sie im Datenbankmanager wieder her; für den Weg nach Odoo Online müssen zuvor alle nicht standardmäßigen Apps entfernt werden und der Transfer läuft über ein Support-Ticket mit Abonnementnummer (Hosting wechseln).
Odoo Online
- Code prüfen: Eigene Module sind auf Odoo Online nicht möglich. Anpassungen entstehen über Odoo Studio in der Datenbank (Modul studio_customization) und lassen sich als ZIP-Datei exportieren (Studio im Überblick); prüfen Sie diesen Export, wenn Sie sie behalten wollen.
- Datenbank sichern: Regelmäßig über Download Backup eine ZIP-Datei mit einer Datenbanksicherung laden. Ist die Option deaktiviert, ist die Datenbank zu groß für den Datenbankmanager; dann geht der Download nur über den Odoo-Support. Nach einer Kündigung bleibt die Datenbank drei Wochen deaktiviert und wird danach zerstört.
- Wechselweg klären: Für den Umzug auf einen eigenen Server oder auf Odoo.sh brauchen Sie die Sicherung (Download Backup; ist die Option deaktiviert, geht der Download über den Odoo-Support). Eine Zwischenversion muss zuerst auf die nächste Hauptversion gehoben werden. Ist ein laufendes Abonnement mit der Datenbank verknüpft, ist laut Dokumentation der Abonnementtransfer über den Customer Service Manager oder den Odoo-Support zu regeln. Nach Odoo Online muss die Kopie ohne nicht standardmäßige Apps auskommen.
Die OCA als unabhängige Modulquelle
Die Odoo Community Association (OCA) beschreibt sich selbst (Startseite und FAQ, 14. Oktober 2026) als gemeinnützige Vereinigung mit Sitz in Lausanne, die eine Community für gegenseitige Unterstützung rund um Odoo bildet und nicht von Odoo S.A. kontrolliert wird. Ihre Kennzahlenübersicht nennt 20.000 Module und 1.600 Beitragende.
Für den Ausstieg zählt ihre Lizenzpolitik: Aufgenommen werden nur Projekte mit OSI-zertifizierten Lizenzen (empfohlen: AGPLv3, LGPLv3, GPLv3), und das Contributor License Agreement soll verhindern, dass eine Lizenz auf eine nicht OSI-konforme Lizenz umgestellt wird. Der Modulcode liegt in öffentlichen Repositorys und bleibt in Ihrer Reichweite; nutzbar bleibt er bei einem Wechsel von Hoster oder Partner auf dem eigenen Server und auf Odoo.sh, nicht auf Odoo Online.
Zwei Voraussetzungen entscheiden, ob solche Module für den Ausstieg tragen. Erstens eine Version für Ihre Odoo-Version: Ohne Quellcode für die Zielversion lässt sich eine Datenbank mit eigenen Modulen nicht upgraden. Zweitens, sobald Enterprise-Add-ons im Spiel sind, eine passende Modullizenz: Laut Lizenzseite der Dokumentation 20.0 dürfen Module nur zusammen mit der Enterprise-Edition genutzt werden, wenn ihre Lizenz mit der Odoo-Enterprise-Lizenz vereinbar ist; welche Lizenzen das im Einzelfall sind, sagt die Seite nicht. Prüfkriterien für fremde Module: Fremdmodule prüfen.
Typische Fehler
- Open Source mit kostenlos verwechselt: Der Community-Code ist frei; die Enterprise-Apps (Accounting, Studio, mobile Apps) stehen laut Editionsseite nur in der Enterprise-Spalte und dürfen ohne Abonnement nicht weiter genutzt werden.
- Ohne Frist geplant: Die Vereinbarung verlängert sich automatisch; gekündigt wird mindestens 30 Tage vor Laufzeitende. Auf der von Odoo betriebenen Cloud wird die Datenbank drei Wochen nach der Kündigung zerstört.
- Exportdatei für eine Sicherung gehalten: Der Export über Aktionen (Actions) ‣ Export liefert je Liste eine Excel- oder CSV-Datei; wiederherstellbar ist nur die Datenbanksicherung mit Filestore.
- Eigene Module ohne Versionspflege: Auf Odoo Online sind eigene Python-Module nicht zulässig, auf Odoo.sh und dem eigenen Server blockieren sie das Upgrade, bis eine passende Modulversion vorliegt.
- Zugang nicht in eigener Hand: Klären Sie, wer Administrator der Datenbank ist, wer das Master-Passwort kennt und wer das Odoo.sh-Repository verwaltet; fehlt ein Zugang, ist der Ausstieg nicht gesichert.
So gehen Sie vor
- Sortieren Sie die installierten Apps nach Edition; markieren Sie jede App, die ohne Abonnement nicht mehr genutzt werden darf.
- Halten Sie den Code: Version und Branch notieren, eigene Module in ein eigenes Repository, das Odoo.sh-Repository im eigenen Konto.
- Testen Sie die Wiederherstellung: Sicherung als ZIP mit Filestore auf einem getrennten Server einspielen und die Kernprozesse durchgehen. Den Ablauf beschreibt Datenbank exportieren und wiederherstellen.
- Prüfen Sie Fristen, Zugänge und Exportwege: Kündigungsfrist, Administratorrechte, Datenbankmanager und die Dateien, die Sie ohne Odoo lesen müssen (Datenexport und Archiv).
- Schalten Sie die alte Installation erst ab, wenn die neue geprüft ist; die Reihenfolge steht in der Hosting-Dokumentation.