Jusletter IT

Die Nutzer von Softwareprogrammen erhalten i.a.R. nur den sog. Objektcode, der zwar für Maschinen, nicht aber für Menschen verständlich ist. Für Fehlerbehebungen, Anpassungen oder Funktionserweiterungen benötigt man jedoch den Quellcode, der das in einer Programmiersprache verfasste Ergebnis des Softwareentwicklers darstellt. Wünscht der Softwarebezieher eine der eben genannten Änderungen an der von ihm bezogenen Software und ist der Softwarehersteller dazu nicht bereit, etwa weil er die Wartung der Software zugunsten der Entwicklung einer neuen Anwendung eingestellt hat¹ , so ist er hinsichtlich der Vornahme von Änderungen auf seine unabdingbaren Rechte in §§ 40d und 40e UrhG verwiesen.²

Nach diesen Bestimmungen darf sich der Softwarebezieher u.a. bestimmte Informationen über den Quellcode beschaffen und darüber hinaus insb. das Programm dekompilieren, d.h. nachträglich Quellcode auf der Basis von Objektcode gewinnen. Allerdings stehen diese Rechte unter den engen Beschränkungen der bestimmungsgemäßen Benutzung bzw. des Zwecks der Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen. Des Weiteren ist die Dekompilierung aufgrund technischer Probleme bei der Umsetzung mit einem sehr hohen Aufwand verbunden und deshalb i.a.R. wirtschaftlich untunlich. Abseits dieser Möglichkeit hat der Softwarebezieher mangels ausdrücklicher Vereinbarung i.d.R. keine Möglichkeit an den Quellcode zu gelangen, weil selbst im Rahmen eines Softwareerstellungsvertrags die Herausgabepflicht des Quellcodes keinen zwingenden Vertragsbestandteil darstellt und allenfalls nur aus dem Parteiwillen entstehen kann.³

Aufgrund der eben erörterten Rechtslage gebietet ein wirksames Risikomanagement auf Seiten des Softwarebeziehers, v.a.⁴ im Rahmen von Softwareerstellungsverträgen mit einem bestimmten Projektvolumen oder hinsichtlich systemkritischer Software, die Sicherstellung des Zugriffs auf den Quellcode in bestimmten Risikoszenarien, wie etwa der Insolvenz des Vertragspartners. Der Abschluss eines Softwarehinterlegungsvertrags, d.h. sog. Software Escrow Agreements, dient diesem Zweck der Sicherung der Investition in die Software.

Daneben stehen freilich auch andere Möglichkeiten zur Sicherung parat, etwa die Hinterlegung des Quellcodes in einem Bankschließfach⁵ oder gar in einem versiegelten Umschlag⁶ beim Softwarebezieher selbst. Diesen Hinterlegungsoptionen ist jedoch der Nachteil von Unsicherheiten im Bezug auf den genauen Inhalt des Hinterlegungsobjekts gemein. Auf dieses Hinterlegungsobjekt bzw. -objekte und die Anforderungen daran aus technischer Sicht wird im Anschluss unter Pkt. REF _Ref187654660 \r \h 3. noch ausführlich eingegangen.

Die folgende Darstellung listet Eckpunkte zu einer abgerundeten Vertragsgestaltung von Softwareüberlassungs- und -hinterlegungsverträgen bzw. Escrow Agreements auf, wobei an geeigneter Stelle insb. die Notwendigkeit der Berücksichtigung des Themas der Insolvenz des Softwareherstellers bei der Vertragsgestaltung erörtert wird.

Einen entscheidenden Punkt bei der Vertragsgestaltung hat die Synchronisierung⁷ von sachenrechtlicher Befugnis am Werkstück, bspw. der Software CD-Rom, und immaterialgüterrechtlicher Befugnis am Quellcode, d.h. etwa Werknutzungsrecht oder -bewilligung zur Fehlerbehebung bzw. Weiterentwicklung, zu bilden. In diesem Zusammenhang ist hervorzuheben, dass bloßes Eigentum an dem Ausdruck des Quellcodes oder dem Speichermedium, auf dem dieser dem Escrow Agent übertragen wurde, ohne die Befugnis, am Quellcode Änderungen vornehmen zu dürfen, keine Abhilfe für den eine Fehlerbehebung begehrenden Softwarebezieher schafft. In dieser Hinsicht ist darauf zu achten, dass die Vertragswerke aufeinander Bezug nehmen. Dabei bietet es sich insb. an, eine vertragliche Verpflichtung des Anbieters zum Abschluss eines Hinterlegungsvertrages mit dem Escrow Agent im Softwareüberlassungsvertrag vorzusehen.⁸

Der Softwareüberlassungsvertrag ist kein einheitlicher Vertragstypus. Bestand-, Kauf- und Werkvertrag sind je nach Vertragsinhalt in Erwägung zu ziehen. Die Bezeichnung des Vertrags als „Lizenzvertrag“, „Nutzungsüberlassung“, etc. ist insofern jedenfalls dann nicht maßgeblich, wenn ein mit ihr nicht in Einklang zu bringender Vertragsinhalt und eine auf diesen gerichtete Parteiabsicht festgestellt sind.⁹ In dieser Hinsicht judiziert der OGH in st.Rsp.¹⁰ , dass die dauerhafte Überlassung einer auf Datenträgern verkörperten fertigen Standardsoftware¹¹ gegen einmaliges Entgelt als Zielschuldverhältnis und näher als Kauf einzuordnen ist. Des Weiteren ist der Vertrag über die Lieferung einer bislang nicht existierenden, exakt auf die Bedürfnisse des Erwerbers zugeschnittenen Individualsoftware als Werkvertrag zu beurteilen.¹²

Wie anfangs erörtert, kommt es für die Einordnung des konkreten Vertrags auf dessen Inhalt und eine darauf gerichtete Parteiabsicht an. So hat der OGH in einer seiner jüngeren En.¹³ die Frage nach dem Vorliegen eines Ziel- oder eines Dauerschuldverhältnisses ausdrücklich offen gelassen, weil sich der „Lizenzgeber“ nach dem darin zu beurteilenden Ausgangssachverhalt ausdrücklich das Eigentum am Softwareprogramm, den entsprechenden Datenträgern und dem Hardware-Schutzmechanismus¹⁴ für dieses Programm vorbehalten und dem Lizenznehmer darüber hinaus sowohl die entgeltliche als auch unentgeltliche Verfügung über die Lizenzprogramme Dritten gegenüber untersagt hat. Bei einem solchen Vertragsinhalt wären sowohl Kaufvertrag als auch Bestandvertrag¹⁵ in Betracht zu ziehen.

Den Fall der Insolvenz des Softwareherstellers in Erinnerung rufend, würde bei der Einordnung als Bestandvertrag zwar § 24 Abs. 1 IO den Eintritt des Insolvenzverwalters in den Vertrag anordnen, ohne dabei ein außerordentliches Kündigungsrecht des Bestandgebers, d.h. grds. des Insolvenzverwalters, vorzusehen. Je nach Vertragsgestaltung könnten dem Insolvenzverwalter allerdings dennoch ordentliche Kündigungsrechte¹⁶ zustehen. Drängten bei einer Ausgestaltung als Dauerschuldverhältnis andere bspw. werkvertragliche Elemente, wie etwa Pflege, Wartung, etc., diejenige der Gebrauchsüberlassung der Software in den Hintergrund, so hätte es der Insolvenzverwalter entsprechend seines Wahlrechts zwischen Erfüllung und Rücktritt¹⁷ von nicht bzw. noch nicht vollständig erfüllten Verträgen gem. § 21 Abs. 1 IO ebenso in der Hand, derartige Verträge zu beenden. Nach den eben erörterten Modellen ist daher lediglich eine Softwareüberlassung in der Ausgestaltung eines zumindest von einer Partei bereits vollständig erfüllten Kauf- oder Werkvertrags uneingeschränkt als insolvenzfest anzusehen.

Ebenso wie beim Softwareüberlassungsvertrag gibt es auch beim -hinterlegungsvertrag keinen Standardvertragstypus. Im Software Escrow Agreement verpflichtet sich der Softwarehersteller dazu, den Quellcode sowie ggf. auch neuere Versionen davon oder Nachbesserungen, bei einem Escrow Agent zu hinterlegen, der diesen treuhänderisch übernimmt. In dieser Hinsicht findet sich regelmäßig eine Ausgestaltung des „Escrow Agreements“, schlicht des „Escrow“ oder des „Hinterlegungsvertrags“ als Drei-Parteien-Vertrag¹⁸ zwischen Softwarehersteller, Escrow Agent und Softwarebezieher. Als Escrow Agent kommen Notare oder Rechtsanwälte, v.a. aber spezialisierte Escrow-Dienstleister¹⁹ in Frage. Letzterer stellt v.a. die Ausfolgung des Quellcodes an den Softwarebezieher in den vertraglich festgelegten Herausgabefällen sicher.²⁰ Spezialisierte Escrow Agents kümmern sich darüber hinaus insb. noch um die technische Verifizierung²¹ des Quellcodes.

