A fork dated to the commit it forked from, three licence files, and a spell checker configured to edit files

The fork is dated to the commit it forked from

The readme dates the fork precisely, with a link to the commit it branched from: September 2024. It also explains what the fork is for, which is to improve on the upstream engine and contribute back to a shared codebase through a more community-driven model. The lineage behind that goes back further, to February 2014, when Godot itself was open sourced, after several years as an in-house engine built by two developers who are still maintaining it and used for work-for-hire titles. The most recent releases are Redot 26.3-rc.2 on 30 September 2026, Redot-26.3-rc.3 on 8 October 2026 and Redot 26.3 stable on 15 October 2026, while the last push to the default branch was on 1 November 2026.

The Python tooling targets 3.8 in a repository with no Python package

There is a Python project file at the root, and it is not a package. There is no project table, no name, no version and no dependencies, only tool configuration. What it configures is the machinery around the build. The type checker is configured with a list of strict flags, including one that forbids implicit optional parameters, one that reports redundant casts, one that reports any value returned where a concrete type is expected, and one that reports unreachable code. It excludes the third-party directory, which is the usual practice in a repository that vendors other people's code. Both tools are pinned to Python 3.8: the type checker's version field and the linter's target version. Nothing in the manifest contradicts that, since there is no runtime requirement here at all; the Python in this repository builds the engine and drives its build system rather than shipping as a library.

The linter is aimed at the build system, and it invents an import section for it

The linter's file list is the interesting part. Alongside the usual Python files, it explicitly includes two build-system patterns, the project's own SConstruct and every file named SCsub, which is what the build system uses to describe a unit of compilation. Those two file types then get their own rule exceptions, which disable the checks for imports that are not at the top of the file and for names that come from a wildcard import without being defined locally. Both are unavoidable in that style of build description. The import sorting rules are rearranged to match, with a custom section named for metadata inserted directly after the future imports and before the standard library, and that section is populated from a specific helper module. Line length is set to 120 characters, and the only extra rule family enabled is import sorting.

The spell checker is configured to write changes, with 28 code-shaped exemptions

The spelling configuration is the one that deserves a second read, because one setting gives the tool permission to edit files rather than only report them. Colours are enabled, hidden files are checked, the output is quieted to a high level, and three dictionaries are loaded, including one for rare words and one that converts British spellings to American ones. Then there is the exemption list: twenty-six words that the spell checker must ignore, and most of them are not words at all. They are short fragments such as three-letter and two-letter sequences that appear inside identifiers, variable names and abbreviations throughout a C++ codebase, alongside a few genuine British spellings and one word that is simply the name of a vendored directory. A skip list of paths does the same job for whole files: author lists, copyright text, a controller database, a generated header of localised strings, the source of a project format converter, and a web lock file.

Three licence files and two author lists sit at the root

A fork tends to accumulate legal files, and this one has the usual set. There is a licence file, which is MIT as the readme states plainly, with no strings attached and no royalties, and the claim that the games users make are theirs down to the last line of engine code. There is a separate copyright file. There is a third file covering the logo, so the branding is licensed apart from the code. Alongside those sit two author lists rather than one, which is the usual way a fork keeps the upstream credits separate from its own, plus a donors file and a changelog. For anyone shipping a game with this engine, the practical question is which of those files their distribution needs to carry, and the readme does not answer it.

Continuous integration is configured in two places at once

The repository carries a GitHub workflows directory and a GitLab pipeline file, so the pipeline story is not settled in one file. Around those sit the other quality gates a project of this size accumulates: a pre-commit configuration, three separate clang tools for formatting, static analysis and editor integration, an editor configuration file, a mailmap for contributor identities, an attributes file, and a list of revisions to exclude from blame, which is the polite way of absorbing large automated reformats. There is also a configuration file for an automated review service. The editor itself, the core library, the scene format, the platform layer, the drivers, the modules, the servers, the tests and a vendored third-party tree make up the rest, with three builder scripts (gles3_builders.py, glsl_builders.py and scu_builders.py) and a shell script for the Mono toolchain on Linux.

Nix is the recommended build, and SCons flags go through it

Compiling is delegated to a documentation site rather than explained here, with a link per supported platform. One exception is called out as recommended, and it is the shortest instruction on the page:

nix run .

That builds and runs the editor in one command, installing build dependencies automatically and compiling the engine first if the binary does not already exist. The repository carries the Nix pieces for it, a flake with a lock file and an environment file for a directory-based tool. A usage guide in the documentation directory covers the awkward parts: passing build flags through the run command rather than around it, forwarding runtime arguments so the editor receives them, and using the develop entry point manually when you want a shell instead of a build. Underneath all of it is the classic SCons build description at the root, which is what those flags configure.

The class reference lives in the editor, and AI integration is a script and a policy

Documentation is thin by design. The class reference is said to be accessible from the editor, which is a deliberate choice to keep the reference next to the code it describes, and everything else is either on the project site or in the documentation directory of the repository. The one newer subsystem has both a file and a rule attached to it: integration with AI assistants through the Model Context Protocol, with setup instructions in the repository and a shell script at the root to launch it. Alongside that sits a policy file about artificial intelligence, which is the kind of document that appears once a project has decided how it wants such contributions handled. The icon and logo set is committed in four variants, filled and outlined in two formats each, and the licence split described earlier applies to at least some of them.

Editorial conclusion

Redot is a reasonable choice if you want Godot's engine under a licence with nothing attached and you intend to shape it with other users, since that is the stated reason for the fork and the reason it exists separately. Before you commit, three things. Treat the divergence from upstream as a cost, not a feature: it forked in September 2024 and every change since is a patch you would have to carry or rebase. Read the licence surface, which is three files rather than one, with the logo licensed apart from the code and two separate author lists. And expect the documentation to be split: the class reference is accessible from the editor, while compiling instructions and the Nix usage guide are split between the docs.redotengine.org site and a file in the repository.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Redot-Engine/redot-engine on GitHub
5. Releases