Game Jams und offene Kollaborationen: Wem gehört der Prototyp?

Game Jams sind Kurzzeit-Entwicklungswettbewerbe, bei denen kreative Köpfe in wenigen Tagen gemeinsam Spiele-Prototypen erschaffen. Die Atmosphäre ist geprägt von Innovation, Teamwork und Zeitdruck. Häufig treffen sich unabhängige Entwickler:innen, Designer:innen und andere Kreative ohne vorherige Absprachen. In der Euphorie entstehen spannende Prototypen – doch wem gehört eigentlich das entstandene Spiel? Gerade in frühen Entwicklungsphasen ohne vertragliche Regelungen stellen sich urheberrechtliche Fragen, die später bei einer möglichen Kommerzialisierung zu handfesten Konflikten führen können. Dieser Blogpost beleuchtet die rechtlichen Hintergründe und gibt praktische Empfehlungen, um Streit zu vermeiden und klare Verhältnisse für alle Beteiligten zu schaffen.

Game Jams und offene Zusammenarbeit – der rechtliche Hintergrund

Bei Game Jams und ähnlichen offenen Kollaborationen kommt es oft ohne schriftliche Verträge zur gemeinsamen Schöpfung eines kreativen Ergebnisses. Rechtlich bewegen wir uns hier im Urheberrecht, speziell im deutschen und europäischen Urheberrecht. Das Urheberrecht schützt persönliche geistige Schöpfungen, also kreative Werke wie z.B. Quellcode, Grafiken, Musik oder Geschichten eines Spiels. In Deutschland ist der Grundsatz klar: Urheber ist der Schöpfer des Werkes (§ 7 UrhG). Das bedeutet, die Person, die einen genügend kreativen Beitrag leistet, erwirbt automatisch Urheberrechte an diesem Beitrag.

In einem Game Jam trägt typischerweise jeder im Team etwas zum Prototyp bei – sei es Programmierung, Leveldesign, Artwork oder Story. Wenn diese Beiträge in ein gemeinsames Werk einfließen, stellt sich die Frage: Entsteht ein gemeinsames Urheberrecht aller Beteiligten? Oder hat jede Person nur Rechte an ihrem eigenen Beitrag? Im Folgenden werden die Grundlagen wie Miturheberschaft, verbundene Werke, Schöpfungshöhe und Nutzungsrechte erklärt, bevor wir uns konkreten Konfliktszenarien und Lösungsansätzen zuwenden.

Urheberrechtliche Grundlagen bei gemeinsamen Projekten

Bevor wir auf Game Jams eingehen, lohnt ein kurzer Überblick über relevante urheberrechtliche Konzepte:

• Urheber und Werk: Ein Werk im Sinne des Urheberrechts ist eine persönliche geistige Schöpfung (§ 2 Abs.2 UrhG). Dazu zählen z.B. Software, Grafiken, musikalische Kompositionen oder Texte, sofern sie eine ausreichende Schöpfungshöhe aufweisen (also nicht rein Triviales oder Alltägliches sind). Urheber ist immer der Mensch, der diese Schöpfung vollbringt (§ 7 UrhG). Bei einem Computerspiel-Prototyp können also mehrere Personen verschiedene Werke beitragen (z.B. ein Musikstück, ein Level-Design oder Code), die zusammen das Spiel bilden.
• Einzelurheberschaft: Hat eine Person alleine ein komplettes Werk geschaffen, liegt die Sache klar: Diese Person ist alleiniger Urheber und kann darüber bestimmen.
• Miturheberschaft: Schaffen mehrere Personen gemeinsam ein einheitliches Werk, dessen Anteile sich nicht getrennt verwerten lassen, spricht man von Miturhebern (§ 8 Abs.1 UrhG). Miturheberschaft bedeutet, dass allen gemeinsam das Urheberrecht am Gesamtwerk zusteht. Typisches Beispiel: Zwei Entwickler schreiben gemeinsam den Quellcode eines Spiels, ohne klare Aufteilung, wer welchen Teil verfasst hat – der Code ist dann untrennbar ihr gemeinsames Werk.
• Verbundene Werke: Haben mehrere Urheber ihre selbständigen Werke nur zum Zweck der gemeinsamen Nutzung verbunden, ohne dass daraus ein untrennbares Gesamtwerk wird, spricht man von verbundenen Werken (§ 9 UrhG). In diesem Fall behält grundsätzlich jede:r Urheber:in die Rechte am eigenen Werk, muss aber der Zusammenverwertung mit den anderen zustimmen. Beispiel: Ein:e Programmierer:in entwickelt die Spiel-Engine, ein:e Künstler:in erstellt sämtliche Grafiken. Code und Grafik sind eigenständige Werke, die kombiniert das Spiel ergeben. Sie können separat bestehen, werden aber zusammen verwertet.
• Teilurheberschaft: Umgangssprachlich wird manchmal auch von „Teilurhebern“ gesprochen, gemeint sind damit zumeist entweder Miturheber eines Gesamtwerks oder Urheber von Teilen in einem verbundenen Werk. Wichtig ist: Das Urheberrecht kennt kein Aufsplitten eines einzelnen Werkes in “Prozent-Anteile” ohne Miturheberschaft – entweder es ist ein gemeinsames Werk (dann Miturheberrecht an allem) oder es sind getrennte Werke, die nur zusammen genutzt werden.

Diese Unterscheidungen sind im Kontext von Game Jams zentral. Oft entstehen Prototypen, bei denen Code, Grafik, Sound usw. eng verzahnt sind – hier kann Miturheberschaft vorliegen. In anderen Fällen könnten Beiträge klar trennbar sein (z.B. ein separat komponierter Soundtrack) – dann haben wir verbundene Werke. Ohne vertragliche Regelung gilt automatisch das Gesetz, also §§ 7–9 UrhG, mit all ihren Konsequenzen.

Miturheberschaft bei gemeinsam entwickelten Prototypen

Werden im Game Jam alle Beiträge der Teammitglieder zu einem untrennbaren Ganzen, dann greifen die Regeln der Miturheberschaft (§ 8 UrhG). Mehrere Personen wären gemeinsam Urheber des gesamten Prototyps. Das hat weitreichende Folgen:

• Gesamthänderische Rechte: Miturheber können nur gemeinsam über das Werk bestimmen. Das Recht zur Veröffentlichung, Verwertung (z.B. Verkauf, Lizenzierung) und auch für Änderungen am Werk steht allen zur gesamten Hand zu (§ 8 Abs.2 S.1 UrhG). Keiner darf alleine das Spiel kommerziell vertreiben oder z.B. den Code einfach weiterentwickeln und veröffentlichen, ohne die Zustimmung der anderen.
• Zustimmungspflicht, Treu und Glauben: In der Praxis bedeutet das, jede größere Nutzung – ob Upload auf eine Plattform, Verkauf, Fortentwicklung – erfordert das Einverständnis aller Miturheber. Niemand darf seine Zustimmung jedoch wider Treu und Glauben verweigern (§ 8 Abs.2 S.2 UrhG). Das heißt, wenn ein Miturheber kein vernünftiges Interesse daran hat, zu blockieren, und die Weigerung schikanös erscheint, könnte im Extremfall ein Gericht ihn zur Zustimmung verpflichten. Dennoch ist das eine hohe Hürde – Konflikte sollten idealerweise gar nicht erst so weit eskalieren.
• Gemeinsame Rechtsdurchsetzung: Bei Urheberrechtsverletzungen (etwa wenn ein Externer den Prototyp unerlaubt kopiert) kann jeder Miturheber selbst klagen, allerdings nur auf Leistung an alle Miturheber (§ 8 Abs.2 S.3 UrhG). Das heißt, ein Miturheber kann Unterlassung verlangen oder Schadenersatz einklagen, aber der Ersatzanspruch stünde allen gemeinsam zu. Kein Miturheber darf alleine alles einstecken oder alleine einen Vergleich über gemeinsame Rechte schließen, der auch die anderen bindet.
• Erlösverteilung: Erzielt das gemeinsame Werk Einnahmen, gebühren die Erträge den Miturhebern nach dem Umfang ihrer Mitwirkung (§ 8 Abs.3 UrhG), sofern sie nichts anderes vereinbart haben. Im Klartext: Wer mehr zur Schöpfung beigetragen hat, soll auch mehr vom Gewinn erhalten – außer das Team hat vorher oder nachher eine andere Aufteilung beschlossen. In der Praxis ist diese gesetzliche Quote oft schwer zu bemessen (wie quantifiziert man den Beitrag eines Programmierers vs. eines Grafikers?). Deshalb werden Teams gut beraten sein, klare Absprachen über die Aufteilung zu treffen, statt sich auf diese unbestimmte Default-Regel zu verlassen.
• Verzicht eines Miturhebers: Ein Miturheber kann jederzeit auf seinen Anteil an den Verwertungsrechten verzichten (§ 8 Abs.4 UrhG). Dieser Verzicht muss gegenüber den anderen erklärt werden und führt dazu, dass die verbleibenden Miturheber die Rechte übernehmen. Beispiel: Wenn eine Person aus dem Team aussteigt und auf alle Rechte verzichtet, haben die übrigen freie Hand. Achtung: Ein Verzicht betrifft nur die Verwertungsrechte (wirtschaftliche Rechte). Die Urheberpersönlichkeitsrechte (z.B. Recht auf Nennung als Urheber) bleiben persönlich und unverzichtbar – die Person bleibt also ideell Miturheber, kann aber an der kommerziellen Nutzung nicht mehr partizipieren.
• Urheberpersönlichkeitsrecht: Auch bei Miturhebern hat jede Person das Recht, als Urheber des Werkes genannt zu werden (§ 13 UrhG). In einem Team sollte also darauf geachtet werden, dass alle einen Credit erhalten, sofern sie das wünschen. Umgekehrt kann sich niemand allein als „der Schöpfer“ ausgeben und andere unterschlagen – das wäre ein Verstoß gegen das Persönlichkeitsrecht der Miturheber. Gerichte haben klargestellt, dass Miturheber einen Anspruch auf Nennung haben. In der Praxis: Wenn der Prototyp später veröffentlicht wird, gehören alle kreativen Köpfe zumindest ins Impressum oder die Credits.

Beispielszenario Miturheberschaft: Drei Entwickler:innen erarbeiten im Jam zusammen einen Prototyp. Person A programmiert, B erstellt Grafiken, C schreibt Story und Dialoge. Alles zusammen ergibt ein stimmiges Spiel. Keiner der Beiträge wäre für sich allein “das Spiel” – es ist ein gemeinsames Werk. Nach § 8 UrhG sind A, B und C Miturheber des gesamten Spiels. Wollen A und B das Spiel nach dem Jam auf Steam veröffentlichen, brauchen sie C’s grünes Licht – selbst wenn C “nur” die Story beigesteuert hat, ist sie Miturheberin des Gesamtwerks. Genauso könnte C die Veröffentlichung nicht ohne A und B durchziehen. Alle sitzen im selben Boot.

Getrennte Beiträge: verbundene Werke statt Miturheberschaft?

Nicht immer führt gemeinsame Projektarbeit automatisch zu Miturheberschaft. Wichtig ist die Frage: Lassen sich die einzelnen Beiträge getrennt verwerten? Wenn ja, spricht das für verbundene Werke (§ 9 UrhG) oder schlicht ein Bündel einzelner Urheberrechte statt eines gemeinsamen.

In vielen Game-Jam-Teams gibt es eine gewisse Arbeitsteilung. Beispiel: Ein Team entscheidet, Mitglied X kümmert sich ausschließlich um die Musik. Die Musikstücke sind eigenständige, abschließend ausgearbeitete Werke. Mitglied Y programmiert das Gameplay, Mitglied Z zeichnet alle Grafiken. Hier liegen mehrere eigenständige Werke vor (Code, Bild, Musik), die zusammen genutzt werden.

Die rechtlichen Konsequenzen bei verbundenen Werken oder getrennten Beiträgen sind andere:

• Jede Person behält Urheberrecht am eigenen Werk: X ist allein Urheber:in der Musik, Y am Code, Z an den Grafiken. Jede:r kann sein eigenes Werk grundsätzlich auch unabhängig verwerten – allerdings nicht in der kombinierten Form ohne die anderen. So dürfte X die komponierte Musik z.B. separat als Soundtrack-Album veröffentlichen oder anderweitig lizenzieren, weil sie sein ureigenes Werk ist. Y könnte den von ihm geschriebenen Code evtl. als Basis für ein anderes Spiel verwenden. Z kann die Artworks in einem Portfolio zeigen oder erneut nutzen.
• Gemeinsame Nutzung erfordert Zustimmung: Wenn jedoch die Werke gemeinsam als Einheit (das Spiel) verwertet werden sollen, müssen sich die Urheber der Einzelwerke einigen. § 9 UrhG regelt, dass jeder Urheber eines verbundenen Werkes vom anderen die Einwilligung zur Veröffentlichung, Verwertung und Änderung der Verbindung verlangen kann, soweit es nach Treu und Glauben zumutbar ist. Praktisch bedeutet das: Haben sich X, Y, Z einmal darauf verständigt, ihre Beiträge zusammen als Spiel zu präsentieren, darf keiner ohne Grund die weitere gemeinsame Nutzung verweigern. Sie können also voneinander Zustimmung verlangen, falls einer quer schießt – aber im Detail ist das nicht so strikt wie bei Miturhebern zur gesamten Hand.
• Kein “gesamthänderisches” Prinzip: Anders als bei Miturheberschaft sind hier die Rechte nicht untrennbar miteinander verschmolzen. Jede:r könnte theoretisch getrennt über das eigene Stück verfügen, solange die Nutzung nicht die Beiträge der anderen berührt. So könnte z.B. der Programmierer Y sein Spielkonzept mit neuen Grafiken und neuer Musik (ohne X und Z) weiterentwickeln – dann nutzt er nur sein eigenes Werk (den Code bzw. die Spielmechanik, sofern diese als Softwarewerk urheberrechtlich geschützt ist) und ersetzt die anderen Komponenten. Das ist rechtlich zulässig, sofern die ursprünglichen Grafiken/Musik von Z und X nicht mehr verwendet werden. Er muss natürlich aufpassen, dass er keine geschützten Elemente von Z und X übernimmt. Wichtig: Die Idee des Spiels an sich genießt ja keinen Schutz; wenn Y das Grundkonzept (Idee) nimmt und mit eigenen Mitteln neu umsetzt, verletzt er nicht das Urheberrecht der ehemaligen Mitstreiter. Moralisch kann das heikel sein, aber juristisch kommt es auf die konkreten schöpferischen Ausdrucksformen an, nicht auf abstrakte Ideen.
• Sammelwerke als Sonderfall: In manchen Konstellationen könnte ein Spiel auch als Sammelwerk gelten (§ 4 UrhG) – etwa wenn es aus klar trennbaren Levelbeiträgen oder Minispielen besteht, die ein:e Organisator:in gesammelt hat. Dann hätte die zusammenstellende Person ein eigenes Urheberrecht an der Sammlung (sofern die Auswahl oder Anordnung eigenschöpferisch ist). Im klassischen Jam-Prototyp spielt das selten eine Rolle, da meist alle eng zusammen an einem Spiel arbeiten, statt mehrere voneinander unabhängige Inhalte zu kompilieren.

Beispielszenario verbundene Werke: Stellen wir uns vor, Teilnehmerin D schreibt im Jam ein eigenständiges Tool/Plugin, das in das Spiel integriert wurde, aber auch losgelöst funktionieren könnte. Teilnehmer E liefert dazu Grafiken, die D’s Plugin nutzt, E’s Bilder könnten aber genauso in einem anderen Projekt eingesetzt werden. Beide haben ihre eigenen, trennbaren Werke beigetragen. Ergebnis: D und E sind nicht Miturheber eines einzigen Werkes, sondern jeweils alleinige Urheber ihrer Teile. Sie müssen sich zwar einigen, wenn sie das Gesamtprodukt (Spiel mit Plugin und Grafiken) verwerten wollen, aber keiner hat vollständige Kontrolle über den anderen Teil. D dürfte ihr Plugin ohne E’s Bilder weitervertreiben; E dürfte ihre Bilder anderweitig verwenden oder das Spiel mit einem anderen Programmierer neu aufrollen, solange sie D’s Code nicht verwendet. Für das konkrete Jam-Spiel bleiben sie jedoch auf Zusammenarbeit angewiesen oder bräuchten zumindest nachträglich Absprachen.

Schöpfungshöhe: Welche Jam-Beiträge sind überhaupt urheberrechtlich geschützt?

Ein zentraler Punkt gerade in frühen Prototyp-Phasen ist die Schöpfungshöhe. Nicht jede Idee oder jeder kleiner Beitrag genießt automatisch Urheberrechtsschutz. Das Urheberrecht schützt konkrete Ausgestaltungen – abstrakte Spielideen, Spielmechaniken oder einfache Konzepte sind für sich genommen nicht schutzfähig (§ 2 Abs.2 UrhG verlangt eine persönliche geistige Schöpfung).

Was bedeutet das im Kontext eines Game Jams?

• Ideen und Konzepte: Die Grundidee eines Spiels (z.B. „ein Plattformer, bei dem man die Zeit zurückdrehen kann“) ist frei. Niemand erwirbt an einer bloßen Idee Urheberrechte. Ebenso sind Spielregeln oder ein Spielprinzip als solche nicht geschützt. Das heißt, wenn Team A bei einem Jam auf eine innovative Mechanik kommt, kann rein rechtlich Team B diese Mechanik später auch nutzen, solange B nicht konkret den Code, die Grafiken oder Leveldesigns von A kopiert. Achtung: Die Grenze zwischen Idee und Ausdruck ist aber fließend – ein ganz konkreter Levelaufbau oder ausformulierter Storytwist kann wiederum als Ausdruck geschützt sein, während die dahinterstehende abstrakte Regel frei bleibt.
• Triviale Beiträge: Kleine Beiträge ohne eigene Kreativität genießen keinen Schutz. Beispiel: Jemand im Team kümmert sich nur um das Testen und meldet Bugs, schreibt aber selbst keinen kreativen Code und gestaltet nichts mit eigener Schöpfungshöhe. So wertvoll diese Arbeit für das Gelingen ist, sie begründet kein Urheberrecht. Auch rein technische Beiträge (z.B. das stumpfe Umsetzen einer genau vorgegebenen Idee ohne eigenen Gestaltungsspielraum) könnten an der Schwelle scheitern. Schöpfungshöhe erfordert eine gewisse individuelle Prägung. Im Zweifel ist allerdings diese Hürde recht niedrig – schon kleine kreative Entscheidungen können genügen.
• Geschützte Elemente im Prototyp: In aller Regel enthält selbst ein einfacher Jam-Prototyp irgendein schutzfähiges Element – sei es ein origineller Programmiercode (Software ist als Sprachwerk geschützt, sofern nicht total banal), ein einzigartiges Charakterdesign als Grafik, eine kreative Story-Idee konkret ausformuliert, oder eine eigenständige musikalische Melodie. Sobald es um solche konkreten Ausdrucksformen geht, greift das Urheberrecht.
• Mitwirkende ohne Urheberstatus: In Teamprojekten kann es also passieren, dass nicht jeder Beitragende auch rechtlich Urheber:in wird. Zum Beispiel könnten Personen, die nur allgemeine Ideen ins Brainstorming einbrachten, aber keine konkrete Umsetzung beigesteuert haben, keine Urheberrechte am Ergebnis geltend machen. Dennoch sollte man deren Beiträge der Fairness halber nicht ignorieren – aber rechtlich haben sie ohne schöpferischen Beitrag kein Mitspracherecht am Werk. Das heißt: Eine Ideengeber*in, die/der z.B. ein Konzept vorschlägt, das andere dann in eigene kreative Leistungen (Code, Art) umsetzen, hat am Ende keine Rechte am Spiel, wenn sie/er nicht selbst kreativ ins Werk eingegriffen hat.
• Beweislast bei Schöpfungshöhe: Sollte es später zum Streit kommen, ob ein bestimmter Beitrag urheberrechtlich geschützt ist, muss derjenige, der Schutz beansprucht, darlegen, warum sein Beitrag die nötige Originalität hat. In der Praxis wird man im Zweifel sagen: bei Programmcode oder Bildern geht man meist von Schutz aus, es sei denn, es war etwas ganz Banales (z.B. ein 08/15 Menü-Button). Aber diese theoretische Diskussion zeigt: Nicht jeder im Jam hat automatisch Urheberrechte nur weil er Teil des Teams war – es kommt auf die konkrete kreative Leistung an.

Praxis-Tipp: Teams sollten idealerweise transparent besprechen, wer welche Rolle hat und welche Beiträge als kreativ gelten. Wenn z.B. jemand „nur mal drüberschaut“ oder Test spielt, wird er es meist selbst nicht als Urheberrolle sehen. Kritischer sind Fälle, in denen jemand ideenreich mitwirkt, aber nichts selbst umsetzt – hier können Erwartungen auseinandergehen. Klarheit hilft, Missverständnisse zu vermeiden.

Beweislast und Dokumentation: Wer hat was geschaffen?

Spätestens wenn Geld ins Spiel kommt, kann es passieren, dass ehemalige Teammitglieder uneins darüber sind, wem welche Anteile am Prototyp zukommen. Vielleicht behauptet Person A plötzlich, sie habe die entscheidende Mechanik erdacht und umgesetzt, während Person B das anders sieht. Im Ernstfall muss geklärt werden, wer Urheber*in welcher Teile ist und ob Miturheberschaft vorliegt. Hier spielt die Beweislast eine große Rolle.

Grundsätzlich gilt: Wer Rechte aus dem Urheberrecht ableitet, muss seine Urheberschaft nachweisen können. Es gibt keine amtliche Registrierung des Urheberrechts (anders als z.B. bei Patenten oder Marken). Deshalb ist Dokumentation alles:

• Versionsverwaltung & Commit-Historie: Für Softwareprojekte ist es Gold wert, ein Versionskontrollsystem (z.B. Git) zu nutzen. Damit lässt sich später nachvollziehen, wer welchen Code eingebracht hat und zu welchem Zeitpunkt. Jeder Commit kann einem Contributor zugeordnet werden. Im Streitfall könnte eine Git-Historie ein starkes Beweismittel sein, um zu zeigen, welche Person konkret die kreativen Codezeilen geschrieben hat. Ähnliches gilt für Design-Dokumente mit Autorenkennung.
• Dateien und Metadaten: Designer:innen sollten Ursprungsdateien (z.B. Photoshop-/Krita-Dateien, 3D-Modelle) mit ihren Metadaten aufbewahren. Diese enthalten oft Erstellungsdaten und manchmal auch Autorennamen. Wenn z.B. Person X behauptet, ein bestimmtes Artwork im Prototyp stamme von ihr, kann Person Y, die das Originalfile mit ihrem Namen gespeichert hat, das Gegenteil belegen.
• Kommunikationsverläufe: Oft lässt sich aus Team-Chats (Slack, Discord) oder E-Mails rekonstruieren, wer welche Idee eingebracht hat oder wer welche Aufgabe übernommen hat. Auch wenn Ideen nicht direkt schützbar sind, kann ein Chatverlauf zeigen, dass eine bestimmte Person die kreative Ausarbeitung übernommen hat („Ich zeichne jetzt den Hauptcharakter so und so…“) – was im Zweifel ihre Urheberschaft stützt.
• Teilnahmebedingungen und Registrierungsdaten: Einige Game Jams verlangen bei Abgabe eines Projekts die Nennung aller Teammitglieder und vielleicht sogar eine Beschreibung, wer was gemacht hat. Diese Infos können später als Anhaltspunkt dienen. Wenn jemand gar nicht als Teammitglied aufgeführt war, aber später Ansprüche stellt, ist das zumindest widersprüchlich.
• Zeugen: Im Notfall können auch Dritte, die dabei waren, als Zeugen dienen. Andere Jam-Teilnehmer oder Mentor:innen haben vielleicht beobachtet, dass Person A den ganzen Tag am Code saß, während Person B hauptsächlich organisierte. Solche Aussagen sind naturgemäß nicht immer präzise, aber können ein Gesamtbild abrunden.
• Beweislastumkehr bei Urhebervermerk: Interessant: § 10 UrhG besagt, dass zugunsten dessen, der auf üblichen Vervielfältigungsstücken als Urheber genannt ist, vermutet wird, dass er Urheber sei. Übertragen auf unser Thema: Wird in der veröffentlichten Version des Prototyps z.B. im Impressum oder Readme eine Person als Autor genannt und gibt es keinen Hinweis auf andere, kann das eine Vermutungswirkung entfalten. Allerdings ist diese Norm eher für formale Angaben gedacht (z.B. auf Buchcovern). Bei kollaborativen Projekten sollte man sich darauf nicht verlassen – es zeigt aber, wie wichtig klare Urheberangaben sind.

Warum all das? Sollte z.B. einer der ehemaligen Teammitglieder alleine die Kommerzialisierung vorantreiben und behaupten, die anderen hätten gar nichts oder nichts Schöpferisches beigetragen, müssen letztere ihre Miturheberschaft beweisen. Umgekehrt könnte der Treiber des Projekts nachweisen müssen, dass bestimmte Teile ausschließlich von ihm stammen, um sie alleine nutzen zu dürfen. Gute Dokumentation schützt vor ungerechtfertigten Ansprüchen und stärkt die eigene Position.

Praxis-Tipp: Auch wenn es in der heißen Jam-Phase lästig erscheint – behaltet die Projekt-Historie nachvollziehbar. Legt am Ende des Jams idealerweise gemeinsam fest, wer welche Bestandteile geschaffen hat. Das kann formlos in einer Textdatei, einer Readme oder sogar per E-Mail geschehen. Solch ein „Schaffensprotokoll“ kann später Missverständnisse ausräumen.

Spätere Kommerzialisierung: Wenn aus dem Prototyp ein Produkt wird

Viele Game Jams enden damit, dass der Prototyp einfach als Lernerfahrung oder Showcase liegen bleibt. Doch hin und wieder steckt in dem 48-Stunden-Projekt eine zündende Idee, die nach dem Jam weiterverfolgt wird. Genau dann stellt sich mit aller Schärfe die Frage: Wem gehört der Prototyp und wer darf daraus Kapital schlagen? Einige typische Szenarien:

Das gesamte Team will zusammen weitermachen

Im besten Fall sind alle motiviert und beschließen, das Spiel gemeinsam zur Marktreife zu bringen. Urheberrechtlich bleiben erstmal alle Miturheber wie gehabt. Allerdings sollte jetzt unbedingt vertraglich geregelt werden, wie die Zusammenarbeit weiterläuft:

