In Part 1 of this two-part article, we discussed the importance for studios to conduct a review of the technologies and software used in video games development. We identified three categories of software, and summarised key issues in respect of two of these: bespoke software and OSS.

Part 2 is dedicated to third-party software, which forms the bulk of software used to build a game's technical framework (and therefore deserves its own detailed section!). Third party software tend to be distributed with a vendor's general terms and conditions, and are rarely negotiable. Having said that, there is never any harm asking for clarifications or amendments. After all, if you don't ask, you don't get.

We set out below a few things to look out for:

  • Software. It is always worth checking whether a specific version of software is being licenced and whether this would include updates, patches and all future functionalities.
  • Specified uses.  Consider carefully how the software will be used in development and ensure that the licence does not restrict the studio from its planned uses. The rights granted may be tied to the platforms of release or number of games intended to be developed. If any uses are linked to specific games/projects, studios should check if this includes development of ports, DLCs and/or sequels (if appropriate). A bit of an obvious one, but this can be easily overlooked: studios should be mindful not to continue development on an 'evaluation-only' licence!
  • Accessibility. In traditional on-premise installation circumstances, accessibility to software may be restricted to a permitted number of users or installations. However, the increasing move to the cloud and reliance on interoperable systems has resulted in terms that might provide specific definitions of 'access' and 'use' of the software. Studios will need to consider if the software licence is suitable with its existing infrastructure. For example, if a virtual environment is used in which one copy of the software is downloaded to the server and subsequently accessed by numerous members of the development team, the studio should ensure this method is not restricted by the software licence.
  • Fees. These are usually tied to the scope of the rights granted. They may range from a one-off payment or periodic subscriptions that are easier to track. Some fees may be linked to the game's expected sales performance, number of users (active or otherwise, in the case of a live game), or the studios' financial circumstances. These fluctuating licence fees should be carefully budgeted and reviewed from time to time.
  • Right to sub-licence. Software providers will usually prevent this as it is expected that the only party to use the software should be the studio purchasing/licensing it from them. However, if sub-contractors/freelancers are expected to contribute to development and use the software, it is advisable that the right to sub-licence the software is obtained. Consider whether any part of the software will be run-time. The right to sub-licence will generally be included, but this is likely to be limited to the right to distribute it along with the final game for players to download alongside the executable form of the game.
  • Warranties, Indemnities, Limitation of Liability. These provisions cover (i) what the software provider promises to the licensee; (ii) compensation for damage or loss and (iii) limitations to a software vendors' responsibilities in respect of damage or loss caused under the licence agreement and by the software. Most software will be typically licenced on an 'as-is basis' and software providers are likely to 'cap' their liability for damages or loss to a negligible monetary amount, if not the amount of the fees paid under the licence. Financial recourse for loss or damage incurred by the studio, for instance where intellectual property is infringed by the software vendor, will therefore be very limited, and studios should be conscious of this risk. Occasionally, the terms will require their licensees to provide unlimited compensation (an indemnity) for the software vendor's loss, however that loss might arise. This is not always appropriate, but in practice it is difficult to negotiate out of this where the software vendor is more established and has a better bargaining power.
  • References to other terms. Quite often, references will be made to Acceptable Use Policies, or licenses of other third party components integrated within the software, for example Open Source Software ( see Part 1 for more details). These should be read carefully as they form part of the main terms, so if they are not readily available to the studio, make sure to ask for them! Other services – With the rise of the 'as-a-service' products, it is likely that software providers offer support and maintenance services throughout the life of the development. This can be important if the software will be used to develop patches and updates for the game. In the case of a live game, attention should be paid to any service level standards, security and any data protection provisions (to the extent that a player's personal data will be collected by the game) contained in those agreements.

These are by no means exhaustive and the relevance of each point will depend on how the software is intended to be used, and if a studio intends to develop a one-off or 'live' product.

Nevertheless, we hope to have provided a framework of software licensing issues to bear in mind, which can potentially be applied to an ever-expanding list of ancillary development services such as version control software and virtualisation software.

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.