Zwischen Entwicklern und SW-Häusern gibt es viele Streitpunkte

SW-Entwickler arbeiten mit einem beträchtlichen Risiko

08.06.1990

Wenn Software-Entwickler schwere Fehler machen, führt das nicht nur zu katastrophalen Folgen für den Kunden. In vielen Fällen haftet der Entwickler selbst für den von ihm verursachten Schaden. Frank Koch* beantwortet im ersten Teil dieser zweiteiligen Serie die Frage, unter welchen Umständen Entwickler für Entwicklungsfehler haftbar gemacht werden können. Weitere Themen: Der Übergang vom freien zum festen Programmierer-Arbeitsverhältnis sowie die Frage, wann Auftraggeber und Entwickler Projekte vorzeitig abbrechen können.

Beschäftigungsverhältnisse kreativer Software-Entwickler entstehen oft aus Einzelaufträgen und bleiben nicht selten über längere Zeit ziemlich formlos. Im Alltagsgeschäft übersehen deshalb Auftraggeber und Entwickler vielfach, daß sie nach einer gewissen Beschäftigungszeit die "Schallmauer" zum festen Anstellungsverhältnis des Entwicklers durchbrehen. Dieser Übergang hat - auch rückwirkende - Folgen: Erweist sich ein Beschäftigungsverhältnis als feste Anstellung, ist der Mitarbeiter nicht mehr frei, Entwicklungsaufträge auch von Dritten anzunehmen. Andereseits muß der Arbeitgeber den Angestellten in der Rentenversicherung nachversichern und außerdem Lohnsteuer nachzahlen. Hier können schnell beträchtliche Summen zusammenkommen.

Beide Seiten haben deshalb Interesse daran, bestehende Beschäftigungsverhältnisse regelmäßig daraufhin zu überprüfen, ob sie sich de facto bereits zu einem festen Anstellungsverhältnis entwickelt haben. Das gilt insbesondere auch für den Entwickler, den bei einem "Hineinwachsen" in eine feste Anstellung auch Nachzahlungspflichten treffen. Er muß dann auf eigenes Risiko Erstattungsansprüche beim Arbeitgeber geltend machen.

Erschwert wird die Überprüfung der Beschäftigungsverhältnisse dadurch, daß übliche Kriterien für eine feste Anstellung wie etwa Weisungsgebundenheit oder feste Arbeitszeiten gerade in dem besonderen Aufgabenbereich von Programmentwicklern nicht immer zu festen Arbeitsverhältnissen führen müssen. Auch Projektvereinbarungen zwischen freien Mitarbeitern können vergleichbare Verpflichtungen auferlegen, so daß vielfach nur nach genauerer Prüfung der tatsächlich erbrachten Tätigkeiten ein Urteil gefallt werden kann. Sollen also mehrere Projekte nacheinander bearbeitet werden und der Programmentwickler seine Leistungsbereitschaft für einen gewissen Zeitraum zur Verfügung stellen, so ist rechtliche Uberprüfung und Absicherung der Vertragsbeziehung dringend zu empfehlen.

Software wird von Entwicklern oft mit besonderem Engagement konzipiert und realisiert. Sie sehen ihre Arbeitsergebnisse zuweilen als eigene Produkte, über die andere nicht einfach frei verfügen sollen. Deshalb zeigen sich häufig Widerstände, wenn eine Programmentwicklung abgebrochen werden soll, obwohl die Problemlösung möglicherweise eine "Pioniertat" ist. Mißmut entsteht auch, wenn ein Abbruch erfolgt, obwohl die Arbeiten kurz vor dem Abschluß stehen.

Als Grundsatz gilt hier: Der Auftraggeber wie auch der Arbeitgeber kann die von ihm vergütete Entwicklungsarbeit jederzeit durch Weisung unterbrechen oder durch andere Mitarbeiter beenden lassen. Der einzelne Entwickler hat keinen Anspruch darauf, ein bestimmtes Programm zu Ende zu entwickeln - weder mit Rechnermitteln des Arbeitgebers noch innerhalb der bezahlten Arbeitszeit. Der Arbeitgeber bleibt damit in seiner Entscheidung über die Fortsetzung oder Beendigung von Entwicklungsprojekten frei.

