It’s a hard choice to make, but imho either keep your code proprietary or stick with “Apache OR MIT” … all this stuff about switching licenses partway down the line is really lame and just seems destined to backfire.

Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck, then it’s not going to hurt the big corpo teams, but rather the users. Big corpo teams are users too, they don’t want to deal with this legal mess either. Like it or not, Redis has always been a permissive open source project which is why it has been a success. Changing that is changing the equation in that regard going forward and portends bad outcomes for everyone involved.

We need to better recognize the difference between "Foundation" owned software like PostgreSQL vs Corporation Owner like Open Source. When you focus in "Maximizing shareholder value" the goal of keeping your user freedoms will inevitably be put aside.

It would be much better choice for Redis community if Antirez would seporate his employment from Project ownership and leave it in hands of some non profit. Something like Apache Redis would be much better for community and it also would allow Redis Labs to build proprietary extensions and cloud business around it.

That depends on who you consider the user. If it's the person buying managed redis, then this license change doesn't affect any user freedoms.

I don't know, it feels like this way of doing things doesn't work well, but pure open source also doesn't work well when you want to pay salaries to a bunch of devs.

I wrote about this conundrum a few years ago: https://www.mooreds.com/wordpress/archives/3438

OSS is a great way to build a community, increase adoption, and get attention. It isn't perfect at that, but it beats alternatives, for devtools at least.

