LilyPond: engraving sheet music from a text file

A text file that compiles into engraved pages

LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible, and it brings the aesthetics of traditionally engraved music to computer printouts. The description in the project readme is that it is a text-based music notation program producing elegant, balanced scores whose look was inspired by classical hand-engraving.

Text-based is the whole design decision, and it has consequences that run in both directions. You write a source file describing the notes, and the program typesets it. What you gain is that the source is diffable, reviewable and reproducible, the way a LaTeX document is rather than the way a drawing in a proprietary editor is. What you give up is the direct manipulation of pointing at a staff and hearing a note appear.

The program is cross-platform, and it is flexible because of an extension system written in the Scheme programming language. That extension system is the piece that distinguishes it from a notation program you simply use. Scheme lets a user define new notation commands and new output behaviour, and the repository layout shows the depth of that commitment, with an scm/ directory of Scheme sources and a ly/ directory of LilyPond's own input language definitions, alongside the C++ engine in lily/.

The project is free software and part of the GNU Project, with the primary website at lilypond.org, the manuals online at lilypond.org/manuals, and the downloads page at lilypond.org/download.html.

So the audience is a person who already thinks in notation and wants the output to look professionally engraved, and is prepared to learn a text format and, if they want to go further, Scheme.

This repository is a mirror, and the real work happens on GitLab

The project description is one sentence and it changes what this repository is for. It is just a mirror of the GNU LilyPond repository, and anyone who wants to contribute is pointed at the development page on lilypond.org.

The readme then lists where everything actually lives. The main website is lilypond.org, downloads are at lilypond.org/download.html, and the documentation is at lilypond.org/manuals. The official repository is on Savannah, at savannah.gnu.org/projects/lilypond, while the development repository and the issue tracker are on GitLab at gitlab.com/lilypond/lilypond. Mailing lists are at lilypond.org/contact, and the Contributor's Guide is at the documentation path under doc/latest/Documentation/contributor.

That split is a deliberate distribution arrangement rather than an accident of history. Savannah is where the GNU project hosts the authoritative archive, and GitLab is where day-to-day development and issue triage happen. If you want to file a bug, the issue tracker is the GitLab one, not this mirror.

The repository tree confirms the breadth of the project. Beyond the engine in lily/ and the Scheme sources in scm/, there is a Documentation/ directory for the manuals, input/ and lily/ for the input language, mf/ and ps/ for output backends, a po/ directory for translations, elisp/ and vim/ for editor integration, python/ and scripts/ for tooling, a docker/ directory, a release/ directory, and the usual autotools scaffolding in configure.ac, aclocal.m4, autogen.sh, config.make.in and GNUmakefile.in.

Two files in the tree are worth pointing at for anyone deciding whether to depend on this. AGENTS.md and a .agents/ directory sit at the root, which tells you the project has explicit instructions for coding agents working in the tree, and there is a ROADMAP file plus a VERSION file, so both the current version and the intended direction are recorded in the repository rather than only in a discussion somewhere.

Binaries first, and how to tell a stable release from a development one

Building and installing is a short section in the readme, and its shortness is the guidance. Binaries are available from the download page, and for compiling LilyPond yourself the readme points to the Compiling chapter in the Contributor's Guide rather than duplicating the instructions.

That is a reasonable division of labour for a project of this size, and it is also a practical instruction: take a binary unless you have a specific reason not to. A from-source build of an autotools C++ project with a Scheme runtime, a font toolchain and documentation generation is not a weekend activity for most people, and the readme does not pretend otherwise.

The versioning scheme is the other piece of guidance, and it is the kind of detail that saves an hour of confusion. In a version x.y.z, an even second number y denotes a stable version, and for development versions y is odd. The release list in the repository bears that out, with v2.26.0 from 2026-04-21 and v2.24.4 from 2024-12-15, both of which have an even second number, and the current tagged state being a 2.26 series.

So when you read a LilyPond version number anywhere, the second digit tells you whether you are looking at a release you can rely on or at something in motion. The recent history also shows a long gap between 2.24.4 in December 2024 and 2.26.0 in April 2026, which tells you releases are not on a fixed schedule.

The documentation follows the same split between online and local. The manuals can be read online at lilypond.org/manuals, and they can also be built locally by following the instructions for generating the documentation in the Contributor's Guide.

The licensing picture is more than one file

