Give 'em SSPL, says Elastic. No thanks, say critics: 'Doubling down on open' not open at all

Elastic, whose products include Elasticsearch and Kibana, has adopted a new licence called SSPL (Server Side Public License), as used by MongoDB. The aim is "to restrict cloud service providers from offering our software as a service," but others warn this could make the products risky to use unless a paid-for licence is adopted …

[Anonymous Coward]

Kill this licecence with fire, its' replicating.

This license has been problematic since day one. It also isn't working. MongoDB isn't riding high on a wave of good fortune as a result of this license change, nor are it's other handful of adopters. Their long term viability is more in doubt then ever.

It's hard for me seeing an Apache licensed project going that route. It, along with the BSD license, are the go to forms for permissive use for many of us that want to contribute to projects that really support code re-use over political concerns and the monopolist urges of some of these companies. Unfortunately the pressures on these companies that spun up a startup thinking that "Benevolent Dictator for Life" was a universal business model have been dashed by the Ellisons and Bezoids of the real world.

I look at these events through the eyes of a sysadmin and programmer, and I can't help but feel like these operations are a bait and switch. They lure in a group of developers and users, then pull out the rug once the project has build up an exploitable base, then pivot off of a permissive license. The license is part of a contract with the community, both users and developers, and one actor shouldn't be unilaterally making that decision. That's where the model becomes a tricky fit for a VC funded startup business model. By definition the people involved are beholden to their investors first and their employees second. That means contributing developers and and users are going to be thrown to the sharks.

[Anonymous Coward]

Re: Kill this licecence with fire, its' replicating.

Sorry but, bollocks.

If 3rd parties have provided code to these then they will need to approve the change in license for their code. Otherwise it will need to have been changed (no pulling the rug from under the devs).

If anyone isn't happy with the change in licensing terms, fork it, its open source.

If the people that are complaining cant fork it due to them not having the dev abilities or money to support the project, now you know how they are feeling.

Amazon, Azure, Google all take these open source projects, provide them as a service (removing these companies source of income that are developing it), provide no fixes to the projects and provide no donations or revenue, yet wish to sell the products they are developing.

What do you think would happen to these companies that produce these products if they can not get money from somewhere, magically keep going via fairy dust and unicorn arse rainbows?

Oh the developers that are providing their time to develop it, yeah, they do not provide as much code as is needed or priorities what should be done.

The cloud providers will pick up the slack... Yeah, they haven't been helping now, why would they later, you will still be paying for their services and no one else with have this product anymore either. The product will die someone else will have something new, same thing will happen.

MongoDB, yep, may not have helped them, but you think keeping the same license would have, no, the cloud providers are providing the services that they have tried to make money off.

Try a different way to make money I hear you say.... OK provide one business model that can make them money, other than hosting services and support?

Extra paid features, ah, but that's devils work, closed source, oh no, can't have that...

If people wanted these products to continue on as they are, they need money, people need to donate or buy support if they are using the product for their business. Otherwise, what do you expect?

[needmorehare]

This and AGPL are the right ways to go.

Forcing companies to share and share alike is the only way to prevent monopolies from occurring as a result of Free Software in the long term. Otherwise, large companies can keep adding "value-add" features and shut out other potential genuine contributors in the form of competing businesses who also offer similar services.

Let's all remember why copyleft exists in the first place

[K]

RE: Sorry but, bollocks.

Frikkin Amen... lets give a "hallelujah" for brother A/C....

I mainly consider AWS the culprit, they profit the most and do the least - what an age we live in, Microsoft does more for Open Source!

Either way, all the cloud-providers are making-bank off the time, sweat and overtime of others. The companies such as Elastic who develop open-source products need support, whether this is the contribution of developers, financial donations, or purchase of commercial-support... or perhaps something else.

Between 2017-19, I worked for a huge AWS client and had access to their devs. They do occasionally feed fixes back into projects, but it's done extremely low-key, there is pressure with-in to keep distance between AWS's brand and their "SaaS" offering, and the open-source products that power them. They also have a reputation for using JIT-forking, i.e. they'd rather see the main product developer go to the wall, they then fork, and offer a modicum of support.

[Arion]

Re: Kill this licecence with fire, its' replicating.

Interesting that this post enters with "bollocks", because that's largely what the first couple of paragraphs consist of.

The Devs have already consented to their code being relicensed by licencing it under the Apache licence. Further approval is not necessary.

Amazon essentially did fork ElasticSearch in the form of OpenDistro for ElasticSearch. [Although according to the FAQ it's not technically a fork, it achieves the same effect].

The OpenDistro FAQ says that any updates are contributed back to Elastic. Even if they weren't, Elastic could just take them under the terms of the Apache Licence.

Amazon and RedHat are co-operating on providing and supporting ROSA (RedHat OpenShift in AWS). It's very possible that Elastic could have done likewise, or indeed licenced the commercial features to Amazon the same way as Microsoft and Oracle licence SQL Server and Oracle DB respectively. They dug their own grave here.

[Anonymous Coward]

Devil is in the detail

...to complain about the number of people who use free software without giving back... If I'm not mistaking, Elastic is complaining about Amazons of this world which as the richest enterprises on this side of the galaxy could afford to spare some loose change just sitting in their pockets.

The software is still open but not for abuse.

[karlkarl]

Is this particularly different to an AGPL / commercial dual license?

In some ways I do hope the GPL isn't actually encouraging more companies to make annoying internet based Software as a Service rather than "real" software just as a way to avoid opening up their own source in return. To me it seems that this and the Affero GPL is trying to address this shortcoming of the license.

[Anonymous Coward]

> Is this particularly different to an AGPL / commercial dual license?

The SSPL is based on the AGPL, with one section (13 IIRC) changed.

The AGPL requires sharing the software's source code with users who access the software over a network.

The SSPL additionally requires sharing any other programs used to install, manage, monitor, etc. the software when a service consists primarily of delivery of the software itself (eg. hosted database instances).

[WolfFan]

I don’t use it

But if I did, about here is where I would be looking to replace it.

[Chubango]

Open source continues to miss the point

Corporations continue to want have their cake and eat it too. Open source is so important that those that benefit the most financially and never give back (remember openssl being basically unfunded for years?). They cry the loudest, too. There's nothing wrong with having a dual license that allows for monetization (mainly through support) and a copyleft version that's for the community/no-commercial-support and can be forked and that perpetually preserves the freedoms of anyone who may one day use a fork.

[stiine]

Re: Open source continues to miss the point

Perhaps the devs should have thought of that when they started the project, whoever they are and whenever that was.

[Robert Grant]

She said she thinks that companies who, like Elastic, are disgruntled with the way cloud providers use their code, are not fully understanding what open source licences mean. “The cloud providers in my experience are using it in a way that’s acceptable within the open source licences,” she said.

Yes, obviously. That's why they're changing the licence.

[Crypto Monad]

It's your cash they're after

The code which was previously released under Apache 2.0 is now being released under two licences instead: the Elastic Licence and the SSPL.

The Elastic Licence is highly restrictive. It says you can use (but not distribute) the binaries, and only for certain purposes. You can look at the source code, but you can't use it: even if you build your own binaries from source, you can "use the resulting object code only for reasonable testing purposes". Essentially it's a full-blown commercial licence, where the cost for some uses of the software is zero.

The SSPL is less restrictive, allowing you to distribute and modify binaries and source. However if you provide Elasticsearch as part of a cloud offering under this licence, you must then release the source to your *entire* cloud environment, such that someone else could replicate the entire cloud. As such, it becomes a huge risk to any SaaS operator to use Elasticsearch anywhere in their infrastructure under these terms.

Of course, you can buy your way out of the risk by paying a licence to elastic.co. But why do that for Elasticsearch, and not for all the other myriad open source components you rely on in your infrastructure?

I think it's disingenuous for elastic.co to argue that cloud users haven't been contributing back source code patches. Nobody wants to maintain their own private fork - everyone wants their enhancements to be merged upstream to avoid the burden of carrying them forward. Look at Red Hat's contributions to Linux.

The reality is, elastic.co is more interested in getting your cash than your patches.

[needmorehare]

Re: It's your cash they're after

If cloud providers are using entirely open source infrastructure, they'll have no problem with these terms, since there's no special sauce to give up. If they're using proprietary code alongside their product to deliver things others can't using free software alone, then they'll need to pay up. This all sounds perfectly fair to me. It's a simple way to prevent people using separate programs alongside others to circumvent having to contribute back.

If they are already giving everything back to the community for everything they use then nothing changes.

[Crypto Monad]

Re: It's your cash they're after

But how is this different to all the things running underneath Elasticsearch: the Linux kernel, GNU utilities, the OpenJDK JVM, and libraries?

You can build a cloud service around all of these things without open-sourcing your special sauce. What makes Elasticsearch think it deserves to be treated differently?

AWS here are the good guys. They took the Apache 2.0 distribution of Elasticsearch, enhanced it with components which normally you'd have to pay elastic.co for (e.g. alerting), and then released it back to the world under Apache 2.0. It seems to me that elastic.co cares less about people "contributing back" code, than getting their cash.

On the other side, from AWS' point of view, I can understand that it makes no sense to buy a licence at their scale. Even if they negotiated favourable terms for now, it would leave them exposed to huge price hikes in the future.

[Nate Amsden]

Re: It's your cash they're after

Curious don't you think they are getting Microsoft Windows and Oracle DB licenses for running those products in their cloud stuff for customers?

https://aws.amazon.com/rds/oracle/

https://aws.amazon.com/windows/products/ec2/

I certainly hope they are paying for them, and I think it's safe to assume those costs are passed onto the customers.

[Peter Gathercole]

Can someone enlighten me please?

I've always been a bit confused about re-licensing software that has already been available under open-source licenses.

The way that I've always interpreted it is that if you obtained the software under an open license, and are using the version you obtained under that license in a manner that is compatible with that license, you can continue to do so without fear of the new license.

What you can't do is take later versions of the software, which may include bug fixes, without agreeing to the new license.

So, as I understand it in this case, you could take the version you already have, licensed under Apache 2.0 , and fork the source and maintain it yourself, or get some third party to maintain your fork (Apache 2.0 is very permissive IIRC). This would be very easy for someone like Amazon to do, and they could continue offering their derivative work under the Apache license.

Can someone confirm if my view is correct, or have I overlooked something?

[Anonymous Coward]

Re: Can someone enlighten me please?

Correct.

But your fork cant use the patches created in the original. You would need to rewrite all the patches yourself or get permission from all the people providing the code to use in your fork, as they are now provided under the new licensing conditions.

[Peter Gathercole]

Re: Can someone enlighten me please?

Thanks, that is what I meant when I mentioned patches, but I guess my language was not specific enough.

[Anonymous Coward]

Re: Can someone enlighten me please?

You were, sorry, I just missed it.

[Anonymous Coward]

Re: Can someone enlighten me please?

Yes. This is thornier than it otherwise needs to be in the case of ElasticSearch though because it's never been a truly open source project. The code is open source and it uses a permissive license, but the project is run by ElasticSearch-the-Company and while contributions are welcome the governance is entirely theirs to direct and crucially they hold all the associated copyrights. That means to fork the software you need to be someone suitably well-equipped to manage that copyright conflict, being prepared to at least change the name of the product.

There's a delicious irony in all of this in that fundamentally Elastic are getting Elastic'd. At its core Elastic is the open source Apache Lucene indexing/search engine. Elastic built their product - competing with Apache Solr - by taking the features of Lucene and building their own pseudo-open product around it, never contributing it back to the ASF from which they "took" it. AWS's actions are no different.

[Anonymous Coward]

Re: Can someone enlighten me please?

Disclaimer - I work for elastic.co, so posting anonymously

> taking the features of Lucene and building their own pseudo-open product

> around it, never contributing it back to the ASF from which they "took" it.

> AWS's actions are no different.

You're wrong, plain and simple.

The CEO of Elastic has committed code to Lucene before and after Elastic was formed.

Current and past employees of elastic are committers to Lucene.

Current and past employees of elastic are on the Lucene PMC.

You are simply wrong.

[Peter Gathercole]

Re: Thornier

Copyright is not an issue when forking. As long as all the code was covered by the Apache license at the time of the fork, and no later changes obtained from the copyright holder are later incorporated, that grants the use of the copyrighted work, regardless of whether the copyright holder wants to change the license.

Now trademarks are another issue. I agree that a forked product would not be allowed to use anything that is trademarked, like the name of the product or service (assuming it is trademarked), although when generic words in the English dictionary are used, it sometimes becomes more difficult to defend the mark. You could not call it "ElasticSearch", but variants including the words "elastic" and "search" (maybe not in that order) probably could be used.

[Anonymous Coward]

Re: Thornier

Entirely correct. The conflict I was referring to was in terms of non-code assets: product names and logos in particular. This has just caught out the original engineering crew behind Presto, who forked the project and have been forced to rename it to the now-entirely-unrecognisable "Trino". This is a pretty big barrier to setting up a fork - you really have to be committed.

[ayay]

AGPL for the win

Well, that's what AGPL is for.

All you hear is that it is a licence that just will not work.

And, funnily enough, out of MURICA with all their MOAR-MONEY corporations, seems that Nextcloud (AGPL licensed) is doing just fine... in Europe of course.

But no, I don't know of any major cloud provider offering it. That is awesome as far as I am concerned. Who the hell need those vampires anyway, other than the massive businesses who can afford the AWSs of the world - and not a penny to the guys coding the tools, ironically?

Let them enjoy each other. Stay out of it.

[Anonymous Coward]

I couldn't work out where the sspl stops

I'd really have liked a worked example of the sspl

If we use docker so I need to mirror source for that? Our website? Linux? Openstack? Windows?

[Peter Gathercole]

Re: I couldn't work out where the sspl stops

Different licenses have different permissions.

If you use software licensed under the Apache or GNU licenses, you must include a notice saying that you're using software licensed under those licenses, but if you do not make any modifications, you do not have to make source available.

If you make modifications to the software and distribute those derived works (although I'm not sure that offering a service on your own systems counts as distribution), under GPL, you must make those changes publicly available. But I can't see a similar requirement under the Apache 2.0 license. Indeed, the license says that you do not even have to license your modifications under the Apache license, just acknowledge that your code includes works licensed under the Apache license.

In this respect, Apache is very different from the GPL licenses, which say that if you use GPL code in a distributed work, all modifications should be released under the GPL as well, and made available in source. GPL does not allow GPL code to be included in or to include closed source non-GPL'd code. But there is the Lesser GPL which allows the use of objects created from unmodified code released under the LGPL to be included (like static linking of libraries) into distributed works.

As far as I can see, this means that you can make a commercial product including your own unpublished changes, based on Apache licensed software, without fear of of any repercussions. If this is what ElasticSearch Co. have done, they are quite within their rights to not publish their changes. This is both a strength and a weakness of the Apache license. It effectively allows code to be used to create derivative works without modifications being made available to other people. But it is a strength, because it allows code re-use with fewer restrictions, which might inspire more use.

The problem is that the Apache license can be used to build up closed code bases that directly compete with the original openly available code.