Yes, and then, if I'm smart, spend time and money discussing it with attorneys and/or other experts, who will probably tell me that they don't know either, because there is no body of case law concerning this new and unique "special snowflake" of a license..., etc, etc.

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.

I agree in general that reading licenses as a lay person can be problematic.

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".

It's really the general case that I'm interested in. Understanding and dealing with different licenses doesn't necessarily scale well, which is exactly why license proliferation is a Bad Thing.

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.

Fair point, I agree with everything you've said here.

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.

The "standard licenses" you're talking about weren't standard until people actually started using them.

People can't start using licenses if you don't first write them.

That's fair. And if there's a market for this kind of license, then it will catch on. And if it does, then so be it. I doubt it's a license I'd use, but I don't begrudge these guys any success they have.