[metheus]

Disclosure: I work for MongoDB.

Forcing droves of community users to buy commercial licenses is not the intention of the SSPL -- indeed, it cannot serve that function, as it does not obligate them to do anything at all unless they are making the licensed software itself available to the public as a service.

[jillesvangurp]

The problem with that statement is that it is your company's lawyers interpretation of what it is all intended to mean. Yet, it's not certified by the OSS foundation and there are now loads of articles trying to interpret what it all means, which suggests to me that this is not a clear cut case of this being all that clear at all. Either way, your company is trying to actively restrict how the software is used even further than the AGPL already did.

I'd recommend sticking with well understood OSS licenses. There are plenty of those. This one is neither OSS (until the OSS foundation says otherwise) nor well understood. Both are problems. Especially when mixing with GPLed code. It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license. I'd still argue that that was the main point. I'd suggest celebrating any successful use of your software instead of trying to constrain it.

My suggestion would be to use Apache 2.0 and try to get companies to take a commercial license based on the merit of added value in terms of support, extra goodies, etc. This seems to work well for others in the industry (e.g. Elastic that recently IPOd); it's well understood; explicitly compatible with GPL; and has none of the disadvantage of rolling your own license.

[metheus]

Much of what you say about the lack of clarity is fair, but we hope that those things will be resolved when the SSPL gains OSI certification. In the meanwhile, we will do our best to 1) listen closely to the specific arguments as to what is unclear, and 2) attempt to dispel what we see as misunderstandings, often prompted by what is essentially FUD.

I appreciate your suggestions on what other licensing options we have. I think you really get what we are trying to do. That strategy is exactly how MongoDB has sold its enterprise edition for years. With apologies if I'm pointing you to something you've already read, we think the current landscape of the tech industry makes that insufficient, as our CTO's announcement post goes into: https://www.mongodb.com/blog/post/mongodb-now-released-under...

Anyhow, I do want to address this:

> It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license.

I think this is unfair. Everything we have said about the SSPL makes clear that it has one very exclusive set of targets in mind: large scale cloud providers with the means to strip-mine not just MongoDB, but any open source project with significant traction. And the one actual data point in this conversation supports that position: fatbird posted that they were on a sales call with MongoDB recently, specifically asked if they were affected by the license change, and were told "no". Is that a legally binding rider to the SSPL? Of course, not, but if the plan for the SSPL was to use it to wring money out of community users, wouldn't the answer have been "yes"?

If you've already read that announcement post, or if you now do, would you let me know if it makes anything clearer?

[jillesvangurp]

> I think this is unfair

I'm just parroting the sentiments here. This is how this move is perceived.

I think your CTO is wrong on this. This situation is not something that is going to improve with more blog posts, explations, or proclamations from your c level executives.

So, a wise move would be to roll this back ASAP and withdraw the SSPL.

This license is no a solution to Mongo's revenue problems and may actually make things worse. It sure doesn't solve any problems your users are having so whatever this is, it is not in their interest.

[thawkins]

Thats exactly how our legal dept intepreted it when it was announced. It took me several days to calm them down, including having to write up a migration plan to mitigate the risk.