TagLib ships two licence files and explains only one of them

Two licence files, two links, and one sentence of guidance

The licence story is stated three ways and does not line up neatly. The project's licence field records the LGPL at version 2.1. The README says it is distributed under both the Lesser General Public License and the Mozilla Public License, and the root carries COPYING.LGPL and COPYING.MPL side by side, which is how a per-file dual licence is normally expressed. The two links point at different things: the LGPL link is unversioned while the MPL link names version 1.1 explicitly. The guidance that follows describes only one obligation, that the library may be used in proprietary applications but changes must be contributed back. The MPL half carries its own condition for modified files, and the README does not restate it, so the one-paragraph summary covers the LGPL case alone.

Three metadata containers, and more than twenty file formats

TagLib separates containers from files, and the README lists them separately. The metadata containers are three: ID3v1, ID3v2 and Vorbis comments. The file formats that carry them are a much longer list: MP3, MP4, AAC, Ogg, Opus, FLAC, Speex, APE, MPC, WavPack, WAV, AIFF, TrueAudio, Matroska, WebM, ASF, WMA, DSF and DFF, plus a tracker group of MOD, XM, S3M and IT. Counting the tracker files individually gives twenty-three named types. That breadth is the practical argument for the library, since the containers are few but the containers that appeared in a given decade are not, and a parser written for one generation of files will not open the next.

The first release of a patch line has no patch number in its tag

Three releases are visible in the history. TagLib 2.3 was published on 11 May 2026, TagLib 2.3.1 on 20 July 2026, and TagLib 2.3.2 on 5 September 2026. The tag names are v2.3, v2.3.1 and v2.3.2, so the first release of the line is tagged without the patch component that the following two carry, even though all three release titles are written out in full. For a library that downstream builds commonly pin by tag, a three-part scheme that starts as two parts is the kind of detail that breaks a script written against the later releases. The branch itself was pushed on 2 October 2026, so the newest tag is a month old.

CMake generates four different configuration files for four consumers

The build is driven by CMake, and the interesting part is how much output it produces for other tools to consume. There is a taglib-config.cmake file with its own template, a pkg-config template that produces a taglib.pc.cmake file, and a separate cmd variant of the config for Windows command shells, which is how a native Windows toolchain would find the library at all. Alongside them sit config.h.cmake for the compiled header, a Doxyfile.cmake for documentation, a ConfigureChecks.cmake for feature detection, and a template for generating an uninstall script. A consumer therefore has four different ways of learning where the library is, and the one that works depends on the build system rather than on the library.

The examples include a C reader and a Matroska pair

The examples directory carries eight files and a CMake file, and the list is more informative about the API surface than a feature list would be. There is a tag reader and a tag writer in C++, and a second reader written in C, which shows that a C interface is supported alongside the C++ one for callers who are not writing C++. Three files are format specific: a Matroska reader, a Matroska writer, and a frame list tool. One is a maintenance utility, strip-id3v1.cpp, whose only purpose is removing the older container from files that carry both. So the examples cover reading, writing, the language boundary, one container family in depth, and one migration path.

Third-party code arrives through submodules under 3rdparty

The root carries a .gitmodules file and a 3rdparty directory, which together mean the build expects dependencies to be checked out as submodules rather than fetched by the build system. A fresh clone therefore does not contain everything needed to compile until those submodules are initialised, and nothing in the short README mentions it. The rest of the tree is ordinary for a long-lived C++ project: a CHANGELOG, an AUTHORS file, an INSTALL document, a doxygen directory, a tests directory, a bindings directory for other languages, and formatting configuration through an .astylerc and an .editorconfig. The default branch is master rather than main, and the project address is written with plain http while every format reference link in the README is https.

Editorial conclusion

TagLib suits a project that needs to read or write tags in files from several decades of audio formats and would rather link a library than parse containers itself, with the Matroska and DSD paths covered alongside the common ones. Two things to settle before you adopt it. The licensing is per file, with one directory covered by the LGPL and another by the MPL, and the single sentence of guidance in the README describes only the contribute-back half of that, so read both licence files for the files you actually link. And the build is a CMake project whose generated configuration differs by consumer, including a separate file for Windows command shells and a pkg-config file, so check that the package you generate matches how your build system discovers libraries.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes