# CMaNGOS, a World of Warcraft server emulator that makes correctness the goal

> CMaNGOS builds server software that emulates World of Warcraft, and its Classic fork is one of several emulator lineages in the same GitHub organisation. What distinguishes this project is a stated standard, that the emulation should be right, plus a licence file that draws careful boundaries around trademarks, game content and third-party libraries.

**cmangos/mangos-classic** — C(ontinued)-MaNGOS (Classic fork) is about: -- Doing WoW-Emulation Right!

- Repository: https://github.com/cmangos/mangos-classic
- Website: http://cmangos.net
- Stars: 1,095 · Forks: 636
- Language: C++
- License: GPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/cmangos-mangos-classic

## Doing Emulation Right, stated as a three-part standard

CMaNGOS is described as a free project with a single goal, doing emulation right, and the README expands that into three words. Doing covers the fact that the project is focused on developing software, that other aspects need doing too and count as equally important, and that anyone who wants to do something is welcome. Emulation covers the substance: server software able to emulate a well known MMORPG service. Right is the demanding one. The goal is always to provide the best code possible, and right is defined by the behaviour of the system being emulated. Developing things right also includes documenting and discussing how to do things better.

That last clause is the one that shapes the repository. A codebase that is judged by behavioural fidelity needs tests against a reference, needs change logs, needs an issue tracker where a discrepancy is a legitimate bug report, and needs people who will argue about what the original actually did. The repository layout shows the apparatus: AUTHORS.md, CONTRIBUTING.md, COPYRIGHT.md, ChangeLog.md, NEWS.md, THANKS and a file named WARNING, alongside src/, dep/, sql/, doc/, contrib/, cmake/ and a CMakeLists.txt.

Alongside the goal sit three supporting values. Freedom of the work, since the code is released under the GPL, and freedom for developers, with the blunt instruction that no one here tells anybody what to do, and that if you want somebody to do something for you you can pay them, but the project is there to enjoy. And a friendly environment, where personal issues are left outside, arguments are about content rather than thin air, and the Netiquette is followed.

## One organisation, several emulator lineages, separate repositories

The repository you are looking at is mangos-classic, one fork in the cmangos organisation, and the fork boundary is the first thing to understand about the project. The organisation hosts several GitHub repositories, and each is a different emulator lineage aimed at a different era of the game. A pull request, an issue or a bug behaves differently depending on which one you are in, and the README points separately at the issue tracker, the pull requests and the wiki for this repository.

The build system is CMake, with a CMakeLists.txt at the root, a cmake/ directory, a contrib/ directory for contributed tooling, and createprojects.bat for generating project files on Windows. The source is under src/, the SQL is under sql/, and dep/ holds the third-party libraries the build pulls in. The README also says documentation can be found in the doc/ subdirectory and on the GitHub wiki, and that the wiki carries additional information on installation.

Platform coverage is visible in the badge row at the top of the README, which shows three separate CI workflows, one for Windows, one for Ubuntu and one for MacOS. Three operating systems built continuously is a meaningful signal for a server emulator, since the deployment target for most people is a Linux box and the development target is often a Mac or a Windows workstation.

One detail of the release naming deserves attention. The only listed release is tagged latest, described as a development build dated 2026-10-15, with a publication timestamp of 2026-05-23. A floating tag pointing at a moving build is a pattern you will meet in projects that publish continuously rather than versioned releases, and it means there is no stable artefact to pin by name.

## A playerbot branch inside the server codebase

The repository root carries a file called README_PLAYERBOT.txt, alongside the main README. In the world of private server emulators, a playerbot is an automated client that plays the game, used for testing and for populating a world. The presence of a separate documentation file for it in the same tree says that the bot is a first-class part of the codebase rather than an external add-on.

That is a design decision with consequences in both directions. On the useful side, a bot inside the server shares the same world model, the same database and the same scripting layer, so behaviours that would be awkward to script from outside become ordinary server-side code. On the cost side, a single repository now carries two large products, and a change to the shared core has to be reconciled with both. The split documentation file is how that is kept legible: a reader looking for the emulator behaviour is not sent through bot documentation, and the reverse holds.

