OpenToonz: the Ghibli-lineage animation tool, and a warning about download mirrors

The first paragraph is about where not to download from

The README opens with a warning marked Important, and it is about provenance rather than features.

OFFICIAL SOURCE ONLY: the only official websites for OpenToonz are opentoonz.github.io and this GitHub repository. To ensure your security, please avoid downloading OpenToonz from any other domain, as there are no other official mirrors or partner sites.

That is a stronger statement than a licence note. It says there are no partner sites, which closes off the tempting middle ground of a download page on a hosting provider's domain.

The two official routes are different in kind: the project site for the current installer and documentation, and the GitHub releases page for older versions and unstable nightly builds.

The lineage is Toonz Studio Ghibli Version, by way of Digital Video

The What is OpenToonz section explains the ancestry in three steps, and they matter for what you expect from the software.

OpenToonz is a 2D animation software published by DWANGO. It is based on Toonz Studio Ghibli Version, originally developed in Italy by Digital Video, Inc., and customized by Studio Ghibli over many years of production.

So this is not a new program that borrowed a name. It is the toolchain a major studio customised for its own production, published and maintained by a Japanese company after that.

The Special Thanks section credits the origin directly, describing it as an open-source program developed from Toonz, originally created by Digital Video, S.p.A., Rome, Italy.

Installation is a site visit, and old builds are a separate page

The Installation section does not contain a command. It says to download and install OpenToonz from the latest installer at the project site, opentoonz.github.io/e/index.html.

Older versions and unstable nightly builds are also available at the GitHub releases page.

Two facts follow. The stable path is a website you visit rather than a package you install, so there is no `apt`, no `brew` and no version manager entry documented here. And the README splits the versions across two places: the releases page for older and unstable builds, the site for the latest installer.

The Program Requirements section points at the site as well, for what you need installed before the program will run.

For anyone scripting a rollout, note that the nightly builds are labelled unstable in the README rather than described.

Build guides for four platforms, plus a stylesheet build of its own

The How to Build Locally section is four links, one per platform, which tells you the project documents building on each of them.

- Windows, `doc/how_to_build_win.md` - macOS, `doc/how_to_build_macosx.md` - Linux, `doc/how_to_build_linux.md` - BSD, `doc/how_to_build_bsd.md`

There is a fifth document for something the others depend on: instructions on how to build stylesheets are in `doc/how_to_stylesheet.md`, which tells you the application is not simply compiled from source without a separate asset step.

That matches the root listing, where `toonz/` is the application's own source and `thirdparty/` and `stuff/` sit beside it.

A build from source here is therefore more than one compiler invocation, and the per-platform documents are the place where that is spelled out.

Testing pull requests is a separate contribution path

The Development section has two checklist links, and one of them is unusual enough to call out: a development checklist, marked as a draft, and an AI-assisted development checklist, also marked as a draft.

Then there is a second sentence that is not about development at all: can't develop but still want to help? Help us test individual pull requests before they are merged, with steps in `doc/how_to_test_prs.md`.

That is a documented process for validating someone else's change on your own machine before it lands. For a desktop application with four platform builds and a stylesheet step, that is not a trivial thing to ask of a contributor, and writing the procedure down means it is not improvised per pull request either.

Both checklists being marked draft is worth noticing: the project is documenting its process while still writing it, so treat them as guidance rather than as a contract.

Three licensing regimes inside one repository

The Licensing section splits the tree three ways, and a reader shipping a build needs all three.

Files outside of the `thirdparty` and `stuff/library/mypaint brushes` directories are based on the Modified BSD License, in `LICENSE.txt`, and based on that license the software may be used or changed freely for business or personal use.

For files in the `thirdparty` directory, the instruction is to consult the licences in the appropriate READMEs or source codes.

For files in the `stuff/library/mypaint brushes` directory, the licences are in `stuff/library/mypaint brushes/Licenses.txt`.

So the permissive Modified BSD statement covers the application's own code and nothing else, and two subtrees carry whatever licences their upstream components had. Those two directories are called out separately rather than folded into the main grant.

If you are redistributing a build, the `thirdparty` and brush directories are where to read.

Support splits into a users forum, GitHub issues, and separate docs

The Community and Documentation sections route three different kinds of question to three different places.

To share tips or to troubleshoot, there is the Google OpenToonz Users forum. If you found a bug with the software after troubleshooting, or you are a developer, the instruction is to search the GitHub issues and post there.

General documentation lives in a separate repository, opentoonz_docs, linked from this one.

The triage rule is in the phrasing. The forum is for people who have a problem with the software; the issue tracker is for people who have found a bug or are developers. Bug reports that arrive without having tried the forum are the ones this is steering away from.

A separate documentation repository is a common pattern for projects of this size, since user documentation has a different lifecycle and a different audience from a desktop application written in C++. The translation situation is the same: the README carries Japanese and Simplified Chinese links to `doc/README_ja.md` and `doc/README_chs.md`, and there is a Weblate badge for the rest.

Editorial conclusion

OpenToonz suits an animator or a developer who needs a full-featured 2D animation application rather than a drawing app, and who wants the toolchain Studio Ghibli customised over many years of production. It does not suit you if you only want to draw frames, and it does not suit you if you want to be certain of what a build contains unless you take the README's advice about mirrors seriously. Verify three things before you install: that you are downloading from opentoonz.github.io or the GitHub repository, since the README states those are the only official sources, which version you are taking, because older versions and unstable nightly builds live on the releases page alongside the stable installer, and, if you build it yourself, the licence of the files you are shipping, because the tree splits into three different licensing regimes rather than one.

Frequently asked questions

Official sources

1. Issues
2. opentoonz/opentoonz on GitHub
3. Project website
4. README
5. Releases