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?).
FFmpeg to Google: Fund us or stop sending bugs
491–500 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#492Earlier 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…
Re: FFmpeg to Google: Fund us or stop sending bugs
#493Earlier 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?
Especially if they’ve just spent all this cash on some ai tool.
Re: FFmpeg to Google: Fund us or stop sending bugs
#494Earlier 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#495I’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…
Typically disclosures happen after a fix exists.
Re: FFmpeg to Google: Fund us or stop sending bugs
#496Earlier 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#497Earlier 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.
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
#498Earlier 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…
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
#499Earlier 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 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
#500Earlier 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…
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.