Hacker News new | past | comments | ask | show | jobs | submit login
An update to the Timescale license (timescale.com)
427 points by bithavoc 10 months ago | hide | past | favorite | 206 comments



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 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 problem with the terms of their license. Use whatever license you want — just don't call it "open source"!

From the blog post... This is problematic:

> open-source in spirit

It ain't. It is firmly in the spirit of "source available" licenses, which have a decades-long history and almost all of which do the same thing this license does: impose a field-of-use restriction to limit commercial competition.

https://en.wikipedia.org/wiki/Source-available_software

By corrupting the term "open source", they are leeching off of the goodwill created by the Open Source movement, and they shouldn't expect people to stop complaining about it until they stop.


Hard disagree. The OSI may have "Open Source" in its name, but we decide what "open source" means. And I agree with the 'spirit' of open source, which is based in RMS' inability to replace code on his printer. The right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications.

This "it's not open-source unless you allow Amazon to profit from your charitable work" is horse hockey. I don't care if this is how a hardliner sees it. Linguistics is descriptive, not prescriptive, and this is important enough that I support the migration of "open-source" to include these restrictions. Which, as they point out, affect none of the people using their code, and only the corporations (not people!) who would abuse the goodwill created by the Open Source movement.


> but we decide what "open source" means

Well, "we" in the Open Source movement decided that it means not restricting what users do with their code.

I don't understand what's so hard about this. Overwhelmingly, the biggest players in the Open Source ecosystem have consistently been saying, "call it whatever you want, just be clear that you're not the same as us." And the response from a lot of people has been, "no, you have to let us call ourselves the same as you."

Source Available has been a term for a really long time, and its generally understood what it means, and plenty of people use the term with plenty of good will. This shouldn't be a controversy, it's such a straightforward, easy concession. There's nothing wrong with being Source Available.

So why do we need to come up with a new term that describes the freedoms we've been consistently preaching for decades just because a couple of for-profit companies want the good will that we've generated? This isn't language evolving over time, it's people outside the community trying to decide how we're allowed to define ourselves within in the community.

Yes, language is descriptive, but that doesn't mean you can just redefine anything you want any time you want. Even more than that, the fact that language is descriptive does not mean it's a bad thing for communities to try and publicize and preserve the descriptive language that already exists. Open Source advocates are hardliners on this issue specifically because we recognize that language is descriptive, and that our ability to preserve the meaning of the words that describe our community is dependent on us taking the time to educate and correct people who are genericizing those terms.


"Source Available" encompasses a wide gamut of licenses. I think it is fair to say that the new TLS license is closer in spirit to "open source" than the old one, or say Gitlab's enterprise license.


No, it's not. It's entire purpose is protecting the copyright owners ability it extract rents against others who might offer competing services, which is exactly the spirit of traditional proprietary licensing, and exactly opposed to the value proposition of Free/Open Source Software.

The terms might be superficially similar to some F/OSS licenses, but the reason it fails to meet the OSI or FSF definitions is precisely that it's spirit is diametrically opposed to F/OSS


> Well, "we" in the Open Source movement decided that it means not restricting what users do with their code.

The "GPL" is way more onerous. You see, one can only be truly unrestricted by being restricted into taking certain actions. Nothing Orwellian to see here.



I would tend to agree. Saying "our software is free for anyone to do anything they want with, except Amazon to profit from" may not be free in letter, but I certainly see it free in spirit.

I fear we're letting perfect be the enemy of the good here, and letting the FOSS ecosystem wither and lose incalculable value by letting trillion-dollar corporations exploit the hard work of people for free. If the choice is between "cheap Timescale on AWS run by Amazon" and "slightly less cheap Timescale on AWS run by Timescale", I'll take the latter.

I think banning FAANG from competing with the single source of revenue these FOSS companies have is a small price to pay to ensure a thriving FOSS ecosystem, and I think insisting on absolute freedom is killing the ecosystem.


> Saying "our software is free for anyone to do anything they want with, except Amazon to profit from" may not be free in letter, but I certainly see it free in spirit.

Some people feel just as strongly about imposing field-of-use restrictions to exclude military entities as you do about excluding "trillion dollar companies". Others feel strongly about excluding all commerical usage.

But "Open Source" means no field-of-use restrictions — so although any of you are free to craft your own licenses excluding X, Y, or Z, you don't get to call those licenses "Open Source".

> I fear we're letting perfect be the enemy of the good here, and letting the FOSS ecosystem wither and lose incalculable value by letting trillion-dollar corporations exploit the hard work of people for free.

No economic value is lost. Timescale is free to publish their own software offings with their own licensing; those offerings merely exist outside the Open Source ecosystem.

Open Source is plenty successful. It does not need to destroy itself in order to encompass all things.

Besides, "letting trillion-dollar corporations exploit the hard work of people for free" is what Open Source has always done. Everybody gets to use it for free — trillion dollar corporations, governments, religious organizations, activists, convicts... everybody!


> But "Open Source" means no field-of-use restrictions — so although any of you are free to craft your own licenses excluding X, Y, or Z, you don't get to call those licenses "Open Source".

Sounds like public domain. What’s the difference between the two then?


> Sounds like public domain. What’s the difference between the two then?

Public domain, other than by copyright expiration or (in the US) federal government creation is actually not clearly possible to create in a legally unambiguous way in many regimes with automatic copyright and no direct provision for unilateral transfer to the public domain; the most permissive open source licenses approximate it while providing better legal clarity.

Open source licenses often seek to protect the originator from liability they might otherwise incur from chain-of-commerce relationships, making it safer for them to make the software available without fee, and to prevent misattribution of origin. Other open source licenses, while not having field of use limits, seek to assure that derivatives are also offered on similarly-free terms. There's quite a variety, within the bounds of certain essential guarantees that are central to the common value proposition.


by that argument copyleft licenses aren't open source either? from a practical perspective this license is strictly more permissive than AGPL in that it only excludes cloud companies rather than all non-OSS companies.


How so? Corporations can use and sell software and run services for money that use copyleft software if they want to if they abide by the terms of the license, and some do, whereas the TSL specifically disallows this. How does AGPL exclude "all non-OSS companies"? These companies are choosing not to use AGPL software; that doesn't make AGPL not an open source license. The AGPL doesn't even require source code publication when run over the network unless you modified the code, so if Timescale were licensed with AGPL, Amazon could directly offer Timescale as a service and not even need to provide a source code download link. AGPL obviously does not exclude other companies from merely using the software in other ways, so I really don't see how the TSL is "strictly more permissive".


The trillion dollar companies don't get it "for free", they still have to pay employees, contractors and consultants to actually run the software. And as you know, the salaries tend to be a lot higher at bigger companies. Pick your poison.


If you give me a couch for free but I have to bring a truck to take it away on, does that make it not-free?


If you had to pay to rent a truck and also pay to hire workers to move it in and out of the truck and then up 10 floors to your apartment, then yes, it wasn't free, there is a real cost to you. A cost that you saved me because I didn't have to pay someone to take it to the landfill. So I would actually be saving money despite that it looks like I gave it to you "for free". And if I was really crafty I'd have suggested for you to use a particular moving company and then I'd have charged them a referral fee.

