Hacker News Reader

Comment by eloff | Hacker News Reader

This is an interesting window into their business model. This could be a purely an altruistic decision, which businesses sometimes do, contrary to popular belief. More likely it's a bet that wider adoption from making the clustered version free will drive more revenue through their managed database as a service offering. Which shows that their non-OSI open-source license is actually leading to more code and features being available free and (mostly) open-source. As opposed to gating features for paying customers.

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.

View on HN

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

> 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?

This. I don't care if I can see the source code if I can't actually _do_ anything with it. If I can't run my modifications in production, it doesn't guard me against vendor lock-in and it doesn't give me the right-to-repair. So what's the benefit?

Note that I am not arguing for OSS licences, but something like the Commons Clause (use freely, even for commercial use, repair as you wish, just don't sell) seems much more suitable for such cases imho. It protects the business from cloud providers, while still offering some basic protections to the users. This... doesn't.

I do.

I don't think Java would have gotten anywhere if not for the fact that most of the source code was available. Trying to divine information about Windows from the header files was excruciatingly painful.

Being able to step into the code and figure out why it doesn't like 0 in the third argument was a massive boost to my efficacy as a coder. I could add a guard and then file a very precise bug report to get the issue fixed.

Yep. I have had the same experience since the .NET ecosystem open-sourced.

We did consider the Commons Clause when investigating our own licensing approach, but ended up concluding that its definition of "Sell" were actually much vaguer than we felt comfortable with:

  “Sell” ...a product or service whose value derives, entirely or 
  substantially, from the functionality of the Software.

I realize that opinions might differ, though.

But then you have put a limitation on use in production instead of sell? Commons Clause might be (too?) vague, but the concept is imho more fair to end users.

Still, I for one applaud you for this step. We need better non-OSS licenses and it's good to be having this discussion.

I appreciate the discussion here, and as mentioned elsewhere, this has been good motivation for us to revisit this clause in the Timescale License, as a bit has changed since we released it in 2018.

That said, I think a lot of this discussion misattributes the frequency of behaviors. For example, I bet the percentage of organizations that modify the source code of open-source databases like MySQL or Postgres before using them production is some tiny tiny fraction of 1%. While on the other hand, a huge fraction of TimescaleDB users (and MySQL/PG users) use it to build external-facing services and products that they in turn sell to their customers. So it was especially important to us that folks felt confident in their ability to use TimescaleDB in commercial settings.

Anyway, thanks for the thoughts.

I agree with the thoughts on discussion and appreciate that you are taking the time to answer this thread!

Just to clarify: while the percentage of those who exercise this particular freedom (modifying the source and then using it in production) is probably very very small, it is an important freedom to have for a much bigger part of customers. It is an insurance policy that gives users confidence that Timescale Corp will not become user hostile - or if it does, it is still possible to make critical security fixes until a more permanent solution is found.

But I do understand it is difficult to find a solution that would please everyone. I am very curious if you will manage to find a more generic solution to this problem. :) Good luck!

> modify the source code ... before using them production

The freedom-to-modify-and-use and the right-to-repair argument are not restricted to "before using them in production".

This is a completely valid point. I also appreciate the "right-to-repair" comment made elsewhere.

The original intent of this clause was so that we wouldn’t have to support modified versions that were deployed to production. (As pointed elsewhere, we provide a lot of free support in Slack [0].)

But that clause was written 1.5 years ago, and a lot has changed since then. There’s an internal debate right now on whether we should remove this restriction.

So thank you for asking this question!

[0] https://slack.timescale.com/

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.

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

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.

1. I have to wait until upstream accepts it before I can use my own change in my own production.

2. I have to hope upstream accepts my change at all.

3. I have to give up the rights to my change if upstream accepts it at all.

High risk of vendor lock-in, and no right-to-repair.

----

> However, the issue is that companies are not able to ...

That's fine. I'm not asking any company to do something. I stating my reasons why I can't use what the company is offering. It sounds like what the company wants is to not license the code, but to sign a contract with me for a service. Would you sign a contract you don't like?

I run a bunch of forks in production that the maintainers didn't want to merge in. Then they made breaking changes... Software doesn't necessary need to be updated all the time. Adding more features often make the program slower and break stuff, the hardest part of dev is to say no to new features, its much easier to implement new features then solving though problems.

Absolutely possibly to upstream changes. People have, and we welcome contributions:

https://github.com/timescale/timescaledb/blob/master/CONTRIB...

> Absolutely possibly to upstream changes.

The problem isn't that changes can be upstreamed. The problem is that that is a necessary pre-condition before I can even use them.

In addition, what I say in my comment[0] beside yours remains valid.

0: https://news.ycombinator.com/item?id=23275370

It's also a hedge against the company/project shutting down or pivoting in a radically different direction than you want.

All the things you listed are foundational pieces of technology that are incredibly risky+costly to swap out, so if you needed to, there's an option to continue with a fork. If the thing is popular enough, there's a good chance a community-driven effort will pop up, you can find consultants to work on code for you, or even a new company will form around it, letting you continue working on your core product (mostly) uninterrupted.

A slightly different perspective of our licensing/copyright approach is there isn't confusion about ownership, so if we were ever to decide on a more permissive license, we have the clean ability to do so.

Zero plans, but this also applies if a company like ours were to ever pivot/shut down: we as copyright holders can just relicense _all_ the code to be more permissive / dual licensed / etc, which is not the case for projects where individuals hold copyright over merged contributions. (Note the opposite is not true: we can't "unrelease" versions of the code already released under a more permissive license, such as how most of our code-base in Apache 2.)

In short, I understand your point, but I think there are actually multiple sides to this issue as well.

This cuts both ways. MongoDB Inc., back when MongoDB was AGPL-only, wouldn't accept contributions without copyright assignment, which allowed them to go proprietary when they did.

What you're saying here is that you have the ability to "give away" things that you own. Sure, but everybody has that. Even if you did not have all the copyrights to yourselves, you could relicense your portions and others could relicense their portions and others still could just replace the remaining portions with new code. In fact, this is precisely how OpenSSL recently relicensed itself completely.

Sure, what you claim you're adding here is a bit of convenience, but it's just that. When compared to the possibility that your company could "pivot/shut down" _without_ doing anything to the code, it's convenience-for-you vs. risk-for-your-customers.

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?

The original intent of that clause was to help us avoid needing to support modified versions that were deployed to production.

And we tend to offer a lot of free support, e.g., via our 4000+ member Slack channel [0]. We like making sure TimescaleDB users are happy.

But that clause was written 1.5 years ago, and a lot has changed since then.

There’s actually an internal debate right now on whether we need to keep it. So thank you and HN for spurring this discussion!

[0] https://slack.timescale.com/

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

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/LIC...

If I'm reading https://github.com/timescale/timescaledb/blob/master/tsl/LIC... right, then for a SaaS company -- not necessarily a database-as-a-service company -- section 3.11 states that SaaS company can't run Data Definition Language (DDL) commands like CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME.

So if I need to adjust my schema using ALTER TABLE, how would I do that and stay license compliant?

Or if I'm running out of disk and need to run DROP TABLE, is my only choice to simply get more disk space rather than dropping tables?

Some of our customers will need their own unique schema, and will need their own tables. So, how would we even run CREATE TABLE and stay compliant?

Maybe I'm missing something?

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.

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

(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 :-)

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.

> 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):

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

> while the core contributors get nothing

Running a half-billion dollar company after raising $150M in funding is not nothing.

On the other hand it is unlikely Redis would be so popular if it stared as paid software.

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.

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

I'm also happy to discuss privately if you'd prefer - ajay (at) timescale.com.

A couple examples from Timescale users which might be relevant to your use case:

