Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

491–500 of 913 posts

Re: FFmpeg to Google: Fund us or stop sending bugs

#491

Earlier quoted context omitted.

Are you interpreting that as "if we violate the license, they can revoke our right to use the software" ?? And they use it in 3 products so that would be really bad. That would make sense to have a compliance person.

Possibly Twitch, Amazon Prime Video, and another one that escapes my mind (AWS-related?).

And Blink. I used to contract with them a few years back, they all rely heavily on open source.

Re: FFmpeg to Google: Fund us or stop sending bugs

#492
post #372

Earlier quoted context omitted.

> Valve is the only company I know of [upstreaming fixes for open source software] Sorry, that's ridiculous. Basically every major free software dependency of every major platform or application is maintained by people on the payroll of one or another tech giant (edit: or an entity like LF or Linaro funded by the giants, or in a smaller handful of cases a foundation like the FSF with reasonably deep industry funding)…

From my time working at a Fortune 100 company, if I ever mentioned pushing even small patches to libraries we effing used , I'd just be met "try to focus on your tickets". Their OSS library and policies were also super byzantine, seemingly needing review of everything you'd release, but the few times I tried to do it the official way, I just never heard anything back from the black-hole mailing list you were supposed…

To steelman this: I've never worked at any of the companies you listed but most likely Red Hat and IBM employees (Is there still a difference?) are being paid specifically to work on Openstack, as they get money from support contracts. When Walmart of Chase use Openstack there is a rather small team who is implementing openstack to be used as a platform. They are then paying IBM/Redhat for that support. There probably isn't really the expertise in the Openstack team at Warlmart to be adding patches. Some companies spend a different amount of money on in house technology than others, and then open source it.

Re: FFmpeg to Google: Fund us or stop sending bugs

#493
post #297

Earlier quoted context omitted.

Unfortunately, nobody not on Twitter can see anything except the first message, which just appears to be some corporate-deflection-speak. It’s a trillion dollar company. I’m sure they could find rifle through their couch cushions and find more than enough money and under-utilised devs to contribute finance or patches.

Google is one of the largest contributors to OSS in the world, so they're already throwing literal millions at OSS?

I’m sure they can take a moment of their _busy schedules_ to send a patch then.

Especially if they’ve just spent all this cash on some ai tool.

Re: FFmpeg to Google: Fund us or stop sending bugs

#494

Earlier quoted context omitted.

Possibly Twitch, Amazon Prime Video, and another one that escapes my mind (AWS-related?).

AWS for sure (Elemental maybe?), but could also be Ring.

Yeah - Amazon Elastic Transcoder which they just shut down and replaced with Elemental MediaConvert is almost certainly just managed "ffmpeg as a Service" under the hood.

Re: FFmpeg to Google: Fund us or stop sending bugs

#495

I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes per…

The issue at hand is that Google has a policy of making the security issue public regardless of whether a fix has been produced.

Typically disclosures happen after a fix exists.

Re: FFmpeg to Google: Fund us or stop sending bugs

#496
post #458

Earlier quoted context omitted.

I saw that tweet and thought it looked crazy. To me, it sounds like a death threat. Especially given that it's posted on X.com, after a really heated argument, with no clarification afterwards. If you didn't actually post that tweet, that's great! I'm happy to be corrected

If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.

It's not a rumor, you literally wrote that on X. The average person would understand it as a threat.

Re: FFmpeg to Google: Fund us or stop sending bugs

#497
post #489

Earlier quoted context omitted.

To be clear, what does relicensing to AGPL do here? Does the AGPL include licensing terms that forbid filing bug reports without also including code patches? Or does it just make ffmpeg that much less appealing to projects and cut off the steady stream of contributions that it has gotten from google since 2009? https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?pg=3;s=...

AGPL is banned from many BigCorps IIRC.

Right, but how is that a benefit here? The bug report was a valid report, ffmpeg is objectively better for it having been filed. Google contributes to ffmpeg on a regular basis according to the git history. They also buy consulting services from the ffmpeg maintainers according to the maintainer's own website. If ffmpeg was banned from Google, all of that would probably stop.

So not only would ffmpeg have multiple uncovered vulnerabilities, they would have less contributions and patches and less money for funding the maintainers. And for what? To satisfy the unfocused and mistaken rage of the peanut gallery online?