(Of course this is a somewhat cynical view, and this isn't even getting into the other costs associated with second hand furniture -- anything with upholstery carries a risk of containing mold or vermin and you may need to pay more to get it cleaned/sanitized)


Open Source - Choosy Beggars.


Yes, that's definitely the cynical way to look at it :)


You'd be in good company with Microsoft circa 2001 with their (source-available) Shared Source Initiative, because your argument is the same one that people have been making back then and ever since: that banning field-of-use restrictions imposes too much of a burden on commercial entities.

But disallowing such field-of-use restrictions is exactly what makes open source collaboration between otherwise competing companies possible. It is a fundamental difference between Open Source and Source Available licenses.


Can you elaborate? What collaboration do you mean?


Uhh, kubernetes would be an immediate example. A massive piece of software that has been adapted into every major cloud provider, with all those cloud providers working on that same piece of software.

While Google may have done it to make their own Cloud offering better, it ultimately has succeeded in saturating the container compute market and with their own success has brought plenty of competition.


On the contrary, Google made Kubernetes precisely so they could commoditize every other cloud provider and then offer the strongest Kubernetes provider there is. When AWS is just a layer under Kubernetes, you can move your entire infrastructure to GCP by pushing your Kubernetes config to a different endpoint.

They succeeded quite well in that.


You statement on what is open source:

>The right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications.

Description of the license from the linked articles:

> 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

I'm very confused on how you're reconciling your stated view on the definition of open source and the directly conflicting text of this license.


That's fair, I didn't look closely enough at the specific terms to make sure it conformed to my view of "open-source". I specifically disagreed with the parent comment and others, which declare that "it's not open source unless [Amazon is free to profit from the software]".


Then I'm afraid you're just wrong.

Open source is a well-defined term with a well-defined meaning. In fact, it was coined precisely because "Free Software" was considered to be too ambiguous.

Words have meaning. You can't just change the meaning of a well defined term to suite your views.


What about the AGPL?

Wouldn’t it grant “the right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications” and provide protection from FAANG profiting without reciprocating, while being OSI and FSF approved?


If Timescale were AGPL Amazon would be free to just run it as a service for profit and all they need to do is publish their modifications to it, if they make any. Amazon has no problem running all kinds of other open source software for profit, and this is what TSL is specifically designed to prevent.


But that's the trade: you either pay with time+effort or with money.

What everyone seems to miss here is that the GNU Affero General Public License offers the ability for people to make that choice. Cloud providers would be forced into an ugly situation if almost every single XaaS codebase switched to AGPL. Their business model depends on being able to make minor investments to provide things people want as a service and not share it with the community.

However, if the AGPL was normalized and used more often, cloud providers would be in a situation where they'd either have to A) build everything of theirs on their own if they don't like the license or B) use the software people want, release their improvements back to the community, and everyone benefits.

It's amazing how everyone has forgotten why Linux won over all the other server, mobile, and edge platforms, and is slowly inching to dominate everything else. The terms underlying most of the core Linux system software, including the kernel obviously, require things incorporating it to be released with usable sources to the public. That is what enabled individuals to sustain a project and make it into the successful juggernaut it is today.

But because Google has managed to poison the well with AGPL, we're in a situation today where "business-friendly" permissive licenses like the Apache Software License are used and companies are surprised when they get sucked dry by cloud providers abusing the properties of that license.

Companies building open source software should expect one of two things: money or code. Both are intrinsically quite valuable to them, and they should take care to nurture that those are the two valid options.


The problem with agpl is that no companies want to touch it. It's too restrictive if you ever want to integrate something with your internal proprietary moneymaking code.


Doesn't that accomplish the goal then? Make your project AGPL and with a commercial license, so only you will be able to make it a commercial business as other big cloud companies don't want to touch it.


The problem is that it is not truly impossible to integrate into a commercial company. It's more that the license practically requires a lawyer to look at exactly how it'll be used and approve that use. AWS certainly does not shy away from hosting AGPL software. It does prevent AWS from taking the code and running with it though, at least not without a shim. A more permissive license can lead to the Athena/Presto situation where Athena is, to my knowledge, a proprietary fork of Presto.


Disclosure: I work at AWS on infrastructure services

I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license.

Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3...

Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.


Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal review it is unproblematic to use commercially, which cuts both ways as Redis found out.

I think there's a serious amount of FUD around it. I suppose it's because of how rare it is. With more usage, it would probably bee seen as less dangerous.


The core Redis code (originally announced on this site in 2009 [1], before Garantia Data started in 2011, or became Redis Labs in 2014) has always been BSD licensed. Only extensions from Redis Labs (e.g., Redis look) were licensed under AGPL, and changed to Commons Clause / Redis Source Available License. Those extensions were never part of an AWS cloud service.

See also [2]

[1] https://news.ycombinator.com/item?id=494649

[2] https://redislabs.com/blog/redis-core-team-update/


