# Aseprite's source is on GitHub, but the licence is an EULA

> A C++ sprite editor for Windows, macOS and Linux whose feature list is unusually thorough, and whose licensing is the part a reader has to understand before anything else. The repository has no standard open source identifier, the main code is under a custom end-user agreement, and the MIT licence covers only specific vendored modules.

**aseprite/aseprite** — GitHub describes it as Animated sprite editor & pixel art tool (Windows, macOS, Linux). The repository metadata lists C++ as its primary language. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/aseprite/aseprite
- Website: https://www.aseprite.org
- Stars: 39,815 · Forks: 9,141
- Language: C++
- License: not declared
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/aseprite-aseprite

## The code is public and the grant is not an open source one

This is the first thing to establish, because the repository being on GitHub invites the opposite assumption. The project states that it is distributed under three different licences, and the first is an End-User License Agreement covering the source code and the official releases and binaries. The licence recorded against the repository is unknown in the standard-identifier sense, which is consistent with a custom agreement rather than a recognised licence. The MIT grant is real but narrow: it applies to specific modules and libraries in the source, named as laf, clip, undo, observable and ui, with a pointer to a file in the source tree that lists them. So the accurate position is that a well-known open source runtime sits underneath a proprietary application, which is a common and defensible arrangement, and it is not the same thing as the project itself being open source.

## Two channels, two agreements, and you have to know which one you have

The second and third licences are split by where you obtained the program, and that distinction is easy to miss because the binaries are identical. Steam releases are distributed under the terms of the Steam Subscriber Agreement, which is Valve's agreement and not the project's, so a licence question about a Steam copy is answered by a document the Aseprite authors did not write. Anything obtained outside Steam falls under the EULA instead. For a reader making an adoption decision the practical consequence is that compliance depends on acquisition route, and that any internal policy about third-party tooling has to be checked against both documents rather than the one linked from the project. There is a dedicated licensing section in the project FAQ covering the commercial case, which is where a reader with a specific question should start rather than inferring terms from the licence file alone.

## The educational licence is granted on request, not automatically

There is a third route, and it is the one that decides whether a classroom can use this. The project states that a special educational licence can be requested by a teacher in an educational institution who wants to use Aseprite in a classroom, and the wording in-situ suggests it is tied to teaching use at the institution rather than to any personal or research use. The mechanism is a request, not a self-service toggle, so a teacher should expect to apply and wait. What is not covered is any broader academic or research exemption, and nothing in the repository describes one. For a student or a researcher reading this, the absence of a stated free tier is the practical fact: the options the project itself offers are the EULA, an educational request, and the Steam agreement, and there is no fourth option listed for individual non-classroom use.

## Layers and frames are separate concepts, and the tools follow from that

The data model is the reason to like or dislike this editor, and it is stated first among the features. Sprites are composed of layers and frames as separated concepts, which means a layer is not a frame and a frame is not a stack, and the timeline links them. Everything else in the feature list descends from that separation. Layer groups exist for organising work, and reference layers exist specifically for rotoscoping, which is a task that only makes sense when one layer can be looked at without being drawn on. A transform operation can apply to multiple frames and layers at once because they are distinct axes rather than one flattened stack. The consequence for a reader coming from a paint program is that animation is a first-class structure here rather than a set of duplicated images, and that structure is what the export formats and the scripting API then work against.

## Export runs from GIF to FLC, and the tail is the interesting part

The import and export list covers sprite sheets, GIF files and a sequence of PNG files, and then in parentheses a set of formats that place the tool in a longer history: FLC, FLI, JPG, BMP, PCX and TGA. Those are animation and raster formats from the era before PNG became universal, and their presence says something about who uses the tool, which is people maintaining or converting existing game assets rather than only people starting new ones. Colour handling is similarly explicit, with support for colour profiles and three colour modes, RGBA, Indexed with palettes up to 256 colours, and Grayscale. The 256-colour ceiling on indexed mode is a hard limit worth knowing before you commit a palette-heavy asset, and the project does not soften it. Sizing a new sprite for indexed rather than RGBA is a decision that is awkward to reverse once frames exist.

## Non-linear undo and crash recovery are features, not accidents

Two entries in the feature list are about not losing work rather than about drawing, and they are the ones that distinguish a tool people use for hours. Undo and redo are supported for every operation, and the undo history is described as non-linear, which means the order in which you undo is not forced to be the reverse of the order in which you did things. The second is data recovery, alongside the ability to reopen closed files, for the case where the application crashes. For a pixel artist this is not a minor feature, because a frame is typically a few hundred bytes of index data and an hour of work, and a crash at the wrong moment is indistinguishable from losing the hour. Whether the recovery is sufficient is not something the repository documents, but the existence of a data-recovery page and a recovery test suite in the tree is a better signal than silence would be.

## Three build scripts, a CMake tree, and a third of the feature list is scripting

Building from source is documented separately, in INSTALL.md, and the repository is shaped for it. There are three platform entry points, build.sh, build.cmd and build.ps1, over a CMakeLists.txt with a cmake/ directory, a third_party/ tree, a data/ directory, a tests/ directory, and pre-commit hooks with .clang-format and .clang-tidy configuration. The README does not contain a build command, so the installation steps live in that file and on the project site. Two capabilities are worth singling out for anyone automating art production, which are the Lua scripting layer and the command line interface. A Lua API means a studio can write its own export and validation passes rather than clicking through the GUI, and a CLI means the same from a shell or a build script. The repository also records its provenance, crediting David Capello as the original creator and Igara Studio with contributors as the current maintainers, with the active team in AUTHORS.md and a CODEOWNERS file beside it.

## Conclusion

Adopt Aseprite if you animate sprites for work you own the rights to, want layer and frame separation as a real data model rather than a convention, and can accept an EULA instead of an open source grant. Do not adopt it expecting to fork it, vendor it into a commercial product, or ship it on a platform it does not build for, because the main code is not MIT and there is no mobile target. Verify first which distribution channel you are licensing, since direct downloads and Steam are under different agreements, and read EULA.txt before treating the public repository as permission to modify and redistribute.

## FAQ

### Is Aseprite for free?

Not as free software. The source code and official releases are under a custom End-User License Agreement, not an open source licence, and the MIT licence covers only named modules such as laf, clip, undo, observable and ui. A special educational licence can be requested for classroom use, and Steam copies fall under the Steam Subscriber Agreement.

### Is Aseprite on mobile?

No mobile target is listed. The project describes itself as a pixel art and sprite editor for Windows, macOS and Linux, and the repository contains no Android or iOS build configuration.

### how to install aseprite from github

The README carries no install command. Building is documented in INSTALL.md, and the repository provides build.sh, build.cmd and build.ps1 over a CMakeLists.txt, so a source build means following that file rather than a command given on the project page.

### how to use aseprite

Sprites are built from layers and frames as separate concepts, with onion skinning and real-time preview for animation, colour modes of RGBA, Indexed up to 256 colours, and Grayscale, and export to sprite sheets, GIF or PNG sequences. There is Lua scripting and a command line interface for automating export and other repetitive work.

## Sources

- [Official documentation](https://www.aseprite.org)
- [Official README](https://github.com/aseprite/aseprite#readme)
- [Project repository](https://github.com/aseprite/aseprite)
- [Release notes](https://github.com/aseprite/aseprite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aseprite-aseprite