Game jams are short-term development competitions where creative minds collaborate to create game prototypes in just a few days. The atmosphere is characterized by innovation, teamwork, and time pressure. Independent developers, designers, and other creatives often meet without prior agreement. Exciting prototypes are created in the euphoria, but who actually owns the resulting game? Especially in early development phases without contractual regulations, copyright issues arise that can later lead to tangible conflicts in the event of commercialization. This blog post sheds light on the legal background and provides practical recommendations to avoid disputes and create clear conditions for all parties involved.

Game Jam Copyright: Legal Background and Ownership in Open Collaboration

Game jams and similar open collaborations often lead to the joint creation of a creative result without written contracts. Legally, we are dealing here with copyright law, specifically German and European copyright law. Copyright law protects personal intellectual creations, such as source code, graphics, music, or stories of a game. In Germany, the principle is clear: the author is the creator of the work (Section 7 UrhG). This means that the person who makes a sufficiently creative contribution automatically acquires copyrights to this contribution.

In a game jam, everyone in the team typically contributes something to the prototype, be it programming, level design, artwork, or story. When these contributions flow into a joint work, the question arises: Is there a joint copyright for all participants? Or does each person only have rights to their own contribution? In the following sections, we will explain the basics, such as co-authorship, associated works, level of creation, and usage rights. We will then turn to specific conflict scenarios and possible solutions.

Copyright Principles for Joint Projects

Before we discuss game jams in detail, it is helpful to provide a brief overview of relevant copyright concepts:

Author and Work: A work within the meaning of copyright law is a personal intellectual creation (Section 2 (2) UrhG). This includes, for example, software, graphics, musical compositions, or texts, provided they have a sufficient level of creation. This means they should not be purely trivial or commonplace. The author is always the person who performs this creation (§ 7 UrhG). In the case of a computer game prototype, several people can therefore contribute different works (e.g., a piece of music, a level design, or code), which together form the game.
Sole Authorship: If one person alone has created a complete work, the matter is clear: this person is the sole author and can decide on it.
Co-authorship: If several persons jointly create a single work whose parts cannot be exploited separately, they are referred to as co-authors (Section 8 (1) UrhG). Co-authorship means that they all jointly own the copyright to the entire work. A typical example is two developers who jointly write the source code of a game without a clear division of who wrote which part. The code is then inseparably their joint work.
Combined Works: If several authors have combined their independent works solely for joint use without creating an inseparable overall work, these are referred to as combined works (Section 9 UrhG). In this case, each author generally retains the rights to their own work but must agree to the joint exploitation with the others. For example, a programmer develops the game engine, and an artist creates all the graphics. Code and graphics are independent works that combine to create the game. They can exist separately but are exploited together.
Partial Authorship: Colloquially, the term "partial authorship" is sometimes used. This usually refers to either co-authorship of a complete work or authorship of parts of a combined work. It is important to note that copyright law does not recognize the splitting up of a single work into "percentage shares" without co-authorship. It is either a joint work (implying joint copyright in everything) or separate works that are only used together.

These distinctions are central in the context of game jams. Prototypes are often created where code, graphics, and sound are closely interlinked, which may lead to co-authorship. In other cases, contributions may be clearly separable, such as a separately composed soundtrack, resulting in associated works. Without a contractual provision, the law automatically applies, specifically Sections 7-9 UrhG, with all its consequences.

Co-authorship of Jointly Developed Prototypes

If all team members' contributions become an inseparable whole in the game jam, then the rules of joint authorship apply (Section 8 UrhG). Several people would be joint authors of the entire prototype. This has far-reaching consequences:

Joint and Several Rights: Co-authors can only jointly determine the work. The right to publish, exploit (e.g., sale, licensing), and make changes to the work belongs to all of them jointly and severally (Section 8 (2) sentence 1 UrhG). No one alone may distribute the game commercially or, for example, simply develop and publish the code without the consent of the others.
Duty of Consent, Good Faith: In practice, this means that any major use, whether uploading to a platform, sale, or further development, requires the consent of all co-authors. However, no one may refuse their consent contrary to good faith (Section 8 (2) sentence 2 UrhG). This implies that if a co-author has no reasonable interest in blocking a commercial use and their refusal appears vexatious, a court could, in extreme cases, oblige them to give consent. Nevertheless, this is a high hurdle; ideally, conflicts should not escalate this far.
Joint Enforcement of Rights: In the event of copyright infringements (e.g., if an external party copies the prototype without permission), each co-author can bring an action themselves, but only for payment to all co-authors (Section 8 (2) sentence 3 UrhG). This means a co-author can demand an injunction or sue for damages, but the compensation claim would be due to all of them jointly. No co-author may take everything alone or conclude a settlement on joint rights alone that also binds the others.
Distribution of Proceeds: If the joint work generates income, the co-authors are entitled to the proceeds according to the extent of their contribution (Section 8 (3) UrhG), unless they have agreed otherwise. In plain language: whoever has contributed more to the creation should also receive more of the profits. This applies unless the team has decided on a different distribution before or after. In practice, this legal quota is often difficult to measure (e.g., how do you quantify the contribution of a programmer versus a graphic designer?). Teams are therefore well advised to make clear agreements on the split rather than relying on this vague default rule.
Waiver by a Co-author: A co-author can waive their share of the exploitation rights at any time (Section 8 (4) UrhG). This waiver must be declared to the others and results in the remaining co-authors taking over the rights. For example, if one person leaves the team and waives all rights, the others have a free hand. Please note: A waiver only affects the exploitation rights (economic rights). The moral rights (e.g., the right to be named as the author) remain personal and unwaivable. The person, therefore, remains a co-author but can no longer participate in the commercial use.
Moral Rights: Even in the case of co-authors, each person has the right to be named as the author of the work (Section 13 UrhG). In a team, care should therefore be taken to ensure that everyone receives credit if they so wish. Conversely, no one alone can claim to be "the creator" and misappropriate others, as that would be a violation of the co-authors' personal rights. Courts have made it clear that co-authors have a right to be named. In practice: If the prototype is published later, all creative minds should at least be included in the imprint or credits.

