Die agile Softwareentwicklung hat sich in internationalen Projekten zur Standardmethode entwickelt. Kaum ein SaaS-Startup oder Entwicklerteam arbeitet noch ausschließlich vor Ort oder in festen Strukturen. Remote-Work, Nearshoring, Offshoring und hybride Teamstrukturen führen dazu, dass Sprint-Zyklen, Code-Reviews, Deliverables und Rechtezuweisungen über unterschiedliche Zeitzonen, Rechtsordnungen und Kommunikationskulturen hinweg organisiert werden müssen. Dieser Wandel eröffnet enorme Chancen, bringt aber zugleich erhebliche rechtliche Risiken mit sich, insbesondere wenn es um die Rechteeinräumung, die Abgrenzung zwischen Dienst- und Werkvertrag, IP-Splitting-Modelle und die Sicherung der wirtschaftlichen Verwertbarkeit des entstandenen Codes geht.

Die Praxis zeigt immer wieder, dass gerade im internationalen Umfeld typische Auslegungsfehler auftreten: Unklare Verantwortlichkeiten, gemischte Vertragsstrukturen, fehlende Dokumentation, unbeabsichtigte IP-Gaps, divergierende Rechtsansichten zu Git-Commits, unausgesprochene Lizenzmodelle und falsch verstandene „agile Freiheiten“. Spätestens dann, wenn ein Projekt in Verzug gerät, ein Investor eine Due-Diligence durchführt oder Streit über Eigentum am Code entsteht, zeigt sich, wie entscheidend eine klare rechtliche Struktur ist.

Dieser Beitrag beleuchtet die juristischen Grundlagen, typische Problemkonstellationen und praxisnahe Lösungsstrategien – mit besonderem Fokus auf Rechteklärung, IP-Splitting-Modelle, die Abgrenzung von § 631 BGB (Werkvertrag) zu § 611 BGB (Dienstvertrag) und den Aufbau einer robusten Vertragsarchitektur für internationale agile Projekte.

Agile Entwicklung und die Abgrenzung von Dienst- und Werkvertrag: Warum die rechtliche Einordnung über Erfolg, Risiko und Haftung entscheidet

Die Unterscheidung zwischen Werk- und Dienstvertrag wirkt auf den ersten Blick wie eine juristische Formalität, ist jedoch in der Praxis einer der wichtigsten Faktoren für Streitprävention. Die agile Softwareentwicklung bewegt sich typischerweise zwischen beiden Welten. Sprints werden geplant, User Stories definiert, Deliverables eingegrenzt. Dennoch wird in agilen Projekten häufig kein konkreter Erfolg geschuldet, sondern ein iterativer Prozess, der Anpassungen zulässt.

Der Werkvertrag (§ 631 BGB) verpflichtet den Entwickler, einen bestimmten Erfolg herbeizuführen. Dies kann ein Feature, eine API, ein lauffähiges Modul oder eine definierte Funktionalität sein. Das Risiko liegt stärker beim Entwickler: Bei Mängeln oder Nichterreichen des Ziels entstehen Gewährleistungs- und Nachbesserungspflichten.

Der Dienstvertrag (§ 611 BGB) hingegen schuldet nur die Tätigkeit, nicht den Erfolg. Der Entwickler erbringt Leistungen, die wirtschaftlich wertvoll sind, ohne dass ein bestimmter Output garantiert wird. Diese Struktur ist im agilen Umfeld oft sachgerechter, da iterative Anpassungen und variable Sprintinhalte schwer messbare Erfolgsmerkmale erzeugen.

In internationalen Teams werden beide Modelle oft vermischt – meist ohne dass die Beteiligten dies bewusst wahrnehmen. Ein Unternehmen glaubt, einen Werkvertrag abgeschlossen zu haben, weil User Stories definiert sind. Das Entwicklerteam arbeitet jedoch faktisch wie in einem Dienstvertrag, da es keinen garantierten Erfolg schuldet. Daraus ergeben sich klassische Streitpunkte: Wer trägt das Risiko eines Verzugs? Wer haftet für Fehlfunktionen? Was passiert bei Abnahmeverweigerung? Welche Rechte entstehen am Code während des Entstehungsprozesses?

Gerade bei der Einbindung externer Entwickler, Agenturen, Freelancern oder Nearshore-Teams ist daher eine eindeutige vertragliche Einordnung zwingend erforderlich. Eine saubere Definition der Rechtsnatur entscheidet darüber, welche Pflichten entstehen, welche Abnahmen wirksam sind, welche Ansprüche bestehen und wie Veränderungen im Projekt zu behandeln sind.

Rechteeinräumung und IP-Splits in der agilen Entwicklung: Warum modulare Rechtezuweisung unverzichtbar geworden ist