I agree that there’s a serious amount of FUD around it. I think it’s at least in part because it proliferating could seriously harm Alphabet’s ability to freely grab people’s code to incorporate in their consumer products (YouTube, G Suite, etc.) without reciprocating, and they’ve been careful to semi-subtly spread the FUD (ie. publish https://opensource.google/docs/using/agpl-policy/). https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html



The problem is that Amazon could still do it, they're just on that scale, while most common companies would shy away as they don't have the Amazon budget for abusing AGPL right.

I hope in the future the Elastic, TimeScale, Confluent and any other "fuck Amazon" license could be merged into one and kind of standardized on as many freedoms as possible, while keeping AWS out of it.


RMS created Free Software, not Open Source. Open Source is something that the OSI made up.


IIRC OSI didn't make it up. OSI was created to codify the existing use of the term


I'm really surprised that people are trying to make open source something it's not because closed source has become such a boogyman. There is a very real practical need for companies that write software to use Copyright to protect their business -- there's nothing evil about it! It's what Copyright is for!

This kind of "screw the big guys" is something I can totally get behind -- power to them for setting the terms of their relationship with them but it's not and shouldn't be open source. And that should be okay. The right to run a piece of software for any purpose whatsoever is fundamental to the spirit of open source.


I have a different take on this. It is open source in spirit. It has all the same freedoms of an OSI open source license with one restriction that matters to maybe half a dozen companies like AWS. Open source is the closest established concept to compare this to. So to say it's open source in spirit, or similar to open source seems to be a legitimate communication device.

That's like trying to describe a nectarine without talking about peaches or plums. You could do it, but you could communicate more effectively if you could make comparisons to the most similar well known concept.

They are somewhat careful to make the distinction and refer to it as source available, open source in spirit, etc. I think that's fine and legitimate communication.

Source available is a less controversial term, but it's also less descriptive. It can be a wide variety of software licenses. Whereas open source is much closer to this license. I don't see the problem here, how would you communicate it if you worked in their marketing department, if you're being honest?


> how would you communicate it if you worked in their marketing department, if you're being honest?

I'd emphasize that both an "Open Source" offering and a more complete "Permissive Source Available" offering were available. The goal would be to contrast the source-available offering favorably with closed-source proprietary offerings, rather than to invite, needlessly, a possibly unflattering comparison with Open Source.

But how about just not picking a fight with the Open Source community?

The argument over field-of-use restrictions is anything but new, so going in with the notion you're going to either win everybody over or that people are going to quietly roll over is foolish.

The other possibility is that you deliberately pick a fight with the Open Source community for the sake of publicity. Some marketers are cynical enough to do that, but I'm not — and Timescale are not taking a combative approach and don't seem to be either.

But people really ought to know by now that attempting to coopt the term "Open Source" is certain to provoke an infuriated and vocal response. This latest wave has been going on for what, a year or two by now?


I don't see it is a picking a fight at all, and I'm petty sure that's counter to their intentions. I really don't get why some people get upset here. Nobody is saying it is OSI open source. But it's the next closest thing, so a comparison is natural and effective communication.


> But it's the next closest thing

That's not meaningful; there's a reason why the FSF and OSI have very similar criteria that end up being essentially identical in practical application; the value associated with F/OSS isn't on a smooth continuum that varies with proximity to those definitions, there's a very sharp cliff near the edge and this is outside of it.

That other actors are free to commercially exploit, including offering SaaS versions without restriction, the software is a major benefit against vendor lock-in for users, even if they have no desire to exercise that freedom directly, and has important effects on building a diverse, invested community around a piece of software. Restricting this to allow rent extraction, while not unethical (outside of, e.g., the ideological framework of the idealistic Free Software community, as opposed to the F/OSS for pragmatic reasons communiry) in the same way other proprietary-licensed commercial software is not unethical, does not even approximate the value of F/OSS.

Vendors can keep having proprietary rent-protection licenses, they just need to stop trying to convince the Open Source community that they are somehow pragmatically equivalent to Open Source. They aren't, even approximately, and critically that is the entire reason that vendors choose them, so they need to stop the dishonest sales pitches.


> they just need to stop trying to convince the Open Source community that they are somehow pragmatically equivalent to Open Source

But it is nearly functionally identical, that's the fact of the matter. It's open source with one tiny restriction that matters to nearly nobody. That sounds pragmatically equivalent to me, from the definitions of those words. I find your claim more dishonest than theirs on that basis. You're trying to say it's a far cry from open source, and that's just not the case.


>But it is nearly functionally identical, that's the fact of the matter

No, its not. Its superficially similar (in much the same way that, say, the Constitution of the USSR was superficially similar to a liberal democratic constitution), but not having key commercial uses reserved for a rent-seeking copyright owner is central to the function of F/OSS.

> It's open source with one tiny restriction that matters to nearly nobody.

It matters to lots of people; sure, very few people are likely to directly exercise it, but that others are free to exercise it is central to the value proposition of open source for other users.


I disagree completely. I'm trying to understand where you're coming from, but I just don't. I think we have irreconcilable viewpoints here, and there's no further discussion possible.


The definitions of almost everything in our lives change over time. I would want to be practical and live in a world where words don't only mean what they used to when they were created but also are revised.

Open source is a philosophy which I have always admired and it motivated my way of thinking. But I can not accept that a few large corporations want to apply their monopoly and scale to single handedly reap the benifits.

Stopping them is vitally important to preserve those exact freedoms that open source gives us.

The Open source movement was not created in an environment where there was such massive centralisation of computing resources and their financial implications. How do you know if the Open source movement itself wouldn't have started differently in an environment like today's?


I think fundamentally open source has to evolve to reflect the new realities of the cloud world, or it will cease to be relevant for commercial software. And maybe that's fine, maybe open source becomes something only used for non commercial software with no profit angle behind it. And some new thing closer to this timescale license will replace it in the for profit but still open domain.


> > open-source in spirit

> It ain't. It is firmly in the spirit of "source available" licenses

Let's put a few more of the OP's words around that:

> a source-available license that was open-source in spirit, but


https://people.debian.org/~bap/dfsg-faq.html

https://en.wikipedia.org/wiki/The_Free_Software_Definition#T...

https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...

The litmus test has always been: "while you may not want your software used in a weapon of mass destruction (or other purpose you don't agree with), it is not free software / open source unless it can be used for that purpose" ... those are items #5 and #6 in the DFSG guidelines.

While Mr. Torvalds may have been a much richer man if he prohibited "Linux as a Service", it was the unrestricted freedom given by the GPL which allowed companies like Amazon/AWS to use Linux in the first place.


This. It boils down to "words mean things". They're fine being firmly on the side of proprietary-with-some-preservation-of-rights; it is _their_ code after all. Their customers get to decide what level of rights they're happy with putting up with.

They're not Open Source. They're not Free Software. Being part of those communities requires following the norms of those communities.


Appreciate the sentiment. We try pretty hard to be careful to not describe the Timescale Licensed code as Open Source, and typically refer to it as "source available".

Of course, a big portion of our code is licensed under Apache 2, which clearly does qualify.

From the Timescale License, for example:

https://www.timescale.com/legal/licenses#section-0-backgroun...

Thanks!


My comment was more directed toward the grandparent, which had their own set of comments regarding Open Source software. By and large, I'm happy with the announcement and how you're handling these terms carefully.

My only nitpick is the repeated statement of:

> a source-available license that was open-source in spirit

Which, um, it's not. I understand you're trying to thread a needle here and protect your business but it's not following the "spirit" of the community. You're removing a rather fundamental freedom by introducing your own license. That's rather antithetical to the whole idea of Open Source


Companies like TimeScale should call themselves "source available companies" in order to signal that they are offering some degree of access to the source (which is good!) while avoiding some of the by-now well-understood pitfalls of trying to commercialize FOSS offerings.


I disagree. "source available" already has a long established meaning, and one that it far more restrictive than the TSL.

The TSL actually lets you do a lot - almost anything, really. It's an open source license (I even used little o's!) that is designed to only prevent cloud providers from selling TimescaleDB as a service.


Then you could call it a permissive source available license, or other such verbiage. There's no need to continue to call it "open source in spirit."


"The usage of pork broth in an otherwise vegetarian dish is vegetarian in spirit."

I can't help but wonder if they're using the phrase "open source in spirit" to leech the branding of open source (while ironically treating other companies as leeches).


That's exactly why they're doing it. They want to have their cake and eat it too.


> "source available" already has a long established meaning, and one that it far more restrictive than the TSL.

The established meaning is “any non-F/OSS licenses that nevertheless provides free access to source code, which may or may not also provide some usage rights”

TSL is exactly that.

There might be some utility to a name for a new subcategory of source available, but it's not meaningfully similar to open source since it remains, ultimately, a traditional, rent-protection proprietary license. The fact that current market conditions give a very particular rent-extracting opportunity that the vendor wants to protect and the vendor focussed rent protection where the most value is...is not unusual, even if the exact current valuable rent-extraction opportunity is different than it was even a few years ago.


> I disagree. "source available" already has a long established meaning, and one that it far more restrictive than the TSL.

It doesn't really - it's been used to describe a pretty broad range of licenses. "Source available" means you can read the source but do not have all of the rights you'd get from an open source license. Which is the case for TSL.


"source available" isn't a great term, since it's relatively strongly associated with "you can look but not touch it" licenses.

A dedicated term probably makes sense. Some other licenses in this space have used terms like "fair licenses".


> it's not following the "spirit" of the community.

Which community are you speaking for here? "Free Software" or "Open Source"? They are separate communities with a long history of rivalry between each other.

https://www.gnu.org/philosophy/open-source-misses-the-point....

https://en.wikipedia.org/w/index.php?title=Open_Source_Initi...


If it matters or not... as an unaffected person, but an open source + license nerd, I like the outcome of what you've done. (and yes... "open source in spirit" seems like your hearts are in the right place).

When you're talking about the licenses I think it's great that you've introduced the talking points of "right to repair/improve" ... that's something which is guaranteed via DFSG (b/c you can do what you want with it), but it's great to see it called out as a more fundamental concept expressed in "non-legalese".

You're also looking at "protections" which could be called out as: "the protection from $CLOUD_PROVIDER taking our work and using it to strangle our company and the people who made it" ... probably with a different wording though.

Have you considered writing down a set of principles / protections which you could rally other businesses around as well? Something like the DFSG guidelines, but organized around protecting potential revenue streams?

What would it look like if you had another option / logo on the creative commons license picker? (ie: "$NO + $CLOUD + $MONEY")... https://creativecommons.org/choose/

What would your "Timescale Monetizeable Source Available Guidelines" look like, and could they be expressed as snappily as you've expresed "Right to Repair" and "Right to Improve"?


(people forget how radical `Copyleft` was at the time of its inception!)


That's a reasonable, if somewhat puritan position, I just think it's not one you should build a company around. If you're considering an OSI open source license for your main product today, don't make that mistake, it may kill your company. I want to point out that having a healthy company behind a product makes it more valuable to its users, regardless of how it's licensed.

If you have no interest in building a business around your product, because it's a labor of love or not central to your company, then by all means use a FOSS license. Apache 2 is a great choice.


I was missing this wikipedia link from your list: https://en.wikipedia.org/wiki/The_Open_Source_Definition


This is certainly a great improvement in the license! Kudos to TimescaleDB.

I wonder if the new license allows us to offer services on top of TimescaleDB in a multi-tenant setting. GitLab.com has metric monitoring https://docs.gitlab.com/ee/operations/metrics/ and we're considering using TimescaleDB to store these. We would not offer direct access to the database.

The relevant section in the license https://www.timescale.com/legal/licenses seems to be the prohibition to "provide any form of software-as-a-service or service offering in which the TSL Licensed Software is offered or made available to third parties to provide time-series database functions or operations, other than as part of Your Value Added Products or Services".

I'm not sure if metrics count as time-series database functions or operations.


I posted below, but an important check really is the definition of the "Value Added Product or Service".

https://www.timescale.com/legal/licenses#section-3-10-value-...

On its face, it sounds like your use case is totally allowed under the TSL (and in fact, since the TSL was initially launched in Dec 2018). We have plenty of users who build commercially-available monitoring products/services on top of TimescaleDB.

Happy to help if you'd like - our engineers are always available in our Slack Channel: https://slack.timescale.com/

UPDATED: Ha! I didn't realize I was responding to the CEO of GitLab. =)


And that is why HN is my favorite part of the net for about a decade now :)


Thanks for the clarification, glad to hear it is allowed.


It seems to me, herein lies the rub. No whether they can call it open source or not. I am sympathetic to Timescale's situation. (I also love their work) But the big problem IMO is this incredibly hard to judge language about "value-added products or services"

It doesn't really matter what is opined outside of the agreement, and from this conversation, it doesn't seem crystal clear one way or another whether Gitlab's use would be considered value-added or not.

So, do you want to be a developer, project-manager, CTO, or CEO who has to determine if your use of TimescaleDB is considered value-added or not?

Also keep in mind, that to really make this determination requires a court case around the specifics of your usage and situation.

And what if they get a SCO Unix style CEO someday?

I hope we can find a better way as developers and technologists to express whether you can use software like this without vague promises that you won't be litigated, or your use case is probably not in violation of the license.


Hi @camkego We tried pretty hard to define a pretty specific definition of "Value Added Service" for TimescaleDB, which is why the license also has some "custom" aspects rather than just having a general clause about "can't be competitive" with us. So the definition is here, and an example of walking through a "test":

https://www.timescale.com/legal/licenses#section-3-10-value-...

    3.10 "Value Added Products or Services" means products or services developed by or for You that utilize (for example, as a back-end function or part of a software stack) all or parts of the Timescale Software to provide time-series database storage and operations in support of larger value-added products or services (for example, an IoT platform or vertical-specific application) with respect to which all of the following are true:

    (i) such value-added products or services are not primarily database storage or operations products or services;

    (ii) such value-added products or services add substantial value of a different nature to the time-series database storage and operations afforded by the Timescale Software and are the key functions upon which such products or services are offered and marketed; and

    (iii) users of such Value Added Products or Services are 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.

So for the GitLab monitoring service, given my understand from the short description:

1. Is the service other than primarily a database storage service? [Yes]

2. Does it offer substantial value over a database and is it offered/marketed for a key function other than a database? [Yes, it is a monitoring system, not a database system]

3. Are users of the monitoring system prevented from defining schema and accessing database DDL? [Yes]

Of course, we _very much_ welcome feedback how to make it clearer or more explicit. Our goal is _not_ to create uncertainty.


I think that your use-case would be fine.

Most people don't seem to realize that the idea behind this kind of legalese is to prevent companies like amazon from offering something like "elastic timescaledb" which is mostly an operated timescale service, eating TimescaleDB's (the company) revenue stream. Or similar things happening in either Google cloud or Microsoft Azure.

I can't really blame for that.


Also not a lawyer but it appears the bar is that "(2) the 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."

For Timescale this may not be as relevant, but I do wonder how a license like this would be applicable to systems like Salesforce, which allows you to define a schema of custom fields, or for someone using an Entity-Attribute-Value type of schema. What is a database operation - is summing over a dimension a database operation? Where does data end and schema begin? These licenses are entering uncharted territory.


Storing JSON or EAV-format data do not require DDL access, and are commonly deployed in many settings, from product/SaaS analytics, IoT, IT/APM monitoring, and others.

That's actually one of the reasons we tried to frame it in terms of interfaces as well.

(Thanks for the question/interest!)


Our data is binary with a complex format (protobuf). We have custom logic to merge these data points. I guess this would not be covered by the license then


Not sure I follow?

The parent poster was asking about "well, isn't it an issue with your TSL definition of 'DDL schema access' if you can store data in JSON or EAV so it doesn't have a 'fixed schema'", and my answer is: No, that's fine.

Just like it would be fine for you to store or use binary/blobs/arrays/whatever. We've seen some crazy/cool use cases like developers storing binary 3D lidar data in TimescaleDB.

In fact, with these "right-to-improve" changes, you could even modify the database to embed custom logic inside TimescaleDB to handle your protobuf format (as opposed to UDFs or application code), and it would still be permitted.


I would guess that jsonb columns or Entity-Attribute-Value type of schemas are permitted, but if doing something in a grey area it wouldn't hurt to reach out to the company and get permission in writing (or negotiate a license exception.)

Or just pay for their managed service, you probably don't want to be fiddling around with hosting the database yourself. At least everywhere I've worked we used RDS for precisely that reason.


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


> because I don't know what the license permits

That's why you read it...


Yes, and then, if I'm smart, spend time and money discussing it with attorneys and/or other experts, who will probably tell me that they don't know either, because there is no body of case law concerning this new and unique "special snowflake" of a license..., etc, etc.

Of course I could just "wing it", read through it, and work off my layman's interpretation and hope for the best. Or.. I could choose to stick to well understood and well known licenses that already exist.


I agree in general that reading licenses as a lay person can be problematic.

In this case though, TimescaleDB has blog posts that describe the license in very plain language, and provide clear examples of what you can and can't do - you can basically do anything except provide it as a service. No need to "wing it".


It's really the general case that I'm interested in. Understanding and dealing with different licenses doesn't necessarily scale well, which is exactly why license proliferation is a Bad Thing.

For those people who use Timescale and really like it, and are willing to read and understand this license and then use it, I say "Great!" But in general I find license proliferation to be undesirable and would generally encourage organizations to use standard licenses.


