If you think this is about Elastic caring about openness and freedom, ask yourself why they don't drop the CLA for a DCO and let themselves be beholden to the same terms

Counterpoint: FSF and Mozilla require CLA too

Except that FSF and Mozilla are not usual for-profit companies with primary mission of making as much money as possible. Elastic on other side is and it's funded by VC money that want return on their investment.

It's a viral open source license, it literally requires open sourcing code, there's nothing proprietary about it except that we allow a council of elitist snots to decide what is and isn't Open Source(TM), and they have decided Google and Amazon support is more important than viable businesses which are building open source businesses.

The SSPL literally violates Freedom 0.

> The freedom to run the program as you wish, for any purpose (freedom 0).

And though we're talking about open source instead of free software, without Freedom 0, the software still might as well be proprietary.

Edit: It also violates Rules 1, 5, 6 & 9 of the OSD. So no, let's not call it "open source"

Could you provide a link to explain how it violates "Rules 1, 5, 6 & 9 of the OSD"? Thanks

Common freaking sense reading.

https://opensource.org/osd

If you can't use the software because you're a cloud provider, that's rules 1, 5 and 6 easy.

If using it forces you to relicense all of your code under the SSPL that's rule 9.

It is well known at this point that the SSPL withdrew their request for recognition to the OSI because they do not meet the rules of the OSD.

> If you can't use the software because you're a cloud provider, that's rules 1, 5 and 6 easy.

I may be mistaken but I thought cloud-providers can use it and offer it for others to use as well, they just can't charge for that. But I may be wrong.

by definition sspl only qualifies as a source available license but it restricts stuff in so many ways that it is basically propriatary, even for normal uses. btw. even open source licenses are not free or libre, they also restrict usages, just not as hard as most source available licenses. source code is not open if I'm restricted to use it in most cases without making everything open, it's available of course, but that limits my use case by a huge margin. even open source (osi) licenses do that, but in a way more fair manner, which does not discriminiate usages. heck I'm not even a fan of gpl 3 (especially agpl) , because I think they also discrimnate usages and are also poorly written (too much stuff that is hard to understand without a lawyer)

This is incorrect, you are free to use the program if you wish, it just also, like the GPL, conveys requirements on open sourcing code you use with it. Open sourcing services without the necessary tools to run it isn't much good, so SSPL ensures the freedom to run your own better than GPL based licenses.

no. get it right. if you are not free to run the program without additional stipulations, especially stipulations that dictate how you license _your_ code, then you are not free to use the program as you wish.

Literally, "as you wish". Stipulations is "as we wish".

And you can read it from the OSI themselves: "The SSPL is Not an Open Source License" https://opensource.org/node/1099

The SSPL conveys no new stipulations not permitted by GPL-based licenses, it is just more inclusive in doing so.

If SSPL isn't open source, neither is the GPL.

GPL carries no restrictions if you don't distribute the software.

The AGPL on the other hand, was a huge mistake, IMO.

The AGPL was the first step in addressing a critical need to protect the users' right to run the software they use, the SSPL just continues that, as many services wouldn't be runnable without the support code around them.

I hear what you're saying, but those whose mission is to encourage open source software don't call the SSPL anything but a source-available, proprietary software license. Like literally the organization that defined what "open source software" is.

While you may disagree, you aren't going to convince me to take your word over theirs, especially when I have come to the same conclusions they did on my own.

On a moral principle, AGPL levels the playing field fairly much like the GPL license, just the terms of distribution are updated for an age of software as a service. No one is exempted to the rules in AGPL like SSPL - it is intentionally viral, even if you'd dislike using it in many of your projects (though I think it's fair to say lawyers don't like the ambiguity of the language).

Just like some projects are best under LGPL instead of GPL, AGPL has its place in the toolkit of free software licensing.

Could Elastic's business model work if lucene were licensed SSPL?

I think it probably could not. And if lucene were licensed GPL, it would not be possible for ElasticSearch to use this new SSPL license, it would be have to be GPL too.

The principle of in the GNU manifesto would be that the software is available for anyone to use in the same way, such that Elastic isn't elevated to not disclose their closed source additions to the software.

At this point, they are directly violating that core principle as well as the uncontroversial OSI directive 6 which copyleftists like myself don't really have a problem with... So I'm not sure what the issue here would be other than you dislike the larger companies' involvement in OSS? I think myself and others would appreciate clarification.