Softwareentwicklung

Als Hersteller oder Vertreiber von Software benötigen wir rechtssichere Lizenzverträge. Nachdem das Gesetz tendenziell den Urheber bevorteilt, gilt dies noch stärker für den Einkäufer oder Auftraggeber von Software. Wir wollen nachfolgend beide Positionen beleuchten.

Beispielsfall: Das Internet Startupunternehmen A (hier Auftraggeber) beauftragt die Softwareschmiede S mit der Programmierung eines Internetportals. Die Software soll einerseits aus dem im Internet zugänglichen Frontend bestehen, mit dem die Nutzer sich für eine ganz neuartige Community anmelden und kostenlose Dienstleistungen oder Premiumdienstleistungen in Anspruch nehmen können. Auf der anderen Seite steht ein Backend, was die Abrechnung der Nutzergebühren vornimmt und über einen geschlossenen Zugang für den Auftraggeber die Administration des Systems ermöglicht.

Die Arbeit besteht aus zahlreichen html/php-Seiten, Stylesheets, kleinen Programmen in Javascript, SQL-Queries innerhalb des php-codes, einigen Flashanwendungen und im Hintergrund eine MySQL-Datenbank. Nebenbei übernahm S das Webposting und richtete später einen gemieteten Linuxserver bei einem Großprovider ein und übernahm die Administration.

Diese oder eine ähnliche Ausgangslage ist für uns IT-Anwälte eine typische Vorgeschichte für spätere Rechtsstreits. In den meisten Fällen wurden die Verträge nicht durch spezialisierte Anwälte ausgearbeitet und verhandelt. In manchen Fällen gab es nur ausgetauschte e-Mails, bestenfalls einen gemeinsam erarbeiteten Katalog oder eine Auftragsbestätigung mit Stichworten zum Inhalt. Gelegentlich hat der eine oder andere Vertragspartner einen Mustervertrag im Internet gefunden und geringfügig angepasst.

In enger Anwendung von Murphy's Law soll nun alles schiefgehen, was schiefgehen kann:

1. Fristen für Fertigstellung und Zahlungen

Für A wird bald erkennbar, dass die vereinbarten Fristen von S nicht eingehalten werden. Der ehrgeizige Projektplan ist längst Makulatur. S räumt dies offen ein, schiebt die Verantwortung jedoch auf A, da es so viele Sonderwünsche und Absprachen gab. A habe die notwendigen Entscheidungen nicht rechtzeitig getroffen und überhaupt nicht richtig mitgearbeitet.

A ist nun auch nicht mehr bereit, die vereinbarten Abschlagszahlungen zu leisten, da man ohnehin schon vielmehr bezahlt habe als zur Verfügung gestellt wurde.

2. Anforderungen an Vertragserstellung

Zwar kommen die Parteien bei größeren Projekten häufig selbst auf die Idee, Fertigstellungsdaten zu vereinbaren, es fehlt jedoch an Regelungen für den Umgang mit Verzug und deren Folgen. Das Gesetz enthält nur allgemeine Regelungen. Wer sich schuldhaft in Verzug befindet, muss den daraus entstehenden Schaden bezahlen (§§ 286 ff BGB). Mangels mehrerer Regelungen wird man nun trefflich darüber streiten, ob tatsächlich verschuldeter Verzug eingetreten ist und welchen Wert der eingetretene Schaden hat.

Aus Sicht des Auftraggebers ist es erforderlich, möglichst genau zu beschreiben, welcher Funktionsumfang zu welchem Zeitpunkt gegeben sein muss. Um den Einwand des Lieferanten, der Auftraggeber habe nicht ordnungsgemäß mitgewirkt, abzuwehren, sollte der Auftraggeber auf eine Regelung bestehen, wonach Mitwirkungspflichten schriftlich eingefordert werden müssen und der Auftragnehmer verpflichtet wird, schriftlich anzuzeigen, wenn ein Fertigstellungszeitpunkt mangels Mitwirkung nicht eingehalten werden kann. Mit einer solchen Regelung wird es dem Auftragnehmer erheblich erschwert, die Verantwortung für die Verzögerung auf den Auftraggeber zu verschieben.

