All of the Apache projects (some to more/less an extant than others).

Most programming language implementations (e.g. CPython). Memcached. WireGuard. SQLAlchemy. Web Frameworks like Flask, Django, Rails, on and on.

There are many open source technologies that do not seek to capture the value they create with licensing hijinks.

I don’t think it’s an accident, that the ones that persist across generations are generally not structured as VC-backed firms, who care a great deal more about “value capture” than the average programmer capable of building such foundational systems. Usually “value capture” is correlated with “consumer harm”, and so they’re replaced over time.

From your example, K8s will definitely outlive Google. Hard to say about Android.

What leads you to say that? I wouldn't be surprised if kubernetes is dead in 20 years. I would be very surprised if google is dead in 20 years.

But I don’t think there’s a significantly-simpler, mature abstraction for doing container orchestration, than K8s.

K8s’ main advantage/stickiness factor, is how abstract and modular it is. It’s an opinionated Kernel that gets most things right and has a huge ecosystem of tools built around this kernel.

It has a very similar set of stickiness factors to Linux, imo, although the origin story couldn’t be more different of course.

I think if anything replaces K8s, it’ll take a Linux-like shape. But K8s gets enough things correct (licensing, api, modularity) that it’ll be hard to replace it wholesale.

What I was trying to say is that FOSS was never about capturing commercial value, and always about capturing the value of the freedom to inspect, share, and tweak.

In this regard, going AGPL is preferable to what Mongo or Elastic did. They basically turned to commercial "source-available" offerings, much like mainframe software from 1970s.

I totally agree that the “we are now AGPL” route is preferable.

FWIW MongoDB was already AGPL, but that wasn’t enough for them I guess, they wanted more money. Old HN thread on the topic: https://news.ycombinator.com/item?id=18229452

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.

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.

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.

Sorry, but free software IS open-source software. I take issue with how you're presenting these. Perhaps a better term would be liberally licensed software, as opposed to copyleft.

Market share/mindshare is almost an inverse measure of quality at this point!

Not necessarily knocking it, though!

If you only compare things above a certain quality threshold, That's true of any creative endeavor. Not too many people will say that Mcdonald's has the best burgers, or the pop singer of the week is their absolute favorite.