An update to the Timescale license
blog.timescale.com
blog.timescale.com
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.
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.
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.
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.
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. =)
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.
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.
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.
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.
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.
That's actually one of the reasons we tried to frame it in terms of interfaces as well.
(Thanks for the question/interest!)
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.
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.
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.
My concerns related to the "right-to-repair" / "right-to-improve", and with vendor lock-in. These changes address my concerns handily.
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.
Still seems like a serious issue to me.
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.
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.
Then use AGPL?
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.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.
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.
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.
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?
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.
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.
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)
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
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.
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.
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.
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
That's why you read it...
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.
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".
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.
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.
People can't start using licenses if you don't first write them.
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.
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.
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.
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.
They're not Open Source. They're not Free Software. Being part of those communities requires following the norms of those communities.
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 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
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.
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).
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.
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.
A dedicated term probably makes sense. Some other licenses in this space have used terms like "fair licenses".
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...
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"?
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.
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 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.
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.
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.
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.
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.
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.
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.
(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)
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!
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.
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.
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.
They succeeded quite well in that.
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.
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?
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.
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.
See also [2]
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.
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 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.
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.
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.
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
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.
> 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
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?
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?
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.
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.
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.
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?
If you're calling your potential licensees leeches, you probably don't have Open Source in mind.
I wonder if Commons Clause was just too early?
That's both a practical limitation and a serious criticism of a company that markets itself as open source.
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.
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.
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.
Thank you for putting this so succinctly.
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.
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 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.
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
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.
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.
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 :)
If they succeed, this could be the blueprint for many other companies in a similar situation.
Keep up the good work!
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.
Seems like table-stakes for anyone including the dev community when building databases these days.
We have a fun and long co-founder history, actually, going back >20 years. So lots of experience doing so!
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
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:
PolyForm Shield would probably achieve the same result as the Timescale License. https://polyformproject.org/licenses/shield/1.0.0/
> 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.
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.
> 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.
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)
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)
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.
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?
> 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.
Basically, I'm trying to understand if Timescale is /only/ useful for timeseries or if it has good-enough performance for other use-cases.
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/latest/using-timescaledb/compress...
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?
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.
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.
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.
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.
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 :-)
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")
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!
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.
So thank YOU!
(Feel free to also reach out to me at mike (at) timescale anytime, or mike in slack.timescale.com)
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.
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!
Are there any docs on non-k8s setups? Maybe with docker-compose?
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.
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.
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.
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.