A couple of days ago Elastic announced that they’re moving their Apache 2.0 licensed code in Elasticsearch and Kibana to be dual licensed under the Server Side Public License (SSPL) and the Elastic License.
SSPL is a copyleft license based on the AGPL, created and first used by MongoDB. In contrast to AGPL, which the OSI approved as open source license, the SSPL is not an open source license, but rather a source available license. The main difference between AGPL and SSPL is in Section 13:
- Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
This sounds like it is what people feared the AGPL to be, but what it isn’t.
I’m not a lawyer, and maybe in law there are understood and defined concepts behind terms like “service”, but to me this whole section sounds rather vague. If you make a proxy to an Elasticsearch instance publicly available, it should be fairly clear that you’re making the functionality of Elasticsearch available to third parties. But what if you put a REST API in front of it? How much logic does the REST layer need to contain to claim that it no longer derives it’s value primarily from Elasticsearch?
And assume that you’d want to make the service source code available under the terms of the license, you’d have to do that for all programs that you use to make the program available as a service. Uh, I don’t own the rights for Gradle, which would be used as build system. How am I supposed to change the license terms of that?
Elastic put a FAQ online that attempts to re-assure users:
If you download and use our default distribution of Elasticsearch and Kibana, nothing changes for you. Our default distribution continues to be free and open under the Elastic License, as it has been for nearly the last three years. If you build applications on top of Elasticsearch, nothing changes for you. Our client libraries continue to be licensed under Apache 2.0. If you use plugins on top of Elasticsearch or Kibana, nothing changes for you.
They refer to the Elastic License here, the phrasing for the SSPL license wouldn’t back this up, which is why others claim that Elasticsearch and Kibana are now business risks.
There is another question in the FAQ:
I build a SaaS application using Elasticsearch as the backend, how does this affect me?
This source code license change should not affect you - you can use our default distribution or develop applications on top of it for free, under the Elastic License. This source-available license does not contain any copyleft provisions and the default functionality is free of charge. For a specific example, you can see our response to a question around this at Magento.
“should not affect you”. They again point to the Elastic License. So who would use the SSPL? Is the SSPL just a smoke bomb to claim that it is still open?
I do sympathize with the move. Having worked at CrateIO and as I continue to have a business relationship with CrateIO, I’m all too familiar with the challenges Elastic and others are facing. As a newly independent developer, finding new ways to sustain open source development is certainly of interest to me. People like Daniel or Drew have written about ways that they’ve found to work for them. I’m convinced that open source as a development methodology is the most effective way to develop software and we need to find ways to ensure that it is a non-zero sum game for all people involved. As things currently stand, Open Source does have a funding problem. Projects like Tidelift sound interesting. I still have hopes for Github Sponsors, though it looks like currently it’s mostly developers trading pocket change with each other.
Is SSPL a step in the right direction? I don’t think so. Based on their communicated goals and their claims for doubling down on open, it sounds like AGPL should have been sufficient. Their real goal seems to be to deny Amazon and consorts their piece of the cake, and I wonder if moving to the Business Source License, like Cockroach or Sentry would have been more honest and less scary for people who - according to their FAQ - shouldn’t be affected?
- Elastic will continue to grow. It will be unclear whether this is because of or despite of the license change. Depending on who you ask, you’ll get a different answer.
- Some companies will double down on their Open Distro for Elasticsearch efforts.
- Some companies will look for replacements.
- Money continues to be unfairly distributed among companies and open source developers.