From where I left

> But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.

Well yeah, that's the point. Trading contributions vs maintenance burden.

> My point in all this is that contributing to open source often benefits the contributor more than the maintainer

And yet they choose to do it... Why?

I said it provides more benefit to the contributor than the maintainer, but I did not say that it provides no benefit to the maintainer. Your question doesn't logically follow.

They already have AGPL, these are just a slight step further.

> There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.

Thanks for the link. I'm a bit blown away. I believed the OSI story, because many major open source figures had endorsed or been a direct part of the OSI, so I didn't think there was any reason to doubt the veracity of what they were saying, and I never saw any direct contradictions, personally. However, the evidence is pretty damning. The OSI did not coin the term open source. Wow.

I guess it's more tangential since, either way, for better or worse, they won. But, I guess it is time to stop repeating that falsehood.

> In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.

That's fair. I think from my perspective, it feels like it's been rapid because it's only been a few years since it really kicked off, whereas architectural decisions to depend on a database or cache lasts a long time... I'm pretty sure software I've written 10+ years ago at companies using Redis is still in production.

> Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.

> Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.

> I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.

It's possible that nobody ever really planned it. I honestly don't believe Hashicorp or Redis, Inc. ever planned it. That said, every company that executed one of these re-licensing efforts does have something in common: they all reserved the right to do so from the beginning. I'm not sure if they did so with the intent to ever actually use it, but I'm sure it had to be a consideration. Otherwise, why bother with a CLA over something more lightweight like a DCO? (Admittedly, I already answered that to some degree. Though, there are alternatives. My understanding is that the Apache Software Foundation CLA allows you to retain copyright ownership while still achieving most of the other functions of a CLA.)

Ultimately, I agree with you 100% regarding ZIRP. Even I, someone with relatively little finance and economics knowledge, can see pretty clearly how there is a direct cause and effect relationship here.

I'm honestly very glad that there are less open source businesses popping up. As I have said, I have no problems using "unfree" software or paying for software. If "fair source" is the answer that makes everyone happy it is not a problem with me. Though, I really hope people consider not using the SSPL.

I think more companies that really do want to do OSI-approved open source but are afraid of cloud providers should consider AGPL though. It is riskier, but right now it's toxic waste to all of them that I know of, and it will still make it very easy for Linux distributions to package and distribute your software. But if they choose closed-source or fair-source first to avoid the potential to mislead people, it's pretty hard to fault them.

Thank you, I'll encourage my colleagues to take everything we can from ValKey, because this is how it works: as the BSD allowed the fork, the BSD allows less liberal licenses to take back. The magic of very liberal licenses is that: they speed up human evolution (and we tried hard to retain the BSD for this reason).

About Vector Sets: it's absolutely ok to disagree here; but what is a good thing about having multiple forks of the original Redis is that you can see it as an optimization to search for the better Redis :D The Vector Set stuff, just to be clear, was not "company stimulated", it's something that I really want and I which I strongly believe.