Eine außervertragliche Weiterentwicklung ist ohnehin unzulässig. Dieser Grundsatz gilt auch, wenn die Fortsetzung der Entwicklungsarbeit einen möglichen Erkenntnisfortschritt des Arbeitnehmers, des freien Entwicklers oder auch des Auftraggebers erbringen könnte. Bei einer Abbruchweisung muß der Auftrag- oder Arbeitnehmer umgehend Arbeitsunterlagen wie Entwicklungsdokumentationen und Datenträger herausgeben, sofern sie noch in seinem Besitz sind.

Der Rückruf von SW bereitet viele Probleme

Andere Bestimmungen gelten, wenn der Arbeitnehmer Programmentwicklungen in das Arbeitsverhältnis einbringt, etwa bei dem unbemerkten Übergang von freier Mitarbeit zu einer festen Anstellung. In diesen Fällen steht keineswegs immer fest, daß der Arbeitgeber über solche Entwicklungsprodukte ebenfalls uneingeschränkt verfügungsberechtigt ist.

Inwieweit sich der Angestellte eine eigene Weiterentwicklung vorbehalten hat und ob die Entwicklungsarbeiten jederzeit auf andere Arbeitnehmer übertragen werden dürfen, muß im Einzelfall sorgfältig geprüft werden. Da professionelle Entwickler häufig eigene Softwarekonstrukte oder Entwicklungsmethoden in ihre bezahlte Arbeit einbringen, ist diese Prüfung notwendig.

Wie aber ist die Rechtslage, wenn der Entwickler seine Arbeitsleistung bezüglich bestimmter Projekte verweigert?. Für eine solche Entscheidung kann es gute Gründe geben. Ausgeklammert werden soll hier der ohnehin eindeutige Fall, daß Entwickler den Auftrag erhalten, bei der Erstellung und Implementierung von Software Ausfuhr- oder sonstige Bestimmungen zu umgehen. Zweifellos kann kein Arbeitgeber vom Arbeitnehmer die Verletzung bestehender gesetzlicher Bestimmungen verlangen. Gleiches gilt natürlich in freien Auftragsverhältnissen.

Manche Entwicklungsaufträge können Programmierer aber auch vor gesetzlich nicht erfaßbare Gewissenskonflikte stellen. Zum Beispiel die Herstellung von Steuerungssoftware für Produktionsstätten, die im mediteranen Raum chemische Kampfstoffe herstellen. Kann der Entwickler in solchen Fällen seine weitere Arbeit am jeweiligen Projekt verweigern? Kann er die Nutzung und Exportierung erstellter Arbeitsprodukte untersagen?

Meist wird hier zunächst das Urheberrecht herangezogen. Paragraph 42 des entsprechenden Gesetzes erlaubt den Rückruf des Produktes, wenn dieses den Überzeugungen des Urheber-Mitarbeiters nicht mehr entspricht. Aus dreifachem Grund erscheint diese Anknüpfung aber nicht hilfreich: Zum einen muß der Arbeitnehmer auf eigenes Beweisrisiko darlegen, daß sein Produkt urheberrechtlich geschützt ist.

Nur dann kann das Rückrufsrecht aus dem Urheberrechtsgesetz greifen. Die Beweisführung ist in aller Regel mit teuren Sachverständigen-Gutachten und nicht selten auch mit Prozessen verbunden, so daß schon deswegen die meisten Arbeitnehmer vor einem solchen Rückruf zurückschrecken werden.

Weiter knüpft die hier angesprochene Rücknahme nicht eigentlich am Softwareprodukt selbst an, sondern an dessen Nutzung. Der Entwickler hält sein Programm nicht plötzlich für schlecht, er will vielmehr dessen Einsatz in bestimmten Anwendungsbereichen oder -gebieten verhindern. Solche Fallgruppen werden vom Rückrufsrecht nicht erfaßt.

Schließlich muß der Mitarbeiter im Falle eines Rückrufs den grundsätzlich nutzungsberechtigten Arbeitgeber für den Gewinnausfall entschädigen. Bei wirtschaftlich relevanten Aufträgen kann der Entwickler eine Zurücknahme meist überhaupt nicht finanzieren, bei unbedeutenden Aufträgen besteht hingegen in aller Regel kein Interesse an einem Rückruf. Das Urheberrecht ist also zur Lösung solcher Gewissenskonflikte weder geeignet noch vorgesehen.

