Vor Jahren hatte ich bereits Blogs über Escrow Agreements geschrieben. Der Abschluss von Escrow Agreements (Hinterlegungsvereinbarungen über den Quellcode von Software) wird häufig von Auftraggebern mit dem Wunsch begründet, die Abhängigkeit von IT-Unternehmen zu mindern. Im Falle dessen, dass über das Vermögen des IT- Unternehmens die Insolvenz eröffnet werde oder das IT- Unternehmen aus anderen Gründen nicht mehr in der Lage sei, die Software zu pflegen (also zu aktualisieren) solle der Auftraggeber den dekompilierten Code der Software erhalten, gemeinsam mit den „Bearbeiternutzungsrechten“ an der Software.
I. Alte Gründe gegen Escrow Agreements
Die rechtliche Zulässigkeit solcher Vereinbarungen ist infolge von mehreren Entscheidungen des BGH hochgradig umstritten. Einer der wesentlichen Gründe für den Abschluss von Hinterlegungsvereinbarungen ist der Schutz des Auftraggebers vor Insolvenzen. Genau dieser Grund darf aber in der Hinterlegungsvereinbarung nicht als Bedingung genannt werden.
Im Normalfall würde für die Überlassung des Quellcodes der Software und die Übertragung der Bearbeiternutzungsrechte viel Geld vom Auftraggeber an den Auftragnehmer bezahlt werden müssen. (Nach Escrow-Agreement) aber: Die Herausgabe von Quellcode und Bearbeiternutzungsrechten erfolgt für den Auftraggeber kostenfrei. Und: Im Falle der Insolvenz des IT- Unternehmens liegt darin eine Benachteiligung der anderen Gläubiger.
Allein dieses Argument hat Hinterlegungsvereinbarungen in meinen Augen schon wertlos gemacht. Die Unternehmen, die die Hinterlegung durchführten, haben zwar immer argumentiert, dass es noch keine veröffentliche Entscheidung gibt, aus der sich ausdrücklich die Unwirksamkeit dieser Regelung einer Hinterlegungsvereinbarung ergibt; es gibt aber auch keine Gerichtsentscheidung, aus der sich das Gegenteil ableiten lässt. Und glauben Sie mir, wenn es eine solche Entscheidung gäbe, würde die von den Hinterlegungsstellen sofort angeführt werden.
Der zweite Punkt ist faktisch: Es gibt für den Sourcecode in Normalfall keine technische Dokumentation, der es „einem dritten, verständigen Programmierer erlauben“ würde, sich schnell in die Matrix der Software einzuarbeiten und diese weiterzuentwickeln. Es gibt zwar Programmiersprachen, die eine komplett getrennte technische Dokumentation entbehrlich machen, aber im Normalfall ist das nicht der Fall. Und da die meisten Techniker nicht die besten Chronisten ihrer eigenen Leistungen sind, lässt sich Software eben nicht einfach „so“ durch einen anderen Programmierer fortentwickeln.
II. Neue Regelungen für Escrow Agreements
Ein Unternehmen aus Süddeutschland, das auch die Zulassung von Autos durchführt, betätigt sich ebenfalls am Markt als Hinterlegungsstelle. Man hatte den Auftraggebern zusätzliche Dienste für die Hinterlegung angeboten, mittels derer für jedes neue Release die Software und die Qualität der Dokumentation geprüft werden sollte. Dies hatte zu viel Zwist geführt.
Nun sind mir aus unterschiedlichen Quellen neue Regelungen dieses Unternehmens für die Hinterlegung zugegangen, die ein völlig anderes Bild zeichnen.
1.) Keine Insolvenz als Hinterlegungsgrund
Die Eröffnung des Antrags auf Insolvenz über das Vermögen des IT- Unternehmens ist kein Grund mehr für die Herausgabe von Quellcode und Bearbeiternutzungsrechten. Das ist meines Erachtens auch richtig, weil das ohne weiteres zur Unwirksamkeit der Hinterlegungsvereinbarung geführt hätte.
2.) Mangelhafte Ausführung des Pflegevertrags
Als Grund für die Herausgabe wird jetzt sehr häufig (und nicht nur von dem süddeutschen Unternehmen) die mangelhafte Erfüllung „des Hauptvertrags“, also des Softwarepflege- oder Wartungsvertrags genannt.
Diese Formulierung würde ich in der Pauschalität nicht unterschreiben. Es müssen klare und messbare Fakten benannt werden, damit man weiß, worauf man sich einlässt. Also z.B. die Regelung darüber, dass die Software trotz Aufforderung des Auftraggebers über einen längeren Zeitraum nicht fortentwickelt und aktualisiert wurde; dass der Support trotz Aufforderung über einen längeren Zeitraum nicht funktioniert hat.
Zudem ist die Regelung in ihrer Pauschalität unter dem Stichwort der AGB rechtlichen Wirksamkeit angreifbar.
Nach dem deutschen Recht gilt, dass eine AGB Regelung so auszulegen ist, dass auch der ungünstige Fall abgedeckt sein soll. Sofern ein Unternehmen über einen längeren Zeitraum keine neuen Releases erstellt oder Support leistet, kann auch eine Insolvenz die Ursache für den Leistungsmangel sein. Mittels einer pauschalen „catch all“ Klausel, die alle Fälle der mangelnden Leistung durch das IT Unternehmen erfasst, hätte aber im Grunde doch wieder eine Regelung vereinbart, die die kostenlose Überlassung von Quellcode und Nutzungsrechten im Falle der Insolvenz bedingen würde.
3.) Überlassung welcher Rechte?
Auch interessant ist, dass die Nutzungsrechte zur Bearbeitung eigentlich gar nicht im Rahmen des Escrow Agreements überlassen werden, weil der Auftraggeber mit dem Vertrag nicht mehr erhält als er durch das Gesetz ohnehin schon hat. In den Hinterlegungsvereinbarung steht, dass der Auftraggeber die Rechte nach den §§ 69d, 69e UrhG erhält.
Das Urhebergesetz formuliert immer in einem Zweitakt, welche Verbietungsrechte dem Rechtsinhaber zustehen (§ 69c Nr.1 bis Nr. 4 UhrG). Ohne Zustimmung des Rechteinhabers darf man den Quellcode nicht bearbeiten (§ 69c Nr.2 UrhG).
Dann zeigt das Gesetz die Grenzen der Verbietungsrechte auf, in dem es formuliert, dass bestimmte Handlungen auch ohne Zustimmung (§ 69d UrhG) vorgenommen werden dürfen, bzw. überhaupt nicht verboten werden können. Die Anfertigung einer Sicherungskopie kann z.B. nicht einfach verboten werden, sondern ist dem Auftraggeber auch ohne Zustimmung des Rechteinhabers erlaubt.
Das Recht zur Bearbeitung des Quellcodes zu Zwecken der Fehlerkorrektur (also Bugfixing) ist samt Dekompilierung dann durch das Gesetz erlaubt (und muss nicht extra noch durch einen anderen Vertrag erkauft werden), wenn derjenige, der die Korrektur durchführt, berechtigter Nutzer ist (also das Programm gekauft hat) und keine andere Möglichkeit zur Fehlerkorrektur besteht.
Die Rechtsübertragung beinhaltet also nicht das Recht zur Weiterentwicklung, sondern nur das Bugfixing.
III. Kostenlose Übertragung als Gläubigerbenachteiligung
Denn wenn die Hinterlegungsvereinbarung dem Kunden nicht mehr gibt, als ihm schon nach dem Gesetz zustünde, entfällt das entscheidende Argument für die Unwirksamkeit der Hinterlegungsvereinbarung. Der Kunde bekommt durch den Vertrag eigentlich nur den Zugang zu dem dekompilierten Source. Und ob dies ausreichend ist, um die Hinterlegungsvereinbarung als unwirksam zu qualifizieren, wage ich zu bezweifeln.
IV Tipps
1.) Für IT- Unternehmen gelten nach wie vor mehrere Punkte:
a.) Die Herausgabe des Quellcodes muss an genaue und wenig interpretierbare Voraussetzungen geknüpft werden.
b.) Es muss nur die technische Dokumentation herausgegeben werden, die ohnehin schon erstellt wird und es dürfen keine gesonderten Kosten für die Erstellung des technischen Dokumentation verursacht werden.
b.) Es müssen Verbote über die Abwerbung und Beschäftigung von den Programmierern vereinbart werden. Im Normalfall sind Hinterlegungsvereinbarungen schon deshalb nicht viel wert, weil sich das Know-how zur Weiterführung der Software im Kopf der Programmierer befindet. Haben die Programmierer das IT- Unternehmens verlassen, ist das Sterben der Software vorgezeichnet. Deshalb aber begründet der Abschluss jeder Hinterlegungsvereinbarung für den Kunden auch immer zugleich die Begehrlichkeit, die Mitarbeiter des IT- Unternehmens abzuwerben und dann im zweiten Schritt von den Regelungen des Escrows Gebrauch zu machen.
2.) Aus der Perspektive des Kunden:
Gegen das Problem der mangelnden Insolvenzfestigkeit von Escrow Agreements gab und gibt es nur den Weg, eine Kaufoption mit dem IT- Unternehmen über die Übertragung der Bearbeiternutzungsrechte und des Quellcodes abzuschließen. Wird eine angemessene Summe für die Leistung vereinbart, sind diese Regelungen insolvenzfest. Die Escrow Agreements haben sehr lange versucht, diesen im Grunde einfachen Tatbestand zu umgehen und zu verschleiern.
Gegen das Problem der mangelhaften technischen Dokumentation des Quellcodes helfen nur Maßnahmen, die den sofortigen Weggang der beteiligten Programmierer verhindern, etwa in dem man mit anderen Kunden des IT- Unternehmens eine Auffanggesellschaft gründet, die den Zweck verfolgt, die Mitarbeiter des Unternehmens noch eine Weile zu beschäftigen. Das Problem an diesem Lösungsweg sind die Programmierer selbst. Falls die lieber für ein anderes Unternehmen arbeiten möchten, wird man deren Weggang nicht verhindern können.
