If you can look at, but not redistribute, freely, it is called 'shared source'.
Open Source really is about free redistribution. And the difference to Free Software is mostly about the stance on community and lock-in.
"Open source" is very generic, it literally just means "Not closed/private source." Nothing else about redistribution and restrictions is implied. For that there are specific licenses, which the article didn't mention.
It's not open source unless it's an open source license, and it's not an open source license unless it meets https://opensource.org/osd-annotated. You are referring to "source available". Please stop conflating the two.
Can you blame us? This is largely a subjective matter, and the different organizations who talk about this kind of thing have often-conflicting ideologies about how all this works.
When I hear "open source", I don't know which camp the speaker is sitting in. It's perfectly reasonable to get mixed up sometimes.
While it is a subjective matter when looking from the outside, the OSI consortium did a pretty good job of bringing in all of the various groups conventionally referred to as 'open source' and getting the various definitions pinned down in a way that seems to accurately reflect the broad spectrum of possibilities, even to the point that non-open-source companies use their definitions.
While I agree one can still certainly debate the legitimacy of this situation if one so desires, it's pretty much consensus 'within the literature' that the OSI definitions 'are correct' at this pont..
It is a technical term defined by a bunch of people who got together and agreed that their opinions (however educated they may be) are more correct than other people's. That's extremely subjective, and not universally accepted.
Technical terms have definitions that transcend the opinions of people who use them. When I say "byte", everyone knows exactly what I mean, as it's a unit of measurement. When I say "agile", it could mean any number of different things, depending on context. When people say "open source", the thought that comes to a lot of people's minds is simply "I can see the _source_ code, because it's out in the _open_."
It's subjective, and, frankly, annoying. It shouldn't matter how something is licensed, because the most important aspect of software is whether or not it provides value and helps me do my job. Bickering about semantics doesn't get work done.
That's how definitions work.
The fact that you ignore one doesn't make you more thoughtful or insightful it just makes you look like a special snowflake.
Your example is also incorrect because I'll assume you think that a Byte is 8 bits but technically it's not, it's an arrangement of bits a byte can be 0-255bits, it was common to have non 8bit bytes in the past.
The 8 bit byte was set by a specific ISO standard and later by IEEE but it's defined as 8 bits only within those standards.
Agile also has a definition if nothing else because you have bodies and various foundations promoting a specific implementation of it.
I'm just going off of what I hear vocal "FOSS" advocates screaming at me on online forums. They tell anyone and everyone, loudly, that licenses are terrible, but at least some are decent, and that if I can't do what I want, it's not free software, even if it's open source.
Turns out opensource.org disagrees with them. But it doesn't seem like FSF (or rather, RMS, and the FSF by proxy) agrees[1].
In the end, I don't really have a horse in this race. I just write code. I don't care how my company's legal department chooses to protect it.
Frankly, I find it kind of tiresome that there's such a big argument over this stuff.
I manually went through each of the OSI licenses and compared them to the FSF's list a while back, and there were only a couple differences. I don't have time to dig them up right now, but they're largely the same.
We reject the term "open source" not because of the licensing, but because of the philosophy: it was created to explicitly ignore the ethical concerns (users' freedoms) and focus instead on a development methodology.