• Gründung eines Studios (Startup): Viele erfolgreiche Jam-Teams gründen ein kleines Studio (z.B. als GbR, UG oder GmbH), um das Projekt professionell anzugehen. Dabei ist es üblich, dass alle ihre Urheberrechte am Prototyp auf die neue Gesellschaft übertragen oder der Gesellschaft entsprechende Nutzungsrechte einräumen. Dadurch gehört der Prototyp (und alle Weiterentwicklungen) dann der Firma und nicht mehr den Einzelpersonen. Vorteile: Die Firma kann Verträge mit Publishern abschließen, Lizenzen vergeben etc., ohne ständig alle ursprünglichen Urheber einzeln fragen zu müssen. Außerdem sind so auch Themen wie Gewinnverteilung formal geklärt (über Gesellschaftsanteile oder interne Verträge).
• Gründervertrag / Kooperationsvertrag: Bevor man eine Firma gründet (was etwas Zeit braucht), kann ein Kooperationsvertrag zwischen den Beteiligten helfen. Darin wird festgelegt, wer welche Rolle übernimmt, wie Entscheidungen getroffen werden, wie Erlöse geteilt werden und insbesondere, wer welche Rechte einbringt. Beispielsweise könnte drinstehen, dass alle Mitwirkenden den Prototyp gemeinsam nutzen dürfen zur Weiterentwicklung, dass spätere Werke gemeinsam gehören, oder dass im Zweifel ein Mehrheitsentscheid gilt, falls jemand ausscheiden will. Hier herrscht Vertragsfreiheit – das Team kann jede Regelung treffen, die nicht gegen Gesetz oder gute Sitten verstößt. Wichtig ist, klare Abmachungen zu haben, um spätere Streitpunkte vorzubeugen.
• Nutzungsrechteeinräumung untereinander: Falls eine formelle Firma (noch) nicht gewünscht ist, kann man vereinbaren, dass sich alle gegenseitig unwiderrufliche Nutzungsrechte an allen Beiträgen einräumen, um das Projekt fortzuführen. So wäre jede Person berechtigt, das Gesamtwerk zu nutzen, ohne jedes Mal neu fragen zu müssen. Hier ist Präzision gefragt: Welche Rechte (bearbeiten, verbreiten, kommerzielle Nutzung etc.) werden wem eingeräumt? Idealerweise umfassend für das Projektzweck. Außerdem sollte geregelt sein, was passiert, wenn jemand später ausscheidet – behält er/sie dann noch ein Nutzungsrecht (z.B. um eigene Version zu machen?), oder erlischt es? Solche Punkte möglichst schriftlich fixieren.
• Verteilung von Einnahmen und Aufgaben: Bei Kommerzialisierung kommt die Geldfrage: Bleibt die gesetzliche Regel (§ 8 Abs.3 UrhG – nach Umfang der Mitwirkung) oder einigt man sich auf andere Schlüssel? Oft wird man konkrete Prozentsätze oder gleich Beteiligung über Gesellschaftsanteile definieren. Zudem kann eine Person vielleicht eine größere Führungsrolle bekommen (z.B. Projektleitung) – das könnte auch in Vereinbarungen festgehalten werden, wer darf was entscheiden etc., um Handlungsfähigkeit zu sichern (denn ansonsten müssten ja eigentlich bei Miturhebern alle alles gemeinsam beschließen).

Kurz: Wenn das Team zusammen bleibt, wandelt die informelle Kooperation sich in ein Geschäftsvorhaben. Spätestens jetzt ist professionelle Absicherung angesagt. Erfolgsstorys zeigen, dass klare Absprachen oder gleich eine Firmengründung hier die besten Wege sind, um aus dem Prototyp ein Produkt zu machen.

Nur ein Teil des Teams oder eine Person möchte das Projekt weiterführen

Häufiger ist das Szenario, dass nicht alle Beteiligten nach dem Jam Zeit, Lust oder Möglichkeit haben, weiter am Spiel zu arbeiten. Vielleicht war es ein Wochenendspaß und manche müssen zurück in den Alltag. Andere glauben nicht an die kommerzielle Tragfähigkeit, während ein Mitglied Feuer und Flamme ist. Was nun, wenn z.B. eine Person alleine die Idee zur Marktreife bringen will?

Hier ist die Rechtslage heikel: Wenn der Prototyp bisher gemeinsam (mit-)urheberrechtlich gebunden ist, kann sich die eine Person nicht einfach „freimachen“, außer sie erhält die Rechte der anderen oder umgeht sie legal. Einige Optionen:

• Einholung von Einwilligungen/Lizenzen: Der sauberste Weg: Die verbleibende Person kontaktiert alle ehemaligen Teammitglieder und vereinbart mit jedem schriftlich, dass sie das Projekt alleine weiterführen und verwerten darf. Das kann als Lizenzvertrag formuliert sein (d.h. die anderen räumen ihr ein exklusives Nutzungsrecht ein, evtl. gegen Beteiligung oder eine Einmalzahlung) oder als Rechteübertragung (Abtretung der Urheberrechte im Rahmen des Zulässigen – rechtlich übertragen werden können nur die Verwertungsrechte, da Urheberpersönlichkeitsrechte unveräußerlich sind). Wichtig ist, dass die Vereinbarung möglichst umfassend ist: inklusive Bearbeitungsrecht, Vertriebsrecht, etc., damit die allein weitermachende Person frei schalten und walten kann. Oft wird eine Gewinnbeteiligung oder Vergütung vereinbart, um den anderen ihr Okay schmackhaft zu machen.
• Verzicht nach § 8 Abs.4 UrhG: Wie oben erwähnt, kann ein Miturheber seinen Anteil an den Verwertungsrechten verzichten. Denkbar wäre also, dass alle außer der verbleibenden Person schriftlich gegenüber dieser erklären, sie verzichten auf ihre Verwertungsrechte am Prototyp. Dadurch „wachsen“ diese Anteile der bleibenden Person zu – im Ergebnis hat sie dann allein die Verwertungsrechte inne. Der Vorteil: Es ist eine im UrhG vorgesehene Lösung, die relativ unkompliziert klingt. Allerdings werden die meisten das nicht gratis tun wollen – man wird also auch hier oft über eine kleine Abfindung oder andere Gegenleistung sprechen müssen. Zudem: Der Verzicht nach § 8 Abs.4 ist endgültig – die anderen könnten dann selbst nicht mehr wirtschaftlich mit dem alten Prototyp etwas anfangen, auch nicht gemeinsam ohne die verbleibende Person. Das sollte allen klar sein.
• Neuentwicklung (Bypass): Falls keine Einigung erzielt wird – sei es, weil jemand nicht zustimmt oder unauffindbar ist – bleibt als Ausweg oft nur, die geschützten Beiträge der anderen zu ersetzen. Das bedeutet, die verbleibende Person entwickelt alle fremden Teile neu, damit sie nichts mehr verwenden muss, woran sie nicht alleinige Rechte hat. Das ist ein harter Weg, aber manchmal praktikabel: Hat z.B. im Jam jemand Musik beigesteuert und verweigert nun die Nutzungserlaubnis, kann der:die Weiterentwickelnde einfach neue Musik komponieren oder lizenzieren und die alte entfernen. Ähnlich mit Grafiken: Original-Assets austauschen. Bei Code ist es schwieriger, aber wenn man weiß, welcher Teil von wem kam, kann man versuchen, den von anderen stammenden Code zu refaktorieren oder neu zu schreiben. Wichtig ist, dass keine urheberrechtlich relevanten Elemente der anderen übrigbleiben. Die Spielidee an sich darf natürlich bleiben, die kann niemand monopolisieren. Auch allgemeine Algorithmen, die nicht individuell-prägend sind, könnte man argumentieren. Doch Vorsicht: Wenn z.B. eine Levelgestaltung 1:1 übernommen wird, obwohl sie von einem Mitstreiter stammt, wäre das kritisch – dann lebt dessen „Ausdruck“ ja fort.
• Risiko „Treu und Glauben“: Theoretisch könnte man versuchen zu argumentieren, ein nicht mitziehendes Teammitglied verweigere die Zustimmung unredlich (wider Treu und Glauben, § 8 Abs.2 UrhG) und daher dürfe man ausnahmsweise ohne ihn/sie weitermachen. Das ist juristisches Neuland und extrem riskant. Ohne gerichtliches Urteil sollte man das nicht tun – und ein Gerichtsverfahren in so einem Stadium kann niemand wollen. Praktisch wird man also versuchen, ggf. mit Druck oder Überzeugung, die Zustimmung zu bekommen oder eben den Umweg der Neuentwicklung gehen.
• Namensnennung und Credits: Selbst wenn die anderen ihre Verwertungsrechte abgeben, haben sie in der Regel noch ein Recht auf Anerkennung ihrer Urheberschaft für das, was ursprünglich von ihnen stammt (§ 13 UrhG). In einem Weiterentwicklungs-Szenario wird man oft vereinbaren, dass im fertigen Spiel etwa im Abspann steht: „Basierend auf einem Prototyp von X, Y und Z“ oder dass man die ursprünglichen Jam-Beiträge würdigt. Das ist nicht nur juristisch fair, sondern auch fürs Klima in der Entwicklungsgemeinschaft besser.

Beispielszenario Einzelweiterführung: Anna und Ben entwickeln im Jam einen innovativen Puzzle-Game-Prototyp. Beide sind Miturheber des Codes und Designs (alles entstand in enger Zusammenarbeit). Nach dem Jam hat Ben kein Interesse, weiterzumachen, Anna aber schon. Anna möchte das Spiel kommerziell rausbringen. Sie hat nun zwei Wege: (a) Ben um ein schriftliches Einverständnis bitten, dass sie allein das Spiel verwerten darf – vielleicht bietet sie ihm eine Umsatzbeteiligung von 10% an. Ben stimmt zu und verzichtet auf seine Rechte, Anna ist safe. Oder (b) Ben reagiert nicht / lehnt ab. Anna entschließt sich, alles von Ben stammende zu ersetzen. Sie schreibt große Teile des Codes neu (weil Ben viel programmiert hatte) und ersetzt Bens Leveldesigns durch eigene. Am Ende hat sie ein Spiel, das im Kern auf der Jam-Idee beruht, aber in der konkreten Ausgestaltung keine kopierten Elemente von Ben mehr enthält. Dann kann Anna das neue Spiel veröffentlichen. Natürlich ist (b) sehr aufwendig – es zeigt, wie wichtig es ist, möglichst den einfachen Weg (a) via Einigung zu gehen.

