IP-Splitting in der Co-Entwicklung: Aufteilung geistigen Eigentums
Wenn zwei oder mehr Unternehmen gemeinsam Software oder ein Spiel entwickeln, stellt sich unmittelbar die Frage, wem die Urheberrechte und IP an den gemeinsamen Ergebnissen zustehen. Ohne klare Vereinbarung greift in Deutschland das Urhebergesetz (UrhG): Haben mehrere Personen ein Werk gemeinsam geschaffen und lassen sich die Beiträge nicht getrennt verwerten, gelten sie als Miturheber (§ 8 Abs. 1 UrhG). Das bedeutet, dass ihnen das Urheberrecht gemeinschaftlich zusteht und grundlegende Entscheidungen – etwa Veröffentlichung, Verwertung oder Änderungen – nur einvernehmlich getroffen werden können. Diese gesetzliche Miturheberschaft kann in der Praxis zu einer Blockadesituation führen, wenn keine vorherige Absprache existiert.
In vielen Co-Development-Szenarien ist es jedoch möglich, die Beiträge der Parteien voneinander abzugrenzen. Zum Beispiel könnte ein Studio die Spiel-Engine entwickeln, während das andere die grafischen Assets erstellt. Sind die Beiträge objektiv trennbar und eigenständig verwertbar, liegt kein untrennbares Gemeinschaftswerk vor – jeder bleibt Urheber seines Teils (vgl. Abgrenzung in § 9 UrhG für verbundene Werke). Doch auch in diesem Fall ist eine vertragliche Regelung essenziell: Selbst wenn jeder sein Teilprojekt besitzt, benötigt jeder Partner Nutzungsrechte an den Ergebnissen des anderen, um das Gesamtprodukt nutzen oder vermarkten zu können. Ohne vertragliche Einigung drohen Lücken – etwa dass das Gesamtwerk nicht ohne alle Erlaubnisse verwertet werden darf.
Sinnvolles IP-Splitting per Vertrag: In der Vertragsgestaltung sollte daher explizit festgelegt werden, wie das geistige Eigentum aufgeteilt wird. Einige gängige Ansätze:
Aufteilung nach Beiträgen: Jede Partei behält das Urheberrecht an den von ihr geschaffenen Teilen (Code-Module, Grafiken, Designs etc.), räumt aber der anderen Partei umfangreiche Nutzungsrechte daran ein, damit das Endprodukt wie vorgesehen genutzt und vermarktet werden kann.
Gesamtrechtsübertragung an einen Partner: Häufig vereinbaren Co-Development-Verträge, dass ein Partner (z.B. der Auftraggeber oder Publisher) alle exklusiven Nutzungsrechte an der gesamten Software bzw. dem Spiel erhält. Die andere Partei erhält im Gegenzug eine Vergütung und ggf. beschränkte Rechte (etwa zur internen Weiterverwendung von Libraries oder als Referenzprojekt). Dieser Ansatz vermeidet Streit über Miturheberrechte, da einer klar zum Rechteinhaber bestimmt wird.
Joint Ownership mit Regelungen: Soll gemeinsames IP bewusst geschaffen werden (etwa bei gleichberechtigten Partnern in einer echten Kooperation), muss der Vertrag genau regeln, wie diese gemeinsame Inhaberschaft funktioniert. Denkbar ist z.B. eine Joint-IP-Klausel, die festlegt, dass beide Parteien als Miturheber gelten, jedoch jeder Partner zur Nutzung und Unterlizenzierung berechtigt ist, ohne den anderen zu blockieren – typischerweise gekoppelt an eine Gewinnbeteiligung oder andere Ausgleichsmechanismen. Ohne eine solche Sonderregel würde deutsches Recht nämlich verlangen, dass beide jede Verwertung gemeinsam genehmigen, was in der Praxis unhandlich ist.
Entscheidend ist, proaktiv festzulegen, wer welche Rechte an welchem Bestandteil erhält. IP-Splitting beginnt idealerweise schon in der Planungsphase: Die Parteien sollten identifizieren, welche Komponenten des Projekts Kern-IP darstellen und für wen sie strategisch wichtig sind. Daran orientiert sich, ob man lieber eine klare Zuweisung (eine Seite bekommt z.B. alle Rechte am fertigen Produkt, die andere vielleicht ein Nutzungsrecht an der Technik) oder ein geteiltes Modell wählt. Häufig wird aus Praktikabilität einer eindeutigen Zuweisung der Vorzug gegeben, um spätere komplexe Auseinandersetzungen zu vermeiden.
Rechtezuordnung: Nutzungsrechte, Lizenzen und (k)ein Joint Ownership
Die Rechtezuordnung im Co-Development-Vertrag legt fest, wer das Ergebnis wie nutzen darf. Dabei ist zu beachten, dass nach deutschem Urheberrecht Urheberrechte als solche unveräußerlich sind – der Urheber (Schöpfer) bleibt immer die natürliche Person, bzw. bei Software der die Programmierer. Unternehmen können jedoch umfassende Nutzungsrechte erwerben (§ 31 UrhG). Im Arbeitsverhältnis ist dies vereinfacht: Entwickelt ein Angestellter ein Computerprogramm in Erfüllung seiner Pflichten, gehen die Verwertungsrechte an der Software kraft Gesetzes auf den Arbeitgeber über (vgl. § 69b UrhG). Bei externen Dienstleistern oder Co-Development-Partnern hingegen müssen die Rechte vertraglich übertragen werden. Ohne ausdrückliche Vereinbarung erhält ein Auftraggeber nach dem gesetzlichen Zweckübertragungsgrundsatz (§ 31 Abs. 5 UrhG) nur die Rechte, die für den Vertragszweck unbedingt notwendig sind – oft lediglich ein einfaches Nutzungsrecht. Für die Praxis heißt das: Was nicht ausdrücklich eingeräumt wird, verbleibt beim Ersteller.
Klare Nutzungsrechte-Klauseln: Ein Co-Development-Vertrag sollte daher eine umfassende Regelung zur Rechteübertragung enthalten. Typischerweise wird vereinbart, dass jeder Entwickler alle ausschließlichen Nutzungsrechte an seinen Beiträgen auf den Auftraggeber oder das gemeinsame Projekt überträgt, zeitlich, räumlich und inhaltlich unbegrenzt. So stellt man sicher, dass am Ende keine Lücken bestehen (etwa ein fehlendes Recht zur Veröffentlichung, Vervielfältigung, Änderung oder Vermarktung auf bestimmten Vertriebswegen). Falls eine vollständige Übertragung nicht gewollt ist, kann auch eine Lizenzierung vereinbart werden – z.B. räumt jeder Partner dem anderen an seinen Bestandteilen ein exklusives Nutzungsrecht für das gemeinsame Produkt ein. Wichtig ist, ob Unterlizenzierung gestattet ist: Muss ein Partner das Endprodukt an Dritte (z.B. Kunden oder Publisher) weiterlizenzieren dürfen, so muss das Recht zur Unterlizenzierung ausdrücklich mit eingeräumt werden. Andernfalls dürfte ein Lizenznehmer ohne Zustimmung des ursprünglichen Rechteinhabers keine weiteren Nutzungsrechte an Dritte weitergeben. Eine sauber formulierte Lizenzkette verhindert, dass am Ende einer der Partner die Vermarktung blockieren kann, weil ihm die Erlaubnis fehlt, Rechte weiter zu übertragen.
Joint Ownership – wann (nicht) sinnvoll? Viele juristische Experten raten davon ab, ungeklärte gemeinsame Urheberschaft am Endprodukt stehenzulassen. Joint Ownership (Miturheberschaft ohne klare Regelung) birgt die Gefahr von Stillstand, da – nach deutschem Recht – keiner ohne den anderen das Werk exklusiv verwerten kann. In manchen anderen Ländern (z.B. USA) dürfen Miturheber teilweise eigenständig Lizenzen erteilen; im internationalen Team sollte man solche Unterschiede kennen und im Vertrag vereinheitlichen. Joint Ownership kann sinnvoll sein, wenn beide Seiten das Ergebnis unabhängig verwerten wollen, etwa in unterschiedlichen Märkten oder Anwendungsbereichen. In diesem Fall sollte der Vertrag aber exakt definieren, wer welche Verwertungsrechte hat, wie Erlöse aufgeteilt werden und wie mit neuen Ideen oder Weiterentwicklungen umgegangen wird. Oft ist es geschickter, anstelle von echtem geteilten Eigentum exklusive Rechteaufteilungen zu vereinbaren (etwa Partner A darf das Produkt im Bereich X nutzen, Partner B im Bereich Y), um Überschneidungen zu vermeiden.
Zudem ist zu berücksichtigen, dass Urheber in Deutschland persönliche Urheberrechte (z.B. Recht auf Namensnennung, Schutz vor Entstellung) behalten. Diese können zwar durch Vertrag in der Ausübung eingeschränkt, aber nicht vollständig aberkannt werden. In der Praxis lässt sich dies handhaben, indem etwa Entwickler auf Namensnennung verzichten und sich verpflichten, der notwendigen Bearbeitung des Codes zuzustimmen. So werden mögliche urheberpersönlichkeitsrechtliche Konflikte minimiert.
Praxis-Tipp: Die Rechtezuordnung sollte in einer Kombination aus Lizenz- und Übertragungsklauseln erfolgen, die auch zukünftige Entwicklungen einbeziehen. Etwa: „Der Entwickler überträgt alle derzeit bekannten und zukünftigen Vermögensrechte an den im Rahmen des Projekts entstehenden Arbeitsergebnissen auf den Auftraggeber. Der Auftraggeber ist berechtigt, diese Rechte Dritten einzuräumen oder auf Dritte zu übertragen.…” Solche Formulierungen sichern ab, dass auch neue Verwertungsarten oder Weiterlizenzen abgedeckt sind.
Risikoallokation: Haftung, Gewährleistung und Performance-Risiken
Neben der IP-Verteilung ist die Risikoallokation ein zentrales Element von Co-Development-Verträgen. Hier geht es um die Frage: Wer trägt welche Risiken, etwa für Verzögerungen, Fehler oder Leistungsprobleme im Entwicklungsprozess? Ohne klare Absprachen drohen im Fehlerfall gegenseitige Schuldzuweisungen oder erhebliche finanzielle Schäden für einen Partner. Deshalb sollten folgende Punkte vertraglich abgedeckt werden:
Zeitpläne und Verzögerungen: Co-Development-Projekte haben oft eng getaktete Milestones. Der Vertrag sollte realistische Deadlines für Deliverables setzen und festlegen, was bei Verzögerungen passiert. Üblich sind Vertragsstrafen oder Boni/Malus-Regelungen – z.B. eine pauschale Konventionalstrafe, wenn ein Milestone ohne triftigen Grund nicht erreicht wird, oder Bonuszahlungen bei vorzeitiger Fertigstellung. Alternativ kann vereinbart werden, dass bei bestimmten Verzögerungen ein Rücktrittsrecht oder die Einschaltung zusätzlicher Entwickler auf Kosten des verzögernden Partners möglich ist. Wichtig ist auch, Pufferzeiten einzuplanen und abhängige Leistungen zu koordinieren (wenn Partner A auf Zuarbeit von Partner B angewiesen ist, muss das im Zeitplan reflektiert sein).
Qualitätsanforderungen und Gewährleistung: Der Vertrag sollte klare Qualitätskriterien für die entwickelten Komponenten enthalten. Insbesondere bei Software ist es sinnvoll, Abnahmekriterien zu definieren (siehe nächster Abschnitt zu Deliverables und Abnahme). Jede Partei sollte gewisse Gewährleistungen übernehmen – z.B., dass ihr Code frei von Sachmängeln im Sinne vereinbarter Spezifikationen ist und die gelieferte Arbeit den branchenüblichen Standards entspricht. Auch die Zusicherung, dass keine Rechte Dritter verletzt werden (siehe IP-Gewährleistung unten) gehört hierher. Wird nach Abnahme ein Mangel festgestellt, muss geregelt sein, ob der leistende Partner Nachbesserung schuldet und in welchem Zeitraum. Typisch ist eine kostenlose Nachbesserungsfrist für bestimmte Fehlerklassen.
Haftungsverteilung und -begrenzung: Trotz aller Prävention kann es zu Schäden kommen – etwa Verzögerungsschäden, entgangener Gewinn oder Kosten wegen Fehlern. Co-Development-Verträge sollten festlegen, in welchem Umfang ein Partner gegenüber dem anderen haftet. Im B2B-Verhältnis ist es üblich, die Haftung vertraglich zu begrenzen: Beispielsweise Ausschluss von Haftung für leichte Fahrlässigkeit in nicht-kardinalen Pflichten, oder Deckelung der Haftungshöhe (etwa auf die Auftragssumme oder einen Vielfachen davon). Für grobe Fahrlässigkeit und Vorsatz sowie Verletzungen von Leben, Körper, Gesundheit kann die Haftung nicht ausgeschlossen werden (gesetzliche Grenze). Ebenso werden oft Spezialregelungen getroffen: etwa eine unbegrenzte Haftung für Verletzung von Geheimhaltungspflichten oder bei Verletzung von Schutzrechten Dritter, da hier das Risiko für den anderen besonders gravierend sein kann. Letztlich geht es darum, eine faire Verteilung zu finden: Jeder sollte für seine Sphäre Verantwortung tragen. Beispielsweise kann vereinbart werden, dass jeder Partner für die von ihm gelieferten Teile und daraus resultierende Schäden haftet, während gemeinsame Risiken geteilt werden.
Indemnität bei Drittansprüchen (Schadloshaltung): Gerade bei IP-Risiken ist eine Freistellungsregelung sinnvoll. Wenn etwa Partner A Code liefert, der doch fremde Urheberrechte verletzt, sollte Partner A den Partner B von allen daraus resultierenden Ansprüchen Dritter freistellen und die Verteidigungskosten tragen. Ähnliches gilt für Verletzungen von Datenschutz, Patenten oder sonstigen Rechten durch einen Partner. Diese Klausel stellt sicher, dass der „unschuldige“ Partner nicht auf Kosten sitzen bleibt, die der andere durch pflichtwidriges Verhalten verursacht hat.
Versicherung und Vorsorge: Bei größeren Kooperationen ist es ratsam zu prüfen, ob entsprechende Versicherungen bestehen (z.B. Berufshaftpflicht oder spezielle Cyber-Versicherungen), die bestimmte Schäden abdecken. Der Vertrag kann vorsehen, dass beide Parteien während der Projektlaufzeit einen geeigneten Versicherungsschutz aufrechterhalten.
Eine ausgewogene Risikoallokation schafft Vertrauen zwischen den Partnern. Sie verhindert, dass einzelne Probleme eskalieren: Beide Seiten wissen, welche Konsequenzen im Worst Case drohen und können sich entsprechend absichern. Wichtig ist, dass Haftungsklauseln transparent und verständlich formuliert sind – gerade im internationalen Kontext, wo unterschiedliche Rechtssysteme aufeinandertreffen, müssen die Begriffe und Haftungsbegrenzungen für alle Beteiligten nachvollziehbar sein.
Gemeinsame Assets rechtlich absichern
In Co-Development-Projekten entstehen häufig gemeinsam geschaffene Assets – von Quellcode über Grafiken bis hin zu Dokumentationen oder Tools. Diese gemeinsam genutzten Vermögenswerte sollten vertraglich gesichert werden, damit beide Seiten sie wie beabsichtigt verwenden können und Missbrauch verhindert wird. Folgende Aspekte sind wesentlich:
Definition von Background und Foreground IP: Der Vertrag sollte unterscheiden zwischen Background-IP (alle bereits vor dem Projekt vorhandenen oder unabhängig entwickelten Materialien jedes Partners) und Foreground-IP (alle Ergebnisse, die im Rahmen des gemeinsamen Projekts entstehen). Diese Abgrenzung verhindert Verwirrung darüber, was eingebracht vs. neu geschaffen wurde. In der Regel bleibt Background-IP im Eigentum der jeweiligen Partei, wird aber oft dem Projekt via Lizenz zur Verfügung gestellt. Foreground-IP unterliegt dann den zuvor besprochenen IP-Splitting-Regeln.
Zugangsrechte und Verwahrung: Beide Parteien sollten Zugang zu den gemeinsamen Arbeitsergebnissen haben. Praktisch empfiehlt sich z.B. ein zentrales Repository (etwa Git), auf das beide Seiten Zugriff haben, sodass Code und Assets nicht einseitig zurückgehalten werden können. Vertraglich kann man festlegen, dass in regelmäßigen Abständen alle Arbeitsergebnisse gegenseitig herauszugeben sind. Im Streitfall verhindert dies, dass eine Seite die Assets „beschlagnahmt“. Zudem kann man eine Escrow-Vereinbarung erwägen: Falls ein Partner insolvent wird oder aussteigt, geht eine Hinterlegung (z.B. Quellcode bei einem Escrow-Agenten) an den anderen über, damit das Projekt weitergeführt werden kann.
Nutzungsrechte an gemeinsamen Ergebnissen außerhalb des Projekts: Oft stellt sich die Frage, ob und inwieweit jede Partei die entwickelten Assets auch außerhalb des konkreten gemeinsamen Projekts nutzen darf. Beispielsweise könnte ein Co-Developer Teile des Codes oder Tools später für eigene Kundenprojekte weiterverwenden wollen. Hier gibt es mehrere Ansätze: Man kann strikte Nutzung nur für das gemeinsame Projekt vereinbaren – dann dürfen die Assets nicht anderweitig eingesetzt werden, außer mit Zustimmung der anderen Seite. Oder man räumt gegenseitig weite Nutzungsrechte ein: Etwa darf jeder Partner die gemeinsam erstellten Bausteine auch in anderen Projekten nutzen, solange vertrauliche Informationen oder Markenrechte des anderen nicht verletzt werden. Ein Mittelweg ist, nach Projektende Lizenzen zu vereinbaren – z.B. Partner A darf ein bestimmtes Asset gegen Zahlung einer Lizenzgebühr in eigenen Produkten einsetzen. Wichtig ist, diese Fragen vorab zu klären, um Streit über „Wer darf was damit machen?“ zu vermeiden.
Schutz gemeinsamer Ergebnisse vor Dritten: Der Vertrag sollte beide Seiten verpflichten, die gemeinsamen Assets vor unberechtigtem Zugriff Dritter zu schützen. Das umfasst strenge Geheimhaltungspflichten (NDAs) für Quellcode, Designs, Geschäftsgeheimnisse und alle sensiblen Informationen. Beide Parteien sollten zusichern, dass sie nur befugten Mitarbeitern Zugriff gewähren und geeignete Sicherheitsmaßnahmen einsetzen. Gerade in internationalen Teams, die remote zusammenarbeiten, ist Datenschutz und Schutz geistigen Eigentums essentiell. Falls externe Subunternehmer eingebunden werden, muss vertraglich sichergestellt sein, dass auch diese entsprechenden Geheimhaltungsklauseln unterliegen und keine zusätzlichen Rechte an den Assets erwerben.
Exit-Strategie für gemeinsame Assets: Schließlich sollte man regeln, was mit den gemeinsamen Ergebnissen passiert, wenn die Kooperation endet – sei es nach erfolgreichem Projektabschluss oder vorzeitig durch Kündigung. Eine Exit-Klausel kann festlegen, dass im Falle einer Trennung jede Partei zumindest die von ihr eingebrachten Assets zurückbehält und ggf. eine Nutzungsberechtigung an den gemeinsam geschaffenen Ergebnissen erhält, um keine Entwicklung im Sand verlaufen zu lassen. Beispielsweise könnte vereinbart werden, dass bei vorzeitiger Beendigung jeder Partner ein einfaches Nutzungsrecht an allen bis dahin entstandenen Ergebnissen erhält, um sie intern weiterzuverwenden (mit der Maßgabe, sie nicht an Dritte zu vertreiben). Solche Regelungen verhindern, dass das Projekt vollständig scheitert, nur weil die Partner auseinandergehen – zumindest können die Teilergebnisse genutzt oder weiterentwickelt werden.
Durch diese vertraglichen Vorkehrungen werden gemeinsame Assets sowohl während der Zusammenarbeit als auch danach geschützt. Beide Seiten wissen, woran sie sind, und die Investition in die gemeinsamen Ergebnisse ist rechtlich abgesichert. Für Unternehmen der Games-Branche kann dies z.B. bedeuten, dass Charakter-Modelle, Texturen oder Level-Designs klar zugeordnet oder lizenziert sind; für SaaS-Entwickler, dass gemeinsam programmierte Module oder Schnittstellen nicht in einer Grauzone verbleiben.
Technische Ownership: Engines, Tools und Middleware
Ein oft unterschätzter Bereich in Co-Development-Verträgen ist die technische Ownership – also die Frage, wem Entwicklungswerkzeuge, Engines oder Middleware gehören, die im Projekt genutzt oder geschaffen werden. Gerade in der Spieleentwicklung bringen Partner häufig eigene Engines oder Editor-Tools mit ins Projekt ein. In der Softwareentwicklung werden bestehende Frameworks oder APIs integriert. Folgende Punkte sollten bedacht werden:
Bestehende Engines und Tools (Background-Technologie): Bringt eine Partei eine eigene Engine, ein Framework oder sonstige proprietäre Tools ins Projekt ein, bleibt diese Technologie grundsätzlich Eigentum der einbringenden Partei. Der Vertrag sollte klarstellen, dass keine Übertragung dieses Background-IP erfolgt. Allerdings benötigt der andere Partner typischerweise eine Nutzungslizenz, um mit der Engine/Tool zu arbeiten und das Endprodukt daraus zu erstellen. Daher wird häufig eine zeitlich beschränkte, projektgebundene Lizenz eingeräumt: z.B. Partner B darf die Engine von Partner A ausschließlich für die Entwicklung und den Betrieb des gemeinsamen Spiels nutzen. Wichtig: Wenn der andere Partner auch nach Projektende Wartung oder Erweiterung durchführen soll, muss das Nutzungsrecht entsprechend verlängert oder erweitert werden. Andernfalls endet das Recht, die Engine zu nutzen, mit Abschluss des Projekts.
Weiterentwicklungen von mitgebrachter Technik: Was passiert, wenn im Zuge der Zusammenarbeit die eingebrachte Engine oder ein Tool weiterentwickelt oder angepasst wird? Ohne Regelung könnte daraus neues gemeinsames IP entstehen oder sogar Urheberrechte des anpassenden Partners. Um Konflikte zu vermeiden, vereinbaren Co-Development-Verträge oft, dass Änderungen oder Verbesserungen an der von Partner A gestellten Technik automatisch Partner A zustehen (mit ggf. Nutzungsrechten für Partner B). Das heißt, wenn Partner B an der Engine mitschreibt und sie verbessert, werden diese Verbesserungen an Partner A übertragen – da sie Teil der Engine sind. Alternativ kann man differenzieren: Fehlerbehebungen und allgemeine Verbesserungen gehen an den ursprünglichen Eigentümer, während völlig neue Module separat behandelt werden. Der springende Punkt ist, vorher festzulegen, wem solche Derivate gehören.
Neu entwickelte Tools und Middleware (Foreground-Technologie): Entwickeln die Partner im Laufe des Projekts völlig neue technische Komponenten (z.B. ein Level-Editor, ein Plug-in, ein KI-Modul), muss auch hierfür Ownership geklärt werden. Man kann analog zum IP-Splitting vorgehen: Entweder gehört ein neues Tool dem Partner, der es hauptsächlich entwickelt hat, mit Lizenz an den anderen – oder, wenn es auf gemeinsame Kosten entstand, erhält der Auftraggeber alle Rechte und der Entwickler ein Nutzungsrecht für andere Projekte (oder umgekehrt, je nach Verhandlungsmacht). Hier kommt es stark auf die Interessen an: Ein Dienstleister möchte evtl. ein generisches Tool wiederverwenden dürfen, während der Auftraggeber ausschließen möchte, dass das Tool an den Wettbewerb weitergegeben wird. Ein möglicher praxisnaher Ansatz: Der Auftraggeber erhält exklusiv die Rechte am eigentlichen Produkt (z.B. dem Spiel), aber der Entwickler darf generische Bestandteile wie Editor-Tools oder allgemeine Engines wiederverwenden, sofern darin keine spezifischen Assets des Auftraggebers enthalten sind. Solche Klauseln fördern eine Win-Win-Situation: Der Entwickler baut sein Know-how aus, und der Auftraggeber muss nicht bei Null anfangen, sondern profitiert von erprobter Technik – ohne Sorge, dass Dritte sein konkretes Produkt kopieren.
Drittlizenzen und Open Source: Co-Development-Projekte greifen oft auf Third-Party-Middleware oder Open-Source-Komponenten zurück. Hier ist die Lizenzkette besonders kritisch: Der Vertrag sollte festlegen, wer dafür verantwortlich ist, dass alle externen Komponenten ordnungsgemäß lizenziert sind. Beide Parteien müssen sicherstellen, dass die Nutzung solcher Komponenten im gemeinsamen Produkt zulässig ist. Eine gängige Regelung ist, dass jede Partei garantiert, nur solche Fremdsoftware einzubringen, die sie entweder selbst lizenzieren darf oder die unter einer Lizenz steht, die kompatibel mit dem Verwendungszweck ist. Beispielsweise muss vermieden werden, dass jemand eine Open-Source-Komponente mit viraler Lizenz (GPL) einbaut, die dann das gesamte Produkt unter GPL stellen würde, ohne dass der andere Partner das will. Deshalb sollten Freigabeprozesse im Vertrag etabliert werden: jede Einbindung von Open Source oder Drittsoftware bedarf der Zustimmung beider, und die jeweiligen Lizenzbedingungen sind zu dokumentieren. Außerdem sollten beide Seiten einander freistellen, falls doch ein Verstoß gegen Lizenzbedingungen eines Drittprodukts passiert, den sie zu vertreten haben (vgl. Indemnität oben).
Eine saubere Regelung der technischen Ownership stellt sicher, dass am Ende keine bösen Überraschungen auftreten, etwa dass ein Partner plötzlich Lizenzgebühren für die Nutzung der gemeinsam entwickelten Engine zahlen muss, weil unklar war, wem sie gehört. Gerade in langfristigen SaaS-Co-Entwicklungen (z.B. Integration zweier Systeme) und in der Games-Branche (Engine-Sharing) sind solche Klarstellungen Gold wert. Beide Seiten behalten die Kontrolle über ihr jeweiliges technologisches Fundament und wissen, worauf sie sich nach Projektabschluss stützen können.
Klare Deliverables und Abnahmemechanismen
Ein häufiger Streitpunkt in Entwicklungskooperationen ist die Definition von Deliverables (Lieferergebnissen) und die Abnahme derselben. Unklare Erwartungen führen zu Verzögerungen, Mehrarbeit und Frust. Daher sollte der Vertrag ausführlich regeln, was genau geliefert werden muss, wann und wie die Abnahme erfolgt:
Pflichtenheft und Spezifikation: Zu Beginn des Vertrags oder in einer Anlage sollte festgehalten werden, welche Module, Features, Assets etc. von welcher Partei erstellt werden. Selbst in agilen Projekten ist ein Mindestmaß an gemeinsamer Vorstellung der Ziele nötig. Das Pflichtenheft dient als Referenzrahmen, um später beurteilen zu können, ob ein Deliverable vollständig ist. Änderungen am Umfang (Change Requests) sollten einem definierten Verfahren folgen, damit beide Seiten wissen, dass zusätzliche Leistungen auch separat vergütet oder terminlich neu verhandelt werden müssen.
Milestones und Teillieferungen: Größere Co-Development-Vorhaben teilt man idealerweise in Meilensteine ein. Für jeden Milestone werden konkrete Teilergebnisse definiert (z.B. “Grundfunktion X fertig implementiert”, “Grafikpaket Y geliefert”). Dies erleichtert die Überwachung des Fortschritts und erlaubt bei Verzögerungen ein frühzeitiges Gegensteuern. Jeder Milestone kann mit einer Abnahmeprüfung verbunden werden, deren Kriterien vorab festgelegt sind.
Abnahmeprozess: Der Vertrag sollte festlegen, wie die Abnahme (Acceptance) eines Deliverables erfolgt. Üblich ist eine Frist, innerhalb der der empfangende Partner das Gelieferte testen und entweder abnehmen oder Mängel anzeigen muss. Etwa: “Der Auftraggeber prüft innerhalb von 10 Werktagen nach Lieferung, ob die Ergebnisse den vereinbarten Anforderungen entsprechen. Werden innerhalb dieser Frist keine schriftlichen Mängelrügen mitgeteilt, gilt die Lieferung als abgenommen.” Ebenso sollte geregelt sein, dass bei festgestellten Mängeln der leistende Partner innerhalb angemessener Frist nachbessert und anschließend erneut zur Abnahme vorlegt. Ein formal dokumentierter Abnahmeprozess (z.B. Abnahmeprotokoll) schafft Klarheit. Wichtig: Teilabnahmen für Meilensteine sollten vorgesehen werden, damit bereits fertiggestellte Komponenten als solche bestätigt werden – das verhindert, dass am Ende über Monate an zurückliegenden Punkten diskutiert wird.
Akzeptanzkriterien: Am besten werden konkrete Kriterien vereinbart, wann etwas als “erfüllt” gilt. Beispielsweise Performance-Kennzahlen, Bestehen bestimmter Testfälle, Kompatibilität mit bestimmten Systemen, oder optische Qualitätsstandards bei Grafiken. Sind die Kriterien objektiv und messbar, reduzieren sich Ermessensstreitigkeiten. Beide Seiten sollten bei der Formulierung dieser Kriterien mitwirken, damit sie realistisch und überprüfbar sind.
Konsequenzen der Abnahmeverweigerung: Für den Fall, dass der eine Partner die Abnahme berechtigt verweigert (wegen erheblichen Mängeln), sollte geregelt sein, dass der andere nachbessern muss und ob es finanzielle Konsequenzen gibt (z.B. Verschiebung von Zahlungen bis zur erfolgreichen Abnahme). Sollte trotz wiederholter Nachbesserungsversuche keine vertragsgemäße Leistung erbracht werden, könnte ein Rücktritts- oder Kündigungsrecht vereinbart sein. Andersherum: Unberechtigte Abnahmeverweigerung – etwa um Zahlungen zu verzögern – sollte sanktioniert sein, z.B. gilt nach zwei unberechtigten Verweigerungen die Abnahme als erfolgt oder es greifen Schadensersatzansprüche des liefernden Partners.
Durch klar definierte Deliverables und Abnahmemechanismen wird Transparenz im Entwicklungsprozess geschaffen. Beide Seiten haben die gleiche Erwartungshaltung, was geliefert wird und wann es als fertig gilt. Gerade in agilen Settings sollte der Vertrag eine Brücke zwischen Flexibilität und Verbindlichkeit schlagen – z.B. regelmäßige Sprint-Reviews als faktische Abnahmen einzelner Funktionen, aber trotzdem ein Endkriterium, wann das Produkt marktreif ist. Diese Planung schützt vor endlosen Nachforderungen und stellt sicher, dass am Ende ein abgenommenes Werk steht, mit dem beide zufrieden sind.
Streitbeilegung in internationalen Teams: Gerichtsstand oder Schiedsgericht?
Trotz bester Vertragsgestaltung kann es bei internationalen Co-Development-Projekten zu Konflikten kommen. Unterschiedliche Zeitzonen, Kulturen und Rechtssysteme erschweren die Durchsetzung von Ansprüchen. Daher ist eine kluge Streitbeilegungsklausel Gold wert, um im Ernstfall effizient eine Lösung zu erzielen. Zu beachten sind insbesondere:
Rechtswahl: Zunächst sollte der Vertrag festlegen, welches Recht anwendbar ist (Governing Law). Bei Beteiligung deutscher Unternehmen wird oft deutsches Recht gewählt, gerade wenn viele Urheberrechtsfragen eine Rolle spielen, die nach deutschem UrhG beurteilt werden sollen. Alternativ kommt ein neutrales Recht in Betracht (etwa Schweizerisches Recht oder das eines für beide akzeptablen Drittstaates). Wichtig ist, eine klare Regelung zu treffen – sonst kann im Streit erst aufwendig geklärt werden müssen, welches Recht gilt.
Gerichtsstand vs. Schiedsgericht: Im internationalen Kontext greifen viele erfahrene Vertragspartner auf Schiedsvereinbarungen zurück. Ein Schiedsgericht (Arbitration Tribunal) hat den Vorteil, dass seine Entscheidung in der Regel nach der New Yorker Konvention in vielen Ländern vollstreckt werden kann, während staatliche Gerichtsurteile nur mit Mühe grenzüberschreitend durchgesetzt werden. Zudem lässt sich ein neutrales Forum bestimmen (z.B. ein Schiedsgericht in Stockholm, Paris oder Zürich), was beiden Parteien entgegenkommen kann, anstatt dass eine Partei im Land der anderen klagen muss. Schiedsverfahren sind vertraulich – bei sensiblen IP-Streitigkeiten kann das wichtig sein, um keine Geschäftsgeheimnisse vor Gericht öffentlich machen zu müssen. Andererseits sind Schiedsverfahren mitunter teuer. Wenn beide Partner aus EU-Ländern kommen, kann auch ein staatliches Gericht mit internationaler Zuständigkeit gewählt werden (z.B. die Gerichte in München), da EU-Urteile innerhalb der EU relativ gut vollstreckt werden können. In jedem Fall sollte der Gerichtsstand eindeutig benannt sein, um „forum shopping“ zu vermeiden.
Schiedsgerichtsklausel gestalten: Falls man sich für Arbitration entscheidet, sollte die Schiedsklausel die Regeln und Institution benennen (z.B. ICC-Schiedsgericht in Paris, Schiedsordnung der Internationalen Handelskammer) und die Anzahl der Schiedsrichter (oft ein oder drei). Auch die Verfahrenssprache und der Sitz des Schiedsgerichts sind anzugeben. Beispiel: „Alle Streitigkeiten aus oder im Zusammenhang mit diesem Vertrag werden endgültig nach der Schiedsgerichtsordnung der Deutschen Institution für Schiedsgerichtsbarkeit e.V. (DIS) von drei Schiedsrichtern entschieden. Der Sitz des Schiedsgerichts ist Berlin, Sprache des Verfahrens ist Englisch.“ Diese Angaben sorgen dafür, dass im Streitfall kein weiterer Dissens über das „Wie und Wo“ der Streitbeilegung entsteht.
Mediation und Eskalation: Eine elegante Lösung kann sein, vor einem Gerichts- oder Schiedsverfahren zunächst eine gütliche Einigung zu versuchen. Viele Verträge enthalten sogenannte Escalation Clauses: Beispielsweise vereinbaren die Parteien, bei einer Streitigkeit zuerst ihre Projektleiter verhandeln zu lassen; wenn das scheitert, treffen sich die Geschäftsleiter beider Unternehmen zu einem Gespräch; hilft auch das nicht, wird ein Mediationsverfahren eingeschaltet; und erst als letzte Stufe geht man vor Gericht bzw. ins Schiedsverfahren. Dieser gestufte Ansatz kann die Geschäftsbeziehung erhalten, weil er die Chance gibt, den Konflikt ohne öffentliche Auseinandersetzung und ohne sofortige Konfrontation auf rechtlicher Ebene beizulegen. Gerade bei langfristigen Kooperationen lohnt sich dieser Mechanismus.
Kosten und Sprache: Im internationalen Setting sollte auch geregelt werden, wer die Kosten eines Verfahrens trägt (meist nach Obsiegen/Unterliegen oder wie vom Schiedsgericht entschieden) und in welcher Sprache verhandelt wird. Wenn der Vertrag selbst zweisprachig ist, kann man festlegen, welche Sprachversion im Zweifel maßgeblich ist.
Durch eine durchdachte Streitbeilegungsklausel demonstriert man Weitsicht: Beide Seiten wissen, dass es einen Plan gibt, fair und effizient Konflikte zu lösen, ohne in endlose Rechtsstreitigkeiten zu münden. Das schafft Vertrauen und kann schon präventiv wirken – die Hemmschwelle für Vertragsbruch ist höher, wenn klare Konsequenzen vereinbart sind. Aus Sicht eines erfahrenen Vertragsanwalts ist die Streitbeilegungsklausel gerade bei internationalen Verträgen ein zentrales Element, das ebenso viel Beachtung erhalten sollte wie die inhaltlichen Regelungen zu IP und Pflichten.
Fazit
Co-Development-Verträge im Software- und Games-Bereich sind komplex, aber mit der richtigen Struktur beherrschbar. Eine strategische Vertragsgestaltung – von IP-Splitting und Rechtezuordnung über Risikoallokation bis hin zur Sicherung gemeinsamer Assets und technischen Ressourcen – bildet das Fundament für eine erfolgreiche Zusammenarbeit. Klar definierte Deliverables, Abnahmeprozesse und Streitbeilegungsmechanismen sorgen dafür, dass beide Seiten ihre Ziele erreichen, ohne in rechtlichen Unsicherheiten stecken zu bleiben.
Für Unternehmen und Entwickler bedeutet dies: Nehmen Sie sich am Anfang die Zeit, diese Punkte mit juristischer Unterstützung detailliert zu regeln. Ein gut aufgesetzter Co-Development-Vertrag schafft Transparenz, Verlässlichkeit und Vertrauen – jeder weiß, woran er ist, kreatives Potenzial kann frei fließen, und im Problemfall gibt es feste Leitplanken. Insbesondere bei internationaler Zusammenarbeit, mit unterschiedlichen Rechtskulturen, zeigt sich die Professionalität darin, mögliche Konfliktfelder vorab zu entschärfen.
Mit der Erfahrung eines spezialisierten Anwalts lassen sich praxisnahe Klauseln formulieren, die Risiken minimieren und den Wert des gemeinsamen Projekts sichern. So wird die Partnerschaft zwischen Software- oder Game-Studios zum Erfolg – juristisch solide untermauert und frei, sich auf das Wesentliche zu konzentrieren: die Entwicklung eines großartigen Produkts.
