The rise of the Server Side Public License (SSPL)

Elasticsearch is the latest project to move away from releasing code under free / open source terms in response to the likes of AWS selling services that use the code:

The article linked above has a good summery (emphasise added):

If you’re not yet aware of the SSPL, you can catch up here. As licenses go, it’s pretty problematic from a business perspective. Every IP lawyer to whom I’ve showed the text of the SSPL has been rather alarmed before they even reach the end of it. Basically, it’s a hostile proprietary license masquerading in open source clothing.

There is a Hacker News thread on this here.

It will be interesting to see what the response to this is, especially from free / open source projects that depend on it like Zammad, I think there are basically three options:

  1. Keep using the last last version under Apache terms.
  2. Pay for a commercial license.
  3. A hard fork based on the last version under Apache terms (which could be open or closed).

Of course there are other options, if Amazon was a better player in the free / open source community it would perhaps follow the approach that RedHat has used in the past, buying companies / projects and then applying the GPL to the code (for example Ansible), but given their history this seems very unlikely…

5 Likes

Could this have been avoided if instead of a permissive licence like Apache they used AGPL? At least they would get back contributions?

2 Likes

I’m still a bit confused around the hate towards the SSPL. As far as I can tell it seems incredibly similar to the AGPL but is simply more clear about what connecting bits must also be openly licensed. I’ve become increasingly sceptical of Vicky’s (the author) whole position on this with her position of defending amazon and claiming they are more champions of open source instead of using their massive financial power to exploit and repurpose open-source projects for their own profit.

The SSPL (as far as I can tell) is not a non-comercial license, it’s a copy-left license that exists in the same spirit of the AGPL. It embodies both copyleft and cooperative principles by requiring that it exist in fully open-source stacks.

Every major critic I’ve seen of this license has either been drawing most of their income from FAANG or citing someone who has for their argument (VM brasseur, Matthew Garret, etc.)

2 Likes

@nolski I think your points make more sense when turned around like this:

I’m still a bit confused around the hate towards the AGPL. As far as I can tell it seems incredibly similar to the SSPL but has abundant community goodwill associated with it and it is backed by the FSF.

It seems to me that the SSPL is being used by smaller corporations (eg Elastic), that are in competition with bigger corporations (eg Amazon), this is what it has been written for and this is it’s purpose, it isn’t being used by community projects or co-operatives.

It’ll be interesting to see if Amazon can live up to what they have promised:

Elastic recently announced that they would be changing the license of Elatsicsearch and Kibana to a non-open source license. With Open Distro for Elasticsearch, AWS made a long-term commitment. AWS stands behind the commitment to ensure Elasticsearch and Kibana remain open source. Today, we are announcing that Open Distro will launch and maintain new forks of Elasticsearch and Kibana based on the latest Apache 2.0 licensed codebases.

Open Source Elasticsearch & Kibana | Open Distro

1 Like

@chris I like your phrasing better than mine and you make a good point :slight_smile:

I will agree that the SSPL being developed from a smaller corporation does make it seem less in the public interest than the AGPL which was developed by the FSF. However, reading the FAQ for the SSPL it seemed that the reasoning for developing the SSPL and not simply using the AGPL was mostly for clarification (quoted below)

Why did you base the SSPL on GPL v3 instead of AGPL?

The AGPL is a modified version of GPL v3. The only additional requirement of AGPL is in section 13: if you run a modified program on a server and let other users communicate with it there, you must open source the source code corresponding to your modified version, known as the “Remote Network Interaction” provision of AGPL.

There is some confusion in the marketplace about the trigger and scope of the Remote Network Interaction provision of AGPL.

As a result, we decided to base the SSPL on GPL v3 and to add a new section 13 which clearly and explicitly sets forth the conditions to offering the licensed program as a third-party service.

2 Likes

I’m not a lawyer but I agree that section 13 doesn’t appear to be against the sprit of the AGPL and does appear to simply make it clearer that when running the software as a service the associated code should also be open, this is it in full:

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.

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

However as was pointed out on debian-legal in the initial discussions around the SSLP and MongoDB in 2018:

They are essentially trying to force one of a few possible actions out
of Amazon:

  1. publish part of its proprietary infrastructure
  2. stop providing mongodb
  3. pay mongodb for a different license
  4. fork it and continue providing an old version
  5. purchase MongoDB Inc and use it against MS/Google

The driving force behind the adoption of the SSPL is competition between capitalists, it isn’t the greater good or a desire to expand the commons and co-operation, however, rather ironically, it might be that the winner is the commons and co-operation if liberally licensed forks become the main focus of development.

1 Like

I don’t disagree here. I would say, the driving force behind the SSPL could be rephrased as smaller companies trying to level the playing field between them and a monopolistic power such as Amazon. In some ways this is an organization struggling against the forces of capitalism (which over time aggregates power into monopolies).

However, no matter how it is phrased, the organizations championing the SSPL are certainly not explicitly championing cooperative development of software and I think unless they reorganize themselves in a way that puts the interests of labor and commons at the forefront, it makes sense to be skeptical of their intentions. If I had to choose sides here though, I certainly would choose them over Amazon and other international mega-corporations.

1 Like

I think that in reference to specific projects like Elasticsearch it is probably too early to make that call (you might be right, time will tell), also note that Elastic is worth $14 billion, I don’t think they deserve to be described as one of a group of “smaller companies trying to level the playing field”, to my mind that phrasing conjures up companies more like Nextcloud.

I don’t think that corporations applying the SSPL to their code are engaged in a struggle “against the forces of capitalism” it is more like a struggle within capitalism to best adapt to and benefit from the emergent peer to peer / open source mode of production.

2 Likes

Nice discussion, thanks for that :slight_smile:

I’m on neither the side of Amazon or Elastic, fuck them both :stuck_out_tongue: As @chris says Elastic is hardly a small company fighting the good fight, and Amazon say nice sounding words: “We’re in this for the long haul, and will work in a way that fosters healthy and sustainable open source practices—including implementing shared project governance with a community of contributors.” … but we all know if the project is not serving amazons profits it will be dropped. So that “community” will always have to act in amazons interests. Very unequal power dynamics.

My “battle” is beyond licenses, important as they are, they are not sufficient on their own to embody a different way of operating. *GPL licenses seem practical to use today, and maybe ethical source ones tomorrow-ish if they gain some traction (The Hippocratic License looks appealing to me).

And by “beyond licenses” I mean things like working on software that the capitalists wouldn’t even know what to do with :slight_smile:

3 Likes

Thanks @nick for keeping us grounded, I fear that for many people in and around CoTech debates about the details of software licenses are off-putting rather than interesting… so how is this for an attempt to see what this issue might practically mean?

Imagine you are a tech co-op which wants to provision a search service on a clients web site using Elasticsearch, I think that the SSPL would allow this without you having to release the whole software stack and the whole website backend under the SSPL?

But on the other hand imagine you are a hosting co-op which wants to provide Elasticsearch as a service to other co-ops, to do this the hosting co-op would have to release the whole software stack providing this service under the SSPL — this is basically an impossible requirement as you would have to have an operating system that is released under the SSPL to run it on and no such thing exists

The SSPL, in practice, prohibits code licensed with it from being used to provide a SAAS (software as a service) offering, that is it’s point and purpose.

This is the one thing that confuses me. If your stack and be run using essentially docker-compose or kubernetes and all the images are freely available, does that adhere to the SSPL? When my non-lawyer eyes read the AGPL/SSPL comparison, I want to say yes.

I’ve seen some lawyers make vague gestures saying that pretty much no one can use SSPL licensed software if you’re going to host it as a service but the only ones who I’ve seen say that work for a FAANG or IBM.

It seems fairly clear that the SSPL must be used by everything related to providing the service?

This is a extract from Clause 13:

If you make the functionality… available to third parties as a service, you must make the Service Source Code available… under the terms of this License

Clearly “this License” is the SSPL itself.

In terms of when they mean by “Service Source Code” it doesn’t specifically mention the operating system but this list of software clearly appears to be designed to include everything:

management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software

But of course this hasn’t been tested in any courts anywhere and small tech co-ops are not the type of organisations that could afford legal battles of this nature (look for example at the SCO case!).

@nolski are you using the SSPL for any code that you are hosting or writing?

1 Like

Nope! I often use the AGPL however. I don’t mean to sound like some sort of SSPL champion or defender of Elastic. I think @nick phrases it well with the below quote

However, I am curious about the validity pretty harsh critique that has been making the rounds on various open-source communities towards the SSPL. If I were to release a web application making use of elastic search running on a container and include the docker-compose configuration that will allow you to run the application on an open-source stack, does that adhere to the terms of the SSPL?

Do Mongo and Elastic both accept and integrate contributions under the SSPL without requiring copyright assignment? If they don’t, then this is good reason to stay away – since it means the lawyers that drafted it know that it’s a problematic license. On the other hand, if these companies do accept these contributions, and are good with being “license-locked” to their own creation, well, then perhaps this is worthy of further consideration. However, symmetry is critical aspect of license regime evaluation.

Reminded me of this quote.

2 Likes

Isn’t this more about the specific project rather than the license itself? Most licenses can be used in bad faith against the community when combined with an aggressive CLA.

I found this comment interesting:

There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.

… which further supports my feeling that the SSPL isn’t a workable/usable license, but mostly funtions to block AWS/others, whilst keeping some of the feel good vibes from open source.

A more cynical part of me could see that it wasn’t even intended to be usable but just a way to increase profits and reduce sharing/commons without getting labelled as Evil Proprietary Software (open washing).

The less cynical part of me could see it as merely misguided attempted to define a new coherent perspective on software licensing that understands the realities of SaaS in 2021.

I think the AGPL could have been a great fit (along with their existing Elastic License), which does understand the SaaS model (at least on a technical level if not a business one?).

I can’t imagine the people at Elastic actually are really desiring more money on a personal level, but are tied into the capitalist growth imperative and have little choice but to act in the interests of profit-maximisation. Sad.

In summary I put forward the idea that the spirit of the *GPL is the commons, but the spirit of SSPL is profit maximisation. Those being the underlying drivers of the choices within the license.

2 Likes

AWS have announced their plans for their Apache licensed fork of Elasticsearch, which they are calling OpenSearch:

There is a Hacker News thread on the announcement.

This is a step in the right direction for Grafana, they are moving from a permissive license (Apache) to a strong copyleft one (AGPL), rather than from permissive license to a proprietary one as MongoDB and Elastic have done:

A Hacker News thread discussing this.

1 Like