The README does not describe the bot's architecture, its configuration or how it is enabled, so a reader looking for operational detail will not find it in the files listed here. The file is a pointer, and the rest of the story lives in the source tree and in the wiki.

For anyone evaluating the project, the takeaway is that the Classic fork is not only a server core with a UI on top. It is a server core that also has to keep a synthetic player population working, which is one of the harder consistency problems in any long-lived simulation.

## GPL-2.0, an OpenSSL exception, and a dep/ full of other licences

The licensing section is unusually complete, and it is the part to read before using any of this code.

CMaNGOS is free software, redistributable and modifiable under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License or, at your option, any later version. The full text is in the COPYING file. That version-or-later clause is worth noting, because it is more permissive than the plain GPL-2.0-only reading many people carry, and it means the project can be relicensed by its own maintainers into a later GPL revision.

Three further points follow. Some third-party libraries CMaNGOS uses have other licences that must be upheld, and those libraries are located within the dep/ directory. That is a practical instruction: a tree you vendor has more than one licence in it, and the dep/ subdirectory is where to look.

Then there is the OpenSSL exception. The project gives permission to link the code of its release of MaNGOS with the OpenSSL library, or with modified versions of it under the same licence, and to distribute the linked executables, while the GPL still governs everything that is not OpenSSL. The exception is written to be extensible: if you modify the file, you may extend the exception to your version of the file, but you are not obligated to, and if you would rather not carry it, the instruction is to delete the exception statement from your version.

The practical effect for a packager is that a binary linking OpenSSL and carrying the exception in its own licence text stays within the GPL, and one that drops the exception text does not. That is a small piece of legal engineering in the source tree, and it is the kind of detail that is easy to remove by accident.

## The boundaries written into the licence file

A section titled exceptions to GPL does something unusual: it does not talk about the code, it talks about what the project is not. World of Warcraft and its content and materials are stated to be copyrighted by Blizzard Entertainment or its licensors, and the long list of names in that paragraph, from The Frozen Throne and The Burning Crusade through to Frostmourne and Onyxia's Lair, are described as trademarks or registered trademarks of Blizzard Entertainment in the United States and other countries.

Then the sentence that matters most for anyone reading the repository: the CMaNGOS project is not affiliated with Blizzard Entertainment or its licensors.

That framing has an operational consequence, and it is the reason this section sits in the licence file rather than in a separate legal notice. The project can only be an emulator of a service; it cannot contain the service's content, its art, its sound or its text, all of which remain the property of the rights holder. What the repository contains is code that reimplements the behaviour, and the data a running server needs comes from elsewhere and is a matter for whoever operates that server, not for the developers who write the emulator.

For a reviewer, this is the line to hold. The project is a reimplementation effort with an explicit non-affiliation statement, and any description of it should keep that distinction intact rather than implying the game content travels with the code.

## Where an emulator fork is the wrong tool

The first limitation is age and divergence. This is a fork of a fork, targeting the Classic era of a game that has since had several expansions, and it has to remain compatible with a specific historic behaviour while the game and its surrounding ecosystem moved on. Every divergence from upstream is a maintenance item, and a project that values behavioural fidelity has to keep choosing between matching the original and borrowing improvements from later lineages.

The second is the release model. The single listed tag is a development build, and the project's own definition of right includes developing things right and documenting how to do things better, which is a development culture rather than a release discipline. There is no long-term support branch described in the README, no compatibility matrix, and no statement about which build is recommended for production. A team that needs a supported version of this software with a predictable maintenance horizon will not find it here.

The third is the scale of the undertaking. This is a server emulator, which means a database, a scripting layer, a network protocol, a world model and, in the playerbot branch, a synthetic population. Nobody adopts it for a single feature. The relevant question is whether you want to operate a service, and the licence file's non-affiliation statement is the reminder that the answer has a legal dimension as well as a technical one.