Verboten: Unterlagen mit nach Hause nehmen

Wesentlich näher liegt eine Anknüpfung an das Arbeitsrecht. Im Rahmen bestehender arbeitsvertraglicher Verpflichtungen eines Mitarbeiters ist vom Arbeitgeber genau zu prüfen, ob ihm eine bestimmte Programmentwicklung zuzumuten ist. Beruft sich der Entwickler auf einen Gewissenskonflikt, so muß er sich die Frage gefallen lassen, ob dies nicht schon zum Zeitpunkt der Einstellung vorhersehbar war.

Das ist zweifellos der Fall, wenn sich der Betroffene bei einem Softwarehaus bewirbt und ihm mitgeteilt wird, daß auch für den militärischen Bereich produziert wird, etwa Software zur Simulation von Sonogrammen in U-Booten. Der Entwickler kann sich also nur dann auf einen Gewissenskonflikt berufen, wenn das Softwarehaus erst nach seiner Einstellung neue Tätigkeitsbereiche erschließt, mit denen zuvor nicht gerechnet werden konnte.

Hat der Arbeitgeber nicht die Möglichkeit, den Mitarbeiter an anderer Stelle im Betrieb zu beschäftigen, kann eine Arbeitsverweigerung eine personenbedingte Kündigung zur Folge haben. Der Arbeitgeber muß allerdings im Zweifelsfall beweisen daß diese Kündigung alle formalen Voraussetzungen erfüllt und inhaltlich berechtigt ist.

Bei Software-Entwicklungen im Anstellungsverhältnis stehen dem Arbeitgeber das Eigentum und alle Nutzungsrechte der Produkte zu. Diese an sich nicht überraschende Feststellung führt zu praktischen Konsequenzen, die gelegentlich übersehen werden. Wenn der Arbeitgeber Eigentümer jener Datenträger und Dokumentationen ist, mit denen der Programmierer arbeitet, so darf der Arbeitnehmer auch ohne besonderes Verbot keine Konzepte, Datenflußpläne und sonstige Unterlagen oder Datenträger mit nach Hause nehmen. Schon in der nicht ausdrücklich gestatteten Mitnahme kann eine Unterschlagung gesehen werden, auf die sich eine fristlose Kündigung stützen läßt. Dazu muß die Entwicklung noch nicht einmal geheimhaltungsbedürftiges betriebliches Wissen enthalten.

Dennoch ist die Rechtslage nicht immer so eindeutig, wie es nach diesen Ausführungen scheinen mag: Der Mitarbeiter muß im Einzelfall klären, welche Entwicklungen eigentlich dem Arbeitgeber zustehen.

Betriebsgeheimnisse müssen gewahrt bleiben

Kreiert der Programmierer zum Beispiel eine neue Methode für die Darstellung von Benutzeroberflächen oder entwickelt er eine automatisierte Form der Schnittstellenprüfung, so kann er dieses allgemeine "Herstellungswissen" nach Ende des Arbeitsverhältnisses als Teil seiner beruflichen Kenntnisse nutzen.

Ihm ist in aller Regel nur untersagt, Arbeitsprodukte aus dem Betrieb zu entfernen Ä und erst recht, diese dann selbst zu verwerten. Ebensowenig darf er Betriebsgeheimnisse Dritten zugänglich machen. Das Wissen zur Herstellung dieser Arbeitsprodukte bleibt ihm aber erhalten und kann von ihm selbst und auch vom neuen Arbeitgeber verwertet werden, wenn nicht besondere, zeitlich begrenzte Wettbewerbsverbote vereinbart wurden.

Schwierig ist im Einzelfall die genaue Abgrenzung zwischen spezifischen vom Arbeitgeber bezahlten Entwicklungen und nicht erfaßtem, vom Mitarbeiter frei verwertbaren Arbeitswissen. Rechtsberater, die hier in Anspruch genommen sind, müssen teilweise recht tief in die Software-Technologie einsteigen, um eingrenzen zu können, welches Wissen Arbeitnehmer auch außerbetrieblich verwerten dürfen.

Zur Abgrenzung kann man folgende Faustregel verwenden: Einzelne Produkte stehen grundsätzlich dem Arbeitgeber zu, methodisches Wissen hingegen kann der Arbeitnehmer frei benutzen und gewerblich verwerten. Ausnahmen sind spezielle Methoden die ausschließlich der Arbeitgebersphäre zuzuordnen sind, zum Beispiel bestimmte Testroutinen.

