Software-Escrow: Quellcode-Hinterlegung richtig vereinbaren

Die neue Fachanwendung läuft seit zwei Jahren stabil, doch der Hersteller reagiert plötzlich nicht mehr auf Supportanfragen. Im Projektteam wächst die Sorge: Was passiert, wenn der Anbieter insolvent wird, die Wartung einstellt oder schlicht nicht mehr erreichbar ist? Wenn dein Unternehmen auf individuell entwickelte Software angewiesen ist, kann der fehlende Zugriff auf den Quellcode schnell zum Betriebsrisiko werden. Ein Software-Escrow kann dieses Risiko begrenzen, aber nur, wenn Hinterlegung, Herausgabe und Rechte sauber zusammenpassen.

Infografik zu Software-Escrow: Quellcode-Hinterlegung richtig vereinbaren (KI-generiert).

Was ein Software-Escrow tatsächlich absichert

Bei einem Software-Escrow hinterlegt der Hersteller oder Entwickler den Quellcode einer Software bei einem neutralen Treuhänder. Der Treuhänder verwahrt die Unterlagen und gibt sie nur heraus, wenn ein vertraglich definierter Herausgabefall eintritt. Typische Beteiligte sind:

• der Hersteller oder Entwicklungspartner als Hinterleger
• dein Unternehmen als Begünstigter
• ein neutraler Escrow-Agent als Treuhänder

Das Ziel ist nicht, dir während der normalen Vertragslaufzeit Zugriff auf den Quellcode zu verschaffen. Vielmehr sollst du handlungsfähig bleiben, wenn der Anbieter seine vertraglichen Pflichten dauerhaft nicht mehr erfüllen kann.

Ein Escrow ist besonders bei Individualsoftware sinnvoll. Das gilt auch für stark angepasste Standardsoftware, wenn die Anpassungen für Kernprozesse, Schnittstellen oder regulatorische Anforderungen entscheidend sind. Bei weit verbreiteter Standardsoftware ist die Hinterlegung dagegen oft weniger hilfreich. Dort kann die langfristige Verfügbarkeit eher durch einen Herstellerwechsel, eine Ersatzlösung oder marktübliche Wartungsangebote abgesichert werden.

Wichtig ist: Die bloße Hinterlegung einer Codekopie löst dein Problem noch nicht. Der Quellcode muss vollständig, aktuell und nutzbar sein. Außerdem brauchst du Rechte, ihn nach der Herausgabe verwenden, ändern und durch Dritte warten zu lassen.

Wann sich eine Escrow-Vereinbarung lohnt

Prüfe zuerst, wie abhängig dein Unternehmen von der Software und ihrem Anbieter ist. Je größer diese Abhängigkeit, desto eher gehört ein Escrow in die Vertragsverhandlung.

Besonders relevant ist die Vereinbarung in diesen Situationen:

• Die Software steuert geschäftskritische Prozesse, etwa Produktion, Logistik, Abrechnung oder Kundenportale.
• Es gibt nur einen Entwickler oder ein kleines Entwicklerteam mit begrenzter wirtschaftlicher Stabilität.
• Die Software ist stark individualisiert und kann nicht kurzfristig ersetzt werden.
• Der Vertrag läuft über viele Jahre oder die Anwendung soll langfristig betrieben werden.
• Der Hersteller betreibt die Software nicht nur, sondern entwickelt und wartet sie exklusiv.
• Schnittstellen, Datenmodelle oder Geschäftslogik sind kaum dokumentiert.
• Die Anwendung unterliegt besonderen Verfügbarkeits-, Nachweis- oder Compliance-Anforderungen.

Ein Escrow ersetzt jedoch kein professionelles Lieferantenmanagement. Wirtschaftliche Lage, Wartungsorganisation, Dokumentation, Know-how-Verteilung und Exit-Plan musst du unabhängig davon bewerten. Der Treuhandvertrag ist eine zusätzliche Absicherung für den Ausnahmefall.

Herausgabefälle präzise und nachweisbar formulieren

Der Kern eines Escrow-Vertrags sind die Herausgabefälle. Sie bestimmen, wann der Treuhänder den hinterlegten Bestand an dich ausliefern darf. Unklare Klauseln führen häufig dazu, dass der Treuhänder gerade im Krisenfall nicht entscheiden kann oder darf.

Die Insolvenz des Herstellers ist ein naheliegender Herausgabefall. Dennoch sollte die Klausel genauer unterscheiden: Reicht die Eröffnung eines Insolvenzverfahrens? Gilt auch die Abweisung mangels Masse? Was passiert bei einer drohenden Liquidation, einer dauerhaften Geschäftseinstellung oder dem Verkauf des Geschäftsbereichs?

Mindestens ebenso wichtig sind Leistungsstörungen ohne Insolvenz. Denn ein Anbieter kann wirtschaftlich bestehen, aber Wartung und Weiterentwicklung faktisch einstellen. Sinnvolle Herausgabefälle können sein:

• die endgültige Einstellung von Wartung, Support oder Fehlerbeseitigung
• eine erhebliche Pflichtverletzung, die trotz schriftlicher Fristsetzung nicht behoben wird
• die dauerhafte Nichterreichbarkeit des Herstellers
• die Einstellung des Produktgeschäfts oder der Weiterentwicklung
• der Verlust wesentlicher Nutzungsrechte des Herstellers, etwa bei fremden Komponenten
• die einvernehmliche Freigabe durch Hersteller und Kunde

Formuliere nicht nur den Anlass, sondern auch das Verfahren. Der Vertrag sollte festlegen, wer den Herausgabefall gegenüber dem Treuhänder erklärt, welche Nachweise erforderlich sind und welche Fristen gelten. Bei streitigen Fällen ist ein abgestuftes Verfahren sinnvoll: Der Treuhänder informiert den Hersteller über das Herausgabeverlangen und räumt ihm eine kurze Gelegenheit zur Stellungnahme ein. Bestreitet er den Fall, muss geregelt sein, ob der Treuhänder bis zu einer Einigung oder Entscheidung weiter verwahrt.

Achte darauf, dass ein angemessenes Prüfverfahren nicht zu einer faktischen Blockade wird. Wenn dein Betrieb von der Software abhängt, kann eine monatelange Auseinandersetzung über den Herausgabefall den Zweck des Escrow zunichtemachen.

Was in die Hinterlegung gehört

Der Begriff „Quellcode“ klingt eindeutig, ist es in der Praxis aber selten. Eine Anwendung lässt sich nur dann übernehmen, wenn alle notwendigen Bestandteile vorhanden und verständlich sind. Deshalb sollte der Hinterlegungsgegenstand in einer Anlage konkret beschrieben werden.

Zur Hinterlegung gehören typischerweise:

• vollständiger Quellcode der kundenspezifischen Software einschließlich Anpassungen
• Build- und Deployment-Skripte
• Konfigurationsdateien, soweit sie für die Wiederherstellung und den Betrieb erforderlich sind
• technische Systemdokumentation und Architekturunterlagen
• Datenbankmodelle, Migrationsskripte und Schnittstellenbeschreibungen
• Installations-, Betriebs- und Administrationshandbücher
• Testfälle, Testdatenkonzepte und Ergebnisse automatisierter Tests
• eine Stückliste aller eingesetzten Komponenten und Abhängigkeiten
• Angaben zu Entwicklungsumgebung, Versionen, Compiler, Bibliotheken und Werkzeugen
• Zugänge oder Verfahren zur Wiederherstellung technischer Schlüssel, soweit rechtlich und sicherheitlich zulässig

Bei cloudbasierten Anwendungen musst du zusätzlich prüfen, ob der Code allein genügt. Häufig sind Infrastrukturdefinitionen, Container-Konfigurationen, Automatisierungsskripte und Betriebsdokumentation unverzichtbar. Auch Datenexporte, Schnittstellenzugänge und Verfahren zur Datenübernahme können für deinen Exit entscheidend sein. Ein Escrow ersetzt dabei nicht automatisch die vertragliche Pflicht des Anbieters, deine Daten herauszugeben oder bei der Migration mitzuwirken.

Nicht in den Bestand gehören ohne Weiteres geheime Zugangsdaten produktiver Systeme. Für Passwörter, Zertifikate und Schlüsselmaterial braucht es ein separates Sicherheitskonzept. Der Treuhänder sollte keine unkontrollierbaren Zugriffsrechte auf deine Produktivumgebung erhalten.

Aktualität und technische Prüfung sind entscheidend

Ein einmal hinterlegter Stand ist bei aktiver Softwareentwicklung schnell überholt. Vereinbare deshalb feste Aktualisierungsanlässe. Geeignet sind etwa neue Releases, wesentliche Fehlerbehebungen, größere Architekturänderungen oder regelmäßige Hinterlegungen in definierten Abständen.

Außerdem sollte klar sein, wie die Hinterlegung erfolgt. Reine Dateiablagen reichen nicht immer aus. Besser ist ein nachvollziehbares Verfahren mit Versionierung, Prüfsummen und einem Übergabeprotokoll. Dieses Protokoll sollte dokumentieren, welchen Stand der Hersteller hinterlegt hat und wann dies geschah.

Noch wichtiger ist die Verifikation. Dabei prüft der Treuhänder oder ein beauftragter technischer Prüfer, ob sich der Bestand technisch verwenden lässt. Der Umfang kann unterschiedlich tief sein:

Prüfstufe	Inhalt	Nutzen
Formale Prüfung	Vollständigkeit der vereinbarten Dateien und Lesbarkeit der Datenträger	Erkennt fehlende oder beschädigte Lieferungen
Plausibilitätsprüfung	Prüfung von Verzeichnisstruktur, Dokumentation und Abhängigkeiten	Erhöht die Nachvollziehbarkeit
Build-Prüfung	Kompilieren oder Erzeugen eines lauffähigen Artefakts	Belegt, dass der Code grundsätzlich baubar ist
Wiederherstellungsprüfung	Installation und Testbetrieb in einer definierten Umgebung	Bietet die höchste praktische Sicherheit

Welche Prüfstufe angemessen ist, hängt von Kritikalität, Technologie und Kosten ab. Für eine geschäftskritische Individualsoftware sollte wenigstens nachvollziehbar sein, ob der hinterlegte Stand gebaut und technisch bereitgestellt werden kann. Lege auch fest, wer Prüfberichte erhält, wer Mängel beseitigt und bis wann eine Nachhinterlegung erfolgen muss.

Escrow schafft keine Rechte, die du nicht vereinbart hast

Der häufigste Vertragsfehler liegt nicht beim Treuhänder, sondern bei den Nutzungsrechten. Die Herausgabe des Quellcodes bedeutet nicht automatisch, dass du ihn bearbeiten oder einem anderen Dienstleister überlassen darfst. Urheberrechtliche Nutzungsrechte verbleiben grundsätzlich beim Rechteinhaber, soweit der Vertrag nichts Weitergehendes regelt.

Dein Hauptvertrag und der Escrow-Vertrag müssen daher aufeinander abgestimmt sein. Für den Herausgabefall benötigst du mindestens das Recht,

• die Software selbst weiter zu nutzen und zu betreiben
• den Quellcode zu speichern, zu vervielfältigen und in eigene Systeme zu überführen
• Fehler zu beheben und notwendige Anpassungen vorzunehmen
• einen qualifizierten Dritten mit Wartung, Fehlerbehebung und Weiterentwicklung zu beauftragen
• dafür den erforderlichen Code, die Dokumentation und technischen Unterlagen an diesen Dritten weiterzugeben

Diese Rechte sollten räumlich, zeitlich und inhaltlich ausreichend weit gefasst sein. Beschränke sie sinnvoll auf den Sicherungsfall und auf den Betrieb deiner eigenen Unternehmensprozesse. Der Hersteller wird regelmäßig verhindern wollen, dass du den Code frei vermarktest oder an Wettbewerber weitergibst. Das ist nachvollziehbar, darf aber die praktische Wartbarkeit nicht einschränken.

Prüfe auch Komponenten von Dritten. Open-Source-Bestandteile sind nicht automatisch problematisch, müssen aber korrekt identifiziert und lizenzkonform eingesetzt werden. Bei proprietären Fremdkomponenten kann es sein, dass der Hersteller dir keine Bearbeitungs- oder Weitergaberechte verschaffen kann. Hier brauchst du eine belastbare Regelung, welche Ersatzkomponenten zulässig sind und wer die Umstellung verantwortet.

Verantwortlichkeiten und Vertragsstruktur sauber ordnen

In der Praxis bestehen oft drei zusammenhängende Dokumente: der Entwicklungs- oder Lizenzvertrag, der Wartungs- und Supportvertrag sowie der Escrow-Vertrag. Widersprüche zwischen ihnen sind gefährlich. Definiere daher dieselben Begriffe für Software, Versionen, Dokumentation und Herausgabefälle.

Klärungsbedürftig sind insbesondere diese Punkte:

• Wer trägt die Kosten für Einrichtung, laufende Verwahrung und technische Prüfung?
• Wer muss aktualisierte Stände liefern und in welchem Turnus?
• Welche Folgen hat eine unvollständige oder fehlerhafte Hinterlegung?
• Wer wird über Aktualisierungen und Prüfergebnisse informiert?
• Wie werden vertrauliche Informationen beim Treuhänder geschützt?
• Was passiert mit dem Bestand nach Vertragsende?
• Welche Rechte gelten nach einer Herausgabe dauerhaft?

Ein Escrow sollte außerdem nicht dazu führen, dass sich der Hersteller aus seiner Wartungspflicht zurückzieht. Die Treuhandlösung ist eine Notfallvorsorge, keine Alternative zu vereinbarten Service Levels, Reaktionszeiten und Fehlerbehebungsprozessen.

So gehst du bei der Vertragsverhandlung vor

Beginne nicht mit dem Formular eines Treuhänders, sondern mit deiner Risikobewertung. Welche Funktionen dürfen nicht ausfallen? Wie lange könntest du ohne Herstellerunterstützung überbrücken? Wer könnte den Code im Ernstfall übernehmen? Diese Fragen bestimmen, wie tief die Hinterlegung und Prüfung gehen müssen.

Danach stimmst du Technik, Einkauf und Recht frühzeitig ab. Die Technik definiert den erforderlichen Hinterlegungsumfang. Einkauf bewertet Anbieterabhängigkeit und Kosten. Recht sorgt dafür, dass Herausgabefälle, Rechte und Vertragsbeziehungen wirksam ineinandergreifen.

Passende Seminare und Termine findest du bei uns auf cmt.de.

Am Ende sollte ein praktischer Notfalltest stehen: Könnte ein externer Dienstleister mit dem hinterlegten Bestand die Anwendung nachvollziehen, bauen und weiterbetreuen? Wenn diese Frage nicht klar mit „ja“ beantwortet werden kann, ist der Escrow zwar vertraglich vorhanden, erfüllt seinen Zweck aber noch nicht.