Every license in this binder is a promise about code, but the code does not maintain itself. Underneath each text is a person, or a small group, doing the unglamorous work the license does not describe: reviewing patches, answering issues, cutting releases, patching security holes at midnight. The licensing debate talks about rights and models; the quieter crisis underneath is about labor.

The binder keeps a sheet for the maintainers because every argument about sustainable licensing is really an argument about whether the people doing the work can keep doing it. The unglamorous version of that labor is visible wherever business software is kept alive, from the weekend maintainer to an IT support portal billing the same kind of hours openly.

The labor the license does not mention

A license grants rights to use the code. It says nothing about who fixes it. Maintenance is the continuous labor of keeping software alive against a moving world: new operating systems, new dependencies, new attacks. Nadia Eghbal's 2016 report for the Ford Foundation, Roads and Bridges, named the problem plainly: digital infrastructure runs on the volunteer work of people nobody pays, the way public roads run on maintenance budgets nobody sees until the bridge cracks.

The xkcd cartoon of the tower of blocks, all modern digital infrastructure depending on a project maintained by one person in Nebraska, is filed here because it is the most accurate diagram of the problem ever drawn.

The labor is also invisible to the license. Nothing in the GPL or the MIT text distinguishes the person who wrote the code from the person who keeps answering for it ten years later. The maintenance falls on whoever said yes first, and it compounds, because every new user of the code is a new source of questions the maintainer did not agree to answer.

Where the money does not reach

The strange thing about the sustainability debate is that the money exists. Companies build products worth billions on top of maintained code. But the license, especially a permissive one, carries no mechanism for moving any of that money to the person keeping the code. The maintainer pays for the commons with time, then watches the commons be monetized elsewhere. The old contribute-or-pay texts were trying to write that transfer into the license; the modern ecosystem mostly relies on donations, sponsorships, and goodwill, which reach some maintainers and miss most.

The practical, unglamorous side of keeping business software alive is the part the licenses never describe: the labor is real whether or not anyone is billed for it.

Burnout as a licensing issue

Maintainer burnout is usually described as a community problem, but it is also a licensing problem. A license that lets a large user run the code for free, at scale, without ever contributing, concentrates the cost of the commons on the few who maintain it. The relicensing wave of the late 2010s was partly a maintainer story: authors changed the terms not because they had stopped believing in openness, but because the existing terms were being exploited by users who gave nothing back.

When a maintainer burns out, the license does not expire; the project does. The code remains legally open and practically unmaintained, which is a state the licensing texts never anticipated and the ecosystem has no clean name for.

What institutions do about it

The funding models keep changing underneath the argument. Foundations pay some maintainers directly; platforms let users sponsor the people whose code they run; companies hire the maintainers of projects they depend on. Each mechanism helps some people and leaves others outside, which is why the binder treats the labor question as the one the licensing shelf has not finished answering.

The ecosystem has built a few partial answers. Foundations sometimes pay maintainers directly. Platforms built sponsorship channels so users can fund the people whose code they run. Companies hire maintainers of the projects they depend on, which helps the person but leaves the power with the employer. None of these is written into a license, which is why the binder keeps returning to the gap between the text and the labor.

The reader's rule

The lesson the binder keeps is this: a license is a plan for the code, and a project is a plan for the people. Read the license to know what you may do, then read the commit log to know who is doing it, and read the funding to know whether they can keep doing it. The healthiest projects are the ones where the license, the community, and the money all point in the same direction.

The commons as a labor question

Filed in the binder, the maintainer sheet is the one that turns all the others into a human question. The definitions, the models, the record: all of them are, in the end, different answers to who pays for the work of sharing. The texts that ignore the question are the ones that produce the famous cartoon: an enormous tower of licensed code, standing on one person's evening.

The maintainer's position is the binder's standing reminder that a license is a floor, not a ceiling. The text guarantees the code's availability; the community's health decides whether anyone will still be answering for it in ten years. Both are read on the same sheet.

What the text grants

Rights to the code, with no clause that reaches the labor of keeping it alive.

What a reader should check

Who maintains the project, how they are funded, and whether the license lets the beneficiaries contribute back.

The limit of this reading

A binder can name the labor gap; closing it is a funding problem no license has fully solved.