Fair point, I agree with everything you've said here.

I do think there is a need for a TSL-like license though, and I think the solution is a new type of widely accepted and understood license, rather than individual companies inventing their own TSL-like licenses.

I have no idea how that could actually come to be though.


The "standard licenses" you're talking about weren't standard until people actually started using them.

People can't start using licenses if you don't first write them.


That's fair. And if there's a market for this kind of license, then it will catch on. And if it does, then so be it. I doubt it's a license I'd use, but I don't begrudge these guys any success they have.


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.


With the release cadence of the current major distros vs the pace at which software is released, it doesn't seem to be worth it to get your stuff in the official repos, to quickly be several major versions behind.

You can package debs or rpms for easy install, host them on a server (or set up an apt/rpm repo) just fine even if they're not FOSS.


Yep, they even quoted some recent HN comments in the article.

I have absolutely no doubt that a small but vocal minority will remain unsatisfied. I'm not surprised by this move, as there was barely anything left in the Enterprise license anyway. Personally, I think this is a great move, and one that should in theory leave that vocal minority with very little to actually grumble about.


I likely qualify as "vocal minority". These changes make TimescaleDB something I could entertain using.

My concerns related to the "right-to-repair" / "right-to-improve", and with vendor lock-in. These changes address my concerns handily.


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

It's almost as if the, in practical terms, near-identical standards of the OSI and FSF weren't just picked haphazardly from the air, but actually reflect the result of a thorough and detailed consideration of what features are necessary to unlock the value that OSI pursues mainly from a pragmatic angle and FSF pursues mainly from an ideological angle, and that all the elements of that standard I react in a way that there is a crisp rather than smooth falloff in achieving the sought-after value when not all the criteria are met.

> Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale

Preventing competitive services is the same thing as protecting lock-in and rent extraction. Now, that is a central purpose of copyright and the traditional focus of proprietary licensing, so that’s not a novel focus of licensing at all. It is, however, directly opposed to the central purpose and value of F/OSS to end-users as well as downstream developers, both from a pragmatic/economic and ideological perspective.

> That's a glaring short-coming of FOSS licenses

No, it's the central purpose and value of F/OSS licenses. It's a shortcoming from the perspective of prospective rentiers, sure, but that's not an incidental side effect unrelated to why F/OSS is sought by those who seek it; freedom from rentiers is the whole point.


The new Timescale License doesn't only restrict AWS, it restricts anyone not Timescale from offering management services for the Timescale Licensed code. It restricts customers who find that Timescale is unable or unwilling to support them in an agree-able manner from paying some one else to manage it for them.

All that is fine and dandy- it is clear that Timescale is open-core, with an Apache-licensed core and proprietary components, just like gitlab and other products. (Timescale is a bit more generous with their proprietary code, though, so that's nice).

I will stick with strongly favoring building on open source code, myself, despite this generous offer of no-fee license to use their proprietary software.


> It restricts customers who find that Timescale is unable or unwilling to support them in an agree-able manner from paying some one else to manage it for them.

It restricts Customers from going to a Timescale-as-a-Service provider, but I don't see how it restricts the Customer from contracting to have a third-party support the Customer's Timescale installation (or to make changes to the codebase as a work-for-hire).

I agree w/ your assessment of their new license insofar as it being proprietary. Their old proprietary license made the product unacceptable for my use, but I am comfortable with the limitations to my rights with the new proprietary license. It has enough "right-to-repair" and ability to avoid vendor lock-in to make me feel comfortable that I could maintain a private fork of my use case was dependent on their software.

Edit:

My first paragraph was a quick-and-dirty. The child post is absolutely right. The license restricts Customers from providing Timescale-as-a-Service services.


As I understand it, it doesn’t restrict customers from going to a TSAAS provider, it simply means that if you want to provide TSAAS then you need to negotiate a different license from Timescale.

The only restriction is that you can’t (necessarily) provide TSAAS for free. To me that’s free as in speech but not free as in beer, and is well within my personal understanding of “free software”. As the saying goes, the right to speech doesn’t imply the right to be heard; likewise, the right to inspect and modify software doesn’t necessarily imply the right to profit from it.


You're totally right re: being a TSAAS provider. I was writing on mobile, in a hurry, and didn't compose my thoughts well.

I don't believe Timescale is Free software or Open Source. It's proprietary source-available software. I wish all software was Free software, but I don't have the fortitude to restrict the software I use to only Free software. Timescale is "Free" enough with this license that I'd consider using it in my personal workflow, or in a business environment.


Anyone could theoretically negotiate a different license with any software vendor... that's not a feature of the license they are generally offering the software under, its a feature of the legal system of contracts.


The inability to maintain a public fork is another strike against the Timescale License. If the company were to shut down or move in a different direction, a community could not form to maintain a fork that meets that communities needs.

If these terms are acceptable to you, that is great, but I find the unpalatable for core infrastructure I would be investing substantially to build on top of.


Maybe that's just the natural progression for technologies that are dependencies of other technologies. As a software business you don't want to depend on too many pieces of software (or hardware) that you have little to no control over. Linux is the best example of a solution for that problem - even the tech giants won't bother making their own OS anymore if there is already one out there that they can use and modify. And ISAs (RISC-V) will probably follow that route too.

What's interesting though is that businesses seem to be unable to initiate that progress on their own. You need those vocal FOSS people for that, who will tirelessly drag technology towards an ideal we'll never reach... but nobody else will get the ball rolling. FOSS as the basis for entire ecosystems of businesses that would have never existed without it makes total sense, but no business will create it out of thin air. I think this gradual opening up like with TimescaleDB is simply an effect of the wind blowing in that direction. Few will be going full speed, but nobody wants to be left behind.


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


The SSPL has at least some hope of potentially being a viable FOSS license; the disagreements around that license were around details and implementation, not necessarily critical unfixable issues. Something like the Timescale license fundamentally can never be a FOSS license.


I don't agree, Josh. Certainly not v1 (which, AFAIK, is the only version in use). I doubt v2 could gain broad support either.


I'm not suggesting it could trivially become an OSI-approved license. Rather, I think it's much closer in spirit than something like the Timescale or "Commons Clause" or similar licenses, that blatantly discriminate against fields of endeavor (OSD 6) by design. The SSPL, by contrast, is a copyleft license that has a much stronger copyleft than the AGPL. It may potentially be overstepping the intent of what the OSD means to allow, but it doesn't on its face violate the spirit of any of those clauses, not any more so than the AGPL does. I think it'd be possible to modify the SSPL into a version that could meet that agreement while maintaining the intent of the license.


To me it violates the spirit of OSD9.


Ah, got it.

I personally feel like the spirit of OSD9 is primarily about not affecting unrelated programs. I think it'd be reasonable to affect related programs. I think the current version of SSPL oversteps wildly in that regard, but I feel like it could be pared back to something that would be consistent with what I'd consider to be the spirit of OSD9 (and the rest of the OSD), while still doing what it seems like the SSPL is trying to do.

In doing so, I'd focus on "such that a user could run an instance of the service using the Service Source Code you make available", and drop all the specific service examples in favor of something like "any software you have made the Program depend on, such that the Program lacks some functionality compared to your service if that software is not present (even if you have made the Program support running without that functionality)". That would be broader than the comparable boundary of the AGPL, but much narrower than the current SSPL, insofar as it would only cover things the Program has been modified to depend on, rather than surrounding hosting infrastructure.

In any case, I don't think it very likely that MongoDB would be willing to make such changes, but if they did, I think it'd be possible to arrive at a license that would pass the OSD.


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

Sure, but if the problem is "leeching off their software without paying for it", then being obligated to share their changes should fix the "leeching" bit. I mean, is Amazon leeching off Linux by shipping it on all their devices?


My own perspective is that companies should probably stop saying that "if only Amazon would contribute back the occasional patch, everything would be fine."

If much of the future is cloud, then getting the hyper-scalars to contribute occasional patches doesn't solve the problem of competition.

That's reflected in our post:

    Some may ask, “Why create a new license - why not just compete
    with public clouds by just providing the best product experience
    on a level playing field?”

    The problem is that the playing field is far from level.
    Today, the public cloud vendors (Amazon, Microsoft, Google)
    are trillion dollar corporations – the largest companies in
    the world – and have a myriad of advantages that arise from
    that size, including market position, pricing power, deep
    balance sheets, and (what many have even called) unfair
    business practices. They lock large customers into prepaid, 
    discounted, multi-year enterprise-wide agreements, and give
    startups $100,000s of free credits.
Now, non-profits like the Linux Foundation are not trying to solve for this same problem.

But I think that the tech and innovation ecosystem would be much for the worst if everybody else is hamstrung when competing in the cloud, or else just have to go fully closed source and proprietary.


Can you honestly say this license is trying to solve for the same problem, rather than just carving a niche for your own business at the expense of other businesses, e.g. other startups who might be able to offer a better service contract to the public cloud vendors? Because it's hard for me to imagine it differently the way these are worded.

This is my main problem with this type of licenses, none of them really seem to have any interest in actually getting the public cloud vendors to compete or buy services or contribute (financially or otherwise) to the upstream project. It just perpetuates the problem because now your company is the one doing it by telling customers they have to sign your agreement and can never buy from any other vendor. I'm sorry if this is an overly negative assessment but I just can't see it as much more than passing the buck when there is no attempt at reciprocity, through copyleft or through some other means. (As much as I had criticism of the SSPL, at least it tried to have this)


It looks like public cloud providers (really mostly AWS) will never ever contribute enough to upstream to support full-time upstream development teams and no one has enough leverage to change that situation. Given that reality, the only solution is what Timescale has come up with.


I know, I get that, but long-term this seems like non-solution that won't actually do anything. It just ties it to their service offering instead of Amazon's. If they decide to sell out to Amazon eventually they'll probably be able to bid the price higher. That's good for them, and if their customers are fine with it, then that's good for them too, but let's not pretend it's something more. I know in current times I certainly wouldn't trust a database with performance/uptime guarantees, where the authors are hiding the implementation from public scrutiny.

If you're going to tell me your company is actually worth a trillion quid and can really compete with AWS then I would see your point, but otherwise I can't see a way that this is going to make the market better for anyone besides the other small fraction of companies that have come up with similar ideas of banning Amazon. (Full disclosure: I'm in the same boat and I personally refuse to purchase any products or services from Amazon, but I acknowledge I'm in the severe minority)


    where the authors are hiding the implementation 
    from public scrutiny
We agree that such visibility is a good thing! All of our source code (both Apache-2 and TSL) has always been public on github:

https://github.com/timescale/timescaledb


Sorry I should have been more clear. It appears you still do that because it's the bare minimum you need to do to keep customers from leaving for Amazon. But if that's where you stop then I can't see how it's solving the problem.


Amazon contributing their changes (if they even do any) but taking the majority of hosting income doesn't fix the business model for the company making the software.

Linux has an entirely different scenario for the economics around it, so from the "does this work financially" perspective the comparison isn't all that helpful.


How does AGPL address this?


The original problem was Amazon "leeching off their software without paying for it". If Amazon shares their changes (as the AGPL requires), then they're contributing, not leeching. If the problem is just that Amazon happens to use a product, or horror of horrors, offer a hosted version... I dunno, I just can't see what the issue is. Is every developer upset about people profiting off their work sending a monthly check to Linus Torvalds for using Linux, Apple for clang and/or GNU for gcc, and the maintainers of their distro of choice? Or is only their software that nobody else is allowed to make money off of?


Timescaledb the company wants to make money from their managed service, thus they are protecting it from competition. That’s fine. They are not true open source but that’s fine too.


Agreed. I don't mind companies selling proprietary software. I do mind companies trying to claim that they're offering open source software when they're actually offering source-available software. With the Apache2 version, Timescale actually appears to be doing both, but I can't find a description of the differences so I can't comment very well; I assume they're doing open core. Which, again, is fine as long as you don't try and pretend that you're doing something else.


Yes, our offering is of the "open core" nature, although our non-open-source code is covered under the Timescale License (source available, free). For most "open core" companies, this latter part is instead closed-source and paid, hence this terminology also leads to confusion :)