ShiftLeft - code analysis and security scanning to catch vulnerabilities [https://blog.shiftleft.io/time-series-at-shiftleft-e1f981969...]

k6 - a load testing tool that scales to 100k concurrent users, analyzes performance over time, etc. [https://www.timescale.com/case-studies/k6]

If you want to talk specific scenarios, you can reach out alex @ timescale or on Slack - slack.timescale.com.

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?

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.

@jcims I'm really interested to see if we can help. If you're open to discussing, please feel free to email me: ajay (at) timescale.com

It wouldn't be me reaching out but I'll put a bug in the right person's ear. This has been something I've been thinking about for a bit, the HN post is just a bit serendipitous.

Sounds good, thanks!

Hi GordonS, would love to hear about your use case if you don't mind sharing! ajay (at) timescale.com

What makes it tedious?

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 ;-)

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.

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

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

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

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.

> I think we're too hung up on OSI open source licenses.

I disagree. The free software criteria were defined as they are for a reason. AWS and other cloud vendors are taking advantage, but that is not a good reason to give up on the ideals of the movement. I would be much more comfortable contributing to timescaledb if the license had a date at which it expired to AGPL or some other OSI/DFSG/fourfreedoms license.

Ideals for the sake of ideals doesn't resonate with me, in software or outside of it. Give me a practical reason.

The expiry clause is interesting, but I'm not sure it matters in practice. Not many people want to use code several years out of date instead of the current version just because of practically no additional freedoms. Except maybe a potential competitor. I'd be happier to have a reversion to an OSI license if the product stops being maintained or gets acquired and shutdown. That's always a risk with young companies.

> Ideals for the sake of ideals doesn't resonate with me, in software or outside of it. Give me a practical reason.

Fair enough.

I am mainly looking to prevent the timescale corp. from coasting off of their long past work. In such a scenario, the several years out of date code would not be that much different from the current version, because income for timescale would not have been spent on meaningful improvements.

Another benefit is as a check to the timescale corp. in case they start acting up. In such a case, a large contributor or user might pick up maintenance of an old version and start porting it to newer postgresql versions as leverage. Users of TimescaleDB could be reassured that timescale will not abuse them through the licensing situation because there is some backup plan.

> Give me a practical reason.

Your legal ability to apply patches to the software you run to better suit your needs, and in extreme cases to fork and continue development if the maintainers can't or won't accommodate your usecase. It's kind of the entire point of the open source movement.

In principle, yes I agree, but in practice: no! AGPL is a minefield, it's a shame it is, but it is. The spirit of GPL (and AGPL) was that you could do whatever you want but you have to release the source, but they have continually been handicapped by the evolution of software. Existing licenses are not appropriate for SaaS businesses, they are either too liberal or too restrictive. What you're seeing here is the right move: I can use this for free, for personal use or business. I can't sell it directly -- why should I be able to? It's sleazy and encourages closed ecosystems (AWS, GCP, etc.).

The spirit of free software is very much alive in this decision, methinks.

> The spirit of free software is very much alive in this decision, methinks.

From the text of the Timescale License, clause 2.1 (d): "A license to prepare, compile, and test Derivative Works of the TSL Licensed Software Source Code solely in a Non-Production Environment". Further along, in section 2.2, the following prohibition is laid out: "You agree not to, except as expressly permitted in Section 2.1(d), prepare Derivative Works of any TSL Licensed Software"

That removes the freedom to run your own modifications in production. Pretty incompatible with the spirit of free software.

This is only for the parts of the code that are licensed under the Timescale license (most code is not).

Personally, I don't have a problem with this, and think it encourages users to upstream their changes.

> ... it encourages users to upstream their changes.

Not really, and not as much. Not really because one cannot begin using their own changes unless and until the upstreaming process concludes successfully. Not as much because, unlike with open-source licenses, one does not get to keep their copyright.

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. The restriction against production use prevents that.

One of the important reasons I personally don't mind contributing to open-source, is the fact that I get to retain my rights.

> This is only for the parts of the code that are licensed under the Timescale license (most code is not).

This is a moot point because without the parts that are TSL licensed, we'd not be having this discussion.

> The spirit of GPL (and AGPL) was that you could do whatever you want but you have to release the source, but they have continually been handicapped by the evolution of software.

This was largely my assessment, as well. And the motive behind the work that led to Parity (https://paritylicense.com).

> AWS and other cloud vendors are taking advantage, but that is not a good reason to give up on the ideals of the movement.

Why not?

I kind of agree.

The argument of go 100% FOSS or not reminds me of the argument of free market vs regulation. Yes a free market sounds ideal, but in practice, a few major players take advantage and everyone who isn't them is left out in the cold.

The same applies to FOSS vs Proprietary software. If everyone did FOSS to the fullest extent, and anyone building products on FOSS made their product 100% FOSS, then it wouldn't be nearly as big a deal if Amazon took TimescaleDB and sold it, because anything they did would be available to everyone else.

But that isn't how it works. They just wait until a market establishes itself and swoop in and do something someone else is already doing successfully, but better by using their massive resources behind it. Honestly it's a lot like embrace, extend, extinguish. I'm not saying this to shit on Amazon, I don't necessarily think it's intentionally malicious, it just often ends up hurting a lot of organizations building FOSS.

I think of it this way: A lot of people agree that tech giants are increasingly becoming more powerful as they expand their reach, often due to their ability to simply buy or kill the competition through undercutting with their massive cash stockpiles accumulated through their primary business.

For FOSS, it is the same strategy except the competition isn't being "bought", it's simply being taken (FOSS) and made into something "better" with their nearly unlimited resources, and then undercutting the original proprietors.

> The additional restriction in the timescaledb license that you can't run a paid database as a service offering affects hardly anyone negatively (AWS).

That's not the only additional restriction. The Timescale License does not give you the freedom to run modified versions of the code in production. Pretty big difference compared to Open Source.

I think I agree with this sentiment with one caveat: (I didn't read their license in detail, but really for licenses like this which seems to be the broader topic)

Today Timescale offers Timescale-as-a-service, so this allows them a kind of soft-monopoly on being a paid provider for this, but do these licenses generally contain a provision such that if they no longer provide that service themselves, whether from going out of business or a pivot to another product, then someone else could step in and offer it in the future? Closed source products have often had a kind of source-code escrow arrangement so that if they go out of business, you're not stuck unable to fix your own bugs, but similarly, if part of the value in adopting it is that the paid service IS available, knowing that someone else can offer a compatible service if they disappear might be a nice reassurance for the license to offer.

They're not actually providing it themselves - Aiven actually runs the backend. Seems like that points to it having some longevity.

https://kb.timescale.cloud/en/articles/2752585-timescale-clo...

> I think we're too hung up on OSI open source licenses.

Where "we" is defined as an extremely vocal minority on HN. I don't think most people take issue with licenses like this Timescale license or the BSL.

I don't think (most) people take issue with source available licenses per se, but rather attempts to misapply the term open source to them. The Timescale license is great if it allows them to provide source code and a free product while still operating a successful business! That doesn't make it open source though. (And to their credit, Timescale doesn't make that claim.)

Yes, that's probably true. Still vocal minorities tends to wield outsized power by virtue of being vocal.

I think you greatly misunderstand the implications of the Timescale License. Others have pointed out additional restrictions, but as to the restriction you mention, if it were the only additional restriction:

If I build my product on such software, host it on the official service, and latter their business model changes to no longer be a good fit for my business model (or if my model changes), I am stuck hosting the fork myself- I can't pay some one else to host it anymore. Now lets say that I am not alone- but there are several other customers in this situation- we can't band together to create a fork with a thriving, healthy community, including hosting options.

Avoiding vendor lock-in is my number one reason for choosing Open Source software! If your non-open source "Diet" Open license license leads to vendor lock-in, it is not much better to me than any other proprietary license.

I think you are being a bit generous on the causes and effects. The #1 concern of a product like this is adoption. Not in some unsustainable subsidized taxi or food delivery type thing, just that data stores are naturally sticky and come with long term opportunity as usage grows. If they dominate the time series use case, and there is good reason to believe they will, earning revenues will fall out of that in a multitude of ways. I will believe the license proves prophetic if a major cloud or minor cloud with deep pockets does a SaaS license. Until then, this is a pretty standard FOSS+support business model that became popular in the past decade.

I don't think it's FOSS+support, more like a cloud database service offering. Time will tell I suppose as to which business model dominates. And one could make the argument the service is a form of support.

My own experience is the majority of people are using it on their own cloud instances, on prem, or embedded. It's not obvious the first-party aaS will catch on right now, just like the novel license. I don't mean any of this negatively, it's clearly a well run business by smart people that are experimenting with revenue models and trying to achieve the fair outcomes for customers and the business.

What this doesn't touch on is the reality of selling enterprise software as an early startup - being open source is a hard requirement for many buyers.

> It affects us all positively

Except for users who want the highest quality hosted Timescale possible and see this license as an attempt to prevent others from creating better offerings. The open source companies that compete with cloud offerings are not exactly struggling.

Don't get me wrong, I don't have a problem with them using their position to prevent competition, but when people sell it as 'best for all the users', it feels disingenuous.

Reply on news.ycombinator.com