Re: FFmpeg to Google: Fund us or stop sending bugs

#498

Earlier quoted context omitted.

Here's the question: Why is Google deliberately running an AI process to find these bugs if they're just going to dump them all on the FFmpeg team to fix? They have the option to pay someone to fix them. They also have the option to not spend resources finding the bugs in the first place. If they think these are so damn important to find that it's worth devoting those resources to, then they can damn well pay for fix…

I would love to see Google contribute here, but I think that's a different issue. Are the bug reports accurate? If so, then they are contributing just as if I found them and sent a bug report, I'd be contributing. Of course a PR that fixes the bug is much better than just a report, but reports have value, too. The alternative is to leave it unfound, which is not a better alternative in my opinion. It's still there an…

The actual real alternative is that the ffmpeg maintainers quit, just like the libxml2 maintainer did.

A lot of these core pieces of infrastructure are maintained by one to three middle-aged engineers in their free time, for nothing. Meanwhile, billion dollar companies use the software everywhere, and often give nothing back except bug reports and occasional license violations.

I mean, I love "responsible disclosure." But the only result of billion dollar corporations drowning a couple of unpaid engineers in bug reports is that the engineers will walk away and leave the code 100% unmaintained.

And yeah, part of the problem here is that C-based data parsers and codecs are almost always horrendously insecure. We could rewrite it all in Rust (and I have in fact rewritten one obscure codec in Rust) or WUFFS. But again, who's going to pay for that?

Re: FFmpeg to Google: Fund us or stop sending bugs

#499

Earlier quoted context omitted.

There should be a "if you use this product in a for-profit environment, and you have a yearly revenue of $500,000,000,000+ ... you can afford to pay X * 100,000/yr" license.

That's the Llama license and yeah, a lot of people prefer this approach, but many don't consider it open source. I don't either. In fact, we are probably just really lucky that some early programmers were kooky believers in the free software philosophy. Thank God for them. So much of what I do owes to the resulting ecosystem that was built back then.

I reckon this is an impedance mismatch between "Open Source Advocacy" and Open Source as a programming hobby/lifestyle/itch-to-scratch that drives people to write and release code as Open Source (of whatever flavour they choose, even if FSS and/or OSF don't consider that license to qualify as "Open Source").

I think Stallmann's ideological "allowing users to run, modify, and share the software without restrictions" stance is good, but I think for me at least that should apply to "users" as human persons, and doesn't necessarily apply to "corporate personhood" and other non-human "users". I don't see a good way to make that distinction work in practice, but I think it's something that if going to become more and more problematic as time goes on, and LLM slop contributions and bug reports somehow feed into this too.

I was watching MongoDB and Redis Labs experiments with non-OSF approved licences clearly targeted at AWS "abusing" those projects, but sadly neither of those cases seemed to work out in the long term. Also sadly, I do not have any suggestions of how to help...

Re: FFmpeg to Google: Fund us or stop sending bugs

#500
post #472

Earlier quoted context omitted.

But FFmpeg does not have the resources to fix these at the speed Google is finding them. It's just not possible. So Google is dedicating resources to finding these bugs and feeding them to bad actors. Bad actors who might, hypothetically have had the information before, but definitely do once Google publicizes them. You are talking about an ideal situation; we are talking about a real situation that is happening in t…

If widely deployed infrastructure software is so full of vulnerabilities that its maintainers can't fix them as fast as they're found, maybe it shouldn't be widely deployed, or they shouldn't be its maintainers. Disabling codecs in the default build that haven't been used in 30 years might be a good move, for example. Either way, users need to know about the vulnerabilities. That way, they can make an informed tradeo…

> they shouldn't be its maintainers.

I mean, yes, the ffmpeg maintainers are very likely to decide this on their own, abandoning the project entirely. This is already happening for quite a few core open source projects that are used by multiple billion-dollar companies and deployed to billions of users.

A lot of the projects probably should be retired and rewritten in safer system languages. But rewriting all of the widely-used projects suffering from these issues would likely cost hundreds of millions of dollars.

The alternative is that maybe some of the billion-dollar companies start making lists of all the software they ship to billions of users, and hire some paid maintainers through the Linux or Apache Foundations.

Post reply on HN