Anyway, here's the link to license pointers in github, and you can find all code there:

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

    Source code in this repository is variously licensed under the Apache License Version 2.0, an Apache compatible license, or the Timescale License.

    All source code should have information at the beginning of its respective file which specifies its licensing information.

    * Outside of the "tsl" directory, source code in a given file is licensed under the Apache License Version 2.0, unless otherwise noted (e.g., an Apache-compatible license).

    * Within the "tsl" folder, source code in a given file is licensed under the Timescale License, unless otherwise noted.

    When built, separate shared object files are generated for the Apache-licensed source code and the Timescale-licensed source code. The shared object binaries that contain `-tsl` in their name are licensed under the Timescale License.


If Linus had wanted users to pay him I certainly wouldn't pay a different company for it, if they just copied his code and didn't forward of the money on...

I do wonder, in a non-free world like that, if we'd have a higher proportion of "tech giants" still in the "making software" space instead of being so advertising-centric with Google, Facebook, etc's, main revenue streams.


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


Yeah it's perfectly fine that they make a product under this license, as going full closed source would be perfectly fine as well. But it's not open source.


Yes, it is necessary to prevent the core purpose of open source.

Which is fine, proprietary licenses are a valid option. Just don’t pretend it's almost open source. It's a source-available proprietary license designed to prevent the kind of exclusionary rent-extraction whose absence is central to the value proposition of open source.


There is just one tiny little thing missing - the license is not generic. I believe a big driver for success of FOSS licenses is that you don't need a lawyer to use them (either as a user or as developer). We are seeing quite a few businesses using these "Cloud Protection Licenses", but they would all benefit if they agreed on a single, well understood legal document (or at least only a few of them, all generic).

I wonder if Commons Clause was just too early?


Hopefully the CockroachDB folks are reading this too. The features set behind the enterprise only license seem arbitrary


These are never arbitrary. They are almost always the result of a lot of internal discussions the outcome of which no one is really happy with.


Agree, they don't even have backups in the non-enterprise license.


They don’t have incremental backups. You are of course able to dump the tables, and it’s fully compatible with postgresql export utilities.


I just want to point out that if Postgres had a similar license then Timescale wouldn't be able to offer their product as a service.


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

Don't forget that Timescale can alter the terms of their license at any time. That's the material difference from an OSI-approved license.

Here's the relevant term of the TSL Agreement. Emphasis mine:

> (c) Distribution of Source Code or Binaries in Standalone Form. Subject to the prohibitions in Section 2.2 below, a license to copy and distribute the Timescale Software source code and binaries solely in unmodified standalone form and subject to the terms and conditions of the most current version of this TSL Agreement.