Ein Dritter (Studio/Publisher) will den Prototyp kaufen oder weiterentwickeln

Angenommen, euer Jam-Spiel erregt Aufmerksamkeit – ein Indie-Publisher oder größeres Studio findet den Prototyp toll und will ihn lizenzieren oder das Team übernehmen. Aus rechtlicher Sicht wird dieser Dritte vor allem sicherstellen wollen, dass die Rechte geklärt sind:

• IP-Check: Der Interessent wird fragen: Wer hat eigentlich alles dran mitgearbeitet und hat irgendjemand Rechte, der nicht hier am Tisch sitzt? Hier zahlt es sich aus, wenn das Team bereits intern klare Verhältnisse hat. Wenn nämlich eine Person fehlt (z.B. man hat die Grafiken von jemandem, der nicht weiter dabei ist, und keine Vereinbarung mit ihm), wird der Publisher nervös – denn dieser jemand könnte später Ansprüche stellen. Im schlimmsten Fall platzt der Deal, weil dem Interessenten das Risiko zu hoch ist. Daher: Transparenz gegenüber Dritten, wer Urheber ist, und am besten schon Abtretungen/Lizenzen von allen Beteiligten eingesammelt haben, bevor man in Verhandlungen geht.
• Vertragsübernahme / Asset-Kauf: Häufige Modelle sind, dass ein Studio z.B. die Assets und Rechte abkauft. Dafür müssen alle Urheber zustimmen oder ihre Rechte auf den verkaufenden übertragen haben. Alternativ werden die Urheber direkt Vertragspartner: Man schließt einen Vertrag, in dem alle Urheber dem Studio die Nutzungsrechte (möglichst exklusiv und vollständig) einräumen, oft gegen eine Pauschalsumme und/oder Revenue Share. Ohne solch einen Vertrag bleibt der Dritte ansonsten handlungsunfähig, weil er das Spiel nicht ohne Risiko veröffentlichen könnte.
• Mitarbeiteranstellung: Manchmal löst man es so, dass der Publisher einfach das ganze Team anstellt oder unter Vertrag nimmt. Die Teammitglieder übertragen dann im Zuge dessen ihre Rechte. Für Software gibt es im Arbeitsrecht sogar spezielle Regeln: Wird jemand angestellt und entwickelt dann (im Rahmen des Jobs) das Spiel weiter, gehen die Verwertungsrechte an den Arbeitgeber über (§ 69b UrhG für Computerprogramme, und allgemeiner nach § 43 UrhG im Wege des Vertrages). Das heißt, wenn das Team in ein Studio übergeht, transferiert sich das IP häufig formal automatisch oder über arbeitsvertragliche Klauseln. Wichtig ist aber: Der bestehende Prototyp entstand vor dieser Anstellung – der Arbeitgeber will sicher sein, dass auch daran schon alle Rechte rüberkommen. Daher wird der Publisher in der Regel verlangen, dass im Vertrag steht: „Die Entwickler versichern, alle Rechte an bisherigen Versionen zu besitzen und übertragen diese ebenfalls auf uns.“

Fazit zu Kommerzialisierung: Ob intern im Team oder mit externen Partnern – klare Vereinbarungen und Rechteketten sind entscheidend, damit aus einem Jam-Spiel ein marktfähiges Produkt werden kann. Ohne Klärung drohen rechtliche Stolpersteine: Ein verprellter ehemaliger Mitstreiter kann z.B. per einstweiliger Verfügung einen Release stoppen, wenn er glaubhaft macht, dass seine Urheberrechte verletzt würden. Dieses Risiko schreckt Geldgeber und Publisher ab. Daher lohnt es, rechtzeitig die Weichen richtig zu stellen.

Die Rolle von Teilnahmebedingungen und AGB der Veranstalter

Viele Konflikte lassen sich entschärfen oder vermeiden, wenn die Rahmenbedingungen eines Game Jams klar geregelt sind. Hier kommen die Teilnahmebedingungen der Veranstalter ins Spiel, quasi die „AGB“ (Allgemeinen Geschäftsbedingungen) eines Game Jams. Was können und sollten solche Regeln abdecken – und wo liegen ihre Grenzen?

• Urheberrechte verbleiben bei den Teilnehmern: Seriöse Game-Jam-Veranstalter stellen meist klar, dass alle geistigen Eigentumsrechte bei den Teams/Teilnehmern bleiben. Das heißt, der Veranstalter selbst erhebt keinen Anspruch darauf, Eigentümer eures Prototyps zu werden. Oft findet sich ein Satz in den Teilnahmebedingungen wie „Die Teilnehmer behalten sämtliche Urheberrechte an ihren eingereichten Spielen.“ Dies schafft Vertrauen und entspricht auch den Erwartungen der Community. Sollte ein Veranstalter das anders handhaben wollen (etwa bei speziellen Wettbewerben mit kommerziellem Hintergrund), müsste er das deutlich sagen – und es wäre rechtlich eine ungewöhnliche Klausel, die wahrscheinlich viele abschreckt.
• Lizenzierung für Jam-Präsentation: Meist räumen die Teilnehmer dem Veranstalter eine begrenzte Nutzungserlaubnis ein, z.B. um die Prototypen auf der Jam-Website zu hosten, Screenshots zu zeigen oder Sieger-Spiele auf Veranstaltungen vorzuführen. Das ist praktisch nötig, damit der Jam seine Ergebnisse zeigen kann. Eine typische Klausel könnte lauten: „Die Teilnehmer gestatten dem Veranstalter, das eingereichte Spiel unentgeltlich zum Zwecke der Berichterstattung, Öffentlichkeitsarbeit und Dokumentation des Game Jams zu nutzen (z.B. Screenshot-Veröffentlichung, Download auf der Jam-Website).“ Diese Lizenz ist in der Regel nicht exklusiv und beschränkt (der Veranstalter darf damit nicht eigenmächtig Geld verdienen, sondern nur in Bezug auf den Jam werben).
• Open-Source-/Creative-Commons-Vorgaben: Manche Game Jams – insbesondere mit wissenschaftlichem oder gemeinschaftlichem Anspruch – haben Vorgaben, dass die Ergebnisse unter einer bestimmten offenen Lizenz veröffentlicht werden müssen. Beispiel: Der Global Game Jam forderte lange Zeit, dass die hochgeladenen Spiele unter Creative Commons BY-NC-SA (Namensnennung, nicht kommerziell, Weitergabe unter gleichen Bedingungen) gestellt werden. Das bedeutet, jeder kann den Prototyp herunterladen, teilen und für nichtkommerzielle Zwecke nutzen, solange Urheber genannt werden und etwaige Abwandlungen wieder unter derselben Lizenz stehen. Achtung: Solche Vorgaben muss man als Teilnehmer kennen, denn sie beeinflussen die Verwertungsmöglichkeiten. Im CC-NC-SA Beispiel heißt das: Der Prototyp wäre für andere nichtkommerziell nutzbar, die Urheber behalten aber das Recht, selbst kommerzielle Versionen zu entwickeln. Dennoch entsteht faktisch eine breite Verfügbarkeit des Spiels (wenn auch ohne kommerzielle Nutzung) – das könnte spätere exklusive Deals erschweren, weil eine frühe Version quasi frei kursiert (wenn auch nur non-profit). Andere Jams erlauben auch gleich Open-Source-Lizenzen (MIT, Apache, etc.). Für Teilnehmer:innen gilt: Prüft, ob ihr mit solch einer Lizenz einverstanden seid. Wenn man sicher plant, kommerziell weiterzumachen, kann eine zu restriktive offene Lizenz hinderlich sein. Umgekehrt kann eine offene Lizenz Konflikte unter Teammitgliedern reduzieren, weil von vornherein klar ist, jeder kann das Ergebnis nutzen (halt unter den Lizenzbedingungen).
• Pflichten der Teilnehmer in Bezug auf fremde Inhalte: Viele Jam-AGB enthalten auch, dass nur eigene oder lizenzierte Inhalte verwendet werden dürfen (keine geklauten Assets, keine urheberrechtsverletzenden Materialien). Das schützt alle Beteiligten: Das Team läuft nicht Gefahr, wegen z.B. unerlaubt verwendeter Musik abgemahnt zu werden, und der Veranstalter haftet nicht für solche Rechtsverletzungen. In der Praxis heißt das: Wenn ihr im Jam fremde Ressourcen benutzt (z.B. ein frei verfügbares Asset), stellt sicher, dass die Lizenz das zulässt und behaltet Nachweise darüber.
• AGB-rechtliche Angemessenheit: Teilnahmebedingungen eines Jams sind rechtlich gesehen allgemeine Geschäftsbedingungen, die gegenüber Verbrauchern wirksam einbezogen werden müssen (§§ 305 ff. BGB) und keine unfairen Klauseln enthalten dürfen (§ 307 BGB). Eine Klausel etwa, die dem Veranstalter alle Verwertungsrechte am Spiel überträgt, wäre wohl überraschend und unangemessen – sie hätte gute Chancen, unwirksam zu sein. Derartige Extremfälle sind aber, wie gesagt, in der Community unüblich. Meist geht es eher um Schutz der Veranstalter (Haftungsausschluss, Verhaltensregeln etc.) und um o.g. Lizenzen.
• Kein Vertrag unter Teilnehmern durch AGB: Wichtig zu verstehen: Die Teilnahmebedingungen regeln primär das Verhältnis Veranstalter – Teilnehmer. Sie schaffen keine direkten Verträge zwischen den Teammitgliedern untereinander. Also Fragen wie „wem gehört der Prototyp im Team“ werden durch Jam-AGB nicht automatisch gelöst. Wenn z.B. die Jam-AGB sagen „alle Rechte bleiben bei den Urhebern“, bestätigt das nur den Grundsatz, ändert aber nichts an der internen Verteilung unter mehreren Urhebern. Das Team muss also eigene Absprachen treffen – der Veranstalter mischt sich in die interne Rechteverteilung normalerweise nicht ein (außer durch die Wahl einer offenen Gesamt-Lizenz, was aber auch eher gegenüber Dritten wirkt).

