Zwei jüngere Entscheidungen des BGH (BGH CR 12,572 – M2Trade; BGH CR 12, 575 Take Five) haben einmal Fragen zu dem Schicksal von Softwarelizenzen im Moment der Insolvenz des Lizenzgebers aufgeworfen. Der BGH hat in diesen Entscheidungen dem Prinzip des Skuzessionsschutzes Vorrang vor den Interessen des Insolvenzverwalters gegeben. Es ging um einen Lizenzerwerb in einem Streckengeschäft. Wer Lizenzen von einem Händler erworben hat, soll die Lizenzen auch dann behalten dürfen, wenn der Vertrag zwischen dem Softwarehändler und dem Hersteller infolge der Insolvenz des Händlers ausgesprochen wurde. Diese Entscheidungen werden derzeit in mehreren juristischen Publikationen besprochen.

Dazu zweierlei: Erstens ist mir derzeit noch nicht klar, wie diese Entscheidungen im Lichte der Entscheidung Oracle /Usedsoft zu sehen sind. In diesen Entscheidungen hat der EUGH klargestellt, daß es einen eigenen Vertragstyp “Softwarelizenzvertrag” nicht gibt, sondern Software wie jedes andere Gut verkauft, verschenkt, vermietet oder verliehen werden könne. Im Markt befinden sich aber noch immer viele Verträge, in denen die Nutzungsrechte an der Software zwar zeitlich unbeschränkt gegen eine Einmalzahlung überlassen werden (also verkauft werden), die Lizenzbestimmungen aber vorsehen, daß eine Verletzung der Lizenzbestimmungen zum Fortfall der Lizenz führen kann. Das ist insofern relevant, als er § 103 INSO (Insolvenzordung) dem Insolvenzverwalter nur dann ein Kündigungsrecht einräumt, wenn der Vertrag noch nicht vollständig erfüllt ist. Durch die Klarstellung in der Entscheidung des EUGH könnte sich jetzt auch eine andere Betrachtung der Interpretation des § 103 InSO ergeben, insofern der Softwarelizenzvertrag, der in Wirklichkeit ein Kaufvertrag ist, schon unter dengleichen Voraussetzungen erfüllt ist wie ein Kaufvertrag. Folge für den Kunden, der eine Lizenz von einem Händler erworben hat: Er darf die Software ohne weitere Zahlung weiterhin nutzen.

Zudem betont der BGH an einer Vielzahl von Stellen, daß die Entscheidung unter Berücksichtung der Umstände des Einzelfalls gefällt wurde. Dies deutet für mich darauf hin, daß den Entscheidungen genau keine generelle Richtung zu entnehmen ist.

II:  Tipps für den Auftraggeber zur Absicherung der Risiken infolge der Insolvenz .

1.) Auftraggeber sind für den Fall der Insolvenz des Herstellers immer dem Risiko ausgesetzt, daß die Software sich als Fehlinvestition erweist. Software weist die Besonderheit auf, schnell zu veralten. Nicht der Softwarecode selbst, sondern die technische Systemumgebung und die faktischen Anforderungen selbst ändern sich und zwingen den Kunden dazu, sich mit dem Erfordernis der permanenten Anpassung der Insolvenz zu befassen. Das zweite Risiko – nämlich das Risiko, daß die Nutzungsrechte im Falle der Insolvenz des Herstellers verfallen und der Kunde gezwungen ist, diegleichen Nutzungsrechte noch einmal vom Insolvenzverwalter teuer erwerben zu dürfen – bewerte ich als niedriger. Die Entscheidungen M2Trade und TakeFive des BGHs, mehr aber noch die Entscheidung des EUGHs Oracle/Usedsoft weisen daraufhin, daß auch im Falle des Direkterwerbs der Lizenz vom Hersteller keine Gefahr droht, das Nutzungsrecht zu verlieren, wenn die zeitlich unbegrenzten Nutzungsrechte an der Software übertragen wurden, die Software ausgeliefert wurde und der Kaufpreis bezahlt ist. In diesem Fall gehen zwar Gewährleistungsrechte des Kunden  verloren (der Insolvenzverwalter wird diese Ansprüche nicht erfüllen), der Kunde kann die gelieferte Software aber weiter nutzen.