Example Scenario Co-authorship: Three developers work on a prototype together in a jam. Person A programs, B creates graphics, and C writes the story and dialogue. Everything together results in a coherent game. None of the contributions would be "the game" on their own; it is a joint work. According to Section 8 UrhG, A, B, and C are co-authors of the entire game. If A and B want to publish the game on Steam after the jam, they need C's green light. This applies even if C "only" contributed the story, as she is a co-author of the entire work. Similarly, C couldn't proceed with the release without A and B. They are all in the same boat.

Separate Contributions: Linked Works Instead of Co-authorship?

Joint project work does not always automatically lead to co-authorship. The important question is: Can the individual contributions be exploited separately? If so, this suggests associated works (Section 9 UrhG) or simply a bundle of individual copyrights instead of a joint one.

In many game jam teams, there is a certain division of labor. For example, one team decides that member X only takes care of the music. The pieces of music are independent, finalized works. Member Y programs the gameplay, and member Z draws all the graphics. In this case, there are several independent works (code, image, music) that are used together.

The legal consequences of linked works or separate contributions are different:

Each Person Retains Copyright to Their Own Work: X is the sole author of the music, Y of the code, and Z of the graphics. In principle, each person can also exploit their own work independently, but not in the combined form without the others. For example, X may publish the composed music separately as a soundtrack album or otherwise license it because it is his own work. Y could possibly use the code he wrote as the basis for another game. Z can show the artwork in a portfolio or use it again.
Joint Use Requires Consent: However, if the works are to be exploited together as a unit (the game), the authors of the individual works must come to an agreement. Section 9 UrhG stipulates that each author of a combined work can demand the consent of the other to the publication, exploitation, and modification of the combination, insofar as this is reasonable in good faith. In practical terms, this means that once X, Y, and Z have agreed to present their contributions together as a game, none of them may refuse further joint use without good reason. They can therefore demand each other's consent if one of them objects. However, this is not as strict in detail as in the case of co-authorship.
No "Joint and Several" Principle: In contrast to co-authorship, the rights are not inseparably merged. Each of them could theoretically dispose of their own work separately as long as the use does not affect the contributions of the others. For example, programmer Y could further develop his game concept with new graphics and new music (without X and Z). He would then only use his own work (the code or the game mechanics, if these are protected by copyright as a software work) and replace the other components. This is legally permissible as long as the original graphics/music of Z and X are no longer used. He must, of course, ensure that he does not take over any protected elements from Z and X. Important: The idea of the game itself is not protected; if Y takes the basic concept (idea) and re-implements it using his own means, he is not infringing the copyright of the former contributors. Morally, this can be tricky, but legally, it is the concrete creative forms of expression that matter, not abstract ideas.
Collective Works as a Special Case: In some constellations, a game could also be considered a collective work (Section 4 UrhG). For example, if it consists of clearly separable level contributions or mini-games that an organizer has collected. In this case, the person compiling the collection would have their own copyright to the collection (provided that the selection or arrangement is self-creative). This rarely plays a role in the classic jam prototype, as everyone usually works closely together on one game instead of compiling several independent pieces of content.

Example Scenario of Connected Works: Let's imagine that participant D writes an independent tool or plugin in the jam that is integrated into the game but could also function independently. Participant E provides graphics that D's plugin uses, but E's images could also be used in another project. Both have contributed their own, separable works. Result: D and E are not co-authors of a single work, but are the sole authors of their respective parts. They must agree if they want to exploit the entire product (game with plugin and graphics), but neither has complete control over the other part. D may continue to distribute her plugin without E's images; E may use her images elsewhere or relaunch the game with another programmer as long as she does not use D's code. For the actual jam game, however, they remain dependent on cooperation or would at least need subsequent agreements.

Level of Creativity: Copyright Protection for Jam Contributions

A key point, especially in the early prototype phases, is the level of creation. Not every idea or small contribution automatically enjoys copyright protection. Copyright law protects concrete designs; abstract game ideas, game mechanics, or simple concepts are not eligible for protection in themselves (Section 2 (2) UrhG requires a personal intellectual creation).

What does that mean in the context of a game jam?

Ideas and Concepts: The basic idea of a game (e.g., "a platformer where you can turn back time") is free. Nobody acquires copyrights to a mere idea. Similarly, game rules or a game principle as such are not protected. This means that if team A comes up with an innovative mechanic during a jam, team B can legally use this mechanic later as long as B does not specifically copy A's code, graphics, or level designs. Caution: However, the boundary between idea and expression is fluid. A very specific level structure or formulated story twist can in turn be protected as an expression, while the abstract rule behind it remains free.
Trivial Contributions: Small contributions without original creativity are not protected. For example, someone in the team only takes care of testing and reports bugs, but does not write any creative code themselves and does not design anything with their own level of creativity. As valuable as this work is for the project's success, it does not constitute copyright. Even purely technical contributions (e.g., the blunt implementation of a precisely specified idea without any scope for individual design) could fail at the threshold. Creativity requires a certain individual character. In case of doubt, however, this hurdle is quite low; even small creative decisions can suffice.
Protected Elements in the Prototype: As a rule, even a simple jam prototype contains some element that can be protected. This could be an original programming code (software is protected as a work unless it is totally banal), a unique character design as a graphic, a creative story idea formulated in concrete terms, or an independent musical melody. As soon as such concrete forms of expression are involved, copyright applies.
Contributors Without Copyright Status: In team projects, it can happen that not every contributor also becomes the legal author. For example, people who only contributed general ideas to the brainstorming session but did not contribute any concrete implementation could not claim any copyrights to the result. Nevertheless, their contributions should not be ignored for the sake of fairness, but legally they have no say in the work without a creative contribution. This means that an idea provider who, for example, proposes a concept that others then translate into their own creative work (code, art) ultimately has no rights to the game if they have not creatively intervened in the work themselves.
Burden of Proof Regarding Level of Creation: If a dispute arises later as to whether a certain contribution is protected by copyright, the person claiming protection must explain why their contribution has the necessary originality. In practice, in case of doubt, it will be assumed that program code or images are usually protected, unless they are quite banal (e.g., a standard menu button). But this theoretical discussion shows: not everyone in the jam automatically has copyrights just because they were part of the team; it depends on the specific creative achievement.

Practical tip: Ideally, teams should discuss transparently who has which role and which contributions are considered creative. If, for example, someone is "just looking over" or playing a test, they will not usually see it as a creative role themselves. More critical are cases in which someone contributes ideas but does not implement anything themselves; expectations can diverge here. Clarity helps to avoid misunderstandings.

Burden of Proof and Documentation: Who Created What?

At the latest when money comes into play, former team members may disagree about who gets what share of the prototype. Perhaps person A suddenly claims to have devised and implemented the crucial mechanics, while person B sees it differently. In a serious case, it must be clarified who is the author of which parts and whether there is co-authorship. The burden of proof plays a major role here.

As a general rule, anyone who derives rights from copyright must be able to prove their authorship. There is no official registration of copyright (unlike patents or trademarks, for example). Therefore, documentation is everything:

Version Management & Commit History: For software projects, using a version control system (e.g., Git) is invaluable. This makes it possible to track who contributed which code and when. Each commit can be assigned to a contributor. In the event of a dispute, a Git history could be strong evidence to show which specific person wrote the creative lines of code. The same applies to design documents with author identification.
Files and Metadata: Designers should keep original files (e.g., Photoshop/Krita files, 3D models) with their metadata. These often contain creation dates and sometimes also author names. If, for example, person X claims that a certain artwork in the prototype was created by them, person Y, who saved the original file with their name, can prove the opposite.
Communication Histories: Team chats (Slack, Discord) or emails can often be used to reconstruct who contributed which idea or who took on which task. Even if ideas are not directly protectable, a chat history can show that a certain person has taken on creative development (e.g., "I'm going to draw the main character like this..."), which, in case of doubt, supports their authorship.
Conditions of Participation and Registration Data: Some game jams require all team members to be named when submitting a project and perhaps even a description of who did what. This information can serve as a reference point later on. If someone was not even listed as a team member but later makes claims, this is at least contradictory.
Witnesses: In an emergency, third parties who were present can also serve as witnesses. Other jam participants or mentors may have observed that person A sat at the code all day while person B mainly organized. Such statements are naturally not always precise but can round off an overall picture.
Reversal of the Burden of Proof for Copyright Notices: Interestingly, Section 10 UrhG states that the person named as the author on standard copies is presumed to be the author. Applied to our topic: if one person is named as the author in the published version of the prototype, e.g., in the imprint or readme, and there is no reference to others, this can have a presumptive effect. However, this standard is intended more for formal information (e.g., on book covers). It should not be relied upon for collaborative projects, but it shows how important clear author information is.

Why all this? If, for example, one of the former team members drives the commercialization alone and claims that the others have contributed nothing or nothing creative, the latter must prove their co-authorship. Conversely, the driver of the project may have to prove that certain parts were created exclusively by him in order to be allowed to use them alone. Good documentation protects against unjustified claims and strengthens your own position.

Practical tip: Even if it seems annoying in the intense jam phase, keep the project history traceable. At the end of the jam, ideally determine together who created which components. This can be done informally in a text file, a readme, or even by email. Such a "creation log" can clear up misunderstandings later on.

Later Commercialization: When the Prototype Becomes a Product

Many game jams end with the prototype simply being left as a learning experience or showcase. But every now and then, the 48-hour project contains a brilliant idea that is pursued after the jam. This is when the question arises with a vengeance: who owns the prototype and who can capitalize on it? Some typical scenarios:

The Entire Team Wants to Continue Together

In the best-case scenario, everyone is motivated and decides to bring the game to market together. In terms of copyright, all co-authors remain as before. However, it is now essential to contractually regulate how the collaboration will continue:

Founding a Studio (Startup): Many successful jam teams set up a small studio (e.g., as a GbR, UG, or GmbH) to tackle the project professionally. It is common for everyone to transfer their copyrights to the prototype to the new company or to grant the company corresponding rights of use. This means that the prototype (and all further developments) then belong to the company and no longer to the individuals. Advantages include the company being able to conclude contracts with publishers, grant licenses, etc., without having to constantly ask all original authors individually. Additionally, issues such as profit distribution are formally clarified via company shares or internal contracts.
Start-up Agreement / Cooperation Agreement: Before setting up a company (which takes some time), a cooperation agreement between the parties involved can help. This defines who takes on which role, how decisions are made, how revenues are shared, and, in particular, who contributes which rights. For example, it could state that all contributors may use the prototype jointly for further development, that later works are jointly owned, or that, in case of doubt, a majority decision applies if someone wants to leave. Freedom of contract prevails here, meaning the team can make any arrangement that does not violate the law or common decency. It is important to have clear agreements to prevent disputes later on.
Granting Rights of Use to Each Other: If a formal company is not (yet) desired, it can be agreed that everyone grants each other irrevocable rights of use to all contributions in order to continue the project. In this way, each person would be entitled to use the entire work without having to ask each time. Precision is required here: Which rights (editing, distribution, commercial use, etc.) are granted to whom? Ideally, these should be comprehensive for the purpose of the project. It should also be regulated what happens if someone leaves later: do they still retain a right of use (e.g., to make their own version?), or does it expire? Such points should be set out in writing if possible.
Distribution of Income and Tasks: In the case of commercialization, the question of money arises: Does the legal rule remain (§ 8 para. 3 UrhG - according to the extent of participation) or do you agree on other keys? Often, concrete percentages or equal participation via company shares will be defined. In addition, one person can perhaps be given a greater leadership role (e.g., project management). This could also be set out in agreements, outlining who can decide what, etc., to ensure the ability to act (because otherwise, with co-authors, everyone would actually have to decide everything together).

In short: if the team stays together, the informal cooperation turns into a business project. At this point at the latest, professional protection is required. Success stories show that clear agreements or even founding a company are the best ways to turn a prototype into a product.

Only Part of the Team or One Person Wants to Continue the Project

A more common scenario is that not everyone involved has the time, inclination, or opportunity to continue working on the game after the jam. Maybe it was a weekend of fun, and some have to return to their everyday lives. Others don't believe in the commercial viability, while one member is on fire. What happens if, for example, one person alone wants to bring the idea to market maturity?

The legal situation is tricky here: If the prototype is previously jointly (co-)copyrighted, one person cannot simply "free themselves" unless they obtain the rights of the other or legally circumvent them. Some options:

Obtaining Consents/Licenses: The cleanest way is for the remaining person to contact all former team members and agree with each of them in writing that they may continue and exploit the project on their own. This can be formulated as a license agreement (i.e., the others grant him/her an exclusive right of use, possibly in return for a share or a one-off payment) or as a transfer of rights (assignment of copyrights within the scope of what is permissible; only the exploitation rights can be legally transferred, as moral rights are inalienable). It is important that the agreement is as comprehensive as possible: including editing rights, distribution rights, etc., so that the person who continues to act alone is free to do so. A profit share or remuneration is often agreed upon to make the other person's approval more palatable.
Waiver Pursuant to Section 8 (4) UrhG: As mentioned above, a co-author can waive their share of the exploitation rights. It is therefore conceivable that all but the remaining person declare in writing to the remaining person that they waive their exploitation rights to the prototype. As a result, these shares "accrue" to the remaining person, who then holds the exploitation rights alone. The advantage is that it is a solution provided for in the Copyright Act that sounds relatively uncomplicated. However, most people will not want to do this for free, so a small settlement or other consideration will often have to be discussed. In addition, the waiver under Section 8 (4) is final, meaning the others would then no longer be able to do anything commercially with the old prototype, not even jointly without the remaining person. This should be clear to everyone.
New Development (Bypass): If no agreement is reached, either because someone does not agree or cannot be found, the only way out is often to replace the protected contributions of others. This means that the remaining person redevelops all third-party parts so that they no longer have to use anything to which they do not have exclusive rights. This is a difficult but sometimes practicable approach. For example, if someone has contributed music to the jam and now refuses permission to use it, the person developing it further can simply compose or license new music and remove the old one. Similarly with graphics: exchange original assets. It is more difficult with code, but if you know which part came from whom, you can try to refactor or rewrite the code originating from others. It is important that no copyright-relevant elements of the others remain. The game idea itself may, of course, remain; nobody can monopolize it. General algorithms that are not individually formative could also be argued. But be careful: if, for example, a level design is adopted 1:1, even though it originates from a competitor, that would be critical, as their "expression" lives on.
Risk of "Good Faith": Theoretically, you could try to argue that a team member who does not participate is dishonestly refusing consent (contrary to good faith, Section 8 (2) UrhG) and therefore you may exceptionally continue without him/her. This is uncharted legal territory and extremely risky. You should not do this without a court ruling, and no one would want court proceedings at such a stage. In practice, you will therefore try to obtain approval, possibly by applying pressure or persuasion, or you will take the detour of redevelopment.
Attribution and Credits: Even if the others give up their exploitation rights, they usually still have a right to recognition of their authorship for what they originally created (Section 13 UrhG). In a further development scenario, it is often agreed that the finished game will state in the credits: "Based on a prototype by X, Y, and Z" or that the original jam contributions will be acknowledged. This is not only legally fair but also better for the climate in the development community.

Example Scenario: Anna and Ben develop an innovative puzzle game prototype in a jam. Both are co-authors of the code and design, as everything was created in close collaboration. After the jam, Ben is not interested in continuing, but Anna is. Anna wants to bring the game out commercially. She now has two options: (a) Ask Ben for written permission to exploit the game on her own, perhaps offering him a 10% share of sales. Ben agrees and waives his rights; Anna is safe. Or (b) Ben does not react or refuses. Anna decides to replace everything from Ben. She rewrites large parts of the code (because Ben had done a lot of programming) and replaces Ben's level designs with her own. In the end, she has a game that is essentially based on the jam idea, but no longer contains any elements copied from Ben in the actual design. Anna can then publish the new game. Of course, (b) is very time-consuming; it shows how important it is to take the simple route (a) via agreement.

A Third Party (Studio/Publisher) Wants to Buy or Further Develop the Prototype

Suppose your jam game attracts attention; an indie publisher or larger studio thinks the prototype is great and wants to license it or take over the team. From a legal perspective, this third party will primarily want to ensure that the rights have been cleared:

IP Check: The interested party will ask: Who actually worked on this, and does anyone have rights who is not sitting at the table? This is where it pays off if the team already has clear internal relationships. If one person is missing (e.g., you have the graphics of someone who is no longer involved and no agreement with them), the publisher gets nervous because this person could make claims later. In the worst case, the deal falls through because the risk is too high for the interested party. Therefore: be transparent with third parties about who the author is and ideally have already collected assignments/licenses from all parties involved before entering into negotiations. For more details, see our article on chain of title in game development.
Contract Takeover / Asset Purchase: Frequent models include a studio buying the assets and rights, for example. All authors must agree to this or have transferred their rights to the seller. Alternatively, the authors become direct contractual partners: a contract is concluded in which all authors grant the studio the rights of use (as exclusively and completely as possible), often in return for a lump sum and/or revenue share. Without such a contract, the third party would otherwise be unable to act because it could not publish the game without risk.
Hiring Employees: Sometimes the solution is that the publisher simply hires or contracts the entire team. The team members then transfer their rights in the process. There are even special rules in employment law for software: if someone is hired and then continues to develop the game (as part of the job), the exploitation rights are transferred to the employer (Section 69b UrhG for computer programs, and more generally under Section 43 UrhG by way of contract). This means that if the team is transferred to a studio, the IP is often formally transferred automatically or via clauses in the employment contract. However, it is important to note that the existing prototype was created before this employment; the employer wants to be sure that all rights to it have already been transferred. Therefore, the publisher will usually require that the contract states: "The developers assure us that they own all rights to previous versions and also transfer these to us."

Conclusion on Commercialization: Whether internally in the team or with external partners, clear agreements and chains of rights are crucial for a jam game to become a marketable product. Without clarification, there is a risk of legal stumbling blocks: an alienated former colleague can, for example, stop a release by means of an injunction if they can credibly claim that their copyrights have been infringed. This risk deters financiers and publishers. It is therefore worth setting the right course in good time.

The Role of Conditions of Participation and General Terms and Conditions of the Organizers

Many conflicts can be defused or avoided if the general conditions of a game jam are clearly regulated. This is where the organizer's conditions of participation come into play, the "general terms and conditions" of a game jam, so to speak. What can and should such rules cover, and where are their limits?

Copyrights Remain with the Participants: Reputable game jam organizers usually make it clear that all intellectual property rights remain with the teams/participants. This means that the organizer itself does not claim ownership of your prototype. There is often a sentence in the conditions of participation such as "The participants retain all copyrights to their submitted games." This creates trust and also meets the expectations of the community. If an organizer wants to handle this differently (e.g., for special competitions with a commercial background), they would have to state this clearly, and it would be an unusual clause in legal terms that would probably deter many people.
Licensing for Jam Presentation: In most cases, the participants grant the organizer a limited permission of use, e.g., to host the prototypes on the jam website, show screenshots, or demonstrate winning games at events. This is practically necessary so that the jam can showcase its results. A typical clause could read: "The participants allow the organizer to use the submitted game free of charge for the purpose of reporting, public relations, and documentation of the game jam (e.g., screenshot publication, download on the jam website)." This license is usually non-exclusive and limited (the organizer is not allowed to earn money with it on his own authority but only to advertise in relation to the jam).
Open Source/Creative Commons Requirements: Some game jams, especially those with scientific or collaborative aspirations, stipulate that the results must be published under a specific open license. For example, for a long time, the Global Game Jam demanded that uploaded games be placed under Creative Commons BY-NC-SA (Attribution, non-commercial, share alike). This means anyone can download the prototype, share it, and use it for non-commercial purposes as long as the author is named and any modifications are made under the same license. Please note: As a participant, you must be aware of such specifications, as they influence the possibilities for exploitation. In the CC-NC-SA example, this means that the prototype can be used by others for non-commercial purposes, but the authors retain the right to develop commercial versions themselves. Nevertheless, the game is in fact widely available (albeit without commercial use), which could make subsequent exclusive deals more difficult because an early version is virtually free to circulate (even if only non-profit). Other jams also allow open-source licenses (MIT, Apache, etc.). For participants: Check whether you agree with such a license. If you certainly plan to continue commercially, an overly restrictive open license can be a hindrance. Conversely, an open license can reduce conflicts among team members because it is clear from the outset that everyone can use the result (just under the license conditions).
Obligations of Participants with Regard to Third-Party Content: Many jam T&Cs also state that only own or licensed content may be used (no stolen assets, no copyright-infringing materials). This protects everyone involved: the team does not run the risk of being warned for using unauthorized music, for example, and the organizer is not liable for such infringements. In practice, this means: If you use third-party resources in the jam (e.g., a freely available asset), make sure that the license allows it and keep proof of this.
Appropriateness Under General Terms and Conditions Law: From a legal point of view, the terms and conditions of participation in a jam are general terms and conditions that must be effectively included for consumers (Sections 305 ff. BGB) and may not contain any unfair clauses (Section 307 BGB). For example, a clause that transfers all exploitation rights to the game to the organizer would probably be surprising and unreasonable, and would have a good chance of being invalid. However, such extreme cases are uncommon in the community. In most cases, it is more about protecting the organizer (disclaimer, rules of conduct, etc.) and the aforementioned licenses.
No Contract Between Participants Through GTC: It's important to understand that the conditions of participation primarily regulate the relationship between the organizer and participants. They do not create direct contracts between the team members themselves. So questions such as "who owns the prototype in the team" are not automatically resolved by jam T&Cs. If, for example, the jam T&Cs say "all rights remain with the authors," this only confirms the principle but does not change the internal distribution among several authors. The team must therefore make its own arrangements; the organizer does not normally interfere in the internal distribution of rights (except by choosing an open overall license, which is also more effective vis-à-vis third parties).

