SFML: four subsystems in C++, a frozen 2.x branch, and dependencies that carry their own licenses

No more features are planned for the 2.x series, and migration.md is where that decision is written down

The clearest statement in the project about its own direction is two lines long: development is focused on version 3 in the master branch, and no more features are planned for the 2.x release series. That is not a vague intention. It means the 2.x line is now a maintenance position, so a team starting fresh in 2026 has no argument for choosing it except a codebase that already depends on it. The repository root carries a migration.md file, which is the artifact of that break: it is where a 2.x user goes to find out what the 3.x API asks of them. Nothing in the project summarises what actually changed, so that file, not the marketing, is your first stop.

The release sequence that followed the break is short enough to read at a glance. Point release 3.0.1 landed on 2025-04-22, point release 3.0.2 on 2025-09-18, and the minor version 3.1.0 on 2026-04-16. Last push to the repository is dated 2026-11-01, so the work is current rather than abandoned. The consequence for a reader is about your own planning, not about SFML's health: if you are on 2.x, you are choosing a feature set that will not grow, and if you evaluate 3.x you are signing up for an API that had a breaking transition within the last two years and still ships point releases after its minors. Both are workable. Neither is free of a migration decision you have to make deliberately.

There is no install command in the project docs, so you choose between a release, the master tree, and branch artifacts

The install section contains no package name, no apt line, no brew line, no vcpkg identifier. It points at the tutorials page and says there is one tutorial per platform and compiler that SFML supports. That is a deliberate deflection: SFML is a library you build, and the build differs enough across platforms that the project treats the tutorial as the installation step. It also means the readme will not tell you whether a package manager already ships it, and if you are considering one, you have to verify that yourself.

Three acquisition routes are named, and they differ in what you are actually tracking. The latest official release is on the project's download page. The source code of the current development version comes from the Git repository, which is the master branch under active 3.x development, so a clone tracks a moving target with no version tag to pin. The third is the artifacts storage at artifacts.sfml-dev.org/by-branch/master/, which is described as the latest snapshot or artifact builds, and the path itself shows the problem: the artifact is filed by branch, not by release, so the same URL can hand you different bytes over time.

Pick the release when you want a build you can reproduce six months from now. Pick the master tree or the branch artifacts when you need a fix that has not shipped in a tag yet, and accept that you now own the decision about when to move to the next tagged release. The project is not archived and the last push is recent, so either path is alive; the difference is entirely about who controls your upgrade timing.

The Zlib license is permissive, and two bundled dependencies bring a GPL option with them

SFML's own terms are about as open as software licenses get. The libraries and source are distributed under the zlib/libpng license, and the project states it plainly: free for any use, commercial or personal, proprietary or open source, usable in your project without restriction, and you can even omit mentioning that you use it, though attribution is appreciated. That sentence settles the question for the SFML code itself. A commercial game or a proprietary internal tool can link it without a licensing conversation.

The complication is one line further down: external libraries used by SFML are distributed under their own licenses, and the project enumerates them. Most are unambiguously permissive, with stb_image and stb_image_write in the public domain, libogg, libvorbis and libflac under BSD, cpp-unicodelib and qoi under MIT, HarfBuzz under the Old MIT license, SheenBidi under Apache, wepoll and libssh2 under BSD, and dr_mp3 and miniaudio as public domain or MIT No Attribution. Two entries are not single-license. FreeType is offered under the FreeType license or the GPL, and Mbed TLS is offered under the Apache license or the GPL.

This is the detail a reader should not skip. Because those two are dual licensed, the permissive path exists, but your binary's compliance depends on which variant you actually linked, and that is a property of your build configuration rather than a line you can read in SFML's license file. The repository keeps its third-party code in an extlibs directory, so the choice is being made inside the tree you build. Before shipping a proprietary binary, confirm which FreeType and which Mbed TLS variant ended up in your link, since inheriting the GPL side of either one changes what you may distribute.

The CMake template pulls SFML into your own build graph instead of the system's

The recommended starting point is not a binary and not a system package. It is a CMake-based project template hosted separately at github.com/SFML/cmake-sfml-project, described as the easiest way to get started, which automatically downloads and builds SFML alongside your own application. The project then sends you to that template's own readme for full instructions, which is itself a signal: the consumption model is documented somewhere other than this repository.

Think about what that does to your build. A library you install once becomes a dependency your configure step fetches and your compiler builds every time, so build duration, the presence of a working compiler and CMake, and network access at configure time all shift from being your machine's private concern to being facts about how anyone builds your project. On a clean CI runner that has never seen SFML, the first build is a full library build, and that cost is paid on every fresh environment rather than amortised across a shared install.

