The European Court of Justice in Nintendo Co Ltd and others v PC Box Srl, Case C-355/12 considered the intellectual property protections available to video games, and came to the conclusion that video games are a hybrid product made of a complex combination of technical and artistic elements. While most are familiar with the intellectual property rights surrounding the latter element (think dance moves and tattoos), little attention is given to the vast range of software assembled together to produce the executable ‘game code’.
From engines to hair/fur or leaf-generating middleware to integrated services via APIs, each and every component is distributed with licences that are, at the very core, permissions from the software vendor as to what, how, where and when that particular piece of software is to be used. These are set out in terms that are colloquially referred to as End-User Licence Agreements/EULA (Yoo-Lahs), or T&Cs (Tees-and-Sees). Neither sounds menacing in the least, but the mere mention of them may invoke a shudder of dread in many.
In 2014, a dispute between Epic Games and now-defunct Silicon Knights resulted in a $9.2million award to Epic Games and an order to destroy all unsold copies of Silicon Knight’s games using Unreal Engine 3. Earlier this year, a public spat between game engine developer Unity and cloud development platform provider Improbable relating to a breach of Unity’s T&Cs left developers using Improbable’s instance of the Unity engine on SpatialOS hanging in uncertainty. These cases highlight the importance of reviewing those wordy licence agreements.
In this two-part series of articles, we hope to give budding video games developers some food for thought throughout their process of curating relevant technolo gies, libraries and tools, and whether you may require video game lawyers or a digital media lawyer to help you.
Why bother?
Understanding the conditions under which a software component (no matter how small) is ‘sold’ to the studio is important to ensure that the terms sit comfortably with the studio’s expected uses. By reviewing T&Cs, a studio can avoid unpleasant surprises by way of unintended breaches of the terms or being imposed additional licence fees, and can future-proof itself against having to renegotiate or reconsider the suitability of the tool in future projects.
An added benefit of systematically auditing technology used to produce the game code, is that it makes studios more attractive to funders such as investors or publishers who will conduct detailed due diligence on the IP rights incorporated into the game. An intellectual property solicitor will be happy to guide you through the process too.
Convinced? Let’s-a-go Mario
Bespoke/Proprietary Software
As much as possible, all intellectual property rights in software created for the game should be owned by, and not licensed to, the studio. By owning software, a studio would not need to consider what permissions are granted to it.
If any third party contractors are engaged to develop part of the game’s code, then it is strongly advised that the studio enter into an agreement under which all intellectual property rights to the work they have created is assigned to the studio. This is because under intellectual property laws, the contractor is automatically presumed to be the original creator and owner of copyright in the code he/she writes, unless there is something written to the contrary.
Opportunity should also be taken to seek contractual promises and compensation for losses under the agreement in respect of the quality of the work delivered, particularly against any third party intellectual property infringement.
Third Party Software
The reality is that the bulk of the game’s executable code will consist of a compilation of licensed third party software, interwoven through bits of bespoke code (as above) and OSS (see below). A studio would therefore need to be very careful with reviewing a software vendor’s terms.
We set out some things to consider in the second part of this article here.
Open-Source Software (OSS)
It is widely accepted that the use of OSS shortens development phase, allowing expensive development resources that might be spent ‘re-inventing the wheel’ for basic routine tasks, in favour of higher value custom work. However, the complexities behind the licensing structures of OSS are such that studios should be careful with the use of any OSS within its code.
There are currently hundreds of OSS licences in use, and these can very briefly be categorised in one of two distinct groups: permissive or restrictive licences. The important difference between both categories lies in how derivatives of the OSS are licensed onwards. What is considered a ‘derivative’ is still a contentious area, but this is generally understood to be any amendments, adaptations, or combinations of the OSS into the studio’s proprietary software:
Suffice it to say, the complexity of OSS are such that a studio should not be so quick to integrate these without further consideration. Furthermore, if a studio is looking for support through a publisher, it should expect that a publisher may expressly request that OSS (in particular those subject to a restrictive licence) not form part of the code used for the game, or that their consent be obtained prior to its use.
Conclusion
The ‘nitty gritty’ technicalities of video game development can be easily overlooked in favour of the front-facing creative assets that players interact with.
However, let us not forget that a good few years of development and upfront financial investment (and very many tears) are dedicated to developing the technical framework that carries the storylines, music, and digital universe that keeps many a player up all night. The consequences of breaching a licence agreement can lead to extended development cycles, blocked pipelines and incurred costs on replacing technology/code. Conducting a tech ‘health check’ prior to use of any software and every so often thereafter is crucial to mitigating those risks.
We hope that this two-part piece helps those embarking on game development to feel a little less apprehensive towards software licence agreements as well as empowered to review their licence agreements as a way to keep a software provider in check.
Although most users of your website will not read your terms, this is an important part of your business. Having to argue in court is expensive, so a little investment to avert the risk is a pragmatic approach. This article highlights some of the most common points which your terms should cover so that the risks explained below do not crystallise.
If your business involves sending personal data outside the UK and EEA, you may be aware of the need for a transfer risk assessment (TRA) to demonstrate that you have properly considered and mitigated any associated risks.
When it comes to commercial negotiations, they often don’t turn out the way you had hoped and then there is no going back. Instead of struggling on your own, losing a lot of management time and still not being sure you have got the best deal, let us negotiate for you.
Get it in writing – Commercial Contracts