But then you need to make money (especially if you've taken VC).

That's when the problems start. It's hard to make money on OSS unless you are using it as a complement to something you can sell. Especially in the age of hyperscalers.

And, as other posts indicate, switching from OSS midstream burns any goodwill you had when you started, and opens you up to forks.

It's not unique to OSS, though. Even devtools that cost money or are free but not OSS run into issues making money. Devs are a hard audience to sell to, in my experience. I know I am stingy.

no, devs aren't hard to sell to. It's business owners that are hard to sell to.

If you are running a business, every cost needs to be controlled for you to be profitable. Adopting open source is a form of cost control.

The problem of OSS is that the value proposition is that it is free-as-in-beer (as well as all of the benefits of OSS). So if/when the software becomes not free-as-in-beer, the company will have to reconsider, or change, or eat the cost if the cost is lower than the value generation of the software.

Open Source may also be less expensive, but I am paying with some combination of time and efort and support contracts or other service and sponsorships.

If your goal is profit, don't open source your core product.

We've seen this time and time again where a company releases their core software under a permissive license, and then bigger competitors come along and resell a solution redistributing their software.

If the company's central goal is profit, this is an existential threat. However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!

This doesn't apply to software that's secondary to your core product, e.g. a useful tool you've developed but don't make money directly selling to others.

That depends on whether those big competitors are contributing code back.

If they are, then great, the code continues to exist as high quality open source, even if you're playing a smaller role.

If they aren't, then the good version isn't open source. Your goal is failing even when you ignore profit. And at that point maybe an "open source except for those guys" license gets you closer to your goal in practice.

Or more fundamentally, don't open source your value prop. Open source your complement. So many OSS shops build a valuable core only to realise their actual business ends up being selling managed servers.

Sure they do. As the original authors of the product, they should have the best understanding of its features, and are in the best position to augment it in ways other pure hosting competitors can't or won't. They have first-mover advantage to build novel features, and integrate them into commercial propositions that benefit their customers first. They should also know best how to deploy and scale the product, even if their competitors excel at this.

If Redis Labs wasn't able to compete with AWS and other pure hosting providers, then they failed at taking advantage of their position. This is not an indication that the open core model can't be successful for both OSS users and the business. E.g. see Grafana.

Of course, this also depends on the nature of the product. A general purpose database or another core infrastructure product is much more attractive for hosting competitors than a purpose-built product.

It's not hard to create a profitable business on open source and make good money. The question is how much.

If your goal as a founder is to be a billionaire, open source products are not going to do it. You need monopoly-level rents to do that, like Oracle or Snowflake. There's plenty of opportunity to create millionaires. But you'll have to forego VC financing to do it because that math does not work for venture capital funds.

No, OSS developers retain authorship (with the exception of public domain). Only the authors can change the license and terms. Users get a license to do various things with the software/code, but they do not get ownership.

A copyleft project with no CLA, levels the playing field so that everyone has the same rights. Eg.: Linux kernel

This license change addresses this very problem so cloud mega corps can't leech.

For me it sounds like better AGPL.

I don't give a shit about philosophical nuances and OSI-approved list – at the end of the day this is much less restrictive license than AGPL - I have source code, I can run it locally, I can run it on my projects, I can run it on my commercial projects, I can run it where I work, I can use it on bare metal, VM, Docker, k8s and from Azure the same way.

The fact that Microsoft will have to share cut of the premium they're already charging is irrelevant to me – if anything I applaud for finding sustainable business model around it.

They are completely within their right to switch licences but it doesn't mean that we have to fall for the narrative that they are protecting themselves from the big guys. Let's be honest, no one would've used redis or terraform if it was closed source. Or if it wasn't available on the big guys platforms.

Redis started as a community project and had tons of community contributions. I'm sure that their effort to gain fairness for the smaller guys doesn't apply to anyone smaller than them. It's ironic that they did exactly what they imply the big cloud players did, scoop up open-source work to build corporate value

You can't if your offer directly competes with redislabs - ie. you are cloud provider and you're selling redis as a service. You have to share your profit margin with them through licensing in this case.

not having read the license (and not a lawyer), i dont know how far or direct it must be for it to be considered directly compete. Surely it's a very blurred area, which would then be rife with risk for anyone to adopt redis from now on.

Reselling redis-as-a-service or not is clear cut to me.

I'm not so much interested in philosophical explorations of theoretical "what if I resell redis but without this and that command?" cases either.

It's your choice between SSLPv1 or RSALv2.

If your product is open source, then you choose SSLPv1 and you're safe.

If your product is closed/commercial, then you choose RSALv2.

You probably want to look at RSALv2 [0] instead of SSLPv1. It's very short, plain and simple.

With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals. If it does that then you need to enter agreement with Redis Labs to share your profit margin with them.

Ie. if documentation for your offering redirects users to redis docs for usage of your product – you can't use RSALv2 because you're directly competing with Redis Labs with your offering.

This means cloud providers are directly impacted, not usual businesses that USE, not OFFER redis.

And frankly, that's the way it should be. This is the way to do sustainable, source available, open source compatible (through SSLPv1) business model.

[0] https://redis.com/legal/rsalv2-agreement

I understand why they do it. I just don't agree it works long term.

Most Redis users have never paid the company behind it even a single cent. Me included. So, I can appreciate them doing this in order to make some money. Except it won't change my behavior; I'll just use the fork. Just like the vast majority of other Redis users, external Redis contributors, all of the cloud providers currently offering Redis commercially, and by the time this runs it course probably a fair bit of current Redis employees.

Given the large amount of commercial users and cloud providers offering Redis, I don't think it will take long for them to get organized even. They pretty much have to given that they have lots of users paying them for this.

There are some precedents with Terraform, Elasticsearch, Red Hat, and a few other big players now dealing with a lot of their target users and potential customers depending on open source forks. As a business strategy alienating future users like that seems misguided.

When Oracle took ownership of Sun's open source projects (including such things as mysql, hudson, openoffice, etc.), they quickly lost control of most of that. Oracle's attempts to convince the world to use their closed source offerings never amounted to much. Even with Java, they more or less gave in and openjdk is where the action is these days. Except for a few banks, very few people use the Oracle JDK. There's no need, Oracle has long ago stopped pretending there's any advantage to that. All the development happens on OpenJDK. There are half a dozen different companies offering certified builds.

Anecdotically, I consult on Elasticsearch and Opensearch. Most of my recent clients default to Opensearch. It's just the way it is. They all go for the free and open source option.

The point here is that this can only end in one way: the creation of a Redis fork that will be used by the vast majority of current Redis users.

[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...

For what it's worth... Microsoft was quoted in the Redis press release as a cloud provider that has partnered officially with Redis under this new licensing scheme.

https://azure.microsoft.com/en-us/blog/redis-license-update-...

To avoid the short term, providers could "buy time" and keep prices low until the project deviates far enough from forks, making migration much harder, then increase prices.

Either way, long term they can end up with a lot of money from a few companies rather than continuing to support many mixed sized companies.

I don't like it either but I can see it working.

Broadcom is able to screw over its customers because they have to choose between either reworking a core part of their infrastructure, running legacy code without support (provided you have a perpetual license), or paying a huge license fee. With Redis, the current version is already open-source: you can maintain it yourself, switch to a drop-in replacement community fork, or pay one of the dozens of SaaS companies to run it for you. Switching away from the official Redis flavor can be as simple as a one-line change in your infrastructure recipe. If they increase their prices, why would anyone stay?

I think MySQL is probably a better comparison. After Oracle's acquisition they have been trying quite hard to add vendor lock-in and extract money out of it, but these days MariaDB has essentially made it completely irrelevant. I wouldn't be surprised if the future of Redis looked quite similar.

Invariably, someone looks at the numbers and realizes "We could make way more money if we only catered to the top 2% of our customers!"

Unfortunately, opinions and needs of the top 2% of customers != a generally useful product.

Thus, the reason to try and maintain user volume is better product-market feedback to guide development, instead of revenue.

When it comes to large corps, the prices paid for these products is already so large, because of the scale, that it often times makes more sense to employ your own, instead. These kind of decisions are taken all too often. We'll spend a good few sprints exploring possibilities/mapping differences/POCing to more accurately estimate all these findings and their ROI before deciding. This can also include tough migrations. At a previous megacorp; ELK did a nasty? Migrated to OpenSearch.

So, hard no on your take.

What we are seeing here, as others have pointed out, is that companies are buying Open Source solutions and then close sourcing them because they view it as a money maker which in the end leads to forks.

so the original owner of said OSS being sold is making money by selling it to this company (who might be told, or is sold the idea that said OSS could be monetized).

This is no different to a startup making their own acquisition the end goal.

What does not work, not long term, is trying to build a business around selling a FOSS solution - RedHat is probably the only notable exception here. But having multiple companies invest in a common tool that they all use as part of their infrastructure has worked wonders.

Kubernetes - Gooogle, Microsoft, Amazon,...

Python - Facebook, Google, Microsoft,...

clang - Google, Apple, Intel, IBM,...

Redis the project/tool existed long before Redis the company owned it.

Vagrant existed before HashiCorp owned it.

Significantly: both companies dropped permissive licensing after the creator of their (original) products stepped away, and both are venture capital backed companies.

So we could just as easily say "I see that long term people will preemptively fork projects the moment they are owned by a VC backed company"

We are probably not going to see mass investment by VCs in free software for awhile (perhaps never, but that is pretty strong), but developers will keep scratching our itch.

And maybe more and more developers and users will realise that AGPL/GPL/LGP are the only licenses which truly protect one’s software.

I don't think this is a fair assessment of the cause of the issue with redis, or hashicorp, or elasticsearch etc;

This wasn't some nefarious third party taking all the community good will and contributions and creating a private fork to kill the original projects.

If you don't want some corporate asshole to turn your open source project into a get rich quick scheme, don't give control of your project to that asshole.

I think you somehow missed the point where Redis the project existed and was extremely popular before it was owned by what is now Redis the company.

The competition for redis in the early days wasn't paid alternatives, it was other open source alternatives; Redis just provided a more featured solution.

It wasn't a "demo" for a paid product funded by corporate dollars or VC funding, it was just a thing that someone created, and released as an open source project.

It's hilarious that you think the companies dropping open source licenses for the products they bought are going to stop the industry using open source. As I said originally, it's going to have the opposite affect: it's going to make the industry embrace the very nature of open source and create forks of projects, the moment there's a sniff of a corporate buy out, specifically because of this type of activity.

I find it hard to believe many if any would see "create an open source tool" as a method to become a millionaire.

The ongoing uptake in open core, shows where it goes.

The above applies to private people as well. You use how many different pieces of software, what are you doing to ensure they stay maintained. (if you are like most nothing...)

Most users never will. That's the fallacy made by MBA types. They dream up some lofty sums "if only everyone paid us money". What they don't realize is that most users will find alternatives.

It sounds like a win-win to me.

For personal projects maybe yes, doesn't work for companies, they can't chase for thousand different forks of Redis and try to understand why feature isn't working properly on their version. Unless single fork emerges as a winner

I'm predicting such a fork backed by several core committers, and possible several cloud providers will emerge pretty quickly because they all need this to continue to exist as free and open source. AWS is not going to pay Redis a cent. Nor is Azure. Or Google. Or people commercializing open stack. All of those offer Redis support currently. Lots of their users use it.

The trend indicates that only open source libraries work for companies that own projects. If it's a program (e.g. server software like a database) then it's either source available or under a foundation. It's tough and I don't know what the answer is here.

I'd love to see a model that causes the pendulum to swing back the other way with open source permissive licenses for complex programs, but I don't see a viable way yet. Maybe trademark enforcement and open source code only with licensed builds?

Either way, I'm sure we'll continue to see the rise and fall (or license change) of popular open source software for years to come. There's too much benefit for developers and companies to start out open source. And there's too much pressure later on to change it.

At the very least, I'll give Redis credit for giving far more value to the world than they've captured. By an absolutely massive margin.

It'll be interesting to see how long a fork takes to land and if it'll be successful. And it'll be interesting to look at Redis (the company)'s revenue growth curve in 5 years.

Yeah, isn’t this just massive cloud providers eating the lunch of Redis etc? I don’t know enough about the licensing but I highly empathize with these small-mid sized companies building foundational tech that is commoditized and upcharged by an oligopolistic cloud behemoths. Surprised it's taken this long.

Question: what other alternatives than license changes are there, assuming we want a healthy ecosystem of both businesses and open source?

It's not technically fully open source, but it's pretty close to it.

Actually, I just took another look and they now market their "open core" as the apache edition (or perhaps have diverged from the "community edition" now)

Like the AGPL3?

https://spdx.org/licenses/AGPL-3.0-or-later.html

Holy cow am I so glad for every line of that viral leftist restrictive code!

Those producing work tools also have bills to pay.

In a way, developers themselves are to blame for the failure of the FOSS dream.

Slowly we are back to the public domain/shareware days.

Then there's the question of what I should be paying anyway. Who among all those non-free developers are paying in turn to all the professionals whose code they build on? Are proprietary developers somehow exempt from paying themselves? If and when I choose to pay I like to think all that contributed are getting the benefit.

There's a long line of professionals behind every code that should have been paid. Certain percentage might have tried to get paid. And even some who in fact did get paid.

Do as we did before the GNU days, analyse what really matters for a specific project development, pay for those tools, and keep using them until they aren't suitable any longer.

If I choose to pay for a tool and the tool maker doesn't pay for their tools, then how much better off we are? I can't really see this next iteration of non-GNU ecosystem faring that much better if only few benefit.

And for that matter, I did pay money for non-free tools. And bought Linux on those CDs distributors used to sell. Then the free-er ones somehow got better, so that revenue stream had nowhere to go. As I said, there's no easy way to pay for free stuff.

It is open source if the source code is available under an open source licence.

For example, OpenJDK is licensed under the GPL and Oracle provides licensed builds, but that does not make OpenJDK not open source.

But in the age of the "Cloud" companies will simply use the managed offering provided by Amazon/MS/Google/etc. basically destroying any financial opportunities for the maintainers and other people around the project. Also nobody wants to work their ass off on some OSS just to see AWS raking in milions off it without contributing back anything.

Madelyn Olson did the hard work for years to earn the trust of other Redis core developers to become a core maintainer, all while employed by AWS to do that work. She and other AWS developers have contributed a lot to the core Redis engine. Some may say that they too worked their asses off for the Redis community.

You can read more about some of those contributions here: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

(the page is now a 404)

  The core team has the following remit:
   * Managing the core Redis code and documentation
   * Managing new Redis releases
   * Maintaining a high-level technical direction/roadmap
   * Providing a fast response, including fixes/patches, to address security vulnerabilities and other major issues
   * Project governance decisions and changes
   * Coordination of Redis core with the rest of the Redis ecosystem
   * Managing the membership of the core team

Amazon simultaneously wants to be "part of the community" but also extract the maximum amount of profit via AWS. Amazon can just do a deal with Redis to share a percentage of the profits from their Redis usage. They don't have to, but they could. But no, they insist on having it for free, and we should be grateful that benevolent Amazon with their $23 billion operating income (from AWS) deems Redis worthy for a contributor or two (which is of course entirely in their own interest). Give me a break.

Amazon Inc. wants to maximize profits. Okay fair. I'm not against capitalism. But it holds others to a different standard by insisting they only (not Amazon) should be beholden to some different type of post-capitalist post-scarcity "let's all share together in community" type of model and cries crocodile tears when they model of extracting the maximum in profits while giving the minimum in return blows up in their face. You reap what you sow.

Amazon needs to either hold everyone to the same standard as they have for themselves or stop whining.

No, you can't have this both ways. I'm the main contributor from AWS, and I've worked many times on weekends because I care about open source. I like helping people, I don't need to be paid to do it. Many of the AWS folks that made changes were normal engineers that were excited to be part of Redis. https://github.com/redis/redis/pull/10419 and https://github.com/redis/redis/pull/8621 are both examples of features someone from AWS built in their free time. We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.

Your landlord and Tesco aren't an open source project.

If for instance I get paid $X to specifically work on Redis by Y. The open source project now has effectively a full time engineer they aren't paying for, one that likely would not be a full time engineer for redis otherwise.

You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.

So your argument is that instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.

Guaranteed one of the FAANG companies would just develop the tools internally instead if paying redis.

Wouldn't be better for both Redis, community and OSS movement if

1) Redis was fully OSS

2) AWS has a deal with Redis Labs were they share some X% of the revenue of their income for managed Redis (ElastiCache)

