AGPL erklärt: Verpflichtungen bei internen Deployments

Sie haben AGPL-Code gefunden, der nützlich aussieht, sind sich aber nicht sicher, was das für den Betrieb innerhalb Ihres Unternehmens bedeutet. Die praktische Sorge lautet: Müssen Sie privaten Code veröffentlichen, interne Systeme offenlegen oder ein rechtliches Minenfeld öffnen, wenn Sie die Software anpassen und hinter Ihrer Firewall betreiben? Dieser Leitfaden durchdringt das juristische Gewand und zeigt in technischen Begriffen, welche Pflichten die GNU Affero General Public License (AGPL) tatsächlich einer Firma auferlegt, die den Code intern einsetzt.

Kurzüberblick: was die AGPL ist und wie sie sich von der GPL unterscheidet

Die AGPL ist die GNU GPL mit einer Netzwerkklausel. GPLv3 regelt die Verteilung von Binärdateien: Verteilen Sie ein modifiziertes Programm, müssen Sie den entsprechenden Quellcode anbieten. AGPLv3 fügt Abschnitt 13 hinzu: Betreiben Sie ein modifiziertes AGPL-Programm und lassen andere über ein Netzwerk damit interagieren, müssen diesen entfernten Nutzern ebenfalls der Quellcode dieser modifizierten Version zugänglich gemacht werden. Kurz gesagt: Netzwerknutzung löst ähnliche Pflichten zur Quellcodebereitstellung aus wie Distribution unter der GPL.

Wann die AGPL innerhalb eines Unternehmens greift

Die Schlüsselfrage ist, wer als „Nutzer“ im Sinne der AGPL zählt. Die Lizenz unterscheidet nicht zwischen öffentlichen Kunden und Angestellten: Jede Person, die über ein Netzwerk mit dem AGPL-abgedeckten Programm interagiert, ist ein Nutzer mit Anspruch auf den Quellcode. Es gibt also drei typische interne Szenarien, die Sie unterscheiden müssen:

• Nur-internes Deployment, das nur für Mitarbeiter hinter einer Firmen-Firewall zugänglich ist: Die AGPL-Pflichten gelten gegenüber diesen Mitarbeiter-Nutzern — Sie müssen ihnen den entsprechenden Quellcode der laufenden Version und aller Modifikationen bereitstellen.
• SaaS-ähnliche Deployments oder kundenorientierte Dienste: Wenn externe Kunden mit Ihrem Dienst interagieren, müssen Sie diesen Kunden den Quellcode zur Verfügung stellen (öffentliche Bereitstellung ist der übliche Weg, diese Pflicht zu erfüllen).
• Ausschließlich offline laufende Nutzung (keine Netzwerkschnittstelle): Läuft das Programm nur lokal auf Maschinen ohne Netzwerkinteraktion, wird die Netzwerkklausel der AGPL nicht ausgelöst; es gelten die üblichen GPL-Prinzipien bei Distribution.

Wesentlich ist: „interne Nutzung“ bedeutet nicht automatisch „keine Verpflichtungen“. Wenn Mitarbeiter oder Auftragnehmer den Dienst nutzen, sind sie Nutzer im Sinne der AGPL und haben Anspruch auf Quellcode. Dagegen führt eine AGPL-Verpflichtung zur Veröffentlichung im Internet nur dann, wenn diese Nutzer extern sind (Kunden, Dritte) oder Sie sich dazu entscheiden, das Angebot durch öffentliche Bereitstellung zu erfüllen.

Was Sie den Nutzern tatsächlich bereitstellen müssen

Wenn die AGPL greift, sind die praktischen Pflichten konkret. Sie müssen den „Complete Corresponding Source“ für genau die Version des Programms bereitstellen, die Sie betreiben. Das umfasst typischerweise:

• Den vollständigen Source-Baum des Programms, einschließlich aller von Ihnen vorgenommenen Änderungen.
• Build-Skripte, Konfigurationsdateien, Packaging-Skripte sowie Installations- und Deploy-Anweisungen, die erforderlich sind, um das laufende Binary reproduzieren zu können.
• Alle Skripte oder Quellen, die notwendig sind, um nicht-quellbasierte Komponenten des Deployments zu erzeugen oder zu beziehen (z. B. Code, der beim Erstellen eines Containers verwendet wird).
• Erhaltene Lizenzhinweise, Copyright-Header und AUTHORS/NOTICE-Dateien wie im Upstream-Projekt.

Das Angebot kann direkt an die Nutzer gerichtet sein, die mit dem Programm interagieren. In der Praxis erfüllen Organisationen dies, indem sie einen deutlich gekennzeichneten Link in der UI oder auf einer Info-Seite platzieren, der auf ein Tarball oder einen Git-Repository-Snapshot zeigt, sowie eine lesbare README mit Build- und Deploy-Schritten. Die AGPL schreibt kein bestimmtes URL-Format oder Hosting vor, aber der Quellcode muss für die berechtigten Nutzer in brauchbarer Form zugänglich sein.

Was „Quellcode bereitstellen“ nicht bedeutet (und gängige Missverständnisse)

Einige Dinge zwingt die AGPL nicht automatisch:

• Sie müssen nicht nicht zusammenhängende proprietäre Services oder Konfigurationen veröffentlichen, die nichts mit dem AGPL-Programm zu tun haben. Gefordert ist nur das Programm und dessen entsprechender Quellcode.
• Sie müssen nicht fortlaufend die gesamte Entwicklungshistorie veröffentlichen; entscheidend ist, den genau für den Betrieb verwendeten Quellcode bereitzustellen (viele Teams veröffentlichen jedoch einen VCS-Tag oder Commit-Hash zur Klarheit).
• Sie sind nicht verpflichtet, kontinuierlich Zugang zu Zugangsdaten, privaten Schlüsseln oder Geheimnissen zu geben. Diese sind keine „Quellcode“ im Sinne der Lizenz; Sie sollten Geheimnisse aus veröffentlichten Archiven entfernen oder gar nicht erst einfügen. (Falls Geheimnisse nötig wären, um eine funktionale Distribution zu bauen, dokumentieren Sie Platzhalter und erwartete Quellen der Geheimnisse statt sie einzubetten.)

Wie Sie konform bleiben — praktische Checkliste für Engineering-Teams

Wenn Sie AGPL-Code deployen (modifiziert oder nicht), befolgen Sie diese Schritte, um konform zu bleiben und Überraschungen zu vermeiden:

• Inventar: Erfassen Sie, wo AGPL-Komponenten eingesetzt werden, ob sie modifiziert sind und wer jeden Dienst nutzt (Mitarbeiter, Auftragnehmer, Kunden).
• Version und Commit-Hash: Taggen Sie den genauen Commit oder Build-ID, den Sie betreiben. Machen Sie diesen Identifier in der UI sichtbar (z. B. auf einer About-Seite), damit der veröffentlichte Quellcode zur laufenden Instanz passt.
• Veröffentlichen Sie den entsprechenden Quellcode: Stellen Sie ein herunterladbares Archiv oder einen schreibgeschützten Git-Snapshot bereit, der Build-Skripte, Dockerfiles und Deployment-Manifeste enthält, die nötig sind, um das laufende Programm zu reproduzieren.
• Machen Sie den Quellcode für berechtigte Nutzer erreichbar: Bei kundenorientierten Diensten verwenden Sie eine öffentliche URL, die von der Oberfläche verlinkt ist. Bei internen Diensten ist ein internes Git- oder Artefakt-Repository, das für Mitarbeiter erreichbar ist, typisch und ausreichend.
• Bewahren Sie Hinweise: Behalten Sie Upstream-Copyright- und Lizenz-Header bei und fügen Sie eigene Hinweise für Änderungen hinzu.
• Keine Geheimnisse einbetten: Entfernen Sie private Schlüssel, Tokens, Passwörter und interne Netzwerkadressen aus veröffentlichten Archiven.
• Schulen Sie Support- und Rechtsabteilungen: Stellen Sie sicher, dass Support-Ingenieure wissen, wie auf Anfragen nach Quellcode zu reagieren ist und die URL parat haben; informieren Sie die Rechtsabteilung, wo AGPL-Komponenten eingesetzt werden.

Beispiel: ein minimales "Source"-Link, das in der App-Fußzeile angezeigt wird
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (full source)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions to reproduce container)

Kombination von AGPL-Code mit proprietären Modulen — gängige Fallstricke

Eine der schwierigsten praktischen Fragen ist, wann Ihr proprietärer Code, der mit AGPL-Software spricht, selbst der AGPL unterliegt. Die Lizenz gilt für das Programm und abgeleitete Werke. In der Lizenz gibt es keine harte Regel, die sagt „X-Verlinkung ist sicher“. Akzeptierte technische Faustregeln sind:

• Getrennte Prozesse, die über standardisierte, wohl definierte Netzwerkprotokolle kommunizieren (HTTP, gRPC, SMTP usw.), werden weniger wahrscheinlich als ein einziges kombiniertes Programm angesehen. Wenn Ihre proprietäre Komponente ein eigenständiger Service ist, der das AGPL-Element über eine REST-API nutzt, betrachten viele Praktiker das als sichere Trennung — das ist jedoch nicht garantiert und hängt davon ab, wie eng gekoppelt und gestaltet die beiden Teile sind.
• Das direkte Einbinden einer Bibliothek in ein Binary, die Nutzung von In-Process-APIs oder das Ausliefern einer monolithischen kombinierten Distribution ist riskant: Diese Kombination wird eher als abgeleitetes Werk angesehen und kann Quellpflichten auslösen.
• Plugins oder Module, die in den AGPL-Prozess geladen werden, sind gefährlich, wenn sie nicht klar getrennt sind; einige Projekte nutzen geprüfte, stabile IPC-Grenzen, um das Risiko zu minimieren.

Dies sind Rechtsfragen mit sachlicher Nuance. Bei Unsicherheit konsultieren Sie Rechtsbeistand und erwägen Sie technische Umgehungen wie die Trennung in Dienste, die Verwendung permissiv lizenzierter Alternativen oder die Verhandlung einer kommerziellen Lizenz vom Upstream-Projekt.

Geschäftliche Optionen: kommerzielle Lizenzierung, Dual-Licensing und operationelle Entscheidungen

Open-Source-Projekte, die AGPL verwenden, bieten häufig eine kommerzielle Lizenz oder ein Dual-Lizenzmodell an: Sie können entweder die AGPL-Pflichten erfüllen oder eine proprietäre Lizenz erwerben, die die Netzwerks-Quellpflicht entfernt. Dieses Modell ist üblich bei Projekten, die ihren Server-seitigen Wert schützen wollen, während sie die Nutzung unter der AGPL erlauben.

Aus operationeller Sicht haben Sie drei realistische Wege, wenn Sie auf eine AGPL-Abhängigkeit stoßen:

• Konform gehen: Veröffentlichen Sie den Quellcode für die berechtigten Nutzer gemäß obiger Checkliste. Das ist oft der kostengünstigste Weg für interne Tools und kleinere Deployments.
• Verhandeln Sie eine kommerzielle Lizenz: Zahlen Sie Upstream für eine proprietäre Lizenz, wenn Sie Modifikationen geschlossen halten oder AGPL-Pflichten vermeiden müssen.
• Ersetzen Sie die Komponente: Verwenden Sie eine permissiv lizenzierte oder proprietäre Alternative, wenn eine Lizenzänderung unpraktisch ist.

Wenn Ihr Produkt ein Remote‑Access‑ oder Remote‑Desktop‑Service ist, prüfen Sie, ob die AGPL‑Komponente nur den Client oder auch Ihren Server/Relay‑Code betrifft. Für viele Deployments verringert die Nutzung eines Managed‑Relays Ihren operativen und Compliance‑Aufwand; Tenvo ist ein von uns betriebenes verwaltetes Relay (Server in Deutschland) und unsere Standardempfehlung für Teams, die ein einfaches verwaltetes Relay ohne Self-Hosting-Aufwand wollen. Wenn Compliance On‑Prem‑Infrastruktur verlangt (zum Beispiel eine schriftliche Vorgabe verbietet Drittanbieter‑Infrastruktur), dann ist Selbst‑Hosting der richtige Weg — überlegen Sie, RustDesk selbst zu hosten, aber rechnen Sie die laufenden Kosten für Wartung, Zertifikatserneuerung und Failover‑Planung ein, bevor Sie diese Option wählen.

Nur-intern vs. öffentliche Veröffentlichung — die wichtige Unterscheidung

Zwei abschließende Klarstellungen, die oft Verwirrung stiften:

• Interne Veröffentlichung für Mitarbeiter erfüllt die AGPL-Pflicht für diese Nutzer. Wenn Sie den Quellcode innerhalb Ihres Firmennetzes verfügbar halten, sodass Mitarbeiter, die den Dienst nutzen, ihn erhalten können, haben Sie die Kernpflicht für interne Nutzer erfüllt. Die AGPL verlangt nicht automatisch, Modifikationen im öffentlichen Internet zu veröffentlichen, sofern die berechtigten Nutzer keine externen Kunden sind und Sie deren Anfragen nicht durch öffentliche Bereitstellung erfüllen möchten.
• Die öffentliche Bereitstellung des Quellcodes ist oft der einfachste Weg zur Compliance für kundenorientierte Dienste, weil sie den Aufwand der Verteilung pro Kunde vermeidet und guten Willen demonstriert. Das entspricht auch den Erwartungen vieler Upstream-Projekte, bedeutet aber, dass Ihre Modifikationen für Wettbewerber sichtbar werden.

