Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

581–590 of 913 posts

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

#581

Post by spookie »

KingMob wrote: post #542
LexiMax wrote: post #307

Earlier quoted context omitted.

I always like to point out that "Open Source" was a deliberate watering-down of the moralizing messaging of Free Software to try and sell businesses on the benefits of developing software in the open. > We realized it was time to dump the confrontational attitude that has been associated with "free software" in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. h…

I like FS, but it's always had kind of nebulous morality, though. It lumps in humans with companies, which cannot have morals, under the blanket term "users". This is the same tortured logic as Citizens United and Santa Clara Co vs Southern Pacific Railroad, but applied to FS freedoms instead of corporate personhood and the 1st Amendment. I like the FS' freedoms, but I favor economic justice more, and existing FS lic…

Agree in some ways. Still, discussing the nitty gritty is superfluous, the important underlying message you are making is more existential.

Open source software is critical infrastructure at this point. Maintainers should be helped out, at least by their largest users. If free riding continues, and maintainers' burden becomes too large, supply chain attacks are bound to happen.

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

#582

Post by tpmoney »

bigiain wrote: post #507
tpmoney wrote: post #346

Earlier quoted context omitted.

I get that the ffmpeg people have limited time and resources, I get that it would be nice if Google (or literally anyone else) patched this themselves and submitted that upstream. But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. If this is so obscure of a bug that there's no real risk, then there's no need for anyone to worry that the bug has been report…

> But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. Is that somehow _less_ of a terrible way to think than "someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company"? > it really needs to b…

> someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company

If you could highlight the relevant part of the bug report that demanded the developers "drop everything" and do "unpaid work for a trillion dollar company", that would be great because I'm having trouble finding it. I see "hey, we found this bug, we found where we think the issue is in the code and here's a minimal reproduction. Also FYI we've sent you this bug report privately, but we will also be filing a public bug report after 90 days." And no, I don't think having a policy of doing a private bug report followed by a public report some time later qualifies as a demand. They could have just made a public report from the get go. They could also have made a private report and then surprised them with a public bug report some arbitrary amount of time later. Giving someone a private heads up before filing a public bug report is a courtesy, not a demand.

And it's really funny to complain about Google expecting "unpaid work for a trillion dollar company", when the maintainers proudly proclaim that the likes of no less than Google ARE paying them for consulting work on ffmpeg[1][2][3]

[1]: https://fflabs.eu [2]: https://fflabs.eu/about/ [3]: https://ffmpeg.org/consulting.html

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

#583

Post by mmooss »

grumbelbart2 wrote: post #555
mmooss wrote: post #550

Earlier quoted context omitted.

Why would they invest resources - scarce, expensive time of attorneys - in researching and solving this problem? The attorneys' job is to help the company profit, to maximize ROI for legal work. Where is the ROI here? And remember, just positive ROI is unacceptable; they want maximum ROI per hour worked. When the CEO asks them how this project maximized ROI, what do they say? I believe in FOSS and can make an argumen…

If you fixed something in an open source library you use, and you don't push that upstream, you are bound to re-apply that patch with every library update you do. And today's compliance rules require you to essentially keep all libraries up to date all the time, or your CVE scanners will light up. So fixing this upstream in the original project has a measurable impact on your "time spent on compliance and updates KPI…

That is a real benefit, I agree.

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

#584

Post by fweimer »

astrange wrote: post #311
zxspectrum1982 wrote: post #77

Earlier quoted context omitted.

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.

ffmpeg cannot relicense anything because it doesn't own anything. The contributors own the license to their code.

They can switch from LGPLv2.1 to GPLv2 or GPLv3 for future development because the license has an explicit provision for that.

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

#585

Post by izacus »

Root_Denied wrote: post #558
rossjudson wrote: post #451

Earlier quoted context omitted.

I'm glad you threw in "I know of", because that part is true. Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.

I'd say as a counterpoint that just because someone works at, say, Meta or Oracle, and also contributes to OSS projects, that doesn't equate to the company they work at funding upstream projects (at least not by itself). I don't even have to link the xkcd comic because everyone already knows which one goes here.

People don't use their company email addresses for private work.

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

#586

Post by izacus »

FridgeSeal wrote: post #493
izacus wrote: post #297

Earlier quoted context omitted.

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.

I'm sure you can as well. I had no issues contributing to ffmpeg under my company payroll before, why not you?

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

#587

Post by samus »

woodruffw wrote: post #10

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…

So what is Google gonna do if security fixes don't happen in time and the project takes a "reputational hit"? Fork it and maintain it themselves? Why not send in patches instead?

Maintaining a reputation might be enough reward for you, but not everyone is happy to work for free for a billion dollars corporation breathing down their necks. It's puzzling to me why people keep defending their free lunch.

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

#588

Post by troupo »

zinekeller wrote: post #402
phkahler wrote: post #283

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?).

Twitch definitely. This whole brouhaha has been brewing for a while, and can be traced back to a spat between Theo and ffmpeg.

In the now deleted tweet Theo thrashed VLC codecs to which ffmpeg replied basically "send patches, but you wouldn't be able to". The reply to which was

--- start quote ---

https://x.com/theo/status/1952441894023389357

You clearly have no idea how much of my history was in ffmpeg. I built a ton of early twitch infra on top of yall.

--- end quote ---

This culminated in Theo offering a 20k bounty to ffmpeg if they remove the people running ffmpeg twitter account. Which prompted a lot of heated discussion.

So when Google Project Zero posted their bug... ffmpeg went understandably ballistic

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

#589

Post by GaryBluto »

Ferret7446 wrote: post #190
justahuman74 wrote: post #171

Earlier quoted context omitted.

Great, they can fix the bugs being filed by another part of their company

So would you rather Google have a secure ffmpeg while us plebian individual users continue to have an insecure ffmpeg?

It's frustrating to me how many people are siding with FFmpeg here considering how unprofessional and generally asshole-ish they are being.

I feel that this is mostly a kneejerk reaction to AI and Google in general, with people coming up with arguments to support their reaction after already forming an opinion.

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

#590

Post by maybewhenthesun »

Aurornis wrote: post #506
skhameneh wrote: post #264

Earlier quoted context omitted.

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…

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate. I’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better. What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount…

While there's sometimes maintainer-prima-donna egos the contend with there's also this:

Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they will not be able to maintain the functionality into the future (because no one on the maintaining team has experience in a certain field, for example).

The quality bar for a 'drive by patch' which is contributed without the promise of future support is ridiculously high and it has to be. Other peoples' code is always harder to maintain than your own so it has to make up for that in quality.

Post reply on HN