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

691–700 of 913 posts

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

#691

Post by cornonthecobra »

josephg wrote: post #653
cornonthecobra wrote: post #361

Earlier quoted context omitted.

I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability. No, it didn't help giving them copies of licenses that have the usual liability clauses. It seems a lot of corporate lawyers fundamentally misunderstand open source.

I don't know if it would work, but sometimes I consider a "moochers" rule wrt opensource code. Like, here's the deal: The work is proper, legit opensource. You can use it for free, with no obligations. But if your company makes a profit from it, you're expected to either donate money to the project or contribute code back in kind. (Eg security patches, bug fixes, or contribute your own opensource projects to the ecos…

I've spent the last 32 years pushing every employer I've had to contribute back to open source. Because of the sector I work in, more often than not I'm constrained by incredibly tight NDAs.

I can usually stop short of providing code and file a bug that explains the replication case and how to fix it. I've taken patches and upstreamed them pseudonymously on my own time when the employer believed the GPL meant they couldn't own the modifications.

If after all that you still want to label me a moocher at cons, that's your choice.

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

#692

Post by Cthulhu_ »

poulpy123 wrote: post #650
phkahler wrote: post #54

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…

Nothing says solid industry better than having 3 majors product lines from a trillion dollar company depending of unpaid volunteer labor.

I think if you look a bit deeper, all product lines from said trillion dollor company rely on open source to some degree. They should be spending hundreds of millions in sponsorship of OS projects. They should put the maintainers on their payroll. Not even reporting to a manager, just pay them a salary for their OS work.

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

#693

Post by walletdrainer »

Orygin wrote: post #682
walletdrainer wrote: post #625

Earlier quoted context omitted.

Google does do that. This bit of ffmpeg is not a Chrome dependency, and likely isn’t used in internal Google tools either. > Just publishing bug reports by themselves does not make open source projects secure! It does, especially when you first privately report them to the maintainers and give them a plenty of time to fix the bug.

It doesn't if you report lots of "security" issues (like this 25 years old bug) and give too little time to fix them. Nobody is against Google reporting bugs, but they use automatic AI to spam them and then expect a prompt fix. If you can't expect the maintainers to fix the bug before disclosure, then it is a balancing act: Is the bug serious enough that users must be warned and avoid using the software? Will disclos…

The timeline here is pretty long, and Google will provide an extension if you ask.

What do you believe would be an appropriate timeline?

>especially if you consider other security notices that may have a bigger impact.

This is a bug in the default config that is likely to result in RCE, it doesn’t get that much worse than this.

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

#694

Post by Orygin »

dzhiurgis wrote: post #666
profsummergig wrote: post #368

Earlier quoted context omitted.

...every media post on IG/FB/X/YT/news sites/AI.

So does a Siemens transformer, but it's era defining. Why there's such a weird toxic empathy around ffmpeg?

Why do you shit on it? This software is literally holding the near entirety of video transcoding *worldwide* on its shoulders.

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

#695

Post by Orygin »

tpmoney wrote: post #414
Msurrow wrote: post #13

Earlier quoted context omitted.

In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so. Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report. Then everybody wins.

> In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. So when the xz backdoor was discovered, you think it would have been better to sit on that quietly and try to both wrest control of upstream away from the upstream maintainers and wait until all the downstream projects had reverted the changes in their copies before making that public?…

The XZ backdoor is not a bug but a malicious payload inserted by malicious actors. The security vulnerability would immediately been used as it was created by attackers.

This bug is almost certainly too obscure to be found and exploited in the time the fix can be produced by Ffmpeg. On the other hand, this vuln being public so soon means any attacker is now free to develop their exploit before a fix is available.

If Google's goal is security, this vulnerability should only be disclosed after it's fixed or a reasonable time (which, according to ffmpeg dev, 90 days is not enough because they receive too many reports by Google).

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

#696

Post by SR2Z »

xgulfie wrote: post #375
SR2Z wrote: post #299

Earlier quoted context omitted.

Look, I know you're being snarky, but YES. All of the viable open-source video codecs of the past 10 years would not have happened without Google. Not just for technical reasons, but for expensive patent-related legal reasons too. Given that ffmpeg is an open-source video transcoding tool, I don't think you can easily just dismiss this as "big company abuses open source." The ffmpeg devs are volunteers or paid to wor…

I don't think ffmpeg is terribly affected by whether a codec is patent-encumbered or not

It would certainly be a less useful tool if all the videos it produced got you legal threats every time you tried to share them :)

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

#697

Post by loodish »

skrebbel wrote: post #73
phkahler wrote: post #54

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…

How could ffmpeg maintainers kill three major AWS product lines with an email?

If you breach the LGPLv2/GPLv2 licence then you lose all rights to use the software.

There's no penalty clause, there's no recovery clause. If you don't comply with the licence conditions then you don't have a licence. If you don't have a licence then you can't use the program, any version of the program. And if your products depend on that program then you lose your products.

The theoretical email would be a notification that they had breached the licence and could no longer use the software. The obvious implication being that AWS was wanting to do something that went contrary to the restrictions in the GPL, and he was trying to convince them not to.

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

#698

Post by seb1204 »

cornonthecobra wrote: post #691
josephg wrote: post #653

Earlier quoted context omitted.

I don't know if it would work, but sometimes I consider a "moochers" rule wrt opensource code. Like, here's the deal: The work is proper, legit opensource. You can use it for free, with no obligations. But if your company makes a profit from it, you're expected to either donate money to the project or contribute code back in kind. (Eg security patches, bug fixes, or contribute your own opensource projects to the ecos…

I've spent the last 32 years pushing every employer I've had to contribute back to open source. Because of the sector I work in, more often than not I'm constrained by incredibly tight NDAs. I can usually stop short of providing code and file a bug that explains the replication case and how to fix it. I've taken patches and upstreamed them pseudonymously on my own time when the employer believed the GPL meant they co…

You can wear your secret cape with pride, don't worry about the moocher badge.

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

#699

Post by seb1204 »

izacus wrote: post #585
Root_Denied wrote: post #558

Earlier quoted context omitted.

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.

Linus does...

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

#700

Post by masto »

Astronaut3315 wrote: post #322
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…

I upstreamed a 1-line fix, plus tests, at my previous company. I had to go through a multi-month process of red tape and legal reviews to make it happen. That was a discouraging experience to say the least.

I found a tiny bug in a library. A single, trivial, “the docs say this utility function does X, but it actually does Y”. I’m not even allowed to file a bug report. It took me some time to figure out how to even ask for permission, and they referred it to some committee where it’s in limbo.
Post reply on HN