Contracts with co-development studios: IP splitting, rights allocation and risk allocation

International collaboration in software and game development offers great opportunities – from shared expertise to faster product creation. However, co-development projects also come with considerable legal challenges. Particularly in contracts with co-development studios, issues of intellectual property (IP), the allocation of usage rights and liability must be clearly regulated. This article highlights the most important aspects – from IP splitting and rights allocation to risk allocation and the treatment of shared assets and technical resources – from a German perspective. It shows practical contractual clauses and strategies to prevent disputes and contractually secure the position of both sides. The following explanations are aimed at software developers (SaaS, enterprise software) as well as computer game development companies and underline the author’s expertise as a contract lawyer in this field.

IP splitting in co-development: division of intellectual property

When two or more companies jointly develop software or a game, the question immediately arises as to who owns the copyrights and IP to the joint results. In the absence of a clear agreement, the Copyright Act (UrhG) applies in Germany: If several people have jointly created a work and the contributions cannot be exploited separately, they are considered co-authors (Section 8 (1) UrhG). This means that they are jointly entitled to the copyright and fundamental decisions – such as publication, exploitation or changes – can only be made by mutual agreement. In practice, this statutory co-authorship can lead to a blockade situation if no prior agreement exists.

In many co-development scenarios, however, it is possible to separate the contributions of the parties. For example, one studio could develop the game engine while the other creates the graphic assets. If the contributions are objectively separable and can be used independently, there is no inseparable joint work – each party remains the author of its part (cf. delimitation in Section 9 UrhG for associated works). However, even in this case, a contractual arrangement is essential: even if each partner owns their own sub-project, each partner requires rights of use to the results of the other in order to be able to use or market the overall product. Without a contractual agreement, there is a risk of loopholes – for example, that the overall work may not be exploited without all permissions.

Sensible IP splitting by contract: The contract should therefore explicitly specify how the intellectual property is to be split. Some common approaches:

• Division according to contributions: Each party retains the copyright to the parts it has created (code modules, graphics, designs, etc.), but grants the other party extensive rights to use them so that the end product can be used and marketed as intended.
• Total transfer of rights to a partner: Co-development agreements often stipulate that one partner (e.g. the client or publisher) receives all exclusive rights of use to the entire software or game. In return, the other party receives remuneration and possibly limited rights (e.g. for the internal reuse of libraries or as a reference project). This approach avoids disputes over joint copyrights, as one party is clearly designated as the rights holder.
• Joint ownership with regulations: If joint IP is to be deliberately created (e.g. in the case of equal partners in a genuine cooperation), the contract must regulate exactly how this joint ownership works. For example, a joint IP clause is conceivable which stipulates that both parties are considered co-authors, but that each partner is entitled to use and sublicense without blocking the other – typically coupled with profit sharing or other compensation mechanisms. Without such a special rule, German law would require both parties to jointly authorize any exploitation, which is unwieldy in practice.

It is crucial to proactively determine who receives which rights to which component. Ideally, IP splitting begins in the planning phase: the parties should identify which components of the project represent core IP and for whom they are strategically important. This will determine whether a clear allocation (e.g. one party receives all rights to the finished product, the other perhaps a right to use the technology) or a split model should be chosen. For practical reasons, a clear allocation is often preferred in order to avoid complex disputes later on.

Assignment of rights: rights of use, licenses and (no) joint ownership

The assignment of rights in the co-development contract determines who may use the result and how. It should be noted that under German copyright law , copyrights as such are inalienable – the author (creator) always remains the natural person or, in the case of software, the programmer. However, companies can acquire comprehensive rights of use (Section 31 UrhG). In the employment relationship, this is simplified: if an employee develops a computer program in the performance of his duties, the exploitation rights to the software are transferred to the employer by law (cf. Section 69b UrhG). In the case of external service providers or co-development partners, however, the rights must be transferred by contract. Without an express agreement, a client only receives the rights that are absolutely necessary for the purpose of the contract – often only a simple right of use – in accordance with the statutory principle of transfer of purpose (Section 31 (5) UrhG). In practice, this means that whatever is not expressly granted remains with the creator.

Clear usage rights clauses: A co-development contract should therefore contain a comprehensive provision on the transfer of rights. Typically, it is agreed that each developer transfers all exclusive rights of use to their contributions to the client or the joint project, unlimited in terms of time, space and content. This ensures that there are no loopholes at the end (such as a lack of rights to publication, reproduction, modification or marketing via certain distribution channels). If a complete transfer is not desired, licensing can also be agreed – e.g. each partner grants the other an exclusive right to use its components for the joint product. It is important to determine whether sublicensing is permitted: If a partner must be allowed to sublicense the end product to third parties (e.g. customers or publishers), the right to sublicense must be expressly granted. Otherwise, a licensee may not pass on any further rights of use to third parties without the consent of the original rights holder. A properly formulated license chain prevents one of the partners from ultimately being able to block marketing because it does not have permission to sublicense rights.

Joint ownership – when does it (not) make sense? Many legal experts advise against leaving unresolved joint authorship of the final product. Joint ownership (co-authorship without a clear regulation) carries the risk of stagnation, as – under German law – no one can exclusively exploit the work without the other. In some other countries (e.g. USA), co-authors are sometimes allowed to grant licenses independently; international teams should be aware of such differences and standardize them in the contract. Joint ownership can make sense if both parties want to exploit the result independently, for example in different markets or areas of application. In this case, however, the contract should precisely define who has which exploitation rights, how revenues are to be divided and how new ideas or further developments are to be handled. Instead of true shared ownership, it is often better to agree on exclusive rights allocations (e.g. partner A may use the product in area X, partner B in area Y) in order to avoid overlaps.

It should also be noted that authors in Germany retain personal copyrights (e.g. right to be named, protection against distortion). Although the exercise of these rights can be restricted by contract, they cannot be completely revoked. In practice, this can be handled, for example, by developers waiving attribution and agreeing to consent to the necessary editing of the code. This minimizes potential conflicts under moral rights law.

Practical tip: The assignment of rights should be made in a combination of license and transfer clauses that also include future developments. For example: “The developer transfers all currently known and future property rights to the work results created within the scope of the project to the client. The client is entitled to grant these rights to third parties or to transfer them to third parties….” Such formulations ensure that new types of exploitation or sublicenses are also covered.

Risk allocation: liability, warranty and performance risks

In addition to IP allocation, risk allocation is a central element of co-development agreements. The question here is: who bears which risks, for example for delays, errors or performance problems in the development process? Without clear agreements, there is a risk of mutual apportionment of blame or considerable financial losses for one partner in the event of an error. The following points should therefore be covered contractually:

• Schedules and delays: Co-development projects often have tightly timed milestones. The contract should set realistic deadlines for deliverables and specify what happens in the event of delays. Contractual penalties or bonus/penalty regulations are common – e.g. a flat-rate contractual penalty if a milestone is not reached without good reason, or bonus payments for early completion. Alternatively, it can be agreed that a right of withdrawal or the involvement of additional developers at the expense of the delaying partner is possible in the event of certain delays. It is also important to allow for buffer times and to coordinate dependent services (if partner A is dependent on input from partner B, this must be reflected in the schedule).
• Quality requirements and warranty: The contract should contain clear quality criteria for the developed components. For software in particular, it makes sense to define acceptance criteria (see next section on deliverables and acceptance). Each party should provide certain warranties – e.g. that their code is free from material defects in terms of agreed specifications and that the work delivered meets industry standards. The assurance that no third-party rights are infringed (see IP warranty below) is also included here. If a defect is discovered after acceptance, it must be stipulated whether the performing partner is obliged to rectify the defect and within what period of time. A free rectification period for certain defect classes is typical.
• Allocation and limitation of liability: Despite all preventative measures, damage can occur – such as damage caused by delays, loss of profit or costs due to errors. Co-development contracts should specify the extent to which one partner is liable to the other. In B2B relationships, it is common to contractually limit liability: For example, exclusion of liability for slight negligence in non-cardinal obligations, or capping the amount of liability (for example, to the order amount or a multiple thereof). Liability cannot be excluded for gross negligence and intent as well as injury to life, limb and health (statutory limit). Special provisions are also often made: for example, unlimited liability for breach of confidentiality obligations or infringement of third-party property rights, as the risk for the other party can be particularly serious here. Ultimately, the aim is to find a fair distribution: Everyone should bear responsibility for their own sphere. For example, it can be agreed that each partner is liable for the parts they supply and any resulting damage, while joint risks are shared.
• Indemnity for third-party claims (indemnification): An indemnification provision is particularly useful for IP risks. For example, if Partner A delivers code that infringes third-party copyrights, Partner A should indemnify Partner B against all resulting third-party claims and bear the defense costs. The same applies to infringements of data protection, patents or other rights by a partner. This clause ensures that the “innocent” partner does not have to bear the costs caused by the other partner’s breach of duty.
• Insurance and provision: For larger collaborations, it is advisable to check whether appropriate insurance exists (e.g. professional liability or special cyber insurance) that covers certain damages. The contract can stipulate that both parties maintain suitable insurance cover for the duration of the project.

A balanced risk allocation creates trust between the partners. It prevents individual problems from escalating: Both sides know what the consequences are in the worst-case scenario and can protect themselves accordingly. It is important that liability clauses are formulated transparently and comprehensibly – especially in an international context where different legal systems clash, the terms and limitations of liability must be understandable for all parties involved.

Legal protection for joint assets

Co-development projects often result in jointly created assets – from source code and graphics to documentation or tools. These shared assets should be contractually secured so that both parties can use them as intended and misuse is prevented. The following aspects are essential:

• Definition of background and foreground IP: The contract should distinguish between background IP (all materials already existing or independently developed by each partner prior to the project) and foreground IP (all results created as part of the joint project). This distinction prevents confusion about what was contributed vs. what was newly created. As a rule, Background IP remains the property of the respective party, but is often made available to the project via license. Foreground IP is then subject to the IP splitting rules discussed above.
• Access rights and storage: Both parties should have access to the joint work results. In practice, a central repository (such as Git) to which both parties have access is recommended so that code and assets cannot be withheld unilaterally. A contract can stipulate that all work results are to be released to each other at regular intervals. In the event of a dispute, this prevents one party from “confiscating” the assets. An escrow agreement can also be considered: If one partner becomes insolvent or drops out, a deposit (e.g. source code with an escrow agent) is transferred to the other so that the project can continue.
• Rights of use to joint results outside the project: The question often arises as to whether and to what extent each party may also use the developed assets outside the specific joint project. For example, a co-developer may want to reuse parts of the code or tools later for their own customer projects. There are several approaches here: You can agree on strict use only for the joint project – in which case the assets may not be used elsewhere except with the consent of the other party. Or you can grant each other broad rights of use: for example, each partner may also use the jointly created components in other projects as long as confidential information or trademark rights of the other party are not infringed. A middle way is to agree licenses after the end of the project – e.g. partner A may use a certain asset in their own products in return for payment of a license fee. It is important to clarify these questions in advance to avoid disputes about “Who can do what with it?”.
• Protection of joint results from third parties: The contract should oblige both parties to protect the shared assets from unauthorized access by third parties. This includes strict non-disclosure agreements (NDAs) for source code, designs, trade secrets and all sensitive information. Both parties should ensure that they only grant access to authorized employees and implement appropriate security measures. Data protection and protection of intellectual property is essential, especially in international teams that work together remotely. If external subcontractors are involved, it must be contractually ensured that they are also subject to appropriate confidentiality clauses and do not acquire any additional rights to the assets.
• Exit strategy for joint assets: Finally, you should regulate what happens to the joint results when the cooperation ends – be it after successful project completion or prematurely due to termination. An exit clause can stipulate that in the event of a separation, each party at least retains the assets it has contributed and, if applicable, receives a right to use the jointly created results so that no development comes to nothing. For example, it could be agreed that in the event of premature termination, each partner receives a simple right of use to all results created up to that point in order to continue using them internally (with the proviso that they are not sold to third parties). Such arrangements prevent the project from failing completely just because the partners part company – at least the partial results can be used or further developed.

These contractual arrangements protect joint assets both during and after the collaboration. Both sides know where they stand and the investment in the joint results is legally protected. For companies in the games industry, for example, this can mean that character models, textures or level designs are clearly assigned or licensed; for SaaS developers, that jointly programmed modules or interfaces do not remain in a gray area.

Technical ownership: Engines, tools and middleware

An often underestimated area in co-development contracts is technical ownership – i.e. the question of who owns development tools, engines or middleware that are used or created in the project. In game development in particular, partners often bring their own engines or editor tools into the project. In software development, existing frameworks or APIs are integrated. The following points should be considered:

• Existing engines and tools (background technology): If a party contributes its own engine, framework or other proprietary tools to the project, this technology generally remains the property of the contributing party. The contract should make it clear that this background IP will not be transferred. However, the other party typically requires a license to work with the engine/tool and create the end product from it. Therefore, a time-limited, project-bound license is often granted: e.g. partner B may only use partner A’s engine for the development and operation of the joint game. Important: If the other partner is also to carry out maintenance or expansion after the end of the project, the right of use must be extended or expanded accordingly. Otherwise, the right to use the engine ends at the end of the project.
• Further development of contributed technology: What happens if the contributed engine or a tool is further developed or adapted in the course of the collaboration? Without regulation, this could result in new joint IP or even copyrights of the adapting partner. To avoid conflicts, co-development agreements often stipulate that changes or improvements to the technology provided by partner A automatically belong to partner A (with possible rights of use for partner B). This means that if Partner B co-writes the engine and improves it, these improvements are transferred to Partner A – as they are part of the engine. Alternatively, you can differentiate: Bug fixes and general improvements go to the original owner, while completely new modules are treated separately. The key point is to determine in advance who owns such derivatives.
• Newly developed tools and middleware (foreground technology): If the partners develop completely new technical components in the course of the project (e.g. a level editor, a plug-in, an AI module), ownership must also be clarified for this. You can proceed in the same way as IP splitting: Either a new tool belongs to the partner who primarily developed it, with a license to the other – or, if it was created at joint expense, the client receives all rights and the developer a right of use for other projects (or vice versa, depending on negotiating power). Here it depends very much on the interests: A service provider may want to be allowed to reuse a generic tool, while the client wants to rule out the tool being passed on to the competition. A possible practical approach: the client receives exclusive rights to the actual product (e.g. the game), but the developer may reuse generic components such as editor tools or general engines, as long as they do not contain any specific assets of the client. Such clauses promote a win-win situation: the developer expands his know-how and the client does not have to start from scratch, but benefits from tried and tested technology – without having to worry about third parties copying his specific product.
• Third-party licenses and open source: Co-development projects often make use of third-party middleware or open source components. The license chain is particularly critical here: the contract should specify who is responsible for ensuring that all external components are properly licensed. Both parties must ensure that the use of such components is permitted in the joint product. A common rule is that each party guarantees to only include third-party software that it is either allowed to license itself or that is under a license that is compatible with the intended use. For example, it must be avoided that someone incorporates an open source component with a viral license (GPL), which would then place the entire product under GPL without the other partner wanting this. Therefore, release processes should be established in the contract: every integration of open source or third-party software requires the consent of both parties, and the respective license conditions must be documented. In addition, both parties should indemnify each other in the event of a breach of the license terms of a third-party product for which they are responsible (see indemnity above).

A clear regulation of technical ownership ensures that there are no nasty surprises at the end, such as a partner suddenly having to pay license fees for the use of the jointly developed engine because it was unclear who owned it. Especially in long-term SaaS co-developments (e.g. integration of two systems) and in the games industry (engine sharing), such clarifications are worth their weight in gold. Both sides retain control over their respective technological foundations and know what they can rely on once the project is complete.

Clear deliverables and acceptance mechanisms

A frequent point of contention in development collaborations is the definition of deliverables and their acceptance. Unclear expectations lead to delays, extra work and frustration. Therefore, the contract should regulate in detail what exactly has to be delivered, when and how the acceptance takes place:

• Requirements specification and specification: At the beginning of the contract or in an annex, it should be specified which modules, features, assets etc. are to be created by which party. Even in agile projects, a minimum common understanding of the objectives is necessary. The requirements specification serves as a reference framework in order to be able to assess later whether a deliverable is complete. Changes to the scope (change requests) should follow a defined procedure so that both parties know that additional services must also be remunerated separately or renegotiated in terms of deadlines.
• Milestones and partial deliveries: Larger co-development projects are ideally divided into milestones. Specific partial results are defined for each milestone (e.g. “Basic function X fully implemented”, “Graphics package Y delivered”). This makes it easier to monitor progress and allows early countermeasures to be taken in the event of delays. Each milestone can be linked to an acceptance test, the criteria for which are defined in advance.
• Acceptance process: The contract should specify how the acceptance of a deliverable takes place. It is usual to specify a period within which the receiving partner must test the deliverable and either accept it or report any defects. For example: “The client shall check within 10 working days of delivery whether the results meet the agreed requirements. If no written notification of defects is received within this period, the delivery shall be deemed to have been accepted.” It should also be stipulated that if defects are identified, the partner providing the service must rectify them within a reasonable period of time and then resubmit them for acceptance. A formally documented acceptance process (e.g. acceptance protocol) creates clarity. Important: Partial acceptances for milestones should be provided for so that components that have already been completed are confirmed as such – this prevents months of discussion about points that have already been completed.
• Acceptance criteria: It is best to agree specific criteria for when something is considered “fulfilled”. For example, key performance indicators, passing certain test cases, compatibility with certain systems or visual quality standards for graphics. If the criteria are objective and measurable, discretionary disputes are reduced. Both sides should be involved in formulating these criteria so that they are realistic and verifiable.
• Consequences of refusal of acceptance: In the event that one party justifiably refuses acceptance (due to significant defects), it should be stipulated that the other party must rectify the defects and whether there are financial consequences (e.g. postponement of payments until successful acceptance). If, despite repeated attempts at rectification, no contractual service is provided, a right of withdrawal or termination could be agreed. Conversely, unjustified refusal of acceptance – e.g. to delay payments – should be sanctioned, e.g. after two unjustified refusals, acceptance is deemed to have taken place or the supplying partner is entitled to claim damages.

Clearly defined deliverables and acceptance mechanisms create transparency in the development process. Both sides have the same expectations as to what will be delivered and when it will be considered finished. Especially in agile settings, the contract should build a bridge between flexibility and commitment – e.g. regular sprint reviews as de facto acceptance of individual functions, but still a final criterion for when the product is ready for the market. This planning protects against endless additional requirements and ensures that at the end there is an approved product that both parties are satisfied with.

Dispute resolution in international teams: jurisdiction or arbitration?

Despite the best contract design, conflicts can arise in international co-development projects. Different time zones, cultures and legal systems make it difficult to enforce claims. A clever dispute resolution clause is therefore worth its weight in gold in order to achieve an efficient solution in an emergency. Particular attention should be paid to this:

• Choice of law: First of all, the contract should specify which law is applicable(governing law). If German companies are involved, German law is often chosen, especially if many copyright issues play a role that are to be assessed according to German copyright law. Alternatively, a neutral law can be considered (such as Swiss law or the law of a third country acceptable to both parties). It is important to make a clear arrangement – otherwise, in the event of a dispute, it may be necessary to go to great lengths to clarify which law applies.
• Jurisdiction vs. arbitration tribunal: In an international context, many experienced contractual partners resort to arbitration agreements. An arbitration tribunal has the advantage that its decision can usually be enforced in many countries in accordance with the New York Convention, whereas state court judgments can only be enforced across borders with difficulty. In addition, a neutral forum can be appointed (e.g. a court of arbitration in Stockholm, Paris or Zurich), which can be convenient for both parties instead of one party having to sue in the country of the other. Arbitration proceedings are confidential – this can be important for sensitive IP disputes to avoid having to disclose business secrets in court. On the other hand, arbitration proceedings can be expensive. If both partners are from EU countries, a state court with international jurisdiction can also be chosen (e.g. the courts in Munich), as EU judgments can be enforced relatively easily within the EU. In any case, the place of jurisdiction should be clearly stated in order to avoid forum shopping.
• Draft the arbitration clause: If arbitration is chosen, the arbitration clause should state the rules and institution (e.g. ICC Court of Arbitration in Paris, Rules of Arbitration of the International Chamber of Commerce) and the number of arbitrators (often one or three). The language of the proceedings and the seat of the arbitration court must also be specified. Example: “All disputes arising out of or in connection with this contract shall be finally settled under the Rules of Arbitration of the German Institution of Arbitration (DIS) by three arbitrators. The seat of the arbitration shall be Berlin and the language of the proceedings shall be English.” This information ensures that, in the event of a dispute, there is no further disagreement about the “how and where” of dispute resolution.
• Mediation and escalation: An elegant solution can be to first try to reach an amicable settlement before going to court or arbitration proceedings. Many contracts contain escalation clauses: for example, in the event of a dispute, the parties agree to let their project managers negotiate first; if this fails, the managing directors of both companies meet for a discussion; if this does not help either, mediation proceedings are initiated; and only as a final step do they go to court or arbitration proceedings. This staged approach can preserve the business relationship because it gives the conflict a chance to be resolved at a legal level without a public dispute and without immediate confrontation. This mechanism is particularly worthwhile for long-term collaborations.
• Costs and language: In an international setting, it should also be stipulated who bears the costs of the proceedings (usually after winning/losing or as decided by the arbitration tribunal) and in which language the proceedings will be conducted. If the contract itself is bilingual, you can specify which language version is decisive in case of doubt.

A well thought-out dispute resolution clause demonstrates foresight: both sides know that there is a plan to resolve conflicts fairly and efficiently without ending up in endless legal disputes. This creates trust and can have a preventative effect – the inhibition threshold for breach of contract is higher if clear consequences are agreed. From the point of view of an experienced contract lawyer, the dispute resolution clause is a central element, especially in international contracts, which should receive just as much attention as the substantive provisions on IP and obligations.

Conclusion

Co-development contracts in the software and games sector are complex, but manageable with the right structure. Strategic contract design – from IP splitting and rights allocation to risk allocation and securing shared assets and technical resources – forms the foundation for successful collaboration. Clearly defined deliverables, acceptance processes and dispute resolution mechanisms ensure that both sides achieve their goals without getting stuck in legal uncertainties.

For companies and developers, this means Take the time at the beginning to regulate these points in detail with legal support. A well-drafted co-development agreement creates transparency, reliability and trust – everyone knows where they stand, creative potential can flow freely and there are firm guidelines in the event of problems. Particularly in the case of international cooperation with different legal cultures, professionalism is demonstrated in defusing potential areas of conflict in advance.

With the experience of a specialized lawyer, practical clauses can be formulated that minimize risks and secure the value of the joint project. This makes the partnership between software or game studios a success – legally sound and free to concentrate on the essentials: the development of a great product.