How We Are Building a Self-Sustaining Open-Source Business in the Cloud Era

Back in 2018, Timescale first announced how we planned to build a self-sustaining open-source business in the cloud era and that we had started developing features under a new, source-available license called the Timescale License (TSL).

At the time, the TSL was a radical idea: a source-available license that was open-source in spirit but that contained a main restriction: preventing companies from offering software licensed under the TSL via a hosted database-as-a-service.

We added this restriction, which only applies to <0.0001 % of all possible TimescaleDB users, to enable us to build a self-sustaining business in a world that was rapidly moving to the cloud. (And importantly, we did not and have never re-licensed any of our open-source software, which continues to be licensed under the Apache 2 license.)

Introducing Cloud Protection Licenses

The TSL, like the Elastic License before it and the Confluent Community License (coincidentally launched around the same time), are examples of what we call “Cloud Protection Licenses.” These licenses attempt to maintain an open-source spirit but recognize that the cloud has increasingly become the dominant form of open-source commercialization.

So, these licenses protect the right of offering the software in the cloud for the main creator/maintainer of the project (who often contributes 99 % of the R&D effort). This “cloud protection” is what enables open-source businesses like ours to become self-sustaining in the cloud era.

However, since these licenses are not officially sanctioned by the Open Source Initiative (OSI), whom many view as the arbiters as to what is and isn’t officially “Open-source,” these licenses are generally not considered “Open-source” (capital "O") (although this sentiment may be shifting). At the same time, many developers still call these licenses “open-source” (lowercase "o") because they embody the same open, transparent, collaborative spirit.

A successful experiment

This experiment has proved successful, exceeding our expectations. The Timescale community has continued to grow to over three million active databases today. The TSL governs many of our new advanced features, including native compression and continuous aggregations, and adoption of these features has continued without friction. The public cloud providers have been deterred from offering these TSL features for free (and are now reaching out to discuss revenue-sharing agreements). And other OSS entrepreneurs have reached out for advice on creating similar licenses.

What Is TimescaleDB?

TimescaleDB is the leading relational database for time-series data, engineered on top of PostgreSQL, and offered via free software or as part of the Timescale cloud offering on AWS, Azure, and GCP.

TimescaleDB offers massive scale (100s billions of rows and millions of inserts per second on a single server), 95%+ native compression, 10-100x faster queries than PostgreSQL, InfluxDB, Cassandra, and MongoDB—all while maintaining all of the reliability, ease-of-use, SQL interface, and overall goodness provided by PostgreSQL.

Initially launched in April 2017, TimescaleDB has come a long way, with tens of millions of downloads and over 3 million active databases today. The TimescaleDB developer community today includes organizations like AppDynamics, Bosch, Cisco, Comcast, DigitalOcean, Fujitsu, IBM, Netflix, Schneider Electric, Samsung, Siemens, Uber, Walmart, Warner Music, and thousands of others.

The growth of the Timescale Community is a clear sign that software developers need a new database to rely on for their time-series data and that increasingly more and more are turning to TimescaleDB. But even with all this adoption, how does one build a sustainable business, particularly given the predatory actions of some public cloud providers?

Enter “Cloud Protection Licenses,” like the Timescale License.

What Are “Cloud Protection Licenses”, and Why Are They Necessary?

Not that long ago, the open-source business model was straightforward: companies run your software, and when they need help or advanced capabilities, they pay you for commercial support or enterprise features. This is the world in which the last generation of Open-source licenses were written.

But the world has changed. Today companies would rather pay someone to run your software, thus obviating the need for paid support (and making selling enterprise capabilities much harder). The standard Open-source licenses allow anyone to completely commercialize your software without contributing any software development.

In other words, the rise of the Cloud has cut off the primary business model for open-source software.

Enter new licenses like the Timescale License, Elastic License, Confluent Community License, and others. These licenses, which we call “Cloud Protection Licenses”, attempt to maintain an open-source spirit but protect the right of offering the software in the cloud for the main creator and maintainer of the project.

This “cloud protection” is what enables open-source businesses like ours to become self-sustaining in the cloud era.

Leveling the field

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 (source: Wall Street Journal articles from April 2020, September 2020). They lock large customers into prepaid, discounted, multi-year enterprise-wide agreements and give startups $100,000s of free credits.

Yet even with hundreds of thousands of employees and tens of billions of dollars in cash, the public clouds did not develop TimescaleDB, the Elastic Stack, the Confluent Platform, and countless other open-source projects. These were built by independent teams dedicated to advancing state-of-the-art technology and serving developers worldwide.

This is David vs. Goliath. The Rebel Alliance vs. the Empire. Entrepreneurial teams taking on the largest corporations in the world with new, innovative technology. Cloud Protection Licenses foster more innovation and enable the open-source underdogs to compete against the public cloud giants.

How Did Developers React to the Timescale License?

Ever since we launched the TSL, the response from the community has been overwhelmingly positive. But over the years, the community has also provided really helpful feedback—via GitHub, Slack, Twitter, Hacker News, Reddit, email, etc.—which we have incorporated into this latest update.

Overall, an overwhelming majority has been supportive of the general direction of the TSL, understanding that offering a managed service is increasingly the primary commercialization approach for database and other infrastructure software providers:

“I think we're too hung up on OSI open source licenses. The additional restriction in the timescaledb license that you can't run a paid database as a service offering affects hardly anyone negatively (AWS). It affects us all positively by providing a sustainable business model to support additional development and support of an open-source product we use. Win-win if ever there was one. I'd like to see more open-source and closed-source companies consider this model.” (Source)

But we also heard some requests for liberalizing some of the terms of the Timescale License:

“One of the important reasons I personally use and support open-source is the freedom to not only inspect (which the TSL provides) but also not have to ask someone else and wait on them to make any changes I need to the software I use. Any chance the TSL can be modified to include this freedom too?” (Source)

“I don't care if I can see the source code if I can't actually _do_ anything with it. If I can't run my modifications in production, it doesn't guard me against vendor lock-in and it doesn't give me the right-to-repair.” (Source)

We took feedback from these comments and our larger community and updated our license in 2020, removing some restrictions that granted additional rights to our users, most notably the right-to-repair and the right-to-improve. We also simplified the legalese, because we believe that everyone (not just lawyers) should be able to understand the licenses which they are interacting with.

The Main Restriction We Have Preserved: No TimescaleDB-as-a-Service

What we did preserve, however, is the main restriction preventing other companies from offering TimescaleDB-as-a-Service in the cloud.

Along a similar vein, we also don’t allow parties to “fork and modify” the database and redistribute this forked version to others, which could serve as a way to try to circumvent licensing restrictions.

This concern isn’t hypothetical: Amazon, for example, forked Elasticsearch to the creatively named OpenSearch, re-implementing some of Elastic’s key community features and licensing them instead as Apache-2 (while heavily monetizing these features as part of its managed Amazon Elasticsearch Service).

As we shared earlier, this restriction is the heart of Cloud Protection Licenses like the TSL and is what enables further innovation.

Summary: What You Can Do, What You Can’t

Let’s review the rights granted by the Timescale License, as well as the explicit restrictions. 

Definitions

• “utilize”: Offering code/product via a software-as-a-service
• “distribute”: Shipping code/product via software
• “Value Added Service or Product”: Something of value on top of TimescaleDB and not just “reselling” TimescaleDB as part of a “database” or “database-as-a-service”

Rights granted under Timescale License (TSL)

• 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
• Right to run modified TimescaleDB for internal use
• Right to utilize modified TimescaleDB to offer a Value Added Service
• Right to distribute modified Binaries as part of a Value Added Product
• Right to distribute unmodified Source and Binaries, even if not as part of Value Added Product

Rights disallowed under Timescale License (TSL)

• No right to utilize TimescaleDB for external use unless as part of a Value Added Service
• No right to distribute modified Source
• No right to distribute modified Binaries unless as part of a Value Added Product

What Does This Mean for Me?

If you are a current or future user of TimescaleDB, The Timescale License gives you the rights to run TimescaleDB for use in your tech stack. But if you are looking to provide TimescaleDB-as-a-service, you are still restricted to only offering the Apache-2 edition.

Today, you can deploy TimescaleDB on-premise or in your own cloud account, running the software on bare metal, on virtual machines, or even in Kubernetes. Totally free to use and even to modify for your own use or for services or products you build on TimescaleDB. If you’d like some backup, we even provide support for self-managed deployments.

Or, if you prefer, you can let us run TimescaleDB for you, production-ready, fully managed, and enhanced with cloud-only features like data tiering to object storage on AWS, GCP, or Azure in 75+ regions and with access to a top-rated support team.

• To get started, you can sign up for a 30-day free trial right now.

And, join our 11,000+ member Slack community for any questions, to learn more, and to meet like-minded developers—we’re active in all channels and here to help.