311–320 of 913 posts
Earlier quoted context omitted.
How could ffmpeg maintainers kill three major AWS product lines with an email?
Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.
Open source projects want people to use their work. Google wants bugs -- especially security ones -- found and fixed fast. Both goals make sense. The tension starts when open source developers expect payment for fixes, and corporations like Google expect fixes for free.
Paying for bug fixes sounds fair, but it risks turning incentives upside down. If security reports start paying the bills, some maintainers might quietly hope for more vulnerabilities to patch. That's a dangerous feedback loop.
On the other hand, Google funding open source directly isn't automatically better. Money always comes with strings. Funding lets Google nudge project priorities, intentionally or not -- and suddenly the "open" ecosystem starts bending toward corporate interests.
There's no neat solution. Software wants to be used. Bugs want to be found and fixed. But good faith and shared responsibility are supposed to be the glue that holds the open source world together.
Maybe the simplest fix right now is cultural, not technical: fewer arguments on Twitter, more collaboration, and more gratitude. If you rely on open source, donate to the maintainers who make your life easier. The ecosystem stays healthy when we feed it, not when we fight over it.
I would suggest that FFmpeg spin up a commercial arm that gets support contracts with Google, Amazon, etc, but with a tight leash so that it does not undermine the open source project. Would need clean guidance as to what the commercial arm does and does not. Probably could pull in millions per year.
Not too fond of maintainers getting too uppity about this stuff. I get that it can be frustrating to receive bug report after bug report from people who are unwilling or unable to contribute to the code base, or at the very least to donate to the team. But the way I see it, a bug report is a bug report, no matter how small or big the bug or the team, it should be addressed. I don’t know, I’m not exactly a pillar of t…
When you already work 40+ hours a week and big companies suddenly start an AI snowblower that shoots a dozen extra hours of work every week at you without doing anything to balance that (like, for instance, also opening PRs with patches that fix the bugs), the relationship starts feeling like being an unpaid employee of their project. What's the point of just showering these things with bug reports when the same tool…
Imagine you're a humble volunteer OSS developer. If a security researcher finds a bug in your code they're going to make up a cute name for it, start a website with a logo, Google is going to give them a million dollar bounty, they're going to go to Defcon and get a prize and I assume go to some kind of secret security people orgy where everyone is dressed like they're in The Matrix.
Nobody is going to do any of this for you when you fix it.
Earlier quoted context omitted.
All the license means is that I can’t sue them. It doesn’t mean I have to like it. Just because software makes no guarantees about being safe doesn’t mean I want it to be unsafe.
If the software makes no guarantees about being safe, then you should assume it is unsafe.
Earlier quoted context omitted.
But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.
Sounds like it would be a lot of churn for nothing; if they can fund a fork, then they could fund the original project, no?
Earlier quoted context omitted.
It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…
It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as t…
From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…
I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…
Earlier quoted context omitted.
My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it. To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’…
> My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it. That is not an accurate description? Project Zero was using a 90 day disclosure policy from the start, so for over a decade. What changed[0] in 2025 is that they disclose earlier than 90 days that there is an issue ,…