Der Auftragnehmer sollte sich nach Möglichkeit gar nicht auf feste Fertigstellungstermine festlegen lassen. Falls dies doch unvermeidbar ist, sollte er vorher eine Klausel vereinbaren, wonach vor Eintritt von Verzug unter Geltendmachung von Ansprüchen durch den Auftraggeber ausreichende Nachfristen gesetzt werden. Hierdurch lassen sich Fertigstellungstermine erheblich verlängern. Der Auftragnehmer sorgt dafür, dass eine Vielzahl von Fällen aufgelistet werden, durch die die Terminplanung aufgehoben wird, beispielsweise die Vereinbarung von Sonderleistungen durch den Auftraggeber oder jegliche Verzögerungen bei Absprachen, idealer Weise auch Fälle, die eigentlich im Risiko des Auftragnehmers liegen, wie beispielsweise Krankheit von Mitarbeitern.

Hinsichtlich der Vergütung muss eine Abhängigkeit zum geleisteten Ergebnis bestehen. Bei kleinen Projekten kann es ausreichen, eine Anzahlung bei Auftragserteilung und eine Restzahlung bei Abnahme zu vereinbaren. Auftragnehmer wünschen sich stattdessen möglichst viele Abschlagszahlungen, die idealer Weise nach einem festen Zeitplan fällig werden.

Auftragnehmer sollten vereinbaren, dass sie bei Nichtleistung einer Abschlagszahlung die Arbeiten vollständig einstellen dürfen und natürlich dann sämtliche Zeitpläne hinfällig werden. Dies soll aus Sicht des Auftragnehmers auch dann gelten, wenn Mängel der Software bereits erkennbar werden.

Der Auftraggeber hingegen wird auf Regelungen dringen, wonach er am Besten erst nach vollständiger Abnahme und Mängelbeseitigung bezahlen muss. Die Bezahlung stellt ein wichtiges Mittel dar, den Auftragnehmer unter Druck zu setzen. Bei IT-Entwicklung beobachtet man zunehmend eine im Baubereich verbreitete Unsitte, wonach der Kunde nur bis zur Zahlung der vorletzten Rate zufriedengestellt wird; ist einmal der Großteil des Honorars bezahlt, kümmert man sich lieber um neue Kunden, statt aufwendiges Fineduning und Bugfixing.

3. Sonderwünsche - Change Requests

Kommen wir zurück zum Ausgangsbeispiel. Auftragsgeber A hat im Laufe der Entwicklung des Projektes immer neue Ideen eingebracht. Der Softwarehersteller S hat viele dieser Wünsche mit seinem lapidaren „kein Problem" entgegengenommen und teilweise auch umgesetzt. Die Sonderwünsche haben zusätzlich Zeit und Ressourcen gekostet und S weist A gelegentlich darauf hin, dass die Leistungen natürlich gesondert abgerechnet werden. A fällt aus allen Wolken.

Als A am Ende des Projektes die letzte Abschlagszahlung nicht mehr leistet, schickt S eine zusätzliche Rechnung für die Sonderwünsche und erklärt, dass er die Arbeiten erst fortsetzen werde, wenn die fälligen Abschläge und die Sonderwünsche vollständig bezahlt sind. Bis dahin wird auch der Zugang zum Testserver gesperrt. A hat zu diesem Zeitpunkt keinen Zugriff auf die bisherigen Arbeitsergebnisse.

S ist bereits hochgradig frustriert von dem Projekt. Wenn S Aufwand und Honorar gegenüber stellt, kommt er auf Stundensätze im einstelligen Eurobereich. Daran würde die Bezahlung der Sonderwünsche noch nicht einmal viel ändern. Auf der anderen Seite ist A verärgert über die vielen Verzögerungen und dämlichen Fehler, auf die er S immer hinweisen musste. A fürchtet, dass er den Launen des S ausgeliefert ist, was er sich auf keinen Fall bieten lassen will. (Dies ist übrigens der Zeitpunkt, indem sich beide Parteien anwaltlich beraten lassen).