Neben der oben erörterten Synchronisierung mit dem Softwareüberlassungsvertrag, gilt es beim Hinterlegungsvertrag v.a. die Herausgabefälle hinreichend detailliert zu umschreiben. Als solche kommen die Insolvenz oder die Einstellung des Geschäftsbetriebs des Softwareherstellers, der Abbruch eines Software-Entwicklungsprojekts, die Kündigung von Softwarepflegeverträgen durch sog. End-of-Life-Schreiben²² , etc. in Frage.²³ Zu regeln sind ferner das Verfahren der Herausgabe des Quellcodes und insb. auch die Kostentragung für die Dienste des Escrow Agents. Bei der Konzipierung des Verfahrens ist einerseits daran zu denken, welche Unterlagen²⁴ oder sonstige Nachweise dem Escrow Agent im Herausgabefall vorzulegen sind. Andererseits wird es im Lichte einer ausgewogenen Vertragsgestaltung geboten sein, dem Softwarehersteller allfällige Widerspruchsmöglichkeiten gegen eine Herausgabe einzuräumen und entsprechende Informationspflichten vorzusehen.²⁵

Angesichts der Absenz eines einheitlichen Vertragstypus’ ist darüber hinaus darauf hinzuweisen, dass die Insolvenzfestigkeit von Software Escrow Agreements Probleme bereiten kann, insb. ob des Wahlrechts des Insolvenzverwalters gem. § 21 Abs. 1 IO bei Dauerschuldverhältnissen und dem Erlöschen von vom Schuldner erteilten Aufträgen mit der Eröffnung des Insolvenzverfahrens nach § 26 Abs. 1 IO. In der deutschen Lit.²⁶ wird dieses Problem bereits seit langem kontrovers diskutiert. Im Gegensatz dazu wird zwar das Thema „Software in der Insolvenz“ in der österreichischen Lehre²⁷ ausreichend behandelt. Zur Insolvenzfestigkeit von Hinterlegungsverträgen finden sich jedoch nur einzelne Stellungnahmen. So weisen Knyrim/Siegel/Autengruber²⁸ im Rahmen der Behandlung datenschutzrechtlicher Bedenken des Outsourcing lediglich darauf hin, dass die Insolvenzfestigkeit von Software Escrow Agreements nach der Österreichischen Rechtsordnung einer Klärung bedarf. Juri²⁹ hat sich bereits vor einiger Zeit zu diesem Thema geäußert. Für die Ausgestaltung der Hinterlegungsvereinbarung als zweiseitigem Vertrag zwischen Softwarehersteller und Hinterlegungsstelle, ist er davon ausgegangen, dass dieser Vertrag mit der treuhändigen Hinterlegung durch den Hersteller als voll erfüllt und damit insolvenzrechtlich unbedenklich anzusehen ist. Jaburek³⁰ geht dann von der Insolvenzfestigkeit des Hinterlegungsvertrags aus, wenn dieser nicht als Mietvertrag ausgestaltet, zum Zeitpunkt der Konkurseröffnung zumindest von einer Vertragspartei vollständig erfüllt worden ist und hinsichtlich möglicher anfechtungsrechtlich relevanter Bedenken keine Gläubiger benachteiligt, Vermögen verschleudert oder einzelne Gläubiger begünstigt.

Eine zusätzliche Lehre für die insolvenzfeste Ausgestaltung von Software Escrow Agreements ist aus den En. des OGH zur Quellcodeherausgabe³¹ und zur Insolvenzausstiegsklausel³² zu ziehen. Aus dem zutreffenderweise als schützenswert³³ anerkannten Interesse des Softwareherstellers am Quellcode, d.h. seinem Know-how, ist zu schießen, dass die Vereinbarung einer entsprechenden Herausgabepflicht ohne Vergütung durch den Softwarebezieher i.a.R.³⁴ als sittenwidrig i.S.v. § 879 ABGB einzustufen ist. Die zu einer Fehlerbehebung oder Anpassung der Software erforderlichen immaterialgüterrechtlichen Nutzungsrechte am Quellcode, d.h. ein entsprechendes umfassendes Werknutzungsrecht oder eine Werknutzungsbewilligung, sollten daher im Idealfall bereits im Rahmen des Softwareüberlassungsvertrags per insolvenzfestem Zielschuldverhältnis³⁵ erworben werden. Darüber hinaus sollte dieser Umstand i.S. der Synchronisierung mit dem Softwarehinterlegungsvertrag auch dort noch einmal festgehalten werden. Schließlich ist zu berücksichtigen, dass die Vereinbarung eines Rücktrittsrechts oder einer Vertragsauflösung für den Fall der Eröffnung eines Insolvenzverfahrens³⁶ über das Vermögen eines Vertragspartners nach § 25b Abs. 2 IO unzulässig ist. Aus diesem Grund hat die Vereinbarung einer Klausel über die Herausgabe des Quellcodes bei gleichzeitiger Vertragsbeendigung wegen der Eröffnung eines Insolvenzverfahrens über das Vermögen des Softwareherstellers zu unterbleiben.

