Ein mittelständisches Fertigungsunternehmen beauftragt einen Softwaredienstleister mit der Entwicklung einer ERP-Schnittstelle. Nach acht Monaten und erheblichen Abschlagszahlungen ist das System nicht produktiv. Der Dienstleister beruft sich auf geänderte Anforderungen, der Auftraggeber auf mangelhafte Lieferung. Wer trägt das Risiko – und nach welchem Vertragstypus richtet sich die Haftung? Diese Konstellation ist in der Mandatspraxis von BRANDT & FALK keine Ausnahme.
IT-Projektverträge und agile Softwareentwicklung unterliegen in Deutschland primär dem Werkvertragsrecht des BGB (§§ 631 ff. BGB), ergänzt durch dienstvertragliche und lizenzrechtliche Elemente je nach Leistungsgegenstand. Geschäftsführer im Mittelstand tragen das Risiko, bei fehlerhafter Vertragsgestaltung Mängelrechte, Rücktrittsrechte und Schadensersatzansprüche zu verlieren – oder im umgekehrten Fall Zahlungsansprüche durchzusetzen, die vertraglich nicht hinreichend abgesichert sind. Die genaue Einordnung des Vertragstyps, die Definition von Abnahmeregeln und der Umgang mit iterativen Entwicklungszyklen sind die drei entscheidenden Stellschrauben.
Dieses FAQ-Dossier beantwortet die zehn zentralen Fragen, die Geschäftsführer und Justiziare mittelständischer Unternehmen beim Abschluss, der Durchführung und der Abwicklung von IT-Projektverträgen stellen – praxisnah, normgestützt und ohne juristische Umwege.
1. Welcher Vertragstyp gilt für einen IT-Projektvertrag?
Maßgeblich ist, ob der Auftragnehmer einen bestimmten Erfolg schuldet oder lediglich ein Tätigwerden. Schuldet der Dienstleister ein funktionsfähiges Softwareprodukt – etwa eine fertig implementierte Applikation oder eine individuell entwickelte Schnittstellenlösung –, liegt in der Regel ein Werkvertrag nach §§ 631 ff. BGB vor. Die Unterscheidung ist grundlegend: Beim Werkvertrag trägt der Auftragnehmer das Herstellungsrisiko bis zur Abnahme, beim Dienstvertrag (§§ 611 ff. BGB) schuldet er ausschließlich die Arbeitsleistung, nicht das Ergebnis.
In der Mandatspraxis sehen wir regelmäßig, dass Parteien Verträge als „Rahmenvertrag" oder „Projektvertrag" bezeichnen, ohne den Typus klar zu definieren. Die Gerichte orientieren sich dann am Vertragsinhalt und an der Interessenlage. Fehlt eine klare Leistungsbeschreibung, kann selbst ein vermeintlicher Werkvertrag als Dienstvertrag eingeordnet werden – mit der Folge, dass Mängelrechte nicht greifen. Die vertragsrechtliche Qualifikation entscheidet darüber, ob Sie Nacherfüllung, Minderung oder Schadensersatz verlangen können.
Gemischte Verträge sind in der IT-Praxis häufig: Ein Vertrag kann werkvertragliche Pflichten (Entwicklung), dienstvertragliche Pflichten (Beratung, Support) und lizenzrechtliche Elemente (Nutzungsrechte an Standardsoftware) kombinieren. Für jeden Leistungsabschnitt gilt dann der jeweils einschlägige Rechtsrahmen. Lassen Sie diesen Befund frühzeitig anwaltlich klären – spätestens vor der ersten Abschlagszahlung.
2. Was bedeutet agile Softwareentwicklung rechtlich – und wo liegt das Problem?
Agile Methoden wie Scrum oder Kanban sind auf iterative Entwicklung ausgelegt: Anforderungen werden sprint-weise konkretisiert, das Produkt wächst schrittweise. Das klassische Werkvertragsrecht setzt dagegen voraus, dass der geschuldete Erfolg bei Vertragsschluss hinreichend bestimmt ist. Dieser Widerspruch ist das Kernproblem des agilen IT-Vertrags.
Ist der Leistungsgegenstand zu Beginn nicht hinreichend definiert, fehlt es an einem abnahmefähigen Werk im Sinne des BGB. Die Folge kann sein, dass Mängelrechte nicht entstehen, die Vergütungsfälligkeit unklar ist oder der Auftragnehmer ohne definierten Abbruchpunkt weiterarbeitet – auf Kosten des Auftraggebers. Nach unserer Erfahrung ist die fehlende Definition von „Done"-Kriterien die häufigste Ursache für eskalierte IT-Projekte.
Rechtlich empfehlenswert ist die Kombination aus einem Rahmenvertrag (der Grundpflichten, Vergütungsmodell und Urheberrechtsfragen regelt) und einzelnen Sprint-Leistungsscheinen, die jeweils einen hinreichend bestimmten Teilleistungsgegenstand definieren. So lässt sich die werkvertragliche Abnahme auf Sprint-Ebene operationalisieren. Ohne abnahmetaugliche Teilleistungen bleibt der Auftraggeber bis zum Schluss im Risiko. Eine anwaltliche Vertragsgestaltung vor Projektbeginn zahlt sich in dieser Konstellation regelmäßig aus.
3. Wann ist eine Abnahme erforderlich – und welche Folgen hat sie?
Die Abnahme ist das zentrale Scharnier des Werkvertragsrechts. Mit ihr geht die Gefahr des zufälligen Untergangs auf den Auftraggeber über, die Vergütung wird fällig, und die Verjährungsfrist für Mängelansprüche beginnt zu laufen. Für Werke, die kein Bauwerk sind, beträgt die gesetzliche Mängelverjährung nach § 634a Abs. 1 Nr. 1 BGB zwei Jahre ab Abnahme – ein Zeitraum, der bei komplexen Softwareprojekten rasch vergeht.
Abnahme kann ausdrücklich (schriftliche Abnahmeerklärung), konkludent (widerspruchslose Inbetriebnahme) oder fiktiv (§ 640 Abs. 2 BGB: nach Ablauf einer gesetzten Frist ohne Mängelrüge) erfolgen. In der Praxis sehen wir häufig, dass Auftraggeber Software produktiv einsetzen, ohne eine förmliche Abnahme vorgenommen zu haben – und damit ungewollt die Abnahme erklären, ohne Mängelvorbehalte zu dokumentieren.
Empfehlung: Vereinbaren Sie im Vertrag eine schriftliche Abnahmeroutine mit konkretem Abnahmeprotokoll, definierten Abnahmekriterien und einer Rügepflicht für bekannte Mängel. Für agile Projekte: Abnahme je Sprint mit Teilabnahmeprotokoll, das Grundlage für die Schlussvergütung ist. Vergessen Sie nicht, Mängel ausdrücklich unter Vorbehalt zu rügen, wenn Sie trotz Mangel abnehmen.
4. Welche Mängelrechte stehen dem Auftraggeber bei IT-Projekten zu?
Liegt ein Mangel vor – das Werk weicht von der vereinbarten oder nach § 633 BGB gewöhnlich vorausgesetzten Beschaffenheit ab –, hat der Auftraggeber zunächst einen Anspruch auf Nacherfüllung (§ 635 BGB). Erst wenn Nacherfüllung scheitert, verweigert wird oder unzumutbar ist, entstehen weitergehende Rechte: Selbstvornahme mit Kostenerstattung, Minderung, Rücktritt vom Vertrag oder Schadensersatz statt der Leistung.
Die Nacherfüllungspflicht ist ein praxisrelevanter Fallstrick: Der Auftraggeber muss dem Auftragnehmer in der Regel zunächst eine angemessene Nacherfüllungsfrist setzen. Tut er das nicht, riskiert er, seine weitergehenden Rechte zu verlieren oder zumindest zu verzögern. Die Anforderungen an die Fristsetzung sind formal; eine formlose E-Mail reicht grundsätzlich, sollte aber den Mangel präzise beschreiben und eine klare Frist benennen.
Bei Softwareprojekten ist die Abgrenzung von Mängeln und Änderungswünschen (sog. „Change Requests") besonders heikel. Was der Auftraggeber als Mangel betrachtet, wird vom Auftragnehmer oft als vertragsgemäße Lieferung mit nachträglichem Änderungswunsch qualifiziert. Eine detaillierte Leistungsbeschreibung und ein vertragliches Change-Request-Verfahren sind deshalb unverzichtbar. Die Beweislastverteilung folgt den allgemeinen zivilrechtlichen Regeln: Nach Abnahme trägt der Auftraggeber die Beweislast für das Vorliegen des Mangels.
5. Wie regelt man Urheberrecht und Nutzungsrechte im IT-Projektvertrag?
Software ist ein urheberrechtlich geschütztes Werk (§ 69a UrhG), sofern sie das Ergebnis einer eigenen geistigen Schöpfung des Entwicklers ist. Das Urheberrecht verbleibt beim Urheber – also regelmäßig beim Dienstleister oder dessen Mitarbeitern. Der Auftraggeber erhält durch den Projektvertrag keine automatische Eigentumsstellung an der Software; er erwirbt lediglich Nutzungsrechte in dem Umfang, der vertraglich eingeräumt wird.
Für den Mittelstand kritisch: Werden Nutzungsrechte nicht ausdrücklich geregelt, gilt nach § 31 Abs. 5 UrhG der Zweckübertragungsgrundsatz – der Auftraggeber erhält nur die Rechte, die für den erkennbaren Vertragszweck unbedingt erforderlich sind. Das kann bedeuten, dass er die Software zwar intern nutzen, aber nicht weiterentwickeln, abändern oder an Dritte lizenzieren darf. In einem aktuellen Mandat beriet die Kanzlei ein mittelständisches Handelsunternehmen, das eine individuell entwickelte Warenwirtschaftssoftware nach einer Unternehmensübernahme nicht auf die übernehmende Gesellschaft übertragen konnte – weil der ursprüngliche Projektvertrag keine Abtretung oder Übertragung der Nutzungsrechte vorsah. Ausgangslage: Der Erwerber setzte die Software produktiv ein. Vorgehen: Klärung des Rechtsrahmens, Nachverhandlung mit dem Ursprungsdienstleister, vertraglich gesicherter Übergang der erforderlichen Nutzungsrechte. Ergebnis: Lizenzstreit vermieden, Betrieb gesichert.
In einem aktuellen Mandat beriet die Kanzlei ein mittelständisches Handelsunternehmen aus dem Bereich Konsumgütervertrieb. Ausgangslage: Nach einer Unternehmensnachfolge war unklar, ob die im Zielunternehmen genutzte Individualsoftware dem neuen Eigentümer urheberrechtlich zur Verfügung stand. Der ursprüngliche IT-Projektvertrag enthielt keine Regelung zur Rechtekette. Vorgehen: Analyse der bestehenden Vertragslage, Identifikation der urheberrechtlichen Lücken, Verhandlung einer ergänzenden Nutzungsrechtseinräumung mit dem Dienstleister. Ergebnis: Die Softwarenutzung wurde rechtssicher gestellt; eine drohende Unterlassungsverfügung konnte abgewendet werden.
Empfehlung: Regeln Sie im IT-Projektvertrag ausdrücklich, welche Nutzungsrechte eingeräumt werden (ausschließlich oder einfach, zeitlich und räumlich unbeschränkt, übertragbar), ob Quellcode herausgegeben wird, und wie mit Open-Source-Komponenten umzugehen ist. Letzteres ist besonders relevant, da bestimmte Open-Source-Lizenzen (GPL, AGPL) eine Offenlegungspflicht für abgeleitete Werke begründen können.
6. Was gilt bei Projektverzug – und welche Rechte hat der Auftraggeber?
Verzug des Auftragnehmers tritt ein, wenn eine vereinbarte oder durch Mahnung bestimmte Leistungsfrist verstrichen ist (§§ 280, 286 BGB). Bei einem vertraglich vereinbarten Fertigstellungstermin kommt der Auftragnehmer unter Umständen auch ohne Mahnung in Verzug – wenn der Kalendertermin hinreichend bestimmt ist (§ 286 Abs. 2 Nr. 1 BGB). Ab Verzugseintritt kann der Auftraggeber Schadensersatz wegen Verzögerung verlangen und bei Vorliegen der weiteren Voraussetzungen vom Vertrag zurücktreten.
In der IT-Praxis ist die Bestimmtheit von Fertigstellungsterminen häufig unklar formuliert. „Q3 2025" oder „nach ca. zwölf Monaten" begründen keinen hinreichend bestimmten Kalendertermin im Sinne des BGB; eine Mahnung bleibt dann erforderlich. Agile Verträge ohne fixe Enddaten erschweren die Verzugsfeststellung erheblich. Nach unserer Erfahrung eskalieren genau diese Fälle, weil weder Auftraggeber noch Auftragnehmer einen klaren Anknüpfungspunkt für Verzugsfolgen haben.
Praxislösung: Vereinbaren Sie neben dem Gesamtfertigstellungstermin Meilenstein-Termine für wesentliche Teilleistungen. Verknüpfen Sie diese mit vertraglichen Konsequenzen – etwa einem definierten Eskalationsverfahren oder einer Vertragsstrafenoption. Eine Vertragsstrafenklausel ist im B2B-Bereich zulässig, muss aber AGB-rechtlich (§§ 305 ff. BGB) sorgfältig ausgestaltet sein, damit sie einer gerichtlichen Inhaltskontrolle standhält.
7. Wie funktioniert das Change-Request-Verfahren – und warum ist es für Auftraggeber entscheidend?
Change Requests sind Änderungs- oder Erweiterungsanforderungen, die während der Projektlaufzeit entstehen. Sie sind in IT-Projekten unvermeidlich. Ohne ein vertragliches Verfahren zur Steuerung von Änderungen entsteht ein Patt: Der Auftragnehmer behauptet, jede Anforderung sei ein kostenpflichtiger Change Request; der Auftraggeber besteht darauf, die Anforderung sei bereits Teil der ursprünglichen Leistungsbeschreibung.
Ein funktionierendes Change-Request-Verfahren regelt mindestens: (1) wer Änderungen anfordern darf, (2) wie sie schriftlich zu dokumentieren sind, (3) innerhalb welcher Frist der Auftragnehmer eine Aufwandsabschätzung vorzulegen hat, (4) wie Einigung und Beauftragung erfolgen, und (5) ob der Auftragnehmer während der Prüfungsphase verpflichtet ist, weiterzuarbeiten. Ohne diese Regelungen ist das Projektbudget für den Auftraggeber faktisch offen.
Wichtig für Geschäftsführer: Auch mündlich oder per E-Mail erteilte Änderungsaufträge können vergütungspflichtige Verbindlichkeiten begründen. Eine Schriftformklausel im Vertrag, die Änderungen des Leistungsumfangs an die Schriftform bindet, schützt vor ungewollten Mehrkosten – sofern sie AGB-rechtlich wirksam vereinbart ist. Lassen Sie diese Klausel anwaltlich prüfen; formularmäßige Schriftformklauseln können unter bestimmten Voraussetzungen unwirksam sein.
8. Welche Haftungsregelungen sind in IT-Projektverträgen üblich und zulässig?
Haftungsbeschränkungen sind in IT-Projektverträgen Standard. Im B2B-Bereich können Parteien die Haftung vertraglich einschränken – allerdings nicht grenzenlos. Haftungsausschlüsse für Vorsatz und grobe Fahrlässigkeit sowie für die Verletzung von Leben, Körper und Gesundheit sind nach § 309 Nr. 7 BGB unwirksam, wenn sie in Allgemeinen Geschäftsbedingungen vereinbart werden. Im individuell ausgehandelten Vertrag ist der Spielraum weiter.
Üblich sind Haftungsobergrenzen (Caps), die die Gesamthaftung des Auftragnehmers auf ein Vielfaches der Auftragssumme – häufig das ein- bis dreifache der Nettovergütung – begrenzen. Für mittelständische Auftraggeber ist entscheidend: Ist der Cap im Verhältnis zum potenziellen Folgeschaden angemessen? Ein Produktionsstopp infolge eines Softwarefehlers kann betriebswirtschaftliche Schäden verursachen, die ein Vielfaches der Entwicklungskosten übersteigen.
Prüfen Sie im Verhandlungsprozess, ob der Auftragnehmer eine Berufshaftpflicht- oder IT-Haftpflichtversicherung unterhält, und lassen Sie Deckungsumfang und Mindestversicherungssumme vertraglich nachweisen. Nach unserer Erfahrung fehlt diese Regelung in gut einem Drittel der uns vorgelegten IT-Projektverträge. Darüber hinaus sollten Regelungen zur Haftung bei Datenverlust und bei Datenschutzverstößen getroffen werden – letztere können nach Art. 83 DSGVO Bußgelder von bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes auslösen, wenn der Auftragnehmer als Auftragsverarbeiter handelt.
9. Was müssen Geschäftsführer bei grenzüberschreitenden IT-Projekten beachten?
Bei IT-Projekten mit ausländischer Beteiligung – Nearshoring in Osteuropa, Offshore-Entwicklung in Asien oder Beteiligung eines ausländischen SaaS-Anbieters – stellen sich Fragen des anwendbaren Rechts und der Gerichtsstandsvereinbarung. Ohne ausdrückliche Rechtswahl bestimmt sich das anwendbare Recht nach der Rom-I-Verordnung: Für werkvertragliche Leistungen ist dies grundsätzlich das Recht des Staates, in dem der Dienstleister seinen gewöhnlichen Aufenthalt hat.
Für mittelständische Auftraggeber in Deutschland bedeutet das: Ein IT-Projektvertrag mit einem polnischen oder indischen Dienstleister ohne deutsche Rechtswahlklausel unterliegt im Zweifel ausländischem Recht – mit erheblichen Konsequenzen für Mängelrechte, Verzugsfolgen und Streitbeilegung. Eine ausdrückliche Rechtswahl zugunsten deutschen Rechts und ein Gerichtsstandsort in Deutschland sind in grenzüberschreitenden IT-Projekten unverzichtbar.
Zu beachten ist ferner: Wird Software im Auftrag entwickelt und werden dabei personenbezogene Daten verarbeitet, sind die Anforderungen der DSGVO an die Auftragsverarbeitung (Art. 28 DSGVO) zu erfüllen. Das gilt unabhängig davon, in welchem Land der Auftragnehmer sitzt – solange der Auftraggeber in der EU ansässig ist. Bei Drittlandtransfers gelten zusätzliche Anforderungen (Art. 44 ff. DSGVO). Bei grenzüberschreitenden Sachverhalten arbeiten wir mit qualifizierten Berufsträgern in der jeweiligen Jurisdiktion zusammen.
10. Wann sollte ein Geschäftsführer einen IT-Projektvertrag anwaltlich prüfen lassen?
Die ehrliche Antwort: Vor Unterzeichnung, nicht nach der ersten Eskalation. In der Mandatspraxis von BRANDT & FALK kommen Geschäftsführer häufig dann auf uns zu, wenn das Projekt bereits aus dem Ruder gelaufen ist – Abschlagszahlungen geleistet, keine Abnahme dokumentiert, kein funktionierendes Change-Request-Verfahren. Die Handlungsoptionen sind zu diesem Zeitpunkt deutlich eingeschränkter als bei einer präventiven Vertragsgestaltung.
Konkret empfehlen wir eine anwaltliche Prüfung in folgenden Konstellationen: (1) Vertragsvolumen übersteigt eine für das Unternehmen spürbare Größenordnung; (2) der Dienstleister legt eigene AGB vor, die Haftung stark begrenzen; (3) das Projekt beinhaltet individuell entwickelte Software, deren Urheberrechtsfragen ungeklärt sind; (4) es sind personenbezogene Daten involviert und ein Auftragsverarbeitungsvertrag ist noch nicht geschlossen; (5) der Auftragnehmer sitzt im Ausland. Ist das Projekt bereits in Schwierigkeiten, sind Fristsetzung, Mängelrüge und die Dokumentation des Verzugs zeitkritische Schritte, die rechtssicher gestaltet sein müssen.
Welche Instrumente konkret passen – Nacherfüllungsaufforderung, Rücktritt, Schadensersatzklage oder außergerichtliche Einigung –, hängt von den Einzelumständen ab. Die Regelfälle sind bekannt; die Würdigung Ihres konkreten Projekts erfordert die Kenntnis der tatsächlichen Vertragslage und der geleisteten Zahlungen.
11. Wie lassen sich Streitigkeiten aus IT-Projekten vermeiden oder effizient lösen?
Streitigkeiten aus IT-Projekten sind erfahrungsgemäß besonders zeitintensiv, weil technische und rechtliche Sachverhalte eng verflochten sind. Gerichte sind mit der Beurteilung von Softwaremängeln oft auf Sachverständige angewiesen; Verfahren können sich über mehrere Jahre hinziehen. Für den Mittelstand ist das regelmäßig eine erhebliche Belastung – betriebswirtschaftlich und personell.
Präventiv wirksam sind: eine detaillierte, vor Projektbeginn fertiggestellte Leistungsbeschreibung (Pflichtenheft oder Product Backlog mit akzeptierten User Stories); klare Abnahmeregeln; ein Eskalationsverfahren, das vor Einleitung gerichtlicher Schritte eine Mediation oder technische Begutachtung vorsieht; und eine Schiedsklausel für technisch komplexe Streitigkeiten, wenn das Unternehmen bereit ist, auf staatliche Gerichte zu verzichten. Eine vertragliche Mediationsklausel kann die Zeit bis zur Konfliktlösung erheblich verkürzen.
Ist ein Streit unvermeidlich, gilt: Dokumentieren Sie lückenlos – E-Mails, Protokolle, Mängelanzeigen, Abnahmedokumente, Liefernachweise. Die Beweissituation entscheidet in IT-Streitigkeiten häufig über den Ausgang. Wenden Sie sich frühzeitig an einen auf IT-Recht spezialisierten Berater; manche Ansprüche verjähren nach § 634a BGB bereits zwei Jahre nach Abnahme.
12. Welche besonderen Regelungen gelten für SaaS- und Cloud-Verträge?
Software-as-a-Service-Vereinbarungen (SaaS) unterscheiden sich strukturell von klassischen IT-Projektverträgen: Es wird keine Software geliefert und abgenommen, sondern ein dauerhafter Zugang zu einer Softwareanwendung über das Internet gewährt. Rechtlich handelt es sich meist um einen Mietvertrag (§ 535 BGB) oder einen Dauerschuldverhältnis mit dienstvertraglichen Elementen, je nach Ausgestaltung. Mängelrechte des Werkvertragsrechts greifen hier grundsätzlich nicht.
Für Geschäftsführer im Mittelstand bedeutet das: Bei SaaS-Verträgen sind Service-Level-Agreements (SLAs) – also vertraglich vereinbarte Verfügbarkeitsgrade und Reaktionszeiten – das wichtigste Steuerungsinstrument. Fehlen sie, ist der Auftraggeber auf die allgemeinen mietrechtlichen Gewährleistungsregeln angewiesen, die für komplexe Cloud-Dienste oft unpassend sind. Vereinbaren Sie Verfügbarkeitsgarantien, Wartungsfenster und Kompensationsregelungen bei Unterschreitung ausdrücklich.
Datenschutzrechtlich ist der SaaS-Anbieter regelmäßig Auftragsverarbeiter im Sinne von Art. 28 DSGVO. Ein schriftlicher Auftragsverarbeitungsvertrag (AVV) ist Pflicht. Fehlt er, drohen Bußgelder der Datenschutzaufsichtsbehörden. Die Meldung einer Datenschutzverletzung muss binnen 72 Stunden nach Art. 33 DSGVO erfolgen – eine Frist, die auch SaaS-Nutzer trifft, wenn personenbezogene Daten verarbeitet werden und der Anbieter einen Vorfall meldet.
Die vorstehende Darstellung betrifft die Regelfälle des IT-Projektvertragsrechts. Ihr konkretes Projekt erfordert die Prüfung der tatsächlichen Vertragsdokumente, der Kommunikationshistorie und der einschlägigen Rechtsprechung. Für eine erste fachliche Einschätzung Ihrer Situation schreiben Sie an info@brandtfalk.com.
Verwandte Leistungen
Häufig gestellte Fragen zum IT-Projektvertrag und agiler Softwareentwicklung
Welches Recht gilt für einen IT-Projektvertrag in Deutschland?
IT-Projektverträge unterliegen in Deutschland primär dem Werkvertragsrecht der §§ 631 ff. BGB, wenn ein funktionsfähiges Softwareprodukt als Ergebnis geschuldet ist. Ergänzend können dienstvertragliche (§§ 611 ff. BGB) und lizenzrechtliche Regelungen (UrhG) einschlägig sein, je nachdem, welche Leistungen der Vertrag im Einzelnen umfasst. Die genaue Einordnung ist für Mängelrechte und Vergütungsfälligkeit entscheidend; eine anwaltliche Prüfung vor Vertragsschluss ist empfehlenswert.
Was ist bei agilen IT-Projekten rechtlich zu beachten?
Agile Entwicklungsmethoden wie Scrum kollidieren strukturell mit dem Bestimmtheitsgrundsatz des Werkvertragsrechts: Das BGB setzt einen bei Vertragsschluss hinreichend definierten Leistungsgegenstand voraus. Empfehlenswert ist eine Kombination aus Rahmenvertrag und Sprint-Leistungsscheinen, die jeweils abnahmefähige Teilleistungen definieren. Ohne diese Struktur riskiert der Auftraggeber, dass weder Abnahme noch Mängelrechte klar zuzuordnen sind.
Wer ist Eigentümer der entwickelten Software?
Das Urheberrecht an individuell entwickelter Software verbleibt kraft Gesetzes beim Urheber – in der Regel beim Dienstleister. Der Auftraggeber erhält nur die Nutzungsrechte, die im Vertrag ausdrücklich eingeräumt werden. Fehlt eine entsprechende Regelung, gilt der Zweckübertragungsgrundsatz (§ 31 Abs. 5 UrhG): Der Auftraggeber erhält lediglich die Rechte, die für den erkennbaren Vertragszweck unbedingt erforderlich sind. Quellcode, Weiterentwicklungsrechte und Übertragbarkeit müssen ausdrücklich geregelt werden.
Welche Fristen gelten bei Mängeln an Software?
Die gesetzliche Mängelverjährungsfrist für Werke, die keine Bauwerke sind, beträgt nach § 634a Abs. 1 Nr. 1 BGB zwei Jahre ab Abnahme. Die Frist beginnt erst mit der wirksamen Abnahme zu laufen. Wird eine förmliche Abnahme versäumt oder konkludent durch Inbetriebnahme erklärt, kann der genaue Fristbeginn streitig sein. Vertragliche Abweichungen sind im B2B-Bereich grundsätzlich zulässig, unterliegen jedoch der AGB-rechtlichen Inhaltskontrolle.
Ist eine Vertragsstrafe bei IT-Projekten möglich?
Im B2B-Bereich sind Vertragsstrafen für Terminüberschreitungen grundsätzlich zulässig. Sie müssen jedoch verhältnismäßig ausgestaltet sein und AGB-rechtlichen Anforderungen genügen, wenn sie in Allgemeinen Geschäftsbedingungen vereinbart werden. Üblich ist eine Obergrenze des kumulierten Vertragsstraffenbetrags. Eine Vertragsstrafe schließt weitergehenden Schadensersatzanspruch nicht aus, sofern der Schaden die Strafenhöhe übersteigt und nicht ausdrücklich auf die Strafe beschränkt wurde.
Was ist ein Auftragsverarbeitungsvertrag (AVV) und wann ist er Pflicht?
Verarbeitet ein IT-Dienstleister im Rahmen des Projekts personenbezogene Daten im Auftrag des Auftraggebers, ist ein schriftlicher Auftragsverarbeitungsvertrag nach Art. 28 DSGVO verpflichtend. Er regelt Gegenstand und Dauer der Verarbeitung, Weisungsrechte des Auftraggebers und Sicherheitsmaßnahmen des Auftragnehmers. Fehlt der AVV, drohen Bußgelder der Datenschutzaufsichtsbehörden. Die DSGVO sieht bei Verstößen Sanktionen von bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes vor.
Kann ich von einem IT-Projektvertrag zurücktreten?
Ein Rücktritt vom Werkvertrag ist möglich, wenn der Auftragnehmer die vereinbarte Leistung nicht oder mangelhaft erbringt und eine angemessene Nacherfüllungsfrist erfolglos abgelaufen ist (§§ 634 Nr. 3, 636, 323 BGB). Bei einem Dauerschuldverhältnis (z. B. SaaS-Vertrag) ist nicht Rücktritt, sondern Kündigung aus wichtigem Grund das einschlägige Instrument. Die genauen Voraussetzungen sind im Einzelfall zu prüfen; insbesondere müssen Mängelrüge und Fristsetzung formal korrekt erfolgt sein.
Welche Risiken bestehen bei Open-Source-Komponenten im IT-Projekt?
Viele Dienstleister verwenden Open-Source-Bibliotheken in der Softwareentwicklung. Je nach Lizenzmodell – insbesondere bei GPL- oder AGPL-lizenzierten Komponenten – kann eine sogenannte Copyleft-Verpflichtung entstehen: Wer abgeleitete Software weiterverbreitet, ist verpflichtet, den Quellcode offenzulegen und unter denselben Lizenzbedingungen freizugeben. Für Auftraggeber, die Software kommerziell nutzen oder weiterveräußern möchten, ist eine genaue Prüfung der im Projekt eingesetzten Open-Source-Lizenzen unverzichtbar. Vertraglich sollte der Dienstleister zur Offenlegung aller verwendeten Open-Source-Komponenten verpflichtet werden.
Die vorstehende Darstellung betrifft die typischen Konstellationen des IT-Projektvertragsrechts. Zur Klärung, wie die dargestellten Grundsätze auf Ihr konkretes Projekt wirken, wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar. Er ersetzt nicht die anwaltliche Prüfung Ihres konkreten Sachverhalts. Für eine auf Ihre Situation zugeschnittene Beratung wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag ist eine allgemeine Information und stellt keine Rechtsberatung dar. Für eine Prüfung Ihres Falls kontaktieren Sie info@brandtfalk.com.