LiquidBounce injects at runtime so it ships none of Mojang's code

The licence covers this repository and stops there

The terms come first, because they are narrower than the label on the project.

The licence is the GNU General Public License v3.0, and the README attaches a condition to it: it applies only to source code located directly in the clean repository. During development and compilation, additional source code may be used to which the project has obtained no rights, and such code is not covered by the GPL. In other words the grant on the build tree you can read is not the same as the grant on the artifact it produces.

Within that grant, the summary lists three permissions, use, share and modify, and two obligations for anyone who takes code from it. You must disclose the source of your modified work and of what you took from the project, which the README spells out as a ban on using any of this code, even partially, in a closed source or even obfuscated application. And your modified application must itself be licensed under the GPL. The file notes that its own summary is by no means legal advice and is not legally binding.

This is also, by its own description, a hacked client for a multiplayer game. Nothing in these terms grants permission to use it on a server that forbids cheats, and the repository's own issue tracker and forum are the only places its maintainers discuss it.

Mixins are how none of the game's code is shipped

The technical claim in the README is specific and worth taking seriously: mixins are used to modify classes at runtime before they are loaded, and LiquidBounce uses that to inject its code into the Minecraft client. The stated consequence is that none of Mojang's copyrighted code is shipped.

That is the whole design decision in two sentences. Instead of a mod jar that embeds the game's classes or a repackaged client, the project rewrites bytecode on its way into the class loader. The client you launch is still the game's own client; the difference is what has been woven into it before the first frame.

The README points readers at the SpongePowered mixin documentation, version 5.1.0, for the mechanism itself, which is a reasonable division of labour: the project does not explain mixins, it uses them. Everything the client does at runtime therefore arrives through injected hooks rather than through a documented plugin interface, and the source tree is where that behaviour lives.

For a reader who wants to know what the client does, that matters. There is no module list, no feature table and no settings documentation in the README to consult instead.

A Gradle repository with a buildSrc, an api package and a zip_include

The root listing shows a Gradle project with a wrapper checked in: `gradlew`, `gradlew.bat` and a `gradle/` directory, alongside `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties` and a `buildSrc/` directory for custom build logic. The Kotlin sources sit under `src/`.

Three entries are less common and say more about how the artifact is assembled. `api/` is a separate top level package directory, which suggests the public surface is kept apart from the implementation. `config/` holds configuration, and `zip_include/` is a directory whose name describes its job: files that get placed into the packaged zip. `scripts/` sits next to it for build and release scripting.

The rest is tooling and editor configuration: `.editorconfig`, `.gitattributes`, `.gitignore`, a `.github/` directory, an `.idea/` directory for IntelliJ, and `LICENSE` next to `README.md`.

The default branch is `nextgen`, which tells you where new work is expected to land without telling you which Minecraft version any of it targets.

src-theme needs Node.js inside a Kotlin build

One directory does not belong to the JVM side of the project. `src-theme/` is a separate tree, and the README says Node.js has to be installed for it. The build therefore spans two toolchains: Gradle for Kotlin and a JavaScript toolchain for whatever produces the theme.

That is not an unusual arrangement for a client with a configurable interface, and it is the kind of detail that matters when you are trying to work out what a build actually consumes. Gradle is named first as the build system, with a link to the Gradle install instructions, and Node.js is named as a second requirement rather than as an optional extra.

The theme link points at the directory on the `nextgen` branch, so the theme lives in the same repository rather than in a separate one. A contributor editing only the Kotlin side still needs Node installed to get through a full build, which is the practical cost of keeping both trees in one place.

The repository also carries `flake.nix` and `flake.lock`, so a Nix based environment is a fourth entry in a build story that already includes Gradle, Node and an IDE.

A Nix flake sits next to the Gradle wrapper

Reproducible environments are usually a single mechanism. This repository has two.

`flake.nix` and `flake.lock` describe a Nix flake, which pins an environment by content hash, while the Gradle wrapper pins the build tool version the project expects. Neither mentions the other in the README, and no section of the documentation explains when to use which.

The combination is not contradictory. A flake can pin JDK versions and system libraries while Gradle handles the build itself, and for a project that has to produce a working client across machines, pinning both ends is defensible. What the README does not give you is a decision: there is no line telling a contributor which of the two paths to take, and no mention of Node or the theme in either list.

So the honest summary of the build story is that it is over-specified rather than under-specified. Gradle, Node.js and Nix are all named as things you need, and the documentation stops there.

Releases moved from v0.38 to v0.40 on a two month cadence

The release history is three tags over five months. v0.38.0 was published on 2026-05-19, v0.39.0 on 2026-07-16 and v0.40.0 on 2026-08-21.

Those dates matter for one practical reason: the README never names a Minecraft version, a loader version or a Fabric API version, so the only way to relate a build to anything is through the release list. The default branch is `nextgen`, which is where new feature work goes by the project's own naming, and the last push was on 2026-10-03, about six weeks after v0.40.0.

So the repository is not a snapshot. Whatever sits on `nextgen` today is past the newest tag, and the tag list is the closest thing to a compatibility record that the documentation offers.

The issue tracker is the other place where version problems get reported, and the README asks for bugs, missing features and steps to reproduce them there rather than in the discussion channels.

An empty Stats heading and an address in Hanover

Two things in the README are worth reading as design decisions rather than oversights.

The first is the Stats heading. It is followed immediately by the Imprint heading, with nothing between them. A client with a public website and a Discord channel could easily have populated it, and the empty heading tells you the project chose not to publish usage numbers, which is consistent with a client whose users would rather not be counted.

The Imprint is the opposite choice. It names CCBlueX, gives a postal address in Hanover, Germany, and identifies the owner and the person responsible for the content as Marco Beyer. For an open source project that injects code into a game client, publishing a legal contact is a deliberate act.

The rest of the README is links. Website, forum, Discord, a YouTube channel and an X account, plus an issues link, and a Contributing section that amounts to an invitation to make changes and submit a pull request. There is no feature list, no documentation of what the client does, and no wiki link in the file, so the documentation burden sits entirely on the website and the forum.

Editorial conclusion

Read this one as an architecture reference rather than as software to run. The mechanism is interesting, a mixin injecting Kotlin into a Java client at load time so that none of the game's own code has to be redistributed, and the repository is a readable Gradle plus Nix project with a separate Node driven theme. None of that makes it appropriate on a server you do not control, on an account you share, or on a client whose rules you have agreed to, and the project itself frames it as a hacked client. Before you read further into the source, settle two things: the GPL grant covers only the clean repository and not code pulled in during the build, and the README documents no Minecraft version and no feature list, so compatibility has to be established from the release tags rather than from the documentation.

Frequently asked questions

Official sources

1. CCBlueX/LiquidBounce on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases