Gestaltung von Softwareentwicklungsverträgen 

Ein Beitrag zur Frage, worauf Sie bei der Erstellung von Softwareverträgen achten sollten.

Von RA David Herz, Fachanwalt für IT-Recht und Urheber- u. Medienrecht und Stud. iur. Katja Wallerberger.

Bei der Beauftragung von Softwareentwicklung stellt sich oftmals das Problem, dass die konkreten Erwartungen der Parteien nicht oder nicht sorgfältig in den Verträgen festgehalten werden. Dies führt im Fortgang der Softwareentwicklung zu einer Vielzahl von Problemen. Lesen Sie hier, welche Vorüberlegungen Sie für eine effektive Aufgabenverteilung  zwischen Auftraggeber und Auftragnehmer beachten sollten und wie Sie häufige Fehler vermeiden können.

Oft gestellte Frage: Welchem Vertragstypus sind Softwareentwicklungsverträge zuzuordnen?

Um in die Thematik der Softwareentwicklungsverträge einzusteigen, muss zunächst geklärt werden, um welchen Vertragstypus des BGB es sich dabei handelt. Fraglich ist, ob es sich um einen Werkvertrag oder um einen Werklieferungsvertrag handelt, wobei die eindeutige Zuordnung noch immer strittig ist. Bei Werklieferungsverträgen wäre nicht das Werkvertragsrecht, sondern gem. § 650 BGB die Regelung des Kaufrechts anzuwenden, was wiederum weitreichende Folgen für bspw. die Mängelgewährleistungsverjährung hätte.

Die erste sich stellende Frage ist, was eine Software eigentlich ist. Schlägt man im Wörterbuch nach, wird eine Software als nicht physikalischer technischer Bestandteil einer Datenverarbeitungsanlage -wie einem Computer- von der physikalischen Hardware abgegrenzt. Kann aber ein nicht physikalischer Bestandteil eine Sache i.S.v. § 90 BGB sein?

Dort werden nämlich lediglich körperliche Gegenstände als Sache definiert, weshalb mangels physikalischer Greifbarkeit die Software dem Wortlaut nach eigentlich nicht als Sache bezeichnet werden kann. Der BGH hat jedoch entschieden, dass Software doch eine Sache i.S.d. BGB sei (vgl. u.a. BGH, Urteil vom 15.11.2006, Az.: XII ZR 120/04). Demnach sei eine auf einem Datenträger gespeicherte bzw. somit verkörperte Software als eine bewegliche Sache anzusehen, weshalb je nach Fallkonstellation auch das Miet- oder Kaufrecht Anwendung finden könne. – Auch wenn es hieße, Kaufrecht auf einen Sachverhalt anzuwenden, bei welchem es um im Kern erfolgsbezogene Verträge geht (vgl. BGH, Urteil vom 23.07.2009, Az.: VII ZR 151/08).

Entgegen der o.g. Rechtsprechung wird in der Literatur die Meinung vertreten, dass nicht das Kauf-, sondern das Werkvertragsrecht gem. §§ 631 ff. BGB Anwendung findet. Dem hat sich der BGH in einem späteren Urteil auch angeschlossen, nach welchem die Programmierung einer Website i.d.R. dem Werkvertrag, lediglich u.U. dem Werklieferungsvertrag, zuzuordnen sei (vgl. BGH, Urteil vom 04.03.2010, Az.: III ZR 79/09). Die Streitfrage ist also noch nicht höchstrichterlich geklärt, im Zweifel sollte man sich folgende Metapher vor Augen führen: Setzt man an die Stelle der Software ein Buch, wird der Schaffungsprozess durch den Autor (Softwareersteller/Auftragnehmer) dem Werkvertragsrecht zugeordnet (vgl. MüKo BGB/Busche § 631 Rn. 132). Die Veräußerung an den Leser (Anwender) durch den Verlag (Auftraggeber) hingegen im nächsten Schritt selbstredend dem statischen Kaufrecht. Denn eben die statische Eigenschaft des Kaufrechts verweigert im Grunde die Zuordnung von Softwareentwicklungsverträgen, denn derartige Schaffungsprozesse sind zu dynamisch und bedürfen der Regelungen aus dem Werkvertragsrecht.

Die Zuordnung zum Werkvertragsrecht kann zudem mit dem Argument begründet werden, dass bei der Erstellung von Software der Schaffungsprozess und die planerischen Leistungen im Vordergrund stehen, die Sachqualität dabei jedoch in den Hintergrund rücken kann. Denn diese kann bei der Entwicklung von Software im Laufe des Schaffungsprozesses durch unvorhergesehene Probleme oder Verbesserungen von der ursprünglich vereinbarten Qualität abweichen.