There is also the ordinary engineering reality of a project this old: the code is C++, the build is CMake, the tooling has grown up alongside the systems it compiles on, and the contributors are a community rather than a team with a roadmap.

## Community rules as part of the technical offer

The social contract is written into the same README as the technical one, which is a reasonable indicator of how the project runs.

The rules are short. Personal issues are left behind. Arguments are about content and not about thin air. The Netiquette is followed. No one is told what to do, and the line about paying someone for work while the project exists to enjoy tells you where the boundary between employment and volunteering sits.

The supporting infrastructure is what makes that credible. CONTRIBUTING.md is linked as the contributing guidelines, and the organisation hosts a Discord, an issue tracker, a pull request area and a wiki, so a contributor has somewhere to ask a question before writing a patch. AUTHORS.md, COPYRIGHT.md and THANKS record who did what, and ChangeLog.md and NEWS.md record what changed, which for a project whose stated standard is behavioural fidelity is the difference between a correction and an unexplained divergence.

The pull request workflow is the interesting part for a developer. For a codebase of this size, most proposed changes are not features but corrections, and the project is structured around the idea that a discrepancy against the original behaviour is a defect worth reporting. The result is a repository where the discussion is inherently about what the system should do, which is exactly the discipline the goal statement asks for and the reason this fork has survived while so much similar work has not.

The last push was on 2026-08-31, and the project is not archived, so the work is still going on.

## Conclusion

CMaNGOS fits a developer who wants to study or work on a large server emulator with a stated correctness standard, an active pull request workflow and a codebase that is still receiving regular updates, and the Classic fork is the right branch for the original game content. It does not fit a team that needs a supported product with a service level, and it is not a route to a public game service, since the project states it is not affiliated with Blizzard Entertainment and that game content and materials remain Blizzard's property. Before adopting anything here, read the licence file's exceptions section and the dep/ directory, because the GPL-2.0 code, the OpenSSL linking exception and the separate third-party licences all apply at once, and check the release naming, where the only tag is a development build dated 2026-10-15. The last push was on 2026-08-31.

## FAQ

### Is CMaNGOS affiliated with Blizzard Entertainment?

No. The exceptions to GPL section of the licence file states that the CMaNGOS project is not affiliated with Blizzard Entertainment or its licensors, and that World of Warcraft content and materials are copyrighted by Blizzard Entertainment. The project ships code that emulates the behaviour, not the game content.

### Under which licence is CMaNGOS released?

The GNU General Public License, version 2 or, at your option, any later version, with the full text in the COPYING file. The project also grants a special exception allowing the code to be linked with the OpenSSL library, and notes that some third-party libraries in the dep/ directory carry their own licences that must be upheld.

### How is the CMaNGOS server built?

With CMake, through a CMakeLists.txt at the root and a cmake/ directory, with contrib/ for contributed tooling and createprojects.bat for generating project files on Windows. The build covers Windows, Ubuntu and MacOS through three separate CI workflows, and the wiki carries additional information on installation alongside the doc/ subdirectory.

### What does the mangos-classic repository emulate?

It is the Classic fork of C(ontinued)-MaNGOS, the project whose goal is to develop server software that emulates a well known MMORPG service. The cmangos organisation hosts several repositories, and mangos-classic is the lineage for the original Classic era of the game.

### Does the CMaNGOS repository include playerbot support?

The repository root carries a separate README_PLAYERBOT.txt alongside the main README, indicating that playerbot support is part of the codebase rather than an external add-on. The file is a pointer for that branch of the project, and the details live in the source tree and the wiki.

## Sources

- [cmangos/mangos-classic on GitHub](https://github.com/cmangos/mangos-classic)
- [License: GPL-2.0](https://github.com/cmangos/mangos-classic/blob/master/LICENSE)
- [Project website](http://cmangos.net)
- [README](https://github.com/cmangos/mangos-classic/blob/master/README.md)
- [Releases](https://github.com/cmangos/mangos-classic/releases)

---

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