Praxis-Beispiel Jam-AGB: Eine Jam-Teilnahmebedingung könnte etwa lauten: „Alle Rechte am entwickelten Spiel verbleiben bei den Teilnehmern. Die Teilnehmer versichern, dass ihre Beiträge eigenständig und frei von Rechten Dritter sind. Durch die Einreichung des Spiels räumen die Teilnehmer dem Veranstalter ein einfaches Nutzungsrecht ein, das Spiel im Rahmen der Berichterstattung über den Game Jam öffentlich zugänglich zu machen und zu vervielfältigen. Im Übrigen ist eine kommerzielle Nutzung durch den Veranstalter ausgeschlossen.“ – Als Teilnehmer weiß man dann: Das IP gehört uns, der Jam darf es nur zeigen, und wir müssen darauf achten, keine geschützten Fremdinhalte zu verwenden.

Vertragsfreiheit: Eigene Absprachen gehen vor

Ein grundlegendes Prinzip, das über all dem steht: Vertragsfreiheit. Die Beteiligten eines Game-Jam-Teams können (und sollten) ihre eigenen Regeln festlegen, sofern sie nicht ausdrücklich gegen zwingendes Recht verstoßen. Das Urheberrechtsgesetz bietet den Default-Rahmen für den Fall, dass nichts vereinbart wurde – aber man darf fast alles anders regeln:

• Einfacher Vertrag unter Teammitgliedern: Schon beim Jam (oder idealerweise davor) könnten die Teammitglieder eine Vereinbarung treffen. Das muss kein seitenlanger Vertrag in Juristendeutsch sein; auch eine kurze schriftliche Absprache oder E-Mail kann genügen. Wichtig ist der gemeinsame Wille, gewisse Punkte zu regeln. Beispielsweise: „Wir vereinbaren, dass jede/r von uns das entstandene Spiel später alleine weiterentwickeln und nutzen darf, ohne die anderen fragen zu müssen.“ – Das wäre eine weitreichende gegenseitige Lizenz. Oder umgekehrt: „Wir halten fest, dass wir das Spiel nur gemeinsam kommerziell nutzen und Entscheidungen einstimmig treffen.“ – Das bestätigt die gesetzliche Miturheberlage. Solange alle einverstanden sind, gilt so eine Absprache.
• Formfreiheit – aber Schriftlichkeit empfohlen: Solche Verträge können mündlich geschlossen werden, aber aus Beweisgründen sollte immer etwas Schriftliches existieren. Ein kurzes gemeinsam unterzeichnetes Dokument oder auch Chats, in denen klar eine Einigung formuliert wird, sind viel wert. Im Zweifel werden Gerichte bei unklaren Absprachen auf die Vertragsauslegung zurückgreifen: Was haben die Parteien erkennbar gewollt? Gab es Indizien für ein bestimmtes Einvernehmen? Hier können auch Verhalten oder Statements während des Jams relevant sein (z.B. „Lass uns das alles Open Source machen!“ – wenn alle dem zugestimmt haben, könnte das als Lizenzvertrag im Raum stehen).
• Grenzen: Unübertragbare Rechte: Manche Aspekte kann man nicht wegverhandeln. Urheberpersönlichkeitsrechte (Recht auf Namensnennung, Entstellungsschutz etc.) bleiben immer beim Urheber. Man kann also z.B. nicht wirksam vereinbaren: „X verzichtet darauf, jemals als Urheber genannt zu werden“ – X könnte sich später trotzdem anders überlegen, auch wenn er zunächst darauf verzichtet hat, genannt zu werden. Allerdings kann X natürlich praktisch erklären, dass er anonym bleiben will; das muss nur nicht für ewig bindend sein.
• Fairness und spätere Auslegung: Bei unstimmigen oder lückenhaften Abmachungen werden allgemeine Vertragsauslegungsregeln angewandt (§§ 133, 157 BGB). Danach wird geschaut, was die Parteien gewollt haben und was verkehrsüblich ist. Hatten alle wenig juristischen Hintergrund, wird man eine für alle vernünftige Auslegung suchen. Im Zweifel eher keine Abtretung aller Rechte, wenn das nicht klar ausgesprochen wurde – denn so etwas ist nicht selbstverständlich. Beispiel: Wenn einer behauptet, alle anderen hätten ihm „schon auf dem Jam mündlich alle Rechte geschenkt“, wird er dafür sehr deutliche Belege brauchen. Bloße Begeisterungsrufe wie „Mach du mal, ich brauch’s eh nicht“ können leicht verschieden interpretiert werden. Hier hilft eben wieder: schriftlich klarstellen, wenn man solche weitreichenden Abreden trifft.
• AGB untereinander? Wenn eine Person dem Team gewissermaßen ihre eigenen Bedingungen vorgibt (z.B. „Ich mache mit, aber nur wenn wir schriftlich festhalten, dass ich die IP später nutzen darf“), könnte man darüber philosophieren, ob das AGB-Recht innerhalb des Teams greift. Praktisch spielt das selten eine Rolle, weil die Teams klein sind und Verhandlungen auf Augenhöhe stattfinden – jeder kann ja mitreden oder notfalls gehen. AGB-Recht soll vor einseitigem Diktat schützen, typischer bei professionellen Auftraggebern gegenüber einzelnen Entwicklern. In unseren Fällen sind es meist Individualabreden.

Zusammengefasst: Was auch immer das Gesetz als Standard vorsieht – einvernehmliche Absprachen der Beteiligten haben Vorrang. Daher raten viele Experten, zumindest eine Minimal-Vereinbarung zu treffen, sobald klar ist, dass das Projekt Potenzial hat. Das erspart später Kopfschmerzen, denn nichts ist ärgerlicher als retrospektiv um Erlaubnis oder Anteile feilschen zu müssen.

Bewährte Vertragstypen und Modelle in der Praxis

In der Games- und Softwareentwicklung haben sich einige Vertragsmodelle herausgebildet, um genau solche Situationen abzudecken. Im Folgenden einige relevante Vertragstypen, die in offenen Kollaborationen zum Einsatz kommen können:

Nutzungsrechtevereinbarung / Lizenzvertrag im Team

Dies ist eine einfache Vereinbarung, dass alle Teammitglieder sich gegenseitig Nutzungsrechte an ihren Beiträgen einräumen. Im Kern: „Du darfst meine Teile nutzen, ich deine, für alle Zwecke am Projekt.“ Dadurch kann jede:r mit dem Gesamtwerk arbeiten, ohne ständig um Erlaubnis zu bitten. Man kann festlegen, ob das exklusiv (nur die Teammitglieder dürfen es nutzen) oder nicht-exklusiv (jeder darf seine Beiträge auch außerhalb lizenzieren) sein soll. Für die Weiterentwicklung ist meist Exklusivität fürs Team sinnvoll, damit kein Außenstehender plötzlich dieselben Assets verwendet.

Ein solcher Vertrag sollte auch regeln, für wie lange und welchen Umfang die Lizenz gilt. Ideal: unbefristet und weltweites Nutzungsrecht, inkl. aller bekannten Nutzungsarten (Vervielfältigung, Verbreitung, Ausstellung, Bearbeitung, etc.). So hat man vorgesorgt für jede Form von Game-Release (digital, evtl. physisch als Collectors Edition, Ports, Merchandising aus Grafiken, usw.).

Gründung einer GbR (Gesellschaft bürgerlichen Rechts)

Ein informelles Entwicklerteam, das vorhat, gemeinsam Geld zu verdienen, wird nach deutschem Recht unter Umständen automatisch als GbR betrachtet – nämlich dann, wenn man sich zusammenschließt, um einen gemeinsamen Zweck (hier: Entwicklung und Vermarktung des Spiels) zu verfolgen. Die GbR entsteht formlos durch den Einigungswillen hierzu. Vorteil: Eine GbR kann Inhaberin von Rechten sein. Oft legt man in einem GbR-Vertrag (schriftlich) fest, dass alles, was im Rahmen der GbR geschaffen wird, gemeinsames Eigentum der GbR ist. Dann müssen nicht zig einzelne Übertragungen untereinander erfolgen – das Gemeinschaftsunternehmen hält die Rechte. Die Gesellschafter (Teammitglieder) haben dann Anteile an der GbR und letztlich am Erfolg.

Allerdings haftet eine GbR auch mit Privatvermögen der Gesellschafter und ist nicht so formalisiert wie eine Kapitalgesellschaft. Für den Übergang ist sie ok, langfristig wechseln viele dann in eine UG/GmbH.

Gründung einer Kapitalgesellschaft (UG, GmbH)

Dies ist der professionelle Schritt: Die Teammitglieder gründen ein Startup als juristische Person. Bei Gründung oder per nachträglichem Vertrag übertragen alle ihre bisherigen Rechte am Prototyp auf die Gesellschaft. Ab dann kann die Gesellschaft als Rechteinhaberin agieren. Der Vorteil sind klare Verhältnisse und Haftungsbeschränkung. Intern wird über einen Gesellschaftsvertrag geregelt, wer wie beteiligt ist und wer was einbringt. Meist bringt jeder sein „geistiges Eigentum“ ein (hier der Prototyp und Folgerechte), oft gegen Einräumung von Geschäftsanteilen. Das erfordert etwas Aufwand (Notar bei GmbH), aber es schafft für externe Partner Vertrauen: Sie verhandeln dann nur noch mit der Firma, nicht mit jedem Einzelentwickler.

Auftrags- oder Arbeitsverträge für Beiträge

Manchmal wird externe Hilfe ins Team geholt (z.B. ein:e Komponist:in für den Soundtrack) oder ein Teammitglied arbeitet quasi mehr als Dienstleister mit, ohne am späteren Projekt beteiligt sein zu wollen. Dann empfiehlt sich ein klarer Werkvertrag oder Dienstvertrag, in dem steht, dass die Person für eine Vergütung XYZ einen Beitrag leistet und die erforderlichen Nutzungsrechte an das Team/die Firma überträgt. Standardklausel: Der Auftragnehmer räumt dem Auftraggeber ausschließliche, übertragbare Nutzungsrechte an seinem Beitrag ein, zeitlich, räumlich, inhaltlich unbegrenzt. Damit kauft man sich sozusagen das Stück IP ein. Solche Verträge kennt man z.B. aus der Auftragsprogrammierung oder wenn ein Freelancer Artworks beisteuert.

Wichtig: Ohne so einen Vertrag behält ein Freelancer sonst die Rechte an seinem Beitrag, und das Team hat nur ein (stillschweigend) eingeräumtes einfaches Nutzungsrecht im Umfang des Vertragszwecks. Das kann später Probleme machen, falls man mehr damit tun will, als ursprünglich besprochen. Darum immer schriftlich fixieren.

Vertraulichkeitsvereinbarung (NDA)

In offenen Jams selten, aber im professionelleren Umfeld üblich: Wenn man seine Idee oder den Prototyp vielleicht Dritten zeigt oder mit neuen Leuten daran arbeitet, kann eine Non-Disclosure Agreement (NDA) sinnvoll sein. Sie schützt zwar nicht direkt Urheberrechte, aber verhindert, dass Wissen abfließt und etwa jemand anders die Idee vorweg nimmt. Bei Game Jams, wo alle gleichzeitig veröffentlichen, ist das meistens nicht relevant. Doch wenn nach dem Jam weitergearbeitet wird und man Externe ins Boot holt (Berater, potenzielle Publisher zu frühem Zeitpunkt), sollten diese eine NDA unterzeichnen, um das Team abzusichern. Ansonsten könnte es passieren, dass ein Publisher die Idee ablehnt und dann doch selbst ein ähnliches Spiel entwickelt (was Ideenklau wäre, aber schwer nachzuweisen ohne NDA).

Open-Source-Lizenzierung

Ein bewährter Ansatz, um Konflikte zu vermeiden, ist das bewusste Open-Source-Stellen des Prototyps. Wenn alle zustimmen, den Quellcode unter eine OSS-Lizenz (z.B. MIT, GPL, Apache) zu stellen, dann ist von vornherein geklärt, dass jeder den Code nutzen kann – nicht nur im Team, sondern weltweit. Das nimmt internen Streit den Wind aus den Segeln (alle haben eh gleiche Rechte als Nutzer der OSS) und fördert ggf. Community-Beiträge. Allerdings muss klar sein: Dann kann auch außerhalb jemand mit dem Code arbeiten, ggf. schneller sein oder ein Konkurrenzprodukt machen (gerade bei sehr permissiver Lizenz wie MIT). Für Assets (Grafiken, Sounds) gibt es ebenfalls freie Lizenzen (z.B. CC-BY). Einige Teams wählen diesen Weg, wenn sie das Projekt eher als gemeinschaftliches Gut denn als kommerzielle Ware sehen. Oder als Kompromiss: Code Open Source, aber vielleicht bestimmte markante Assets zurückhalten.

Open-Source-Strategie kann auch untereinander Vertrauen schaffen: Falls einer aussteigt, kann ein anderer dennoch mit dem Code weitermachen, weil es ja lizenzrechtlich erlaubt ist (solange er die Lizenzbedingungen einhält, z.B. Nennung und Bei-Weitergabe offenlassen bei GPL etc.). Zu beachten: Alle Miturheber müssen zustimmen, bevor man ein gemeinsames Werk Open Source stellen kann, sonst verstößt man selbst gegen die Miturheberrechte der anderen.

Zwischenfazit: Es gibt nicht die eine richtige vertragliche Lösung – je nach Zielen der Beteiligten bieten sich verschiedene Wege an, vom lockeren „Gentlemen’s Agreement“ bis zur firmengründenden Übertragung. Wichtig ist nur, überhaupt eine Lösung zu haben. Zu oft wird in der Euphorie ganz vergessen, klare Rechtevereinbarungen zu treffen, was später viel aufwändiger nachzuholen ist.

Praktische Handlungsempfehlungen für die Zielgruppen

Abschließend fassen wir konkrete Tipps zusammen, zugeschnitten auf die verschiedenen Akteure: einzelne Entwickler:innen, Teams/Studios sowie Veranstalter von Game Jams. Diese Empfehlungen sollen helfen, das Konfliktpotenzial zu minimieren und allen Seiten Sicherheit zu geben.

Für einzelne Entwickler:innen und kreative Köpfe

1. Informiere dich über die Regeln des Jams: Lies die Teilnahmebedingungen genau. Stelle sicher, dass du verstehst, welche Lizenzbedingungen gelten und ob du damit einverstanden bist (z.B. wenn der Prototyp open-source sein muss). Nur so kannst du bewusst entscheiden, was du beim Jam preisgibst.
2. Klärt Erwartungen im Team frühzeitig: Sprich schon beim Formieren des Jam-Teams an, was ihr nach dem Jam mit dem Projekt vorhabt. Ist es nur zum Spaß oder gibt es Ambitionen, weiterzumachen? Ein kurzes Gespräch kann Missverständnisse vorbeugen. Wenn jemand sagt „ich möchte das evtl. später kommerziell nutzen“, sollte das offen auf den Tisch.
3. Dokumentiere deinen Beitrag: Auch wenn es vielleicht pedantisch wirkt – sorge dafür, dass dein Anteil erkennbar ist. Nutze eigene Accounts für Commits, bewahre Originaldateien auf, und halte notfalls privat fest, was du beigetragen hast (z.B. in deinem Portfolio oder Blog hinterher: „Habe bei Spiel X die Level 1-3 gestaltet und den Hauptcharakter programmiert“). Das schafft Klarheit über deine Urheberschaft.
4. Respektiere die Beiträge der anderen: Nimm nicht einfach an, dass du nach dem Jam alleine mit dem Projekt durchstarten darfst. Die anderen haben Rechte an ihren Teilen. Behandle dies mit der gleichen Achtung, mit der du deine Rechte behandelt sehen willst. Hol dir Zustimmung ein, bevor du etwas alleine veröffentlichst oder veränderst, was nicht nur von dir stammt.
5. Sichere dir notfalls Nutzungsrechte schriftlich: Wenn du planst, den Prototyp auf jeden Fall für eigene Zwecke zu verwenden, rede mit deinen Mitstreitern offen und versuche, eine schriftliche Erlaubnis zu bekommen. Das kann auch ein simples Schreiben sein: „Hiermit stimme ich zu, dass [Name] den gemeinsam erstellten Prototyp eigenständig weiter nutzen und kommerziell verwerten darf.“ Unterschrift/Name drunter, fertig. Es mag ungewöhnlich klingen unter Freunden, aber im Nachhinein wirst du froh sein, Klarheit zu haben.
6. Schutz deiner Idee außerhalb des Teams: Sei vorsichtig, wem du außerhalb des Teams deinen Prototyp oder deine geniale Idee zeigst, bevor du irgendeinen Schutz hast. In der Jam-Community ist zwar vieles offen, aber wenn du wirklich denkst, das Konzept ist revolutionär und du willst es patentieren (Spielideen sind allerdings nicht patentierbar) oder aufbauen, teile Details nicht leichtfertig ohne NDA an Dritte. Innerhalb des Teams sollte Transparenz herrschen, aber außerhalb gilt: so viel wie nötig, so wenig wie möglich preisgeben, bis du abgesichert bist.

Für Studios, Startups und Gründer:innen

