Ein mittelständisches Unternehmen beauftragt einen IT-Dienstleister mit der Entwicklung einer individuellen Unternehmenssoftware. Die Parteien einigen sich auf ein agiles Vorgehen: Sprints, Product Backlogs, wöchentliche Reviews. Nach einem Jahr und erheblichen Zahlungen steht das System – aber es erfüllt die ursprünglich vereinbarten Kernfunktionen nicht. Wer haftet? Welches Vertragsrecht gilt? Und welche Rechte hat der Auftraggeber noch?
IT-Projektverträge über agile Softwareentwicklung sind nach deutschem Recht überwiegend als Werkverträge im Sinne der §§ 631 ff. BGB zu qualifizieren, wenn ein funktionsfähiges Softwareprodukt als Ergebnis geschuldet ist. Diese Einordnung bestimmt die Gewährleistungsrechte, die Abnahmepflicht und die Haftung des Auftragnehmers maßgeblich. Für Geschäftsführer im Mittelstand bedeutet das: Ohne klare vertragliche Leistungsbeschreibung und ohne dokumentierte Abnahme drohen erhebliche Lücken im Rechtsschutz – und eine persönliche Haftungsexponierung, wenn IT-Projekte scheitern und die Gesellschaft Schaden nimmt.
Dieser Beitrag analysiert die werkvertragliche Einordnung des IT-Projektvertrags, erörtert die besonderen Friktionen, die agile Methoden im Rechtsrahmen des BGB erzeugen, und zeigt Gestaltungsoptionen auf, mit denen der Mittelstand seine Position rechtssicher strukturieren kann.
Werkvertrag oder Dienstvertrag? Die Vertragstypenabgrenzung als Grundsatzfrage
Die rechtliche Qualifikation des IT-Projektvertrags entscheidet über Gewährleistung, Abnahme und Kündigungsrecht – und ist deshalb die erste und zugleich folgenreichste Rechtsfrage jedes Projekts.
Das BGB kennt zwei relevante Grundtypen: den Werkvertrag (§ 631 BGB), der auf einen bestimmten Erfolg gerichtet ist, und den Dienstvertrag (§ 611 BGB), der lediglich die Erbringung von Tätigkeiten schuldet. Bei der Entwicklung einer individuellen Unternehmenssoftware sprechen starke Argumente für die werkvertragliche Einordnung: Der Auftraggeber verfolgt typischerweise ein konkretes wirtschaftliches Ziel – ein lauffähiges System, das seine Prozesse unterstützt. Er schuldet nicht Programmierleistung in der Stunde, sondern ein funktionierendes Produkt. Wo diese Erfolgsorientiertheit im Vertrag zum Ausdruck kommt, greift das Werkvertragsrecht.
Die Konsequenzen sind erheblich. Der Auftragnehmer schuldet nach § 633 BGB ein mangelfreies Werk. Liegt ein Mangel vor, stehen dem Auftraggeber die §§ 634 ff. BGB zur Seite: Nacherfüllung, Selbstvornahme, Minderung, Rücktritt, Schadensersatz. Die Verjährungsfrist für Mängelansprüche beträgt bei beweglichen Sachen und bei Softwareerwerb regelmäßig zwei Jahre (§ 634a Abs. 1 Nr. 1 BGB), sofern keine Schaffung eines Bauwerks vorliegt. Bei Software als Arbeitsergebnis ist dies der einschlägige Rahmen – soweit vertraglich nichts anderes vereinbart wurde.
Dienstvertragliche Elemente treten hingegen dort in den Vordergrund, wo Parties lediglich die Bereitstellung von Entwicklerkapazität vereinbaren, ohne einen bestimmten Funktionsumfang zuzusagen. In der Mandatspraxis sehen wir regelmäßig Verträge, die sprachlich zwischen beiden Typen pendeln – und damit beide Seiten in einer Grauzone belassen, die im Streitfall zu ihrem Nachteil wird.
Wie verändert agile Softwareentwicklung die werkvertragliche Struktur?
Agile Methoden wie Scrum oder Kanban tragen eine spezifische Entwicklungsphilosophie in sich: iteratives Vorgehen, flexible Anforderungen, kontinuierliche Anpassung. Diese Philosophie steht in einer strukturellen Spannung zum Werkvertragsrecht, das auf einen definierten Leistungserfolg ausgerichtet ist.
Das Kernproblem liegt in der Leistungsbeschreibung. Das klassische Werkvertragsrecht setzt voraus, dass der Erfolg bei Vertragsschluss hinreichend bestimmt oder bestimmbar ist. Agile Projekte hingegen beginnen bewusst mit einem unvollständigen Anforderungskatalog – dem sogenannten Product Backlog (der in Sprints zu priorisierende Aufgabenvorrat des Projekts). Leistungsumfang und Funktionalitäten werden iterativ verfeinert. Was schuldet der Auftragnehmer dann rechtlich?
Die Lösung liegt nicht in der Vermeidung des Werkvertragsrechts, sondern in seiner methodenbewussten Ausgestaltung. In der Mandatspraxis empfehlen wir, Projekte in Phasen oder Release-Einheiten zu strukturieren, für die jeweils ein klar definierter Leistungsinhalt (Sprint-Ziele, Akzeptanzkriterien) vereinbart und dokumentiert wird. Jede Phase erhält damit den Charakter eines eigenständigen Teilwerkvertrags – mit eigener Abnahme, eigenem Mängelregime und klarer Fälligkeit der anteiligen Vergütung.
Wird diese Strukturierung versäumt, entsteht eine rechtliche Grauzone: Der Auftraggeber kann nicht eindeutig bestimmen, ob eine gelieferte Teilfunktionalität mangelhaft oder schlicht noch nicht fertiggestellt ist. Gleichzeitig kann der Auftragnehmer keine Abnahme verlangen, solange Gesamtleistung und Fertigstellungskriterien unklar sind. Ohne dokumentierte Abnahmeerklärung beginnt die Gewährleistungsfrist nicht zu laufen (§ 640 BGB). Dieses Problem trifft in der Praxis beide Seiten – erzeugt beim Auftraggeber aber das größere wirtschaftliche Risiko, wenn er weiter bezahlt hat, ohne Mängelrechte formell auslösen zu können.
Welche Mängelrechte bestehen bei gescheitertem IT-Projekt?
Wenn ein IT-Projekt nicht das liefert, was vereinbart war, stellt sich für den Geschäftsführer sofort die Frage nach dem rechtlichen Handlungsrahmen. Die Antwort hängt von drei Faktoren ab: Vertragstyp, Abnahmestatus und Vertragsgestaltung.
Bei werkvertraglicher Einordnung und erklärter Abnahme stehen dem Auftraggeber die gesetzlichen Mängelrechte nach §§ 634 ff. BGB zu. Der erste Schritt ist stets die Nacherfüllungsforderung (§ 635 BGB): Der Auftraggeber setzt dem Auftragnehmer eine angemessene Frist zur Mängelbeseitigung. Erst nach fruchtlosem Fristablauf öffnen sich die weiteren Rechte – Minderung (§ 638 BGB), Rücktritt (§ 636 BGB i. V. m. §§ 323, 326 BGB) und Schadensersatz (§ 634 Nr. 4 BGB i. V. m. §§ 280 ff. BGB).
In der Praxis scheitert die Durchsetzung dieser Rechte häufig an drei Hürden: Erstens fehlt es an einer dokumentierten Leistungsbeschreibung, anhand derer die Mangelhaftigkeit überhaupt belegt werden kann. Zweitens wurde die Abnahme – ausdrücklich oder konkludent – erteilt, ohne dass Mängel vorbehalten wurden (§ 640 Abs. 2 BGB: bei bekannten Mängeln Vorbehalt erforderlich). Drittens greifen vertragliche Haftungsbeschränkungen, die in AGB-Klauseln des Auftragnehmers enthalten sind und die gesetzliche Haftung auf bestimmte Mangelarten oder Maximalbeträge begrenzen.
Liegt hingegen noch keine Abnahme vor – etwa weil das System nie in einen produktiven Betrieb überführt wurde –, kann der Auftraggeber unter Umständen nach § 648 BGB jederzeit kündigen und Vergütungsansprüche des Auftragnehmers auf ersparte Aufwendungen begrenzen. Nach unserer Erfahrung wird dieses Instrument bei stockenden Projekten zu selten und zu spät eingesetzt.
Aus der Mandatspraxis: In einem aktuellen Mandat beriet die Kanzlei ein produzierendes Unternehmen aus dem Maschinenbau-Umfeld mit rund 180 Mitarbeitern. Das Unternehmen hatte über einen Zeitraum von ca. 18 Monaten eine ERP-Individuallösung entwickeln lassen. Das Projekt war auf Basis eines agilen Rahmenvertrags beauftragt worden, der weder Abnahmeprozesse noch Akzeptanzkriterien für einzelne Sprints definierte. Nach Übergabe des Systems zeigte sich, dass wesentliche Buchungsmodule fehlerhafte Ergebnisse lieferten. Vorgehen: Analyse der Vertragsdokumentation, Rekonstruktion der Sprint-Reviews als konkludente Teilabnahmen, Formulierung einer detaillierten Mängelrüge mit Fristsetzung. Ergebnis: Nach Verhandlungen einigte man sich auf eine substanzielle Nachbesserung und eine anteilige Vergütungsreduzierung – ohne Prozess. Das Verfahren demonstriert, wie entscheidend die nachträgliche Dokumentationsarbeit sein kann, wenn die Vertragsgestaltung im Vorfeld lückenhaft war.
Haftung der Geschäftsführung: Wann wird das IT-Projekt zur persönlichen Risikoposition?
IT-Projekte scheitern nicht selten mit siebenstelligen Investitionsvolumina. Für Geschäftsführer einer GmbH stellt sich dann die Frage, ob das unternehmerische Handeln im Rahmen der Business Judgment Rule vertretbar war – oder ob eine Pflichtverletzung nach § 43 GmbHG vorliegt.
Die Business Judgment Rule (§ 93 AktG analog, für die GmbH über § 43 GmbHG entwickelt) schützt Geschäftsführer bei unternehmerischen Entscheidungen, wenn sie auf angemessener Informationsgrundlage und zum Wohl der Gesellschaft gehandelt haben. Bei IT-Projekten bedeutet das konkret: Wurde das Projekt auf Basis einer sorgfältigen Beschaffungsentscheidung beauftragt? Wurde der Vertrag fachkundig geprüft? Wurden Warnzeichen im Projektverlauf frühzeitig erkannt und dokumentiert? Gab es ein funktionierendes Projektcontrolling?
Scheitert ein Projekt, weil diese Sorgfaltspflichten vernachlässigt wurden – etwa weil der Vertrag ohne anwaltliche Prüfung abgeschlossen wurde, weil Meilensteinkontrollen fehlten oder weil trotz offensichtlicher Qualitätsmängel weiter bezahlt wurde –, kann die Geschäftsführerhaftung gegenüber der Gesellschaft entstehen. Die Beweislast für die Sorgfalt liegt nach § 43 Abs. 2 GmbHG beim Geschäftsführer. Das bedeutet: Wer keine Dokumentation vorlegen kann, trägt im Innenverhältnis das volle Risiko.
Nach unserer Erfahrung sind es gerade inhabergeführte Mittelstandsunternehmen, die IT-Projekte im Vertrauen auf persönliche Geschäftsbeziehungen mit Dienstleistern starten – und dabei auf eine belastbare Vertragsgrundlage und ein formalisiertes Projektcontrolling verzichten. Diese Praxis kann im Schadensfall zur erheblichen persönlichen Exponierung der Geschäftsführung führen.
Vertragsgestaltung: Welche Regelungen sind bei agilen IT-Projekten unverzichtbar?
Wer ein IT-Projekt rechtssicher gestalten will, muss die methodischen Besonderheiten agiler Entwicklung in die Vertragsarchitektur übersetzen. Folgende Regelungsbereiche sind nach unserer Einschätzung unverzichtbar.
Leistungsbeschreibung und Akzeptanzkriterien: Für jede Entwicklungseinheit – ob Sprint, Release oder Milestone – sollten messbare Akzeptanzkriterien definiert werden. Diese ersetzen das klassische Pflichtenheft nicht vollständig, ermöglichen aber eine rechtssichere Feststellung der Vertragserfüllung. Fehlen solche Kriterien, wird die Abnahme zum Streitpunkt.
Abnahmeprozess: Die Abnahme (§ 640 BGB) ist der zentrale Schalter im Werkvertragsrecht. Sie begrenzt die Nacherfüllungsphase, startet die Gewährleistungsfrist und begründet die Vergütungsfälligkeit. Bei agilen Projekten empfiehlt sich ein zweistufiger Prozess: eine technische Abnahme durch das Entwicklungsteam nach Sprintende und eine fachliche Abnahme durch den Product Owner des Auftraggebers innerhalb einer definierten Frist. Erkannte Mängel sind ausdrücklich vorzubehalten.
Änderungsmanagement (Change Control): Agile Projekte leben von Anforderungsänderungen. Ohne klares Verfahren für die Vereinbarung und Vergütung von Änderungen entsteht der klassische Streit über „Scope Creep" – die schleichende Ausweitung des Leistungsumfangs ohne entsprechende Vergütungsanpassung. Vertraglich sollte geregelt sein, wer Änderungsanforderungen authorisieren kann, wie sie dokumentiert werden und wie sie die Vergütung beeinflussen.
Quellcode und Nutzungsrechte: Software ist urheberrechtlich geschütztes Werk. Der Auftraggeber erhält nicht automatisch das Recht, den Quellcode zu nutzen, zu verändern oder weiterzuentwickeln. Die Einräumung von Nutzungsrechten nach §§ 31 ff. UrhG muss ausdrücklich und in geeignetem Umfang vertraglich geregelt sein. Fehlt eine solche Regelung, bleibt der Auftraggeber bei Software, für die er vollständig bezahlt hat, auf die Kooperation des Auftragnehmers angewiesen.
Haftungsbeschränkungen kritisch prüfen: IT-Dienstleister verwenden regelmäßig AGB oder Musterverträge, die Haftung auf bestimmte Schadensarten begrenzen oder auf ein Vielfaches der Jahresvergütung deckeln. Solche Klauseln sind im unternehmerischen Verkehr weitgehend zulässig, können aber die Schadensdurchsetzung im Schadensfall erheblich erschweren. Ob eine Klausel im konkreten Fall der Inhaltskontrolle nach §§ 305 ff. BGB standhält, ist stets im Einzelfall zu prüfen.
Urheberrecht und Datenschutz bei agiler Entwicklung: Übersehene Risiken
Neben der werkvertraglichen Dimension werfen IT-Projekte regelmäßig Fragen des Urheberrechts und des Datenschutzrechts auf – insbesondere dann, wenn externe Entwickler, Open-Source-Komponenten oder cloudbasierte Entwicklungsumgebungen eingesetzt werden.
Das Urheberrecht an Software entsteht mit ihrer Schöpfung beim Entwickler (§ 69a UrhG). Für Mitarbeiter in einem Angestelltenverhältnis sieht § 69b UrhG vor, dass der Arbeitgeber an der im Rahmen des Arbeitsverhältnisses geschaffenen Software alle vermögensrechtlichen Befugnisse erwirbt. Für externe Freelancer und Agenturen gilt dies nicht: Dort entsteht das Urheberrecht beim Entwickler, und der Auftraggeber erhält nur die vertraglich eingeräumten Nutzungsrechte. Fehlt eine ausdrückliche Nutzungsrechtseinräumung, droht eine Lücke im Rechtsschutz des Auftraggebers – mit potenziell gravierenden Folgen bei einem Auftragnehmerwechsel oder einer Insolvenz des Dienstleisters.
Wird in der Entwicklungsumgebung mit personenbezogenen Daten – etwa Testdaten aus dem Produktivsystem – gearbeitet, greift zusätzlich die DSGVO. Die Weitergabe solcher Daten an einen externen Dienstleister setzt einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO voraus. Verstöße können Bußgelder von bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes (Art. 83 Abs. 5 DSGVO) nach sich ziehen. In der Praxis werden Testdaten häufig ohne diese Absicherung genutzt – ein Compliance-Risiko, das im Rahmen jeder IT-Projektvorbereitung adressiert werden muss.
Werden Open-Source-Komponenten in das zu entwickelnde System integriert – was bei modernen Softwareprojekten nahezu unvermeidlich ist –, ist die jeweils geltende Open-Source-Lizenz zu prüfen. Copyleft-Lizenzen wie die GPL können bei bestimmten Nutzungs- und Vertriebsszenarien dazu führen, dass der gesamte davon abhängige Quellcode ebenfalls der Open-Source-Veröffentlichungspflicht unterliegt. Diese „Infektionswirkung" kann das Geschäftsmodell des Auftraggebers gefährden, wenn proprietäre Software auf solchen Komponenten aufgebaut wird.
Gegensätzliche Positionen in der rechtswissenschaftlichen Diskussion
Die werkvertragliche Einordnung agiler Softwareentwicklung ist in der deutschen Rechtswissenschaft und Praxis nicht unumstritten. Zwei Positionen stehen sich gegenüber.
Die werkvertragliche Position – vertreten in der überwiegenden Kommentarliteratur und von einer wachsenden Zahl instanzgerichtlicher Entscheidungen – betont, dass der wirtschaftliche Zweck eines IT-Projekts in der Herstellung eines funktionsfähigen Softwaresystems liegt. Auf dieses Ergebnis vertraut der Auftraggeber. Nur das Werkvertragsrecht schützt dieses Interesse angemessen, weil es Mängelrechte, Abnahme und Nacherfüllungsanspruch vorsieht.
Die dienstvertragliche Gegenposition argumentiert, dass agile Entwicklung strukturbedingt keinen definierten Erfolg verspreche. Anforderungen ändern sich, das Endprodukt sei bei Vertragsschluss nicht bestimmbar, und die Vergütung erfolge oft zeitbasiert (nach Mannstunden). In diesem Modell schulde der Auftragnehmer ordnungsgemäße Tätigkeit – nicht ein bestimmtes Ergebnis.
Die Auflösung dieser Spannung liegt nach unserer Einschätzung nicht in einer einheitlichen Qualifikation, sondern in der Vertragsgestaltung: Wer als Auftraggeber werkvertraglichen Schutz will, muss diesen Schutz durch klare Leistungsbeschreibung, Abnahmeprozesse und Erfolgsmaßstäbe im Vertrag verankern. Wer dies versäumt, riskiert, im Streitfall in die schwächere dienstvertragliche Einordnung gedrängt zu werden – mit dem Verlust der §§ 634 ff. BGB-Mängelrechte.
Die vorstehende Darstellung betrifft die typischen Konstellationen in der Praxis. Ihr konkretes IT-Projekt erfordert die Prüfung des Vertragswerks, der Kommunikationshistorie und der einschlägigen Rechtsprechung Ihrer Gerichtsbarkeit. Für eine erste Durchsicht Ihrer Unterlagen erreichen Sie uns unter info@brandtfalk.com.
Entscheidungsmatrix: Welche Vertragsstrategie passt zu welchem Projektszenario?
Nicht jedes IT-Projekt hat dieselbe Risikostruktur. Für die Vertragsstrategie empfiehlt sich eine Differenzierung nach Projekttyp und unternehmerischer Ausgangslage.
Konstellation A – Klar umrissenes Individualentwicklungsprojekt (z. B. CRM-System mit definiertem Funktionskatalog): Vertragstyp Werkvertrag mit Pflichtenheft → Abnahme gemäß § 640 BGB mit Protokoll → Gewährleistung nach § 634a Abs. 1 Nr. 1 BGB → Empfehlung: Vollständiges Pflichtenheft als Vertragsanlage, stufenweiser Zahlungsplan mit Abnahmemeilensteinen verknüpfen.
Konstellation B – Agiles Projekt mit schrittweise konkretisierten Anforderungen: Rahmenvertrag mit werkvertraglichen Sprints → Sprint-weise Teilabnahme mit definierten Akzeptanzkriterien → Kündigung nach § 648 BGB bei dauerhafter Schlechtleistung → Empfehlung: Change-Control-Verfahren und eskalationsfähige Governance-Struktur im Vertrag verankern.
Konstellation C – Ressourcenbasierter Abruf von Entwicklerleistung (Staff Augmentation): Dienstvertrag oder Arbeitnehmerüberlassung (AÜG prüfen) → kein werkvertraglicher Mängelanspruch → Empfehlung: Klare Abgrenzung zur Arbeitnehmerüberlassung, Qualitätssicherung über interne Projektsteuerung.
Der Vergleich der Konstellationen zeigt: Konstellation A gibt dem Auftraggeber den stärksten Rechtsschutz – mit dem Preis einer intensiveren Vorbereitungsphase. Konstellation B ist in der Praxis häufig der wirtschaftlich effizientere Weg, verlangt aber erhöhte Sorgfalt bei der Vertragsgestaltung. Konstellation C ist das geringste rechtliche Risiko für den Dienstleister – und das größte für den Auftraggeber, der auf das Gelingen angewiesen ist, ohne Ergebnisanspruch zu haben.
Praktische Handlungsempfehlung: Sieben Schritte für rechtssichere IT-Projekte
Geschäftsführer, die IT-Projekte verantworten, sollten die folgende Prüfliste als Mindestrahmen verstehen. Sie ersetzt keine anwaltliche Beratung im Einzelfall, gibt aber einen strukturierten Überblick über die relevanten Handlungsfelder.
- Vertragstyp bewusst wählen: Entscheiden Sie vor Vertragsschluss, ob ein Werkvertrag (Erfolgsorientierung) oder ein Dienstvertrag (Tätigkeitsorientierung) dem wirtschaftlichen Zweck des Projekts besser entspricht. Lassen Sie die Wahl durch einen Rechtsanwalt überprüfen.
- Leistungsbeschreibung konkretisieren: Formulieren oder fordern Sie für jede Entwicklungsphase messbare Akzeptanzkriterien. Vage Formulierungen wie „zeitgemäße Benutzeroberfläche" oder „performantes System" sind im Streitfall ohne Wert.
- Abnahmeprozess formalisieren: Definieren Sie im Vertrag, wer die Abnahme erklärt, in welcher Form und innerhalb welcher Frist. Vereinbaren Sie, dass eine Abnahme unter Vorbehalt bekannter Mängel möglich ist.
- Nutzungsrechte vollständig regeln: Stellen Sie sicher, dass der Vertrag die Einräumung der für Ihren Verwendungszweck notwendigen Nutzungsrechte am Quellcode ausdrücklich vorsieht – einschließlich des Rechts zur Weiterentwicklung durch Dritte.
- Open-Source-Compliance sichern: Verpflichten Sie den Auftragnehmer, verwendete Open-Source-Komponenten zu dokumentieren (Software Bill of Materials) und sicherzustellen, dass deren Lizenzbedingungen mit Ihrem Geschäftsmodell vereinbar sind.
- Datenschutz strukturieren: Schließen Sie vor Projektbeginn einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ab, wenn personenbezogene Daten im Entwicklungs- oder Testbetrieb verarbeitet werden. Verwenden Sie anonymisierte oder synthetische Testdaten.
- Eskalationsweg definieren: Regeln Sie im Vertrag, welche Schritte bei dauerhafter Schlechtleistung oder Projektbehinderung folgen – von der Abmahnung über die Kündigung nach § 648 BGB bis hin zur außerordentlichen Kündigung aus wichtigem Grund.
Wird das Projekt trotz dieser Vorkehrungen kritisch, ist frühzeitiges anwaltliches Eingreifen der wirkungsvollste Hebel. Wer wartet, bis das Scheitern offensichtlich ist, hat in der Regel bereits Beweismittel verloren und Fristen versäumt.
Die vorstehende Darstellung betrifft die Regelfälle der Praxis. Ihr konkreter IT-Projektvertrag erfordert die Prüfung des Vertragswerks, der Projektdokumentation und der einschlägigen Kommunikation. Für eine erste Durchsicht Ihrer Unterlagen wenden Sie sich an info@brandtfalk.com.
Verwandte Leistungen
Häufige Fragen zum IT-Projektvertrag und agiler Softwareentwicklung
Ist ein agiler Softwareentwicklungsvertrag immer ein Werkvertrag?
Nicht zwingend. Die Vertragstypenqualifikation hängt davon ab, ob die Parteien einen bestimmten Erfolg – ein funktionsfähiges Softwareprodukt – oder lediglich eine Tätigkeit schulden. Bei agilen Projekten mit ergebnisoffener Anforderungsentwicklung und zeitbasierter Vergütung sprechen Argumente für einen Dienstvertrag. Sobald ein konkretisierter Leistungsumfang für einzelne Phasen vereinbart wird, greift das Werkvertragsrecht. Die genaue Einordnung ist im Einzelfall durch Analyse des Vertragswerks und der Begleitumstände zu bestimmen.
Was passiert, wenn keine Abnahme vereinbart wurde?
Fehlt eine Abnahmeregelung, gilt bei Werkverträgen die gesetzliche Abnahme nach § 640 BGB. Der Auftraggeber ist zur Abnahme verpflichtet, sobald das Werk fertiggestellt und frei von wesentlichen Mängeln ist. Erklärt er keine Abnahme, obwohl diese geschuldet wäre, kann der Auftragnehmer eine Frist setzen; nach deren Ablauf gilt die Abnahme unter Umständen als erteilt. Für den Auftraggeber ist deshalb eine aktive, dokumentierte Abnahmekontrolle – auch mit Mängelvorbehalten – wesentlich.
Wie werden Nutzungsrechte an der entwickelten Software geregelt?
Nutzungsrechte entstehen nicht automatisch beim Auftraggeber. Bei externen Entwicklern oder Agenturen muss die Einräumung der Nutzungsrechte vertraglich ausdrücklich vereinbart werden (§§ 31 ff. UrhG). Notwendig sind typischerweise: das Recht zur Nutzung, zur Bearbeitung und zur Weiterentwicklung durch Dritte sowie das Recht, den Quellcode zu erhalten. Fehlen diese Regelungen, kann der Auftraggeber rechtlich kein selbstständiges System betreiben und ist dauerhaft auf die Mitwirkung des Auftragnehmers angewiesen.
Wann haften Geschäftsführer persönlich für das Scheitern eines IT-Projekts?
Eine persönliche Haftung nach § 43 Abs. 2 GmbHG kommt in Betracht, wenn der Geschäftsführer seine Sorgfaltspflichten verletzt hat – etwa durch Beauftragung ohne angemessene Prüfung, fehlende Kontrolle des Projektverlaufs oder fortgesetzte Zahlung trotz erkennbarer Schlechtleistung. Die Beweislast für ordnungsgemäßes Handeln liegt beim Geschäftsführer. Belastbare Dokumentation des Beschaffungsvorgangs und des Projektcontrollings ist daher nicht nur organisatorisch, sondern rechtlich geboten.
Was ist bei Open-Source-Komponenten im Projekt zu beachten?
Open-Source-Lizenzen variieren erheblich in ihrer Wirkung. Permissive Lizenzen (z. B. MIT, Apache 2.0) erlauben eine weitgehend freie kommerzielle Nutzung. Copyleft-Lizenzen (z. B. GPL) können dazu führen, dass abhängige proprietäre Software ebenfalls unter Open-Source-Bedingungen veröffentlicht werden muss. Auftraggeber sollten den Einsatz von Open-Source-Komponenten dokumentieren lassen (Software Bill of Materials) und die Lizenzkonformität vor der Produktivnahme des Systems prüfen.
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.