Two Ways of Interpreting the Elastic License Change

Will open source software and public clouds ever learn to get along? There is more than one way to answer that question. Your viewpoint likely depends on how you choose to think about Elastic’s recent decision to change the licensing terms for Elasticsearch and Kibana, two widely used open source (or just “open,” according to Elastic’s new terminology) platforms. Viewed from one perspective, the Elastic license change suggests that open source will never really work in the cloud. From another, it looks like open source is finally fighting back in a real way against public cloud providers.

The Elastic License Change, Explained

In a nutshell, the Elastic license change means that, henceforth, Elasticsearch and Kibana will be available from Elastic under a license that is similar in most ways to open source licenses (not including the GPL, which is more restrictive), with one major difference: These platforms can no longer be used as the basis for offering managed services, such as those hosted in the cloud via a SaaS model.

That’s a big deal for public cloud providers like AWS, which offers a managed service based on Elasticsearch. The licensing change means that AWS can no longer use Elastic’s version of the Elasticsearch platform on its cloud.

Not to be outdone, Amazon has “forked” Elasticsearch by spinning off its own version of the platform, which it is completely within its legal rights to do. So, Amazon will be able to use its own version of Elasticsearch to continue offering its managed service. But the version developed by Elastic and the open source community surrounding it, which to date had been the only upstream open source version of Elasticsearch, can no longer be used by AWS to offer a managed service.

Meanwhile, Elastic is also offering users the option of choosing to license its implementations of Elasticsearch and Kibana under the Server Side Public License, or SSPL. The SSPL doesn’t forbid the use of open source platforms as the basis for managed services, but it does require that a cloud provider that offers a managed service make its full stack of related management software open source. In other words, if you want to offer an SSPL-licensed platform as SaaS, you have to release the code for any management tools that you build yourself to help users access and manage the platform in your cloud.

Is Open Source Winning in the Cloud? Two Perspectives

There are two ways to interpret this turn of events.

The Elastic license change is terrible for open source.

One is to view this as a major retreat by Elastic--and, by extension, the open source community in general--in the face of the cloud.

Open source has long had a strained relationship with the cloud due to the fundamental design of cloud services. Traditionally, open source licenses focused on ensuring that users had access to the source code of applications that they ran on their own computers. In so doing, they aimed to protect users’ freedoms, based on the idea that if you can view (and, if desired, modify) source code, you have full control over your software.

That idea works nicely when software is running on your own PC or server. But when software moves to the cloud and is hosted on a cloud vendor’s servers, matters become more complicated. The source code for an application running in the cloud could be publicly available, but if the cloud computing company that hosts the application controls the servers on which it runs, the ability of the user to view the source code doesn’t translate to much control over the application. The fact that cloud providers often couple open source platforms with proprietary management tooling that they build themselves undercuts the value of open source in the cloud even more.

Open source and free software advocates have long warned against these problems. They’ve also experimented with various new open source licenses designed to close the gaps that arise when open source software is used as the basis for cloud services. But they have never arrived at a perfect solution.

Against this backdrop, the Elastic license change could be viewed as a surrender. Realizing that user freedoms (not to mention the interests of open source developers) can never be fully protected in the cloud, Elastic has opted for licensing terms that essentially bar public cloud vendors--or at least AWS, the largest public cloud provider--from using its software in a profitable way.

Given that the future of most software deployments clearly lies in the cloud, this would seem self-defeating. Elastic has given many of its users a very good reason not to use its open source platform and to opt for Amazon’s forked version instead. And while Amazon’s variant will also be open source, it will be developed under the auspices and for the benefit of Amazon, killing the democratic, all-for-one-and-one-for-all vibe on which most open source projects thrive.

As for the SSPL licensing option that Elastic has provided, that, too, could be interpreted as a major retreat. As Elastic has readily admitted, the SSPL is a contentious license that the Open Source Initiative, a leading open source community organization, has deemed too restrictive even to merit the title of “open source license.” (That’s why Elastic is now saying that its software is not open source, just open.)

In many ways, the SSPL option backs cloud providers into the same corner as the ban on managed services does in Elastic’s own license, and leaves users in the same boat: in search of a more flexible platform, like Amazon’s fork, that is less restrictive.

Elastic is leading the fight against cloud providers.

If you’re a free software purist, though, you’d probably applaud what Elastic has done. In essentially making it much harder for cloud providers to build SaaS platforms using someone else’s code, the company has taken the bold stance necessary to achieve meaningful change with regard to the way clouds use open source.

No other open source organization has gone this far. Most open source projects and companies do little to stop cloud providers from co-opting their software, even if doing so constrains user freedoms and allows cloud providers to profit off of open source developers’ work while offering nothing in return. They’ve presumably done this because they haven’t been bold enough to take a strong stance against the large public clouds that increasingly rule the world of IT.

Elastic’s move may not be good for Elasticsearch and Kibana in the short run, and it’s certainly not good for Elastic as a company. But if other open source projects follow suit, the decision could help open source in the long run by forcing cloud providers to play more nicely with open source platforms.

Granted, most open source and free software advocates are not purists. They realize that life is full of compromise, and that for open source to succeed, it’s sometimes necessary to work with companies and platforms (like Amazon, which is almost entirely proprietary) that aren’t generally friendly toward open source.

But for those who think that the open source community has let cloud providers walk all over open source projects for too long, Elastic’s new license policies suggest that it doesn’t have to be this way. I’m guessing Richard Stallman was pleased, if no one else. (Actually, he probably thinks the Elastic license is still far too restrictive and doesn’t offer users enough freedoms, even if he likes the anti-AWS modifications.)

Conclusion

The impact of the Elastic license change will depend on whether most Elasticsearch users opt to migrate to Amazon’s fork, which would leave Elastic isolated and irrelevant. In that case, the decision would surely end up looking like a bad one.

On the other hand, if the open source community rallies around Elastic (which, admittedly, does not appear to be happening right now), perhaps we’ll look back at this battle as the moment when open source finally started asserting its independence within a cloud-dominated world.