Achtung: An dieser Stelle kann die o.g. Argumentation nicht auf bereits fertig gestellte Software angewendet werden, die lediglich noch ausgeliefert bzw. verkauft wird! Solche Fälle erfordern die Anwendung von Kaufrecht.

Das Werkvertragsrecht findet im Software-Bereich ausschließlich auf die Erstellung/Änderung von Individualsoftware Anwendung, denn dann besteht die Leistung in der schöpferischen Gestaltung der Software und nicht in der bloßen Lieferung (Werklieferungsvertrag).

Festlegen einer Arbeitsweise: Klassische Wasserfall-Methode oder das agile Scrum-Modell?

Nachdem die Frage des Vertragstypus geklärt ist, sollte im Vertrag die Arbeitsweise zur Softwareentwicklung festgelegt werden, damit bereits vor Beginn der Arbeitsaufnahme die Strategie feststeht und es zu keinen Missverständnissen kommt.

Zurückgegriffen wird bei den Arbeitsweisen i.d.R. auf zwei Klassiker im Projektmanagement: Die sog. Wasserfall-Methode oder das agile Scrum-Modell.

Bei der Wasserfall-Methode erfolgt die Arbeit sukzessiv, d.h. in aufeinanderfolgenden und gleichzeitig aufeinander aufbauenden Phasen, die in strikter Reihenfolge abgearbeitet werden. Diese Herangehensweise ist besonders für den Arbeitgeber vorteilhaft, da sie hohe Planungssicherheit und das Einigen auf einen Festpreis möglich macht. Oft steht nur ein begrenztes Budget zur Verfügung und unvorhersehbare Kosten kommen bei der Wasserfall-Methode idealerweise nicht auf. Voraussetzung dafür ist allerdings eine äußerst sorgfältige und präzise Planung, da hier kein Platz für Fehler ist.

Sollte für eine Softwareentwicklung jedoch ein flexibleres Budget bereitliegen und sind unvorhersehbare Faktoren nicht ausgeschlossen, empfiehlt es sich, auf das Modell des agilen Projektmanagements (Scrum-Modell) zurückzugreifen.

Problematisch ist bei einem starren Ablauf und einem bestimmten, limitierten Budget ohne Puffer nämlich oft, dass die Qualität der erbrachten Leistung leidet. Das ist aber keineswegs zielführend, denn bei Softwareentwicklungen hat i.d.R. der Anspruch des Endnutzers bzw. Anwenders oberste Priorität, da nur bei zufriedenen Anwendern das investierte Budget sich letztlich in „schwarze Zahlen“ umwandeln lässt („Return on Investment“). Aus diesem Grund hat auch das agile Scrum-Modell die Wasserfall-Methode weitestgehend aus der Praxis verdrängt; zumindest, was Softwareentwicklungen betrifft.

Doch was kann man sich unter dem Scrum-Modell vorstellen? Als Scrums werden tägliche, kurze Team-Besprechungen zum Fortschritt des Projekts bezeichnet, die eine schnelle Reaktionsmöglichkeit auf unvorhergesehene Faktoren ermöglichen.

An die Stelle einer starren Einheitsplanung, bei der jeder vorangegangene Schritt die Voraussetzung für den nächsten ist, treten sog. Sprints. Diese Sprints sind Bearbeitungszyklen, die von kleineren (Fach-) Teams hingelegt werden. Die Basis für die Sprints sind sog. User-Stories, die die Anforderungen der Anwender an die Software darstellen. Jedes Team sucht sich eine realistische Anzahl dieser Aufgaben aus und arbeitet an deren Erfüllung ganz unabhängig vom Stand der übrigen Teams. Um der aus der Unabhängigkeit möglicherweise resultierenden langsameren Bearbeitung von Aufgaben entgegenzuwirken, sollte ein Zeitplan aufgestellt und in den Vertrag integriert werden. Sollte kein Zeitplan aufgestellt worden sein, kann zumindest die Leistungserbringung nicht gem. § 271 BGB sofort verlangt werden, da es sich schließlich um einen Werkvertrag handelt. Dem Auftragnehmer muss in jedem Fall ein angemessener Zeitraum zur Verfügung gestellt werden, wobei grundsätzlich davon ausgegangen wird, dass dieser mit der Aufnahme seiner Tätigkeit sofort beginnt und diese zügig fortführt, sollte vertraglich nichts Anderweitiges vereinbart worden sein.