The repository layout matches this build-centric design. At the root sit CMakeLists.txt, CMakePresets.json and a cmake directory, alongside src, include, extlibs, test, tools, doc and examples. A presets file in particular means the build has named configurations you are expected to select rather than a single default, which is convenient for reproducible CI and one more decision for a newcomer. If your project already has its own CMake conventions, the template is still worth reading before you assume how the dependency will be fetched, since the README does not document any other consumption path.

Four subsystems in one library, with language bindings the repository does not ship

The scope is stated in one sentence: access to windowing, graphics, audio and network. That is the whole product, and it is the reason to choose SFML over assembling a windowing library, a rendering library, an audio library and a socket library separately. Each subsystem brings its own external dependency, which explains the license list in the previous section, since text rendering needs FreeType, audio decoding needs the Ogg, Vorbis, FLAC and mp3 decoders plus miniaudio, and the network side needs Mbed TLS and libssh2.

The same sentence then names bindings for various languages such as C, .Net, Ruby and Python. Read carefully, that claim describes the wider SFML ecosystem, not this repository. The primary language here is C++, and the root layout contains include, src, examples, test, tools, doc, cmake and extlibs, with no binding directory anywhere in it. The consequence for a reader outside C++ is that you are consuming a different project with its own maintainers, its own release cadence, and its own lag against the 3.x API. Nothing in this repository tracks which binding has caught up to which SFML version, and no file here will tell you that a Ruby or .NET binding supports 3.1.0. If a binding lags, you inherit the gap between what the C++ API offers and what your language exposes, and you cannot read that gap off of this project.

The examples tree is the real API surface: 22 directories, three platforms, three protocols

Because the project describes features rather than signatures, the examples directory is where the actual scope becomes visible. It carries 23 subdirectories, most of them sample programs, and their names are effectively an inventory of the library. Input handling appears as event_handling, keyboard, joystick and raw_input, which tells you the library distinguishes a high level event queue from a lower level raw path rather than offering only one input mechanism. Drawing appears as opengl, shader and stencil, so shader compilation and stencil buffer work are part of the supported surface rather than afterthoughts. Audio splits into sound, sound_capture, sound_device and sound_effects, which is a distinction that matters only if you are wiring a game audio pipeline.

The network samples are the most informative group, because they go well above raw sockets: sockets sits next to ftp, http and sftp. That tells you the network module reaches those three protocols rather than leaving you to implement them, and the presence of libssh2 in the dependency list is consistent with the sftp sample. Platform coverage is visible too, with dedicated X11, android and cocoa directories, so the windowing layer has platform specific paths rather than one portable abstraction pretending differences do not exist. There is also examples/projects for longer samples and an examples/island program.

Two limits travel with all of this. No feature matrix exists anywhere in the project that maps capabilities to versions, so nothing here tells you whether a given sample still reflects 3.1.0 or predates the 2.x transition. And examples/asset_licenses.md exists, which tells you the sample assets carry licenses tracked separately from the zlib terms on the code. If you lift a file from examples/assets into a product, its terms are not SFML's, and that file is the place to check.

A maintenance project, not a growing one, with contribution rules kept out of the repository docs

Reading the project as an organisation rather than a library, the signs point to a mature codebase in maintenance mode rather than one expanding its surface. The two authors named first are Laurent Gomila and Marco Antognini, followed by a long list of named contributors and then a collective entry for many other members of the SFML community. Three community channels are published, a Discord invite, a Twitter account, and forums in English and French. Code quality tooling is configured at the root as well, with .clang-format, .clang-tidy and .editorconfig, and there is a .github directory.

The contribution route is documented but not inline. The project says to file a bug report or submit a patch and points at a contribution guidelines page, and the repository root holds a CONTRIBUTING.md alongside changelog.md. So the process for proposing work exists, and it lives one click away rather than in the file you are reading.

The consequence to weigh before adopting this into a long lived product is about expectations rather than quality. The project promises no support policy for 2.x: there is no end of life date, no stated window for security fixes on the older series, and no promise that a 2.x branch will receive them. It also offers no performance figures of any kind, no benchmark data, and no comparison against competing libraries, which is reasonable for a project of this size and means those numbers have to come from your own measurements. Last push on 2026-11-01 tells you the work is current; it does not tell you what will happen to the branch you are on.

Editorial conclusion

SFML is a reasonable pick for a C++ project that needs a window, drawn frames, sound, and sockets without assembling four separate libraries, and the Zlib license makes shipping it inside a commercial product unremarkable. Steer away if you need a feature matrix, a support policy for 2.x, or a one-command install, because the README provides none of those. Before you commit, decide between a tagged release and the master tree, check which build of FreeType and Mbed TLS your binary actually links given that both list a GPL option, and read migration.md in full if you are coming from 2.x.

Frequently asked questions

Official sources

1. License: Zlib
2. Project website
3. README
4. Releases
5. SFML/SFML on GitHub