FFmpeg to Google: Fund us or stop sending bugs
811–820 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#812Re: FFmpeg to Google: Fund us or stop sending bugs
#813People volunteer to make billionaires even more profit - crazy world. Who even have the time and resources to volunteer so much??? I don't get all this at all.
It can be a hobby like model trains and it can be a a social context like joining a club or going to church.
But it's safe to say that nobody is volunteering "to make billionaires even more profit."
Re: FFmpeg to Google: Fund us or stop sending bugs
#814Is it unreasonable to ask that if a massive company funds someone to find a CVE in an open source project, they should also submit a patch? Google is a search company. Seems kind of... evil... to pay your devs to find holes in something with nothing to do with searching, then refuse to pay them to fix the problem they noticed.
Google contributes to ffmpeg on a fairly regular basis https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@goog... No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't. They could just not file the bug reports at all, and that is an objectively worse outcome.
Your stance seems to be is that it is unreasonable to be annoyed by someone who is being unreasonable.
When I searched for synonyms for "unreasonable" in a major English language thesarus, the following synonyms were listed:
indefensible, mindless, reasonless, senseless, unjustified, untenable, unwarranted
So yes, it absolutely is valid for the FFMPEG crew to feel trolled by Project Zero.
Re: FFmpeg to Google: Fund us or stop sending bugs
#815From 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…
Re: FFmpeg to Google: Fund us or stop sending bugs
#816Earlier quoted context omitted.
Not really. Their whole reason for not funding open source is it essentially funds their competitors who use the same projects. That's why they'd rather build a closed fork in-house than just hand money to ffmpeg. It's a dumb reason, especially when there are CVE bugs like this one, but that's how executives think.
> Their whole reason for not funding open source is it essentially funds their competitors who use the same projects. That's why they'd rather build a closed fork in-house than just hand money to ffmpeg. So the premise here is that AWS should waste their own money maintaining an internal fork in order to try to make their competitors do the same thing? But then Google or Intel or someone just fixes it a bit later and…
Re: FFmpeg to Google: Fund us or stop sending bugs
#817Earlier quoted context omitted.
You dont get to decide that lmao. Telling everyone this project doesnt care about security if they ignore my CVE is obviously a demand and your traditions can not change that
> Telling everyone this project doesnt care about security Google did nothing like this. If people infer that a hypothetical project doesn't care about security because they didn't fix anything, then they're right. It's not google's fault they're factually bad at security. Making someone look bad is not always a bad action. Drawing attention to that decision by publicly reporting a bug is not a demand for what the de…
Re: FFmpeg to Google: Fund us or stop sending bugs
#818Earlier 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…
Re: FFmpeg to Google: Fund us or stop sending bugs
#819Earlier 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…
That brings us full circle to the topic because one important thing that gets people motivated into accepting other people's changes to their code is being paid.
If you work in FOSS side projects as well as a proprietary day job, you know it: you accept changes at work that you wouldn't in those side projects.
In the first place, you write the code in ways you wouldn't due to conventions you disagree with, in some crap language you wouldn't use voluntarily, and so it geos.
People working on their own FOSS project want everything their way, because that's one of the benefits of working on your own FOSS project.