§ 24 IT-Recht / I. Entwicklung von Individualsoftware mit umfassender Rechtsübertragung an Auftraggeber

1. Typischer Sachverhalt

Rz. 1

Der Auftragnehmer entwickelt für den Auftraggeber eine bestimmte Software nach dessen Bedürfnissen. Der Auftraggeber beabsichtigt zwar in erster Linie, die Software für eigene Zwecke in seinem Unternehmen einzusetzen. Er möchte jedoch die Nutzungsrechte möglichst weitgehend erwerben, etwa um die Nutzung der Software durch Konkurrenten auszuschließen und so einen Wettbewerbsvorsprung zu erhalten, oder aber um die Software unter Umständen selbst an Dritte (z.B. Partnerunternehmen) weiter zu lizenzieren.

Um einen optimalen Zuschnitt der Software sicherzustellen, geht der eigentlichen Entwicklung meist eine Planungsphase voraus, die in ein Pflichtenheft zur Umsetzung des Vorhabens mündet. Die Planungsphase kann dabei auch ergeben, dass bestimmte, beim Auftraggeber vorhandene Softwarekomponenten übernommen und angepasst werden können, oder aber, dass Softwarebestandteile von Dritten bezogen werden können.

Eine anderer, im letzten Jahrzehnt immer beliebter gewordener Ansatz ist die agile Softwareentwicklung, bei der – je nach angewandtem Vorgehensmodell unterschiedlich ausgeprägt – auf eine anfängliche Planung ganz oder teilweise verzichtet wird.^[1] Als Beispiele für agile Entwicklungsmethoden genannt seien SCRUM^[2] und Kanban. Der Fokus liegt bei diesen Vorgehensmodellen auf Flexibilität und Schlankheit des Entwicklungsprozesses; Ziel ist es, schneller zu testfähiger, funktionierender Software zu gelangen und besser und zielgerichteter auf Veränderungen in den Anforderungen des Kunden reagieren zu können. Hier gibt es kein Pflichtenheft, sondern die Parteien vereinbaren in sog. "Sprints" oder ähnlich verdichteten Entwicklungsperioden gemeinsam die Arbeitsziele.

Im Anschluss an die Erstellung der Software werden weitere Leistungen erbracht, insb. die Installation der Software beim Besteller sowie die Einweisung der Mitarbeiter des Auftraggebers und ggf. auf Dauer die Pflege der Software.

[1] Vgl. dazu z.B. den Eintrag "Agile Softwareentwicklung" der Wikipedia (https://de.wikipedia.org/wiki/Agile_Softwareentwicklung).

[2] Der offizielle Guide für diese Entwicklungsform ist abrufbar unter https://www.scrum.org/resources/scrum-guide?gclid=CjwKCAiA65iBBhB-EiwAW253W4c4CXlF3l1FDzYMzoYgYDDbLwdu2HTsoft4ajvFWZYeJ_Soqq7YmhoCoP4QAvD_BwE.

2. Rechtliche Grundlagen

a) Vertragsrechtliche Überlegungen

Rz. 2

Bei Verträgen über die Entwicklung von Software handelt es sich klassischerweise um Verträge, die zwischen Unternehmen geschlossen werden. Verbraucherschutzrechtliche Gestaltungsschranken bestehen daher in der Regel nicht. AGB-rechtlich besteht – wenn nicht ohnehin die Vertragsbedingungen im Einzelnen ausgehandelt werden – im Vergleich zum Verbrauchervertrag mehr Gestaltungsspielraum, da die §§ 308 und 309 BGB gem. § 310 Abs. 1 BGB nur als Auslegungsmaßstäbe Anwendung finden.^[3]

Wird ein klassisches Projektvorgehensmodell (z.B. das sog. Wasserfallmodell oder das V-Modell) gewählt, fasst der Vertrag regelmäßig verschiedene Vertragsphasen zusammen (Planung, Erstellung, Installation sowie Einweisung und Schulung). Die Planungsphase kann dienst- oder werkvertraglich ausgestaltet sein. Ersteres ist – bei Schwierigkeiten der Abgrenzung im Einzelfall – der Fall, wenn eine tätigkeitsorientierte Übernahme von Planungsleistungen im Vordergrund steht, Letzteres, wenn ein bestimmter Erfolg geschuldet wird.^[4] Dabei kann es unter Umständen im Hinblick auf die Möglichkeit des Auftraggebers, während der gesamten Planungsphase Einfluss auf strategische Entscheidungen zu nehmen, interessant sein, die Planungsphase eher dienstvertraglich auszugestalten.^[5] Bei werkvertraglicher Ausgestaltung ist aus Sicht des Kunden darauf zu achten, dass das Ergebnis der Planungsphase die Pflichten der nachfolgenden Erstellungsphase nicht zu weitgehend verengt, etwa durch ausschließliche Beschränkung auf ein vom Kunden abzunehmendes Feinkonzept.

Wird hingegen, wie heutzutage in der Regel, ein agiles Projektvorgehensmodell oder eine Mischform gewählt, sollte der Vertrag dieses entsprechend dem tatsächlich geplanten Vorgehen abbilden: Wie wird geplant und festgelegt, was entwickelt wird? In welchen Etappen und nach welchen Regeln wird entwickelt und getestet? Welche Partei ist im Prozess für welche Aspekte der Entwicklung verantwortlich? Was hat zu geschehen, wenn das Entwicklungsprojekt funktional-technisch, zeitlich oder finanziell in Schieflage gerät? Mit Verträgen, die sich strukturell und sprachlich zu sehr an den klassischen Softwareentwicklungsverträgen orientieren (Erstellung des Pflichtenhefts → Umsetzung des Pflichtenhefts → (Gesamt-)Funktionsprüfung mit anschließender (Gesamt-)Abnahme der entwickelten Software), lassen sich in der Praxis die Streitfälle, die in agilen Entwicklungsprojekten typischerweise entstehen, meist überhaupt nicht sinnvoll lösen.

Bei der anschließenden Erstellung und Überlassung von Individualsoftware ist in beiden Fällen – bei klassischen wie auch agilen Vorgehensmodellen – umstritten, ob die werkvertraglichen Regeln anzuwenden sind. Bei klassischen Vorgehensmodellen dreht sich der Streit ...