3) Redis Labs with that revenue can hire more maintainers

3a) Redis Labs with that revenue can pursue a competitive offering to ElastiCache (booom!)

4) AWS can still hire their developers and try to make them core maintainers to steer Redis development into implementing features they want/need

It's really impossible for me to paint AWS as the good citizen here and Redis Labs as the villain.

EDIT: I also wonder what history would have been if antirez started or moved to an AGPL3 licensing early on.

Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.

I don't have the time but go strip out all commits from FAANG companies employee and see if redis would be the product it is currently.

I'm not saying AWS is right but at the same time that is what redis decided to allow when they used the model they did. Now that they see they could be making a ton of money they want to retroactively change their licensing which is arguably also bad.

It's a money grab both ways which is what I have an issue with.

I'm pretty sure we will see AWS fork redis just before the license change and keep developing from there. They could even also then have all new code be proprietary as far as the current license allows that.

My argument is the industry in general is probably going to be worse of after this move than before.

All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent). That's why the FSF or SFC have no problems with AWS.

However, these companies don't want to collaborate with AWS on building Redis or Mongo or whatever. They want AWS to be their customer, or at least to stop being their competitor. And FOSS has never been about preventing others from becoming your competitors.

Can you point me to the code describing some of the secret sauce used by AWS? If AWS was a real good OSS citizen, they would use FLOSS software and create FLOSS automation to operate it at scale, no? We have hundreds of such tools out there: Linux kernel, IPVS, keepealived, HAProxy, Kubernetes etc etc etc. These are all plumbing that are FLOSS. Why isn't AWS publishing their own plumbing as FLOSS so I can potentially run a mini-AWS in my datacenter?

This already happens. Amazon is never the main contributor. That blog post talks about 33 commits for MariaDB for 2023. Like, that's great and all, but that project doesn't run on those 33 commits. It's the same with Elastic; when they did their license change I looked a bit at the commit history, and something like >95% was by Elastic.

And all these projects that did license changes are fine.

> At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally).

So, while I believe you're true in the general case, you appear to be wrong about Redis in particular.

I'm an open-source zealot and I have no beef with the SSPL.

Redis is still an open-source project for 99.99999999999% of entities on Earth. The only people crying foul about this are tech giants and the corporate drones at the OSI. Sorry if this sounds harsh, but normal people don't care about either of you.

I'm not going to shed a tear for your trillion $ market cap company being asked to contribute a little more in exchange for all the wealth they siphon from the rest of the world.

If the tech giant you're cheerleading for is such a fan of open-source, why don't they open-source the management layer like the SSPL asks? This would resolve this beef overnight, right?

There isn’t really any way for someone who wanted to offer software licensed under SSPLv1 to comply with the obligations of the license in good faith. This is what makes those obligations a “constructive restriction” [1].

[1] https://meshedinsights.com/2021/01/27/all-open-source-licens...

When a FOSS maintainer tells you they sometimes do work on the weekends for the love of the community [1] you believe them. The evidence (with timestamps!) is there for all to see in the pull requests and commit history.