Sollte allerdings der Auftragnehmer den vertraglich vereinbarten Zeitraum unbegründet überschreiten oder im Falle fehlender Vereinbarung unverhältnismäßig viel Zeit beanspruchen, ohne die vertragsgemäße Zügigkeit an den Tag zu legen, nehmen die Auftraggeber diesen Missstand nicht selten zum Anlass, den Vertrag rückabzuwickeln. Bei der Überschreitung des Zeitraums muss allerdings nicht zwingend die finale Abgabefrist gemeint sein, sondern auch „Zwischentermine“ wie das Einreichen eines Entwurfs oder einer Power-Point-Präsentation etc. können ausschlaggebend sein. Derlei Terminzusagen geschehen im Rahmen des Scrum-Modells aufgrund der Unabhängigkeit der Teams leider nicht selten auf Zuruf durch einen Mitarbeiter des Auftragnehmers, der jedoch als Projektleiter keine Kenntnis von solch einer Zusage hat.

Grundsätzlich wird für die Wirksamkeit solcher Terminzusagen eine Vertretungsbefugnis des Mitarbeiters vorausgesetzt. Allerdings greift zum Schutz des Auftraggebers oft der Grundsatz der Anscheinsvollmacht, nach welcher der Vertretene das vollmachtlose Handeln zwar nicht kennt, er jedoch bei Erfüllung seiner Sorgfaltspflicht davon hätte Kenntnis erlangen können müssen. Damit der Auftragnehmer also in die Haftung genommen werden kann, muss er seiner Sorgfaltspflicht nicht nachgekommen sein (bspw. ausschließliches Arbeiten vom „Home-Office“ aus, keine Kontrolle über seine Mitarbeiter durch mangelnde Anwesenheit bei den Teambesprechungen etc.) und zusätzlich muss der Auftraggeber gem. § 179 III BGB analog im guten Glauben darauf vertraut haben, dass der Mitarbeiter tatsächlich befugt ist, solche Zusagen zu machen.

Die Bedeutung von Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft dienen im Kern dem Zweck, dass beide Parteien wissen, was von Seiten des Auftraggebers konkret gewünscht ist (Lastenheft) und wie der Auftragnehmer gedenkt, diese Wünsche und Forderungen zu erfüllen (Pflichtenheft). Sie sollen Missverständnisse vermeiden, die gerade im Software-Bereich immer dann vorprogrammiert sind, wenn der der Auftragnehmer keine klaren Vorgaben hat und das Projekt nach seinen Vorstellungen leitet. Dabei muss er gar nicht böswillig die Wünsche des Auftraggebers umgangen sein; es ist i.d.R. die Folge mangelnder technischer Hintergrundkenntnisse des Auftraggebers, weshalb dieser nur oberflächlich seine Wünsche schildert und der Auftragnehmer diese dann u.U. anders aufnimmt und nach seinen Vorstellungen umsetzt. Um derlei Kommunikationsfehler zulasten des Auftraggebers -und letztlich zulasten des Anwenders- zu vermeiden, sollte das Lastenheft entweder mit dem Auftragnehmer gemeinsam oder zumindest in Zusammenarbeit mit einem extern Beauftragten, der über hinreichendes Hintergrundwissen verfügt, erarbeitet werden.

Was gehört in ein Lastenheft beim Softwarevertrag?

Das Lastenheft oder auch Anforderungskatalog bzw. Produktskizze wird vom Auftraggeber erstellt und präzisiert den Entwicklungsauftrag an den Auftragnehmer. Es sollte lieber etwas umfangreicher als zu knapp formuliert sein, denn der Auftraggeber tut weder sich noch seinem Vertragspartner einen Gefallen, wenn er sich kurzfasst.

Konkrete Inhalte sollten sein: Der Ist-Zustand, der beschreibt, aus welchen Gründen diese Software in Auftrag gegeben wird. Gründe können bspw. in einer „Marktlücke“ liegen, in besonderem Handlungsbedarf oder auch für die Einbettung in ein größeres Projekt, für dessen Durchführung diese Software benötigt wird.

Außerdem muss der Soll-Zustand inklusive der funktionalen Anforderungen definiert werden. Der Auftraggeber muss sich fragen, was die Software letztendlich leisten können und welche Funktionen sie haben soll. Besondere Funktionen können beispielsweise eine Zwei-Faktor-Authentifizierung, ein Fingerabdruckscan als Passwortschutz oder auch die Möglichkeit sein, Inhalte auf sozialen Netzwerken zu „teilen“.

Daneben sollten auch die nicht-funktionalen Anforderungen wie bspw. eine Update-Möglichkeit, Zuverlässigkeit, Virenschutz, einfache Bedienbarkeit und Energieverbrauch etc. im Lastenheft aufgelistet werden.

Weiter ist zu empfehlen, die Zuständigkeiten am Erstellungsprojekt und ggf. Kooperationen mit weiteren (auf bestimmte Teilbereiche spezialisierte) Firmen festzulegen. Es besteht die Möglichkeit, die Phasenplanung im Detail ebenfalls in das Lastenheft aufzunehmen, wobei es bei diesem Punkt darauf ankommt, wie sehr sich der Auftraggeber einbringen will.

In der Regel wird die genaue Planung dem Auftragnehmer überlassen; „Meilensteine“ des Projekts werden allerdings oft festgelegt, damit sich der Auftraggeber in regelmäßigen Abständen einen Überblick über den Entwicklungsstand verschaffen kann. Über die „Meilensteine“ an sich hinaus sollte gleich vorab schriftlich festgehalten werden, welche Art des Status-Updates gewünscht ist. Die räumliche Distanz spielt dabei eine maßgebliche Rolle, wenn zwischen persönlichen Meetings, Telefonaten oder E-Mails ausgewählt werden soll.

Inhalt des Pflichtenhefts und dessen rechtliche Bedeutung

Wie bereits erwähnt, wird das Pflichtenheft vom Auftragnehmer erstellt. Zuvor erhält dieser das Lastenheft und entwirft aufbauend auf den darin enthaltenen Anforderungen die konkrete Durchführung des Projekts. Es ist nicht unüblich, dass das Pflichtenheft eine Art Bewerbung um den Auftrag darstellt: Der Auftraggeber verschickt sein Lastenheft an mehrere potentielle Auftragnehmer, lässt sich deren Entwürfe in Form von Pflichtenheften zusenden und entscheidet sich dann in einem Auswahlverfahren für das beste Angebot.

Grundsätzlich empfiehlt es sich als Auftraggeber spätestens an diesem Punkt des Projekts einen Rechtsanwalt zu konsultieren, damit dieser das Pflichtenheft prüft. Denn anders als beim Lastenheft handelt es sich beim Pflichtenheft als ein konkretes Angebot um einen gem. § 145 BGB rechtlich-verbindlichen (und somit juristisch relevanten) Teil des Werkvertrags. Als ein Angebot wird eine empfangsbedürftige Willenserklärung bezeichnet, die alle wesentlichen Vertragsbestandteile enthält und dem Vertragspartner (Auftraggeber) so zugetragen wird, dass dieser zum Zustandekommen des Vertrages lediglich noch sein Einverständnis bzw. seine Annahme erklären muss.

Inhaltlich weist das Pflichtenheft eine Besonderheit auf, die nicht ausgelassen werden sollte: Es werden neben den Zielen und deren Weg zur Verwirklichung (positive Abgrenzung) auch die Nicht-Ziele (negative Abgrenzung) erläutert. Neben den Erläuterungen zu den Wünschen und Forderungen aus dem Lastenheft sollte das Pflichtenheft auch eine Problemanalyse enthalten, anhand derer Risikofaktoren analysiert werden. Daraus ergibt sich der Prüfungspunkt der Machbarkeit des Projekts.

Der Auftragnehmer als Projektleiter entwickelt einen organisatorischen sowie betriebswirtschaftlichen Plan, anhand dessen die Umsetzbarkeit mit dem zur Verfügung gestellten Budget analysiert wird. An dieser Stelle wird insbesondere die Arbeitsweise relevant, da von der Wasserfall-Methode oder dem Scrum-Modell dieser Punkt im Pflichtenheft im Wesentlichen abhängt. Muss das Budget strikt eingehalten werden? Wie viele Teams werden benötigt? – Bei der Wasserfall-Methode werden tendenziell weniger Teams als bei dem Scrum-Modell benötigt, da die Arbeitsschritte nicht parallel absolviert werden können. Mitwirkungspflichten des Auftraggebers sollten als organisatorischer Bestandteil in die AGB aufgenommen werden, da im Falle von durch mangelnde Mitwirkung des Auftraggebers entstandenen Schäden dem Auftragnehmer dann kein Schadensersatzanspruch zusteht, wenn die Mitwirkungsleistungen des Arbeitgebers nicht explizit als durchsetzbare Pflichten in den AGB festgehalten wurden.

