[bkuhn]

It seems to me that almost everything that needs to be said about the SS Public License has already been said. I have even posted twice about it (and related issues) myself a few times: https://sfconservancy.org/blog/2018/oct/16/mongodb-copyleft-... https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...

The only thing I haven't seen said succinctly, although it's been hinted at by many, is this:

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.

That really says it all. Whatever your view about copyleft licenses generally: legitimate and well-intentioned copyleft licenses (e.g., CC-BY-SA, GPL, and Affero GPL) have many projects that use the license in an inbound=outbound contributor licensing fashion. All (two of the) SS Public License uses have a strict CLA that give the publishing entity non-SS-Public-Licensed rights to the contributions. We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way. Period. I suggest we all try to not give further interest to this clearly risible licensing proposals from MongoDB and Elastic.

If there's energy to focus here, I'd say it's toward figuring out how to handle good governance of forks of these two projects. I hope folks can maintain the discipline to discern and bifricate these two very different issues.

[matkoniecz]

> We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way.

I would just treat them as proprietary. With access to code and opened gate to provide also code, if you are paying someone and they still do not care about your bug.

What may be better than fully proprietary and unavailable source.

I would not dismiss for example Windows just because they are not open source.

[ocdtrekkie]

It's worth noting that Crate isn't contesting that SSPL is a perfectly legitimate open source license, it's the GPL part that's the issue for them.

GPL and AGPL are just as much used to "poison the well" for potential competitors to a product also released as open source, and dual licensing strategies are a well-known part of open source businesses. This hasn't changed with SSPL at all, there's just a lot of pearl-clutching about the fact that the high and mighty OSI has not signed off on it.

[Pet_Ant]

> GPL and AGPL are just as much used to "poison the well"

But it is also legitimately outside of the purpose as well... unlike the SSPL. The Linux kernel for example. No one has ever looked at the SSPL and said “I want to work on that project” unlike the the GPL, which I believe is the GP’s point.

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

[ocdtrekkie]

Many of the people who are enthusiasts for the GPL should be similarly enthusiastic about the copyleft protections afforded by the SSPL. It, like the GPL, discourages commercial use by encouraging users of the software to open source any software they want to build on top of this software.

RMS would not be upset that the GPL poisons the well because companies don't want to open source their code, RMS would say they are denying user freedoms by failing to open source their code. The SSPL merely builds on this.

The only real sticking point here seems to be the OSI, and probably some manner of lobbying by tech firms to keep the SSPL from being accepted more widely as an open source license.

[xorcist]

> like the GPL, discourages commercial use

Comments of this sort was comme il faut in the 90s. But now, more than two decades later, GPL has proven its commercial value so many times over it's hard to take such arguments seriously.

Tit-for-tat business models grow faster than those staking out islands. Linux won. We need to move on from this.

[ocdtrekkie]

By "discourages commercial use", I refer to the very-real-today fact that plenty of organizations won't touch GPL or especially AGPL code because of the copyleft restrictions. This is largely the same for SSPL.

Amazon could use SSPL-licensed Elasticsearch on AWS, if they wanted to open source AWS, and they'd probably still make bank on it. But they don't want to, so hence going to SSPL, like GPL, discourages their use.

[2Gkashmiri]

Isnt sspl just agpl with "addtional" requirement only if you are a cloud service provider just for the benefit of their users? If am an end user of say Amazon, am I not getting more freedoms with respect to the source code of Amazon stack? Isnt that GPL is supposed to provide ?

[ocdtrekkie]

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

Doesn't particularly specify what type of business you have to be running, though it's obviously partially related to whatever type of software you licensed under the SSPL.

The GPL affects projects which embed GPL code into them, and the SSPL effectively does the same, it just draws the borders wider, to anything used to provide it as a service to others. In a copyleft sense, that promotes providers of it to also contribute to the ecosystem of tools around it.

[2Gkashmiri]

I dont think GPL forces anyone to contribute upstream. I am asking about the idea of freedom the end user enjoys with GPL code. Does sspl build on it, give more freedom to end user or restrict that freedom. If it gives more freedom, isnt that a good thing ? Why should people be up with pitchforks ?

[matthewmacleod]

I think that nails it.

I will happily contribute to a permissively-licensed code base for a project, although I'm aware that my contributions might be used in some closed-source platform later on. Exchanging my contributions for the ability to do whatever I want with the software is a reasonable trade.

I'm also willing to contribute to projects using copyleft licenses, on the basis that a project that requires all contributors to leave all of their contributions and derivatives of the product in the open offers a fair playing field.

I am way less interested in contributing to this new breed of semi-open projects, which require me to sign over my contributions in exchange for access under a license which stops me from using the project in certain ways, but grants one entity special privileges to use it in that way.

I think the evidence suggests that both GPL and permissively-licensed projects can be wildly successful. There are good reasons for both approaches, with different benefits and trade-offs. It's also legitimate to be irritated at "bad neighbours" who take without contributing back. I'm not convinced that this semi-open licensing approach is a benefit to anyone.

[matkoniecz]

> I'm not convinced that this semi-open licensing approach is a benefit to anyone.

It may be better than fully closed source? Just that it should be self-described as proprietary, with source available.