Unklarheiten über den Vertragsinhalt und -umfang sind häufiger Ausgangspunkt für Streitigkeiten. Wenn die Parteien nicht durch Pflichten- und Lastenheft genau spezifiziert haben, was alles erarbeitet werden soll, fällt es den Parteien schwer, zwischen der bloßen Ausgestaltung des bisherigen Auftrages und der Erteilung neuer Aufträge zu unterscheiden.

S hätte sich an dieser Stelle gewünscht, er hätte nicht einen Pauschalpreis vereinbart, sondern nach aufgewendeten Stunden abgerechnet. Als Auftragnehmer hätte er auf jeden Fall dafür Sorge tragen müssen, dass die Vergütungspflicht von Sonderwünschen klar geregelt ist.

Auch der Auftraggeber ist an einer klaren Regelung interessiert. Er wünscht sich jedoch eine Klausel, wonach ein Sonderwunsch nur dann entgeltpflichtig ist, wenn dies ausdrücklich und schriftlich vereinbart ist. Der Auftraggeber wird vorschlagen, dass zunächst alle, während des Projektes abgegebenen Anweisungen, Inklusivleistungen darstellen und der Auftragnehmer am Besten schriftlich darauf hinweisen muss, wenn ein sogenannter Chancerequest vorliegt, bei dem die Höhe einer zusätzlichen Vergütung ausdrücklich vereinbart werden muss.

Eine Kommunikationsregelung zu Chancerequests mag zwar verhindern, dass der Auftraggeber nachträglich mit Ansprüchen konfrontiert wird. Die Regelung hilft jedoch nicht weiter, wenn sich die Parteien uneinig darüber sind, in welchem Umfang die Softwareerstellung geschuldet war, zum Beispiel wie viele Gestaltungsvorschläge vorgelegt werden müssen und welche Zusatzmodule im Backendbereich bereit gestellt werden müssen.

Der Auftragnehmer vereinbart an dieser Stelle am liebsten eine Klausel, wonach im Zweifel nur die Grundfunktionalität, die für den bestimmungsgemäßen Gebrauch unbedingt erforderlich ist, geschuldet ist. Im Zweifel soll nur das vereinbart sein, was ausdrücklich im Vertrag genannt ist.

Der Auftraggeber täte gut daran, sämtliche Features einzeln aufzulisten. Wenn er auf eine allgemeine Formulierung angewiesen sein sollte, braucht er eine Klausel, mit der er im Zweifel alle nützlichen Funktionen, die am Markt üblich sind, geschuldet werden.

4. Jede Software hat Fehler, aber wer bezahlt dafür?

Stellen wir uns vor, A und S haben es endlich geschafft, das Projekt zu Ende zu bringen. Noch während der Entwicklungsarbeit hat A eine ganze Liste von Punkten zusammengestellt, die nach seiner Meinung unbedingt erledigt werden müssen. Das beginnt mit der Korrektur von ein paar Rechtschreibfehlern, Fehlern bei der Darstellung in einem bestimmten Browser bei einer bestimmten Schriftgröße, Links, die ins Leere führen, langsame Responszeiten des Servers und einigen Features, an die man längst erinnert hatte. A hat ausgerechnet, dass der für die Fehlerbeseitigung notwendige Betrag den Wert der letzten Rate übersteigt und zahlt daher nichts mehr.

S ist der Meinung, dass einige der Punkte zwar noch erledigt werden können, ein Großteil wäre aber Weiterentwicklung oder Wartung, was A aus Kostengründen nicht vereinbart hatte. Außerdem habe A das Werk längst abgenommen und könne keine Rechte mehr geltend machen.

A setzt für die Nachbesserung durch seinen Anwalt eine Frist von zwei Wochen, die fruchtlos abläuft und erklärt daraufhin den Rücktritt. Neben der Rückzahlung sämtlicher Beträge fordert er Schadensersatz für eine Neuprogrammierung im Wert von circa dem zweifachen Wert des ursprünglichen Auftrages.

S verweist auf seinen Haftungsausschluss, wonach er auf Schadensersatz gar nicht oder allenfalls in der Höhe des Auftragsvolumens hafte.

Gewährleistung ist bei Softwareprojekten eines der häufigsten Streitthemen. Da verwundert es umso mehr, dass viele Unternehmer mit zusammengeklauten Haftungsregeln arbeiten, die einer gerichtlichen Überprüfung nicht standhalten. Der Auftragnehmer ist bei Fragen der Gewährleistung mit der gesetzlichen Regelung bereits mit der gesetzlichen Regelung ziemlich gut bedient. Er kann sich freuen, wenn der Auftragnehmer in seinen AGB eine unwirksame Klausel verwendet, da ihm dann das Haftungsregime des BGB zugute kommt.

Wenn der Auftragnehmer selbst die Bedingungen diktiert, vereinbart er nach Möglichkeit verschuldensunabhängige Garantiehaftungen. Danach verpflichtet er den Auftragnehmer, ein 100 % vollständiges und fehlerfreies Werk pünktlich abzuliefern. Der Auftragnehmer garantiert, dass das Werk frei von Rechten Dritter ist und sichert unverzügliche Beseitigung sämtlicher auftretender Fehler innerhalb kürzester Zeit zu.

Für den Auftragnehmer ist es nicht einfach, die Gewährleistung und Haftung wirksam zu beschränken oder zu begrenzen. Der Auftragnehmer wird versuchen, die Geltendmachung von Gewährleistungsansprüchen z. B. durch verkürzte Gewährleistungs- oder Anzeigepflichten zu beschränken. Für bestimmte Fehlerarten kann die Haftung betragsmäßig begrenzt werden, beispielsweise auf die Höhe der Haftpflichtversicherungssumme.

Noch günstiger fährt der Auftragnehmer, wenn er Test- und Fehlersuche und Fehlerbehebung gleich in die Projektplanung aufnimmt und sich vergüten lässt. Idealerweise verpflichtet er sogar den Auftraggeber, die Fehler aufzuspüren und rechtzeitig zu benennen.

Ein an die Softwareentwicklung anschließender Support- und Wartungsvertrag ist für den Auftragnehmer eine gute Möglichkeit, die ansonsten kostenlosen Nachbesserungen in bezahlter Arbeitszeit umzuwandeln.

5. Nutzungsrechte

Nach langem hin und her haben sich A und S geeinigt, die verbliebenen Mängel zu beheben und noch ein bisschen für die Restarbeiten zu bezahlen. Das System läuft seit einigen Monaten halbwegs stabil. A möchte, dass die Software auf einem eigenen Server läuft, auf dem nur er und sein künftiger, neuer IT-Partner Zugriff haben. S ist gerne bereit, hierbei mitzuwirken - gegen zusätzlicher Vergütung versteht sich - will jedoch nur verschlüsselte Versionen der Skripte und kompilierte Programme im Objektcode übergeben. Eine weitere Bearbeitung dürfe nur durch S erfolgen.

Inzwischen bemerkt A, dass ein Mitbewerber ein Portal eröffnet hat, das dem eigenen erstaunlich ähnlich sieht. Im Impressum findet er sogar einen Vermerk, wonach S an der Entwicklung mitgewirkt habe. A verlang von S nicht nur die Herausgabe der Quellcodes, sondern auch die Unterlassung der weiteren Nutzungen von S und dessen Kunden.

Es gibt vermutlich viele Dinge, die spannender zu lesen sind, als Lizenzbedingungen. A und S hatten sich hierüber bei Vertragsschluss wenig Gedanken gemacht oder eine pauschale Formulierung vereinbart, mit der sie die nun aufgetretenen Fragen nicht lösen können.

Mangels ausdrücklicher vertraglicher Regelung gelten Nutzungsrechte nur in dem Umfang als eingeräumt, wie es für die Erfüllung des Vertragszweckes erforderlich ist (§ 31 Abs. 5 Urheberrechtsgesetz). Bearbeitungen und Übertragungen von Nutzungsrechten bedürfen im Zweifel der Zustimmung des Urhebers. Bei Individualsoftware kann sich aus der Gesetzesauslegung jedoch auch eine umfangreichere Rechtsübertragung ergeben. Die Auslegung ist aber jedoch schwer vorhersehbar.

Siehe hierzu auch den Beitrag über Softwarelizenzvertrag/Eula.