[1] https://twitter.com/reconditerose/status/1770697315671535707

> There are people that work for Amazon that work on FOSS projects out of the goodness of their heart

So they work for free then?

Didn't think so.

They just have a job they like. That's great. But lots of people have jobs they like. And lots of people work on weekends. But don't try to spin this as an act of altruism, because it's not.

There are services with varying partnership terms, and there have been services launched with an intent to build long term mutually beneficial relationships that help ensure FOSS projects are well resourced.

“AWS, working with Grafana Labs, will be contributing licensing revenue and code to help make Grafana even better, not just for the AWS service, but also for open source users and Grafana Cloud customers.”

https://aws.amazon.com/blogs/opensource/how-aws-and-grafana-...

All I have to go by are AWS's huge profits and the continuing struggles of FOSS projects involved with AWS to develop sustainable business models.

You’re just showing your ignorance of redis. The project is sustainable without the company as the vast majority of work on the project is done by those who don’t work for the company.

What isn’t currently sustainable is the company. That’s all.

How much does redis pay those aws engineers for their contributions?

I know devs doing exactly this today. Devs who when the actions of their employer would have forced them to diverge from being able to do so, stuck to their convictions so much that they chose to terminate that employet contract so they could continue to do exactly that "in their spare time out of the goodness of their heart."

