> However, in 2023, MPEG LA was acquired by Via-LA, and everything changed. When I reached out to Via-LA in late 2024 to confirm FFmpegKit’s position under their terms, I received no response.<p>The real reason. Greedy bastards, and the risk of your business being set on fire by greedy bastards, even if they don't have a right to anything - they can still threaten to waste your time and money and offer a shakedown instead.<p>I've never used FFmpegKit (I've mostly just used the command-line, or indirectly via yt-dlp and Handbrake) but just hearing about it now, the maintainer sounds like an awesome person who really went above and beyond to support free software, so hooray for them! I bet it was useful for thousands of other projects, and those people are all grateful too.
Having dealt with MPEG-LA before, it makes me so wildly angry that a company composed of nothing but lawyers can suck money out of any product that wants to use a widely supported, arguably critical video codec.<p>The process for reporting to them for sales is also horrible. Uploading excel spreadsheets to an ASP.NET backend that's barely holding together. It's minimal effort from them to leverage all possible legal action over you. Horrible.
It seems really strange that a library that wraps FFMpeg is being discontinued due to patent concerns with the underlying codecs, but those codecs are only implemented in FFMpeg itself, which continues along without issues.
<i>"To get clarity, I consulted an IP law firm. Their review raised concerns about potential risks related to licensing and patents. They recommended retiring the project and removing older binaries as the safest option. They did suggest some alternative paths, but those options would have required significant time, effort, and money, neither of which I could commit."</i><p>Thanks to Taner Sener for putting in all the effort! I guess most technical people shudder at the mere thought of dealing with all the legal matters.
I’ve never used FFmpeg-kit—I always use FFmpeg from distro packages (Linux, Homebrew) or build it selectively—so I’m not sure how important it is. Is it just a thin wrapper around the FFmpeg C API for various platforms?<p>If that’s the case, software engineers relying on it should learn how to build FFmpeg from source and handle platform-specific challenges (especially on Android). The loss of the overall community support doesn’t seem that significant, right?<p>That said, whether someone uses FFmpeg-kit or builds FFmpeg manually, the legal risks remain the same. If they don’t understand codec patents (like x264 and MPEG-LA) or GPL/LGPL obligations, they could face lawsuits or be forced to release their code under GPL. The real issue isn’t FFmpeg-kit—it’s whether developers actually understand these legal implications.
Ah, patent rights, when even legality of something can be debatable. How the heck is anyone supposed to follow the law if for every action A they have to ask lawyer if A is legal?
FFMpegKit at <a href="https://github.com/arthenica/ffmpeg-kit">https://github.com/arthenica/ffmpeg-kit</a> is discontinued by the author
<i>Why #1</i>: not enough time and money.<p>The project had become a time sink, I get it. But that's exactly why OSS is a "What You See Is What You Get".<p>Normally I'd encourage any OSS maintainer in this position to just announce their intentions and let the community (as small as it might be) decide to either inherit maintenance and development of the project, or let it languish. I don't see any reason to close the repos so dramatically, depriving potential future readers of reaching the source code and improving upon it, as is the spirit of OSS.<p>The project had also become an actual cost, getting to the point of hiring contractors to make releases and please users (who would most probably have been unwilling to pay for that themselves, as my experience tells me most FOSS users are just freeloaders with no intention at all of supporting the project in any way or means). Well, what can I say, this conversation appears from time to time in HN. OSS maintainers need to have that special kind of ability to say "No" or even "I don't care" because otherwise the project (and its users) tend to absorb the author's attention, goodwill, wallet, and enthusiasm. It's very healthy, as a maintainer, to be able to ruthlessly point to the License file whenever someone complains and even _requires_ attention. The "Provided on an AS-IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND" phrase is wonderful.<p>I understand the author. The feeling of attachment and goodwill, the desire to show the highest attention to detail and quality support for a project is always there. We all experience it. But it's important to remember at all times that OSS is just an act of generosity to the universe, it cannot become a self-induced hell.<p><i>Why #2</i>: legal concerns around potential litigations.<p>Yeah, I know it myself too: distributing FFmpeg binaries can be a legal risk if some codecs were enabled in the build.<p>Still no reason to shut everything down... or is it? My gut instinct for this is to "just" (I know, not a trivial change, but not astronomically complicated either) change to a "provide your own FFmpeg executable, please" model. <i>Then</i>, proceed with abandoning the project, as per the previous point.<p>Or just move everything to an anonymous Chinese Git provider.. and forget about receiving legal threats in there (just half-joking!)
I think contacting patent trolls about anything like their opinion on legal matters about existing projects is a huge mistake. It only gives them the idea whom to shake down (namely you, since you contacted them)! It also probably makes it easier for them to claim that you knew about their patents when they come to shake you down. Don't feed the trolls!
I had never heard of ffmpeg until yesterday. In fact, I just Googled the term because I _still_ wasn't sure what it was beyond a dependency required to utilize a huggingface model I was testing. And now here we are...<p>Farewell FFmpegKit. You will be missed.