This is not true even in those spaces anymore. Games these days require libraries like SDL, or (increasingly) use engines like Godot.
Defense is a weird place, but open source is used quite a lot there, it's often required to do so and to record the open source consumed to produce a product. And often times, it must be commercial open source where you can get engineering support for the lifetime of the product's existence.
This stopped a long time ago. Many older GNU projects still have them, but newer ones are not required to have them. Some have even made their usage optional.
In practice, precedence has about the same legal power in both common law and civil law jurisdictions.
That is civil law courts tend to go with the precedent most of the time on the one hand. And on the other hand, a common law judge can always do a bit of nitpicking to argue why the case before her is special and thus different enough from the precedent (or she can pick from multiple different precedents, and then come up with a justification for why the one she picked matches the case before her the most).
Some, but not all, precedents are absolutely legally binding in the French system, they have the same force as the law (unless a later law contradicts them).
Fullscreen HDR support is coming with KDE Plasma 6 on Wayland (which should be available with Fedora Linux 40 and other distributions depending on their timelines).
As an Indian-American, I've heard variations of this to describe first-gen American born Indians in a negative fashion. Sometimes, the shorthand "ABCD" is used (meaning American Born Confused Desi) to insult American Indians. This is principally used by Indians who either live in India or emigrated to the US and encounter American Indians.
(As an aside, it's rather difficult to accurately describe my ethno-national status given the regular confusion with people of the First Nations...)
There's no need to worry about confusion, Indian-American always means ancestry or origin in India. Native American is the usual term in the US for the indigenous, although many of them call themselves Indians and prefer it, a generation ago it was American Indian, but it's never been the other way around, hyphen or otherwise.
It was definitely not bad faith. They're pointing out that OpenTF isn't bothering to hold to quality standards that Hashicorp had for Terraform before the fork and they aren't trying to raise beyond those standards to reach the levels common in higher quality community projects like Linux, Kubernetes, LibreOffice, and OBS Studio.
A project being run by professional developers who have a lot of experience working with the Terraform code should be capable of doing this.
If your problem with a project is that it advertised itself to its target audience prior to releasing a repository, then a good faith comment would say something like, "My problem with this project is that they have spent more time writing manifestos and blog posts and social media comments so far than they have spent developing strong processes and working on publishing a repository for the project".
But if that's your real problem with a project, then a bad faith comment might look like "This is a bad pull request, how could you let it get merged?". The reason that is in bad faith is that it says nothing about your actual problem with the project, it's just a totally random swipe that you don't even actually care about. If there turns out to be a good answer to the question, like "Oh you're right, we forgot to require squashing pull requests when merging, I've fixed it now!", then instead of recognizing that your complaint has been spoken to, you are likely to simply find further things to criticize, because the first thing wasn't actually your real criticism, it was just a smokescreen.
Now, if you are making this other, better, point that the OpenTF project should have more mature software development practices, at least equivalent to and ideally exceeding the better-known project they have forked from, then yep, I agree with that criticism and do not think it is necessarily being made in bad faith.
However, I would be significantly more sympathetic to that criticism if it were a comment on an article entitled "OpenTF project celebrates one full year since its conception" rather than one entitled "OpenTF repository is now public".
The project is brand new, and they clearly rushed to get out a public repository because of other haters who were giving them crap about taking too long to publish the repository, and their processes clearly haven't matured yet. (Or I dunno, maybe it was even many of the same haters, because again, this is the tendency with people who criticize in bad faith, to just move on to the next random criticism that they don't actually care about.)
So if we get to a year from now and their processes remain immature, then yep, I'm right there with you on your criticism. But I think it's crazy (and, sorry to keep repeating myself: likely in bad faith) to make this criticism of such a new project. There is absolutely no indication that the developers running the project are incapable of having mature processes for the project, from the tiny amount of data available from the tiny amount of time that has elapsed since they announced the project.
I think you're confusing X/Y and faith here. You're making the basic assumption that the comment itself is in bad faith because it's not formulated the way you expect. That doesn't stand up to scrutiny because everyone evaluates and expresses things differently, and many folks would consider that a bad faith evaluation of feedback (whether it is positive or negative in reality wouldn't matter).
I think there's a stronger argument of an X/Y problem in the statement, since they talk about what they see as output vs what they expect to see instead.
And frankly, I am disappointed too, as these people working on this project should have spent all that time understanding how Hashicorp actually handled the codebase and ensured that their own engineers followed the same quality level for development. They're all definitely capable of it, so they should actually do it.
Otherwise it's going to be hard to trust the fork to succeed.
There's nothing more I can say on the bad-faithness thing that I didn't already say in my last comment. I think the comment speaks for itself, and I don't agree that it is "X/Y", or itself a bad faith evaluation.
(I do think you may be missing that I was responding to the entire sequence of comments, which started with just a drive-by swipe at pull request merging process, not just the later comments expressing disappointment with the perceived emphasis on marketing over engineering.)
I think your direct expression of disappointment is totally reasonable. I personally think it's also super premature to be disappointed, but it's your prerogative.
But I just think the other commenter's approach to expressing this criticism was way off base.
I just re-checked github.com, and the only options are merge commit, squash commit and rebase commit. Rebase comes the closest, but none of these are fast-forward merges. Worst of all: you can't disable the green button if you don't like any of them.
Defense is a weird place, but open source is used quite a lot there, it's often required to do so and to record the open source consumed to produce a product. And often times, it must be commercial open source where you can get engineering support for the lifetime of the product's existence.