Hacker News new | past | comments | ask | show | jobs | submit login

Hi JeremyNT: We've never "changed" any Apache-2 licensed code to TSL-licensed code. And in fact, we've recently basically eliminated most of our enterprise features (read: paid only) and converted them to community features (read: free under the TSL).

So I'm curious: Why do you use only the Apache-2 version of TimescaleDB rather than the Community version?


(I realize that I'm saying "TSL-licensed" versus proprietary, because I'm not sure what it means to think of the code as proprietary when it's all source available on github, people can contribute, and 99% of companies just use it for free.)

First, thanks for replying. But, I'll note you didn't answer my question, which is about the future of the current open source codebase. Knowing that you haven't changed the license on such code yet is great, but that doesn't speak to the future direction for that codebase.

EDIT: I just saw this reply to another child, which addresses this concern for the core timescale, I think! [0]

To be clear, I don't think the license change as described is a blocker for my org, given their use case. Indeed, it may be an near term win, as they will likely be able to take advantage of the new features that you are placing under this license.

That said, I always prefer open source code that I can modify myself. Open source licenses guarantee that the code can't be "taken away" from me, that I can integrate a technology without concerns for the sands shifting under me. If a company goes away, I and others can keep on working on it, and it can live on even if the original authors decide to no longer maintain it.

So, as an example: say Timescale changes the license of all its code under this new license tomorrow, then happily adds features and changes some fundamental things over the next few years, and then is bought by Oracle, who decides to take it fully proprietary under a new license that is more restrictive than the TSL license. This would make a fork unlikely or at least very difficult to get going!

[0] https://news.ycombinator.com/item?id=23276614

Just to clarify, the Timescale License was originally announced in December 2018. At that time, we didn't "relicense" any existing Apache-2 code, we just said some future features will be licensed under the TSL rather than Apache 2.

Many people over the past year+ knew that we were working on a distributed version of TimescaleDB; a common question was whether the distributed TimescaleDB would be paid-only (like some other time-series database alternatives) or whether it would also be free.

This announcement was meant to say: Yes, multi-node TimescaleDB is free, not paid.

So there wasn't any _new_ license announced today; just that multi-node TimescaleDB would be released under the TSL rather than as a paid-only option, which many of our users had assumed.

Proprietary usually mean "not Open Source".

Not JeremyNT, but from my perspective, avoiding vendor lock-in is my number one reason to favor open source software. Avoiding vendor lock in is very important to me when I am evaluating options.

Just because your business model and my business model currently align, does not guarantee that they will always align. I don't want you to be stuck being my vendor if I am not a good customer for you- and I don't want to be stuck using you as my vendor if you are no longer able or willing to provide the product I need.

Just so that everything is 100% clear, most of our code base is still Apache 2 licensed (and we have no plans to change that).

All that this blog post is (trying) to say is that multi-node will not be under a paid license, but instead will be free under the Timescale License.

Hope this helps.

Thanks very much for clarifying. You might want to make a note of this in the blog post!

Fair enough, will do!

Done :-)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact