Modern game development is faster and more efficient than ever, largely thanks to the wide availability of third-party software and engines. However, these tools often come with their own licensing terms, fees and obligations. For this reason, most video game publishing agreements include a third-party software clause to clearly regulate their use.
What is the third-party software clause?
The third-party software clause sets out the rules for using external software components in the development of a video game. In many agreements, it prohibits developers from including third-party software unless they first obtain written approval from the publisher.
This clause can also define who is responsible for paying license fees, managing updates, or ensuring ongoing compliance with third-party license terms.
What is the importance of the third-party software clause?
From a publisher’s perspective, this clause ensures transparency around licensing risks and potential costs. Without it, several issues may arise:
- Unexpected fees: If the game relies on paid third-party software, the publisher might not be able to release it without first obtaining the required license. Some of these licenses can be very expensive, leading to unplanned expenses late in production.
- License restrictions: Some software licenses limit how a game can be published or monetised. A well-known example is open-source software distributed under the GPL license. The GPL requires that any product made using the licensed software must also be distributed under the GPL, including an obligation to make the source code public. This conflicts directly with most commercial publishing goals.
For developers, the clause is equally important. It not only ensures that they have permission to use the third-party software, but also that the publisher will comply with the applicable license conditions once the game is released. Without such clarity, a developer could unintentionally breach a third-party license due to the publisher’s actions.
Example of the third-party software clause in a video game publishing agreement
Below is an example of a third-party software clause in a video game publishing agreement which we have seen in practice, so that you can recognize a similar clause in your own draft:
“Developer is not allowed to include Third Party Software in the Game, except in cases where Publisher has provided prior approval. The Developer will provide the applicable license conditions and fees when requesting approval”
Most common engines in practice
Game engines are often the most impactful “third-party software” in a project. The most common ones engines are Unreal Engine and Unity. Alternatively, Godot is an upcoming open source video game engine. Looking at each of them helps you align license approvals, costs, and support expectations with your publishing agreement.
Considerations when using Unity Engine
Despite recent controversies regarding potential changes to Unity’s terms of use, the engine remains relatively straightforward from a legal perspective. Like most engines it has its own license terms and conditions, but it typically doesn’t introduce special complications for publishing contracts.
The key is to ensure that the Unity license you use covers the game’s intended scope—commercial distribution, target platforms, and number of users—and that both developer and publisher are aligned on who pays for the relevant subscription tier or fees.
Royalties and net revenue when using Unreal Engine
Unreal Engine is widely used for commercial titles and is licensed under a revenue-based royalty system. This means that the license fee is linked to the game’s revenue—a detail that can directly affect the financial terms of your publishing agreement.
In most video game publishing agreements, the publisher recoups their investment from Net Revenue, with only out-of-pocket costs (like marketing and distribution fees) deducted before splitting profits. However, engine royalties, such as Unreal’s 5% royalty, are often paid by the developer rather than the publisher.
In such cases, it’s important to agree that the engine license fees can also be deducted from the revenue before calculating the revenue split. Otherwise, the developer may end up covering the cost out of their own royalty share.
This detail becomes even more important when the publisher is still recouping their investment. If these engine costs are not deducted upfront, it may take much longer for the developer to receive any royalties at all.
Stuck on legal fine print?
Let us decode it for you.
Considerations when using Godot Engine
The Godot Engine is an increasingly popular open-source alternative. From a legal perspective, open-source software is software distributed under one of the standard (open source) license conditions. If these standard license conditions are used, it is immediately clear what the terms and conditions are.
The Godot Engine is distributed under the permissive MT-license, which means that the license conditions are straightforward. It primarly includes:
- A limitation of liability; and
- A requirement to properly include the Godot Engine in the credits of the video game.
There are no further restrictions on commercial use or distribution, making it one the most developer-friendly engines available.
However, there are still a few points to consider when using Godot in a commercial context.
Make sure open-source software use is allowed
Some commercial contracts limit or prohibit the use of open-source software. While many only restrict “copyleft” licenses (like GPL), which require the source code to be made public, others may ban open-source software entirely.
Here’s an example of a restrictive clause:
“Developer represents and warrants that no Open Source Software is or will be incorporated into the Game. For the purposes of this Agreement, “Open Source Software” means any software that is distributed under a license that requires the Developer to (publicly) disclose or make (publicly) available the source code of the software or any derivative works thereof”
This clause would actually allow for the use of the Godot Engine, as the MIT-license does not require the developer to make the source code available.
Discussing the usage of Godot in advance with a publisher is important nonetheless, because some publishers may have limited experience with the engine.
Be mindful of bug fixing and technical support obligations
The security and support of open-source software depends largely on the participation of the community. This is no different for the Godot engine, which is a non-commercial initiative. This also means that there is a possibility that SDKs will be abandoned or that there is no (commercial) party who you can approach to solve your problem in case technical problems arise with your game build.
While this isn’t necessarily a downside, developers should take it into account when negotiating bug-fixing or technical support obligations in their publishing agreement. If something breaks due to an external dependency, the developer, not the community, is still responsible for fixing it under the terms of the contract.
Before you sign: summary and next steps
Third-party software can speed up development, but it also introduces legal and financial risks. A clear clause ensures everyone knows which tools are used, who pays for them, and how licenses affect publication and royalties.
When reviewing your contract:
- Confirm that your current tools and engines are explicitly permitted;
- Check whether license fees (like Unreal royalties) are deducted from revenue before splits;
- Ensure open-source tools such as Godot are allowed and properly credited;
- Clarify who is responsible for maintaining compliance with license terms.
If you’re unsure whether your draft publishing agreement handles these points correctly, it’s worth having a legal professional review it before signing.
Next we’ll explore Marketing Obligations of the Publisher, a clause that defines what promotional efforts you can expect for your game once it’s ready to reach players.