I will fully admit that I am not that kind of individual, I lack the capacity to contribute meaningfully in that way, but there are certainly many out there in our industry who are.

Wasn't Dwarf Fortress charity funded for a long time?

They only hit it big when they got the game prettified and on Steam.

The alternate future seems to be a headline like "Redis shuts down and stops development" anyway, so how is this different?

What do you think Redis should do? Continue to let the cloud providers run them out of business? And all because Amazon was gracious enough to fund 1 employee working on it? I think this thread is missing that response.

And these efforts involved more than one developer. It is only that one of them happened to be a core team member (which required working in good faith for the interest of the Redis community as a whole—a “commitment to the project”).

https://redis.com/blog/redis-core-team-update/

Amazon isn't running and charging for redis as a platform to make redis in the world a better place.

When such a line of business has a core component that is open source, the growth and health of the “upstream” project, its developers, and the user community is an essential component in its continued success. This is why folks on the ElastiCache team has been increasing their investments in both the upstream project code and in helping to maintain it as a “community-led” project under the previous governance structure.

Those investments increased the provision of digital public goods (as open source licensed software is generally considered to be a “digital public good” even if it is not technically in the public domain). Increasing the provision of digital public goods is generally seen as in service of the public good, as it (more often than not) makes the world a better place.

What do you want redis to do though as they are run out of business by amazon and the rest? Who pays for the rest of the developers?

It reads like Amazon is trying to bully their code supplier. The code was out there, and without negotiating Amazon decided on their own "one developer sending TLS upstream seems fair". I'm sure amazon will negotiate with Redis for some amount in the end. Or have the one developer write the drop in replacement if the code is only worth one persons time and some other random commits? Then maybe Amazon can even open source it with no restrictions?

Do you at least see and understand the perspective, that giant companies are making tons of money off software that is out there from smaller people. Giving back what is perceived not that much if anything?

AWS of course is the single biggest reason why projects are flocking to more restrictive licenses. The right thing to do for AWS would have been to respect the work of the original authors (/company) and throw their weight behind an offering supported by the original developers. Instead, AWS builds a competing product when they see an OSS product succeeding. Third party vendors stand no chance after that due to the tighter integration and marketing muscle.

Not to mention, Amazon and AWS give so little back to Open Source despite being a big (the biggest?) beneficiary. Google, Microsoft and even Oracle do more for Open Source than Amazon.

SSPL + no CLA: we don't want anyone to profit from the hard work of our volunteer contributors

SSPL + CLA: we don't want anyone but us to profit from the hard work of our volunteer contributors

If you want to dual-license your software, dual-license it from the people that helped write it, or treat their contributions as work-for-hire from the very beginning

The question is: WHO are you signing the CLA over to?

If it's a for-profit company, well, then do you trust that company to follow through?

If it's a non-profit, then look to see (in the US) if they're a 501(c)(3) public charity, which have legal restrictions on their governance, which typically require serving some larger public good. Also look at their history of past governance. I certainly hope (as an ASF peep) that we've shown who we are to be who we plan to be in the future; namely producing software for the public good.

Key reasons the ASF uses a CLA are protecting the org from future IP issues, and partly simply to be able to fix some future typo or legal issue in our license if one ever comes up. But the ASF will always provide all of it's released software under a similar style permissive license to Apache-2.0, as long as the organization is around.

If they're a 501(c)(6), then they're a business league, and might act more like a for-profit corporation, so...

Signing legal documents requires disclosure of personal information. Most CLAs require full legal names and often the names of employers. While Elric is my legal name, I prefer not to disclose my last name for a variety of reasons. Being able to commit to FOSS on a pseudonymous basis is impossible when CLAs are involved, which I think is a real shame.

I understand that orgs want to protect themselves, but CLAs only protect orgs, and can potentially harm contributors. Now, I happen to trust the ASF, and I hope my personal information is safe with them.

There is a solution to that in many jurisdictions: register your pseudonym as an "alternate name".

