13 ms·

(Timescale CEO and post author) You are spot on. Before the Timescale License, we were left with a tough decision: do we open-source a feature so that everyone

(Timescale CEO and post author) You are spot on. Before the Timescale License, we were left with a tough decision: do we open-source a feature so that everyone can have it for free OR do we close a feature so that the mega-clouds don't have access to it? We didn't like either of those options, which is why we created the Timescale License, which allows us to offer capabilities for free (and make the source code available) to everyone except the cloud providers (ie free for 99.9999% of all users). We find that this has resulted in a mutually beneficial outcome for ourselves and our users. "I think we're too hung up on OSI open source licenses. The additional restriction in the timescaledb license that you can't run a paid database as a service offering affects hardly anyone negatively (AWS). It affects us all positively by providing a sustainable business model to support additional development and support of an open-source product we use. Win-win if ever there was one. I'd like to see more open-source and closed-source companies consider this model." ^ Really well put.

bithavoc 6y ago
Can this license be used to, say, create a Datadog-like SaaS powered by TimescaledDB?
- akulkarni 6y ago
  It depends on the amount of access to TimescaleDB the services provides. If you're really curious, I'd be happy to chat: ajay (at) timescale.com
- mfreed 6y ago
  In most cases, yes, the license will permit this. (There is discussion elsewhere in this threads about whether you give DDL access to your users, i.e., they themselves define schemas, tables, indexes, etc. Otherwise, Datadog is primarily a Value Added Service over just the database; huge numbers of companies utilize Timescale for building their SaaS services.)
jcims 6y ago
I'm a huge fan of Splunk but always want to keep my eye open for alternatives. My use case is mostly security analytics against event content and patterns, and for that the Splunk Processing Language is very well suited. That said I find it's fairly tedious to do a lot of time-series analysis and pattern discovery/anomaly detction across rich event models (think aws cloudtrail events). Anything TimescaleDB can help with here? Are there case studies you can point us to? It feels like there is probably home for both just in my domain and quite obviously in the broader context of large enterprise ops/security.
- gk1 6y ago
  What makes it tedious?
- akulkarni 6y ago
  Yes, we hear Splunk complaints quite often. :) Here is a doc on using TimescaleDB as a horizontally-scalable, easy-to-deploy, operationally-mature data store for Prometheus data (i.e., metrics), put together by another of our engineering teams: Building an open-source analytical platform for Prometheus https://tsdb.co/prom-design-doc https://tsdb.co/prom-design-doc I'm also happy to discuss privately if you'd prefer - ajay (at) timescale.com.
- GordonS 6y ago
  I use TimescaleDB for mass storage and query of security events (up to 100s of millions) - the speed of queries and aggregate queries even on a single node is very impressive. I haven't done anything with regards to anomaly/trend detection yet, but it's planned. Not really sure where you see a database (TimescaleDB) fitting into that though?
  - jcims 6y ago
    We're in that scale domain where everything is a pain in the ass but not obviously outside the scope of commercial solutions. I just checked and we're averaging ~500k events per second in the five areas I'm interested in. I feel that we could probably use a time-series database to reflect our streams as 'last observed state' type collections as well as do the aggregations that we need to feed back into anomaly detection. I'd like to also use something like that to create a 'heat map service' where you can feed a property/window/range and get back scalar for color coding and possibly a slice of values for sparkline type UI. Without getting hands on, though, it's hard to say for sure.
nojvek 6y ago
I admire the `except the cloud providers`. What GCP, Azure and AWS have done with paid Redis offerings make me curious what @antirez (Salvator) thinks about it. They're making billions off Redis while the core contributors get nothing. I guess they agreed to it by having their work as BSD licence. I do think there is a place for royalty based software. Free for personal and development use. For production use, you pay a small royalty to have it on the cloud. It's a win win on both sides. User gets managed offering + support + ability to look at source code, db/service authors get sustainable revenue, cloud providers get their usual PaaS cut.
- pritambaral 6y ago
  > make me curious what @antirez (Salvator) thinks about it. They're making billions off Redis while the core contributors get nothing. I guess they agreed to it by having their work as BSD licence. Here's what Salvatore has to say (from http://antirez.com/news/120 http://antirez.com/news/120): "About myself, I’ll keep writing BSD code for Redis. For Redis modules I’ll develop, such as Disque, I’ll pick AGPL instead, for similar reasons: we live in a “Cloud-poly”, so it’s a good idea to go forward with licenses that will force other SaaS companies to redistribute back their improvements. However this does not apply to Redis itself. Redis at this point is a 10 years collective effort, the base for many other things that we can do together, and this base must be as available as possible, that is, BSD licensed."
- solidasparagus 6y ago
  > while the core contributors get nothing Running a half-billion dollar company after raising $150M in funding is not nothing.
- imhoguy 6y ago
  On the other hand it is unlikely Redis would be so popular if it stared as paid software.
pritambaral 6y ago
> and make the source code available It's available to _see_, but not to "prepare, compile, and test Derivative Works of the TSL Licensed Software Source Code" in a production environment, as per your license's clause 2.1 (d). That's a pretty big departure from open-source; and a bit discouraging for use by non-mega-cloud business interests too. One of the important reasons I personally use and support open-source is the freedom to not only inspect (which the TSL provides) but to also not have to ask someone else and wait on them to make any changes I need to the software I use. Any chance the TSL can be modified to include this freedom too?
- lukevp 6y ago
  Is this really an issue in practice? For libraries (react, jquery) that can’t be used on their own as a product, a lot are adopting MIT. For a “service” - mongodb, redis, rabbitmq, Kafka, Postgres, etc. I have never run into an issue where I would be comfortable modifying something, rebuilding source and deploying into production.
  - pritambaral 6y ago
    > I have never ... _You_ may not have, but plenty of us have. Although, it's not as important when or how many times one has _needed_ to exercise one's freedoms, as it is to have them. But yes, plenty of us open-source users and supporters have exercised this very freedom. In fact, quite a lot of open-source contributions happen _because_ of this freedom: someone has an itch, they scratch it, and _then_ they upstream it.
    - lukevp 6y ago
      Is that not possible under this license, to upstream a change? It sounds like you can’t put the change into production without it first being accepted, but not that you couldn’t contribute in other ways. I get the spirit of your argument. However, the issue is that companies are not able to make open-source compatible, permissive licenses that allow commercial use due to the new reality that creating a service and supporting a product are the main moneymakers. The code is not itself valuable to them but it is valuable as a holistic system because it’s an already built and adopted and production ready standardization of an idea.
brightball 6y ago
I imagine the model will be effective because it will help you to increase adoption, provide an easy path to transition to your cloud managed version and likely a lot of support/training opportunities. Plus, it makes it easier to just start with Timescale even if you don’t need it because we all like to preoptimize.
JeremyNT 6y ago
Hi there! We use and love Timescale, so we've been paying attention to this feature. We currently use the open source version and it's very nice. Would you mind clarifying a bit, because the blog post doesn't really explain: how much of TS do you expect to remain Open Source versus proprietary? Is the idea here that you will switch the entire project to this new license (i.e., this means you're killing the open source project), or is the idea that you'll continue to work on the open source version (but with the enterprise functionality now available under the new license)? The omission of this really important information in the blog post makes me suspect that this is, in effect, the end of OSS Timescale. I'd love to be reading that wrong! If the core will remain open source, you should consider mentioning that in the post.
- mfreed 6y ago
  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? https://www.timescale.com/products/features https://www.timescale.com/products/features (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.)
  - ensignavenger 6y ago
    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.
    - 6y ago
jeffdavis 6y ago
Did you discuss the license with any free/open source software organization to get their input? Are other products adopting similar licenses, and if so, what are the differences? I'm not fundamentally opposed to any deviation in licensing. But I am much less inclined to use software if the license hasn't been reviewed/endorsed/used by others widely. Also, I'm curious if you considered just addressing the license to anyone excluding $COMPANY_YOU_ARE_WORRIED_ABOUT. Not sure what the implications of that would be, but it would be interesting. Realistically, a startup has to prove itself in a relatively short period of time, and in that short period of time there are generally very few competitors (typically zero or one) that threaten your business model itself. If you have 10 competitors that actually threaten your business model, your business has already proven itself ;-)
- akulkarni 6y ago
  We launched the Timescale License about 1.5 years ago. At that point we did engage with multiple folks in different organizations, but realized that we had a business to build and didn't have the bandwidth for all the politicking usually required to establish a standard. However, if someone wants to propose a standard around the principles of the Timescale License, then I would completely support that discussion. Also, so that we are 100% clear: most of our code base remains licensed under Apache 2. The main thing that this post is trying to convey is that multi-node will be free under the Timescale License.
boulos 6y ago
Disclosure: I work on Google Cloud (but am glad to see you protecting your rights to your software). The conversation down thread though raises an interesting point: why does the license say you can’t run modifications in production (under any circumstances) versus some sort of “for commercial purposes” clause? It seems to me like it’s infeasible to have actual contributions if someone isn’t allowed to have a patch, carry it forward, and attempt to upstream it over time. I assume the intent / goal of your license is to prevent people (AWS, Azure, GCP) from taking your code and offering it as a service. I don’t disagree with that. I think it’s also fine to prevent even small companies from saying “and now we wish to be the TimescaleDB company!”. But it seems strange to also prevent non-commercial usage to run patched versions. Lawyering is hard, but is there a clear reason against patched non-commercial?
- gautamdivgi 6y ago
  It's a good question. How do we classify non-commercial? Is a telecom company using timescaledb for internal time series storage non-commercial although it is directly supporting a commercial offering (maybe mobile traffic platforms)? I do get the direct commercial inference. What about the indirect ones? Just about anything in production is directed towards supporting some sort of commercial offering. Just genuinely curious...
  - deleted 6y ago
    [deleted]
  - akulkarni 6y ago
    We took great effort to try to draw a clear line within the actual Timescale License language [0]. Usage is permitted, as long as: the [end-]customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services. In other words, if your service just provides DML access (read/write/modify), then that is permitted, while DDL access (modifying/creating schemas) is not permitted. And in fact we already have thousands of companies building commercial applications on top of Timescale Licensed software (while adhering to the license). [0] https://github.com/timescale/timescaledb/blob/master/tsl/LICENSE-TIMESCALE https://github.com/timescale/timescaledb/blob/master/tsl/LIC...

bithavoc 6y ago

Can this license be used to, say, create a Datadog-like SaaS powered by TimescaledDB?

akulkarni 6y ago
It depends on the amount of access to TimescaleDB the services provides. If you're really curious, I'd be happy to chat: ajay (at) timescale.com
mfreed 6y ago
In most cases, yes, the license will permit this. (There is discussion elsewhere in this threads about whether you give DDL access to your users, i.e., they themselves define schemas, tables, indexes, etc. Otherwise, Datadog is primarily a Value Added Service over just the database; huge numbers of companies utilize Timescale for building their SaaS services.)

jcims 6y ago

I'm a huge fan of Splunk but always want to keep my eye open for alternatives. My use case is mostly security analytics against event content and patterns, and for that the Splunk Processing Language is very well suited. That said I find it's fairly tedious to do a lot of time-series analysis and pattern discovery/anomaly detction across rich event models (think aws cloudtrail events). Anything TimescaleDB can help with here? Are there case studies you can point us to? It feels like there is probably home for both just in my domain and quite obviously in the broader context of large enterprise ops/security.

