My biggest familiarity with "source available" was some of the .Net stuff from MS before they fully embraced FLOSS for .Net language/platform development. Which was iirc, a look, but don't touch kind of thing.

If you can fork and reuse, then "source-available" is probably a poor term for said license.

> If you can fork and reuse, then "source-available" is probably a poor term for said license.

I agree. Yet projects using said licenses get shamed into adopting the term "source-available" even though it doesn't fit, while "open-source" actually makes more sense in terms of communicating freedoms. It's all so ridiculous. Things need to change.

To be fair, "source available" could also mean a fully custom license, closer to a typical proprietary closed-source license, except with "btw here's some source code, but you're not really allowed to do anything with it".

Even in the above scenario, source-available is still better because you at least have the technical possibility of doing something with it, at the cost of potential litigation for breach of license.

Yes, in theory. But in practice, I haven't seen a popular "source-available" license that limits your ability to fork. So making a blanket statement like that is wrong in practice, but people still tout it. That's the problem with the term "source-available" and why a lot of companies using these licenses avoid the term altogether.

But if you say "open source" instead of "source available" then you get the OSI folks flaming you for not comforming to the definition. It's a lose-lose situation.