1. IP-Check bei Rekrutierung: Wenn ihr ein vielversprechendes Jam-Team übernehmen oder deren Prototyp lizenzieren wollt, prüft die IP-Lage. Lasst euch von allen Beteiligten schriftlich versichern, dass sie Urheber sind und keine dritten Ansprüche bestehen. Klärt, ob eventuell Open-Source-Komponenten drin sind, die es zu beachten gilt (Stichwort Copyleft-Lizenzen).
2. Alle an Bord holen: Es ist klug, alle Urheber ins Boot zu holen, sei es durch Anstellung, durch eine Beteiligung oder zumindest durch klare Verträge. Der schlimmste Fehler wäre, zu denken „Person X hat uns das angeboten, die anderen werden schon stillhalten“. Gerade wenn Erfolg absehbar ist, melden sich Urheber, die bisher still waren, ganz sicher – was ihr gutes Recht ist. Also: Rechtekette lückenlos schließen. Jeder, der kreativ beigetragen hat, muss entweder Teil der Firma sein oder seine Rechte übertragen haben, bevor große Investitionen getätigt werden.
3. Klare Gründervereinbarung: Wenn ihr selbst Teil des Jam-Teams wart und jetzt gründet, schließt untereinander einen rechtsverbindlichen Gründervertrag. Darin: Wer bringt welche Vorleistung (Prototyp, Ideen), wie werden künftige Anteile oder Gewinne verteilt, was passiert bei Ausstieg eines Gründers und was passiert mit dessen Anteilen/Rechten, etc. Gerade Startups scheitern oft an Unklarheit unter den Foundern – umgeht das durch upfront-Regeln.
4. Nutzung existierender Musterverträge: Nutzt verfügbare Muster für Entwicklerverträge. Viele IT-Anwälte oder Gründerinitiativen haben Vorlagen für IP-Übertragungen, Lizenzverträge oder NDAs. Z.B. kann ein IP-Assignment Agreement sinnvoll sein, das jede:r unterschreibt, worin alle Rechte an der entstehenden Software an das Unternehmen übergehen. Standard in vielen Tech-Startups.
5. Achtung bei Mitarbeiter-Jams: Wenn ein Mitglied eures Teams (bereits als Angestellter) auf einem externen Jam mitmacht, checkt eure Arbeitsverträge. Normalerweise regeln diese, ob der Arbeitgeber an „Neben-Erfindungen“ oder Projekten Ansprüche hat. Bei Software ist § 69b UrhG zu beachten: Software, die im Rahmen des Arbeitsverhältnisses geschaffen wird, gehört dem Arbeitgeber bzgl. Nutzungsrechten. War der Jam aber in der Freizeit ohne Bezug zum Arbeitgeber, sollte der Arbeitgeber keine automatischen Rechte haben – es sei denn, im Vertrag steht was anderes. Tipp: Klärt intern, ob Angestellte bei Jams mitmachen dürfen und wie entstehende IP behandelt wird. Manchmal fördern Unternehmen interne Game Jams; dann sollte aber eindeutig sein, dass alles entweder dem Unternehmen gehört (wenn gewollt) oder freigegeben wird. Unklarheit hier kann später für das Unternehmen selbst problematisch sein, wenn der Mitarbeiter das Jam-Projekt separat verwertet.
6. Sorgfältige Due Diligence: Wenn ihr einen Prototyp kaufen wollt, macht quasi eine kleine Due Diligence: Lasst euch z.B. die Git-Repository-Historie zeigen, schaut, ob in den Dateien klare Autoren-Kommentare sind, fragt nach, wer genau was gemacht hat. Identifiziert potentielle „IP-Lücken“ (z.B. „den Sound hat uns ein Freund gegeben, der war aber nicht offiziell im Team“ – hier müsstet ihr dann eine Erlaubnis von diesem Freund einholen). Besser jetzt nachfragen als nachher in einem Rechtsstreit aufdecken.

Für Anbieter und Veranstalter von Game Jams

1. Klare und faire Teilnahmebedingungen: Stellen Sie sicher, dass Ihre AGB eindeutig formulieren, was mit den Spielideen und Prototypen passiert. Empfehlung: Schreiben Sie explizit hinein, dass alle Rechte bei den Teilnehmern bleiben. Dies schafft Vertrauen und schützt Sie auch davor, in Miturheber-Konflikte hineingezogen zu werden. Definieren Sie, welche Rechte Sie als Veranstalter benötigen (Präsentation, Veröffentlichung auf der Jam-Website usw.) und verzichten Sie auf darüber hinausgehende Ansprüche.
2. Transparenz über Lizenzierung: Wenn Sie möchten, dass die Ergebnisse geteilt werden können (Open Source, Creative Commons), dann kommunizieren Sie das unmissverständlich vorab. Nutzen Sie wenn möglich gängige Lizenzmodelle (z.B. „Die Spiele stehen standardmäßig unter CC-BY-NC“, etc.) und erklären Sie kurz, was das bedeutet. Einige Teilnehmer sind juristische Laien – helfen Sie ihnen, indem Sie die Konsequenzen erläutern. Und ganz wichtig: Lassen Sie sie diese Bedingungen aktiv akzeptieren (z.B. beim Registrieren oder Einreichen des Spiels).
3. Ermutigung zu Team-Absprachen: Sie könnten als Veranstalter proaktiv darauf hinweisen, dass die Teams gut daran tun, ihre Zusammenarbeit zu klären. Vielleicht im Vorfeld oder in einem Info-Sheet: „Tipp: Überlegt euch im Team, wie es nach dem Jam weitergeht. Wenn ihr euer Spiel kommerziell nutzen wollt, sprecht darüber offen. Ihr könnt z.B. Vereinbarungen treffen, um spätere Konflikte zu vermeiden.“ – Solche Hinweise sensibilisieren die Teilnehmer für das Thema, ohne dass Sie als Veranstalter eingreifen müssen.
4. Schutz vor Haftung: Nehmen Sie in die AGB eine Klausel auf, dass Teilnehmer zusichern, nur Materialien zu verwenden, an denen sie die Rechte haben, und dass sie den Veranstalter von Ansprüchen Dritter freistellen, falls doch jemand Rechte verletzt. So schützen Sie sich, sollte bspw. einer urheberrechtlich geschützte Musik in sein Spiel tun und der Rechteinhaber den Veranstalter wegen der Präsentation auf der Jam-Website belangen will.
5. Keine Vereinnahmung von Ideen: Vermeiden Sie den Eindruck, Sie könnten Ideen der Teilnehmer „stehlen“. Etwaige Jurys oder Coaches sollten Verschwiegenheit wahren, wenn es um nicht-öffentliche Projektinfos geht. Professionelle Veranstalter – z.B. in Kooperation mit Firmen – müssen hier besonders sensibel sein, damit das Vertrauen der Entwickler-Community nicht verspielt wird. Ein negative Beispiel wäre, wenn nach einem Jam die veranstaltende Firma plötzlich ein ähnliches Spiel entwickelt, ohne die ursprünglichen Teams einzubeziehen.
6. Unterstützung nach dem Jam: Als Veranstalter können Sie auch Plattformen für die Weiterarbeit bieten. Manche Game Jams haben Nachfolge-Programme oder Mentoring für Teams, die weitermachen möchten. Hier können Sie Hilfestellung leisten, vielleicht auch Standard-Dokumente bereitstellen (z.B. Mustervorlagen für einfache Teamvereinbarungen) – sofern das in Ihrem Interesse liegt, die Projekte reifen zu sehen. Das ist natürlich kein Muss, geht aber heute in Richtung Community-Management.

Fazit

Game Jams und offene Entwicklungsformate sind fantastische Brutstätten für Kreativität und Innovation. Doch gerade weil am Anfang alles formlos und freundschaftlich zugeht, werden rechtliche Weichenstellungen oft übersehen. Die Frage „Wem gehört der Prototyp?“ ist keineswegs trivial: Ohne Absprachen gehören die Rechte grundsätzlich den Schöpfern – häufig allen gemeinsam. Das kann zur Bremse werden, wenn es weitergehen soll, oder zu Konflikten, wenn sich Wege trennen.

Die Rechtslage nach deutschem (und im Wesentlichen auch europäischem) Urheberrecht gibt einen Rahmen vor, der Kooperation erfordert, sobald mehrere Urheber im Spiel sind. Miturheberschaft (§ 8 UrhG) bedeutet eben Gemeinschaftseigentum am kreativen Werk – erfreulich im Sinne von gemeinsam geschaffen, aber anspruchsvoll, was spätere Entscheidungen betrifft. Daher ist unsere Kernempfehlung: Schafft klare Verhältnisse!

Für Entwickler:innen heißt das, sich schon früh Gedanken zu machen und notfalls die unliebsame Rechtsfrage aktiv anzusprechen. Für Teams/Startups, die aus Jams hervorgehen, ist Professionalität in Sachen IP unerlässlich – es zahlt sich spätestens beim ersten Vertrag mit einem Publisher aus. Und für Veranstalter liegt es im Interesse, den Rahmen so zu gestalten, dass Kreativität gefördert wird, ohne unnötige Fallen.

Mit dem richtigen Maß an Vorsorge – seien es einfache schriftliche Abmachungen, eine weitsichtige Lizenzierung oder ein ausformulierter Kooperationsvertrag – lässt sich die kreative Energie aus Game Jams nahtlos in erfolgreiche Projekte überführen. So können alle Beteiligten fair partizipieren, und aus dem kleinen Prototyp von heute wird vielleicht der Indie-Hit von morgen, ohne dass der Spaß von gestern zum Streitfall von morgen wird.