The repository listing contains four licence-related files at the root: COPYING, COPYING.FDL, LICENSE and LICENSE.OFL, and the project description records the licence as one that GitHub cannot classify as a standard one. That is worth pausing on for a project that outputs fonts and documentation alongside the engraver itself.

The set of files is the tell. A single COPYING file is what a project with one licence looks like. Here there is a separate file for the documentation, one with an FDL suffix, and one with an OFL suffix, and the presence of an OFL file alongside a font directory in the tree is a strong indication that the bundled fonts are covered by the Open Font License rather than by whatever governs the code. OFL is the licence that requires the font itself to remain freely redistributable, and it is the usual choice for a project that ships its own typeface.

What this means practically is that a deployment of LilyPond is not a single artefact with a single licence, and a compliance review has to look at more than the top-level file. The project describes itself simply as free software and part of the GNU Project, and the readme does not summarise the terms, so the files themselves are the place to read. Without going further than the filenames and the project statement, the reasonable conclusion is that the code, the documentation and the fonts are under different terms and should be checked separately.

For most users of the binaries none of this matters. For an organisation redistributing LilyPond, or embedding its fonts in a product, it does.

Where LilyPond is the wrong tool

The first limitation is the one the text-based design implies. There is no graphical score editor, no mouse-driven note entry and no WYSIWYG preview of a page as you type. A composer who thinks in terms of a staff and a cursor will find the file-based approach slower at the start, however good the output looks at the end. LilyPond is for the person who is happy describing music as data, which is how most people who end up using it permanently are.

The second is that it does not read scanned or photographed scores. It is an engraver, not an optical music recognition system, and there is no path from an image of a page to typeset output.

The third is the cost of compiling. If your reason for looking at the source is to build a specific version for a specific platform, the readme sends you to a chapter of the Contributor's Guide rather than to a quickstart, and the tree shows what you are signing up for: autotools, a Scheme implementation, a Python directory, translation catalogues, documentation in several formats, editor modes for Emacs and Vim, and a docker/ directory. It is a project with a long history and a wide surface, and a custom build is a maintenance commitment rather than a one-off task.

The fourth is the governance and hosting arrangement. The project is run by volunteers, and the readme points contributors at the lilypond-devel mailing list rather than at a code of conduct or a review process document. For a project with this much history, understanding how a patch is reviewed means asking on a mailing list, and reading the mailing list archives is how you learn what happened to a proposal from two years ago.

The fifth is the mirror question itself. This repository is not where releases are cut and not where the issue tracker lives, so if you are evaluating LilyPond as a dependency, evaluate the GitLab repository and the download page, and treat this one as a convenient read-only copy.

Support that runs through mailing lists

Support is organised around the [email protected] mailing list, described as the primary place for users to help each other. The contact page carries the subscription and archive information, and the readme notes that mailing lists in other languages are referenced there too.

For a GNU project of this age, mailing lists are not an anachronism but the actual support channel, and there is a reason for it beyond habit. A question about a notation command that produces an unexpected result is answered best by someone who has already hit it, and the answer accumulates in a searchable archive rather than in a closed issue tracker. The trade-off is discoverability: a modern search engine will not surface a thread from 2011 as readily as a GitHub discussion, so you need to know to look at the archives.

Contributors are routed to a different list, [email protected], and the project says outright that it is run by volunteers. The Contributor's Guide is the document that helps you get started, and the same guide holds the compiling instructions and the documentation generation instructions referenced elsewhere in the readme.

There is also a DEDICATION file in the repository root, which is a LilyPond-specific artefact. The project keeps the file listing, the acknowledgements and the licensing in the tree itself, which is what a project that has been running for decades looks like: the institutional memory is in the repository, and a new contributor is expected to read it.

Editorial conclusion

LilyPond fits a composer, a music theorist or an academic who wants notation that is a text file, reviewable in a diff and reproducible on another machine, and the Scheme extension system is what lets a workflow add its own notation commands rather than living with the built-in set. It is the wrong choice if you want an interactive score editor, if you need to engrave photos of existing music, or if a self-hosted GNU infrastructure project is not something you want to depend on. Before adopting it, download a binary from lilypond.org/download.html rather than building from this mirror, read the versioning rule that an even second number means a stable release and an odd one a development release, and note that the last push here was on 2026-10-20 while the newest tag is v2.26.0 from 2026-04-21, so this mirror is where development happens rather than where releases are cut.

Frequently asked questions

Official sources

1. Issues
2. lilypond/lilypond on GitHub
3. README
4. Releases