Die zentrale Frage in jedem Softwareprojekt lautet: Wer besitzt welche Rechte am Code? Die Annahme vieler Startups, dass Rechte automatisch auf den Auftraggeber übergehen, ist juristisch falsch und in internationalen Projekten sogar brandgefährlich. Rechte entstehen grundsätzlich bei dem, der sie schafft – oder bei dem Unternehmen, das den Entwickler angestellt hat. Wird ein externer Entwickler eingebunden, entstehen die Rechte zunächst bei diesem oder bei seiner lokalen Arbeitgeberstruktur.

Gerade in agilen Projekten entstehen viele unterschiedliche Rechte: Rechte an einzelnen Modulen, an API-Schnittstellen, an Architekturkonzepten, an UX-Designs, an Testskripten oder an Infrastrukturkomponenten. In internationalen Projekten entstehen häufig „verstreute“ Rechteketten, wenn mehrere Entwickler aus verschiedenen Rechtsordnungen arbeiten.

Ein sogenanntes IP-Splitting-Modell strukturiert diese Rechte und legt fest, wer welche Bestandteile des Projekts schafft, nutzt oder weitergeben darf. Diese Modelle definieren drei Kernbereiche:

1. Originäre IP
Hierzu zählen Rechte, die ein Entwickler bereits mitbringt: Frameworks, Libraries, interne Tools, proprietäre Module, die Agenturen oder Teams bereits vorher entwickelt haben. Ohne klare vertragliche Abgrenzung kommt es bei späteren Produktintegrationen regelmäßig zum Streit über Lizenzmodelle, Gewährleistung und Herausgabepflichten.

2. Projektbezogene IP
Diese Rechte entstehen während der Entwicklung: Code, Architekturentscheidungen, Sprints, UX-Designs, Logikstrukturen, Implementierungsdetails. Diese Rechte müssen vertraglich vollständig und endgültig auf den Auftraggeber übertragen werden, damit ein Investor oder Kunde am Ende ein belastbares Produkt besitzt.

3. Gemeinsame oder abgeleitete IP
Hierunter fallen Inhalte, die auf bestehenden Modulen basieren oder durch die Zusammenarbeit verschiedener Parteien entstehen. Ohne klare Regeln kann es dazu kommen, dass ein Unternehmen nicht eindeutig besitzt, was es produziert hat, weil einzelne Entwickler oder Agenturen Eigentumsanteile oder Nutzungsrechte behalten.

Diese drei Ebenen sind in internationalen Teams besonders relevant, weil häufig nicht nur unterschiedliche Entwickler beteiligt sind, sondern auch unterschiedliche rechtliche IP-Kulturen existieren. In einigen Ländern sind automatische Rechteübertragungen üblich, in anderen nicht. Zudem können kollektivvertragliche Regelungen, lokale Urheberpersönlichkeitsrechte oder zwingende Arbeitsgesetze die Rechteübertragbarkeit einschränken.

Ein strukturiertes IP-Splitting-Modell schafft Transparenz, hilft bei der Bewertung des Projekts, vermindert Streitpotenzial und ist für spätere Finanzierungsrunden essenziell. Kein Investor akzeptiert ein Produkt, dessen Rechtekette nicht nachvollziehbar ist.

Typische Auslegungsfehler in internationalen agilen Projekten: Missverständnisse, kulturelle Unterschiede und unklare Dokumentation

Internationale Entwicklerteams arbeiten oft hochprofessionell, dennoch treten immer wieder dieselben Auslegungsfehler auf – juristische wie organisatorische. Der erste Fehler besteht darin, dass viele Startups davon ausgehen, die agile Methode erlaube automatisch ein flexibles Vertragsverständnis. Tatsächlich führt gerade diese Annahme häufig zu Streit. Agile Prozesse sind flexibel, Verträge müssen es dagegen nicht sein. Im Gegenteil: Gute Verträge schaffen den Rahmen, in dem agile Methoden erst rechtssicher funktionieren.

Ein weiterer typischer Auslegungsfehler betrifft die Abnahme. Während in Deutschland und vielen EU-Staaten eine formelle Abnahme im Werkvertragsrecht eine zentrale Rolle spielt, ist sie in anderen Ländern weitgehend unbekannt. Entwicklerteams gehen dann davon aus, dass ein Sprint abgeschlossen ist, sobald die Codebasis in Git gepusht wurde. Auftraggeber hingegen gehen davon aus, dass erst eine explizite Abnahme den Sprint abschließt. Diese Divergenz führt häufig zu unbeabsichtigten Verzugsansprüchen, Streit über Mängel oder Unklarheiten über die Vergütung.

Auch die Dokumentation ist ein kritischer Punkt. Agile Dokumentation basiert auf User Stories, Backlogs, Tickets und Commit-Nachweisen. Diese sind jedoch nur dann juristisch verwertbar, wenn sie eindeutig sind. Fehlende oder oberflächliche Dokumentation führt dazu, dass unklar bleibt, welches Modul wann erstellt wurde und welcher Entwickler welche Rechte übertragen muss.

