It would seem these folks listened to the criticism of their Timescale License here on HN and took it to heart. Right to repair, right to improve, and the gating of enterprise features were the only serious criticisms, and they've been addressed. I tip my metaphorical hat to them.

I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale by leeching off their software without paying for it. That's a glaring short-coming of FOSS licenses that really should be addressed. Until then I expect this kind of almost-FOSS license to become more popular in the future. We're seeing it from many of the recently founded open-source companies in the cloud era.

I'm developing a bit of a Pavlovian response to blog posts that begin with "An update to <Product>", so I was glad to see that all of the changes seem really positive.

TimescaleDB is a neat piece of software and I'd definitely recommend checking it out if you're looking for a time series database. I had used some of their competitors in the past and it wasn't a fun experience. They had a high learning curve (things like multiple custom query languages, quasi-relational design that led to massive performance penalties if used the "wrong" way, etc), and at least for my use case the performance wasn't even good enough to justify the esotericism (although I've only used Timescale on small hobby projects with low data rates so maybe it's not fair to complain about another DB's performance with heavier workloads).

IMO what makes Timescale so great and user friendly is that after you set up your tables you can treat it like a regular old SQL database. Everything just works, and you get all the niceties when you make temporal queries.

I’m not much of a fan of AWS, but when Amazon takes a “free as in speech AND beer” product and turns it into SaaS, that’s pretty much the expected outcome since (a) the license allows it and (b) companies exist to make money. Why would Amazon spend more than necessary to create this service? It’s not that they’re intrinsically evil for doing this; it’s literally how the rules are written. If you want to change that world, you need to change the rules.

So I think this direction for complex, expensive to create “open” backend software is inevitable, and that dogmatic appeals to some formal and restrictive definition of openness are philosophically naive.

Arguments that Timescale is not open remind me again of the paradox of tolerance [0]. This basically says that a tolerant society must not tolerate intolerance. This is because a tolerant society is vulnerable to intolerance; a tolerant society, by definition, fails when it allows intolerance.

Similarly, I am quite comfortable to consider software “open” if I can download it, build it, and use it in my products; even if it is closed in some specific dimension that is required for it to exist. It’s a shame in theory that I can’t create a little TSaaS without Timescale’s approval, but it’s not a right that most people care about, and I prefer that to a world in which the Timescale product itself doesn’t exist.

Ultimately, it’s an argument between dogmatic openness and pragmatic openness. I’m decidedly in the pragmatic camp on this one. And FWIW, my recollection is that OSI itself was created in order to extend and formalise the definition of “open” to include pragmatically open licenses beyond the GPL. (I could be wrong here, it was a long time ago and I was not involved, but I seem to remember discussions on slashdot and technocrat)

In any case, I think that any academic discussion of the definition of “open” needs to take into account the paradox that perhaps, by requiring dogmatic adherence to the definition of “open”, we cause the world to be more closed. Which is, I think, not what we want.

[0] https://en.wikipedia.org/wiki/Paradox_of_tolerance

edited to clarify.

Reading the comments here, it seems to me that there are two sides to the debate: One side says it's not FOSS unless it's completely free, and the other side says it's fine for a small subset of use cases to lose a modicum of freedom if it means that everyone else benefits with more software that's essentially OSS.

I think that what the "purist" view is not considering so much is that, when it comes to a company like Timescale, the choice isn't between "OSI" and "source available", it's between "source available" and "closed source". They're a company that wants to make a profit from the software it spends resources to develop. The debate seems to be mostly on whether this license should be called "open source", but I think there's an implicit value judgement there, which I'd like to make explicit.

I'd like to clarify that, given that it's almost impossible to make money when AWS can just take your OSS product and undercut you, Timescale is doing us all a great service by giving us a product for free and making the source available. However, does it really make sense to argue over the license is OSS or not?

The FOSS ecosystem has a monetization problem, and it's largely being funded by our collective donation of our time. I think that having options that allow us to grow the ecosystem in a sustainable way is important, even if they aren't as pure as we'd all like. Practicality usually beats purity, and "source available" is better than "closed source".

I haven't really seen any concrete dangers that come from a "source available" license, especially any that make it worse than just having no source (which is the real alternative here), so if anyone could educate me, I would be grateful.

> Rights still disallowed under Timescale License

[...]

> No right to distribute modified Source

> No right to distribute modified Binaries, unless as part of a Value Added Product

Yeah given these restrictions the license doesn't even come close to the spirit of Open Source and it's laughable that they suggest otherwise.

Of course, they're well within their rights to do this and I wish them the best of luck doing business with people who are willing to entertain the use of a proprietary database (a term I wish they would embrace for the sake of honesty), but personally I could never use or recommend TimescaleDB in good conscience.

> What we have preserved, however, is the main restriction preventing other companies from offering TimescaleDB-as-a-Service in the cloud.

I wonder how this ties in to eg Digital Ocean's managed Postgres product. According to their docs[0] I can just `CREATE EXTENSION timescaledb` on a managed postgres instance and I'm done. Isn't that totally breaking the TSL? And if not, what's preventing AWS and friends from doing the same?

[0] https://www.digitalocean.com/docs/databases/postgresql/resou...

EDIT: just saw that mfreed answered a similar question here https://news.ycombinator.com/item?id=24581533

> These licenses attempt to maintain an open-source spirit

No they’re not. Open source licenses are in the open source spirit.

Source available licenses are not.

Free software is free to use for any purpose. If your software comes with nonfree restrictions, it is not only not free software, it is not in the spirit of free software.

This is just more anticompetitive behavior from those that mistakenly believe that IP is property to be guarded with the machinery of the state (and the associated threat of violence for transgressions) to back them up.

Your software either is free to use for all purposes, or it is not. If it’s the latter, why the fake and misleading “in the spirit” posturing? Make a decision and be proud of it instead of pretending you’re something you’re not.

As an aside, this article links to Wikipedia to insinuate that there's some ongoing problem with the OSI and it's likely to fade in importance. Wikipedia, in turn, mentions two recent problems. The first is that Bruce Perens left the OSI because they were considering approving a license that he thought wasn't open source - so this doesn't back up the idea that the OSI is too cautious with licenses and that the sentiment is shifting in the direction of accepting more licenses as "open source" than the OSI would want to.

The second is that ESR got banned from the mailing lists. If you believe his version of the story, it was because he spoke up in favor of keeping the OSD intact. If you believe the OSI's version of the story, it was because of his behavior. Yes, this was technically controversial (ESR seems to be extraordinarily good at having controversy follow wherever he goes), but again, neither interpretation backs up the idea that people want the OSI to be more liberal about licensing.

I think this Wikipedia section is all undue weight which could be justifiably removed, and I think it's weird that this post points to the (mutable) Wikipedia article to make its point.

This move makes sense; I am trying to think about the implications of this specific license long term, and it seems it strikes a balance between protecting the company from AWS, Azure and GCP, while at the same time offering a relatively straightforward framework for their customers and, down the road, for 3rd party vendors.

If they succeed, this could be the blueprint for many other companies in a similar situation.

Keep up the good work!

I wish more vendors would move this way. The rise of cloud computing has made it clear that people want to buy services, not software licenses.

Too many (DB) vendors keep trying to sell licenses with a heavy sales process, and barely have a working cloud offering while complaining about AWS.

You gotta hand it to them - Mike & Ajay are fantastic at writing blog posts. Either it's all them, or they have someone helping them, but either way the content is really top-notch.

Seems like table-stakes for anyone including the dev community when building databases these days.

If anyone is interested in using a source-available license for their own code, the Polyform Project has a set of standardized, source-available licenses. https://polyformproject.org/

PolyForm Shield would probably achieve the same result as the Timescale License. https://polyformproject.org/licenses/shield/1.0.0/

I've been thinking very hard about introducing Timescale as a replacement for Cassandra in an application which is starting to show its age (when it was first built in the early 2010s, Cassandra was the only player in the game - but Cassandra never was a great time-series database). One thing which has made me wary of Timescale is the source-available license - which is great and all, but if the license changes significantly to make it more restrictive then we end up in a tough spot. A constant sticking point of Cassandra is that it's Apache Cassandra - it's very unlikely the license is ever going to become more restrictive, since it's owned by the ASF. This looks like a great development though, and I'm warming even more to further exploring Timescale.

Something I'm still trying to understand: does not allowing database-as-a-service just mean that you can't have, say, an application which abstracts away the details of implementing a Timescale database (e.g. you input some kind of configuration file which describes the details of your deployment) without violating the TSL? Are you still allowed to leverage Timescale in your SaaS?

> Rights previously granted (and still allowed) under Timescale License

> Right to run unmodified TimescaleDB for internal use

> Right to utilize unmodified TimescaleDB to offer a Value Added Service

> Right to distribute unmodified Source and Binaries as part of Value Added Product

> Right to modify TimescaleDB for internal development and testing, and subsequently upstream modifications to Timescale

Do you can still run modified (or unmodified) "community edition" timescale in an SaaS configuration right?

Also it sounds like you can actually run unmodified TimeScaleDB (Timescale license w/ all the enterprise features) as long as you add some value (is easy setup value? Do I need to like automatically shard or something on top of it?)...

Am I misunderstanding? I'd love to run a postgres aaS provider for fun someday and I'd like to use timescale as one of the supported addons.

A bit of a side question, but how slow would it be if we were to query the data without using a time-based approach? I.e. "select * from obj where parent_id = <x>" --> Imagine we had billions of obj and a few thousands matching "parent_id" added randomly during the last 5-10 years. Would there be an index on "parent_id" or would it need to read every hypertable for such a query?

Basically, I'm trying to understand if Timescale is /only/ useful for timeseries or if it has good-enough performance for other use-cases.

Hey! Maybe mfreed could answer this but how does this affect users of Timescale as part of Azure's Managed Posgres service, is this something that will still continue to be available?

Just curious, what does distributing sourcecode mean? If I fork on github and push a change, am I then distributing sourcecode?

Going off tangent here, what would be a killer Timescale feature is to have multi-master writes.

I've been following these guys since the project started, and it keeps getting better! Well done!

I wonder if the Star Wars clip in the blog post is licensed :)

I am probably wrong, as often is the case, but I seem to remember that High availability used to be in the enterprise tier. Now it is missing from the “software tier”. What am I missing? Is HA now free or not?

Does timescale have speed party with click house yet? IIRC there was some issues with plumbing postgres to do SIMD or something?

Is there a list of enterprise features which are now free?

Read it as Tailscale. ;D

Calling your users leeches while being leeches yourselves, how ironic.

While this looks like the end of arbitrary enterprise tiers, when I look around to me it looks like the other database providers saw Snowflake execute "cloud" brilliantly, and now everyone is trying to emulate that.

Turns out the need to keep your data on prem has been greatly exaggerated, and most companies would rather pay a single cloud bill than paying for more machines and FTEs to handle another product.