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.
2.) 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.
3.) 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.
4.) Abseits vertraglicher Regelungen hat der Kunde dann, wenn er die Software gekauft hat, ohnehin das Recht, Maßnahmen zur Erhaltung der Funktionsfähigkeit der Software vorzunehmen (§ 69d UrhG) und zu diesem Zweck nach freilich umstrittener Ansicht auch den Source zu dekompilieren. Diese Rechte können den Kunden aber nicht in Jubelstimmung versetzen, denn ohne technische Dokumentation steht ein neuer Programmierer vor dem Source wie ein normal Sterblicher heute in den Motorraum eines neuen Autos blickt. Software ist derart kompliziert aufgebaut, daß man ohne entsprechendes Know How einfach nicht weiß, wie sie funktioniert und wo man mit welchen Schritten ansetzen soll oder darf.
5.) 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 und 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.
