Softwarerecht: Beim Oberlandesgericht Frankfurt am Main (5 U 152/16) stritt man um die Mangelhaftigkeit einer Softwarelösung, die mittels agiler Entwicklung entwickelt wurde. Der Auftraggeber bemängelte eine unzureichende Dokumentation einmal der Software insgesamt, aber auch hinsichtlich einer (vereinbarten) Kommentierung des Software-Quelltextes.
Das Gericht macht deutlich, dass eben auch eine „äußerst knappe“ Kommentierung des Quelltextes ausreichend sein kann; etwas anderes gilt, aber bei der Dokumentation der Systemarchitektur – hier kann eine mangelnde Dokumentation insbesondere dann problematisch sein, wenn hierdurch verhindert wird, dass ein fachkundiger Dritter sich in das Projekt einarbeiten und dieses fortführen kann, die Leistung kann damit für den Auftraggeber unbrauchbar und letztlich wertlos sein. Hier aber schlägt die vereinbarte agile Softwareentwicklung durch, wie auch das OLG bestätigt: Eine solche Dokumentation ist erst dann sinnvoll möglich, wenn die Systemarchitektur und die letztendlich verwendeten Komponenten überhaupt feststehen – das ist während eines laufenden und „mittendrin“ gescheiterten Projekts – anders als bei den Quelltextdateien – kaum sinnvoll möglich.
Angesichts der 6-stelligen im Streit stehenden Summe ein für den Auftraggeber unerfreuliches Ergebnis, das durchaus gewisse Tücken agiler Entwicklung dokumentiert: Softwareprojekte, gerade die besonders umfangreichen, entwickeln sich durchaus gerne für alle Beteiligten recht unerfreulich. Bei agiler Entwicklung besteht an dieser Stelle eine gewisse Unsicherheit, wenn das Projekt wie so oft „mittendrin“ abgebrochen wird – der Auftraggeber möchte dann ein zumindest irgendwie verwertbares Ergebnis, der Auftragnehmer seinen Aufwand angemessen vergütet sehen. Bei zunehmendem Streit driftet diese Schere von Ansprüchen immer weiter auseinander, dem vertraglich zu begegnen ist bei agiler Entwicklung ebenso trickreich wie mit Tücken versehen.
Aus der Entscheidung des OLG:
Unabhängig hiervon hat die durchgeführte Beweisaufnahme das Vorliegen von Mängeln, die zu einer Minderung oder einem Rücktritt von dem Vertrag berechtigt hätten, tatsächlich nicht ergeben. In seinem Gutachten vom 30.05.2016 (Bl. 205 ff. d. A.) führt der Gutachter Diplom-Informatiker D aus, dass der Quellcode der Programmierungen der Klägerin durchaus kommentiert war. Allerdings sei die Kommentierung „äußerst knapp“. Dass hierin ein relevanter Mangel liege, hat der Sachverständige jedoch nicht festgestellt. Stattdessen bekundet er auf Seite 6 seines Gutachtens, dass dem „ersten Halbsatz [„Es fehle an der Dokumentation der Programmierung der Interfaces im Code …“] nicht zuzustimmen“ sei, „da die Interfaces der Klassen (sofern diese hier gemeint sind) durchaus rudimentär kommentiert sind.“ Weiter heißt es: „Der zweite Halbsatz [„In kaum einer Quellcode-Datei sei eine Dokumentation gefunden worden.“] sei (ebenfalls) im Prinzip zu verneinen, da „die Quellcode-Dateien …durchweg kommentiert (seien)…, wenn auch die Kommentierung nur sehr rudimentär ist und fachlich nicht überall als ausreichend zum Verständnis bewertet werden kann.“
Als erheblichen Mangel konstatiert der Sachverständige lediglich, dass „die Dokumentation der Systemarchitektur und der Systemkomponenten (sowie das Zusammenspiel der Systemkomponenten)“ fehle. Aus diesem Grunde sei „aus fachlichen Gründen zu verneinen“, dass die „von der Klägerin erstellte Dokumentationen nach Java-Doc sowie die Dokumentation des Projekts … mittels des Projekts … … einen fachkundigen Dritten in die Lage (versetzen), das Projekt … fortzuführen.“
Dass diese, von der Kommentierung der Quellcode-Dateien zu unterscheidende Dokumentation der Systemarchitektur und ihrer Komponenten bereits im Zeitpunkt des Abbruchs der Programmierungsarbeiten im Januar 2013 geschuldet war, ist nicht ersichtlich. Vielmehr hat die Klägerin (zuletzt in der mündlichen Verhandlung am 27.07.2017) unwidersprochen vorgetragen, dass dies erst geschehen kann bzw. sinnvoll ist, wenn die Systemarchitektur und die letztendlich verwendeten Komponenten feststehen. Dass dies trotzt des „agilen“, fortlaufend korrigierten Systems der Softwareerstellung bereits zu diesem Zeitpunkt der Fall war, hat die Beklagte nicht vorgetragen. Dementsprechend stellt der Sachverständige auch nicht etwa eine gänzliche Unbrauchbarkeit der (unstreitig unvollständigen) Programmierungsleistungen der Klägerin fest. Vielmehr hält er sie lediglich ohne Beratung aus dem früheren Entwicklerteam für nicht brauchbar. Hätte die Beklagte nicht aufgrund ihrer unstreitigen Zahlungsschwierigkeiten die Weiterführung des Projekts im Januar/Februar 2013 gestoppt, wäre jedoch genau diese Beratung, d. h. die weitere Betreuung des Projekts, durch die Klägerin geschuldet gewesen. Da sich – wie ausgeführt – die Beklagte mit ihrer vereinbarten Zahlungsverpflichtung in Verzug befand, war bis zur Begleichung der aufgelaufenen Forderungen die Klägerin nicht verpflichtet, weiter tätig zu werden. Der Umstand, dass unstreitig die beauftragte Programmierung noch nicht vollständig war, fällt daher nicht der Klägerin zur Last.
- Sichere Softwareentwicklung: Ein Leitfaden zur Risikovermeidung und Qualitätssteigerung - November 10, 2024
- Open Source AI Definition 1.0 - Oktober 31, 2024
- Überblick über das Softwarerecht in Deutschland: Wichtige rechtliche Probleme bei der Softwareentwicklung und -vermarktung - September 21, 2024
