That's why you read it...
Of course I could just "wing it", read through it, and work off my layman's interpretation and hope for the best. Or.. I could choose to stick to well understood and well known licenses that already exist.
In this case though, TimescaleDB has blog posts that describe the license in very plain language, and provide clear examples of what you can and can't do - you can basically do anything except provide it as a service. No need to "wing it".
For those people who use Timescale and really like it, and are willing to read and understand this license and then use it, I say "Great!" But in general I find license proliferation to be undesirable and would generally encourage organizations to use standard licenses.
I do think there is a need for a TSL-like license though, and I think the solution is a new type of widely accepted and understood license, rather than individual companies inventing their own TSL-like licenses.
I have no idea how that could actually come to be though.
People can't start using licenses if you don't first write them.
I don't have a dog in this fight, so to speak, as I'm not a user of Timescale. All I'll say is that I hate to see license proliferation in general, and I don't think people should refer to things as "Open Source" if they aren't using an OSI compliant license. To me, if I see a project that's using anything other than a well known, well understood, OSI sanctioned license, I get the heebie-jeebies - because I don't know what the license permits. And I don't want to invest time trying to understand the nuances and ins-and-outs of every random project specific license that comes along.
So props to Timescale for making what appear to be improvements to their license. But I'll always advocate using an off-the-shelf license when/where possible. shrug