[gqewogpdqa]

Why the toxicity? AGPL was deemed by many to not be clear about what it was trying to accomplish. As I read in the various exchanges and articles around the time SSPL came out, I think they were just trying to clarify AGPL, not getting any more restrictive than AGPLs intent. And how would moving from a license that said you couldn't run a service bureau for free to something that says more clearly that you can't run a service bureau for free make MongoDB more money?

[gen220]

Sorry you’re right, I was being petty. I’ll explain my perspective in hope that we can learn something from this, but being flippant like that wasn’t justifiable. That’s a lesson in itself! :)

From my perspective, MongoDB (the company) “wins” by getting more people to purchase their product, and making MongoDB (the software) better is only one of the many possible dimensions to optimize in pursuit of this goal. When I see a license change by such a company, my null hypothesis is that somebody realized the marginal cost of changing their license would capture enough value (even if a smaller pie) to offset any potential harm to the community, brand, etc. It’s perhaps too cynical a view, and I’m open to learning otherwise.

I do agree that the AGPL is a mess, and there seems to be a consensus around this fact. It isn’t the correct license for a VC-backed firm trying to SaaSify a FOSS project, which is what MongoDB learned. And since SaaS is ostensibly its target audience, AGPL doesn’t come away looking great.

More broadly, I’m concerned for the developer productivity that’s wasted (from a humanity/society POV) in the corporate-driven pursuit of defensible and sellable intellectual property. Nothing wrong with making money, but I think it’s a tragedy that capital assets aren’t broken down, recycled and repurposed in the software world like they were in the industrial world.

From this angle, I view the GPL as a positive influence towards making our work less repetitive and more reusable. It makes me sad to see MongoDB move away from any GPL-based license, even when it’s in their shareholders’ best interest, because it means all the dev hours invested into MongoDB post-2018 likely will have been invested in vain.

But maybe I’m wrong and their new license means their software is still salvageable for the future, when MongoDB (the company) no longer exists! I’d love for that to be the case.

[gqewogpdqa]

I really appreciate the constructive response back.

From reading all the press, it feels like MongoDB did not do this to garner more revenue but to instead prevent open-source parasites from causing MongoDB to lose money or even go out of business. When I read Eliot's posts in 2018, it feels like he's trying to stay in business, not be greedy.

From a commercial point of view, databases have been shown to need management. Maybe someday somebody will write a database that has a magic simple-to-use endpoint, stays up 100% of the time, and doesn't require a cadre of people dancing around the database chanting spells to operate it. None to date... So the cloud providers capitalize on that need, and wrap control planes around databases - often hurting the people who are working hard to innovate on that software - and deserve to be paid for their work.

As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products. I.e. why would anybody want to improve PostgreSQL or MySQL when Amazon Aurora PostgreSQL and MySQL exist, CloudSQL and Azure SQL all exist - and may or may not take the changes - and even when they do, it takes many months or years.

Finally, I guess I'm puzzled by your last two paragraphs.

You mention that "all the dev hours invested into MongoDB post 2018 likely will have been invested in vain" - why? They go into the community edition, which anybody can use. They go into the EA and Atlas version, which customers who want enterprise-quality software with enterprise-quality support can use.

Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't. Or that it prevents them using MongoDB as much as they want. It doesn't, with one exception - and that exception probably affects <0.01% of the users of the software. The MongoDB license (and the Elastic and TimeScaleDB and many other licenses) don't even prevent anybody from wrapping up the software into a cloud service and offering it for money. In fact, many companies (SAP, IBM, Tencent, Alibaba, to name a few, apparently do). It just means you have to talk to the company before doing it.

I personally love MongoDB and I think the SSPL ended up preserving the company and preserving innovation, which is good for the open source community. At least it's not a complicated mess like MySQL and MariaDB.

That said, I'd love to hear more about how SSPL actually damages anybody in a meaningful way. I haven't yet seen anything except a philosophical argument. I'd love to hear it.

[gen220]

I appreciate yours as well!

I agree that, from a commercial point of view, databases have been shown to need management.

> As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products

I don't think we agree on this. I think PostgreSQL has improved dramatically in the past 5 years, coinciding with (but perhaps not caused by) its increased adoption by AWS customers. The more customers/users FOSS projects have, the more information they have to work with, and the more interested developers they have to draw contributions from.

But it's OK, we don't need to agree on this point. We can adopt the axiom "MongoDB is more innovative because they have a non-OSI-compliant license". Again, I don't think this is necessarily true, but I can concede it so it doesn't distract us.

> You mention <quote> - why?

The reason requires stretching our imagination just a bit, but I hope you won't see it as philosophical, since real people plan against scenarios like this. Let's say that, today, MongoDB the company is benevolent, and happy to permit anybody who asks to operate their software. Everybody's happy.

At some point in the future, there's some management change, and the company that owns this IP has decided that the best thing they can do is box-in the customers they have, and make other service providers' lives as legally difficult as possible, thanks to the license they switched to in 2018.

Now, in the future, if you want this database management service that we agree is important and necessary, and you don't want to use MongoDB's platform, you're out of luck.

If you stick to databases with an OSI-certified license, you never have to make contingency plans for this future. There will always be a vendor for code with this license, as long as there's sufficient customer demand, until time immemorial.

Because you can not control the tail risk of MongoDB becoming an Orcale-like company (or, for that matter, being acquired by Oracle), you can not rule out the possibility that all vendors will be excluded from offering MongoDB as a service. You need to plan for the worst case, and treat it as a time-bomb.

You might consider this a philosophical argument, but, practically, this is why OSI has rule #6, and it's why the SSPL (and Elastic License) are not OSI-certified.

> Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't.

Correct, it doesn't. It prevents them from contributing to software with a license that does not "Discriminate Against Fields of Endeavor" and does not "Restrict Other Software". Which again, doesn't seem like a bad thing today but opens up paths that are otherwise avoidable.

Even if we buy the innovation argument, and even if this change was made with the purest of intentions, it's noncompliance with OSI standards makes it not worth the tail risk for people who want to pick software today that will be serviceable in 15 years.

[gqewogpdqa]

I get your point, and thanks for the discussion. My thought is that even software with an OSI approved license can be moved to a non-OSI license at any time. So you can't actually insure against the dystopian future you are concerned about. The only way to insure against that is if the software IP is not owned by a company. It will be interesting to see how this plays out with TimescaleDB, Confluent, Starburst, Grafana, and a host of others - none of their code is owned by a foundation (like PostgreSQL is) but is instead owned by a company. And those companies have ( and will continue to ) do thing that protect their customers, employees, and stakeholders. Thanks for the clarifications - I understand now better the concerns of the OSI-favorable community.