Überspringen und zum Inhalt gehen →

AGPL-Software

Einschätzung, ob es strategisch und rechtlich sinnvoll ist, eine Software auf Basis eines Open-Source-Produkts unter der GNU Affero General Public License (AGPL) anzubieten.

Lizenzkernpunkte der AGPL

PunktBeschreibung
NetzwerkpflichtAGPL verlangt, dass der vollständige Sourcecode auch bereitgestellt wird, wenn Nutzer über ein Netzwerk auf die Software zugreifen (SaaS, Webservice, API).
Weitergabe / InstallationJede Weitergabe an Dritte – z. B. Installation beim Kunden – aktiviert die Offenlegungspflicht für alle abgeleiteten Werke.
Abgeleitete WerkeJede Modifikation oder Erweiterung, die auf der AGPL-Software basiert und funktional eng gekoppelt ist, gilt als abgeleitet und muss offen gelegt werden.
Open Source bleibtKunden oder Nutzer dürfen die Software intern oder extern weitergeben, verändern oder selbst kommerziell nutzen, solange die AGPL eingehalten wird.

Pflichten bei Kundenbetrieb (On-Prem)

  • Sourcecode muss bereitgestellt werden, sobald der Kunde die Software installiert.
  • Vollständiger abgeleiteter Code, inklusive Build-Skripte, muss offenliegen.
  • Geheimhaltung des eigenen Codes ist nicht möglich, wenn er als abgeleitet gilt.
  • Nur interne Nutzung beim Kunden: Sourcecode muss dem Kunden zugänglich gemacht werden, nicht automatisch der ganzen Welt.
  • Kunden dürfen den Code selbst weitergeben oder verändern.

Pflichten bei SaaS / Netzwerkbetrieb

  • Jede Person, die über ein Netzwerk auf die Software zugreift, hat das Recht auf den vollständigen Sourcecode.
  • Typische SaaS-Anwendungen unter AGPL müssen den Sourcecode aktiv zur Verfügung stellen.
  • Alle Änderungen am Originalcode müssen ebenfalls offenliegen.

Risiken für das Unternehmen

RisikoBeschreibung
Verlust von Proprietärem CodeWenn eigene Erweiterungen als abgeleitet gelten, müssen sie offengelegt werden.
Rechtliche GrauzonenPlugins, Bibliotheken oder Microservices, die eng gekoppelt sind, könnten als abgeleitet gelten → Offenlegungspflicht.
VertriebseinschränkungKunden, die Exklusivität oder Geheimhaltung erwarten, könnten nicht bedient werden.

Chancen / erlaubte Geschäftsfelder

  • Kostenpflichtige Dienstleistungen
    Anpassung, Integration, Installation, Support, Wartung.
  • Verkauf der Software selbst
    Erlaubt, solange Sourcecode offengelegt wird.
  • Interne Nutzung oder Testversionen
    Problemlos, solange keine externen Nutzer Zugriff haben.

Strategische Optionen

  1. AGPL akzeptieren
    • Eigene Software wird teilweise offen.
    • Geeignet für Geschäftsmodelle, die Dienstleistungen über Code hinaus verkaufen.
  2. Dual-License / kommerzielle Lizenz erwerben
    • Proprietärer Code kann geheim bleiben.
    • Lizenzkosten fallen an.
  3. Alternative Lizenz / Produkt suchen
    • MIT/BSD/Apache → keine Offenlegungspflicht.
    • Proprietärer Vertrieb bleibt möglich.

Entscheidungsfaktoren für den Vertrieb

FaktorFragen zur Bewertung
GeschäftsmodellGeht es um Codeverkauf oder Service? Ist Offenlegung akzeptabel?
KundenanforderungenMüssen Kunden Exklusivität oder Geheimhaltung erwarten?
Technische ArchitekturSind eigene Erweiterungen klar getrennt oder eng gekoppelt an AGPL-Code?
Ressourcen / ComplianceKann Sourcecode formal korrekt bereitgestellt und dokumentiert werden?

Zusammenfassung / Empfehlung

  • AGPL zwingt zur Offenlegung aller abgeleiteten Arbeiten beim Kunden oder bei Netzwerkzugriff.
  • Verlust von Kontrolle über eigenen Code ist wahrscheinlich, wenn er eng an die AGPL-Software gekoppelt ist.
  • Verkauf möglich, aber nur als Dienstleistung oder unter klaren Bedingungen.
  • Option für Vertrieb: nur anbieten, wenn Offenlegung kein Problem ist oder eine Dual License verfügbar ist.
  • Vorsicht bei SaaS / API-Zugriff: Sourcecode muss aktiv verfügbar sein.