Weniger gut sieht es mit der Frage aus, in welchem Umfang die Software eigentlich “repariert” und an die sich ändernde Umgebung angepasst werden kann. Juristen versuchen hier häufig mit sogenannten “Escrow Agreements” (also Hinterlegungsvereinbarungen) über Software zu helfen. Diese Verträge sehen vor, daß bei einer Hinterlegungsstelle der Sourcecode der Software hinterlegt wird. Der Kunde erhält für den Fall des Eintritts der Insolvenz des Herstellers das Recht, den Sourcecode zu erhalten, ihm werden bearbeiter Nutzungsrechte an dem Source übertragen und er darf auch den Source einsehen und erhält auch die vorhandene technische Dokumentation. Ich halte von diesen Verträgen nichts. Ihre Wirksamkeit ist rechtlich hochgradig umstritten. Nach dem Insolvenzrecht kann ein Insolvenzverwalter jede Rechtshandlung anfechten, die einem Gläubiger für den Fall der Insolvenz des Schuldners bessere Rechte ohne angemessene Gegenleistung einräumt. Falls Sie Zweifel haben: Würde ein Softwarehersteller ohne weitere Zahlung den Code an der Software samt Bearbeiternutzungsrechten und Einsichtsrechten übertragen oder dafür Geld verlangen. Und falls Sie jetzt diskutieren wollen: Ein Insolvenzverwalter, der diese Frage verneint und der Hinterlegung nicht zustimmt, geht eben genau nicht in Haftung nach § 60 InSO, da viele Juristen die Anfechtbarkeit solcher Vereinbarungen bejahen und zudem jegliche Rechtsprechung fehlt, die die Wirksamkeit der Escrows bestätigt. Damit steht der Kunde, der es mit der Pflege und Fortentwicklung der Software eilig hat, vor einem Insolvenzverwalter, der Zeit und Muße hat, sich verklagen zu lassen. Diesen Interessenkonflikt lösen Insolvenzverwalter und Kunde meist durch Abschluß eines Vergleichsvertrags. Und glauben Sie mir bitte – da ich aus der Insolvenzverwaltung komme – weiß ich, daß Insolvenzverwalter gute Taktiker sind.

Zum anderen sind auch die technischen Schwierigkeiten eines Escrows samt der verbundenen Kosten zu berücksichtigen. Denn: Der Source muß eine ausreichende technische Dokumentation aufweisen. Mit anderen Worten: Der Entwickler und der Softwaredesigner müssen ausreichend umfassend und verständlich erklärt haben, was sie sich bei der Entwicklung des Programms jeweils gedacht haben. Und dies nicht für die erstmalig überlassene Software sondern auch für die weiteren Releases, die der Kunde im Rahmen von Support und Softwarepflegeverträgen erhält. Die damit einhergehenden Kosten sind hoch. Um zu kontrollieren, ob die technische Dokumentation gut ist, müssten Sie einen Sachverständigen einschalten, der für jedes einzelne Release prüft, ob die genannten Vorgaben eingehalten sind. Denn falls der Code über keine ausreichende Dokumentation verfügt ist es besser, die Software neu entwickeln zu lassen.  Wenn man sich überlegt, daß manche Software über mehrere Millionen Zeilen Code verfügt und Software heutzutage oft objektbezogen entwickelt wird (dh. mittels Software, die ihrerseits Softwarecode erzeugt) kann man die finanziellen und organisatorischen Anforderungen erahnen.

Mein praktischer Tipp deshalb: Sparen Sie sich das Geld für einen Escrow. Im Falle der Insolvenz gibt es – falls die Programmierer noch vorhanden sind – eine sehr gute Möglichkeit, den Insolvenzverwalter des Softwareunternehmens anzusprechen und ihm die schnelle Gründung einer Auffanggesellschaft schmackhaft zu machen. Insolvenzverwalter wollen ihre Reputation bei Gericht immer durch Unternehmensfortführungen und den Erhalt von Arbeitsplätzen verbessern. Das Know How der Entwickler und Designer des Softwarecodes, der in ihrem Unternehmen verwendet wird, lässt sich Escrow Agreements nur sehr schlecht übertragen. Also versuche man so schnell wie möglich eine Liste mit den Kunden des insolventen Unternehmens zu erstellen, rufe diese an, frage ob sich diese an der Finanzierung einer Auffanggesellschaft und deren Betrieb beteiligen. Die Zeitspanne muß nicht unermesslich sein, sondern durch die Auswahl und Installation einer neuen Lösung begrenzt werden.