input-overlay: two kinds of preset, three dependency licences

A GPL 2.0 project that links a GPL 3.0 library

The credits section is the most informative paragraph in the readme, and it names three dependencies with three different licences.

The first is a global input hook library, credited to an individual and licensed GPL version 3. The second is an embedded web server library, licensed GPL version 2. The third is a cross-platform development library for input and windows, under the zlib licence.

The project itself is reported as GPL 2.0.

So the tree contains one dependency under a licence that is newer than the project's own. That combination is not unusual in practice and it is not hidden either, since the credits are stated in the readme rather than only in a licence file. It does mean a distributor who reads the project licence alone gets a different answer from a distributor who reads the credits.

The dependency that does the work of catching input is the first one, which is why its licence is the one to think about if you are redistributing a build.

Presets means two different things in this repository

There is a directory called presets at the top of the tree, and there is a preset file for the build system, and they have nothing to do with each other.

The directory holds the overlay layouts a user picks between: which keys and buttons are shown, where they sit, and what they look like. That is the meaning the rest of the project uses, since the readme links a page for converting old preset files and a configuration creation tool.

The file is a CMake presets file, which tells the build system how to configure and build the project. Same word, opposite audience: one is consumed at run time by a streamer, the other at build time by a contributor.

The confusion is easy to create and easy to resolve. If you are looking for the overlays, you want the directory. If you are trying to reproduce someone else's build, you want the file. Nothing in the readme mentions either, which means a contributor reading only the readme has no way to know the build system supports named configurations.

Three formatters and one script

Count the style configuration files in the root and the tooling picture becomes clear.

There is a formatter configuration for C++, which covers the source directory. There is a configuration for one specific CMake formatter, and a separate configuration file for a different CMake formatter. And there is a shell script whose name is simply format.

So this is a C++ project that formats its own build files with one of two tools, both of which are configured in the tree, and a script to run the formatting.

The most likely explanation is history rather than confusion. A project that adopted one build-file formatter and later added another would keep the first configuration for files still formatted that way, which is exactly what two configuration files and a single script looks like.

The old preset format was INI and the converter is unfinished

One line in the readme's information section tells you more about the format history than the whole installation page would.

It links a converter for old presets to JSON, and marks it work in progress.

So the current preset format is JSON, the previous one was the INI format that Windows applications traditionally use, and the tool that moves between them is acknowledged as incomplete.

That is worth knowing before you go looking for your old configuration files. A preset you wrote years ago for an earlier version of this tool is in a format the current build may not read, and the migration path is a tool the project describes as unfinished. Expect to recreate at least part of a layout by hand.

The other link in the same section is a configuration creation tool, hosted as a page rather than as a program in the repository. Together they cover both ends of the workflow: build a layout in a browser, then migrate it if you are coming from an older version.

The user-facing tools are hosted outside the repository

Every link a streamer would use points somewhere other than the repository, and the pattern is consistent.

There is the wiki, with an installation page inside it. There is the releases page, which the readme tells you to go to for binaries. There is a resource page on the streaming application's own forum. And there are two hosted pages for the creation tool and the format converter.

So the repository holds the source, and everything a user touches is somewhere else. That is a normal arrangement for a project with a compiled binary and a browser tool, and it has one consequence worth stating: the readme in the repository is a pointer file rather than documentation, and at seven lines it does not even attempt to be more.

For a project of this size that is a deliberate choice rather than an oversight. The documentation effort went into the wiki, and the readme does the minimum needed to route someone there.

Tag naming changed between two of the last three releases

The release list shows three recent entries, and they are named consistently.

The most recent is 5.1.3, published on October 29, 2026. Before that are 5.1.2 from October 25, 2026 and 5.1.1 from October 24, 2026.

The cadence itself is worth noting: three releases within a week, and the most recent push is dated November 1, 2026.

So the source has moved since the last release, which is normal for a project with an active branch. If you are chasing a bug fix, check whether it landed after the last tag rather than assuming the latest release contains it.

Two platforms, vendored dependencies, and a bundled web interface

The readme states the platform support in one line: available for the streaming application on Windows and Linux, 64-bit.

So there are two targets, one of them architecture-restricted, and the binaries are on the releases page rather than built from a package manager. There is no Linux distribution package named in the readme and no source build recipe.

The tree explains the rest. There is a source directory, a client directory, a build-auxiliary directory, a dependencies directory, a data directory, a documentation directory and the preset directory, alongside the top-level build file, the preset file for the build system and a submodules file.

That submodules file is the interesting one. It suggests some dependencies are checked out as separate repositories, which fits the deps/ directory in the tree.

Editorial conclusion

Use input-overlay if you stream and want your key presses, mouse movement and controller inputs visible to viewers, and if OBS Studio on Windows or 64-bit Linux is your setup. Three things to check before you commit. The project declares GPL 2.0 while one of its dependencies is GPL 3.0, which is a combination worth resolving with whoever handles your compliance. Preset files are JSON now, and the converter from the older format is marked unfinished, so old presets may need manual work. And the tooling is unusual: the tree carries a formatter for C++, two different formatters for the build files, and a script to run them. Build from source only if you need a platform the releases do not cover, since the documented path is a binary download.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. univrsal/input-overlay on GitHub