News

FFmpeg developer says AI Rust rewrite and MIT relicensing violate copyright

An FFmpeg developer says an AI-assisted Rust port and MIT relicensing cross a copyright line, turning a code rewrite into a licensing fight.

Nina Kowalski··2 min read
Published
Listen to this article0:00 min
Share this article:
FFmpeg developer says AI Rust rewrite and MIT relicensing violate copyright
Source: preview.redd.it

The sharpest question in Rust’s wave of C-to-Rust rewrites is no longer whether an AI can produce usable code, but whether that code can be safely relicensed or pushed upstream without crossing a copyright line. FFmpeg developer Paul Mahol says the answer is no, arguing that an AI rewrite of FFmpeg code into Rust, paired with a switch from LGPL to MIT, violates copyright.

That dispute lands in a project space where licensing details matter as much as compiler output. FFmpeg says most of its codebase is under the GNU Lesser General Public License version 2.1 or later, with some optional parts under GPL. MIT, by contrast, is a permissive license that allows use, copying, modification, and redistribution. The gap between those regimes is exactly what makes an AI port so sensitive: if the new Rust code is built too closely from FFmpeg’s protected expression, the license swap is not just aggressive, it may be legally unstable.

The project at the center of the argument, OxideAV, presents itself as a pure-Rust media transcoding framework with no C dependencies. Its public repositories show a rapid build-out of codec and container crates in spring 2026, including MIT-licensed components, which makes the relicensing question immediate rather than theoretical. One subproject, oxideav-magicyuv, describes itself as a clean-room implementation based on a behavioral trace, with zero C dependencies and no third-party source consulted.

AI-generated illustration
AI-generated illustration

But a closed GitHub issue on that repo complicated that clean-room story. An OxideAV contributor acknowledged that the methodology critique was legitimate, and said the earlier trace document had read FFmpeg source for cross-checks and named FFmpeg internals in its outputs. The same discussion says the project would avoid those cross-references going forward, because the team did not want to relitigate the issue every time someone read the git log. In that thread, the argument also leans on Feist v. Rural and Google v. Oracle to say that public API identifiers and wire-format facts are not copyrightable in the same way as expressive code.

The legal backdrop is still unsettled enough to make maintainers cautious. The U.S. Copyright Office has said AI-assisted creation does not automatically block copyrightability, but its 2025 guidance draws a line around human authorship, including prompts, expressive inputs, and the selection, arrangement, or modification of AI-generated material. That leaves a hard practical question for Rust projects built from automated rewrites: who owns the result, what exactly was copied, and can a permissive license really land on top of code that still smells too much like the original?

Related stock photo
Photo by cottonbro studio

The community reaction around OxideAV has already split between clean-room optimism and infringement alarm, with some commenters calling the method “dirty room” and others treating it as a serious legal overreach. For Rust developers chasing FFmpeg replacement efforts, that is the real warning shot: the technical port may compile, but the licensing and authorship story still has to survive scrutiny.

Know something we missed? Have a correction or additional information?

Submit a Tip

Never miss a story.

Get Rust Programming updates weekly. The top stories delivered to your inbox.

Free forever · Unsubscribe anytime

Discussion

More Rust Programming News