Books You Are Allowed to Read Aloud

Two Notes About One Book

On the 1st of March 2026, 2 notes went in within a minute of each other, both about the same project and both slightly wistful.

Consider what other books are available on GitHub that we could read and use for the PärPod book project. The curl one is really good.

The second note asked something odder. Whether the curl book should be forked from the original repository. Whether that might be a fun thing to do. The note is honest about not knowing what the fork would be for, and files it as worth looking into.

Both notes assume the hard part is finding good books. It is not. There are thousands of freely readable technical books sitting in public repositories, many of them excellent, and a well-known catalogue of them has been maintained for years.

The hard part is that almost none of them may legally be turned into audio and published, and the one that started this whole thing is a rare and specific exception for a reason nobody would guess.

The Man In Stockholm

Start with the book that prompted the note, because its situation explains everything else.

Daniel Stenberg founded the curl project. If you have ever used the internet, you have used his software, whether or not you know it. It sits inside cars, televisions, phones, printers, games consoles, and an enormous share of the world's servers. He has said the number of installations runs into the billions. He lives and works in Stockholm.

At some point he decided the project needed a proper book. Not reference documentation, which existed, but the thing documentation never is: an account of what the project is, how it came to be, why it works the way it does, how development actually happens, and what it takes to use the thing well. He wrote it in the open, in a public repository, in plain markdown, and he invited corrections. The credits list runs to well over a hundred contributors who reported errors or improved sections.

The book is rendered from that markdown into a website, and also into portable document and electronic book formats, by a documentation tool that the project switched to in March 2024. The whole thing is a pipeline: text files in a repository go in, a book comes out. Which, incidentally, is exactly the shape a text-to-speech project wants, and one of the quiet reasons that book was easy to work with in the first place.

And then there is the licence.

The Accident That Made It Possible

The book carries the same licence as the software it documents, which is a variant of one of the most permissive licences in common use. It grants permission to use, copy, modify, and distribute the work for any purpose, with or without a fee, provided the copyright notice travels with it. The project's own explanation of what this means in practice is refreshingly blunt: you may change it, redistribute it, build proprietary things on it, and nobody can require you to give your changes back. The one thing you may not do is claim you wrote it.

The project arrived at that licence by wandering. They started under a strong copyleft licence, tried another, and settled where they are now. That wandering happened for reasons entirely to do with software distribution, decades before anyone thought about narration.

But the book inherited it. And so a book about a command-line tool ended up under a licence that permits commercial audio adaptation, translation, remixing, and republication, with attribution, no permission required.

That is extremely unusual, and it happened because the book was treated as part of the project rather than as a publication. Nobody sat down and decided to permit audiobooks. They decided the book was part of curl, and curl's licence came along for the ride.

The Licence Is The Whole Question

Now the general case, which is where the first note's assumption falls apart.

Turning a book into a podcast episode is 2 legally distinct acts. It is the creation of a derivative work, because you have adapted the text into a new form. And it is a public performance and distribution of that adaptation. Both of those are rights the author holds by default, and both must be granted explicitly before you may do it.

"Free to read" grants neither. A book can be readable by anyone, hosted publicly, welcoming pull requests, and still be a work you have no right to narrate. Readability is not permission. The repository being public is not permission. The author being generous is not permission. Only the licence file is permission.

And the licences that free books actually carry vary enormously, in ways that matter completely for this specific purpose and barely at all for reading.

The Non-Commercial Trap

Take the most famous free technical book of all: the standard book on version control, written by 2 authors, published by a real publisher, and given away in full on the web in many languages.

Its licence permits attribution, requires derivative works to carry the same licence, and forbids commercial use.

That last clause is where it gets uncomfortable, because commercial use is not as clearly bounded as people assume. A podcast with no advertising, published for free, listened to by 3 people, is plainly non-commercial. A podcast on a feed run by a business, that mentions the business, and which was noted in a capture inbox alongside a separate spark about testing advertising units, is considerably less plain. The clause does not have a bright line, and licences without bright lines are licences you end up guessing about, which is a poor position to build a series on.

The share-alike part has its own consequence that is easy to miss. If you produce an adaptation, the adaptation must carry the same licence. Your audio, your edit, your narration choices, the script you wrote to compress 40 pages into 20 minutes: all of it goes out under the same terms, including the non-commercial restriction, which now attaches to your work as well.

None of that makes the book unusable. It makes the book usable under conditions, and those conditions need deciding before recording rather than after publication.

The No-Derivatives Wall

There is a stricter clause that appears on a surprising number of freely available books, and it ends the conversation entirely.

A no-derivatives clause permits you to copy and share the work verbatim, and forbids you from adapting it. Not "forbids commercial adaptation". Forbids adaptation. A narrated version, an abridgement, a summary, a translation, a version reorganised into chapters that suit listening: all of those are adaptations, and all of them are outside the grant.

You can find that clause on well-loved books whose authors would probably be delighted to hear them narrated. That does not help. The licence is what governs, and the polite path when you find one is to ask the author directly, which works more often than people expect and costs one email.

There is also a category that catches people out because it looks like open licensing but is not licensing at all. Some books are simply published online at the author's pleasure, with a copyright notice and no licence file. The code samples might be permissively licensed while the prose is not. Reading it is free. Everything else is reserved. The absence of a licence is not permissiveness. It is the default, and the default is that you may not.

What A Fork Would Actually Be

The second note asked about forking the curl book, and it is worth answering plainly because the answer is more interesting than the question.

Mechanically, forking a public repository is one click and costs nothing. It creates a copy under your own name that you may change freely. Under a permissive licence, you may then do more or less whatever you like with the result, including publishing it and charging for it, so long as the original notice stays attached.

Socially, forking a healthy, actively maintained project without an intention to diverge is a slightly strange gesture. A fork says: I intend to go a different way. If what you actually mean is "I want to fix a typo" or "I want to add a chapter", the path is a pull request, and that path is explicitly invited. The book's contributor list is long precisely because that door is open.

But there is a version of the fork that makes complete sense, and it is not a fork of the book. It is a fork for a different output.

The book is markdown files rendered by a documentation tool into a website and a couple of document formats. An audio version needs a different transformation of the same source: chapters restructured for listening, code sections replaced with spoken descriptions, cross-references removed because a listener cannot follow them, and length adjusted so a chapter is an episode rather than a page count. That is not an edit to the book. That is a second renderer for the same source.

Keeping that as a fork means every upstream correction has to be pulled in by hand forever. Keeping it as a separate project that reads the original as an input means upstream stays upstream, and the audio pipeline benefits automatically when 40 more contributors fix 40 more errors. Same result on day one. Very different situation on day 400.

What Makes A Book Work Out Loud

Licence aside, the note said the curl book is really good, and it is worth being precise about why, because that quality is rarer than it seems and it determines which other books are worth the effort.

Most technical books are reference works with a narrative varnish. They are organised for looking things up, which means they are organised as a hierarchy of topics, and a hierarchy read aloud in order is unbearable. There is no tension, no sequence, no reason for chapter 4 to follow chapter 3 other than alphabetisation of concepts.

The books that survive narration have a spine. Something happened, in an order, to people, and the technical content is attached to that. The curl book has a project history, a founder with opinions, a set of decisions that were made under pressure and can be explained, and an enormous amount of accumulated argument about how open source actually works when it is 25 years old and running on 20 billion devices. That is a story with software in it, not software with anecdotes in it.

So the test for a candidate book is not "is it good" and not even "is it well written". It is: does it contain decisions. Does someone in this book choose something, for reasons, and could the reasons be wrong. A book full of decisions can be narrated. A book full of definitions cannot, no matter how excellent the definitions are.

That test rules out most reference manuals, most language tutorials, and most of the very large catalogues of free programming books, which are mostly instructional rather than narrative. It rules in project histories, retrospectives, protocol design documents that explain their own arguments, and the small genre of books where a maintainer explains what maintaining actually costs.

The Practical Order Of Operations

Which produces a workflow, and it inverts what the note assumed.

Do not start by looking for good books and then checking licences. Start with the licence filter, because it eliminates most of the field in an afternoon and it eliminates it definitively. Look for the licence file. Establish whether adaptation is permitted, whether commercial use is permitted, and whether share-alike attaches. Sort the results into three piles: freely adaptable, adaptable with conditions, and off limits without an email.

Only then apply the quality test, on the surviving pile.

And when the good pile turns out to be small, which it will, remember that the email works. Authors of freely published technical books are, as a group, unusually reachable and unusually pleased that someone wants to do something with their work. A specific request, describing exactly what you intend to make and where it will be published, gets a yes far more often than silence. The 2 things that get ignored are vague requests and requests that have obviously not read the existing licence.

The Series That Should Exist

There is a version of this project that sidesteps the entire licensing problem, and it may be better than the original idea.

The books are not the only artefact. Every one of these projects has a public history: the issues, the arguments, the pull request where a decision got made, the mailing list thread from 2009 where somebody proposed the thing that is now in a billion devices. All of that is factual record, and reporting on it, describing it, and quoting small pieces of it with attribution is ordinary journalism, not adaptation.

A series about how a piece of software came to be, built from its own public record, is not a derivative work of anything. It requires no licence. It cannot be revoked. And it is, in most cases, a better listen than the book, because the book was written after the fact with the messiness edited out, and the record still has the messiness in it.

The book tells you what was decided. The repository tells you what it cost.

Which leaves 2 clean paths out of a note that has sat for 6 months. Narrate the curl book, because the licence genuinely permits it and the book genuinely deserves it, and do it as a separate renderer reading the original rather than as a fork that will rot. And for everything else, stop asking permission to adapt books and start reporting on projects, where no permission was ever required.