Open 3D Engine and how to use open-source software in video games

You might have already heard that there is a new 3D video games engine dedicated to the development of high-budget and high-quality (AAA) games – called Open 3D engine (O3DE). It is not exactly ‘brand-new’ – it is based on a modified version of Amazon Games’ Lumberyard engine (which, by the way, is a modified CryEngine). What is interesting about this engine, however, is that it is not only free to use, but also open-source.

It is yet another example of open-source software available to video games developers. But what does ‘open-source’ mean and what do you have to keep in mind when creating games with open-source software? In this short article, we would answer these questions, based on the O3DE example.

Open-source licence – what are the implications?

In theory, open-source software is a type of software that is distributed (by the licensor) under a licence that allows the user (licensee) to use (access), change and distribute the software and its source code. This facilitates the developers’ (programmers’) collaboration in the process of software development and saves time for programmers. As great as it sounds, it is not so straightforward in practice. Not every open-source licence provides the same level of freedom.

There are numerous licences which are considered open-source. For example, the list of licenses approved by the Open Source Initiative (i.e. meeting OSI’s Open Source Definition) includes over 100 licences (the list is available here). The most popular ones that one might come across online (e.g. on GitHub) are probably Apache, BSD, GNU and MIT licences.

All of the listed licences are considered open-source but the terms that they license software on vary, sometimes significantly. Open-source licences often contain important limitations which might make the way you want to use the software illegal. Therefore, the first lesson regarding the open-source licences is the following: always check what the licence is that the particular piece of software (source code or object code) is distributed on.

With that in mind – what licences is Open 3D Engine distributed on?

General Open 3D Engine licences – permissive open-source

When we look to the O3DE’s Github repository, in the ‘LICENSE.txt’ file we can see that the default and general licence for O3DE is the Apache 2.0 license, but the developers can also choose to use O3DE under MIT licence. All future contributions to the repository have to be made under both of these two licences. Fortunately, both Apache 2.0 and MIT licences are actually very permissible. Let us dive into the terms of both these licences.

Apache 2.0

Apache 2.0 licence gives the licensee a following set of rights:

“perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form”

(capitalised terms are defined in the licence text).

It also gives the licensee a patent licence (if there is any patent) which is very similar in scope.

Reproduction of the software and its source code (modified or not) has to meet the following requirements:

  1. every recipient must receive a copy of the licence (e.g. in a “license.txt” file attached to the program);
  2. every file you modified must carry a notice stating that you have done so;
  3. you must keep all the previous copyright or patent notices included in the files;
  4. you must further distribute the “NOTICE” text file, containing all the relevant attribution notices.

In relation to contributions, all contributions to the Apache-licensed software are also deemed Apache-licensed, unless the contributor states otherwise. In the case of O3DE, the general licence requires developers to share contributions on both Apache 2.0 AND MIT licenses, so this rule has been overridden by the general O3DE licence.

The licence also includes provisions on the use of licensor’s trademarks (in short: do not use any if you are not explicitly permitted to do it), limitations of liability and warranties, as well as the instructions on how to apply the Apache licence to the work created by licensee.

Nothing in the licence restricts the use of the source code in commercial projects. In short, what Apache licence requires is that you include in your software the information that you use the Apache-licensed software, the information that you modified it (if you did), all attribution notices and the copy of the licence text. You do not have to share the modifications or any other part of the source code publicly.


At first glance, the MIT licence is much simpler and significantly shorter than the Apache 2.0 licence. It grants free of charge the rights “to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so”. The set of rights is similar in spirit to the one in the Apache licence, but there are some differences in the wording.

Compared to Apache 2.0, the permission to use the software in the ways described above is made under one condition only: “The above copyright notice [that is: the notice stating who is the copyright holder of the software – in O3DE’s case “Copyright Contributors to the Open 3D Engine”] and this permission notice shall be included in all copies or substantial portions of the Software”.

In short: you can use and modify the source code distributed under MIT license however you like, even in commercial products, as long as your software includes the full text of the copyright notice and permission notice.