gk1 6y ago
What makes it tedious?
akulkarni 6y ago
Yes, we hear Splunk complaints quite often. :) Here is a doc on using TimescaleDB as a horizontally-scalable, easy-to-deploy, operationally-mature data store for Prometheus data (i.e., metrics), put together by another of our engineering teams: Building an open-source analytical platform for Prometheus https://tsdb.co/prom-design-doc https://tsdb.co/prom-design-doc I'm also happy to discuss privately if you'd prefer - ajay (at) timescale.com.
GordonS 6y ago
I use TimescaleDB for mass storage and query of security events (up to 100s of millions) - the speed of queries and aggregate queries even on a single node is very impressive. I haven't done anything with regards to anomaly/trend detection yet, but it's planned. Not really sure where you see a database (TimescaleDB) fitting into that though?
- jcims 6y ago
  We're in that scale domain where everything is a pain in the ass but not obviously outside the scope of commercial solutions. I just checked and we're averaging ~500k events per second in the five areas I'm interested in. I feel that we could probably use a time-series database to reflect our streams as 'last observed state' type collections as well as do the aggregations that we need to feed back into anomaly detection. I'd like to also use something like that to create a 'heat map service' where you can feed a property/window/range and get back scalar for color coding and possibly a slice of values for sparkline type UI. Without getting hands on, though, it's hard to say for sure.

nojvek 6y ago

I admire the `except the cloud providers`. What GCP, Azure and AWS have done with paid Redis offerings make me curious what @antirez (Salvator) thinks about it. They're making billions off Redis while the core contributors get nothing. I guess they agreed to it by having their work as BSD licence. I do think there is a place for royalty based software. Free for personal and development use. For production use, you pay a small royalty to have it on the cloud. It's a win win on both sides. User gets managed offering + support + ability to look at source code, db/service authors get sustainable revenue, cloud providers get their usual PaaS cut.

pritambaral 6y ago
> make me curious what @antirez (Salvator) thinks about it. They're making billions off Redis while the core contributors get nothing. I guess they agreed to it by having their work as BSD licence. Here's what Salvatore has to say (from http://antirez.com/news/120 http://antirez.com/news/120): "About myself, I’ll keep writing BSD code for Redis. For Redis modules I’ll develop, such as Disque, I’ll pick AGPL instead, for similar reasons: we live in a “Cloud-poly”, so it’s a good idea to go forward with licenses that will force other SaaS companies to redistribute back their improvements. However this does not apply to Redis itself. Redis at this point is a 10 years collective effort, the base for many other things that we can do together, and this base must be as available as possible, that is, BSD licensed."
solidasparagus 6y ago
> while the core contributors get nothing Running a half-billion dollar company after raising $150M in funding is not nothing.
imhoguy 6y ago
On the other hand it is unlikely Redis would be so popular if it stared as paid software.

pritambaral 6y ago

> and make the source code available It's available to _see_, but not to "prepare, compile, and test Derivative Works of the TSL Licensed Software Source Code" in a production environment, as per your license's clause 2.1 (d). That's a pretty big departure from open-source; and a bit discouraging for use by non-mega-cloud business interests too. One of the important reasons I personally use and support open-source is the freedom to not only inspect (which the TSL provides) but to also not have to ask someone else and wait on them to make any changes I need to the software I use. Any chance the TSL can be modified to include this freedom too?

lukevp 6y ago
Is this really an issue in practice? For libraries (react, jquery) that can’t be used on their own as a product, a lot are adopting MIT. For a “service” - mongodb, redis, rabbitmq, Kafka, Postgres, etc. I have never run into an issue where I would be comfortable modifying something, rebuilding source and deploying into production.
- pritambaral 6y ago
  > I have never ... _You_ may not have, but plenty of us have. Although, it's not as important when or how many times one has _needed_ to exercise one's freedoms, as it is to have them. But yes, plenty of us open-source users and supporters have exercised this very freedom. In fact, quite a lot of open-source contributions happen _because_ of this freedom: someone has an itch, they scratch it, and _then_ they upstream it.
  - lukevp 6y ago
    Is that not possible under this license, to upstream a change? It sounds like you can’t put the change into production without it first being accepted, but not that you couldn’t contribute in other ways. I get the spirit of your argument. However, the issue is that companies are not able to make open-source compatible, permissive licenses that allow commercial use due to the new reality that creating a service and supporting a product are the main moneymakers. The code is not itself valuable to them but it is valuable as a holistic system because it’s an already built and adopted and production ready standardization of an idea.

brightball 6y ago

I imagine the model will be effective because it will help you to increase adoption, provide an easy path to transition to your cloud managed version and likely a lot of support/training opportunities. Plus, it makes it easier to just start with Timescale even if you don’t need it because we all like to preoptimize.

JeremyNT 6y ago

Hi there! We use and love Timescale, so we've been paying attention to this feature. We currently use the open source version and it's very nice. Would you mind clarifying a bit, because the blog post doesn't really explain: how much of TS do you expect to remain Open Source versus proprietary? Is the idea here that you will switch the entire project to this new license (i.e., this means you're killing the open source project), or is the idea that you'll continue to work on the open source version (but with the enterprise functionality now available under the new license)? The omission of this really important information in the blog post makes me suspect that this is, in effect, the end of OSS Timescale. I'd love to be reading that wrong! If the core will remain open source, you should consider mentioning that in the post.

mfreed 6y ago
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? https://www.timescale.com/products/features https://www.timescale.com/products/features (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.)
- ensignavenger 6y ago
  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.
  - 6y ago

jeffdavis 6y ago

Did you discuss the license with any free/open source software organization to get their input? Are other products adopting similar licenses, and if so, what are the differences? I'm not fundamentally opposed to any deviation in licensing. But I am much less inclined to use software if the license hasn't been reviewed/endorsed/used by others widely. Also, I'm curious if you considered just addressing the license to anyone excluding $COMPANY_YOU_ARE_WORRIED_ABOUT. Not sure what the implications of that would be, but it would be interesting. Realistically, a startup has to prove itself in a relatively short period of time, and in that short period of time there are generally very few competitors (typically zero or one) that threaten your business model itself. If you have 10 competitors that actually threaten your business model, your business has already proven itself ;-)

akulkarni 6y ago
We launched the Timescale License about 1.5 years ago. At that point we did engage with multiple folks in different organizations, but realized that we had a business to build and didn't have the bandwidth for all the politicking usually required to establish a standard. However, if someone wants to propose a standard around the principles of the Timescale License, then I would completely support that discussion. Also, so that we are 100% clear: most of our code base remains licensed under Apache 2. The main thing that this post is trying to convey is that multi-node will be free under the Timescale License.

boulos 6y ago

Disclosure: I work on Google Cloud (but am glad to see you protecting your rights to your software). The conversation down thread though raises an interesting point: why does the license say you can’t run modifications in production (under any circumstances) versus some sort of “for commercial purposes” clause? It seems to me like it’s infeasible to have actual contributions if someone isn’t allowed to have a patch, carry it forward, and attempt to upstream it over time. I assume the intent / goal of your license is to prevent people (AWS, Azure, GCP) from taking your code and offering it as a service. I don’t disagree with that. I think it’s also fine to prevent even small companies from saying “and now we wish to be the TimescaleDB company!”. But it seems strange to also prevent non-commercial usage to run patched versions. Lawyering is hard, but is there a clear reason against patched non-commercial?

gautamdivgi 6y ago
It's a good question. How do we classify non-commercial? Is a telecom company using timescaledb for internal time series storage non-commercial although it is directly supporting a commercial offering (maybe mobile traffic platforms)? I do get the direct commercial inference. What about the indirect ones? Just about anything in production is directed towards supporting some sort of commercial offering. Just genuinely curious...
- deleted 6y ago
  [deleted]
- akulkarni 6y ago
  We took great effort to try to draw a clear line within the actual Timescale License language [0]. Usage is permitted, as long as: the [end-]customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services. In other words, if your service just provides DML access (read/write/modify), then that is permitted, while DDL access (modifying/creating schemas) is not permitted. And in fact we already have thousands of companies building commercial applications on top of Timescale Licensed software (while adhering to the license). [0] https://github.com/timescale/timescaledb/blob/master/tsl/LICENSE-TIMESCALE https://github.com/timescale/timescaledb/blob/master/tsl/LIC...