Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update to the Timescale license

blog.timescale.com

Post reply on HN
Print view View original

41–50 of 210 posts

Re: An update to the Timescale license

#41

Post by rbjorklin »

est31 wrote: post #34
slashdev wrote: post #2

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 on…

> No right to distribute modified Source Still seems like a serious issue to me.

How so? To me it seems like a clause like it is required to protect their business from the "Open Distro for Elasticsearch" scenario.

Re: An update to the Timescale license

#42

Post by yjftsjthsd-h »

slashdev wrote: post #2

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 on…

> 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

Then use AGPL?

Re: An update to the Timescale license

#43

Post by geofft »

slashdev wrote: post #2

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 on…

I've been vocal in the past about using an OSI-approved license for one very specific practical reason: it gets you the ability to be packaged for Linux distros etc. that have policies that match the OSI definition (usually by having terms that match the OSI's current definition, not by delegating the decision to the OSI). In my opinion, that's important for adoption - not as important as it used to be in years past, yes, but still important. Even if production users are going to want to run the latest version (or run a commercially-supported binary), the ability to apt-get install something on your laptop to test it has value, as does the ability for other pieces of software in a Linux distro to depend on it.

That said, given that they're following a more-or-less "open core" model where there's a clearly FOSS portion (Apache 2) and some non-FOSS extra features on top, I don't think that this is going to be a practical barrier. It looks like the Apache 2 portion of Timescale is substantial enough that you can package it in Linux distros and use it. So in this particular case, I think it doesn't matter whether the rest of it is technically "open source" - it very clearly isn't going to be accepted by Linux distros, and it very clearly is fine for its intended users, and both of those are okay.

Re: An update to the Timescale license

#45

Post by mindcrime »

slashdev wrote: post #2

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 on…

I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license.

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

Re: An update to the Timescale license

#46

Post by mindcrime »

rbjorklin wrote: post #41
est31 wrote: post #34

Earlier quoted context omitted.

> No right to distribute modified Source Still seems like a serious issue to me.

How so? To me it seems like a clause like it is required to protect their business from the "Open Distro for Elasticsearch" scenario.

I mean... that's fine if that's what their business requires. It just isn't open source. It's "source available" or "shared source" or something. And there's nothing wrong with that, as long as everybody is up-front about what it is.

Edit: to qualify what I just said... I obviously only mean that IF their license doesn't also allow distribution of patch files. You can be OSI compliant and not allow distribution of the modified source as a "whole" so long as you allow distribution of the patches needed to get to the modified source. I didn't notice at a brief glance where the "new" (or old) Timescale license falls on this point.

Re: An update to the Timescale license

#47

Post by xyzzy_plugh »

yjftsjthsd-h wrote: post #42
slashdev wrote: post #2

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 on…

> 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 Then use AGPL?

How does AGPL address this?

Re: An update to the Timescale license

#48

Post by mfreed »

yjftsjthsd-h wrote: post #42
slashdev wrote: post #2

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 on…

> 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 Then use AGPL?

The AGPL allows Amazon to offer a competing service. It just needs to be open-source.

But the cloud vendor's efforts aren't typically with the software itself -- they often run the open-source version unmodified -- but rather with the operations and systems around the software.

Mongo's SSPL was trying to block this case by forcing folks to open-source all their surrounding infra (which likely AWS would never do), but at least for now, the SSPL was not accepted as an Open-Source License by the OSI.

Also, I'd argue that efforts like the SSPL are actually trying to "backdoor" the goal of "cloud protection licenses" in the first place. They are trying to bake-in a poison pill that the cloud vendors won't want to do, as opposed to having a clause that just directly speaks to the stated goal.

Re: An update to the Timescale license

#49

Post by lima »

yamrzou wrote: post #40
mfreed wrote: post #25

Earlier quoted context omitted.

Internally, a hypertable "partitions" data into 1+ dimensions, typically always by time, but also by other dimensions (esp. for multi-node). Each of these partitions are called a "chunk" (and are actually Postgres tables within the DB). You can also define arbitrary indexes on a hypertable; practically, these index definitions get "pushed down" to all chunks, so an index is built on each chunk. Queries have two-stage…

Another side question, please. How does TimescaleDB compare to Clickhouse? Since you mentioned compression, I've been using Clickhouse to store bitemporal data, and have been amazed by its speed and compression levels. Unfortunately it's lacking in terms of relational modeling. Would I get the best of two worlds with TimescaleDB? What are the tradeoffs?

Compression and aggregation performance in TimescaleDB is much worse than ClickHouse - it represents a different tradeoff, you trade relational features for raw speed.

TimescaleDB is basically (very) fancy PostgreSQL sharding and row-oriented, while ClickHouse is a column store.

Depending on what you need to do, ClickHouse dictionaries and JOINs might be good enough.

Re: An update to the Timescale license

#50

Post by skrebbel »

> 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

Post reply on HN