Elasticsearch is moving to SSPL 1.0, so what?
About a week ago Elastic made an announcement that had repercussions in probably every OSPO around the globe, as it decided to abandon Apache2 in favor of SSPL 1.0 for Elasticsearch and Kibana (more from Shay Banon here).
In this post, I’ll try to provide a (different?) perspective into possible implications and what might be happening in the future. But before going further, and even though the Java High Level Rest Client will not be under an Apache2 license from Day-1 of releasing Elasticsearch 7.11, I’m going to assume all Elasticsearch client libraries are under a permissive license (Apache2). I’m also not going to enter the debate whether SSPL 1.0 is an Open-Source license or not (it is not according to OSI).
Why now?
In his tweets, Shay Banon insisted quite a bit on extremely poor behavior from Amazon as a key reason for making this change. But as for timing, we should definitely keep in mind that version 8 of the stack should be coming in the next few months.
As with any major version, it will introduce new features. By doing the change before v8, Elastic is making sure that none of these makes its way to a fork of Elasticsearch.
Elastic didn’t make this change at the time of the v8 release. There will be more v7.x releases in the coming weeks/months which will new features, paving the way for v8, and smoothing the upgrade for its user base. All of these will not be available in the forks.
SSPL 1.0 is not the Elastic license
It’s also worth noting that from a usage point of view SSPL 1.0 is different from the free tier of the Elastic license, which prevents SaaS-based services from using features attached to that license for free.
But with the official Elasticsearch client libraries remaining under a permissive license, we’re talking about a license (SSPL 1.0) that primarily impacts the ability to modify Elasticsearch and/or to redistribute it.
This does not limit the ability to provide a SaaS-based service using this SSPL 1.0 version of Elasticsearch for free in the back-office, as long as no modifications are intended. And if SaaS-based service ever needs to do so, the requirement here is to also publish the sources of both such modifications and the management layer under the SSPL 1.0 license, not the entire software stack.
Agreed though that this would be a major pain point for projects already under a permissive open-source license who wouldn’t want to modify their own license into the more restrictive SSPL 1.0 for the management layer. Understandably, the feeling of being forced into such a change can be super frustrating. But on the “plus” site, Elastic indicates in their FAQ being open to discussion with Open Source projects.
Yes, it will create frustration, it does upset those in the Open-Source community in disagreement with SSPL 1.0 in general, but this is very likely a very minor fraction of the Elasticsearch user base. I would be tempted to say it is also likely a small fraction of those in the Elasticsearch user base building and contributing to Open-Source software.
Open Distro?
There have already been a few announcements ([1], [2]) about upcoming forks of Elasticsearch, to maintain and continue to grow a version of the product under a permissive license.
The main challenger in this field is Open Distro, initiated by AWS a few years ago and which claims to be 100% Open-Source and community-driven. Want something funny? Scroll down to the very bottom of that website, what do we see there?
© 2019–2020 Amazon Web Services, Inc. or its affiliates. All rights reserved.
With Open Distro, AWS has been maintaining a fork of Elasticsearch under a “Community Driven” blanket and was able to maintain feature parity with Elasticsearch by bringing in new features from the Elasticsearch Apache2 codebase.
With that approach, Open Distro was a possible alternative, from a technical/feature standpoint, when compared to Elastic Cloud (Elastic’s PaaS offering) for those only interested in features available in the Apache2 version of the Elasticsearch codebase.
But there’s one thing Open Distro is not, it is not a community-driven project under shared governance (such as projects under the Apache Foundation). And now that Open Distro is on its own, it will have to dedicate a considerable amount of resources to keep innovating on the product and remain a relevant solution as time passes.
Will AWS even want to keep it Open-Source? or will they decide to fork the project, give it a new name, Close-Source it, and call it a day?
My guess would be the second option.
Is forking the full codebase a viable option?
Yes, maybe… but I feel there are a couple of very important points to take into consideration.
This will need to be a fork placed under shared governance, such as an Apache Foundation project (for the most famous one). It must contain in its management board multiple organizations with a strong stake in the new fork and willingness to dedicate considerable resources to its development.
On the contrary, with governance handled by a single organization:
- If this organization's main source of revenue is based on commercial support and/or operating this fork as a service, what value-added services will this organization provides to differentiate itself from others? Will we end with a clone of Elastic?
- If this organization’s main source of revenue is entirely different and the fork is a key resource for operating its business. How many resources could the organization dedicate to this project? in particular, when compared to a company whose primary source of revenue is to build and operate a competing solution
I’m a firm believer that well-managed engineering-driven organizations (or teams) aiming for a similar goal acquire an equivalent velocity when given the same amount of resources. In other words, if team A is composed of 10 engineers, it will achieve a similar delivery when compared to team B also composed of 10 engineers. This might sound simplistic, but what I’m saying here is that if you fork Elasticsearch but still want to compete with future versions of Elasticsearch on the same grounds, you’d need to give it the same amount of engineering resources (not just devs). Of course, there are ways to be more efficient and deliver more (or better) with fewer resources:
- By narrowing down the scope and specializing in a particular feature-set, hoping that the competition, by maintaining a large scope will be losing focus or getting slower in adapting to changes in the market.
- By hoping the competition progressively becomes more procedural and begin to lose its “engineering spirit”. Which are things that could happen after losing a charismatic founder.
Could such a fork be successful? Except if under a shared governance model, I’m very skeptical.
Successfully forking Elasticsearch
If you agree with what I wrote above you might think that there’s not much room for a successful fork of Elasticsearch? Actually, there is a possible path forward, not an easy one, but possibly the one presenting the biggest risk for Elastic.
I believe that to be successful in forking Elasticsearch, the new project must take an entirely new name and completely cut ties with Elasticsearch. It should identify a domain (or use case) to focus on, trim down the codebase to only that domain and make sure the resulting codebase is of a size manageable by the size of the team at hand.
From there it can focus on building a community of users and start growing its user base. Only then, as opportunities arise, could it begin to look at growing further as an organization (and bring more engineers onboard), progressively covering more use cases, increasing adoption.
There’s nothing new in that model, disrupters in a wide variety of markets (telco, finance, transportation, …) have been successful with that approach that consisted in challenging the establishment (think Ryanair, Uber, Netflix, Apple, … at their beginning).
The biggest difference here is that most disrupters don’t get to start from an existing and already successful codebase, and this can be a key opportunity for a disrupter if approached wisely.
Understanding Open-Source
As I’m getting towards the end of this opinionated blog post, I’m going to diverge a bit from Elasticsearch and SSPL 1.0 and focus on the reactions over the past week that sometimes demonstrates a limited understanding of what Open-Source is and what it entails.
The choice of a license is critical for any Open-Source organization, whether this organization is a for-profit company or a group of friends wanting to give back to the community. Choosing the right license plays a key factor in getting something back for all the effort spent on a project. It’s not about good versus evil, permissive versus copyleft, profit versus non-profit, it’s about what makes sense for a group of individuals to achieve their goals. There’s an incredible diversity in the possible goals associated with Open-Source groups, it could be to give back to people in need, to contribute to spreading knowledge or ideas, attracting talents, having access to a trained workforce, …
On the other side of the spectrum, the choice to integrate external Open-Source technologies in your stack is also a critical decision for your product, and understanding Open-Source licenses is key to figure out what you’re stepping into. And as you understand the implication of incorporating an Open-Source tool/framework/lib in your stack, you also understand how you can adapt to changes in this product (change of license, change of direction, project halting its development, …).
One of the great things about Open-Source is the level of freedom it gives to adapt to changes since in most cases and at any point, you can decide to:
- Fork the project and maintain it on your own
- Fork the project and team up with other sharing similar business objectives
- Move on to a different solution
Although a change of license will likely impact future versions of your product, it doesn’t impact your current codebase nor its previous iterations. Of course, you may not like it, but it has been a possibility since you first took the decision to integrate that Open-Source tech in your stack.
Compare it to the Closed-Source world, in which if a project is halted you have no other option than move to a different solution or start entirely from scratch. One big advantage with Open-Source in that context lies in the amount of freedom it gives you to fully remain in control of your stack for the future.
The point being, the license changed, so what? You were prepared for it, right?
Conclusion
I hope this article was useful in putting things in perspective and provided some relevant pointers to better understand Open-Source by focusing on a concrete example.
You might be wondering what to do with this week’s news, actually not much, except if you’re an organization directly targeted by the change. We need to see how the various organizations having a stake in the field are going to react and adapt to this change. My guess is that not much will actually change and that the risks for Elastic lie more in trying to cover too many grounds (making room for the successful fork I mentioned above) than in changing its license.
Elasticsearch was the topic this week, but this article would likely be similar for any Open-Source product modifying its license. Ultimately, Elastic and AWS in their conflicts (and whether we root for one, another, or none) are both playing a role in making sure we do think about how we approach Open-Source and contribute to get our position and the field to keep evolving.
As a final note, it could very well be that in a few months I’ll stumble again on this article and will find all of its content very naive and idealistic, and maybe you do today. If that the case, my apologies and don’t hesitate to reach out, I’d be happy to discuss, brainstorm, and exchange opinions.
Please note that the above are personal opinions and are not that of my current or previous employers. This article does not represent legal advice. I invite you to consult resources at the Open Source Initiatives to learn more about Open-Source in general.
Edit: jan. 25 — Fixed minor typos and adjusted some sentences.