Die technischen Herausforderungen im Hinblick auf die im Rahmen von Software Escrow Agreements zu hinterlegenden Objekte lassen sich in zwei Kernbereiche unterteilen: Vollständigkeit und Qualität der Hinterlegungsobjekte.

In den meisten Fällen von Hinterlegungen für Software wird nur der Quellcode hinterlegt. Ein Computerprogramm ist mehr als nur der Quellcode. Viel Arbeit steckt außerhalb des Quellcodes. Als Beispiele dafür sind Modelle für Codeerstellung, technische Dokumentationen, Entwicklungs- und Testumgebungen, Konfigurationen, verwendete Bibliotheken, Adaptionen und Konfigurationen von existierenden Systemen anzuführen. Ohne diese zusätzlichen Objekte hat der Quellcode nur einen sehr eingeschränkten Wert. Ohne Zusatzinformationen ist es nahezu unmöglich den Code zu verstehen, analysieren, verwenden oder zu ändern. Vor allem in technisch komplexeren System werden viele Aspekte der Geschäftslogik außerhalb des Quellcodes abgebildet, wie zum Beispiel in Konfigurationsdateien.

Die häufigsten Probleme im Zusammenhang mit der Quellcode-Hinterlegung ergeben sich aus der mangelnden Qualität der hinterlegten Objekte, welche sich v.a. in der Unvollständigkeit oder in einer veralteten Version des Quellcodes äußert. Bei der Softwareübergabe gibt es häufig Nachbesserungen und Fehlerbehebungen. Dabei werden neue Versionen des Objektcodes geliefert. Diese Verbesserungen werden aber meistens nicht bei dem hinterlegenden Quellcode nachgezogen. Dies führt dazu, dass gelieferter Objektcode und hinterlegter Quellcode nicht übereinstimmen. Häufig ist darüber hinaus der Quellcode an sich von mangelnder Qualität, wobei die fehlende Kommentierung und Einhaltung von Standards die effiziente Weiterverwendung des Codes verhindern.

Ein einfacher Ansatz kann ein Katalog von digitalen Objekten für die Hinterlegung sein. Dieser hat die notwendige Software, Dokumentation und die Informationen, die notwendig sind, um den Quellcode zu verstehen, und ausführbaren Maschinencode daraus zu erstellen, zu umfassen. Den zweiten Schritt bildet eine technische Überprüfung der Hinterlegung, wobei diese hinsichtlich der Vollständigkeit oder der Aktualität der Objekte leicht vorgenommen werden kann. Die objektive Bestimmung der Qualität der Objekte, d.h. Quellcode, Dokumentationen, etc., stellt jedoch aus technischer Sicht eine große Herausforderung dar. Durch die Bezugnahme auf den Standard SQuaRE³⁷ können hier allerdings Prüfungsverfahren in den Vertrag aufgenommen werden. Unterschieden wird in diesem Zusammenhang zwischen Standard-, Voll- und Maßverifikation von hinterlegtem Material. Die Standardverifikation umfasst die Überprüfung der Lesbarkeit des Materials und eine grobe Qualitätsüberprüfung des Materials, d.h. stichprobenartige Überprüfung von einzelnen Quellcode-Passagen. Bei einer Vollverifikation wird der hinterlegte Quellcode kompiliert und mit dem gelieferten Objektcode verglichen. Eine Maßverifikation beinhaltet darüber hinaus noch weiter gehende Überprüfungen des hinterlegten Materials, wie etwa die Verifikation gegen Standards oder Qualitätsprüfung der Dokumentation. Der Umfang einer Überprüfung ist abhängig von der Größe, Komplexität und wirtschaftlichen Bedeutung der Software individuell in dem jeweiligen Software Escrow Agreement festzulegen.

Durch den Erwerb von Software begibt man sich als Anwender zwingend in ein bestimmtes Abhängigkeitsverhältnis zum Softwarehersteller. Im kontemporären Wirtschaftsleben bildet Software oft einen integralen Bestandteil von Unternehmen, sei es ob ihres Einsatzes in einem systemkritischen Bereich, ihrer hohen Anschaffungskosten oder des nicht unmittelbar ins Auge fallenden Aufwands, welcher sich aus der Anpassung auf eine neue Software ergeben könnte, d.h. in erster Linie Mitarbeiterumschulung, Umstellung eines Betriebs oder gar der gesamten Unternehmenskultur. Software Escrow Agreements sollten daher v.a. auf Seiten des Softwarebeziehers im Rahmen dessen vertraglichen Risikomanagements Berücksichtigung finden, um solche Risiken einzudämmen. Um weiters den technischen Anforderungen an die Vollständigkeit der Hinterlegungsobjekte und die Codequalität gerecht zu werden, empfiehlt es sich, die Dienste eines spezialisierten Escrow-Anbieters in Anspruch zu nehmen. In diesem Zusammenhang sollten insb. der Umfang der Hinterlegungsobjekte und der Überprüfung, wie auch die genauen Überprüfungsmechanismen detailliert vertraglich festgelegt werden. Dies geschieht regelmäßig im Escrow Agreement, wobei i.S.d. oben erörterten Gesichtspunkte im Rahmen der Vertragsgestaltung auf die notwendige Synchronisierung mit dem Softwareüberlassungsvertrag besonders zu achten ist. Eine Hilfestellung für Software Escrows von der Auswahl eines solchen Instruments bis hin zur konkreten Vertragsgestaltung bietet der Escrowguide³⁸ des CEN³⁹ . Im Speziellen findet sich in dieser Ausgestaltungsrichtlinie auch eine Beschreibung von Standard- und zusätzlichen Herausgabeszenarien⁴⁰ . In diesem Zusammenhang ist darauf hinzuweisen, dass der Herausgabefall der Insolvenz des Softwareherstellers gewisse Escrow-Vertragskonstrukte auf eine Probe stellen könnte. Nach Kenntnisstand der Autoren war bislang noch kein österreichisches Gericht zur Beurteilung von Software Escrow Agreements berufen. Lediglich das BVA⁴¹ ist bereits damit konfrontiert worden.

Appl, C., Softwarevertrag: Vereinbarung der vorzeitigen Auflösung im Konkursfall des Lizenznehmers. In: MR, Heft 4, S. 211-216 (2010).

Jaburek, W., Handbuch der EDV-Verträge II³, Medien und Recht, Wien (2003).

Juri, H., Software im Konkurs. In: EDVuR, S. 120 ff. (1991).

Kast, C. R., Schneider, J., Siegel, V., Software Escrow. In: K&R, Heft 10, S. 446-452 (2006).

Kilian, W., Heussen, B. (Hrsg.), Computerrechts-Handbuch²⁹, C. H. Beck, München (2011).

Knyrim, R., Siegel, V., Autengruber, S., Datenschutz und Datenrettung beim Outsourcing. In: ecolex, Heft 5, S. 413-417 (2004).

Konecny, A., Das Insolvenzrechtsänderungsgesetz 2010. In: ZIK, Heft 3, S. 82-91 (2010).

Koziol, H., Bydlinski, P., Bollenberger, R. (Hrsg.), Kurzkommentar zum ABGB³, Springer, Wien (2010).

Leupold, A., Glossner, S. (Hrsg.), Münchener Anwaltshandbuch IT-Recht², C. H. Beck, München (2011).

Paulus, C., Der „Escrow Agent“- Eine konkursfeste Hinterlegungsmöglichkeit?. In: CR, S. 84 ff. (1994).

Siegel, V., Software-Escrow. In: IS, S. 403-406 (2005).

Staudegger, E., Software-Erstellung: Vertragstyp und Quellcodeherausgabe. In: JBl, S. 195 ff. (2006).

Staudegger, E., Insolvenzfestigkeit von Softwarelizenzen. In: JusIT, Heft 4, S. 137-138 (2009).

Thiele, C., Urheberrecht und Insolvenz - aktuelle Entwicklungen. In: Schweighofer, E., Geist, A., Staufer, I. (Hrsg.), Globale Sicherheit und proaktiver Staat - Die Rolle der Rechtsinformatik, Tagungsband des 13. Internationalen Rechtsinformatik-Symposions IRIS 2010, books@ocg.at (Band 266), S. 373-378 (2010).

Welker, A. M., Schmidt, P., Kündigung von Softwarepflegeverträgen durch sog. End-of-Life-Schreiben. In: CR, S. 873 ff. (2002).

Widhalm, K., Die Rechte des Urhebers, Masseverwalters und Dritten im Konkurs und Ausgleich des Werknutzungsberechtigten. In: ÖBl, 209 ff. (2001).

Wolf, E., Softwarelizenzvertrag und Konkurs. In: EDVuR, S. 132 ff. (1994).