Copyleft and engine plugins – what to pay attention to

Unfortunately, not all open-source software is distributed on such permissive licences as MIT or Apache 2.0. Developers have to be aware in particular of the so-called “copyleft” licences, of which the most popular is the GNU license family. There are too many issues regarding copyleft licences to discuss in this short article, however as O3DE licence text explicitly discusses this topic and because of the risks associated with it, short description is required.

In general, copyleft licences are the licences that include the requirement that the derivative works created based on the work distributed on such licences are distributed on the same terms (same licence). In short, this means that if you use the source code licensed on a copyleft licence in the computer program, due to the rule which is sometimes called the ‘copyleft virus’, you might be required to distribute your program (the rest of the code) on the same copyleft licence, for example for free. This ‘infection’ is a huge risk for proprietary (commercial) software and it is also present to some extent in the case of Open 3D Engine.

There is a very important disclaimer in the O3DE licence text, which can be seen in full below:

Open 3D Engine requires the use of (and in some cases makes available to you) software and assets that have been developed by third parties and are subject to separate license terms (such as code licensed under other open source licenses). It is your responsibility to comply with the applicable licenses. Information on third party materials, and the applicable license terms, are referenced in or included with the materials, such as in separate LICENSE.txt files accompanying the materials.

Please note that certain materials are subject to “copyleft” licenses, which require distribution of source code, including:

– Qt Toolkit, which is subject to the GNU Lesser General Public License version 3 (with certain exceptions). A copy of the source code for Qt Toolkit may be found at

– The AWS Python SDK uses Chardet, which is subject to the GNU Lesser General Public License version 2.1. A copy of the source code may be found at

It means that although the O3DE is open-source and distributed on quite permissive licences, it may require (and does require) the use of software and assets which may be subject to separate licence terms, which often are distributed on much stricter licenses. Before you decide to use O3DE, check the repository for other licences.

General O3DE licence text provides two examples of materials (Qt Toolkit and Chardet) that are distributed on GNU LGPL licence (v. 2.1 and 3.0). Without going into too much detail, in contrast to GNU GPL, the LGPL licence allows the use of LGPL-licenced library to be used in the proprietary products, as long as your work is not a derivative work of the LGPL-licensed work. It is a matter of legal discussion whether in a particular case there would be a derivative work created, but generally it is understood that dynamic linking to the LGPL-licensed library does not create a derivative work but rather is a “work that uses the Library” (using the wording of the licence). This would probably be the case when the engine uses some outside tools and does not incorporate their source-code into the proprietary software, but important disclaimer has to be made: every case is different and the interpretation in a particular case might be different.

As you can see, using copyleft-licensed materials in proprietary works is a legal minefield. The general lesson is that you should always check what other licences are in play and whether they allow you to use software in the way you have imagined and how they might impact other parts of software you develop. Generally, when possible, it is recommended to avoid using copyleft licences in proprietary software. If you want to use copyleft software in your software, it is recommended you consult the IP lawyer and – at the very least – analyse the licence terms very carefully before you decide to use the software.


There is a myriad of different licences which might be applicable in case of open-source software and if the developer wants to use software distributed on proprietary licences in addition to self-developed and open-source software as well, it adds another layer of difficulty, because every proprietary software has different rules of its use. Managing the use of software in a development project is therefore a complex matter which requires thorough examination and a careful approach.

A recommended practice is to create a list of all third-party software used and create guidelines within the organisation regarding which software licences are accepted to use and which are not. The crucial moment in the management of software licences is the moment that the software (the video game, but also any later update) is released to the public. At this moment, any licensor can potentially get to know that the developers have inappropriately used his code. We recommend to check the code in this regard at least once before every release. Many open-source licences require the attribution of licensor’s rights at the minimum, so such an internal audit would be required to carry out this obligation.

If you happen to come by with any issues when using O3DE or any other open-source software in your projects, we recommend you contact a lawyer, for example the LegalPlay team at KL&M LAW.