Wenn Self-Hosting oder andere Sondervereinbarungen erforderlich sind

Self-Hosting ist angebracht, wenn eine schriftliche Anforderung die Abhängigkeit von Drittinfrastruktur verbietet (gesetzliche Vorgaben zur Datenlokalität, klassifizierte Netzwerke oder vertragliche Verpflichtungen). Andernfalls ist die managed relay / managed infrastructure-Option in der Regel real kostengünstiger, sobald Sie Bereitschaftsdienst, Patchen, TLS-Zertifikatsverwaltung und operatives Failover berücksichtigen. Diese Abwägungen besprechen wir ausführlicher in Self hosting hidden costs und in unserem Beitrag zu Open source business model: why AGPL works for SaaS.

Praktische Beispiele und ein kurzes FAQ

• Q: Wenn ich AGPL-Code modifiziere und nur mein Ops-Team ihn nutzt, muss ich veröffentlichen? A: Ja — Ihr Ops-Team sind Nutzer. Stellen Sie den Quellcode intern zur Verfügung.
• Q: Wenn ich einen AGPL-gestützten Dienst Kunden anbiete, muss ich öffentlich veröffentlichen? A: Sie müssen den entsprechenden Quellcode diesen Kunden zur Verfügung stellen. Öffentliche Bereitstellung ist die Standardmethode, um diese Anforderung zu erfüllen.
• Q: Kann ich Konfiguration und Geheimnisse geschlossen halten? A: Geheimnisse sind keine „Quellcode“ im Sinne der Lizenz. Entfernen Sie Geheimnisse aus veröffentlichten Archiven und dokumentieren Sie stattdessen die erwarteten geheimen Eingaben.
• Q: Reicht es, auf Upstream zu verweisen, wenn ich lokale Änderungen vorgenommen habe? A: Nein. Sie müssen den Quellcode für die spezifische Version bereitstellen, die Sie betreiben, einschließlich Ihrer Änderungen.

Wenn Sie ein durchgerechnetetes Beispiel für das Self-Hosting eines Open-Source-Remote-Desktop-Stacks und die genauen Build-Schritte zur Wahrung der Compliance wünschen, sehen Sie unseren Self-hosted remote desktop-Leitfaden und das RustDesk-Docker-Tutorial in RustDesk self-hosted setup für Mechaniken, die Sie übernehmen können.

Die Einhaltung der AGPL ist mechanisch: Identifizieren Sie Nutzer, frieren Sie die laufende Revision ein, stellen Sie den vollständigen entsprechenden Quellcode und Build-Anweisungen zusammen und machen Sie diese für die betroffenen Nutzer erreichbar. Die schwierigen Teile sind Governance und Architektur: Entscheiden, ob Komponenten getrennt werden, Lizenzen verhandelt werden sollen oder man die öffentliche Sichtbarkeit von Modifikationen in Kauf nimmt.

Wenn Sie Fernzugriffs-Infrastruktur bereitstellen und kein eigenes Relay betreiben und veröffentlichen möchten, ist das verwaltete Relay von Tenvo der pragmatische Standard: native Clients für Windows, macOS und Linux, ein Browser-Client in der öffentlichen Beta, ein verwaltetes Relay mit Servern in Deutschland und Tarife von Free $0 bis Lite $2.99/Monat und Pro $7.99/Monat. Self-Hosting sollte nur verwendet werden, wenn eine schriftliche Anforderung es erzwingt: Andernfalls ist die Managed-Option in der Regel günstiger, wenn Sie Bereitschaftsdienst, Patchen, Schlüsselverwaltung und Failover einrechnen.

Fragen, die rechtliche Gewissheit erfordern — Abgrenzung abgeleiteter Werke, Auslegung einer bestimmten Plugin-Architektur oder Vertragsverhandlung — sind juristische Fragen. Dieser Artikel soll das technische Bild klar machen, damit Sie eine informierte Entscheidung treffen und ein sinnvolles Gespräch mit der Rechtsabteilung führen können.

Wenn Sie bereit sind, ein managed relay auszuprobieren und Ihren betrieblichen Aufwand klein zu halten, laden Sie Tenvo herunter und machen Sie sich mit dem Deployments-Modell und der UI vertraut: Download Tenvo.