Practical Example of Jam Terms and Conditions: A jam participation condition could read as follows: "All rights to the developed game remain with the participants. The participants assure that their contributions are independent and free of third-party rights. By submitting the game, the participants grant the organizer a simple right of use to make the game publicly accessible and reproduce it as part of the reporting on the Game Jam. Otherwise, commercial use by the organizer is excluded." As a participant, you know that the IP belongs to you, the jam is only allowed to show it, and you have to be careful not to use any protected third-party content.

Freedom of Contract: Own Agreements Take Precedence

A fundamental principle that stands above all of this is freedom of contract. The participants in a game jam team can (and should) set their own rules, provided they do not expressly violate mandatory law. Copyright law provides the default framework in the event that nothing has been agreed, but you can regulate almost everything differently:

Simple Contract Between Team Members: The team members could reach an agreement at the jam (or ideally beforehand). This does not have to be a page-long contract in legalese; a short written agreement or email can also suffice. What is important is the common will to regulate certain points. For example: "We agree that each of us may later develop and use the resulting game on our own without having to ask the others." That would be a far-reaching mutual license. Or vice versa: "We stipulate that we will only use the game commercially together and make decisions unanimously." This confirms the legal co-copyright situation. As long as everyone agrees, such an agreement is valid.
Freedom of Form – But Written Form Recommended: Such contracts can be concluded verbally, but for reasons of proof, there should always be something in writing. A short, jointly signed document or even chats in which an agreement is clearly formulated are worth a lot. In case of doubt, courts will resort to contract interpretation in the event of unclear agreements: What did the parties recognizably want? Were there indications of a specific agreement? Behavior or statements during the jam can also be relevant here (e.g., "Let's make it all open source!" - if everyone agreed to this, it could be a license agreement).
Limits: Non-transferable Rights: Some aspects cannot be negotiated away. Moral rights (right to be named, protection against distortion, etc.) always remain with the author. For example, you cannot effectively agree: "X waives the right to ever be named as the author." X could still change his mind later, even if he initially waived the right to be named. However, X can of course declare in practice that he wishes to remain anonymous; this need not be binding forever.
Fairness and Subsequent Interpretation: In the event of inconsistent or incomplete agreements, general contract interpretation rules are applied (Sections 133, 157 BGB). This is followed by an examination of what the parties intended and what is customary. If all parties had little legal background, a reasonable interpretation for all parties will be sought. In case of doubt, no assignment of all rights if this was not clearly stated, because such a thing is not self-evident. Example: If someone claims that everyone else "verbally gave him all rights at the jam," he will need very clear evidence of this. Mere shouts of enthusiasm such as "You do it, I don't need it anyway" can easily be interpreted differently. Again, it helps to clarify this in writing when making such far-reaching agreements.
AGB Among Each Other? If one person imposes their own conditions on the team (e.g., "I will participate, but only if we agree in writing that I may use the IP later"), one could philosophize about whether the law on general terms and conditions applies within the team. In practice, this rarely plays a role because the teams are small and negotiations take place on an equal footing; everyone can have their say or leave if necessary. T&C law is intended to protect against one-sided dictation, which is more typical for professional clients in relation to individual developers. In our cases, these are mostly individual agreements.

To summarize: Whatever the law stipulates as the standard, consensual agreements between the parties involved have priority. Many experts, therefore, advise reaching at least a minimum agreement as soon as it is clear that the project has potential. This saves headaches later on, because nothing is more annoying than having to haggle retrospectively over permission or shares.

Proven Contract Types and Models in Practice

In games and software development, a number of contract models have emerged to cover precisely such situations. Below are some relevant contract types that can be used in open collaborations:

Rights of Use Agreement / License Agreement in the Team

This is a simple agreement that all team members grant each other usage rights to their contributions. In essence: "You may use my parts, I may use yours, for all purposes on the project." This allows everyone to work with the entire work without constantly asking for permission. You can specify whether this should be exclusive (only team members may use it) or non-exclusive (everyone may license their contributions outside the project). Exclusivity for the team usually makes sense for further development, so that no outsider suddenly uses the same assets.

Such a contract should also regulate for how long and to what extent the license applies. Ideally: unlimited and worldwide right of use, including all known types of use (reproduction, distribution, exhibition, editing, etc.). In this way, provision is made for every form of game release (digital, possibly physical as a Collector's Edition, ports, merchandising from graphics, etc.).

Formation of a GbR (Partnership Under Civil Law)

An informal development team that intends to earn money together is automatically considered a GbR under German law under certain circumstances. Namely, when they join together to pursue a common purpose (here: development and marketing of the game). The GbR is created informally through the will to reach an agreement. Advantage: A GbR can be the owner of rights. It is often stipulated (in writing) in a GbR contract that everything created within the framework of the GbR is the joint property of the GbR. There is then no need for countless individual transfers among each other; the joint venture holds the rights. The partners (team members) then have shares in the GbR and ultimately in its success.

However, a GbR is also liable with the private assets of the partners and is not as formalized as a corporation. It's okay for the transition, but in the long term, many people switch to a UG/GmbH.

Formation of a Corporation (UG, GmbH)

This is the professional step: the team members found a start-up as a legal entity. When the company is founded or by subsequent contract, everyone transfers their existing rights to the prototype to the company. From then on, the company can act as the rights holder. The advantages are clear relationships and limited liability. Internally, a partnership agreement regulates who is involved and how, and who contributes what. In most cases, everyone contributes their "intellectual property" (in this case, the prototype and subsequent rights), often in return for the granting of shares. This requires some effort (notary in the case of a GmbH), but it creates trust for external partners: They then only negotiate with the company, not with each individual developer.

Order or Employment Contracts for Contributions

Sometimes external help is brought into the team (e.g., a composer for the soundtrack) or a team member works more or less as a service provider without wanting to be involved in the subsequent project. In this case, a clear contract for work or service contract is recommended. This contract should state that the person will make a contribution for XYZ remuneration and transfer the necessary rights of use to the team/company. A standard clause would be: The contractor grants the client exclusive, transferable rights of use to their contribution, unlimited in terms of time, space, and content. This effectively buys the IP. Such contracts are familiar, for example, from contract programming or when a freelancer contributes artwork.

Important: Without such a contract, a freelancer otherwise retains the rights to their contribution, and the team only has a (tacit) simple right of use within the scope of the contract's purpose. This can cause problems later if you want to do more with it than originally agreed. Therefore, always put it in writing.

Confidentiality Agreement (NDA)

Rare in open jams, but common in a more professional environment: if you show your idea or prototype to third parties or work on it with new people, a non-disclosure agreement (NDA) can be useful. Although it does not directly protect copyrights, it prevents knowledge from flowing out and someone else from anticipating the idea. In the case of game jams, where everyone publishes at the same time, this is usually not relevant. However, if work continues after the jam and external parties are brought on board (consultants, potential publishers at an early stage), they should sign an NDA to protect the team. Otherwise, it could happen that a publisher rejects the idea and then develops a similar game themselves (which would be idea theft but difficult to prove without an NDA).

Open Source Licensing

A proven approach to avoid conflicts is to deliberately make the prototype open source. If everyone agrees to place the source code under an OSS license (e.g., MIT, GPL, Apache), then it is clear from the outset that everyone can use the code, not just within the team, but worldwide. This takes the wind out of the sails of internal disputes (everyone has the same rights as users of the OSS anyway) and encourages community contributions. However, it must be clear: then someone outside can also work with the code, possibly be faster or make a competing product (especially with very permissive licenses like MIT). There are also free licenses for assets (graphics, sounds) (e.g., CC-BY). Some teams choose this route if they see the project as a common good rather than a commercial product. Or as a compromise: code open source, but perhaps withhold certain prominent assets.

An open-source strategy can also create trust among each other: if one person drops out, another can still continue with the code because it is permitted under licensing law (as long as they comply with the license conditions, e.g., leave attribution and redistribution open with GPL etc.). Please note: All co-authors must agree before you can make a joint work open source, otherwise you yourself are infringing the co-copyrights of the others.

Interim Conclusion: There is no one right contractual solution. Depending on the objectives of the parties involved, there are various options, from a loose "gentlemen's agreement" to a company-founding transfer. The important thing is to have a solution in the first place. All too often, in the euphoria, people forget to make clear agreements on rights, which is much more time-consuming to make up for later.

Practical Recommendations for Action

Finally, we summarize specific tips tailored to the various players: individual developers, teams/studios, and game jam organizers. These recommendations are intended to help minimize the potential for conflict and provide security for all sides.

For Individual Developers and Creative Minds

Inform Yourself About the Rules of the Jam: Read the conditions of participation carefully. Make sure that you understand which license conditions apply and whether you agree to them (e.g., if the prototype has to be open-source). Only then can you make a conscious decision about what you disclose at the jam.
Clarify Expectations in the Team Early On: When forming the jam team, talk about what you plan to do with the project after the jam. Is it just for fun or are there ambitions to continue? A brief conversation can prevent misunderstandings. If someone says "I might want to use this commercially later," this should be openly discussed.
Document Your Contribution: Even if it may seem pedantic, make sure that your contribution is recognizable. Use your own accounts for commits, keep original files, and, if necessary, keep a private record of what you have contributed (e.g., in your portfolio or blog afterwards: "I designed levels 1-3 of game X and programmed the main character"). This creates clarity about your authorship.
Respect the Contributions of Others: Don't just assume that you can go it alone with the project after the jam. The others have rights to their parts. Treat this with the same respect with which you want your rights to be treated. Get approval before you publish or change something on your own that is not yours alone.
If Necessary, Secure Usage Rights in Writing: If you plan to use the prototype for your own purposes in any case, talk openly with your colleagues and try to get written permission. This can also be a simple letter: "I hereby agree that [Name of Colleague] may continue to use the jointly created prototype independently and exploit it commercially." Signature/name underneath, done. It may sound unusual between friends, but in retrospect, you will be glad to have clarity.
Protect Your Idea Outside the Team: Be careful who you show your prototype or brilliant idea to outside the team before you have any protection. While many things are open in the jam community, if you really think the concept is revolutionary and you want to patent it (game ideas are not patentable) or build on it, don't share details lightly without an NDA. There should be transparency within the team, but outside the team: disclose as much as necessary, as little as possible, until you are secure.

For Studios, Start-ups, and Founders

IP Check When Recruiting: If you want to take over a promising jam team or license their prototype, check the IP situation. Ask all parties involved to confirm in writing that they are the authors and that there are no third-party claims. Clarify whether there are any open source components that need to be observed (keyword: copyleft licenses).
Get Everyone on Board: It is wise to get all creators on board, whether through employment, participation, or at least clear contracts. The worst mistake would be to think, "Person X has offered us this; the others will keep quiet." Especially when success is foreseeable, authors who have been quiet so far will certainly come forward, which is their right. So: close the rights chain completely. Everyone who has contributed creatively must either be part of the company or have transferred their rights before large investments are made. Our article on chain of title in game development provides further guidance.
Clear Founder Agreement: If you were part of the jam team and are now founding a company, sign a legally binding founder agreement between yourselves. In it: Who will make what advance contributions (prototype, ideas), how will future shares or profits be distributed, what happens if a founder leaves, and what happens to their shares/rights, etc.? Start-ups, in particular, often fail due to a lack of clarity among the founders; avoid this with upfront rules.
Use of Existing Model Contracts: Use available templates for developer contracts. Many IT lawyers or start-up initiatives have templates for IP assignments, license agreements, or NDAs. For example, an IP assignment agreement can be useful, which everyone signs, in which all rights to the resulting software are transferred to the company. This is standard in many tech start-ups.
Caution with Employee Jams: If a member of your team (already an employee) takes part in an external jam, check your employment contracts. These usually regulate whether the employer has any claims to "secondary inventions" or projects. Section 69b UrhG must be observed for software: Software that is created within the scope of the employment relationship belongs to the employer in terms of usage rights. However, if the jam was created in your free time without any connection to the employer, the employer should have no automatic rights, unless the contract states otherwise. Tip: Clarify internally whether employees are allowed to take part in jams and how any resulting IP is handled. Sometimes companies encourage internal game jams, but it should then be clear that everything either belongs to the company (if desired) or is released. Lack of clarity here can later be problematic for the company itself if the employee exploits the jam project separately.
Careful Due Diligence: If you want to buy a prototype, do a little due diligence: ask to see the Git repository history, for example, see if there are clear author comments in the files, ask who exactly did what. Identify potential "IP gaps" (e.g., "a friend gave us the sound, but he wasn't officially on the team"). You would then have to get permission from this friend. It's better to ask now than to find out later in a legal dispute.

For Providers and Organizers of Game Jams

Clear and Fair Conditions of Participation: Make sure that your terms and conditions clearly state what happens to the game ideas and prototypes. Recommendation: explicitly state that all rights remain with the participants. This creates trust and also protects you from being drawn into co-authorship conflicts. Define which rights you need as the organizer (presentation, publication on the jam website, etc.) and waive any further claims.
Transparency About Licensing: If you want the results to be shareable (open source, Creative Commons), communicate this clearly in advance. If possible, use common license models (e.g., "The games are under CC-BY-NC by default," etc.) and briefly explain what this means. Some participants are legal laypersons; help them by explaining the consequences. And very importantly, have them actively accept these terms (e.g., when registering or submitting the game).
Encourage Team Agreements: As the organizer, you could proactively point out that the teams would do well to clarify their collaboration. Perhaps in advance or in an info sheet: "Tip: Think as a team about what will happen after the jam. If you want to use your game commercially, talk about it openly. For example, you can make agreements to avoid conflicts later on." Such tips raise participants' awareness of the topic without you as the organizer having to intervene.
Protection Against Liability: Include a clause in the terms and conditions stating that participants guarantee to only use materials to which they hold the rights and that they will indemnify the organizer against third-party claims if someone does infringe rights. This will protect you if, for example, someone puts copyrighted music in their game and the rights holder wants to sue the organizer for the presentation on the jam website.
No Appropriation of Ideas: Avoid giving the impression that you could "steal" ideas from participants. Any juries or coaches should maintain confidentiality when it comes to non-public project information. Professional organizers, e.g., in cooperation with companies, must be particularly sensitive here so that the trust of the developer community is not squandered. A negative example would be if, after a jam, the organizing company suddenly developed a similar game without involving the original teams. For further reading, consider our article on protecting business ideas and concepts.
Support After the Jam: As an organizer, you can also offer platforms for further work. Some game jams have follow-up programs or mentoring for teams that want to continue. Here you can provide support, perhaps even standard documents (e.g., templates for simple team agreements), if it is in your interest to see the projects mature. Of course, this is not a must, but today it is in the direction of community management.

Conclusion

Game jams and open development formats are fantastic breeding grounds for creativity and innovation. However, precisely because everything is informal and friendly at the beginning, legal decisions are often overlooked. The question "Who owns the prototype?" is by no means trivial: without agreements, the rights generally belong to the creators, often jointly. This can put the brakes on progress or lead to conflicts when the parties go their separate ways.

The legal situation under German (and essentially also European) copyright law provides a framework that requires cooperation as soon as several authors are involved. Co-authorship (Section 8 UrhG) means joint ownership of the creative work. While pleasing in the sense of a jointly created product, it can be challenging in terms of subsequent decisions. Our core recommendation is therefore: Create clear conditions!

For developers, this means thinking about it early on and, if necessary, actively addressing unpleasant legal issues. For teams/startups that emerge from jams, professionalism in terms of IP is essential; it pays off at the latest when the first contract with a publisher is signed. And for organizers, it is in their interest to design the framework in such a way that creativity is encouraged without unnecessary pitfalls.

With the right level of precaution, be it simple written agreements, far-sighted licensing, or a well-formulated cooperation agreement, the creative energy from game jams can be seamlessly transferred into successful projects. This allows everyone involved to participate fairly, ensuring that today's small prototype may become tomorrow's indie hit without yesterday's fun becoming tomorrow's dispute.