Software-Entwickler machen sich oft nur unzureichend klar, daß sie für alle Fehler ihrer Arbeit haften. Dies gilt auch für leichteste Fahrlässigkeiten. Wird nach einzelfallbezogener Prüfung eine Programmentwicklung als "gefahrgeneigte Arbeit" erkannt, so haftet der Arbeitnehmer zwar nicht für leichteste Fahrlässigkeit, wohl aber für leichte Fahrlässigkeit, und zwar anteilig neben dem Arbeitgeber. Leichteste Fahrlässigkeit liegt zum Beispiel bei reinen Flüchtigkeitsfehlern vor.

Die Entdeckung solcher Fehler kann allerdings selbst Teil einer dem Arbeitnehmer auferlegten besonderen Prüfpflicht sein. Unterläuft dem Mitarbeiter dann ein Flüchtigkeitsfehler, zum Beispiel beim Codieren, so löst dies allein noch keine Haftung aus. Haftbar ist der Entwickler erst, wenn er bestimmte Routineprüfungen nicht oder nur unvollständig ausführt. Hier liegt dann bereits eine mittlere Fahrlässigkeit vor.

Haftung bedeutet hier konkret, daß der Entwickler dem Arbeitgeber grundsätzlich allen aus einem fahrlässig oder gar vorsätzlich verursachten Fehler entstandenen Schaden ersetzen muß. Dies können auch an Kunden zu zahlende Vertragsstrafen oder ein Gewinnausfall bei einem verzögerten Software-Release im Rahmen eines Wartungsvertrages oder eines Entwicklungsprojektes sein.

Noch schwerwiegender wirkt sich mitunter ein zweiter Aspekt aus: Nach überwiegender Auffassung unterliegt Software der bisherigen deliktischen beziehungsweise der neuen gesetzlichen Produkthaftung. Geschädigte können sich mit entsprechenden Beweisen zunächst an das vertreibende Softwarehaus, daneben aber auch immer unmittelbar an den einzelnen Mitarbeiter halten. Der kann zum Beispiel belangt werden, wenn das Softwarehaus Konkurs anmeldet, eine zunehmend drohende Gefahr.

Erweist sich - unabhängig von wirtschaftlichen Größenordnungen - die Software-Entwicklung als ähnlich komplex wie die Produktion in einem Industriebetrieb, so nimmt die Rechtsprechung eine Beweislastumkehr zugunsten des Geschädigten vor. Dieses Verfahren muß auch der Angestellte des schadensersatzpflichtigen Unternehmens im gegen ihn persönlich gerichteten Haftungsprozeß über sich ergehen lassen. Kann er nicht nachweisen, daß ihn an dem durch seine Arbeit entstandenen Software-Fehler kein Verschulden trifft, so haftet er voll, sofern er bei seinem Softwarehaus keine Regreßansprüche geltend machen kann.

Dieser Entlastungsnachweis scheitert erfahrungsgemäß daran, daß der angestellte Programmentwickler keine ausreichenden Qualitätssicherungsmaßnahmen nachweisen kann. Freilich gibt es auch im Bereich des Software-Engineering durchaus erprobte Qualitätssicherungssysteme.

Gesichert wird von diesen Systemen aber immer nur die Übereinstimmung zwischen dem erstellten Programm und den vorgegebenen Spezifikationen. Kaum ein Softwarehaus prüft systematisch die angebotene Software auf das Vorhandensein personen- oder sachgefährdender Fehler.

Softwarehäuser wie auch deren Mitarbeiter müssen deshalb zwangsläufig in Beweisführungsnöte geraten. Dieses Defizit hat vor allem auf die Angestellten negative Auswirkungen. lhnen drohen bei Körperschäden aus Produktfehlern - zum Beispiel an computergesteuerten Insulindosier-Geräten - sogar strafrechtliche Folgen.

Deshalb können Entwickler auf der Basis einer nebenvertraglich geregelten Fürsorgepflicht des Arbeitgebers vom Softwarehaus die Einführung eines letztlich auch sie schützenden, gefährdungsbezogenen Qualitätssicherungssystems verlangen.