The whole point of open source license is that they are a legal document that can be enforced and have legal meaning. It's not just a feel-good article. Your argument is like saying to a client who you are drafting a contract to and say "oh yeah don't worry about the word by word terms in the contract, wink".
Also, this "non-AI" license is plainly not open source nor is it permissive. You can't really say you are a fan of open source when you use a license like this. The whole pt of the MIT license is that you just take it with no strings attached. You can use the software for good or for evil. It's not the license's job to decide.
There is nothing wrong with not liking open source, btw. The largest tech companies in the world all have their most critical software behind closed doors. I just really dislike it when people engage in double-speak and go on this open source clout chasing. This is also why all these hipsters startups (MongoDB, Redis, etc) all ended up enshittifying their open source products IMO, because culturally we are all trying to chase this "we ♥ open source" meme without thinking whether it makes sense.
If people say they "truly love open source", they should mean it.
I can't even reproduce your supposed "issue" regarding the Zig compiler "bug". I have an Apple Silicon Mac and tried your reproducer and zig compiled and ran the program just fine.
Honestly, I really suggest reading up on what self-reflection means. I read through your various PRs, and the fact that you can't even answer why a random author name shows up in your PR means the code can't be trusted. It's not just about attribution (although that's important). It's that it's such a simple thing that you can't even reason through.
You may claim you have written loads of tests, but that means literally nothing. How do you know they are testing the important parts? Also you haven't demonstrated that it "works" other than in the simplest use cases.
Timed disclosure is just a compromise between giving project time and public interests. People have been doing this for years now. Why are people acting like this is new just because ffmpeg is whining?
And occasionally you do see immediate disclosures (see below). This usually happens for vulnerabilities that are time-sensitive or actively being exploited where the user needs to know ASAP. It's very context dependent. In this case I don't think that's the case, so there's a standard delayed disclosure to give courtesy for the project to fix it first.
Note the word "courtesy". The public interest always overrides considerations for the project's fragile ego after some time.
(Some examples of shortened disclosures include Cloudbleed and the aCropalypse cropping bug, where in each case there were immediate reasons to notify the public / users)
Whether the codec is from 1995 or 2025 does not matter. What matters is that the codec is compiled in and working by default on ffmpeg as they intend to bundle all codecs for the user. You can just craft a file, send it to a user pretending to be a regular mp4 file, and trigger the bug. It literally wouldn't matter if the codec was this Lucas Arts one of HEVC. An attacker wouldn't care if they walk in the front door or a random broken window in the back.
But the vulnerability exists already. You are making it sound like Google invented a problem for the project. Maybe the project should be name called if it has hundreds of vulnerabilities? Whether it's run by volunteers or not does not matter for a user of the software.
No one is forcing anyone to do anything. Ffmpeg does not have to fix this bug, btw. If they don't have time, just let the disclosure happen.
Also, in this case, the simple fix is to turn off the codec. They just didn't want to do that because they want to have all codecs enabled. This is a conscious choice and no one is forcing them to do that. If the CVE was allowed to disclose without ffmpeg fixing the issue, at least the downstream users can turn off the codec themselves.
Just to be clear here: Googles' responsibility here is to the public (aka the users of ffmpeg), not the project.
Also, let's go back to your "cooked a meal" analogy. If I cook a meal for you, for free, that's nice. But that doesn't entitle me to be careless in hygiene and gives you salmonella poisoning because I didn't wash my hands. Doing things for free doesn't absolve me of any responsibility.
What makes you think the bad actors aren't already finding these bugs? From the looks of it, there isn't really any rocket science going on here. There are equally well-funded bad actors who will and do find these issues.
With Google finding these bugs, at least the user can be informed. For this instance for example, the core problem here is the codec is in *active use*. Ffmpeg utilizes a disingenuous argument that it's old and obscure, but omits the fact that it's still compiled in meaning that an attacker can craft a file and send it to you and still works.
A user (it could be a distro who packages ffmpeg) can use this information to turn off the codec that virtually no one uses today and make their distribution of ffmpeg more secure. Not having this information means they can't do that.
If ffmpeg doesn't have the resources to fix these bugs, at least let the public know so we can deal with it.
Also, just maybe, they wouldn't have that many vulnerabilities filed against them if the project took security more seriously to begin with? It's not a good sign for the software when you get so many valid security reports and just ask them to withhold them.
Yeah, ffmpeg's responses is really giving me a disingenuous vibe as their argument is completely misleading (and it seems to be working on a decent amount of people who don't try to read further into it). IMO it really damages their reputation in my eyes. If they handled it maturely I think I would have had a bit more respect for them.
As a user this is making me wary of running it tbh.
I'm an open source maintainer and I have never been in a situation where someone filing a security issue will withhold indefinitely, nor would I ever think of asking them to withhold forever. If there are some complications maybe we can discuss a delayed disclosure but ffmpeg is just complaining about the whole concept of delayed disclosures which seems really immature to me.
As a user of ffmpeg I would definitely want to know this kind of information. The responsibility the issue filer has is not to the project, but to the public.
Public disclosures also means users will know about it and distros can turn off said codec downstream. It's not that hard lol. Information is always better. You may also get third-party contributors who will then be motivated to fix the issue. If no one signs up to do so, maybe this codec should just be permanently shelved.
Note that ffmpeg doesn't want to remove the codec because their goal is to play every format known to man, but that's their goal. No one forces them to keep all codecs working.
Except users can act accordingly to work around the vulnerability.
For one, it lets people understand where ffmpeg is at so they can treat it more carefully (e.g. run it in a sandbox).
Ffmpeg is also open source. After public disclosure, distros can choose to turn off said codec downstream to not expose this attack vector. There are a lot of things users can do to protect themselves but they need to be aware of the problem first.
The key point here is: how would a distro know about this vulnerability if Google didn't disclose it? ffmpeg is acting as if Google should have just shut up about it instead of using a well-established timed disclosure mechanism. That means the vulnerability would be private, and downstream users (e.g. distros and individuals) would have no way of knowing said codec is insecure.
I think the answer is pretty simple: ffmpeg is being thin-skinned here. They do care about the vulnerability (despite whining it's an old / obscure format), but they don't want to / have time to fix the issue, and don't want to publicly admit that their software is insecure with lots of attack vectors due to the gazillion codecs they have.
Judging from some online responses I think it's working too. I honestly don't see how ffmpeg's response is remotely acceptable.
What is a dick move is releasing an open source project and then getting mad at people cloning it and then go on a PR blitz to try to destroy said fork. You are basically saying "please take my $100" and then 1 week later accuse them of stealing.
When you make your project open source you are basically inviting people to clone and modify them. If you actually read the terms of MIT and GPL licenses you will realize that they aren't just legal documents but also a social contract telling people it is ok to do so. Otherwise why the F would you make it open source to begin with…?
This matters on a concrete level too. Contributors are much more likely to contribute to open source, so you immediately gain clout and contributors by doing so. So to use such a license and then renegade on the implicit promise is a dick move on the OpenFront's creator's part. Also, note how he keeps referring this to be his game and how it's his copyright? No it isn't. Legally the copyright belongs to each contributor for every bit of code each contributor wrote.
Seems like there are multiple ways to address that within the GitHub ecosystem.
For example, you can set up a GitHub Action trigged by `push_request_target` that will call CodeRabbit's API to generate a patch and then push a new commit to the branch. This way CodeRabbit is being polled by a well-defined and minimal action (since this action will have write access to repo) rather than it itself having crazy power to do anything it wants on your repository.
Alternatively, why can't they just comment and propose a patch? GitHub's code review UI allows the human code reviewer to hit a button and incorporate that change into the PR.
There are pros and cons to these other techniques but the clear pro is that it would be more secure.
It just seems like they took the easiest way out rather than thinking it through in typical AI-bro ways.
I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise).
Now, of course, if there are literally hundreds of dependencies to update every week, then a human isn't really going to go through each and make sure they look good, so that person just becomes a rubber-stamper, which doesn't help the situation. At that point the team should probably seriously evaluate if their tech stack is just utterly broken if they have that many dependencies.
I mean, I think there's a difference between trusting GitHub and trusting third parties. If I can't trust GitHub, then there's absolutely no point in hosting on GitHub or trusting anything in GitHub Actions to begin with.
But yes I do think using tags is problematic. I think for one, GitHub should ban re-tagging. I can't think of a good reason for a maintainer to re-publish a tag to another commit without malicious intent. Otherwise they should provide a syntax to pin to both a tag and a commit, something like this:
The action should only work if both conditions are satisfied. This way you can still gain semantics version info (so things like dependabot can work to notify an update) but the commit is still pinned.
---
I do have to say though, these are all just band-aids on top of the actual issue. If you are actually using a dependency that is compromised, someone is going to get screwed. Are you really going to read through the commit and the source code to scan for suspicious stuff? I guess if someone else got screwed before you did they may report it, but it's still fundamentally an issue here. The simple answer is "don't use untrustworthy repositories" but that is hard to guarantee. Only real solution is to use as few dependencies as possible.
I don't trust apps. I trust Apple (enough) that they engineered iOS to have a secure enough sandbox that a random calculator app can't just compromise my phone.
Most developer packages have much higher permission levels because they integrate it with your code without a clear separation of boundaries. This is why attackers now like to attack GitHub Actions because if you get access to secrets you can do a lot of damage.
With the garbage collection aspect, I do want to point out that eventually people rediscover the benefit of lower level ways to do things and instead come up with improved methods of doing them. See how Rust and Zig have been gaining in popularity for example as a modern alternative to C/C++. As you said, learning how to write in such languages also yield benefits in general as you learn to be more efficient.
Old ideas being new again happens all the time. It's easy to get masked by the new hotness before the disadvantages start to pile up and you need to do a more honest evaluation on the pros and cons of each technique. For example with garbage collection, turns out computers are actually still dog slow today in an absolute sense and squeezing performance is still worth it (people who want to argue otherwise and say "computers are lightning fast", please tell me why a video game cannot render 4K / 120 fps even today, or why an LLM takes months to train with a gazillion GPUs, or why VSCode loads slower than an old copy of Visual Studio on an ancient machine).
I think AI / LLM will probably stick around, but programmers who have become too reliant on them will eventually be filtered out much quicker than people who bother to learn to program well and retain more useful skillsets (even if they end up using LLMs themselves).
Also, this "non-AI" license is plainly not open source nor is it permissive. You can't really say you are a fan of open source when you use a license like this. The whole pt of the MIT license is that you just take it with no strings attached. You can use the software for good or for evil. It's not the license's job to decide.
There is nothing wrong with not liking open source, btw. The largest tech companies in the world all have their most critical software behind closed doors. I just really dislike it when people engage in double-speak and go on this open source clout chasing. This is also why all these hipsters startups (MongoDB, Redis, etc) all ended up enshittifying their open source products IMO, because culturally we are all trying to chase this "we ♥ open source" meme without thinking whether it makes sense.
If people say they "truly love open source", they should mean it.