There’s a date circled in ffmpeg-wasi’s documentation: 2027-11-29. On that day the last US essential patent in the AVC pool expires, H.264 becomes just another bit of maths in America, and a whole paragraph of careful legal hedging in my docs gets to retire. Until then the LGPL build of ffmpeg-wasi ships an encoder that exists on sufferance. And if you’re going to ship something on those terms, you say so. Out loud, prominently, with the date attached.

This is the story of the most-requested capability in any media toolkit (making mp4s people can actually play) and what it costs to offer it in a permissively-licensed build.

Decode was never the gap

The two-variant scheme gives ffmpeg-wasi an LGPL floor and a GPL full-fat build. From day one the LGPL floor could decode H.264; FFmpeg’s own decoder carries no GPL strings. The gap was encode. FFmpeg’s blessed H.264 encoder is x264, and x264 is GPL: enable it and the whole artifact graduates to the GPL variant. So the LGPL build, the one a permissively-licensed Go library wants to lean on, could read the world’s videos and write none of them.

Enter openh264, Cisco’s H.264 codec, BSD-2-Clause licensed. Two build flags (--enable-libopenh264 --enable-encoder=libopenh264, no --enable-gpl in sight) and the LGPL artifact encodes H.264. Shipped in n8.1.2-2, in both variants.

If that sounds too easy… it is. The BSD licence was never the hard bit.

Copyright is one umbrella; patents are another

A codec has two legal layers, and they don’t care about each other. The copyright on openh264’s source is Cisco’s to give away, and BSD gives it away. The patents on the H.264 techniques themselves belong to a pool of rights-holders (administered by Via LA), and no source licence in the world can waive them.

Cisco’s famous move was to pay the pool’s royalties on everyone’s behalf… for the binary modules Cisco itself builds and distributes. That grant does not travel with the source code. My docs put it in a red box rather than a footnote: ffmpeg-wasi compiles openh264 from source for wasm32-wasi (Cisco doesn’t publish a wasm binary), so our artifact is not under Cisco’s umbrella. Anyone who tells you “it’s fine, Cisco pays” for a self-compiled openh264 has read the first half of the licence page.

What makes it tenable is duller and more precise, and the licensing docs spell it out: the pool’s terms are royalty-free beneath an annual volume threshold (the first 100,000 units a year), a horizon this project’s expectations sit comfortably under. And the docs make a plain commitment on top: if Via LA or any AVC rights-holder asks us to stop distributing the encoder, we pull it. No fight, no fundraiser. The docs also say, twice, that none of this is legal advice, and neither is this post.

The horse had already bolted

You might ask why I’d take on any of this for the permissive build when the GPL build already existed. The answer is that the patent exposure was already there. Patents don’t read your source licence: an x264 binary practises exactly the same claims as an openh264 one, so the GPL variant had opened whatever door there was to open. Declining to add encode to the LGPL floor wouldn’t have closed it; it would only have kept the safer variant less useful. Same risk either way, and turning encode down would’ve bought me nothing but a less useful build. Call that caution if you like. I’d call it cost with no upside.

So both variants carry the risk, both carry the caveat, and the caveat comes with a date on it. Rather than embed a list of patent numbers that would only rot in place, the docs link Via LA’s maintained roster and state the one fact worth remembering: the final US essential patent lapses on 2027-11-29 (other jurisdictions track a similar horizon). None of this is meant to hold forever. There’s a clock running on it.

Making Cisco’s code believe in WASI

Getting openh264 v2.6.0 to build for wasm32-wasi took a small patch and a shim: a __wasi__ path through its threading library, a single-threaded pthread stand-in compiled into the archive, a hand-written pkg-config file (upstream’s insists on -lstdc++ -lpthread, neither of which exists on wasi)… and one genuinely fun find: a function declared with one signature in C and defined with another in C++, an arity slip native linkers have silently forgiven for years. Wasm’s strict function typing forgave nothing, and trapped on the spot. Which makes the sandbox an accidental linter, catching a bug that had sat there unbothered for years.

A feature with a use-by date

It nets out about as well as this kind of thing can. The LGPL build does the thing everyone actually needs, the risk is written down where you can’t miss it, the escape hatch is pre-committed, and the whole lot comes with a sell-by date, after which there’s nothing left to hedge and it’s back to being maths. Fifteen months on the clock. That red box in the docs is really just a changelog entry with the date left blank.