Ein häufiger Fehler in internationalen Projekten besteht zudem darin, dass Unternehmen glauben, ein Git-Commit belege automatisch ein Recht. Tatsächlich handelt es sich bei einem Commit lediglich um einen technischen Zeitstempel ohne rechtliche Aussagekraft zur Inhaberschaft. Ohne vertragliche Grundlage entsteht kein Übergang von Rechten.

Schließlich entsteht Streit oft dadurch, dass internationale Teams ihre Lizenzmodelle unterschiedlich interpretieren. Ein Entwickler versteht „Nutzungsrecht“ als einfache Nutzungslizenz. Der Auftraggeber versteht es als vollständige Rechteübertragung. Diese Unterschiede führen zu erheblichen Risiken, insbesondere dann, wenn das Projekt später verkauft oder externalisiert werden soll.

Eine belastbare Vertragsarchitektur für internationale agile Teams: Rechteketten, Vergütung, Geheimhaltung, Remotebindung und Streitprävention

Ein professionelles Vertragsmodell ist der effektivste Schutz vor Projektabbrüchen, Rechtsunsicherheiten oder Investorenproblemen. Die Vertragsarchitektur sollte sich an der agilen Methode orientieren, ohne deren Struktur zu übernehmen. Ziel ist eine Kombination aus Flexibilität und Rechtssicherheit.

Die Basis bildet ein Master Service Agreement (MSA), das die rechtlichen Rahmenbedingungen definiert: Rechteübertragung, Haftung, Vergütung, Vertraulichkeitsregeln, Datenschutz, internationale Zuständigkeiten und Streitbeilegungsverfahren. Ergänzend dazu werden in Statements of Work (SOW) die konkreten Arbeitspakete, Sprints, Meilensteine und Deliverables definiert. Diese Kombination erlaubt es, den rechtlichen Rahmen stabil zu halten und die Projektinhalte flexibel anzupassen.

Wesentliche Bestandteile eines solchen Vertragsmodells sind:

Rechteübertragung
Alle im Projekt entstandenen Rechte müssen vollständig, unwiderruflich und global übertragen werden. Die Formulierung muss sicherstellen, dass auch zukünftige Rechte, Versionen, Derivate und modulare Erweiterungen erfasst sind.

Lizenzmodelle für originäre IP
Wenn Entwickler oder Agenturen eigene Tools einbringen, müssen deren Nutzungsrechte präzise definiert werden. Ohne klare Regelungen entstehen häufig Lizenzkonflikte, die später kostspielig werden.

Vergütungsmodelle
Agile Projekte arbeiten mit Zeitmodellen, Pauschalen, Sprintmodellen oder hybriden Strukturen. Verträge müssen klar definieren, wofür bezahlt wird, wie Meilensteine entstehen und was im Falle von Verzug oder unklaren Ergebnissen gilt.

Abnahmeprozesse
Ein definierter Abnahmeprozess ist essenziell. Er sollte sowohl technische Kriterien (Testing, QA, Performance) als auch formelle Schritte umfassen.

Internationale Zuständigkeit
Gerichtsstand und anwendbares Recht müssen eindeutig sein. Internationale Teams erzeugen Konflikte, wenn mehrere Rechtsordnungen unklar nebeneinander stehen.

Geheimhaltung und Datenschutz
Remote-Work erfordert erhöhte Anforderungen an Geheimhaltung, Zugriffsschutz, Datenverarbeitung und technische Schutzmaßnahmen.

Streitbeilegung
Ein standardisierter Eskalationsprozess – inklusive Mediation, Tech-Review oder arbitrageähnlichen Verfahren – verhindert, dass kleine Konflikte zu Projektabbrüchen führen.

Fazit: Agile Entwicklung gelingt nur mit klaren Rechten, strukturiertem IP-Splitting und einer belastbaren juristischen Grundlage

Agile Softwareentwicklung ermöglicht enorme Geschwindigkeit und Flexibilität. Doch gerade in internationalen Projekten entstehen rechtliche Herausforderungen, die ohne klare Vertragsstrukturen kaum beherrschbar sind. Die Abgrenzung zwischen Werk- und Dienstvertrag, die Rechteübertragung, die Definition originärer IP, die Dokumentation des Entwicklungsprozesses und die verlässliche Vertragsarchitektur entscheiden darüber, ob ein Projekt erfolgreich abgeschlossen werden kann – und ob es später verkaufbar, skalierbar oder investorenfähig ist.

IP-Splitting-Modelle schaffen Transparenz und verhindern Streit über Eigentums- und Nutzungsrechte. Professionelle Verträge sichern die wirtschaftliche Verwertbarkeit des Codes. Und ein strukturierter Rahmen ermöglicht es, agile Methoden rechtssicher anzuwenden.

Startups, SaaS-Unternehmen und internationale Entwicklerteams sollten daher frühzeitig investieren – nicht in mehr Code, sondern in klare Rechteketten, verständliche Verträge und eine rechtlich fundierte Struktur, die agiles Arbeiten erst ermöglicht. Nur dann entsteht ein Produkt, das nicht nur technisch überzeugt, sondern auch rechtlich belastbar ist.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.