Not really. Modifications only apply to next versions, doesn't change to prior versions:

  The modified agreement shall govern any new version of the TSL Licensed Software
  (and all its constituent source code and binaries) that is officially released as
  a complete version release by Timescale on or after such Posted Date.
https://www.timescale.com/legal/licenses#section-7-2-modific...


Thanks, I was looking for that and could not find it.

The point remains that there's nothing to protect users from changes in licenses like the TSL. It's possible with FOSS licenses provided you own all copyrights but much less likely.


And not to mention profiting off of the patches and fixes the maintainers provide and almost never contributing back. I am definitely happy to see attempts to help the creators.


> 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

If you're calling your potential licensees leeches, you probably don't have Open Source in mind.


Its kind of tricky, in terms of the license how do you end up with that practical limitation? IE how do you distinguish a company thats "too big" (like amazon) to be likely to just be predatorially taking advantage of OSS, vs others.


Thanks for question.

One of the things that Timescale License does (similar with Elastic, Confluent Community, etc.) is to define a "Value Added Service", and basically say you can utilize/distribute the database as part of a SaaS service or product provided that it's a Value Added Service/Product, and basically just isn't offering the (in our case) "TimescaleDB-as-a-Service".

Then it becomes a bit of reading the actual definition in the license. In our case:

https://www.timescale.com/legal/licenses#section-3-10-value-...

Unlike the other licenses, we tried to couch part of this definition is specific details that engineers could understand, e.g.

"(iii) users of such Value Added Products or Services are 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."

So basically one important test would be: if your SaaS service is defining the data schema, indexes, etc., all good. If your users have arbitrary DDL access to the database and do this all themselves, that would "classify" as a "database-as-a-service" offering under this definition.


Many new open source companies, like Timescale, Cockroach Labs are going with a managed cloud service offering as their business model. Even RethinkDB pivoted in that direction, although too late in the game for them to survive. So one could make an open-source license specifically reserving that freedom for the creators only.

There are probably other business models one could try to protect. The basic idea I think is give as much freedom as possible while also providing some protection for specific use cases that allow the creators to be compensated for their work. It benefits nobody if you create a wild west of freedoms that deny creators a way to finance their work.


You can't distribute changes to the source code. This is a read-only license.

That's both a practical limitation and a serious criticism of a company that markets itself as open source.


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.


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

Thank you for putting this so succinctly.


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.


Language matters and distinctions matter and branding matters. If you believe that OSS > Source Available > Closed Source that doesn't mean you want the concept of OSS to be diluted by Source Available. If you want to release a Source Available piece of code then all the power to you. But don't call it Open Source Software (or whatever vague variant of that implication you use) unless it actually is. Source Available should stand or fall on it's own merits and not by trying to co-opt the goodwill that OSS has built up over the last many decades.

edit: This is a license that doesn't allow source code modifications to be released and only after feedback does it even allow you to run source code modifications privately. That very much is not in the "spirit of open source."


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


Yeah, this is basically closed source software with source code available for viewing. Just because Microsoft allows the windows source code to be viewed by some institutions doesn't make windows open source. There's room for debate on open source vs. not open source thing but I don't see how this falls into the gray area. When you're not allowing forking and distributing modifications then I feel it falls squarely into not open source.


> 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


The version available in Digital Ocean's managed Postgres product is the Apache-2 edition of TimescaleDB. It doesn't included advanced capabilities like native compression, multi-node, continuous aggregations, etc.


> 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 is a totally fair comment. Thanks for bringing it to our attention.

I've removed the Wikipedia link and any mention of OSI "controversy".

However, I do believe sentiment is shifting (as can be seen in these comments), so I left that part in.

Thanks for helping us improve the post :)


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.


This exactly! All the stuff from Redis, Elastic and others whilst they have terrible 'cloud' offerings, of course I'd rather use Aws, they make it really simple, reliable and don't charge too much, meanwhile none of these have terraform plugins and the price is insane.


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.


Aww, thanks =) We are good co-editors for each other!

We have a fun and long co-founder history, actually, going back >20 years. So lots of experience doing so!


Aw yes, thank you :)

We do write these posts (and as other folks at Timescale will attest, we are also notoriously picky editors for other peoples' posts)

We've been writing together for a long-time. One of my favorite memories at MIT was working on a joint 6.033 paper with Mike 20 years ago (some of you will know what I'm talking about).

Probably lost to the early Internet dustbin tho :)

UPDATE: I found it! http://www.scs.stanford.edu/~mfreed/docs/6.033/smartcard.pdf


Oof. Making undergrad course project reports available for the world to see! ;)

The third member of that team has also built some pretty cool technology -- maybe behind some of the music you're listening to right now:

https://www.izotope.com/


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 would not use any PolyForm Shield licensed software, since there is no guarantee that the provider will never expand their scope of business to compete with me.

The Perimeter variant might be usable, but only if competing with versions of the product I don't use is allowed (it's not clear to me if that's the case)


Please read the license terms carefully.

New Products

If you are using the software to provide a product that does not compete, but the licensor or any of its affiliates brings your product into competition by providing a new version of the software or another product using the software, you may continue using versions of the software available under these terms beforehand to provide your competing product, but not any later versions.

Discontinued Products

You may begin using the software to compete with a product or service that the licensor or any of its affiliates has stopped providing, unless the licensor includes a plain-text line beginning with Licensor Line of Business: with the software that mentions that line of business. For example:

Licensor Line of Business: YoyodyneCMS Content Management System (http://example.com/cms)


If I use the software, then the creator expands their business to compete with me, I can never update the software again.

Maybe this is software meant to work over the network and a security vulnerability is discovered. The license says I am stuck running a version with vulnerabilities until I can figure out how to use a different project. That's a deal-breaker.


The PolyForm Shield license prohibits competition with the original project, but then goes on to define "competition"

> Goods and services compete even when provided free of charge

If you host your project on Github under this license and I fork it, then my Github page is competing with yours and I am therefore in violation.


Please read the license terms carefully.

Distribution of the source code, modified or unmodified, would not be considered competition. On the contrary, it is an explicitly granted right. So, for example, forking on GitHub is allowed.

Distribution License

The licensor grants you an additional copyright license to distribute copies of the software. Your license to distribute covers distributing the software with changes and new works permitted by Changes and New Works License.


I did read it carefully, and provided thoughtful feedback.

> Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.

> Goods and services compete even when provided free of charge. If you market a product as a practical substitute for the software or another product, it definitely competes.

If I use your software and find a bug, I am prohibited from hosting a fork with a fix for the bug on Github as it would clearly be a practical substitute for the original.


I am using this quite successfully in Micro (https://github.com/micro/micro). Having spoken to one of the authors Heather Meeker, who wrote the majority of the custom licenses, I'm fairly confident it's going to become an industry standard. There is no point wasting time drafting custom licenses. Drop in Polyform Shield to defend against AWS and others in one simple move as you would have used MIT or Apache 2.0 licenses in the past.


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?


The distinction they try to make is whether or not timescale is a ‘value added’ thing or not. You can’t provide a customer with a hosted timescaledb for them to use as the service, but you can provide a dashboard that stores data in timescale.


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


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

1. Using "constraint exclusion" by looking at the SQL query and constaints on each chunk (e.g., their time interval), exclude certain chunks for the query.

2. "Push down" the query (often in parallel) to all non-excluded chunks, and collect/aggregate those results.

Various features in TimescaleDB will help even in your case:

1. You get parallelism to scan across chunks. If employing multi-node (TimescaleDB 2.x), you can parallelize these aggregations across servers.

2. You can employ native columnar compression, which gets like 94-97% compression rates, and allows you to organize your data based on selected keys (the "segmentby" parameter). So if you "segmentby" parent_id, it really collocates that data together, and enables much faster query.

Thanks for quesiton!

https://docs.timescale.com/

https://docs.timescale.com/latest/using-timescaledb/compress...

https://slack.timescale.com//


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.


> Compression and aggregation performance in TimescaleDB is much worse than ClickHouse

You are likely basing this off on an old version of TimescaleDB.

For the last year TimescaleDB has included native compression (in part by storing data in a columnar format):

https://blog.timescale.com/blog/building-columnar-compressio...

TimescaleDB now implements delta-delta, Gorilla, and other best-in-class compression algorithms:

https://blog.timescale.com/blog/time-series-compression-algo...

This has yielded 94%+ compression, which should make TimescaleDB and Clickhouse fairly similar in storage compression.


There is no technical tradeoff here. PostgreSQL could add a batched, vectorized and JITed execution engine, and ClickHouse could add "relational features". Either one would of course be a significant engineering project, but there is no fundamental breakthrough required. A small matter of programming as they say.


I haven't read all your docs exhaustively, but how do you solve joining your parallelized query results without running into spill problems? Or rather, how do you solve for spill?

Once your hypertables balloon to large sizes, you may be able to store handily across many Postgres instances, but collating the sub-queries will be costly. Spilling to e.g. S3 is a potential solution, but brings with it a new bag of problems, not to mention cost.


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?


Azure Postgres offers the Apache-2 Edition of TimescaleDB, not the Community Edition (which the TSL applies to). Same with DigitalOcean, Rackspace, Scaleways, Alibaba, etc.

So they can continue to offer the Apache-2 Edition, but could not before, and still can't, offer the Community Edition.

Community is where a lot of our more advanced features lie: multi-node, columnar compression, continuous and real-time aggregates, automation, advanced analytics, etc.


fwiw, I've spent 10 minutes scouring the timescale.com but I can't find any information about the difference between the Apache-2 Edition or the Community edition. Links from your GitHub readme suggest that such information used to be there, but now it's all "cloud" vs "software" - if I choose "software", which of the two editions do I get?

I assume this is still a WIP since the recent licensing / business model changes likely also warranted website changes, hence my feedback.

Congrats on the move btw, and fantastic that Timescale Cloud is working so well as a business model. Are you considering adding other clouds? I ask for selfish reasons as we're currently on Digital Ocean and quite happily so. If Timescale Cloud would exist for DO we'd likely become a customer.

In fact, if your business model succeeds and gets adopted by other open source vendors, supporting a wide range of clouds and hosting providers might very well help directly undermine the current effective oligopoly that is AWS/GCP/Azure! That'd be just splendid. Sorry for rambling a bit :-)


The "Software" column of product page [0], which I assume you are referring to, corresponds to our Community Edition, as least from a feature-set edition.

But thanks for the feedback. Always a balance between making things easily understandable and too much "in the weeds." We used to separately show "Community" and "Apache-2" on our feature matrix on product page, but frankly, it was too confusing / too much information for visitors that were just coming to TimescaleDB for the first time. Especially given that the vast, vast majority of deployments are indeed the Community edition.

For a detailed comparison, our docs should explicitly label all community features as "Community Edition". Otherwise, they are Apache-2. For example, see the labelling with compression [1], continuous aggregates [2], etc.

And we continue to provide binary packages for the Apache-2 edition of the TimescaleDB, which you can similarly find through our installation instructions (eg [3]).

[0] https://www.timescale.com/products

[1] https://docs.timescale.com/latest/api#compression

[2] https://docs.timescale.com/latest/api#continuous-aggregates

[3] https://docs.timescale.com/latest/getting-started/installati... ("apt-get timescaledb-oss-postgresql-12")


It is Apache version of TimescaleDB there (right?), which stays the same. While, those, who are using TimescaleDB under Timescale license, e.g., on premise, have now right to repair, for example.


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


Yes.


That is quite weird, i guess they'd never go after people for doing this "the right way". But it's not nice being in breach of license without ill intent.


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!


Agreed!

We run several instances in production and have had zero problems. TimescaleDB engineers, if you are watching / reading. Thank you VERY MUCH! You totally rock!


I'm using TimescaleDB for algo trading and it is performing beautifully. It's been rock solid and is handling everything being thrown at it (and in my case, it's every second of every day, yes weekends too).

edit: I have about 24,000 tables most with millions of rows. All 24,000 tables are touched at least daily. Often every few seconds.


This is all great to hear, and the whole team really loves this type of feedback/support from the community.

So thank YOU!

(Feel free to also reach out to me at mike (at) timescale anytime, or mike in slack.timescale.com)


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?


TimescaleDB (single-node) leverages Postgres features for HA (physical replication). It was never in the "enterprise tier", it fully works with the pure Apache 2 version.

We also make available k8s helm charts that make it super easy to setup replicated clusters, including with mechanisms (Patroni) for automated failure detection and failover, and continuous incremental backup. That's also available under the Apache-2 license:

https://github.com/timescale/timescaledb-kubernetes

(There used to be some slightly confusing language in our product page that perhaps led to some of your confusion, and apologies for that.)

For multi-node (available starting in TimescaleDB 2.0), we are working on more native mechanisms for replication. But as announced earlier, these will all be "community" features (free) under our Timescale License.


I've commented on it before, but I have to say again, the Timescale Helm charts are by far the best way I've ever seen a database run in Kubernetes, and actually from an operations, backup, and scaling perspective they are the best database management experience I've had period. Huge fan, always enjoy talking with Feike, and keep up the great work Timescale team.


Great job on the product! I was also very impressed with the support on slack channel, you guys rock!

One thing that I found confusing is that there is no clear explanation of the differences between the editions. Your answers are very clear and explain things nicely, but I would expect this information to be available on your site. Just a thumbs up. Keep up the good work!


Sounds great thank you.

Are there any docs on non-k8s setups? Maybe with docker-compose?


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?


Most of the enterprise features were moved actually moved into the Community tier in our 1.7 release, where we also announced that the upcoming multi-node would also be a Community feature:

https://blog.timescale.com/blog/timescaledb-1-7-fast-continu...

(Many thought that multi-node would be an enterprise feature, as that's somewhat common for databases.)

I believe that it was only data-tiering that was remaining/moved from enterprise to community as part of the 2.0 release. But the bigger thing is the "elimination" of the notion of enterprise / usage limits from the license and code base, as a statement for the future.


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.


I wouldn't look at it that way.

A company running on premises probably has a mindset that is okay with dealing with all the things related. And it probably operates at a scale where it can save a lot by not moving to the cloud. This is often jut not understood by a lot of people.

A company embracing the cloud doesn't want to do that and is just interested in services. They don't want hosts, they want service endpoints.

There are a lot of developer-centric companies for which operations and operational work is definitely not a core of the business, and have no interest in getting operational work and know-how in house.


> Turns out the need to keep your data on prem has been greatly exaggerated...

It's more like selling on-prem is slower and can lead to a slower growth ramp. The change may reflect pressure to focus on growth to ensure payback on investment. If you execute like Snowflake it accelerates revenue growth significantly.




Applications are open for YC Winter 2022

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

Search: