# Tahoma2D carries on the Toonz Studio Ghibli codebase under a layered licence > Tahoma2D is a 2D and stop motion animation program descended from Toonz Studio Ghibli, maintained as a community fork with patch releases and a nightly build. Its licensing has three layers, and the repository adds an explicit policy on AI contributed code. **tahoma2d/tahoma2d** — 2D and Stop Motion Animation Software - Repository: https://github.com/tahoma2d/tahoma2d - Website: https://tahoma2d.org - Stars: 675 · Forks: 104 - Language: C++ - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/tahoma2d-tahoma2d ## Tahoma2D is a continuation of Toonz Studio Ghibli, not a new program The single most useful fact about Tahoma2D is where it came from. The README states that it is based on Toonz Studio Ghibli Version, originally developed in Italy by Digital Video, Inc., and then customized by Studio Ghibli over many years of production. That lineage explains the character of the software and of the repository. A production tool that a major studio shaped for its own films accumulates a very large and very specific feature set, and it also accumulates a large amount of code that no one outside the original company fully understands. The top level listing shows that scale directly: a toonz directory carries the bulk of the application, thirdparty holds vendored dependencies, plugins and stuff hold the plug-in and content libraries, and ci-scripts, doc and scripts directories carry the build and documentation work. Tahoma2D is what happens when such a codebase is handed to a community and maintained in the open, which is a genuinely different proposition from building a new animation program from scratch. ## Installing means downloading a release and reading the site for requirements The installation story is short because the software ships as conventional builds. The README points at the GitHub releases page for the latest release and sends you to the Tahoma2D site download page for the program requirements, which is where the supported platforms and dependencies are described. That separation is worth understanding: the repository does not enumerate requirements itself, so anyone automating a deployment has to read the site rather than the README. The release list shows a steady patch line, v1.6.2 published on 2026-07-01 and v1.6.3 on 2026-09-01, plus a nightly build alongside them. The nightly entry carries a misleading publication date of 2021-12-06 in the release metadata even though it is named for the latest nightly, so treat the named date rather than the timestamp as the version identifier. There is no package manager recipe in the README for Linux or macOS, no Homebrew cask mentioned and no snap, so distribution is through the release artifacts. ## Building locally means following a per platform guide in the doc directory The README points at three separate build documents depending on your operating system, one for Windows, one for macOS and one for Linux, each linked as a markdown file in the doc directory. There is also a fourth document, for building stylesheets, which is the kind of thing that only exists in a project with a large customisable interface, and a fifth, a step by step guide for testing individual pull requests before they are merged. That last one tells you something about how the project is run: non developers are explicitly invited to help by testing pull requests, which is a sensible division of labour for a project whose issue tracker is busy. At the top level of the repository there is a build shell script, tahoma_build.sh, alongside an updateVersion.sh script for version bumping and a .travis.yml file next to an appveyor.yml file, so the project carries configuration for two different continuous integration systems. The build documentation is a linked document rather than inline text, which means the exact toolchain requirements live outside the README. ## Three licence layers sit inside one tree The licensing section is the most carefully written part of the README, and it is worth reading in full before you use the software commercially. Files outside the thirdparty directory and the mypaint brush directory are under a modified BSD licence, and the README says the software may be used or changed freely for business or personal use on that basis. Files inside the thirdparty directory have their own terms, and the README asks you to consult the licences in the relevant READMEs or source files. Files in the stuff/library/mypaint brushes directory have their own licence list in a Licenses.txt file inside that directory. So a single checkout contains at least three layers of terms, and which layer applies depends on the file. There is a further wrinkle. The repository listing classifies the licence as a custom one that GitHub cannot classify, pointing to the LICENSE file, while the README describes the core files as modified BSD. A reviewer looking at the repository metadata alone would not learn the structure, so the LICENSE.txt file in the tree and the per directory licence files are the documents that matter. A studio with a legal review process should collect all three before shipping anything built on it. ## The project now states its position on AI contributed code The repository includes an AI_POLICY.md file, and the README links to it as the AI Contribution Policy. It also carries AGENTS.md and CLAUDE.md files, which are the conventions files that tell automated coding agents how to work in the tree, and a CONTRIBUTING.md. The presence of a written policy on AI contributions is a meaningful change in how a project of this vintage is being run, and it is unusual to see it called out in the README rather than buried. For a studio considering the project, that document is the place to look for rules about generated code, attribution and review, and a project that has decided to publish such a policy is at least aware that the question exists. It also tells you the project is actively maintaining its contribution workflow rather than only its bug fixes. The broader community channels are a Google Groups user forum for tips and troubleshooting, with bugs and development discussion moved to the GitHub issue tracker. ## Active maintenance shows up as recent pushes, not as new major versions The maintenance signals are mixed in a way worth reading carefully. The last push was on 2026-10-17, only days before this snapshot, and the repository is not archived, and the release line moved from v1.6.2 in July 2026 to v1.6.3 in September 2026, with a nightly build alongside. What has not happened is a new major or minor version. The version line sits in the 1.6 range while the code changes daily, which is a familiar pattern for a project that ships fix releases for a long lived branch and keeps the interesting work on master. For an evaluator, the practical questions are what your actual upgrade path looks like between 1.6.2 and 1.6.3, and whether the project documentation on the site matches the build in the repository, and neither can be answered from the README alone. The changelog file at the top of the tree and the project documentation directory are where to look, along with the issue tracker where upgrade reports accumulate. ## Conclusion Tahoma2D is a reasonable choice for a studio or a hobbyist who already knows Toonz and wants a community maintained branch with regular patch releases, a nightly build and per platform build guides, especially for 2D and stop motion work. It is a poor choice for a commercial pipeline that needs a vendor support contract or a clean single licence, since the tree carries a modified BSD core, separately licensed third party code and a separate brush library, and the repository listing classifies the whole thing as a custom licence GitHub cannot classify. Verify three things before you adopt it: that the third party and mypaint brush licences in your specific build are acceptable to your legal reviewer, that the release you install matches the platform requirements listed on the Tahoma2D download page, and that the AI contribution policy in AI_POLICY.md matches your own rules about generated code in a project with a copyright history. The last push was on 2026-10-17 and the newest fix release is v1.6.3 from 2026-09-01. ## FAQ ### What is the relationship between Tahoma2D and Toonz Studio Ghibli? The README states that Tahoma2D is based on Toonz Studio Ghibli Version, which was originally developed in Italy by Digital Video, Inc. and then customized by Studio Ghibli over many years of production. Tahoma2D is the community maintained continuation of that code. ### How do I install Tahoma2D? The README directs you to the latest release on the GitHub releases page and to the Tahoma2D site download page for the program requirements. There is no package manager recipe listed in the README for Linux or macOS. ### Can I use Tahoma2D commercially? For the files covered by the modified BSD licence, the README says the software may be used or changed freely for business or personal use. Files in the thirdparty directory have their own licences, and the mypaint brush files have a separate licence list, so those need checking separately. ### Does Tahoma2D have a policy on AI generated contributions? Yes. The repository contains an AI_POLICY.md file that the README links as the AI Contribution Policy, and it also carries AGENTS.md and CLAUDE.md files alongside CONTRIBUTING.md. The README also points to a guide for testing individual pull requests before merge. ## Sources - [Issues](https://github.com/tahoma2d/tahoma2d/issues) - [Project website](https://tahoma2d.org) - [README](https://github.com/tahoma2d/tahoma2d/blob/master/README.md) - [Releases](https://github.com/tahoma2d/tahoma2d/releases) - [tahoma2d/tahoma2d on GitHub](https://github.com/tahoma2d/tahoma2d) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tahoma2d-tahoma2d