Comment by judge2020

4 years ago

The SSPL directly prohibits offering the software as a service without releasing the source code of your entire operation regardless of if you change it or not:

> 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...

> “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.

AKA someone must be able to create aws.example.com if aws uses SSPL code. Not exactly the 'freedom to run it anywhere'.

https://www.mongodb.com/licensing/server-side-public-license....

Doesn't a lot of that hinge on what the "service" is? Like, if I run some generic knowledgebase website and use my own ES installation to provide user-facing search, does Elastic want to see my Ansible scripts? Or just the ones related to the search function?

If this interpretation holds, I feel like it could be a pretty big problem for companies like GitLab, who not only have deep integration with ElasticSearch, but offer it as a premium-tier feature:

https://docs.gitlab.com/ee/integration/elasticsearch.html

Maybe this really is just a cash grab from the Elastic side, like, "it's too easy to self-host rather than paying for our SaaS offering, so now you need to pay us for many common self-hosting use cases also."

  • There's several lawyers who believe the wording would imply the problematic interpretation - /dev/lawyer is one on the internet, one from my anecdotes is the lawyer who advised the company I used to work at.

    SSPL doesn't come up under free or open source licenses partly for this reason, actually.

  • > 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.

    This probably qualifies it as a service, but since it looks like gitlab doesn't install it or redistribute it Elastic isn't going to come after them (if they don't use SSPL code then SSPL doesn't apply). Plus, GitLab is effectively open-source, so they might meet the qualification for using SSPL anyways. Of course, I am not your/a lawyer.

  • > I run some generic knowledgebase website and use my own ES installation to provide user-facing search, does Elastic want to see my Ansible scripts?

    According to Elastic, "it depends" - if you can just search by entering a term in the searchbox, you're probably fine; If you allow users to use Elastic's query language, you're very likely in violation. If you let your customers define Kibana dashboards, you're definitely in violation.

    It's worth noting that you can do a custom deal with Elastic, as long as you pay whatever they ask & accept their terms (or renegotiate them, which is a fairly painful process) - so maybe GitLab did just that.

Great point. SSPL is basically the open source equivalent of “we had to destroy the village in order to save it.” In order to protect their IP from being “taken away” because of their original licensing decision, they basically chose a new license that’s effectively no longer open source (although it is “source available”).