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.
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.
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 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'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
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.
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'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.
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
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'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.
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.
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.
> 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.
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."
> 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?
> 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 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.
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.
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 :)
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/
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)
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?
> 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.
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?
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!
[+] [-] slashdev|5 years ago|reply
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.
[+] [-] rectang|5 years ago|reply
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.
[+] [-] ramses0|5 years ago|reply
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.
[+] [-] sytse|5 years ago|reply
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.
[+] [-] mindcrime|5 years ago|reply
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
[+] [-] geofft|5 years ago|reply
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.
[+] [-] GordonS|5 years ago|reply
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.
[+] [-] dragonwriter|5 years ago|reply
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.
[+] [-] ensignavenger|5 years ago|reply
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.
[+] [-] Netcob|5 years ago|reply
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.
[+] [-] yjftsjthsd-h|5 years ago|reply
Then use AGPL?
[+] [-] est31|5 years ago|reply
Still seems like a serious issue to me.
[+] [-] Drdrdrq|5 years ago|reply
I wonder if Commons Clause was just too early?
[+] [-] gigatexal|5 years ago|reply
[+] [-] mcherm|5 years ago|reply
[+] [-] hodgesrm|5 years ago|reply
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.
[+] [-] aloknnikhil|5 years ago|reply
[+] [-] wyldfire|5 years ago|reply
If you're calling your potential licensees leeches, you probably don't have Open Source in mind.
[+] [-] nautilus12|5 years ago|reply
[+] [-] SquishyPanda23|5 years ago|reply
That's both a practical limitation and a serious criticism of a company that markets itself as open source.
[+] [-] Rebelgecko|5 years ago|reply
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.
[+] [-] doctor_eval|5 years ago|reply
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.
[+] [-] xyzzy_plugh|5 years ago|reply
Thank you for putting this so succinctly.
[+] [-] stavros|5 years ago|reply
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.
[+] [-] marcinzm|5 years ago|reply
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."
[+] [-] mixedCase|5 years ago|reply
[...]
> 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.
[+] [-] marcinzm|5 years ago|reply
[+] [-] skrebbel|5 years ago|reply
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
[+] [-] sneak|5 years ago|reply
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.
[+] [-] geofft|5 years ago|reply
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.
[+] [-] akulkarni|5 years ago|reply
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 :)
[+] [-] simonebrunozzi|5 years ago|reply
If they succeed, this could be the blueprint for many other companies in a similar situation.
Keep up the good work!
[+] [-] manigandham|5 years ago|reply
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.
[+] [-] mcfedr|5 years ago|reply
[+] [-] shay_ker|5 years ago|reply
Seems like table-stakes for anyone including the dev community when building databases these days.
[+] [-] mfreed|5 years ago|reply
We have a fun and long co-founder history, actually, going back >20 years. So lots of experience doing so!
[+] [-] akulkarni|5 years ago|reply
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
[+] [-] orlandohill|5 years ago|reply
PolyForm Shield would probably achieve the same result as the Timescale License. https://polyformproject.org/licenses/shield/1.0.0/
[+] [-] CodesInChaos|5 years ago|reply
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)
[+] [-] kdtsh|5 years ago|reply
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?
[+] [-] hardwaresofton|5 years ago|reply
> 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.
[+] [-] snarkypixel|5 years ago|reply
Basically, I'm trying to understand if Timescale is /only/ useful for timeseries or if it has good-enough performance for other use-cases.
[+] [-] jordz|5 years ago|reply
[+] [-] lillecarl|5 years ago|reply
[+] [-] andrewshadura|5 years ago|reply
[+] [-] didip|5 years ago|reply
[+] [-] ttsda|5 years ago|reply
[+] [-] nmaludy|5 years ago|reply
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!
[+] [-] mfreed|5 years ago|reply
So thank YOU!
(Feel free to also reach out to me at mike (at) timescale anytime, or mike in slack.timescale.com)
[+] [-] nottorp|5 years ago|reply