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 technologies, libraries and tools.

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.

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:

  • A restrictive licence or 'copyleft' would require that derivatives are licensed on the same terms as the OSS. A restrictive licence generally requires that the modified or derivative code be disclosed and distributed for the public. What is considered a 'derivative' will be subject to how an OSS is linked or combined with the game's code. What is certain is that if this involves static linking, i.e where OSS and code are permanently combined to make up the executable, the entire code base would be considered a derivative. In such a case, studio would need to distribute and disclose its entire code base under the same restrictive licence which can be a concern where considerable work has been put into proprietary software.
  • A permissive licence is slightly less prescriptive as to how derivatives are distributed. However, such licences often provide certain obligations to attribute and credit the original copyright owners (which can be achieved by way of a notice in the EULA, for example), or to take certain steps to redistribute the OSS with the original licence.

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.

"Checking, checking, checking" – Kadi 55-30, Destiny 2's loot hoarding Postmaster

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.