Ein Startup entwickelt sein Flaggschiff-Produkt seit 2 Jahren. Das Team besteht hauptsächlich aus Entwicklern von Body-Leasing-Unternehmen - 8 von 10 Personen. Kernalgorithmus, Architektur, gesamte Codebasis von externen Spezialisten geschrieben. Series-B-Finanzierungsrunde kommt, Due Diligence, und eine Frage vom VC-Anwalt: „Haben Sie alle Urheberrechte von Subunternehmern für den Code übertragen bekommen?” Der CEO prüft die Verträge. Stille. Niemand hat daran gedacht.
Diese Situation wiederholt sich in Dutzenden von Unternehmen. Im Eifer schneller Entwicklung vergessen sie eine fundamentale Frage: wem gehört der Code, den externe Spezialisten erstellen? Nach dem Urheberrecht ist die Antwort nicht offensichtlich - und kann sehr kostspielig sein, wenn sie nicht ordnungsgemäß im Vertrag geregelt wird.
Wie behandelt das Urheberrecht Code, der von externen Entwicklern erstellt wurde?
Standardregel: der Schöpfer ist der Eigentümer. Im Urheberrecht stehen die wirtschaftlichen Rechte dem Schöpfer zu - der Person, die das Werk geschaffen hat. Der Entwickler, der den Code geschrieben hat, ist ursprünglich dessen Eigentümer, unabhängig davon, wer ihn bezahlt hat.
Ausnahme: Arbeitnehmerwerk. Wenn ein Werk im Rahmen eines Arbeitsverhältnisses geschaffen wurde, erwirbt der Arbeitgeber die wirtschaftlichen Rechte bei Annahme des Werks. Aber das gilt nur für Arbeitsverträge - nicht für B2B-Verträge, nicht für Dienstleistungsverträge, nicht für Body Leasing.
Body Leasing = kein Arbeitsverhältnis. Ein Entwickler von einem Body-Leasing-Unternehmen ist nicht Ihr Mitarbeiter. Er ist Mitarbeiter (oder Auftragnehmer) des Body-Leasing-Anbieters. Automatische Übertragung von Rechten erfolgt nicht.
Vertrag regelt Übertragung. Damit der Body-Leasing-Kunde Rechte am Code erwirbt, muss dies ausdrücklich im Vertrag geregelt werden. Und zwar in einer spezifischen Weise, die das Urheberrecht vorschreibt.
Rechtekette kann lang sein. Entwickler → Body-Leasing-Unternehmen → Kunde. Jedes Glied muss Rechte ordnungsgemäß übertragen. Eine Lücke in einem Glied = Lücke in der gesamten Kette.
Was sind die rechtlichen Anforderungen für eine wirksame Urheberrechtsübertragung?
Schriftform bei Nichtigkeit erforderlich. Nach Urheberrecht: der Vertrag über die Übertragung von wirtschaftlichen Urheberrechten erfordert Schriftform. Ohne Unterschrift auf Papier (oder qualifizierte elektronische Signatur) - ist die Übertragung unwirksam.
Angabe der Nutzungsfelder. Der Vertrag über die Übertragung von Rechten umfasst nur die Nutzungsfelder, die ausdrücklich darin genannt sind. Allgemeine „Übertragung aller Rechte” ohne Aufzählung der Felder ist riskant.
Nutzungsfelder umfassen beispielsweise:
- Aufnahme und Vervielfältigung (Kopieren)
- Handel mit Original oder Kopien (Verkauf)
- Verbreitung (öffentliche Zugänglichmachung)
- Vermietung, Verleih
- Laden in Computerspeicher
- öffentliche Aufführung, Ausstellung, Vorführung
- Sendung, Weitersendung
- öffentliche Zugänglichmachung (Internet)
Unbekannte Nutzungsfelder. Die Übertragung von Rechten auf zum Zeitpunkt des Vertragsschlusses unbekannte Nutzungsfelder erfordert einen separaten Vertrag. Die Klausel „und alle zukünftigen Nutzungsfelder” ist unwirksam.
Zukünftige Werke mit Einschränkungen. Die Übertragung von Rechten an noch nicht geschaffenen Werken ist möglich, aber sie müssen hinreichend bestimmt sein. „Alles was der Entwickler schreibt” kann zu allgemein sein.
Wie sieht eine ordnungsgemäße Vertragsstruktur bei Body Leasing bezüglich IP aus?
Dreiseitige Beziehung. Entwickler - Body-Leasing-Anbieter - Kunde. Muss regeln: (1) Entwickler überträgt Rechte an Anbieter, (2) Anbieter überträgt Rechte an Kunden. Alternativ: Entwickler überträgt Rechte direkt an Kunden mit Vertretung durch Anbieter.
IP-Klausel im Rahmenvertrag. Der Vertrag zwischen Kunde und Anbieter sollte enthalten:
- Verpflichtung des Anbieters, Übertragung von Rechten von Entwicklern sicherzustellen
- Zeitpunkt der Übertragung (z.B. bei Abnahme von Sprint/Deliverable)
- Liste der Nutzungsfelder
- Erklärung, dass Anbieter das Recht zur Übertragung hat (von Entwicklern)
- Regelung bezüglich im Projekt verwendeter Open-Source-Software
Vertrag zwischen Anbieter und Entwickler. Der Anbieter muss einen Vertrag mit dem Entwickler haben, der:
- Rechte an Werken auf den Anbieter überträgt (oder direkt auf Kunden)
- alle notwendigen Nutzungsfelder abdeckt
- in Schriftform ist
Abtretung vs. Lizenz. Übertragung (Abtretung) bedeutet, der Übertragende verliert Rechte. Lizenz bedeutet, er behält Rechte, erteilt aber Erlaubnis zur Nutzung. Für Code, der dem Kunden gehören soll - Abtretung ist sicherer.
Was ist mit Open-Source-Code und Third-Party-Bibliotheken?
Entwickler erstellt nicht alles von Grund auf. Er nutzt Frameworks, Bibliotheken, Tools. Rechte an diesen Elementen verbleiben bei ihren Autoren. Open-Source-Lizenzen definieren Nutzungsbedingungen.
Permissive Lizenzen (MIT, BSD, Apache 2.0). Erlauben Einbindung in proprietäre Software mit minimalen Anforderungen (Attribution, Erhaltung des Lizenzhinweises). Generell sicher für kommerzielle Projekte.
Copyleft-Lizenzen (GPL, AGPL). Erfordern Verfügbarmachung abgeleiteter Werke unter derselben Lizenz. Nutzung einer GPL-Bibliothek in Ihrem Produkt kann Open-Sourcing Ihres Codes erfordern. AGPL betrifft auch Netzwerknutzung (SaaS).
SBOM und Lizenz-Compliance. Der Kunde sollte eine Liste aller Dependencies und ihrer Lizenzen verlangen. Ohne dies - Risiko der Verletzung von Third-Party-Lizenzen.
Vertrag sollte regeln. Entwickler erklärt, dass: (1) Originalcode original ist, (2) verwendete Third-Party-Komponenten legal lizenziert sind, (3) Lizenzen mit kommerzieller Nutzung durch Kunden kompatibel sind.
Welche Risiken sind mit unzureichender IP-Regelung bei Body Leasing verbunden?
Unfähigkeit zur Verfügung über Eigentum. Wenn Sie keine Urheberrechte am Code haben - können Sie ihn nicht legal verkaufen, lizenzieren, unterlizenzieren. Das blockiert M&A, Produktlizenzierung, Partnerschaften.
Due Diligence in der Investitionsrunde. VC/PE führen IP Due Diligence durch. Fehlende klare Rechte = Red Flag. Kann Investition blockieren oder Bewertung deutlich senken.
Streitigkeiten mit ehemaligen Anbietern. Zusammenarbeit mit Body-Leasing-Unternehmen endet. Sie behaupten, ihr Entwickler hat den Code geschrieben, also haben sie Rechte daran. Ohne klare Verträge - teurer Rechtsstreit.
Ansprüche von Entwicklern. Ein bestimmter Entwickler beendet das Projekt, gründet ein konkurrierendes Unternehmen, behauptet „sein” Code wurde gestohlen. Ohne dokumentierte Übertragung - Risiko.
Probleme beim Exit. Sie verkaufen das Unternehmen, Käufer will Garantien, dass aller Code legal ist. Sie können keine solche Garantie geben, weil Sie keine Verträge mit allen Entwicklern von vor 5 Jahren haben.
Open-Source-Lizenzverletzung. Entwickler verwendete GPL-Bibliothek, Sie wissen es nicht, Sie verkaufen ein Closed-Source-Produkt. FSF sendet Unterlassungserklärung. Reputations- und finanzielle Konsequenzen.
Wie führt man ein IP-Audit der bestehenden Body-Leasing-Zusammenarbeit durch?
Dokumentation sammeln. Alle Verträge mit Body-Leasing-Anbietern. Alle Bestellungen/Statements of Work. Prüfen, ob sie IP-Klauseln enthalten.
Lücken identifizieren. Welche Verträge haben keine Rechteübertragung? Welche haben unvollständige Nutzungsfelder? Welche sind nur in E-Mail-Form (unwirksam)?
Liste der Entwickler und ihrer Beiträge. Wer hat gearbeitet, wann, woran. Mapping von Autoren zu Code. Git blame und Commit-Historie helfen.
Remediation-Plan. Für jede Lücke - Lösung: Vertragsänderung, neue Vereinbarung, Erklärung. Priorisieren nach Risiko und Codewert.
Für ehemalige Mitarbeiter. Wenn Anbieter oder Entwickler nicht mehr zusammenarbeitet - müssen Sie sie finden und nachträglich Vereinbarung unterzeichnen. Kann Verhandlung erfordern (und möglicherweise Vergütung).
Dokumentation für die Zukunft. Standards für alle neuen Zusammenarbeiten einführen: Vertragsvorlage, IP-Checkliste, rechtliche Prüfung.
Was sollte eine IP-Due-Diligence-Checkliste für neue Body-Leasing-Projekte enthalten?
Vor Beginn:
- Enthält Rahmenvertrag IP-Klausel mit vollen Nutzungsfeldern?
- Ist Vertragsform gültig (schriftlich)?
- Erklärt Anbieter, dass er das Recht zur Übertragung hat (von Entwicklern)?
- Ist Open-Source-Software geregelt?
Während des Projekts:
- Hat jeder Entwickler entsprechende Dokumente unterzeichnet?
- Gibt es Tracking, wer welchen Code schreibt (git)?
- Gibt es ein Register der verwendeten Bibliotheken und Lizenzen (SBOM)?
- Umfasst Code Review Prüfung auf problematische Lizenzen?
Bei Abschluss/Deliverable:
- Gibt es formale Abnahme der Werke (Abnahmeprotokoll)?
- Ist Übertragungsdokumentation vollständig?
- Ist SBOM aktuell und verifiziert?
Bei Ende der Zusammenarbeit:
- Wurden alle Rechte übertragen?
- Entwickler behält keine Code-Kopie (außer Portfolio)?
- Bleibt NDA in Kraft?
Wie regelt man Rechte an Tools und wiederverwendbaren Komponenten des Entwicklers?
Entwickler bringt Toolkit mit. Erfahrene Entwickler haben eigene Tools, Snippets, Bibliotheken, die sie in vielen Projekten verwenden. Die Übertragung von Rechten daran an einen Kunden würde weitere Nutzung verhindern.
Lösung: Lizenz statt Abtretung für generische Tools. „Entwickler gewährt Kunden eine nicht-exklusive, unbefristete Lizenz an Tools X, Y, Z, die im Projekt verwendet werden. Rechte an diesen Tools verbleiben beim Entwickler/Anbieter.”
Unterscheidung: projektspezifisch vs. generisch. Code spezifisch für das Projekt (Geschäftslogik, Features) - Abtretung an Kunden. Generischer Code (Utils, Helper überall verwendet) - Lizenz.
Dokumentation der Unterscheidung. Liste der Komponenten mit Bezeichnung: „Abtretung” oder „Lizenz”. Verhindert spätere Streitigkeiten „aber das ist mein Tool!”
Vermeidung von Derivative-Works-Problemen. Wenn projektspezifischer Code ein abgeleitetes Werk des Entwickler-Tools ist - wird die Sache kompliziert. Architektur sollte das berücksichtigen.
Welche Bestimmungen schützen beide Seiten - Kunde und Anbieter?
Für Kunden (Rechteerwerber):
- Erklärung des Anbieters, dass Code original ist und keine Rechte Dritter verletzt
- Garantie, dass Anbieter das Recht zur Übertragung hat (von Entwicklern)
- Freistellungsklausel - Anbieter deckt Schäden aus IP-Ansprüchen Dritter
- Recht zur Unterlizenzierung und Modifikation ohne Einschränkungen
- Keine territorialen oder zeitlichen Beschränkungen
Für Anbieter:
- Klare Angabe, dass Übertragung nach Zahlung erfolgt (IP-Retention als Sicherheit)
- Recht auf Referenz und Showcase (unter Wahrung der Vertraulichkeit)
- Lizenz für generische Tools/Komponenten (verliert nicht sein Toolkit)
- Haftungsbeschränkung auf Vertragswert
- Abnahmeverfahren (nach Abnahme kann Kunde IP nicht anfechten)
Für Entwickler:
- Klarheit über Übertragungsumfang (nicht „alles was Sie jemals erstellen”)
- Erhalt der Rechte am vorbestehenden Toolkit
- Recht auf Portfolio/Demonstration (ohne Geheimnisse preiszugeben)
- Vergütung für Übertragung (im Satz enthalten)
Wie unterscheidet sich die Situation bei verschiedenen Kooperationsmodellen?
Time & Materials Body Leasing: Entwickler arbeitet unter Kundenleitung, Code wird „on the fly” erstellt. Rechteübertragung sollte kontinuierlich sein (z.B. bei jedem Sprint Review) oder automatisch bei Erstellung. Schlüssel: Kontinuität der Übertragung, nicht nur am Projektende.
Festpreis-Projekt: Deliverable ist definiert. Rechteübertragung erfolgt bei Endabnahme (oder Meilenstein). IP-Retention bis Zahlung ist Standard. Kunde muss sicherstellen, dass ALLE Rechte übertragen werden (einschließlich Zwischen-Deliverables).
Managed Services / Outsourcing: Anbieter wartet System, nimmt Änderungen vor. Neuer Code, der im Rahmen der Wartung entsteht - erwirbt Kunde Rechte? Muss ausdrücklich geregelt werden.
Consulting / Advisory: Berater liefert Analysen, Empfehlungen, Dokumentation. Das sind auch Werke im Sinne des Urheberrechts. Werden Berichte, Präsentationen, Spezifikationen übertragen?
Tabelle: IP-Checkliste für Body-Leasing-Vertrag
| Bereich | Zu berücksichtigendes Element | Verantwortlich | Risiko bei Auslassung |
|---|---|---|---|
| Vertragsform | Schriftlich mit Unterschriften (oder qualifizierte E-Signatur) | Legal beider Seiten | Unwirksamkeit der Übertragung |
| Nutzungsfelder | Vollständige Liste (Aufnahme, Vervielfältigung, Verbreitung, Modifikation, Unterlizenz etc.) | Legal Kunde | Eingeschränkte Rechte |
| Rechtekette | Erklärung des Anbieters, dass er Rechte von Entwicklern hat | Anbieter + Legal | Lücke in Kette, unwirksame Übertragung |
| Übertragungszeitpunkt | Festgelegt (bei Abnahme, bei Zahlung, kontinuierlich) | Beide Seiten | Streit über Timing |
| Open Source | Liste erlaubter Lizenzen, SBOM-Anforderung | Development Team + Legal | GPL/AGPL-Lizenzverletzung |
| Vorbestehendes IP | Unterscheidung: Abtretung für projektspezifisch, Lizenz für generisch | Entwickler + Legal | Entwickler verliert seine Tools |
| Freistellung | Anbieter deckt IP-Ansprüche Dritter | Legal Kunde | Kunde trägt Kosten von Streitigkeiten |
| Urheberpersönlichkeitsrechte | Verzicht oder Nichtausübung (Urheberschaft, Integrität) | Legal | Entwickler kann Modifikationen blockieren |
| Territorialer Umfang | „Weltweit” ohne Einschränkungen | Legal Kunde | Eingeschränkte geografische Nutzung |
| Zeitlicher Umfang | „Unbefristet” | Legal Kunde | Rechte laufen aus |
| Dokumentation | Abnahmeprotokolle, Git-Historie, SBOM | PM/Tech Lead | Fehlende Eigentumsnachweise |
| Vertraulichkeit | NDA umfasst Code als vertrauliche Information | Legal beider Seiten | Code-Leak |
Geistiges Eigentum bei Body Leasing ist ein Bereich, in dem Fehler teuer und schwer zu korrigieren sind. Ein Vertrag, der IP „irgendwie” regelt, kann sich als unzureichend erweisen, wenn echtes Geld ins Spiel kommt - Investition, Unternehmensverkauf, Rechtsstreit.
Wichtige Erkenntnisse:
- Standardmäßig gehört dem Entwickler der Code - Übertragung erfordert ausdrücklichen Vertrag
- Schriftform ist verpflichtend - E-Mail oder mündliche Vereinbarung reicht nicht
- Nutzungsfelder müssen aufgelistet werden - „alle Rechte” ist nicht genug
- Rechtekette muss vollständig sein - Entwickler → Anbieter → Kunde
- Open Source hat eigene Lizenzen - SBOM und Lizenz-Compliance sind notwendig
- Vorbestehende Tools des Entwicklers sind separate Frage - Lizenz statt Abtretung
- IP-Audit sollte regelmäßig durchgeführt werden - nicht erst bei Due Diligence
Best Practice: Beauftragen Sie einen auf IP und IT spezialisierten Anwalt bei der Vertragsverhandlung, nicht wenn Probleme auftreten.
Wie schützt ARDURA Consulting Ihr geistiges Eigentum bei Body Leasing?
ARDURA Consulting ist auf rechtssicheres IT-Body-Leasing spezialisiert. Mit einem Netzwerk von über 500 Senior-IT-Spezialisten und 211+ abgeschlossenen Projekten liefern wir verifizierte Experten innerhalb von 2 Wochen — nicht Monaten. Unsere Kunden berichten von 40% Kostenersparnis gegenüber traditioneller Rekrutierung und einer Spezialistenbindungsrate von 99%.
Unsere Verträge enthalten standardmäßig vollständige IP-Klauseln mit klarer Rechtekette, umfassenden Nutzungsfeldern und Open-Source-Compliance. Jeder Spezialist hat die entsprechenden Rechteübertragungen unterzeichnet, sodass unser Kunde saubere Eigentumsrechte am Code erhält — Due-Diligence-ready von Tag eins.
Bereit, rechtssichere Body-Leasing-Zusammenarbeit zu starten? Kontaktieren Sie uns für eine kostenlose Beratung.
ARDURA Consulting bietet transparente Body-Leasing-Verträge mit vollständiger Regelung des geistigen Eigentums. Unsere Kunden erhalten saubere Rechte am Code, Compliance mit Open-Source-Lizenzen und Dokumentation, die Due-Diligence-Anforderungen erfüllt. Kontaktieren Sie uns, um sichere Zusammenarbeit mit externen IT-Spezialisten zu besprechen.