I'll refrain from going off on a naming tangent, but that stuff is wild.

What makes you think that? What stops a few "evil" people from getting on the board and changing the mission in some way and then changing the license so that it is no longer permissive?

I've never been clear on what stops the above attack. Many people have setup foundations on their death that are now promoting things the person was clearly against in their life. Martin Luther King Jr's "I have a dream" speech is now property of his heirs who milk that copyright for all the dollars they can get - I believe this is not what he would have wanted. There are plenty of other examples.

Practically, I know it because the ASF is a Membership organization, meaning there are hundreds of individual Members who have been elected by their peers inside the ASF. The Membership is the group who elects the board. The ASF has only individuals as Members (never corporations), and quite a lot of folks have made their careers about their ASF project work, while hopping between multiple jobs at various vendors.

So to mount an attack like that, you'd need to "evil-ise" a over a hundred Members to get them to vote for your hand-picked candidates who would be shunned by basically everyone else involved in the ASF.

https://apache.org/foundation/governance/members.html

Vendor neutrality and our permissive license are baked very, very deeply into everything the ASF does.

A fair number of 501(c)(3) foundations are similarly membership corporations, where the board is elected from the set of people who've been volunteering there for years, so they are unlikely to change direction like that. Some (c)(3)s are not, but still have a good track history. (c)(6) organizations are a mixed bag, since some explicitly allow sponsors to pay for board seats - a very different world.

I guess plenty of people have already made their own call on this matter but I'm still genuinely undecided. As much as the megacorps are rushing to rule the AI roost - it's possible it will turn out to be a universal solvent to some degree.

But I'm also pretty lukewarm about AGPL and SSPL. I feel there's a huge amount of fragmentation in open source land and I'm often unable to use code in situations where I feel the original creator would probably have been ok with it.

Don't forget that AWS is one of the biggest reasons so many OSS projects became popular. Redis, Mongo, ES, HashiCorp stuff, a complete big data ecosystem, got wider recognition through AWS's offering. Many people have yet to learn about dozens of obscure databases (that have been in development for years) simply because AWS or other big cloud providers have not pushed them.

Also, many projects receive a lot of contributions (bug reports, PRs, patches) due to liberal licenses increasing their use and popularity. I'm not particularly eager to contribute to anything with SSPL/BSL/etc-like licenses simply because I don't want to waste my time on something I can't use liberally in the future.

There’s a difference between developer popularity, and ability to actually use it in commercial product. If AWS provides a commercial alternative out of the box available within existing contracts and certifications, adopting that is low friction.

I do agree there’s some value in wider use but developers have to get paid. If users are paying someone who doesn’t contribute much to the upstream codebase at some point the project is going to founder. I don’t love the change as someone who’s been using open source for decades but the maintainer problem is real and won’t go away without structural changes.

Also, with AGPL-style license Redis will not become less popular. Anyone still will be able to use it as a cache, but not as a free work done by others that you can resell without contributing back.

Redis is newer than you think. Or the cloud is older.

Other commentators have already pointed out that this is probably not true.

But MongoDB relicensed before Amazon could launch a direct hosted offering and it is the biggest of all these projects. It did not want nor did it need Amazon launching a hosted variant.

That's what they do in some cases - their managed Grafana and Prometheus are a cooperation with Grafana Labs. But it's the only one I'm aware of, practically all other ones (MongoDB, Redis, Memcached, MySQL, PgSQL, etc.) aren't.

Should be general competition, including AWS, right? AWS does not host a Terraform service, yet HashiCorp feels the pressure from quite a number of competitors that offer Terraform as a service.

No one forces you to make OSS, you can be closed source from the beginning and no one will fault you. But companies releasing OSS as a growth hack because it's seen as a donation to the software commons and then rug pulling deserve every fork coming to them. Debian and Fedora don't include JSMin (not that it's relevant anymore but still) because the license says you can't use it for evil making it not OSS.

That's what OSS means -- everyone, even the worst person you know, especially the worst person you know, can use the software for anything they want.

This roughly means that 6.2 will go out of support once 8.0 is released, and 7.2 will go out of support once 7.6, or 8.0 is released.

Looking at prior releases, my guess would be to expect a 8.0 release around Mar-May 2025. So if you're relying on Redis under the 3BSD license, plan accordingly.

Note that Ubuntu packages redis under the `universe` repo, which means security upgrades are only available to Ubuntu Pro customers. So Ubuntu 20.04 will stop redis upgrades on Apr 2024, except for Ubuntu Pro users under ESM.

Debian 11/12 track Redis 6.0/7.0, so they are responsible for backporting the patches from 7.2. Unsure how this will happen once 7.2 stops receiving security updates, and they only go to the 7.4 branch.

Also note that you might be impacted indirectly (even if your usage of redis fits with the new license), because your distro will likely drop redis from its official repos in the next release, so should account for that in the next distro upgrade cycle.

(I maintain https://endoflife.date/redis, happy to merge PRs if someone has clarity on how this might impact EOL/Support)

Good timing.

There's a lot less incentive for Microsoft to muck about with the license and in that sense it's not really about trust.

Or maybe they saw redis had some shortcomings when trying to use in their cloud offering. The thing is that once it will get popular enough that other cloud providers might add it to their offering, the license likely might also change.

Yeah sure.

On one hand I could see why Microsoft would back the original project, since they likely don’t want Amazon owning a replacement (elasticsearch). But I’m not sure how they plan to honour the new licensing?

“Redis will continue to support its vast partner ecosystem – including managed service providers and system integrators – with exclusive access to all future releases, updates, and features developed and delivered by Redis through its Partner Program. There is no change for existing Redis Enterprise customers.”

I wonder how exclusive this actually is. Did Microsoft pay a boat load of money to freeze out Amazon?

https://microsoft.github.io/garnet/docs

> Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

While there are limitations, this is an active area of work for future versions of .NET.

(On the other hand, call me an old fart, but my trust in Microsoft has been completely eroded in early millennium and did not came back.)

The JVM and the .NET clr are just runtime JIT engines. It’s not like they ship with a full O/S and a hypervisor.

* compare with eBPF

Rust would have been a better choice.

And .NET can bundle the runtime, even in a single binary if you prefer that.

The bootstrapping path does not exist. There is (afaik) no way to go from C compiler to working dotnet environment. You are supposed to just download binary blobs from m$soft.

The repository looks promising, however the build.sh trying to reach to the internet during the build is disappointing. I would expect that to not help with having reproducible results. I need to look into how distributions approach this.

https://opensource.org/definition-annotated#6

That's the point of open source, and free software in a way as well. Copyleft licenses have restrictions, but as long as you follow those restrictions, you can build whatever you want using the software. SSPL, FSL, BUSL licenses outright prevent you from competing in certain commercial ways, no matter what.

Just because most business models don't want to comply with copyleft doesn't mean it's not open source - it just means it doesn't fit your business model.

No, its not. SaaS has existed for more than 20 years and reselling FOSS has been something it has done as long as there has been FOSS to resell.

What's changed recently is people launching venture-funded startups centered on gaining popularity through the appeal of FOSS with initially no clear monetization plan or one centered on selling services that were essentially just the FOSS, hosted. That’s the new thing, and why there is so much energy going into trying to figure out how to retain the marketing appeal of FOSS with the new licenses that lack the value proposition of FOSS.

Not from a single vendor everyone is already using (AWS, GCP, Azure).

> What's changed recently is people launching venture-funded startups centered on gaining popularity through the appeal of FOSS

Redis aren't a venture-funded startup.

> one centered on selling services that were essentially just the FOSS, hosted

Many companies tried open core and hosting, like InfluxData, and it still didn't work. It's a hard sell when the big cloud providers' services are right there, a click/tf resource away, with integrated billing just a line item you don't have to haggle over. Honestly the only one I can think of that is kinda working with that business model (but still losing money) is GitLab.

> That’s the new thing, and why there is so much energy going into trying to figure out how to retain the marketing appeal of FOSS with the new licenses that lack the value proposition of FOSS.

BSL/SSPL don't lack the value proposition of FOSS. You can still see the code, you can still contribute to it, you can still fork if it the company goes under or you disagree with their direction. The only thing you can't really do is compete with the company behind it, which most users actually don't care about and is hardly a part of the value prop.

That isn't new either. What has changed is some have found what looks like a path to monetization that seems like it might actually work. 20 years ago they never found a path to monetization at all. You just forgot about the other failed ones because they never went anywhere (though the source code may still be out there).

Some folks are working on terminology over here, if you're curious.

https://github.com/softwarecommons/softwarecommons.com/issue...

The non-ideological value of open source is exactly the commodification that the retreat to source available licensing seeks to end, along with downstream consequences of that commodification.

It is not a problem of terminology.