As of version 1.4.2 we changed ZeroTier’s license from the GNU General Public License V3 (GPLv3) to a newer licensing scheme pioneered by MariaDB called the Business Source License (BSL). ZeroTier’s version can be found here and there is more information on our pricing page.
For the vast majority of our users this change means nothing, but it’s upset a few open source purists. As ZeroTier’s founder I would like to respond to some of these criticisms.
Business Phobia of GPL “Virality”
The first reason for the change is a common phobia of the GPL and its supposed “virality” on the part of business customers and their legal departments.
Yes, we know. This phobia results from a misunderstanding of how the GPL works. The GPL does not apply “downward” from application to platform or “sideways” from one application to another running in the same execution environment. People can and do run GPL software on Windows and Macintosh systems without the GPL somehow magically transferring to Windows or MacOS itself or other software on the system.
Yet when one is running a business one must sometimes bend even to irrational customer demands. We repeatedly found ourselves on the receiving end of “no GPL” policies in corporations or GPL-phobia on the part of corporate legal departments. Linux and its user-space tools get grandfathered in, but otherwise our readers would surely be shocked to learn how many companies out there still subscribe to this bit of FUD and prohibit the use of GPL software in mission critical or production roles.
Many users have suggested that we move to a less restrictive license like Apache, MIT, or BSD. Unfortunately this presents a problem for us if we want to keep operating as a business and for you if you want ZeroTIer to keep getting developed full time.
The Problem of “SaaSification”
In a pervious version of our my.www.zerotier.com backend we used an excellent “NoSQL” database called RethinkDB.
We think (and still think) RethinkDB was revolutionary. It delivered an almost zero-configuration cluster setup experience, efficient and flexible replication, very good high availability features, and paired a developer-friendly JSON document model with SQL-like join capabilities. You might call it a “weakly relational document database.” Last and certainly not least it supported a powerful observer feature allowing queries to be executed in an open-ended change-subscribe mode. This made responsive real-time features ridiculously easy to develop without the implied inefficiencies of polling or the need to run another application for publish-subscribe event distribution.
Unfortunately RethinkDB was a bit slow. It was fast enough for our needs at the time but as we grew we gave up waiting for its performance to be improved. We sponsored one improvement in an effort to help it scale with us but it wasn’t enough. We ended up abandoning it in favor of PostgreSQL.
RethinkDB’s performance issues are not intrinsic to its design. They could be solved with a bit of developer time. Unfortunately the RethinkDB team no longer exists and development has almost stopped. That’s because RethinkDB, Inc. failed.
The postmortem on the failure of RethinkDB, Inc. discusses a number of reasons for its failure, but it only skirts around a problem that in more recent years has been termed “SaaSification.”
SaaSification (in this context) is when cloud services companies take open source software, slap on an interface, and offer it as a paid service. In the vast majority of cases they do this without giving anything back to the project either financially or as developer hours to improve the product they’re hosting.
A number of companies that shall here remain nameless made money on RethinkDB, but unfortunately none of those were RethinkDB, Inc.
Here at ZeroTier we receive one or two questions per week about whether it’s okay to take our software, strip our name off it, and re-distribute it to power some kind of for-profit service: privacy VPNs, managed service providers, SD-WAN boxes, and so on. We respond by explaining that this would constitute incorporation of our code into a proprietary application and that a commercial license would be required. We can do this because we are conservatively licensed.
If ZeroTier transitioned to an almost-public-domain license like Apache, BSD, or MIT, we would almost certainly suffer the same fate as RethinkDB. The investors that helped make ZeroTier happen would lose their money and the people who dedicated years to its development and support would in the end find themselves poorer than if they’d worked for a “FAANG” instead.
That’s why we’ve always used licenses that are intentionally problematic for companies that want to “SaaSify” ZeroTier. If it weren’t for the problem of GPL-phobia we’d likely have stayed with the GPL (with a dual licensing model) or even considered the slightly stronger AGPL, but GPL-phobia prompted us to consider other options.
Some readers may ask: why not run our own SaaS? Why couldn’t RethinkDB do this too? The answer is: we do, and they did. The problem is that without some other method to restrict for-profit SaaS deployment the SaaS business is one that strongly favors scale and integration. That means larger SaaS players like major cloud hosts or dedicated infrastructure as a service (IaaS) companies have a powerful advantage over any SaaS offering put forward by a smaller startup venture. RethinkDB’s SaaS offerings lost when they were pitted against those of larger vendors, and those larger vendors weren’t paying RethinkDB anything for the use of their code.
MongoDB was probably RethinkDB’s closest competitor. Many regard it as technically inferior, but it ended up being a huge business success to the point of becoming one of the few open source company IPOs. Unlike RethinkDB with its Apache license, MongoDB’s license effectively restricts SaaSification by requiring that SaaS service code be open sourced.
Can Free Free Stay Free?
High-quality software that solves difficult problems requires thousands upon thousands of hours of developer time. Creating something people can actually use requires thousands more hours of time dedicated to documentation, porting, bug fixes, infrastructure, user experience, and support.
Contrary to popular mythology there are few large scale open source projects that subsist exclusively (or even mostly) on pure volunteerism. Even Linux, perhaps the oldest and most significant open source project of all time, receives only about 8% of its support from independents [PDF]. The rest of its support comes from full time employees of corporations, universities, and governments. These organizations donate their employees’ time because they have a vested interest in Linux’s continued existence.
Moving down the curve from the oldest and largest projects the rest are almost entirely supported by one or two key corporations, academic or government largesse, a foundation funded by contributing members (mostly large corporations in most cases), or an apparently independent group that is in fact dominated by employees of one or two large entities.
| Project | Supporting Organization(s) |
| React | |
| Ubuntu Linux | Canonical |
| Kubernetes | Mostly Google and Red Hat |
| Clang / LLVM
(compiler) |
Largely
|
| Chromium
(browser engine) |
|
| Firefox | Mozilla Foundation |
| Go
(language) |
|
| Visual Studio Code | Microsoft |
| Docker | Docker |
| CockroachDB | Cockroach Labs |
| MongoDB | MongoDB |
In case you think we’re cherry picking, here are some aggregate statistics from GitHub that strongly support the general thesis. A very large percentage of the code on GitHub is pushed by on-the-clock employees of large corporations.
This same prevalence of large corporations can be observed if you follow the PDF link to the most recent Linux kernel contributors report above of if you dig into who is actually funding (directly or through dedication of employee time) some of the other large apparently independent and collaborative open source projects.
Open source today appears to be largely corporate philanthropy.
The last three items in the table are a little different: they’re startups. ZeroTier belongs to this class of open source projects: those backed by companies founded by their creators, bootstrapped with angel and VC capital, and sustained by revenue.
Huge corporations are huge because they fit the current status quo. As such they’re going to tend to create and support projects that fit and also perpetuate this status quo. It’s not necessarily a conspiracy, though corporations definitely do strategize. It’s more a result of the incentive structures present in these organizations. They’re going to make stuff that goes with the flow.
Open source created and sustained by large corporations might be useful, but it’s not likely to be revolutionary. It’s not likely to do anything to change the current paradigm.
That means genuinely revolutionary open source is only likely to come from independent authors or startups. Independent authors with the free time to take on huge projects are few, so that leaves independent ventures like ourselves.
As we’ve discussed before, ZeroTier began life as an open source project to make it really easy to create private peer to peer networks with the goal of helping people take back control of their own data and their own computing resources. We want to make it ridiculously easy to create personal cloud networks that link your own devices and carry your own data. The hope is that this might help shift the industry from one dominated by closed services that productize the user back toward one dominated by personal computing that serves the user.
In other words, we were founded to support free as in freedom. That means we can’t always be “free as in beer” or we won’t have the resources to do that. Our license allows the vast majority of people to use ZeroTier for free. All we ask is that you pay us something if you use it as a core component to build something you’re selling.
The Year is 2019
Open source gained traction and momentum in the 1990s as part of a push to liberate computing from monopoly closed source operating systems and platforms. That open source movement is largely triumphant. Today even Microsoft is integrating Linux into Windows and shipping open source software.
Twenty years later there is a new closed. The new closed is not closed source, it’s closed services. Many of these closed services are powered behind the scenes by open source software, but the ability to view the code or run it locally means nothing.
The new closed may be even more closed than the old closed. A user on a 1990s PC running closed-source OSes and applications still owned their data. That data was private. Their computer was not an instrument to spy on them.
Fighting the new closed may require new approaches to open that preserve not only access to internals like source code but the independence of that code’s creators and the sustaining of their ability to create. That may mean choosing between the two kinds of free.