Neben personell-organisatorischen Überlegungen wird auch die technische Realisierbarkeit im Pflichtenheft aufgeführt. Dabei sollte unbedingt der Punkt der Vereinbarkeit von Hardware mit Software geprüft werden.

Des Weiteren wird ein Angebot zur Projektorganisation, dem Phasenplan mit seinen Meilensteinen und der Ablaufkontrolle jener Entwicklungsstadien unterbreitet.

Unter allen Umständen sollte im Pflichtenheft eine Benutzerdokumentation berücksichtigt werden. Mit diesem Nutzerhandbuch für den Anwender wird die bestmögliche Nutzung der Software gewährleistet. Denn fehlt eine solche Benutzerdokumentation, können die Anwender u.U. aus Unwissenheit nicht die gesamte Bandbreite der Funktionen abrufen oder sind nicht einmal in der Lage, die Grundfunktionen zu bedienen. Aus dem Bereitstellen eines Nutzerhandbuchs ergibt sich auch für den Auftraggeber ein Vorteil: Wenn man den Anwendern die Möglichkeit bietet, sich bei auftretenden Problemen oder Unklarheiten selbst zu belesen, minimieren sich die Support-Anfragen an den Anbieter.

Sollte der Softwareentwickler eine fehlerhafte, unvollständige oder für den Durchschnittsanwender zu komplizierte Benutzerdokumentation zur Verfügung stellen, stellt dies sodann eine Nichterfüllung der Auftragnehmerpflichten dar, wenn diese Missstände zur mangelnden Akzeptanz beim Anwender und letztlich zu finanziellen Verlusten seitens des Auftraggebers führen.

Neben dem Anwender muss selbstredend der Anbieter (Auftraggeber) Kenntnis von der Funktionsfähigkeit der Software haben, weshalb eine Einweisung durch den Softwareentwickler ebenfalls im Pflichtenheft berücksichtigt werden sollte. Diese Schulung zur Anwendung macht es dem Anbieter möglich, bspw. Überhaupt einen Support-Service anbieten zu können, ohne jedes Mal die Softwareentwicklungsfirma zu kontaktieren.

Zusammenfassend sollte aus Auftraggeber-Sicht darauf geachtet werden, dass das Pflichtenheft nicht zu oberflächlich und knapp formuliert ist. Auch sollte geprüft werden, ob die Abgrenzungskriterien aufgezeigt wurden, um eventuelle „Kostenfallen“ oder Meinungsverschiedenheiten zu vermeiden. Der Auftragnehmer auf der anderen Seite sollte sich auch nicht gehemmt sehen, komplizierte technische Zusammenhänge und eventuelle Risikoberechnungen etc. mit einzubringen, denn ein unvollständiges Pflichtenheft ist letztlich nicht zielführend.

Betriebliches Kontinuitätsmanagement (Business Continuity Planning) – Der Notfallplan für den Auftraggeber bei Leistungsstörungen

Aus dem Bereich des Risikomanagements entstammt der Begriff des Business Continuity Planning und meint die Ausarbeitung eines Notfallplans, sollte es zu Leistungsstörungen wie einer verspäteten Fertigstellung oder mangelhafter Qualität der Software kommen. Diese Leistungsstörungen sind dann erheblich, wenn sie den Betriebsablauf derart stören, dass der Auftraggeber finanzielle Verluste verzeichnet.

Das Ziel dieses Notfallplans ist es, den Betriebsablauf wie gewohnt oder zumindest mit minimierten Beeinträchtigungen zu gestalten. Nicht nur aus Auftraggeber-Sicht ist solch ein Plan von Vorteil; auch der Auftragnehmer sieht sich im Zweifelsfall durch einen geringeren Schaden einer folglich geringeren Schadensersatzforderung ausgesetzt.

Wer entwickelt diesen Notfallplan? Im Idealfall beschäftigen sich beide Parteien in Kooperation mit dessen Ausarbeitung. Am besten lässt sich das im Rahmen des agilen Scrum-Modells realisieren, da sich ein Team unabhängig von den Tätigkeiten der anderen Teams mit dem Auftraggeber in Verbindung setzen und den Plan gemeinsam ausarbeiten kann.

Es besteht allerdings auch die Möglichkeit für den Auftraggeber, den Plan selbständig auszuarbeiten, da er seinen Betrieb i.d.R. am besten kennt und weiß, wie er seine Angestellten und die Finanzmittel strategisch am klügsten einsetzt, um die Zeit bis zur Behebung der Störung zu überbrücken.

Freigabe und Freigabeverweigerung beim Softwareerstellungsvertrag

Die finalen Schritte sind die Freigabe oder die Freigabeverweigerung, wobei diese Begriffe oft missverstanden werden. Es ist nämlich fraglich, ob die Freigabe als eine Abnahme i.S.v. § 640 BGB verstanden werden darf. Die Antwort: Ja und nein, denn die Freigabe erfolgt nicht nur einseitig, sondern durch beide Vertragsparteien.

Die Freigabe seitens des Auftragnehmers erfolgt dann, wenn die Software fertiggestellt wurde oder die Teams im Rahmen des agilen Scrum-Modells ihre einzelnen Sprints absolviert haben. Der Projektleiter (Auftragnehmer) ermittelt anhand von Tests die Funktionsfähigkeit der gesamten Software oder der einzelnen Sprints. Sollte alles den Vorgaben und bspw. technischen Sicherheitsstandards entsprechen und fehlerfrei funktionieren, erteilt der Projektleiter seine Freigabe. Im Umkehrschluss bedeutet das, dass nicht freigegebene Software (Freigabeverweigerung) von der fachlichen Seite nicht abgenommen wurde, weil Mängel aufgetaucht sind. In solchen Fällen wird ggf. das o.g. Business Continuity Planning relevant.

Der Auftraggeber erteilt folglich nach dem Auftragnehmer seine Freigabe. Diese wird dann erteilt, wenn sich der Auftraggeber mittels eines Testprozederes im Rahmen des Abnahmeverfahrens selbst von der Funktionsfähigkeit und der Verwirklichung seiner Forderungen sowie den Versprechungen aus dem Pflichtenheft überzeugt hat. An dieser Stelle handelt es sich bei der (Markt-) Freigabe um eine Abnahme gem. § 640 BGB. Die Abnahme kann auch schrittweise nach den einzelnen Meilensteinen bzw. Sprints erfolgen; man spricht dann von einer Teilabnahme.

Sind nachträgliche Änderungen des Leistungsinhalts im Laufe der Vertragsdurchführung zulässig?

Aus der Natur eines Werkvertrages ergibt sich, dass dem Auftraggeber kein einseitiges Leistungsbestimmungsrecht obliegt hinsichtlich der Art, wie der Auftragnehmer die gesetzten Ziele erreichen soll. Bei Werkverträgen ist im Gegensatz zu Dienstleistungsverträgen nicht die Arbeit die geschuldete Leistung, sondern das Werk als Ergebnis. Selbstredend kann auch der Auftragnehmer das vertraglich zugesicherte Ergebnis nicht nachträglich nach seinen Vorstellungen abändern. Es muss allerdings eine Möglichkeit eingeräumt werden, vertragliche Änderungen im Nachhinein einzubauen, wenn sie zwangsläufig erfolgen müssen.

Bei Softwareentwicklungsverträgen handelt es sich um ein komplexes Themengebiet, bei welchem solch eine Problematik nicht ausgeschlossen werden kann. Die Leistungsänderung muss ganz simpel von beiden Vertragsparteien genehmigt werden. Dieses sog. Change-Management setzt also beidseitiges „Agreement“ voraus, damit der Änderungsvorschlag nicht bspw. an einer Inhaltskontrolle gem. § 307 BGB scheitert, wonach Bestimmungen in den AGB dann unwirksam sind, wenn sie einen Vertragspartner entgegen den Geboten von Treu und Glauben unangemessen benachteiligen.

Umstritten: Hat der Auftraggeber Anspruch auf Übergabe des Quellcodes beim Softwarevertrag?

Die Frage, ob der Auftraggeber einen Anspruch auf Heraus- und Übergabe des Quellcodes hat, also ob dies Bestandteil der vertraglich geschuldeten Leistung ist, ist bei Softwareentwicklungsverträgen nicht unüblich und häufig Gegenstand eines Rechtsstreits.

Ob ein Werkunternehmer, der sich zur Erstellung eines Datenverarbeitungsprogramms verpflichtet hat, dem Besteller auch den Quellcode des Programms überlassen muss, ist mangels einer ausdrücklichen Vereinbarung nach den Umständen des Einzelfalls zu beurteilen. Neben der Höhe des vereinbarten Werklohns kann dabei insbesondere dem Umstand Bedeutung zukommen, ob das Programm zur Vermarktung durch den Besteller erstellt wird und dieser zur Wartung und Fortentwicklung des Programms des Zugriffs auf den Quellcode bedarf (BGH NJW-RR 2004, 782, beck-online).

Soweit es keine ausdrückliche Vereinbarung gibt, werden beim voll vergüteten Entwicklungsauftrag sämtliche Nutzungsrechte und – jedenfalls wenn auch der Quelltext übergeben wird – auch Änderungsrechte übertragen. Umgekehrt spricht beim voll vergüteten Entwicklungsauftrag mangels abweichender Vereinbarungen viel dafür, dass der Quelltext mit überlassen werden muss (Kilian/Heussen ComputerR-HdB, 20.4 Urheberrecht Rn. 118 Rn. 118, beck-online m.w.N.).

Es kommt daher wie immer auf den Einzelfall an.

Unser anwaltlicher Rat: Um an dieser Stelle Streit zu vermeiden, sollte in jedem Softwareerstellungsvertrag eine Regelung zur Herausgabe des Quellcodes getroffen werden! Egal, ob die Herausgabe geschuldet ist oder nicht.

Falls es zu einem Rechtsstreit kommt, ist die Herausgabe des Quellcodes auch im einstweiligen Verfügungsverfahren möglich (OLG Karlsruhe, Beschl. v. 18.3.2019 – 10 U 13/18 Rn. 22, GRUR-RS 2019, 37445, beck-online), wobei auch hier immer eine Einzelfallsbetrachtung erforderlich ist und ein spezialisierter Anwalt zu Rate gezogen werden sollte

Was ist bei der Vergütung von Softwareentwicklungsverträgen zu beachten?

Die Vergütung nimmt bei Softwareentwicklungsverträgen die Form eines Kostenplans an, wobei dieser i.d.R. flexibel gestaltet wird. Die Ausnahme bildet die Arbeitsweise der Wasserfall-Methode, wo das Budget meistens noch vor Projektbeginn festgelegt wird.

Der Kostenplan kann also beim Scrum-Modell vom Auftragnehmer den entsprechenden Gegebenheiten angepasst werden. Selbstredend ist auch das nur nach Absprache mit dem Auftraggeber möglich; dieser kann nämlich bei inakzeptablen Kosten den Vertrag beenden, wenn der Auftragnehmer sich nicht an den marktüblichen Kosten orientiert. Dies dient der Kalkulationssicherheit für den Auftraggeber, auch wenn es sich um ein grundsätzlich flexibles Budget handelt.

Die Fälligkeit der Vergütung richtet sich nach § 641 BGB, wonach bei Werkabnahme der Auftragnehmer ausbezahlt wird. Auch eine Vergütung nach der Teilabnahme von Abschnitten bzw. Meilensteinen ist möglich und vergleichbar mit den Abschlagszahlungen gem. § 632a Abs. 1 BGB.

Nutzungsrechte seit der Urheberrechtsreform 2016 und die Frage der Zulässigkeit von Total-Buy-Outs

Jeder Unternehmer, welcher eine Individualsoftware in Auftrag gibt, wünscht sich umfassende Nutzungsrechte. Diese werden ihm i.d.R. durch den Softwareentwickler eingeräumt, da es sich schließlich um Individualsoftware handelt. Doch im Zuge der Urheberrechtsreform 2016 wurde das „Gesetz zur verbesserten Durchsetzung des Anspruchs auf angemessene Vergütung und zur Regelung von Fragen der Verlegerbeteiligung“ verabschiedet, was wesentliche Änderungen an den Bestimmungen zum Nutzungsrecht im UrhG nach sich zog.

So besagt nämlich § 40a UrhG, dass wenn der Auftragnehmer dem Auftraggeber ausschließliche Nutzungsrechte übertragen hat, diese nach 10 Jahren ablaufen und dem Auftraggeber nunmehr einfache Nutzungsrechte bleiben. Diese Regel findet allerdings gem. § 69a Abs. 5 UrhG nicht auf Computerprogramme Anwendung, weshalb in der Praxis sog. Total-Buy-Out-Klauseln in die AGB eingebaut werden. Diese Buy-Outs sind der Ausverkauf von Nutzungsrechten an einem Werk gegen pauschales Honorar. Die Vergütung bei Softwareentwicklungsverträgen umfasst bereits Total-Buy-Outs und die Klauseln sind auch dann angemessen, wenn der Posten einzeln hervorgehoben und angemessen vergütet wird.

Welche Rechte habe ich, wenn der Softwarevertrag Mängel aufweist?

Die Mängelansprüche des Auftraggebers sind in § 634 BGB aufgelistet und umfassen die Nacherfüllung gem. § 635 BGB sowie die Möglichkeit, selbst den Mangel zu beseitigen und gem. § 637 BGB Aufwendungsersatz zu verlangen oder Schadensersatz nach den §§ 636, 280, 281, 283 und 311a BGB zu verlangen.

Der Auftraggeber kann auch Ersatz für vergebliche Aufwendungen gem. § 284 BGB verlangen, wenn er bspw. bereits einen Webdesigner beauftragt hat, ein Logo für die in Auftrag gegebene Software zu entwerfen, es aber wegen des Auftragnehmers zu keiner entsprechenden Softwareentwicklung kommt. Diese Ansprüche verjähren alle gem. § 634a Abs. 1 BGB nach 2 Jahren ab der Abnahme nach § 634a Abs. 2 BGB. Selbst eine Freigabe- bzw. Abnahmeverweigerung ist als Datierung zulässig, vgl. OLG Hamm, Urteil vom 26.02.2014, Az.: 12 U 112/13. Der Grund, weshalb nicht die regelmäßige Verjährung (3 Jahre ab Abnahme) gem. § 634 Abs. 1 Nr. 3 BGB greift, liegt in der spezialgesetzlichen Regelung des § 634a Abs. 1 Nr. 1 BGB (lex specialis). Demnach verjähren Ansprüche bei einem Werk, dessen Erfolg in der Herstellung, Wartung oder Veränderung einer Sache oder in der Erbringung von Planungs- oder Überwachungsleistungen hierfür besteht, nach 2 Jahren.

Bei einem Softwareentwicklungsvertrag geht es vorrangig um die Herstellung einer Sache; wenn bereits bestehende Software individuell angepasst werden soll, handelt es sich um eine Veränderung einer Sache und falls der Auftraggeber den Auftragnehmer nach Erbringung der eigentlichen Leistung (Softwareentwicklung) zusätzlich mit der regelmäßigen Instandsetzung der Software beauftragt, handelt es sich um die Wartung einer Sache. Zudem erfordert die Entwicklung einer Software wie oben beschrieben Planungs- und Überwachungsleistungen. Da die Tatbestände der spezialgesetzlichen Regelung greifen, verjähren die Ansprüche gegenüber dem Softwareentwickler nicht erst nach 3 Jahren.

Die einzige Ausnahme ist in § 634a Abs. 3 BGB normiert, wonach die regelmäßige Verjährungsfrist bei Softwareentwicklungsverträgen dann Anwendung findet, wenn der Auftragnehmer den Mangel arglistig verschwiegen hat.

Unwirksam in den AGB sind: Ein vollständiger Ausschluss von Gewährleistungsansprüchen sowie das Unterschreiten einer Mängelhaftungsfrist von 1 Jahr. Die Frist kann bei einem Unternehmer-Unternehmer-Verhältnis durch eine entsprechende AGB-Klausel auf 1 Jahr verkürzt werden, vgl. §§ 309 ff. BGB.

Aus Verbraucherschutzgründen findet diese Regelung nicht bei Unternehmer-Verbraucher-verhältnissen Anwendung, wobei solche Konstellationen bei Softwareentwicklungsverträgen eher die Ausnahme bilden dürften.

Fazit: Was sollte bei Softwareerstellungsverträgen beachtet werden?

Die Materie der Softwareentwicklungsverträge ist äußerst komplex und erfordert höchste Genauigkeit bei der Prüfung auf Richtigkeit und Vollständigkeit, um Enttäuschungen und hohe finanzielle Verluste zu vermeiden. Wichtig ist, möglichst genau die Rechte und Pflichten der Vertragsparteien inkl. Zeitplan vertraglich zu regeln.

Aus Anwaltssicht ist für die Beratung zu diesem Thema ein hohes technisches Verständnis erforderlich. Unsere spezialisierten Anwälte:innen stehen Ihnen bundesweit auch bei komplexen Softwareprojekten mit den erforderlichen rechtlichen und technischen Kenntnissen zur Seite.

RA David Herz, Fachanwalt für IT-Recht:

„Die Frage, worauf Sie bei der Erstellung von Softwareverträgen achten sollten, hängt sehr stark davon ab, was Ihre Zielrichtung ist. Je nach Ausgestaltung schuldet der Auftragnehmer entweder nur eine begleitende Dienstleistung – dies kann bei einer agilen Softwareentwicklung sinnvoll sein – oder ein fertiges Werk in Form eines  konkreten Erfolgs, was insbesondere für den Auftragnehmer die größtmögliche Sicherheit bietet, da hier der Leistungsumfang konkret messbar ist.“

Unser spezialisiertes Fachanwaltsteam aus Berlin und Hamburg vertritt Sie bundesweit in allen Belangen des IT-Rechts und des Software-Vertragsrechts.