[HN Gopher] Redis is open source again
___________________________________________________________________
Redis is open source again
Author : antirez
Score : 1780 points
Date : 2025-05-01 15:56 UTC (1 days ago)
(HTM) web link (antirez.com)
(TXT) w3m dump (antirez.com)
| placatedmayhem wrote:
| I'm curious whether the community will trust Redis-the-company
| again after this, or if they'll choose to stick with Valkey. The
| other concern is at least some big company legal departments are
| wary of AGPL software, which makes Valkey, still BSD, more
| attractive to them.
|
| Edit: Regardless, thank you and the rest of the folks inside
| Redis for pushing to bring this back to OSS!
| ksec wrote:
| I am thinking the same that going to AGPL may actually push
| more people to Valkey.
|
| Although I haven't checked if ValKey any substantial
| development since the fork.
| reconditerose wrote:
| Yeah, there has been a lot of stuff like performance [1] and
| efficiency improvements [2]. A lot of the contributors, that
| didn't work for Redis labs but worked on Redis OSS before the
| fork, moved to Valkey and they continued to contribute.
|
| [1] https://valkey.io/blog/unlock-one-million-rps-part2/ [2]
| https://valkey.io/blog/new-hash-table/
| olavgg wrote:
| Valkey has RDMA support, which offers significant performance
| improvements.
| graton wrote:
| Well Valkey has more commits to their repository then Redis
| does, and more contributors. So it appears to be active.
|
| https://github.com/valkey-io/valkey
|
| https://github.com/redis/redis
| skywhopper wrote:
| In fact, some of Redis 8's new features were taken from
| Valkey source code.
| internetter wrote:
| Lol feels a little hypocritical to complain about
| proprietary clouds, then take open source software from a
| competitor and embed it into your own
| VWWHFSfQ wrote:
| I very much doubt that anyone will stick with valkey after the
| PaaS providers switch back to just offering Redis proper.
| md3911027514 wrote:
| Why would PaaS providers switch back to offering Redis?
| They've clearly all already invested a lot in Valkey (AWS,
| GCP, Heroku).
| antirez wrote:
| AWS, GCP, surely are invested: they paid for ValKey, they
| forked to avoid doing revenue sharing with Redis in any way
| :D IMHO it's a matter of what the community does, and it,
| in turn, this depends on how well we are able to develop
| Redis.
|
| It's not just licensing and hyper-scalers, it's also a
| matter of development quality and direction. For instance,
| now in Redis you can find substantial more stuff not
| available in ValKey, including hash items expires, Vector
| Sets that are very useful for a number of things, the
| probabilistic data structures just introduced with Redis 8,
| and so forth.
| lotharcable wrote:
| If Redis is superior then sticking with Valkey would just
| be throwing good money after bad. Hopefully those companies
| are competent enough to understand the concept of sunk
| costs.
|
| Maybe Valkey has served its purpose in pressuring Redis
| into playing ball.
|
| Just answering "why would". Whether or not Redis is better
| then Valkey or if it would be worth it to switch back is
| not something I know.
| kiitos wrote:
| AWS and GCP offer valkey-based versions of products that
| are typically based on Redis, but those versions are
| currently, generally, preview-grade, and statistically zero
| customers are using them. They still offer the original,
| Redis-based versions of those products, which,
| statistically, 100% of their customers are using.
| reconditerose wrote:
| Do you have data to back up your claims? I see a lot of
| customer claims for Valkey here,
| https://aws.amazon.com/elasticache/customers/. Neither of
| the AWS or GCP offerings are in preview.
| ziddoap wrote:
| > _and statistically zero customers are using them_
|
| You've said this twice now, but not provided any data or
| even a hand-wave to a possible source so that others
| could go get the data and look at it.
|
| If it's _statistically_ something, where are the stats?
| kiitos wrote:
| valkey was introduced as an opt-in alternative to Redis
| as an implementation choice for specific products offered
| by the the major cloud providers approximately 9 months
| ago. Generally valkey is shown as a preview or beta or
| whatever option. Nobody has performed any kind of
| automatic or default transition from Redis to valkey for
| existing customers.
|
| My claim that statistically zero (cloud provider)
| customers are using valkey should, I sincerely hope, be
| self-evident.
| ziddoap wrote:
| > _My claim that statistically zero (cloud provider)
| customers are using valkey should, I sincerely hope, be
| self-evident._
|
| I have no idea what the actual stats are. But no, I don't
| find your "statistically 0%" to be self-evident,
| especially in light of the other comments and links in
| this thread, and what I've heard elsewhere.
|
| I was hoping, since you presented it so confidently, that
| you had something more than "trust me". In another
| comment you say you have evidence of marketshare, maybe
| you could post that?
| joshstrange wrote:
| Their stats are "I asked an LLM", no, that's not joke,
| see this thread:
| https://news.ycombinator.com/item?id=43860256
| kiitos wrote:
| My stats are not "I asked an LLM", that was a response I
| gave to a specific comment, go away
| ziddoap wrote:
| If your stats aren't from "trust me" or an LLM, can you
| please just post where you are getting your market share
| stats from?
| skywhopper wrote:
| But if that's your typical method of research, I have bad
| news for you about the quality of the statistics you're
| relying on.
| AustinWentz wrote:
| >Nobody has performed any kind of automatic or default
| transition from Redis to valkey for existing customers.
|
| >My claim that statistically zero (cloud provider)
| customers are using valkey should, I sincerely hope, be
| self-evident.
|
| This is simply not true. For example, Aiven (a cloud
| provider) completely ended support for Redis at the end
| of March and migrated existing users to Valkey.
| https://aiven.io/docs/platform/reference/end-of-
| life#aiven-f...
| kevinsf90 wrote:
| I recently moved on to a new company, but my prior
| company had a pretty large scale Elasticache Redis
| deployment in production (over 50 large clusters in us-
| east-1), and were in the middle of a complete migration
| to Valkey due cost savings, improved performance, and
| reduction in memory usage.
|
| We've already completed migrating several large
| production clusters and I can confidently say that the
| migration had been pretty smooth and seamless.
|
| Valkey is certainly production ready (at least on AWS it
| is). The team is looking forward to expedite and complete
| the migration
| kiitos wrote:
| Statistically nobody is using valkey.
| echoangle wrote:
| Are there usage stats available? How do you know this?
| Osiris wrote:
| My guess is most people are using Redis via cloud
| providers. Did any cloud providers switch away from Redis?
| andenacitelli wrote:
| AWS supports Valkey for Elasticache, and they actually
| bill it 33% cheaper. We use it and it works well.
| pjm331 wrote:
| AWS Elasticache gave a nice discount to switch to valkey
| w/ 1 button click no downtime migration path
| aweiher wrote:
| ValKey is cheaper in AWS than Reddis
| echoangle wrote:
| Wasn't the whole point (or one of the major ones) of
| Valkey so that AWS could use it?
| reconditerose wrote:
| My guess is they are making it up. AWS has no public
| information, but there are some high profile customers that
| have migrated
| https://aws.amazon.com/elasticache/customers/.
| shaky-carrousel wrote:
| Without sources, it's a "statistically worthless" comment
| :)
| achillean wrote:
| Based on Internet-accessible services the number of Valkey
| servers is low (~120):
|
| https://trends.shodan.io/search?query=valkey_version+port%3
| A...
|
| Here's a chart of all Redis-compatible services (~55,000):
|
| https://trends.shodan.io/search?query=port%3A6379+redis_ver
| s...
| echoangle wrote:
| And how representative are publicly accessible
| redis/valkey instances for redis/valkey usage in general?
| And can shodan even differentiate Redis from a Valkey
| instance setup in a backwards-compatible way without
| being able to authenticate?
| teaearlgraycold wrote:
| I don't know about valkey but I got word Nvidia was switching
| away from Redis.
| cyrnel wrote:
| Amazon really encourages valkey in the elasticache dashboard.
| There's a banner advertising lower prices and it's listed
| first in the dropdown when you go to create one. Default
| settings do have power.
| kiitos wrote:
| Sure, but the impact of new customers and their decisions
| take a long time before they impact net statistics. All
| evidence I can find, regardless of domain or context,
| suggests Redis vs. valkey marketshare is something around a
| 99%/1% difference.
| rustc wrote:
| > All evidence I can find, regardless of domain or
| context, suggests Redis vs. valkey marketshare is
| something around a 99%/1% difference.
|
| What evidence did you find?
| rmsaksida wrote:
| I've been using Valkey simply because after I updated to the
| latest Fedora version, it dropped redis and pointed me to
| Valkey instead. I assume as more distros do this and more
| people update their systems, the Valkey user base will grow.
| But perhaps with the AGPL redis that will no longer be the
| case.
| shaky-carrousel wrote:
| Yeah, all the open source distributions and most open source
| projects switching to valkey must be "nobody".
| _msw_ wrote:
| If you use the latest versions of Redis, you are benefiting
| from the continued efforts of the Valkey development
| community. [1]
|
| This is Open Source working well.
|
| Unfortunately, the reverse flow does not work.
|
| [1] https://github.com/redis/redis/pull/13638
| graton wrote:
| I wonder how that works legally with CLA. If the person who
| originally wrote the code is not the one who signs off the
| PR. I assume the lawyers have signed off on it.
|
| Did they maintain the author's copyright notice as required
| by BSD-3?
| darkwater wrote:
| Well, now that Redis is once again Open Source and even
| Free Software, that should change.
| jzb wrote:
| That kind of assertion _really_ needs some backup or it 's
| just noise. I'll be honest and say that I have _no idea_ what
| the usage stats for Valkey are -- and it may be that it 's a
| drop in the bucket compared to Redis. _But_ I don 't know.
| Can you back this up or is this just your gut feeling?
| oweiler wrote:
| Yet. It's a drop-in replacement, and both faster and cheaper.
| lurking_swe wrote:
| what do you mean? i work at a FAANG-adjacent company and our
| entire engineering org was told to switch to valkey, with an
| internal deadline from ops. My team supports a public facing
| service and we made the switch 2 months ago.
|
| It was pretty easy, a small config change and some
| performance testing to make sure it worked well at scale.
|
| Maybe nobody is talking about it online but some people have
| definitely switched.
| seneca wrote:
| All of this aside, Redis-the-company has some of the least
| tactful salespeople I've come across in my long stint in this
| industry. Used car sales level tactics.
|
| Between that and the licensing, I would never consider dealing
| with them.
| antirez wrote:
| The team of sales was, AFAIK, rebuilt from scratch recently.
| Please if this happened recently tell me, and I'll make sure
| to report back. Thanks.
| cortesoft wrote:
| We kept using redis, the license change never affected us. We
| had no reason to switch.
| ketzo wrote:
| I imagine there is quite a large, quiet fraction (majority)
| of users who were the same way.
|
| Not to say it's not an important discussion!
| Alupis wrote:
| Many people switched to Valkey and didn't even know it. A
| lot like how many users are using MariaDB but think they
| are using MySQL.
|
| Several major linux distros transparently switched to
| Valkey and the users are none-the-wiser. On Fedora, for
| example, doing `sudo dnf install redis` just installs
| Valkey.
| sigzero wrote:
| Well that's a reason not to use a distro right? If I type
| `sudo dnf install redis`, I want to install redis not
| valkey.
| Alupis wrote:
| I disagree probably because I'm just used to it. Most of
| your major distros do this, including Fedora and Debian
| (the two largest). Usually this is due to license issues.
| fastball wrote:
| "I'm used to it" is a terrible reason for disagreement.
| gkbrk wrote:
| If I update my packages and suddenly an open-source
| software is replaced with a closed-source one, I would
| blame my distro. It's totally normal for distros to
| replace packages like this with the best replacement they
| have.
| cortesoft wrote:
| This would suck if you wrote scripts that looked for a
| process called 'redis' running on your machine.
| thayne wrote:
| I'd imagine the package would have a symlink for redis
| that points to valkey
| cortesoft wrote:
| Even with a symlink, the running process is going to be
| called valkey, not redis
| thayne wrote:
| Only if valkey explicitly changes the program name after
| it starts, or Does something like calls exec on it's
| program directly. At least on linux.
| fastball wrote:
| I think that is not normal at all, and absolutely should
| not be normalized.
|
| It is _much_ worse for my package manager to install a
| totally different software, than for my package manager
| to install a new version of the software I asked for that
| now has a different license. Also as an aside, SSPL is
| not closed-source.
|
| If the distro wants to do something, they can throw a
| warning up saying "this package is now licensed with the
| SSPL, would you still like to install? Try installing
| valkey for a BSD-licensed alternative". But installing
| software I didn't ask for is bad, actually.
| Alupis wrote:
| You're a bit late to the party. Its been normalized for
| almost as long as distros have existed.
|
| No, you don't just randomly have a different package
| installed one day, at least on major distros. The next
| distro release will include the new package. If for any
| reason you care, you can always go install the other one
| you want instead as well, it just won't be part of the
| default package repos.
|
| Generally, the replacement packages are 1:1 with the one
| they are replacing, and/or compatibility shims are
| included during the install. Its seamless. Also,
| generally the package manager does tell you what it's
| installing.
|
| The major Linux distros are very careful about this
| stuff. The two largest have huge enterprise user bases,
| and it's never been a problem.
|
| Many of the Linux distros are extremely opinionated on
| what goes into their default package repositories - it's
| a major reason why you choose certain distros. You are
| delegating all of this concern about packages,
| compatibility, bug/security fixes, and licenses and
| whatever to the maintainers of the distro. They are very
| careful not to break existing systems, and aren't going
| to surprise you one day with a major disruptive change.
| For them to replace Redis, for instance, with Valkey,
| it's going to be on the next major os release, it'll be a
| drop in replacement (all Redis commands continue to work,
| etc), and you'll have an opportunity to see this change
| while installing packages. This isn't "shoot from the
| hip" npm style stuff...
| lblume wrote:
| On Arch Linux, you are explicitly asked whether to
| replace a package with the (distro-)designated successor.
| fc417fc802 wrote:
| > But installing software I didn't ask for is bad,
| actually.
|
| Except it's a fork, so it is what you asked for. The name
| changed, sure, and there's a different governance
| arrangement. But pretty much the entire point of using a
| distro is offloading decisions such as which developers
| and repositories to trust onto the maintainers.
|
| If you want to make those decisions for yourself then you
| should obviously be cloning and building from source. I'm
| not just saying that - I myself do exactly that in cases
| where it matters to me.
|
| If you don't care about license purity then perhaps don't
| use a distro that explicitly filters on that?
| rascul wrote:
| > Also as an aside, SSPL is not closed-source.
|
| It's also not a free and open source software license.
| This is disqualifies software using it from being in the
| main repos for various distros.
|
| Seems like some sort of user prompting could be
| acceptable, though.
| Xunjin wrote:
| I understand your point, but that's how distros handles
| mostly licence issues. And I do believe that's the right
| way, we should strive for OSS projects in a distro that
| literally focuses on it.
| skywhopper wrote:
| Not really. Post-closing the source, the thing called
| "Redis" was the actual fork, and Valkey was the original
| community-built product. Users who want existing
| configurations to continue working on the same terms need
| "install redis" command not to break their licensing
| expectations.
| cortesoft wrote:
| First, they didn't "close the source". The new license is
| not closed source. You can argue why you think the
| license is bad, but it is not closed source.
|
| Second, I don't know about you, but continuing to
| function in the same way is my primary need for systems I
| am managing. When my provisioning system installs a
| package by name, i expect it to work in the same way as
| before. Switching binary names breaks that promise.
|
| My setup has scripts that do things like check that a
| process named "redis" is running... this will break if
| the process is now called "valkey"
|
| I feel like all the commenters live in some kind of crazy
| alternate world where purity of license matters more than
| stability of systems.
| barotalomey wrote:
| > When my provisioning system installs a package by name,
| i expect it to work in the same way as before.
|
| But where do you put the blame?
|
| The distro for making that change, or the redis company
| for breaking your software stack?
| cortesoft wrote:
| Look, I know licensing decisions are important and a lot
| of people care a lot about them.
|
| For me and my company, though, it just doesn't matter. We
| don't use redis in a way that would ever come into
| conflict with the license, so it really doesn't affect
| me. Redis didn't break my software stack with the license
| change. I am sorry, but I just can't get up the energy to
| care that much about which license they choose. If it
| helps them make money, fine go for it. I can't root that
| hard for the side Amazon is on.
| s1mplicissimus wrote:
| > Well that's a reason not to use a distro right? If I
| type `sudo dnf install redis`, I want to install redis
| not valkey.
|
| Using a distro that handles things your way is your
| privilege. I assume most people who install packages care
| about the functionality they provide, not the brand name
| - so it seems like a fair default for distros that aim to
| appeal to broad user bases imo.
| nozzlegear wrote:
| > Using a distro that handles things your way is your
| privilege. I assume most people who install packages care
| about the functionality they provide, not the brand name
|
| This is an amusing example of "the duality of man,"
| having just finished reading a bunch of comments to the
| effect of "the user should have the ultimate say as to
| what apps they can install from the App Store" in the
| Apple thread.
| fc417fc802 wrote:
| But you do have the ultimate say in this case. You can
| reconfigure the mainstream package managers in all sorts
| of ways, set up your own repos, anything you'd like.
|
| I use a distro because I don't have the time or energy to
| do all of that for myself. It's a purely voluntary
| arrangement unlike the iOS/Android duopoly that modern
| society is increasingly built on top of.
| cortesoft wrote:
| It's not just the brand name, it's also the binary name.
| All the support code I have expects the binary to be
| named 'redis'
|
| Also, what happens if functionality drifts?
| nektro wrote:
| 100% if they wanna stop shipping redis they should just
| remove the redis package
| barotalomey wrote:
| Problem is, redis threw their users under the bus by
| relicensing [1], and user would end up with an outdated
| redis version.
|
| 1: https://github.com/redis/redis/commit/0b34396924eca4ed
| c52446...
| ramon156 wrote:
| Same here. The response from the community was valid, but
| basically didn't affect us.
| dharmab wrote:
| From the blog post it seems like existing users kept using
| Redis but new users adopted alternatives instead.
| zimpenfish wrote:
| > it seems like existing users kept using Redis
|
| Redis user since it appeared and I switched my servers
| (~15) to Valkey - partially because of the shenanigans,
| partially because Arch is moving Redis to archive.
| llmthrow103 wrote:
| We switched to Valkey on our Elasticache instances and
| immediately noticed a performance improvement in our usecase
| that allowed us to reduce number of instances. Not really
| interested in moving back to Redis at this point.
| eknkc wrote:
| During this time I believe a lot of alternatives (mostly protocol
| compatible to redis so they would be drop in replacements) came
| into light.
|
| Has there been a consensus on one? Is there a winner?
|
| I love redis and will probably keep using it. Just curious.
| DeepYogurt wrote:
| Valkey has replaced redis in a few distros
| ezekg wrote:
| Also PaaS like Heroku adopted Valkey as a drop-in replacement
| for Redis.
| eknkc wrote:
| It is a fork of the latest oss release right? I thought some
| completely new implementations were introduced.
| reconditerose wrote:
| It's not just a fork, there have been two releases on
| Valkey that improved performance and memory efficiency.
| There is a lie that Redis likes to spread that only their
| own employees were working on the core engine at the time
| of the fork, but most of the engineers on Valkey came
| directly from having worked on Redis OSS. A recent example
| is we modernized the hash table a bit:
| https://valkey.io/blog/new-hash-table/.
| antirez wrote:
| Nobody wants to deny that Redis got from contribution
| from external developers. But it is fundamentally true
| that for like 8 years _almost_ every substantial
| contribution was created by people working for Redis, and
| that later we got something that was still a small part
| compared to the total.
|
| There are the commit histories, the GitHub contribution
| graphs. Everything is public. The current code base was
| written for the majority by a few single folks, for
| another small amount of the sum of all random people in
| the community, for a smaller part by people that now work
| at ValKey.
| avinassh wrote:
| this lwn article supports the argument that many cloud
| providers contributed back to Redis:
| https://lwn.net/Articles/966631
|
| > It is also hard to reconcile the claims that cloud
| providers do not contribute with the actual commits to
| the Redis repository. A quick examination of the commits
| since the 7.0.0 release using gitdm shows 967 commits
| over that time period: Top changeset
| contributions by employer (Unknown) 331
| 34.2% Tencent 240 24.8%
| Redis 189 19.5% Alibaba
| 65 6.7% Huawei 50 5.2%
| Amazon.com 50 5.2% Bytedance
| 19 2.0% NetEase 13 1.3%
|
| > Binbin Zhu, of Tencent, is responsible for nearly 25%
| of the commits to the project. Some of the contributors
| without a readily identifiable employer surely are Redis
| employees, but it's clear that the company has not been
| working alone.
| antirez wrote:
| If you go into the GitHub of any of the forks, and check
| the contribution page, you will see this data is not
| correct. Probably _all_ my commits are into this
| "unknown", since I push with @gmail.com account without
| being part of any organization for most of the time.
|
| This is likely some partial data of some specific fork or
| alike.
| _msw_ wrote:
| The LWN article is examining the 976 commits made after
| the 7.0.0 release. I don't think you had any commits
| during that time?
|
| As is typical for software projects, early authors will
| be disproportionately represented in revision histories.
| I am still the #4 contributor to the Anaconda installer
| [1] originally used by Red Hat Linux, then RHEL, then
| Fedora, and others, despite not contributing to the code
| base for two decades.
|
| [1] https://github.com/rhinstaller/anaconda/graphs/contri
| butors
| ezekg wrote:
| Of course it's the AGPL, which is essentially the SSPL in
| practice.
| kstrauser wrote:
| Except that it's actually open source.
| ezekg wrote:
| In word, but not in deed. I'll say it over and over again:
| COSS startups don't adopt the AGPL because they want to
| prioritize user freedom, they adopt it as a means of defense.
| happymellon wrote:
| Absolutely in deed.
|
| Just because they don't have the same motives as you,
| doesn't stop it being a user freedom. Anything that shares
| the changes and improvements is a user improvement.
| ezekg wrote:
| You misunderstand my point. Startups adopt the AGPL, not
| for user freedom, but because of the FUD that makes the
| AGPL just like SSPL in practice.
|
| I wrote more about the issue here:
| https://keygen.sh/blog/whither-open-source/
| anticorporate wrote:
| I don't really care _why_ they adopt it, only that they do.
| AGPL is a license I can use, SSPL is not.
| ndiddy wrote:
| The difference is how compliance is handled for cloud
| providers. Complying with the AGPL requires releasing the
| source code for the program you're hosting as a service.
| Complying with the SSPL requires releasing the source code for
| "all programs that you use to make the Program or modified
| version available as a service, including, without limitation,
| management software, user interfaces, application program
| interfaces, automation software, monitoring software, backup
| software, storage software and hosting software" under the
| terms of the SSPL. This is effectively impossible for any cloud
| provider to comply with (it would require a massive engineering
| effort to rewrite every single piece of software used to convey
| the service), which is why the OSI didn't approve it as an open
| source license.
| xiwenc wrote:
| A bit more info from CEO: https://redis.io/blog/agplv3/
|
| Sounds like SSPL did not yield the desired outcome.
|
| Glad AGPL is an option now.
| ocdtrekkie wrote:
| It did yield the desired outcome: Google and AWS are no longer
| using it.
| jillesvangurp wrote:
| If by desired outcome you mean split the developer community
| and then chase them away to a newly forked competitor that is
| now widely used by all the cloud providers and users that
| prefer open source; complete success!
|
| But I doubt that was the outcome that they hoped for. They
| created a large and successful competitor that by nature of
| being a fork does exactly the same thing. It's pretty hard to
| compete with yourself and the differentiate from your own
| product.
|
| Honestly, I think Redis Inc. was better off when there was
| just one code base. AGPL just marginalizes them further. It's
| not an acceptable license for many corporate legal
| departments. So, it would necessitate buying a commercial
| license for such companies. I.e. Fortune 500 companies,
| public companies, and pretty much anything with a legal
| department worthy of the name. Note how Redis advertises
| AGPLv3 as "one" of the available licenses. The whole point of
| that license is selling commercial licenses.
|
| Valkey is at this point stable and supported and a drop in
| replacement. It's pretty much the default choice for anyone
| not interested in buying a commercial license. That genie
| isn't going back in the bottle with this license choice.
|
| More importantly, Valkey is a pretty active Github project
| with dozens of contributors in the last month. More than
| double those in Redis. Those commits aren't going to Redis.
| And Redis still requires the right to re-license your commits
| if you try to contribute. That's how they were able to pull
| this stunt to begin with. I doubt a lot of the Valkey
| contributors will be moving back to that status quo.
| skywhopper wrote:
| Not sure how the hyperscale clouds switching to a
| compatible/competing project from which Redis Labs gets no
| value or contribution is a win.
| VWWHFSfQ wrote:
| I'm guessing valkey will be dead now?
| detaro wrote:
| why? The investment into it has already been done, and quite a
| few places will be happier with its license still. I think
| enough has happened/too much time passed that its not a given
| everyone will just quietly move back to Redis.
| kubatyszko wrote:
| Sure, but the damage is done already, and it's AGPL too.
| MrFurious wrote:
| I can understand problems with SSPL license, but i cannot
| understand the problems with AGPL. If you use software for your
| SAAS service for free, and made changes in it, you should share
| the changes with others. Is free software, not a gift for your
| business.
| dismalaf wrote:
| AGPL is cancer. Valkey already exists, people already switched,
| it's already landed in a bunch of distros. I don't see anyone
| moving back, especially when Valkey has some big corporate
| support.
|
| And for my personal usage, Rails 8 has moved Redis functionality
| into the database by default, which works fine.
| nilamo wrote:
| > Rails 8 has moved Redis functionality into the database by
| default, which works fine.
|
| Databases could always do what redis did. Redis doesn't bring
| functionality to the table, it brings speed. If database
| caching, pub/sub, and streams are good enough for your use
| case, there was never a reason to pay for an extra instance
| just to stand up redis.
| anonzzzies wrote:
| Extra instance _and_ developer overhead.
| mattl wrote:
| AGPL isn't cancer. It's a license that exists to solve a
| particular problem: the proliferation of free software in a
| world of network services.
|
| If you don't like it, don't use AGPLv3 software. Those of us
| who do like it will keep writing AGPLv3 software.
| dijit wrote:
| AGPL is cancer[0] in exactly the same way GPL is cancer, in
| that it's _intentionally designed_ to *BE* cancer (or,
| congenital at least).
|
| If you modify GPL code you are expected to open source the
| changes, AGPL adapts that to the networked world, if you modify
| AGPL code to serve something, you should open source those
| changes too, otherwise you're violating the original spirit of
| GPL which was designed in a time that was not as perpetually
| internet (and SaaS) driven as today.
|
| If you want a true free license, BSD or MIT have you covered,
| but then you shouldn't expect corporations to give back.
|
| A good example of what happens if companies _don 't_ give back
| is Linux VS the various BSD's. BSD is a lot more popular in
| appliances than you might otherwise believe but the popularity
| is starting to wane as Linux (despite GPL) has improved so much
| with companies giving back that the "free license" BSD is no
| longer being seen as good enough in some cases. People do not
| tend to give back to the BSD's.
|
| [0]: https://blog.jamesbayley.com/2014/01/17/gpl-living-with-
| canc...
| antirez wrote:
| RMS was enough of a genius to understand the potential of open
| source software, and basically gave us, with GPL and his
| evangelism (and his code! plenty of it), and the free software
| movement, the software world we are living now. AGPL reflects
| the fact that he understood before everybody else that
| something was happening with software as a service.
|
| I love the BSD license, but now who says that AGPL is a cancer
| is making a big favor to the few huge companies that want to
| abuse the original dream that spawned modern and open software.
| Times changes, the best license to use change with times.
| _msw_ wrote:
| RMS was not convinced that the Affero clause was a good idea
| as a general rule, though he approved the Affero-sponsored
| fork of the GPL that created AGPLv1. Hence, he did not
| support the addition of network copyleft obligations in GPLv3
| during its drafting.
|
| RMS has long expressed concerns about "Service as a Software
| Substitute" [1], and I think he hesitated to endorse the AGPL
| because it would conflict with his philosophy on the dangers
| of "Service as a Software Substitute".
|
| Henry Poole should be given credit for raising the concern;
| Bradley M. Kuhn and Eben Moglen should be given the credit
| for advancing the license to address the concern.
|
| It took a long time for the Free Software Foundation to
| accept Affero versions of the GPL under their stewardship
| with the release of AGPLv3.
|
| So, perhaps he _did_ understand before many people that
| services posed some challenges for his social movement. But
| it 's my belief that he favored self-reliance and maximum
| "freedom" by running computer programs on hardware you own
| yourself as the remedy, rather than extending copyleft
| obligations to reach over the network.
|
| [1] https://www.gnu.org/philosophy/who-does-that-server-
| really-s...
| rdtsc wrote:
| > AGPL is cancer.
|
| Good, you can think it is cancer and stay away from it. You
| don't like it, don't use it. It's like those bright colored
| poisonous frogs from the Amazon. That's better than some newly
| made up license that's different than anything else, and you
| have to wonder how it would hold up in practice.
| dismalaf wrote:
| I agree it's better than their previous made up license. It
| won't win back everyone who left though. The ship has sailed.
| They should have gone GPL.
| md3911027514 wrote:
| Our company made the switch over to Valkey, and we've invested
| hundreds of engineering hours into it already. I don't see us
| switching back at this point especially when it's clear Redis
| could easily pull the bait-and-switch again.
| benwilber0 wrote:
| Your company invested hundreds of engineering hours switching
| from Redis to a clean fork of Redis?
| cogman10 wrote:
| I can easily see this for a midsize company.
|
| While it's likely an easy process to drop in valkey, creating
| the new instances, migrating apps to those new instances, and
| making sure there's not some hidden regression (even though
| it's "drop in") all takes time.
|
| At a minimum, 1 or 2 hours per app optimistically.
|
| My company has hundreds of apps (hurray microservices).
| That's where "hundreds of hours" seems pretty reasonable to
| me.
|
| We don't have a lot of redis use in the company, but if we
| did it'd have taken a bit of time to switch over.
|
| Edit: Dead before I could respond but I figured it was
| worthwhile to respond.
|
| > It's literally just redis with a different name, what is
| there to test?
|
| I've seen this happen quite a bit in opensource where a "x
| just named y" also happens to include tiny changes that
| actually conflict with the way we use it. For example, maybe
| some api doesn't guarantee order but our app (in a silly
| manor) relied on the order anyways. A bug on us, for sure,
| but not something that would surface until an update of redis
| or this switch over.
|
| It can also be the case that we were relying on an older
| version of redis, the switchover to valkey necessitates that
| we now bring in the new changes to redis that we may not have
| tested.
|
| These things certainly are unlikely (which is why 1 or 2
| hours as an estimate, it'd take more if these are more common
| problems). Yet, they do and have happened to me with other
| dependency updates.
|
| At a minimum, simply making sure someone didn't fat finger
| the new valkey addresses or mess up the terraform for the
| deployment will take time to test and verify.
| JamesSwift wrote:
| My understanding is that Valkey was forked directly from
| redis. So assuming you migrate at the forks point-in-time,
| then it literally is the same code.
| terminalbraid wrote:
| Yes, but not the same infrastructure and configuration
| and documentation. Any reasonable operation will also do
| validation and assurance. That adds up if you have a
| sizable operation. "Hundreds of hours" is also not some
| enormous scale for operations that, say, have lots of
| employees, lots of data, and lots of instances.
|
| The part you are thinking of is not the time consuming
| part.
| rlpb wrote:
| > My company has hundreds of apps (hurray microservices).
| That's where "hundreds of hours" seems pretty reasonable to
| me.
|
| Sounds like a huge disadvantage in your company's choice of
| software architecture to me.
| cogman10 wrote:
| There's definitely pros and cons to this approach.
|
| The pro being that every service is an island that can be
| independently updated and managed when needs be. Scaling
| is also somewhat nicer as you only need to scale the
| services under heavy load rather than larger services.
|
| It also makes for better separation of systems. The foo
| system gets a foo database and when both are under load
| we only have to discuss increasing hardware for the foo
| system/database and not the everything database.
|
| The cons are that it's more complex and consistency is
| nearly impossible (though we are mostly consistent). It
| also means that if we need a system wide replacement of a
| service like redis, you have to visit our 100+ services
| to see who depends on it. That rarely comes up as most
| companies don't do what redis did.
| lurking_swe wrote:
| that's a loaded statement without understanding the
| company.
|
| Sometimes large companies acquire smaller companies and
| keep the lights on in the old system for a while. They
| may not even use a similar tech stack!
|
| Sometimes they want to cleanly incorporate the acquired
| systems into the existing architecture but that might
| take years of development time.
|
| Sometimes having a distributed system can be beneficial.
| Pros / cons.
|
| and sometimes it's just a big company with many people
| working in parallel, where it's hard to deploy everything
| as a single web app in a single pipeline.
| switch007 wrote:
| Indeed. Microservice zealot 'architects' love to ignore
| the work that has to into each microservice and the
| overhead of collaboration between services. They'll spend
| a couple of years pretending to work on that problem in
| any meaningful way, then move on to a different company
| to cause similar chaos
| md3911027514 wrote:
| By switch I mean that all new projects use Valkey instead of
| Redis, and we've invested hundreds of hours into those new
| projects.
| brookst wrote:
| At the very least you have to validate everything that
| touches redis, which means finding everything that touches
| redis. Internal tools and docs need to be updated.
|
| And who knows if someone adopted post-fork features?
|
| If this is a production system that supports the core
| business, hundreds of hours seems pretty reasonable. For a
| small operation that can afford to YOLO it, sure, it should
| be pretty easy.
| benwilber0 wrote:
| But why are they spending any time switching away from
| Redis at all unless they are a hosting provider offering
| Redis-as-a-service?
|
| I wasn't aware the license had any negative affect on
| private internal use.
| twoodfin wrote:
| The negative effect is that you have to bring the lawyers
| back in, and they tend to take an extremely conservative
| position on what might be litigated as offering "Redis-
| as-a-service".
| cortesoft wrote:
| Would they? My experience is the lawyers sign off when
| software is being chosen, but then they aren't consulted
| again.
|
| After that, it is just updating version numbers. Lawyers
| don't sign off on version upgrades, why would I bring
| this to them?
| ukuina wrote:
| Many legal departments cannot afford nuance when a
| newsworthy license change occurs. The kneejerk reaction
| is to switch away to mitigate any business risk.
| freeAgent wrote:
| I doubt having lawyers review your usage is more
| expensive than spending hundreds of hours of dev time to
| migrate.
| stackskipton wrote:
| Our lawyers looked at SSPL since we do host software for
| customers and it does use Redis and went "Eh, this is as
| clear as mud." so Valkey it is!
| txcwg002 wrote:
| I believe it. There are companies that invested hundreds of
| engineering hours to rename master to main.
| patates wrote:
| One would find it hard to believe how often we hardcoded
| "master" to every corner of the software that ever touches
| any VCS.
| xandrius wrote:
| That is even more ridiculous, at least switching to a clean
| fork of Redis has business reasons. Following the latest
| cultural fads, less so.
| mperham wrote:
| There are companies using many thousands of Redis instances
| storing petabytes of data with millions of users.
|
| Now consider a no-down-time migration. How long do you think
| that'll take to engineer and execute?
| dbacar wrote:
| Even the infrastructure switch and testing should take a lot
| of time, yet the application level tests etc.
| edoceo wrote:
| What? Isn't Valkey a "drop in" replacement? I switched a couple
| of deployment, it "just worked" but maybe I'm just too simple.
| tinix wrote:
| how does it take hundreds of hours to swap out a back end when
| you're using a trivial protocol like redis?
|
| did you switch out the client or something? maybe the problem
| is not using pluggable adapters? is your business logic coupled
| to the particular database client API? oof.
|
| I know the cluster clients are different (been there, done
| that) but hundreds of hours, seriously? or was that just
| hyperbole?
| md3911027514 wrote:
| By switch I mean that all new projects use Valkey instead of
| Redis, and we've invested hundreds of hours into those new
| projects. We've also tried stuff with the Valkey Glide
| client.
| tuckerman wrote:
| Hundreds could be 200 which, at 10 hours a day 5 days a week,
| is like a week and a half for a team of 3. It seems quite
| possible if you had to do testing/benchmarking, config
| changes, deploy the system, watch metrics, etc.
| Twirrim wrote:
| I think you might underestimate how little time hundreds of
| hours is. It's very, very easy to reach your first hundred
| hours in a task, e.g. taking a 40 hour week, 3 engineers =
| 120 hours.
|
| If valkey is working, why spend that time reverting to redis,
| when you could be spending it on things that are actually
| going to provide value?
| poincaredisk wrote:
| My company is relatively small. With probably 6 separate
| redis instances deployed in various places (k8s, bare metal,
| staging and prod environments) and dozens of (micro)services
| using them it's probably at least 40 hours (one person-week)
| to migrate everything at this point. Also there are things
| like documentation, legacy apps that keep working but nobody
| wants to spend time updating them, naming problems everywhere
| (renaming "redis" everywhere with zero downtime would be a
| huge pain), outdated documentation, possibly updates in CI,
| CD, and e2e tests, and probably more problems that ight
| become apparent in scale.
|
| And we're honestly not large. For a mid size company,
| hundreds hours sound reasonable. For a big company the amount
| of work must be truly staggering.
| geysersam wrote:
| Why did you not pay Redis for a licence instead? I'm genuinely
| curious. Did you feel uncomfortable being tied to a license fee
| that might increase in the future, or was it just too
| expensive?
| linotype wrote:
| No thanks, going to stick with Valkey for all future projects.
| bravetraveler wrote:
| After what Mullenweg has pulled, in the era of Blogging CEOs I
| have to be cynical.
|
| Valkey.
| kstrauser wrote:
| Heh! While I appreciate what you're saying, I see this as the
| opposite of WordPress. It's basically a CEO saying oops, we
| messed up, let's fix this, which is fundamentally different
| than doubling down and ending up in court.
| bravetraveler wrote:
| Oh, I agree... I _want_ to be wrong
| kstrauser wrote:
| I hope you are, too. Don't mistake my optimism for complete
| confidence.
| fastball wrote:
| antirez is not the CEO of Redis.
| bravetraveler wrote:
| Sorry, you're right. ICs, CTOs, and CEOs. Oh my. _Pardon me_
| for not subscribing to another accountability shell game. I
| again call Mullenweg.
|
| /s in case I haven't piled it on thick enough to make an
| impact.
|
| Read the last link of TFA [0], the last time this came up [1]
| _(noting the timespan)_ , and extrapolate as necessary.
|
| 0: https://redis.io/blog/agplv3/ _(CEO)_
|
| 1: https://redis.io/blog/redis-license-bsd-will-remain-bsd/
| _(CTO)_
|
| Or don't, I don't care. Point/fix has been made.
| fastball wrote:
| I'm not really sure what your point is. Salvatore
| Sanfilippo (aka antirez and the author of _this_ blog post)
| has never been the CTO or CEO of Redis Ltd. He didn 't
| start it and only briefly worked there (relative to how
| long it has been around as a company).
| bravetraveler wrote:
| antirez isn't the focus of my ire, stop. They simply have
| the misfortune of proximity. The _actual CTO_ told us _'
| always BSD'._ Now Salvatore is telling us it didn't
| totally expire. Great!
|
| Except... the CEO forgot. Here's a lesson about AGPL and
| the Big Bad Cloud. Give me a break or I'll take one.
|
| At risk of confusing things further: YouTube is leaking,
| is kind of my point. Apologies again for not exhaustively
| phrasing my criticism. _s /ging CEOs/gers/_; better?
|
| One last try: I'm happy for the evangelism, I'm less
| happy about the repeat license discussion. The blog _s_
| from all of the employees add a frustrating element. It
| 's a trend now spanning businesses.
|
| With what Mullenweg did, another conveniently forgetful
| CEO, I'm _(admittedly, excessively)_ cynical.
|
| How you thought I was saying antirez is the CEO is
| utterly baffling. I have a hard time thinking this is
| genuine, but rather, a troll. Entirely non-
| sequitur/failure of compound reasoning.
| bravetraveler wrote:
| ~ $ curl -s
| 'https://news.ycombinator.com/user?id=fastball'
| [...] I used to argue on the internet too
| much.<p>Co-founder and tinkerer at supernotes.app
|
| Ah, it all makes sense now. Another point of criticism.
| Or, a Supernote, if you will: s/used to//
| not_your_vase wrote:
| This will be very relevant when Valkey decides to go closed
| source.
|
| It's better than the previous state of course, but it would have
| been even better if the previous license change didn't happen.
|
| As the french people say: fool me once, shame on you...
| benatkin wrote:
| fool me can't get fooled again
|
| But in seriousness, the chances of valkey going closed source
| are low. It's run by Linux Foundation. It would be like
| suggesting that Node.js might go closed source...
| Zambyte wrote:
| They were obviously making a tongue in cheek comment instead
| of seriously suggesting Valkey may go proprietary.
| benatkin wrote:
| And it was so absurd that it didn't land with me, even
| though most of the time I notice these sorts of things. Ah
| well.
| paavohtl wrote:
| Valkey is a Linux Foundation project. Talking about license
| changes is just pure irrational FUD.
| ac130kz wrote:
| Good luck to them, everyone is moving to Valkey, especially with
| its major backing and already better performance.
| mattl wrote:
| Redis should step up and fund an independent foundation now and
| encourage Valkey to contribute where relevant.
|
| Some code under a 3 clause BSD and some under AGPLv3 could be
| interesting.
| _msw_ wrote:
| Why? They can already just copy the code they want from Valkey,
| since Valkey is 3 clause BSD...
|
| But maybe Valkey should switch to GPLv3 instead to correct this
| imbalance.
|
| https://github.com/redis/redis/pull/13638
| gray_-_wolf wrote:
| I am not sure what that would achieve? Combining programs
| under GPLv3 and AGPLv3 is possible (the resulting work is
| under AGPLv3).
| jraph wrote:
| The imbalance I think _msw_ refers to is the fact that
| Valkey couldn't both take code from a GPL-licenced Redis
| and keep its license.
|
| So either they relicense, or they can't take code from
| Redis but Redis can take code from Valkey.
| gray_-_wolf wrote:
| I see, I misunderstood that. I have read it as an attempt
| to prevent redis taking the code from valkey.
|
| However, if the intention was the other way (to allow
| valkey to take code from redis), valkey should just go
| for AGPL as well, there is little reason to pick GPL if
| the code sharing would be the motivation for the license
| change.
| _msw_ wrote:
| Disclaimer: I am not a lawyer, this is not legal advice.
|
| In theory, one would not be able to offer a combined
| program under _other_ licenses (in particular, RSALv2 and
| SSPLv1), as those licenses have conflicts with GPL
| obligations.
|
| Direct contributions to the Redis project avoid this issue
| via a separate Contributor License Agreement. It would only
| mean that Redis developers could not unilaterally copy code
| from Valkey.
|
| I'm not saying that the Valkey community _should_ do this.
| Personally, I think it 's better off as a BSD-3 licensed
| project, with the community fulfilling the promise made by
| others that it would always be that way.
| jamessinghal wrote:
| Similar move to Elasticsearch, tacking on AGPL with their
| existing source available licenses. [1]
|
| The products (commercialized open source) that are often chosen
| by and championed by developers as opposed to executives see the
| harm that a bait and switch has on their popularity. With their
| competitors being more permissive, I don't see many devs moving
| back unless Valkey loses significant feature parity.
|
| [1] https://ir.elastic.co/news/news-details/2024/Elastic-
| Announc...
| remram wrote:
| This doesn't solve anything, Redis has proved that it is willing
| to do a rug pull, and how much they are willing to hurt the
| community when they do (taking over client libraries, etc). I
| don't see a reason to go back from valkey. Again and again, Redis
| Labs has been the worst thing about Redis, I'm glad we now have
| an other option.
| kamranjon wrote:
| One of the big things I love about Redis is that it's become this
| tool for me to learn new techniques and explore data. Like, the
| new vector sets feature has let me really explore dense vectors
| and custom search and taxonomy mapping and all sorts of areas
| that seemed like a high barrier to entry for me, but now I'm just
| streaming stuff into llama.cpp with an embedding model and
| storing it in Redis and being able to do mappings between
| different data sets super efficiently.
|
| A big part of that is API design - I can't think of another
| system that is as well thought out as the Redis API - it's
| deceptively simple and because of that I didn't have to wait for
| client libraries to incorporate the new Redis features - they
| just work cause they all speak RESP and I can just send raw
| commands.
|
| All of this is to say that I was really happy to hear Antirez was
| back working on Redis and it's paying off in more ways than I
| could have imagined. People can use valkey or whatever they want
| as an alternative - but I like Redis because it's always pushing
| forward and letting me explore new things that otherwise wouldn't
| feel as "at my fingertips" as it does in Redis.
| antirez wrote:
| Thank you so much for your kind words! I tried hard, with
| Vector Sets, to follow exactly the "wave" you are referring
| here, I hope I was able to. Thanks.
| Implicated wrote:
| The Vector Sets, omg. Thank you, so much thank you :)
| wg0 wrote:
| Redis is in SQLite and Wireguard league of simplicity and
| elegance.
| boruto wrote:
| Could you please link any blog post which goes into what you
| are talking about, I feel I am also at the high barrier to
| enter situation about this stuff
| c0l0 wrote:
| I contributed a minor (but imho still neat :p) improvement to
| Redis under its original license, and personally moved to using
| redict when the unexpected license change to SSPL was announced -
| and I was feeling betrayed as a contributor to a properly-FOSS-
| codebase. (Had they switched to AGPL right away, I'd have been
| perfectly fine with that change from a moral perspective, ftr.)
|
| I have a great deal of respect for antirez and recgnize him as a
| kind and benevolent member of the FOSS community, but no matter
| what Redis, Inc. announced or does, they have lost my trust for
| good, and I will continue to use Redis forks for as long as they
| exist.
| homebrewer wrote:
| The only real reason to use non-copyleft licenses for these
| kinds of projects is to be able to do the rug pull, so you
| should have expected it instead of feeling betrayed.
|
| I imagine they will now require copyright assignment or
| something like that for external contributors to be able to
| relicense new code under a commercial license.
| echelon wrote:
| All advantage accrues to hyperscaler "managed" versions.
| That's so much more fucked than a rug pull.
|
| Amazon gets to make millions off of the thing _you_ built.
|
| "Equitable source" licenses with MAU / ARR limits,
| hyperscaler resale limits, and AGPL-like "entire stack must
| be open" clauses is the way to go. It's a "fuck you" to
| Amazon, Google, and Microsoft in particular and leaves you
| untouched.
|
| Open source today is hyperscaler serfdom. Very few orgs are
| running Redis on bare metal, and a equitable source license
| can be made to always support the bare metal case.
| tough wrote:
| It's sad as an open source lover how money fucks it all
| echelon wrote:
| If you open source something, the rich trillion dollar
| companies just steal it.
|
| If you're okay with that, that's cool. But they'll profit
| off of your work and labor. And the worst part is that at
| scale, the advantages of the sum total of open source is
| used to compete with you and put price pressure on your
| salary and career options. To rephrase that, the
| hyperscalers are in a position to leverage open source to
| take advantage of market opportunities you cannot, and
| they can use that to compete with your business or
| competing businesses that might otherwise pay you better.
|
| Open source needs anti-Google/Amazon/Microsoft clauses.
| tough wrote:
| doesn't the Affero GPL v3 cover this? have seen some
| projects use it, I think it limits the server run parts
| of the software etc
| echelon wrote:
| Yes, it does! The "problem" with AGPL3 is that it has no
| carve-out for companies smaller than Amazon, Microsoft,
| or Google. If you use AGPL, you have to open source your
| entire stack.
|
| Not everyone thinks infectious copyleft / free software
| is a problem. But it will mean that if you use AGPL3,
| every part of your stack has to be open. That doesn't
| work for everyone.
|
| This is why "equitable source" / "fair source" is gaining
| traction. You can use a license like Apache and add in
| clauses with MAU/ARR/Hyperscaler limits that allows
| practically everyone else to use your software.
| papashell wrote:
| AGPL doesn't require you to open source the entire stack.
| Only the changes you made to the AGPL software if you
| interact with over a network
|
| AGPL does not and has not prevented hyperscalers from
| creating managed services for software licensed with it
|
| That's why mongo created the server side public license,
| which does require open sourcing the entire stack.
| MongoDB was AGPL before that
| tough wrote:
| thank you for this tidbit i had no idea and am now more
| educated on FOSS licensing
| kmeisthax wrote:
| No, SSPL requires you to open source your entire stack.
| That's why the OSI and FSF rejected it.
|
| AGPLv3 says, if you modify the software and put it on a
| network, you have to provide a link for anyone accessing
| the software to download the modified source. There's
| numerous drafting and technical problems with this
| arrangement[0] but the only parts of your stack you have
| to release are the parts that are actually part of the
| program covered by AGPLv3.
|
| The "strong copyleft" strategy[1] is to identify a
| specific freedom-restricting behavior we don't like and
| prohibit just that. We're not saying "Amazon is not
| allowed to use this software", we're saying "Anyone who
| turns this software into a service needs to provide a way
| to fork the service and get the software back without
| losing anything". If such a copyleft license happens to
| scare a company into buying license exceptions, that's a
| happy accident.
|
| In contrast equitable source doesn't say anything about
| freedom, it just says "these people need to pay a license
| fee". That's not FOSS, that's shareware. In FOSS, free-
| riding _is not a bug_. The problem with AWS isn 't that
| they aren't paying a license fee, it's that they are
| building roach motels out of community projects.
|
| [0] I'd link to Hector Martin's _incredibly_ informative
| Mastodon posts regarding the subject, but he deleted his
| account after crashing out of LKML. As a substitute for
| that, I 'll summarize my hazy memories:
|
| - The intended compliance mechanism is to make your app a
| quine; but that only makes sense for webapps written in
| PHP/Python/etc. Someone actually put AGPLv3 on an
| Ethernet stack - how do you comply with that?
|
| - It's unclear how license compliance works in a pull
| request driven Git workflow. If you're running the server
| locally for testing, and someone accesses it, have you
| violated the license?
|
| - You can filter out the source offer with an HTTP proxy
| not covered by AGPLv3. That seems like a very wide
| loophole which the FSF apparently believes would work.
|
| [1] e.g. AGPL, SSPL, OpenWatcom, etc
| prmoustache wrote:
| They aren't stealing anything, they use the rights they
| are granted by the developers of the project.
| theamk wrote:
| Open source with anti-Google/Amazon/Microsoft clauses is
| called AGPL.
|
| And yet somehow people keep making new projects under MIT
| license.
| pcthrowaway wrote:
| You do realize the owners of the copyright can relicense it
| under any terms they want, even if it's a copyleft license
| like GPL, right?
| arghwhat wrote:
| Unless a CLA transfers copyright to the project owner, the
| copyright owners are every historical contributor to the
| project. Each contribution is owned by the contributor
| alone and they alone are able to grant rights to it.
|
| A CLA often tries to mitigate this by making contributors
| give the project owners special rights at the time of
| contribution.
|
| (Note that even if relicensed, this itself can never revoke
| licenses granted for prior versions unless that license
| specifically had revocation written into it.)
| pcthrowaway wrote:
| Yes, a project can only be relicensed if a CLA assigning
| _licensing rights_ (not ownership) is signed by all
| contributors, or if all code is owned by the entity
| relicensing it. Whether it 's under a copyleft license, a
| permissive license, or even a proprietary license is
| irrelevant.
| dharmab wrote:
| There are good legal reasons to avoid the GPL; there are open
| legal questions about whether the GPL and its variants are
| enforceable.
| fsckboy wrote:
| your comment is logically defective
|
| if that's your "good legal reason" to avoid the GPL, then
| it's just as much a "good legal reason" not to open source
| your work at all: if the GPL is not enforceable, that would
| mean you have used a non-copyleft license, which according
| to you is the thing you want to avoid for good legal
| reasons.
| dharmab wrote:
| I didn't say you should avoid non-copyleft licenses?
| Indeed, all of my own OSS projects are non-copyleft.
| fsckboy wrote:
| loosely speaking:
|
| you said "avoid gpl". reason? "unenforceable".
| eliminating gpl from consideration, thus you advocate
| non-copyleft licenses instead.
|
| with me so far?
|
| but gpl's "unenforceability" could only mean it turns
| into a non-copyleft license, _one which you say one
| should not use_ , so if one shouldn't use gpl because in
| reality it is a non-copyleft license, then you must be
| against non-copyleft licenses.
|
| just to state it again for clarity: _" don't use gpl
| because copyleft is unenforceable so gpl is just MIT
| underneath, and I repeat, don't use it"_ is a
| recommendation not to use MIT license.
| dharmab wrote:
| Please link to where I said not to use copyleft licenses.
| Check the usernames carefully.
|
| Note that I don't agree that GPL and MIT are equivalent,
| or that GPL becomes a non-copyleft open source license if
| not enforceable. IANAL but it might revert to the regular
| copyright law for wherever you publish software, not an
| open source license.
| throwaway2037 wrote:
| > there are open legal questions about whether the GPL and
| its variants are enforceable.
|
| At this point in history, there are multiple legal cases
| where GPL violators were taken to court and lost or
| settled. See: BusyBox and Linksys/OpenWrt.
|
| GPL v3 also has a nice clause that allows companies to
| "repair/cure" their non-compliance. >
| Moreover, your license from a particular copyright holder
| is reinstated permanently if the copyright holder notifies
| you of the violation by some reasonable means, this is the
| first time you have received notice of violation of this
| License (for any work) from that copyright holder, and you
| cure the violation prior to 30 days after your receipt of
| the notice.
|
| Red Hat also has a good blog post about their view of using
| the legal system to enforce compliance:
| https://www.redhat.com/ja/about/gplv3-enforcement-statement
| KZerda wrote:
| A copyleft license like the AGPL didn't stop MongoDB from
| rugpulling. I'd argue that the AGPL, and the copyright
| assignment that tends to go with it, makes it easier to
| rugpull because forking entities would be at an extreme
| disadvantage in keeping the lights on compared to the closed-
| sourcing company. A non-copyleft license, on the other hand,
| makes it much easier for a forking company to cover all the
| same niches as the original company, making a rugpull that
| much more difficult.
| NewsaHackO wrote:
| ? How did MongoDB rug pull?
| kmeisthax wrote:
| MongoDB used to be AGPLv3. A year after their IPO they
| realized "aww shit, Wall Street wants continuous growth,
| being profitable isn't enough" and decided to migrate to
| a completely new license, SSPL, that's designed to put
| everything surrounding the software in scope of the
| copyleft. The implication being that if Amazon were to
| offer MongoDB they'd also have to release _all of AWS
| RDS[0]_ as a thing you could just download and use.
|
| The community did not like this one bit, but MongoDB
| doesn't need to care about what the community thinks
| because they had CLA'd all their contributors. That is,
| if you wanted something in MongoDB upstream, you had to
| give MongoDB full copyright ownership over the software.
| Which exempts them from copyleft[1]. One of the critical
| parts of copyleft is the "no further restrictions" rule;
| otherwise copyleft is just proprietary with extra steps.
|
| [0] I don't remember if they were hosting MongoDB as part
| of RDS or something else.
|
| [1] As we've seen with the Neo4J lawsuit, copyright
| licenses cannot tie the hands of the copyright owner. The
| only way for copyleft to work is to create a Mexican
| standoff of contributors who will sue each other to death
| if any one of them decides to relicense without unanimous
| community consensus.
| _msw_ wrote:
| AWS never offered the AGPLv3 licensed version of the
| MongoDB server as part of any managed service. There were
| large cloud providers in China that _did_ offer MongoDB
| as a service. They also provided the corresponding source
| code [1]. Despite signs that they were complying with the
| obligations of the license, they had the SSPL drafted
| anyway.
|
| Because once it was clear that software as a service was
| a compelling model, it was no longer appealing to give
| everyone the permissions needed to offer the software as
| part of a service (as AGPLv3 was always designed to do).
|
| Changing the license seemingly worked, as a partnership
| was eventually announced [2].
|
| [1] https://github.com/Tencent/CMONGO
|
| [2] https://www.mongodb.com/company/newsroom/press-
| releases/tenc...
| umanwizard wrote:
| > The only real reason to use non-copyleft licenses for these
| kinds of projects is to be able to do the rug pull
|
| That's an exaggeration. The vast majority of permissively
| licensed projects have never "rug pulled" and never will. It
| might be one possible reason to choose such a license but
| it's very far from the only one.
| giancarlostoro wrote:
| Microsoft made one called Garnet, I wouldn't say its a fork
| though, its basically compatible with Redis and implemented
| mostly in C#. It supports the RESP wire protocol from Redis for
| ease of compatibility.
|
| https://github.com/microsoft/garnet
| cess11 wrote:
| You do see how that's even worse, right?
| jayofdoom wrote:
| I don't see how it's worse?
|
| https://github.com/microsoft/garnet/blob/main/LICENSE
|
| It's MIT licensed?
| Alupis wrote:
| Microsoft has a habit of "fake" open source. Particularly
| on Github.
|
| By "fake", I mean Microsoft largely treats their Open
| Source codebases like they are closed-source, in-house
| proprietary codebases that they happen to let members of
| the public look at.
|
| They'll accept a PR once in a while, but mostly it
| appears Issues and PR's are used as a free alternative to
| UserVoice.
|
| Every decision is made behind closed doors (probably a MS
| Teams call actually), and you'll notice how top-heavy
| their staff is on these projects (half a dozen employees
| with "Manager" in their title on any given repo).
|
| Beggars can't be choosers, and I'm glad they are dipping
| their toes into the FOSS water... but I don't really get
| FOSS vibes from their projects on Github.
| neonsunset wrote:
| Garnet has a discord server and has been actively
| accepting community PRs, so I don't know what kind of
| nonsense you are on about.
|
| What is it with .NET that compels you to lie?
|
| Also FOSS and open contribution are different things, as
| sibling comment notes.
| cess11 wrote:
| MIT license is not FOSS, it's OSS at best.
| neonsunset wrote:
| MIT is one of the least restrictive licenses.
|
| If you think otherwise, I suggest checking if there's any
| aluminium foil on your head.
| Nab443 wrote:
| As a end user, I find it quite restrictive. There might
| be some software I won't be able to fork/modify because
| they were MIT. I'm not the owner of the software anymore.
| neonsunset wrote:
| "The MIT License (MIT) Copyright (c) 2025 <copyright
| holders>
|
| Permission is hereby granted, free of charge, to any
| person obtaining a copy of this software and associated
| documentation files (the "Software"), to deal in the
| Software without restriction, including without
| limitation the rights to use, copy, modify, merge,
| publish, distribute, sublicense, and/or sell copies of
| the Software, and to permit persons..."
|
| https://mit-license.org
| pabs3 wrote:
| The MIT license always allows you to fork/modify the
| project. You wouldn't be the copyright owner of the
| existing code in your fork, but you could be the owner of
| the project, and the copyright owner of any new code you
| add.
| cess11 wrote:
| Free software is licensed in a way that protects your
| freedom. MIT license does not.
|
| Are you actually unaware of this? If so, why? Is it age
| or have you been sheltered somehow?
| throwaway66112 wrote:
| Free software is software that you are free to use or
| modify however you want.
| cess11 wrote:
| That's too vague. Free software is software you can't
| take and then modify and keep your modifications hidden
| or proprietary, thus depriving your users and the
| community of access to these changes.
|
| MIT license allows this, hence it's not a free software
| license. Because very large corporations don't like
| freedom they've poisoned the discourse around software
| freedom and launched PR campaigns trying to substitute
| talk about freedom with talk about openness or open
| source. To some extent they've succeeded, as evidenced by
| the chatter about it in this thread.
| KolmogorovComp wrote:
| You're confusing open source and open to contribution. Is
| SQLite not open-source?
| tough wrote:
| Does SQLite try to embrace, extend, and extinguish their
| competitors?
| atonse wrote:
| Embrace, Extend, Extinguish is from an era where Open
| Source wasn't the default for infrastructure.
|
| I don't know how you can extinguish something that's MIT
| licensed and has a million copies around the world.
| tough wrote:
| I've read at least several stories from this era like
| AppGet's https://medium.com/@keivan/the-day-appget-
| died-e9a5c96c8b22
|
| I wouldn't trust Microsoft near my open source code base
| in 3 centuries
|
| They can extinguish it by just stealing all the code, and
| using their bigger marketplace advantage to become the
| defacto standard.
| Alupis wrote:
| I'm fairly impressed Microsoft managed _not_ to name
| their Redis competitor "Cache", just to pollute the
| keyspace like they do with so many of their other
| products.
| tough wrote:
| LMAO they're so evil its even mildly funny
| joshstrange wrote:
| I guess it will depend on your definition of "extinguish"
| and a few other things but:
|
| _gestures wildly at the MIT-licenced VSCode codebase_
|
| Yes, they are not rug pulling the VSCode source but by
| locking down the marketplace (and never giving a truly
| open source VSCode, what developers think of as "VSCode")
| they are in the processes of locking out forks.
| atonse wrote:
| Ah so this is like how Android being open source was
| (almost) always bullshit. You had to play all kinds of
| google dances to get the google apps on them.
|
| Fair point! good example of an attempt to extinguish.
| joshstrange wrote:
| I couldn't agree more with the Android comparison, I made
| the same comparison to VSCode a few days ago:
| https://news.ycombinator.com/item?id=43787009
| sophacles wrote:
| Does Microsoft do this in 2025?
|
| Like seriously - I haven't heard of them doing it in
| quite a long time. I know they were atrocious in the 90s
| and 00s, I'm not disputing that at all. Are there any
| examples of them continuing this behavior in the last
| decade though?
|
| Further, a huge percentage of the people making those
| decisions back then are no longer with the company,
| different people are in charge, etc. The industry has
| changed it's relationship with open source - company
| board rooms aren't scared of the consequences of loading
| open source onto a server, the legality and liabilities
| have been hashed out, and MS isn't really even capable of
| pulling those fear levers anymore. MS itself has
| repositioned in the industry - their dreams of total
| computing dominance have been shattered: there's no
| chance of a windows derivative owning the server market
| any more, there's no money in browsers or consumer OSes
| (heck even MS's domination in gaming is showing cracks
| due the the efforts of valve). Point being - would it
| even make strategic sense for them to try to EEE anything
| anymore?
|
| Note: I have almost no ties to MS. I haven't used an MS
| os or desktop software since before covid (in any
| capacity, even moving the mouse on a computer running
| windows). I don't use any of their SaaS products
| personally or professionally. There are integrations
| between the products I help build and azure, however
| those are not a major source of revenue for my employer
| and I do very little work that even touches that stuff.
| Point being - I'm pretty non-MS in my life and don't have
| any sort of loyalty or incentive to defend them. I do
| abhor their EEE actions back in the 90s and 00s when they
| were doing them, and those still make me angry... but
| that's not a reason to assume that different people at a
| company are going to act the same as the old-school ones.
| luchsio wrote:
| Just read this a few days ago, so maybe the behaviour is
| better than it was, but still. Here is the link:
| https://news.ycombinator.com/item?id=43750535
| Alupis wrote:
| Perhaps... when I look at an Open Source codebase, I
| expect there to not just be source you can read, but also
| a way to contribute and engage with the codebase
| creators, beyond just bug reporting (aka. Github Issues).
|
| While it may technically be open source due to it's
| license and you can literally go look at the source -
| Microsoft is operating these codebases as-if they are
| proprietary. Every decision is made out of public - and I
| would not be surprised to learn they have their own
| internal tracker for the "real" backlog items. You
| frequently see command/comments by Microsoft employees
| which clearly are triggering workflows in their real
| backlog tracker, and near-zero discussion happens in
| Github by Microsoft employees, and when it does - it's
| clearly through a PR filter.
|
| Like I said, beggars can't be choosers and it's better to
| have this than nothing - but I don't really think
| Microsoft has grasped the true concept of FOSS as-of yet.
|
| > Is SQLite not open-source?
|
| Not really in my opinion either. There's no way to
| contribute at all... best you can do it raise hell on the
| forums about a particular issue you want to see fixed. So
| while it's Open Source in the strict sense, it's not Open
| Source in the general sense.
| burnished wrote:
| I think most projects are genuinely like this though,
| even ones that accept outside contributions more
| earnestly. I understand why you'd associate open to
| contributions with open source but I think its a mistake
| to treat the relationship as required rather than common.
|
| The sibling comments contain some sharper critique of
| Microsoft if you haven't read them yet.
| seba_dos1 wrote:
| Whether a project is developed by a community or by a
| single entity holding all keys is completely orthogonal
| to being Open Source/Free Software. There's nothing wrong
| in putting one kind of projects above the other, but you
| may want to revise "your opinion" if you want to stay
| communicative, because terms and definitions are only
| useful when people agree on what they mean.
| MaxBarraclough wrote:
| The terminology for this is the _cathedral_ model and the
| _bazaar_ model. Under the former model, code is released
| from 'on high'. Under the latter, it's developed in the
| open and with cooperation with the community. Both count
| as Free and Open Source software though, provided of
| course that a FOSS licence is used.
|
| https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaa
| r
| throwaway2037 wrote:
| > best you can do it raise hell on the forums about a
| particular issue you want to see fixed
|
| With regards to SQLite, do you have a specific issue in
| mind?
|
| Also, do you have any open source projects that you
| wrote, maintain, and accept contributions?
| munchler wrote:
| How is that "fake"? There's no requirement that an open
| source project take contributions from outsiders at all.
| justin66 wrote:
| This notion that open source projects aren't _really_
| open source unless they welcome all contributions is one
| of the dumber ideas in the world.
| glenngillen wrote:
| Having worked a few places that have major open source
| projects, it was eye opening to see how pervasive this
| seems to have become. It feels like over my lifetime I've
| watched the value/expectations/demands/definition of OSS
| shift from "source is available, and I can make changes
| to my own copy/fork of of it if required" to "source is
| available, and I will demand you make changes to it for
| me"
| Alupis wrote:
| > source is available, and I will demand you make changes
| to it for me
|
| There seems to be a disconnect here. I agree, demanding
| someone else make changes for you is in poor taste. The
| issue is, some of these projects advertise themselves as
| being open source while having no meaningful way to
| contribute changes back upstream - ie. the spirit of open
| source.
|
| If I use your program for free, and encounter a bug, I
| should be able to fix it and contribute that back
| upstream so everyone benefits. That's my way of "paying
| back" and helping the community. Projects that reject
| contributions, or make contributing difficult are not in
| the spirit of open source, even if they are technically
| open source via their license.
|
| That's what I call "fake" open source - you want the
| positive image of being Open Source only.
| toast0 wrote:
| > There seems to be a disconnect here. I agree, demanding
| someone else make changes for you is in poor taste. The
| issue is, some of these projects advertise themselves as
| being open source while having no meaningful way to
| contribute changes back upstream - ie. the spirit of open
| source.
|
| I mean, you're not demanding someone else make the
| changes. You're _only_ demanding that they engage and
| build a community around their project and all that
| entails.
|
| As long as the license is reasonable, anybody else could
| pick up the project and do the community building around
| it. Apache HTTP Server developed around community patches
| to NCSA httpd. I don't think hitch (from the people who
| brought you Varnish) is well know, but it started as stud
| with community patches. If something like this takes off,
| the originator will either start taking the community
| patches too, or not; it's their choice.
|
| In the meantime, as a user, I get the benefit of whatever
| changes the origin provides and I can patch it as I want,
| and fix up problems that I see. That works for code dump
| open source and community open source,.
| hn_acc1 wrote:
| You are free to fork their code, add your fix, open a
| bug-tracking system, start a forum, guarantee response
| times, etc to "help the community".
|
| Not everyone has time for a second or third full-time
| job.
| glenngillen wrote:
| heh, related:
| https://x.com/mitchellh/status/1918055154991202470
| dharmab wrote:
| I make an open source, MIT licensed piece of software. I
| don't accept unsolicited contributions, but I document
| that people are free to fork the code and provide
| instructions on how to develop, test and build on your
| machine.
|
| Am I "fake open source"?
| Alupis wrote:
| In my opinion, the spirit of open source goes beyond just
| tossing code over a wall for people to look at. In my
| opinion, it means accepting engagement from your users,
| their inputs and their contributions when/where
| warranted.
|
| In my opinion, for something to be truly open source, I
| should be able to fix a bug I ran into, or implement a
| feature from the backlog and contribute it back upstream.
| If upstream is just going to ignore my contribution,
| pretend it doesn't exist, or reject it just because -
| then that codebase is just pretending to be open source.
|
| That's not to say you are required to accept all
| contributions - I'm saying you should be open to
| contributions that A) save you time B) enhance the
| codebase or C) fix confirmed bugs.
|
| In Microsoft's case - I don't see a lot of that going on.
| I see lots of Issues (bug reports), some PR's, but mostly
| opaque decision making, and complete silence on things
| the Corporate side of Microsoft doesn't want to comment
| on yet. Which is the beef - it's a corporate project run
| like it's proprietary but you can go look at the code.
| Again, better than nothing, but it's not really what I
| consider true open source.
| neongreen wrote:
| I have the same feeling. I got used to infrastructure
| being run as a democracy, not merely "source available
| under GPL/BSD/MIT". (It's a big thing to want, sure, but
| I don't mind wanting big things.)
| krab wrote:
| Wow, that's stretching it a bit, isn't it?
|
| I'd say the spirit of open source is that others are free
| to modify the code and that's it. This requires a good
| license, the possibility to fork, some documentation and
| a way to build the project yourself.
|
| But why would accepting contributions be required?
| NewsaHackO wrote:
| A lot of people are _very_ entitled. They think that an
| open-source project gives the right to make request
| /demand of the project. Even if they are willing to write
| the contribution themselves, they still think they have
| the right to have their pull request accepted. They
| forget that 1) it may be outside the scope of the
| project, and 2) the project owners are going to be the
| ones that have to actually maintain the code they commit.
| Crazy stuff.
| throwaway2037 wrote:
| I am 100% in agreement with your sentiment.
|
| This blog post is legendary (in my mind): "Open Source
| Maintainers Owe You Nothing" ->
| https://mikemcquaid.com/open-source-maintainers-owe-you-
| noth...
|
| It perfectly sums up how this conversation is going.
| thewebguyd wrote:
| > In my opinion, the spirit of open source goes beyond
| just tossing code over a wall for people to look at. In
| my opinion, it means accepting engagement from your
| users, their inputs and their contributions when/where
| warranted.
|
| I disagree. There's nothing about open source or the
| various open source licenses that require accepting
| engagement from the community and/or contributions.
|
| Open source means allowing modifications, and sharing
| those modifications. It's in most licenses that the
| software is provided as is and without warranty.
|
| > In my opinion, for something to be truly open source, I
| should be able to fix a bug I ran into, or implement a
| feature from the backlog and contribute it back upstream.
| If upstream is just going to ignore my contribution,
| pretend it doesn't exist, or reject it just because -
| then that codebase is just pretending to be open source.
|
| A project not accepting outside contributions is still
| open source, not pretending to be, and the beauty of it
| is - if you want it to accept outside contributions, you
| are able to fork it and accept contributions on your own
| fork, or otherwise share your modifications. But there's
| absolutely no obligation of the original dev/owner to
| accept or engage with anything from the community. It's
| in the license, the software is provided as is and
| without warranty of any kind.
|
| Maybe it's worthwhile to coin a new term, community
| software, to specifically make a distinction between
| projects that are community developed (accept
| contributions) vs those that don't.
| hn_acc1 wrote:
| What if you want implement a feature, but they don't have
| time to look at it and make sure it's secure, or support
| future bugs? Look at the xz (IIRC) hack - not everyone
| has tons of free time.
|
| How long after they release their code are the required
| to keep this up? Do they need to respond to your requests
| within 5 business days?
|
| If they retire / move on to another project, does the
| source code stop being open source?
| thewebguyd wrote:
| IMO, no. The open source definition says nothing about
| requiring outside contributions, and IMO the spirit of it
| in the beginning was never about that.
|
| It was about being able to have access to, fork/modify,
| and redistribute the software. That's the important thing
| - that the software I use can be modified by me, and if I
| wish to do so, the license allows me to then redistribute
| those changes vs. proprietary software, which cannot be
| modified nor redistributed.
|
| I'm not sure why the zeitgeist went from the above and
| turned into "all open source must be community software
| and engage with users and accept contributions" because
| that was never what it was about. It was a benefit of
| some projects, sure, but at the end of the day the
| important thing isn't whether or not the project accepts
| contributions but whether I have the power and license to
| modify something to my liking, fork it if I wash, and/or
| redistribute my changes.
| cess11 wrote:
| No, but you've deliberately chosen to not make it free
| software.
| bigstrat2003 wrote:
| Open source does not mean you accept contributions from
| others. It means that the source code is available, and
| that people are free to take it and modify it themselves.
| You are using a definition which is... not exactly
| incorrect, because definitions are what they are, but
| certainly not what everyone else uses.
| ipaddr wrote:
| What stops them from doing the exact same thing
| KomoD wrote:
| I don't, would you like to explain?
| cess11 wrote:
| It's controlled by an even larger and much, much nastier
| corporation.
| avinassh wrote:
| Garnet fascinates me. Their benchmarks even claim that it is
| better than Redis and also Dragonfly. Are there any papers or
| write ups explaining what makes Garnet fast? (I do know its
| based on FASTER)
| reconditerose wrote:
| The tl;dr is it's just a lockless hashmap attached to a TCP
| server with a log. Simple Get/Set operations are highly
| optimized, so with high batching they are able to
| efficiently fetch a lot of data efficiently. The
| architectures scales _very_ well when you add threads and
| data access that is uniform.
|
| It struggles a bit on certain types of workloads like hot
| keys, think heavy hitting a single sorted set. It's a cool
| architecture.
| arghwhat wrote:
| That's... Pretty much exactly what you'd expect from a KV
| store. It's a hashmap on the network.
| whizzter wrote:
| The difference is that Redis is single-threaded, the
| value proposition of Redis was/is a fast (in-memory)
| simple (single-threaded) server to serve things so much
| faster than a traditional DB. It was a perfect fit and
| became popular with the Ruby/Rails community,etc since
| those environments combined with traditional SQL servers
| are slogs compared to what a fast server like Redis could
| do.
|
| As good as Redis is, modern computers with multiple cores
| potentially leaves a lot of performance on the table.
| Garnet seems to be a well designed multithread KV-store
| (though sadly the benchmark page doesn't list benchmark
| for more complex objects even if the simple cases looks
| good).
| neonsunset wrote:
| There's more to it than just having a fast hashmap:
| https://www.microsoft.com/en-us/research/wp-
| content/uploads/...
|
| (I'd imagine implementing mechanisms for resilient
| storage and larger than memory data sizes would be the
| hard parts)
| neonsunset wrote:
| Yup, it's a complete reimplementation in pure C#. It's built
| on top of FASTER KV / Tsavorite project from MSR.
| gschizas wrote:
| Nice. I've been using Memurai (https://www.memurai.com/) for
| development on Windows (native, no WSL or Docker - for
| reasons), but this looks much better.
|
| EDIT: Weird that being a program from Microsoft (well, it's
| Microsoft Research, so that probably explains it?) it has no
| installer and doesn't run as a service on its own.
| yyyk wrote:
| The readytorun zip includes a service exe, it does need 'sc
| create binpath= ' etc. to be ran as a service.
| ahartmetz wrote:
| Conventional wisdom from 10 years ago on HN is that
| Microsoft Research just pays some top researchers (with
| commercially interesting, err, interests) to keep doing
| their thing. I wouldn't distrust anyone from there based on
| their employer. That is from someone who doesn't trust MSFT
| very far.
| gschizas wrote:
| Oh, don't get me wrong, I don't distrust them, it's just
| that some projects that come out of Microsoft Research
| are more rough around the edges!
| rs999gti wrote:
| Wow. First time hearing about Garnet. MS should package and
| deploy it as a service in the Azure SAAS offerings.
| weinzierl wrote:
| I think we need to get back to state where we take software
| licenses serious in letter and in spirit. The transitions Redis
| made are pristine on a legal and moral level. Feeling betrayed
| is absolutely uncalled for.
| yjftsjthsd-h wrote:
| > The transitions Redis made are pristine on a legal
|
| Yes, of course.
|
| > and moral level. Feeling betrayed is absolutely uncalled
| for.
|
| Er, no, that's an unsubstantiated leap.
| bornfreddy wrote:
| Not sure why Redis is blamed for the "rug pull". They
| didn't relicense the old versions. They just said "sorry
| guys, we don't want to support this project under those
| terms anymore". They are under no obligation to do that,
| legal or moral. Don't like it? No problem, fork it and
| maintain it yourself (as many did). But don't demand of
| others to continue to support the project under those terms
| if they do not want to. This is FOSS working as intended.
|
| All those people that contributed, did so to the FOSS
| version. Their contributions live on in all the forks, both
| FOSS and proprietary (by Amazon & co., and Redis before
| today). So not sure where "betrayal" supposedly happened.
| Maybe when Amazon used their contributions too?
| md3911027514 wrote:
| I mean isn't lying bad? They literally made public statements
| saying they "will always remain BSD."
| https://redis.io/blog/redis-license-bsd-will-remain-bsd/
| tough wrote:
| People and companies are allowed to change opinions, why
| would anyone blame Redis or Elastic instead of Amazon for
| taking it all?
| echoangle wrote:
| Because Redis said they would never do something and then
| changed their mind (which makes the whole concept of
| saying you will never do something useless), while Amazon
| never said they wouldn't use open source software for
| free (which is their right).
| orthecreedence wrote:
| You're not arguing for the honesty of individual
| companies, you're arguing against the profit mechanism.
| tough wrote:
| I'd still trust more antirez than amazon as entities.
|
| Never trust a company.
| echoangle wrote:
| What does trusting antirez help me if he's working for
| another company?
| weinzierl wrote:
| They already had made a strong statement by choosing BSD
| when GPL was at their disposal. That is a much stronger
| statement than some blog post that reflects a momentary
| snapshot of their plans.
|
| It is just that people don't hear what they don't want to
| hear. Every BSD or MIT is a loud and clear statement to
| deny the guarantee that derivative works will remain free
| and open.
| antirez wrote:
| Anyway: thanks for having contributed to Redis :)
| revskill wrote:
| Not quite. Company can easily change license at any time. No
| string attached.
| osigurdson wrote:
| I believe AGPL + time + contributors makes that very
| difficult. It also means that if you have a commercial
| product that uses Redis you need to open source your stuff
| though, so not net better imu. Please correct me if I am
| wrong.
| gkbrk wrote:
| Nope, looks like they still require a CLA for code
| contributions, which means they can release it under
| whatever license they want.
|
| https://github.com/redis/redis/blob/unstable/CONTRIBUTING
| .md
| osigurdson wrote:
| Hmmm. Yes, agree.
| eikenberry wrote:
| It all depends on if they have a CLA or not. Have CLA ==
| continued easy rug pull, No CLA == rug pull gets harder
| over time.
| cdelsolar wrote:
| No, it doesn't mean you need to open source your
| commercial product if it uses Redis. AGPLV3 doesn't work
| like that. You need to open source your changes to Redis
| if you make any, and if your product is distributed
| through a network.
| palata wrote:
| > You need to open source your changes to Redis
|
| I am pretty sure that AGPL makes you distribute your
| changes to your users, not to Redis.
| noshitsherlock wrote:
| Good decision, I hope the best for Redis!
| elAhmo wrote:
| Likewise. Respect for antirez and all of that he is doing, but
| his hiring back feels like just trying to lure developers back
| after ridiculous move by the Redis corporation.
|
| Given there are viable alternatives out there, I see no reason
| why someone should invest any time in Redis (we are using
| Valkey as a replacement).
| antirez wrote:
| Nothing wrong in checking other alternatives, but Redis the
| company didn't call me to rejoin. I approached them to do
| something like an evangelist and bring back some kind of
| community vision inside. Then... if you can code, you end
| coding often times, and instead of doing the evangelist I
| wrote the Vector Set data type :D Just to clarify that me
| rejoining was not some kind of "winning back the community
| plan". I wrote at large about all that, even clearly stating
| that even the paycheck is modest (to avoid that kind of
| conflict of interest of the economical motivation).
| fastball wrote:
| I use Redis in basically every project, and this "ridiculous"
| move had literally zero impact on my usage of Redis, so maybe
| that is a bit hyperbolic.
|
| SSPL is not as bad as the OSS community pretends it is
| (unless you're a hyperscaler).
| lolinder wrote:
| Yeah, we just did this whole ride with Elastic [0]: company
| changes the license out from under the community, community
| revolts, company gives up and changes it back. Both companies
| even pulled the same "it worked" excuse ("while it was painful,
| it worked", "this achieved our goal").
|
| Neither company has built in a legal safety mechanism to
| prevent themselves from pulling the rug again later and both
| companies have shown themselves to be untrustworthy stewards.
| They came groveling back when it turned out that community
| goodwill really did matter after all, but this is definitely a
| "fool me twice, shame on me" situation.
|
| [0] https://news.ycombinator.com/item?id=41394797
| citizenpaul wrote:
| This seems to be accelerating. I guess the era of lighting
| investment money on fire and pretending that the flames equal
| success is coming to an end.
|
| Unless of course you are an AI startup.
| jaapz wrote:
| Interestingly their CEO states that AWS an Google forking
| redis and maintaining it separately was their "goal" all
| along. Because fragmentation is apparently good?
| badlucklottery wrote:
| > Because fragmentation is apparently good?
|
| I think it's more "they are no longer piggybacking off our
| work for free".
|
| I also think what they _actually_ wanted was that plus
| "...and they paid us".
| tedivm wrote:
| The reason the ValKey fork happened so fast is that AWS
| was already sponsoring developers for the open source
| redis project.
| SweetLlamaMyth wrote:
| And not merely "some developers", but a member of the
| Redis Core Team: https://redis.io/blog/redis-core-team-
| update/
| lolinder wrote:
| Yeah, the whole "they give nothing back" line might be
| the worst part of the PR around these changes. It's
| obvious to anyone familiar with the ecosystem that it's
| not true, which damages the credibility of Redis's
| argument in the eyes of the people who matter most.
| echelon wrote:
| This keeps happening:
|
| 1. People put a lot of work into building databases. The
| license choice is OSS / FOSS.
|
| 2. Some people in the community (original authors, community
| leads) make a company around the database and continue
| developing it for years on end. They sometimes raise venture
| capital to expand the business.
|
| 3. Amazon / Google / Microsoft offer managed versions of the
| database and make bank on it. Easily millions in revenue.
| Original creator / company doesn't get anything, and the
| hyperscaler isn't obliged to pay.
|
| 4. The company decides to change the license to force Amazon
| / Google / Microsoft to pitch in and pay a fee.
|
| 5. Amazon / Google / Microsoft fork the database. The
| community revolts. Sometimes the people revolting are
| employees of the hyperscalers, other times these are just
| FOSS fans that hate "source available" licenses or
| relicensing.
|
| 6. Database company is forced to walk back the changes. Still
| no revenue.
|
| ---
|
| The solution is clear: start your new database with an
| "equitable source / source available" license from day one.
| Nobody will complain about a relicense since your license
| will handle the hyperscalers right off the bat.
|
| Basically your license needs one of a few things if you want
| to prevent Amazon from walking off with your money:
|
| - A hyperscaler clause such that any managed offering has to
| (1) be fully open source, (2) has to pay a fee, or (3) is
| prevented outright.
|
| - A MAU / ARR clause such that hyperscalers are in the blast
| radius. Note that this also hits your customers.
| blibble wrote:
| the problem is the definition of Open Source is controlled
| by the Open Source Initiative, which has been captured by
| the hyperscalers
|
| which is sort of funny because the term "Open Source" was
| itself coined to make it possible for people to seek
| funding to build companies based on the (crazy?) idea of
| producing software, then giving away its source code
|
| 20 years later, the structure of the industry has now
| changed, and now "Open Source" exists to feed Amazon,
| Microsoft and Google
|
| if it's not possible to alter the definition to include
| licenses that include terms that allow sustainable value
| creation for businesses other than the hyperscalers, then
| the term is no longer fit for purpose, and we need a new
| one
|
| "Fair Software"?
| echelon wrote:
| > "Fair Software"?
|
| That's the term most frequently used! I've seen a number
| of different efforts start to coalesce around this.
|
| https://fair.io/
|
| This was also a really nice license:
|
| https://defold.com/license/
|
| We need licenses like these to combat Amazon, Google, and
| Microsoft. "Open Source" is their grift now.
| lolinder wrote:
| It's really not though. The OSI quickly loses credibility
| when they try to push a definition that the community
| doesn't like (see the Open Source AI kerfuffle).
|
| Both the OSI and the FSF are agreed that Source Available
| with bans on specific use cases is not FOSS. When you've
| got freaking Richard Stallman opposing you you _really_
| have to do better than just scream "corporate capture".
| Engage with his idea of Freedom, don't set up straw men.
| blibble wrote:
| the OSI and the FSF agree, for different reasons
|
| > Both the OSI and the FSF are agreed that Source
| Available with bans on specific use cases is not FOSS.
|
| well... yes, because they decide the definition of the
| terms
|
| > When you've got freaking Richard Stallman opposing you
| you really have to do better than just scream "corporate
| capture". Engage with his idea of Freedom, don't set up
| straw men.
|
| Stallman has a very particular view of Freedom (itself a
| multifaceted term)
|
| and he rather famously completely rejects the term "Open
| Source"
|
| the situation we're finding ourselves in is one where
| three increasingly malevolent entities control and
| capture 100% of the value generated by writing and
| selling software with source code
|
| if you're an employee of these entities, great for you
|
| for the rest of us, this is a bad situation to be in
|
| and certainly not one that could produce another Red Hat
| mcny wrote:
| The AGPLv3 or later is both free and open source and
| should be the de facto license of choice in my opinion
| for mass adoption.
| KingMob wrote:
| I agree that the OSI and FSF are trapped with their most
| hardcore followers, and can't effectively change,
| assuming they even wanted to.
|
| As for Stallman... his idea of freedom is very narrowly-
| scoped. In particular, it makes no distinction between
| hobbyists and megacorps, and is completely blind with
| respect to economics.
|
| By lumping hobbyists with companies, it makes the
| category error of extending human rights to corporations.
| This of course, is nothing new in America, and hasn't
| been since the infamous 1886 Santa Clara County vs
| Southern Pacific Railroad court case, that established
| corporate "personhood".
| lolinder wrote:
| Corporations are collections of humans. There are certain
| ways in which extending human rights to corporations a
| mistake, but allowing them to use free software isn't one
| of them: either the individuals in the company are able
| to use the software or they are not, and if they are not
| then the software is not free.
| michaelt wrote:
| _> the problem is the definition of Open Source is
| controlled by the Open Source Initiative, which has been
| captured by the hyperscalers_
|
| I'm not sure this is true. The OSI's definition of open
| source doesn't seem to have changed since ~2001 [1] -
| before AWS was founded - and it'd been around in various
| forms since ~1997.
|
| This was the era of Microsoft's 2001-era "Shared Source
| license" which was deliberately GPL-incompatible; Bruce
| Perens, author of the definition, wrote _" Microsoft's
| Shared Source program recognizes that there are many
| benefits to the openness, community involvement, and
| innovation of the Open Source model. But the most
| important component of that model, the one that makes all
| of the others work, is freedom."_ [2] (Perens also judged
| the first version of the "Apple Public Source License"
| insufficiently free [3])
|
| They've kinda always been about not just being able to
| view the source, but also modify it, and redistribute the
| modified version, merge it into other software projects,
| make commercial use of it, etc etc
|
| It just so happens that this stance, adopted well before
| AWS existed, works extremely well for AWS.
|
| [1] https://web.archive.org/web/20020126171934/http://ope
| nsource... [2] https://web.archive.org/web/20010813210224
| /http://perens.com... [3] https://web.archive.org/web/200
| 10430042835/http://www.perens...
| lolinder wrote:
| I'd argue it doesn't "just so happen" to benefit AWS, it
| was causal: Open Source created AWS. AWS is structured
| the way that it is in order to benefit from Open Source,
| and it grew to its current size by so benefiting.
|
| In a lot of ways things like AWS are what the OSI set out
| to create when they set out to sell Free Software as an
| idea to corporations. This was the pitch.
| rlpb wrote:
| Take a look at Debian's philosophy:
| https://www.debian.org/social_contract#guidelines
|
| This predates the OSI definition. The philosophy is about
| what empowers the user. Business models (or their
| challenges) have nothing to do with it.
|
| It just so happens that empowering the user also empowers
| competitors.
| pabs3 wrote:
| The OSD is basically a copy of the DFSG btw
| amrocha wrote:
| You wouldn't use the ten commandments as your only moral
| guide.
|
| The landscape has changed. Google, Amazon, and microsoft
| are actively trying to destroy open source business
| models. Don't let the leopards eat your face because you
| were too attached to your ideology.
| rlpb wrote:
| > Don't let the leopards eat your face because you were
| too attached to your ideology.
|
| You're conflating ideologies. User-focused ideology
| doesn't care about business models. Leopards aren't
| eating their faces. They're perfectly fine where they
| are.
|
| Business model focused ideology might care, but the AGPL
| exists and meets Debian's requirements. Those who care
| can choose to use it, or not, as they wish.
| palata wrote:
| > It just so happens that empowering the user also
| empowers competitors.
|
| IMHO copyleft licences are better for the user and
| permissive licences are better for competitors. Still
| people keep going with permissive licences.
| KingMob wrote:
| Ehhh, Amazon offers a hosted Grafana service, which is
| AGPL. I'm not so sure that.
| palata wrote:
| Which means that they have to share their changes to
| Grafana, doesn't it?
| pabs3 wrote:
| The LWN thread says that they don't, but have separate
| proprietary licensing and co-marketing agreements with
| Grafana Labs.
|
| https://lwn.net/Articles/1019686/#CommAnchor1019710
| palata wrote:
| Thanks that interesting!
|
| And in this case it means that it's not AGPL, but
| proprietary. Which kind of proves my point: they are
| apparently paying Grafana Labs to avoid the constraints
| of AGPL. If Grafana was permissive, they would surely not
| pay.
| sunshine-o wrote:
| > the problem is the definition of Open Source is
| controlled by the Open Source Initiative, which has been
| captured by the hyperscalers
|
| Thank you for pointing that out.
|
| This is something I have noticed in the last decade:
|
| A lot of fake, captured organisations have popup around
| open source. I once went down the rabbit hole to try to
| make a list and quickly found dozen of them. It is always
| very hard to understand what they do and employ a bunch
| of people who usually never wrote a single line of code.
|
| One example found on the Fedora website is the "Digital
| Public Goods Alliance" [0]
|
| - [0] https://www.digitalpublicgoods.net/
| lolinder wrote:
| > The solution is clear: start your new database with an
| "equitable source / source available" license from day one.
| Nobody will complain about a relicense since your license
| will handle the hyperscalers right off the bat.
|
| Yes, this would be the honest thing to do, but people don't
| do it because using a non-FOSS license loses you adoption.
| The step you're missing in your little timeline is that the
| only reason the project takes off at all and becomes big
| enough that anyone is making money off of it is because
| it's Open Source. Proprietary databases, programming
| languages, and similar have lost big time and that's not
| changing any time soon.
|
| So what's really happening is that these FOSS companies
| want to have their cake and eat it too. They want to
| release code for free so that other devs will use it and
| then make money from the project while somehow banning
| other companies from also making money off it.
| mulmen wrote:
| What's missing is _why_ open source won. It 's impossible
| to be rug pulled. If the maintainers (this is a carefully
| chosen word) attempt a rug-pull you can just Elastic or
| Redis them. If the product is closed this is impossible
| and you're at the mercy of whoever you built on. Open
| Source is the ultimate right to repair. Everything is
| working as intended.
| KingMob wrote:
| > Everything is working as intended.
|
| If this true, than we need something else.
|
| Otherwise, expect to see a hell of a lot less new FOSS in
| the next decade, which will be a pyrrhic victory.
|
| If FOSS can't meet the demands of the time, it needs to
| be updated or replaced.
| immibis wrote:
| The majority of software was always proprietary. GNU was
| a revolutionary idea. Businesses giving away their
| product to gain favor is just the natural tendency of the
| rate of profit to fall.
| mulmen wrote:
| Selling software is a deadend. Nobody in their right mind
| will pay for it because the risks are too great. If you
| want to build a technology business sell services and
| support.
| trgn wrote:
| > So what's really happening is that these FOSS companies
| want to have their cake and eat it too.
|
| talk about kicking down. So no harsh words about the big
| dogs who, while contributing nothing, and just due to
| sheer size and scale advantage, are capturing the lion's
| share of the enterprise value?
| lolinder wrote:
| > contributing nothing
|
| This is a line that gets thrown around very casually, but
| every assessment I've heard says that the big dogs are
| quite prolific contributors to these projects.
|
| > capturing the lion's share of the enterprise value?
|
| Ah, here's the Matt Mullenweg logic creeping in again
| [0]! This is basically his taunt towards DHH (though at
| least you're using it to cry foul rather than tease!):
| "although he has invented about half a trillion dollars
| worth of good ideas, most of the value has been captured
| by others."
|
| And this is where I think most of this aggression towards
| cloud providers is actually coming from: a significant
| number of these companies have bought into the idea that
| they're a failure if they fail to capture the majority of
| the value from their Open Source project. Which is
| understandable when you make a VC-funded business out of
| it, but makes no sense given that FOSS has always been
| about advancing the collective good, not raking it in.
|
| [0] http://web.archive.org/web/20241014235025/https://ma.
| tt/2024...
| trgn wrote:
| > big dogs are quite prolific contributors
|
| ok sure, but there's contributing and contributing.
|
| > a significant number of these companies have bought
| into the idea that they're a failure ...
|
| ok, fair enough. But in that equilibrium you're painting,
| _only_ companies like AWS will ever be able to monetize
| open source, especially since software delivery and SAAS
| are essentially equivalent in 2025, and SAAS is a
| margin's play which small fry cannot compete with.
|
| VC-funding is also the lever that allows for open source
| software to find deep and quick penetration in the
| industry. it's not aws driving it. So when a practitioner
| benefits from the mature tooling and such a wide userbase
| of say Redis or ElasticSearch, it is not only because it
| was cheap (open source), but also because it was lavishly
| supported (VC).
|
| > I think most of this aggression towards cloud providers
| is actually coming from ...
|
| I mean, you're certainly right about that, wouldn't call
| it aggression necessarily.
|
| The software platform is different now than it was 20
| years ago. If we want a thriving open source ecosystem,
| we will need a answer to the fact that big tech can hover
| up the spoils before the upstarts - that both spearhead
| the project _and_ fund its expansion - have a chance.
| porker wrote:
| This purist mindset is killing the long term viability of
| open source. If hyperscalers can make money from
| successful projects but open source founders can't, in 10
| years we'll have fewer open source projects.
|
| Licence freedoms don't have to be all or nothing, or
| apply to everyone in the world. It can be open source and
| have restrictions. Anything else turns open source into a
| religion.
| rastignack wrote:
| It's not about religion. PostgreSQL devs do make money
| right ? Despite RDS.
| porker wrote:
| Sort-of, we've had a litany of Postgres devshops go bust
| over the past decade. Some will be for the usual reasons
| but I wouldn't want to discount the impact of RDS.
|
| However I think Postgres is a bit different. It's a
| bigger market and more widely used. There's a need for
| tuning services no matter which platform provides the
| database servers, so there's a level to make money above
| cloud hosting.
| lolinder wrote:
| Not a religion, but a term with a specific meaning, which
| meaning implies a collection of freedoms granted without
| discrimination. People are welcome to use licenses that
| revoke those freedoms, but calling them FOSS is confusing
| and muddies the waters.
|
| See Llama's license: if it can be Open Source while
| having restrictions, then having an Acceptable Use Policy
| is okay, right? So Redis could create a license that bans
| its use if you host adult content, Star Wars fan fiction,
| or documents containing the letter R?
|
| If Open Source doesn't mean a license that
| indiscriminately grants a set of specific freedoms then
| it's pretty useless as a term--all I know on hearing it
| is that a project's source code is available. Which
| reminds me, we already have a term for that: Source
| Available.
| noirscape wrote:
| I don't think the license pick is because of adoption -
| outside of a few specific cases, the license usually _isn
| 't_ the blocker to getting your tools/projects more
| widely adopted.
|
| I've written code in the past that I put under GPL that
| today, I'd probably use a different license for (BSD
| 3-clause has my preference these days, although I'd just
| prefer a generic non-commercial license instead). I don't
| really bother relicensing cuz... it just doesn't matter
| in the end, these projects are super niche anyway. I
| picked the GPL since "everyone uses it".
|
| There's always this backlash to demonize anyone daring to
| move away from the GPL when the simple fact is... maybe
| some products just don't work in the modern market with
| the GPL. The hyperscaler thing is a pretty massive issue
| and the fact that GPL proponents can only give platitudes
| of "it's working as intended"/"fuck your greed" instead
| of y'know, accepting that maybe the GPL doesn't work in
| these environments is... not great.
|
| That isn't a defense of the SSPL or anything like that
| (it's quite the bad license), but there's a reason that
| these entities keep writing new licenses instead of going
| "all rights reserved, we publish source as a courtesy,
| you can't use it for anything" (even if they effectively
| close all contributions, they still _want_ to try a
| permissive license.
|
| Basically the thought that goes into picking the license
| often isn't nearly as complicated as you may think. It
| can literally just be "if everyone is doing it, maybe
| what they're doing is right". Not so much "the GPL gets
| you more contributors".
| adamc wrote:
| I think it might depend on the business. In some places,
| open source is the "safe pick" (particularly if you
| aren't selling software and are not worried about things
| like the GPL). In others, licensing concerns are huge.
| WD-42 wrote:
| Or start with the AGPL from the start instead of a pushover
| license and sell alternative licenses to hyper scalers if
| they want it.
| KingMob wrote:
| You know Amazon has a hosted Grafana service, right? The
| AGPL isn't a guaranteed obstacle to hyperscalers sucking
| up most of the value produced by maintainers.
| immibis wrote:
| They don't suck it up, since they pay Grafana Labs for
| it.
| Brian_K_White wrote:
| "walking off with your money"
|
| This is the heart of all of these stupid takes. There is no
| "your money" for anyone else to walk off with. Nothing was
| stolen.
|
| If you want to sell software, or rent access to software,
| then just do that honestly forom the outset. And good luck
| to you on that. I will not consume it unless I have no
| other choice, and I will not contribute to it at all
| period, even tertially by for instance developing things
| that use it or help people work out how to solve problems
| with it etc. In other words just generally not invest in
| it, in all the different ways one might invest in
| something. But hey maybe you will make something
| indispensible and do it better than anyone else can, and
| maybe you will get a bunch of other customers.
|
| If you want to benefit from the adoption and goodwill and
| army of free work that comes with open source, then do
| that.
|
| The honest reason to work on open source is because you
| yourself have recognized how much utility you have been
| given fo free because of it, and wish to pay it forward and
| basically add to humanity as a whole. What you get back out
| of it is the same thing everyone else does, the use of the
| software itself, plus your name being on it.
|
| But if you license something open source, and then care the
| TINIEST BIT what someone else does with it beyond adhering
| to the attribution and share-alike terms, then you have
| missed the point of open source. You are bent about being
| "robbed" of something that was never yours in the first
| place. You have no right to Amazon's billions, even the
| part of it that they made by hosting a copy of some oss
| software you happened to have written. Amazon is not
| selling your property, they are selling a managed hosting
| service. You have no right to the revenue from that. The
| software being hosted is a community resource there for
| everyone to use like the air or water, only even better
| since unlike Nestle taking the water from everyone else,
| everyone else still has the software.
|
| If anything the supposed injured party in all of these
| cases are the bad community members because they are often
| only OSS disingenuously in the first place. They start off
| with MIT/BSD style licenses because they know a lot of
| companies are allergic to GPL. But WHY are they so
| intolerant of GPL? Because GPL doesn't allow them to steal,
| but MIT allows them to steal. So they start with an MIT-
| type license because it's "commercial friendly" and then
| later cry that someone "stole" their B S freaking D
| licensed software.
|
| People that do that were never writing open source for the
| purpose of adding to the community pool in the first place.
| It's either dishonest or at best, possibly honest but in
| that case just unbelievably incompetent and ignorant.
| amrocha wrote:
| You're living in theoretical fantasy land.
|
| Yeah, it'd be great if everything was open source and
| everyone was happy.
|
| But that's not really what happens. Redis and Elastic are
| popular exactly because there's entire companies behind
| it constantly maintaining it, securing it, and adding
| features.
|
| If you want use open source software at your job that's a
| hard requirement. No, you can't use
| "MySillyKeyValueCache" that Timmy develops in his free
| time with no security or compatibility concerns.
|
| Companies cost money to run. Google and AWS exploit open
| source work for profit, and don't contribute back enough
| to ensure its support. This is what you should be really
| mad about. The internet giants are literally killing open
| source.
|
| If they have their way you'll be stuck with their
| proprietary software. In practice AWS is already there.
| Brian_K_White wrote:
| Then sell software. I said that first thing. Where is the
| fantasy in that?
|
| If _you_ don 't understand it such that you think it's a
| fantasy (despite the ocean of existing software as proof
| that is produced, and countless published manifestos from
| people who do it describing why they do), well that's a
| you problem not a me or anyone else problem.
|
| You don't get it, that's fine, then simply don't get it,
| and don't participate in this activity you think is
| insane.
|
| You are free to have any opinion you want about what
| constitutes a rational use of _your_ time and effort.
|
| But don't pretend you understand something that the
| participants do not understand. We're all eating non-
| fantasy food just fine, somehow.
| tyg13 wrote:
| If they try to sell their software, by your own
| admission, you won't consume it. That's the point. The
| fantasy is the idea that some of these open-source
| products would even work as a closed-source proprietary
| business model.
| Brian_K_White wrote:
| Then don't try to sell it. Or make something else that
| people can't live without and are willing to pay for and
| can't just pay themselves to write an equivalent instead
| of paying rent to you forever, whatever, what's it to me
| or anyone else?
|
| Do whatever you want but it's no one else's problem if
| you can't figure out what.
|
| Ya got no argument here.
| growse wrote:
| I disagree with you on a lot, but you're bang on the
| money here.
|
| If you want a business, build a business. One key aspect
| of building a business is understanding what your IP and
| trade secrets are, how they affect your bottom line, and
| then controlling them appropriately.
| amrocha wrote:
| The point is that if there was no business behind
| projects like Redis and ElasticSearch you wouldn't be
| using them either. You'd be using some random Microsoft
| or Oracle product.
|
| I'm guessing you don't want that either, so come up with
| a way to make sure Redis has the financial support it
| needs to hire engineers to do the full time work that
| part time contributors like us don't want to.
| Brian_K_White wrote:
| The point is I don't have to come up with any such thing.
|
| It is not true that if redis didn't exist then I'd be
| using some MS or Oracle product. I might, if it was
| practical. Or someone might have invented redis, or I
| might if that was a space that still needed filling and
| somehow no one else did it.
|
| It's like saying if linux didn't exist we'd all be using
| NT.
|
| That's completely ridiculous. No we would not. BSD
| already existed and if not that then a minix clone or
| someone else would have started some other unix clone.
| There were several small unix clones and other full OS's
| made by completely small developer teams by then, even
| single people, commercially. If a single guy can do it at
| all (regardles that they were doing it to sell), it means
| the job is not infinitely big and so perfectly doable by
| a few self-motivated volunteers, especially given how
| that kind of work has no deadline.
|
| Except "volunteer" is the wrong word because they aren't
| some kind of weird saint doing something _just_ for you
| or me. They are doing it for themselves, and you get to
| have it too.
|
| Everything is like that. Redis is no different. There is
| nothing magic about redis. Things exactly like that get
| created when the need for them arises every day. If redis
| didn't exist is a nonsense invalid premis because 12
| redis-alikes will always exist any time the need for it
| exists. It doesn't matter that I didn't already do it
| muyself, and I don't have to now either, and that is not
| just beacause redis happens to exist.
| palata wrote:
| > Google and AWS exploit open source work for profit, and
| don't contribute back enough to ensure its support. This
| is what you should be really mad about. The internet
| giants are literally killing open source.
|
| They would have to publish their changes if those
| projects used copyleft licences. Copyleft licences don't
| force to "contribute back", but they force disclosing the
| changes, that the community can then benefit from.
| amrocha wrote:
| I like copyleft licenses!
|
| But they don't solve the problem of cloud providers
| pulling the rug out from under companies based on open
| source companies.
| palata wrote:
| Not sure I understand your message. If you have a
| copyleft licence without a CLA, then the copyright is
| distributed between all the contributors, which makes it
| almost impossible to change the licence. And because it
| is copyleft, it means that the sources need to be
| distributed to the users.
|
| So TooBigTech can build a service upon a copyleft
| project, but they have to distribute their changes, which
| means that the community can benefit from them. One
| example I learned about here is Grafana: AWS did not want
| to use their AGPL version so apparently they pay Grafana
| to get a commercial licence. That's of course possible
| only because Grafana own the copyright of the whole
| codebase. It wouldn't be possible with Linux, for
| instance, where nobody has the power to give a commercial
| licence and therefore it is GPLv2 for everybody.
|
| It doesn't prevent TooBigTech from competing by serving
| the open source project, but that is more of an antitrust
| issue, I think.
| amrocha wrote:
| Gotcha, I see what you're saying.
|
| I didn't know about Grafana. That sounds awesome.
|
| Maybe you're right about this being an antitrust issue
| though.
| jpc0 wrote:
| > Companies cost money to run. Google and AWS exploit
| open source work for profit, and don't contribute back
| enough to ensure its support.
|
| I don't understand this take, if Google/AWS/Microsoft
| decide to host your service and some vulnerabilities are
| discovered then you got free Security Research done, your
| product would either have remained vulnerable or someone
| else would have filed the same bug.
|
| You own the code so you can decide only certain people
| can commit PRs and can choose to close any feature
| requests issues.
|
| If one of the cloud providers decided to use your product
| it's because they deemed it reasonable as is or they can
| fork / contribute upstream.
|
| That is what OSS is, by definition.
|
| Hell you can post the code with a license like MIT and
| then never touch it again, and if someone else can
| monitise that code kudos to them.
|
| If you are an existing company and open sourced your
| code, Facebook/react, then you presumably already make
| enough money to support development yourself or intend to
| stop development.
|
| If you open source code that is your core business and
| somebody "steals your lunch" your learnt an important
| lesson and hopefully won't make the same mistake twice.
| If you then decide to relicense and the community
| abandons you and causes uproar on the internet you are
| reaping the rewards of your actions, accept them.
| amrocha wrote:
| Look, in principle I don't disagree with anything you
| said.
|
| However, I think OSS is a net positive to the industry,
| and would like to see it remain that way.
|
| The classic way to monetize OSS has been to provide
| hosting and support for a price.
|
| Now the internet giants are taking that entire pie for
| themselves.
|
| If we agree that we want OSS to be a viable option going
| forward, and we agree that you need money to hire devs to
| maintain a successful large scale OSS project, then what
| do you suggest be done?
| jpc0 wrote:
| > and we agree that you need money to hire devs to
| maintain a successful large scale OSS project
|
| Therein lies our disagreement, you don't need to. If you
| are amazon and upstream is willing to accept requests
| then amazon can hire devs, and if someone eats their cake
| then those devs will eventually migrate to the new
| location.
|
| As someone who did the initial work for OSS I put the
| code out there, if I dislike the direction a fork is
| taking I can ignore said fork and keep working on my own
| version, why do I need to use the version they are using.
|
| It boils down to why did you even start an OSS project,
| if the intention was to make money or hire other
| employees you fundamentally misunderstood the assignment.
|
| If you made a project that serves your own need, decide
| someone else may benefit so you publish it as FOSS online
| and it gets massive traction how does that change your
| need, you probably have no reason to make it commercially
| viable, it is still serving the same need it always has
| for you.
|
| Now if it gets forked and the fork proves to be of better
| quality and still serves your need then switch to the
| fork for your own personal need and now someone else is
| doing the maintenance, so you end up being the
| "freeloader".
|
| And I've already discussed the "burden on the
| maintainer", if it's such an issue close access to issues
| and pull requests. No more burden.
| theamk wrote:
| All companies should do this.. if anything so we know what
| not to use.
|
| Any sort of proprietary product (be it fully closed source,
| source-available, or "open source with limitations") is
| always a risk. You were happily using database X, but they
| got acquired by Broadcom and now their product costs 100x
| what it was before. What do you do now?
|
| That's why it is much safer to adopt open source - worst
| case is the company goes under, but you still keep using
| last released version indefinitely, and hope new entity
| (maybe even hyperscaler!) forks the code. Or make an in-
| house fork if you have enough resources.
|
| "equitable source" license means it's not an option. That
| new product should really be much, much better than open-
| source alternatives to even be considered.
| palata wrote:
| > worst case is the company goes under, but you still
| keep using last released version indefinitely, and hope
| new entity (maybe even hyperscaler!) forks the code
|
| But it's not always the worst case, is it? If the licence
| is permissive, an hyperscaler can just take is and make a
| proprietary product out of it.
|
| Hence copyleft licences _without a CLA_. Nobody could
| make Linux proprietary because the copyright is shared
| between so many people /companies.
| immibis wrote:
| They're talking about worst for the customer. You're
| talking about worst for the supplier.
| palata wrote:
| I don't understand what you are saying. What has a
| "supplier" to do in this?
|
| Copyleft is _always_ the best for the customer. Copyleft
| says "the customer has _rights_ ". Permissive says "do
| whatever you want, as long as you keep my name somewhere
| in the attributions".
| immibis wrote:
| A product - in this case, software - is supplied from a
| supplier, or vendor, to their customer. Is this business
| 101?
|
| The usual worst case for the supplier is that they give
| the product but don't get paid, and the usual worst case
| for the customer is that they give the money but don't
| get the product.
|
| With copyleft specifically, the supplier is much more
| likely to not get paid, but the customer receives the
| benefit of being allowed to continue the maintenance of
| the software themselves if the supplier goes out of
| business. The supplier hopes this will help them acquire
| and keep customers, many of whom will pay, and keep them
| in business.
| palata wrote:
| > Is this business 101?
|
| I understand what a supplier is. I don't understand how
| it relates to what I said.
|
| > With copyleft specifically, the supplier is much more
| likely to not get paid
|
| That doesn't make any sense. Whether the supplier open
| sources their code as permissive or copyleft doesn't have
| any impact on the likelihood of getting paid.
|
| But if they distribute it as permissive, a competitor can
| just make a proprietary fork. Possibly continuously
| importing the new improvements from upstream and focusing
| on differentiating. Whereas if they distribute it as
| copyleft, a competitor has to share their changes, that
| upstream can benefit from.
|
| So for the supplier, if that's how you want to call it,
| it's better to licence code as copyleft. Except if the
| whole idea is to be adopted by corporations, but in that
| case don't whine when they take your code and build a
| proprietary product without contributing anything back.
| theamk wrote:
| Who exactly is suffering in this case?
|
| The original company went under, they no longer exist, so
| they obviously don't care.
|
| The software user does not care either. OK, someone made
| a proprietary fork, and that "someone" is a
| hyperscaler... so what? The last released version is
| still out there and still can be used-as is / maintained
| by you / maintained by other 3rd party.
|
| The new maintainers / fork authors should not care too.
| They base off the last released version, and their fork
| is not affected in any shape by what some hyperscalers
| do.
|
| (I guess you can make an argument that proprietary fork
| might pull users/resources from the open-source one...
| but I don't think it's a big issue. If the users chose
| open-source version to begin with, why would they switch
| to proprietary fork?)
| scargrillo wrote:
| This breakdown hits hard because it's not just about
| business models -- it's about trust.
|
| Open source succeeded because it created shared public
| infrastructure. But hyperscalers turned it into extraction
| infrastructure: mine the code, skip the stewardship.
|
| The result? We've confused "open" with "free-for-the-
| powerful."
|
| It's time to stop pretending licenses are enough. This is
| about incentives, governance, and resilience. The next
| generation of "open" has to bake in counterpower -- or it's
| just a feeding trough for monopolies.
| palata wrote:
| Before moving from permissive licences to non-open-source
| licences (because they have exceptions for TooBigTech),
| an easy step would be to use copyleft licences, wouldn't
| it?
| KingMob wrote:
| Not necessarily. Amazon sells a hosted Grafana service,
| which is AGPL.
| palata wrote:
| That's wrong: they pay Grafana Labs to use it as
| proprietary, as noted in another comment:
|
| https://lwn.net/Articles/1019686/#CommAnchor1019710
|
| > Grafana's a great example of this. AWS and Azure
| _could_ have sold the unmodified AGPL Grafana as a
| service or published their modified versions, but
| instead, they both struck proprietary licensing and co-
| marketing agreements with Grafana Labs.
| mfitton wrote:
| Testing my LLM-detection abilities. Did you write this
| yourself? Or is this LLM produced?
|
| The phrasings stick out to me as super GPT-like.
| palata wrote:
| > A hyperscaler clause such that any managed offering has
| to (1) be fully open source, (2) has to pay a fee, or (3)
| is prevented outright.
|
| A copyleft licence (not necessarily GPL, there is also MPL
| and EUPL) from the beginning on would result in (1), no
| need for a new license.
|
| But people "don't want strings attached" and are happier
| with permissive licences, and then they complain.
| SPBS wrote:
| > Amazon / Google / Microsoft offer managed versions of the
| database and make bank on it. Easily millions in revenue.
| Original creator / company doesn't get anything, and the
| hyperscaler isn't obliged to pay.
|
| This isn't what is happening. A company called Garantia
| Data renamed themselves to Redis Labs and acquired the
| Redis trademark. They're not the original company, and they
| used a naming trick to present as if they are official
| (they are now, and nothing they did was illegal).
|
| https://news.ycombinator.com/item?id=42256757
|
| https://www.gomomento.com/blog/rip-redis-how-garantia-
| data-p...
| KronisLV wrote:
| > The company decides to change the license to force Amazon
| / Google / Microsoft to pitch in and pay a fee.
|
| Could you put a clause in the license that calls out those
| _specific_ companies that you 're concerned about and makes
| them pay, as well as any of their subsidiaries, a list that
| can be changed later?
|
| That way, smaller businesses around the software can still
| exist, nobody gets concerned with the license too much
| because it calls out specific hyperscalers (no love lost on
| them in the community) and you still get them to pay their
| fair share.
|
| Why do people try to ruin everything by SSPL that's overly
| restrictive and catches everyone else in the blast area, or
| try to write some clever license that would apply in all
| cases? Just call out the exact companies that are eating
| your lunch! Hyperscaler Anti-Freeloading
| License (HAFL): If you belong to any of the following
| companies, or are a subsidiary of them, or operate any of
| the given cloud platforms and want to offer the service
| there, pay up: Amazon Web Services (Amazon), Google Cloud
| Platform (Google), Microsoft Azure (Microsoft), Alibaba
| Cloud (Alibaba Group), IBM Cloud (IBM), Oracle Cloud
| Infrastructure (Oracle), Tencent Cloud (Tencent), SAP Cloud
| Platform (SAP). This list can be changed at our discretion.
| gkbrk wrote:
| You could, but it still wouldn't be open source.
| lolinder wrote:
| > a list that can be changed later?
|
| No legal department will ever approve using software
| under a license like that. Who wants to risk being the
| next addition to that list?
| hmottestad wrote:
| Dunno about Redis, but for Elastic I still feel sorry for
| them being thrown around like a rag doll by Amazon. On
| principal I will not use the Amazon fork, because I don't
| want to support a company that would prefer to fork a project
| rather than fork over some cash. Amazon is more than willing
| to sell you their Elasticsearch fork at a loss as long as
| they can eventually recoup the losses when Elastic inevitably
| dies. At which point they will naturally abandon the open
| sources side of their fork and continue development in
| private, at a much slower rate, while doubling the price of
| the AWS service. At which point you'll have no choice but the
| pay up, cause there aren't any competitors left.
| andrepd wrote:
| I sure wish I lived in a world where anti-competitive
| regulators weren't a joke.
| ikiris wrote:
| What exactly do you think is anti-competitive about
| offering an open source product as a service?
| palata wrote:
| Being in a position where you can copy anything and crush
| competition is a problem.
|
| In terms of antitrust, I believe that if you could prove
| that Amazon forked and offered the service with the
| intent to crush the competition, it would be downright
| illegal. A current case is Meta: back then, Zuckerberg
| was happily writing (internally) that Facebook needed to
| buy WhatsApp and Instagram and Snapchat to prevent them
| from ever competing. This is anti-competitive.
|
| This post explains it well:
| https://pluralistic.net/2025/04/18/chatty-zucky/#is-you-
| taki...
| growse wrote:
| They can't "copy anything".
|
| They can only copy what they're explicitly legally
| allowed to.
|
| Elastic explicitly allowed AWS to copy and use their
| source code, then whined about it.
| palata wrote:
| I meant they have the resources to copy any product in a
| way that will crush the competition.
|
| As in, they can build an alternative to an open source
| project, offer it for free (i.e. at a loss) for years
| until they capture the market, and then start
| enshittifying. This is an antitrust problem.
|
| > Elastic explicitly allowed AWS to copy and use their
| source code, then whined about it.
|
| Yeah at the very least they should have started with a
| copyleft licence.
| growse wrote:
| Ah I see what you mean. Yes, agree. But that's orthogonal
| to OSS and like you say is a reg issue.
| ignaloidas wrote:
| Companies that build themselves on selling open source
| software put themselves in the position where anyone else
| can copy them and compete with them on price, and price
| alone. This is clearly the disadvantage of open source.
| It brings plenty of advantages, which is why people do it
| - but you can't have only the advantages and no
| disadvantages of open source.
|
| Open sourcing your product is a risky investment, and as
| with all risky investments, it might pay out, or it might
| not.
| palata wrote:
| As I said before, I believe that using permissive
| licences is a bad idea. I have seen multiple projects
| choosing a permissive licence as a way to compete against
| an already established copyleft project, just because
| it's easier to get adopted by companies. I find it unfair
| but also a bit stupid: by using a permissive licence,
| they allow anyone to compete with them with a proprietary
| fork.
|
| Still, there is an antitrust question (that is slightly
| orthogonal): if TooBigTech can offer a similar product at
| a loss (e.g. for free) until they capture the market,
| then that's a problem. And they can only do it because
| they are too big, and that is an antitrust issue IMO.
| lolinder wrote:
| > being thrown around like a rag doll by Amazon
|
| Can you elaborate on what exactly Amazon did to Elastic? I
| read all of their blog posts and the only thing I really
| got out of it was "they sell hosted Elastic cheaper than we
| can", which is hardly surprising given that Elastic really
| just packages up AWS/GCP/Azure cloud infra. That doesn't
| have to be AWS selling at a loss, AWS just doesn't need to
| pay itself.
|
| And by all accounts I've read Amazon _did_ contribute back
| to Elastic development up until Elastic switched the
| license on them. _At that point_ they forked, but it 's
| hard to blame them when they were deliberately locked out
| of the original project.
|
| Most of the arguments I've seen against Amazon with regard
| to Elastic have tended to be very vibe-based. Amazon
| bullied Elastic because that's always what Amazon does!
| It's plausible, but it's also plausible that Elastic
| thought they could use Amazon's terrible reputation as a
| weapon against it without there being any substance.
| osigurdson wrote:
| My understanding is the dispute was mostly about the
| trademark. Here is a link:
| https://www.elastic.co/blog/why-license-change-aws
| (original license change in 2021, not the most recent
| one).
| trgn wrote:
| Elastic was in the same bind as every company which
| writes opensource. There's no way to monetize it when a
| hyperscaler can sell it at much thinner margins.
|
| Either the product is donated to a foundation, or the
| parent company dies.
|
| While amazon technically wasn't doing anything "wrong",
| they're effectively squeezing the oxygen out of the
| ecosystem.
|
| The parameters of the problem are relatively new. SAAS -
| which is now the norm for how software should be
| delivered, and opensource - which is old - just don't
| mix, the incentive structure is completely misaligned.
| Companies are prodding to see how to get out of this
| conundrum. Mongodb set the tone with the SSPL, and other
| midcap just kind of followed suit, what else was there to
| do, what other approaches could have been taken? Now, as
| the fallout starts to become clear, there's just a lot
| more information now on what works and doesn't, and
| companies are pivoting.
|
| There's no vibes about it, it's brutal reality out there,
| big tech is strangling the market, and the small guys are
| figuring a way out, first trying one way, now another.
| musicale wrote:
| > Elastic was in the same bind as every company which
| writes opensource. There's no way to monetize it
|
| It is hard to get customers, especially businesses, to
| pay for something which is being given away for free.
| rank0 wrote:
| Whats the point of open source if you can't fork or sell
| hosted clusters?
|
| Also from
| https://en.wikipedia.org/wiki/OpenSearch_(software):
|
| > On September 16, 2024, the Linux Foundation and Amazon
| Web Services announced the creation of the OpenSearch
| Software Foundation.[15][16] Ownership of OpenSearch
| software was transferred from Amazon to OpenSearch Software
| Foundation, which is organized as an open technical project
| within the Linux Foundation.
|
| OpenSearch is Apache License 2.0. You can do whatever you
| want to/with it. How are Elastic the good guys in your
| mind?
| BoorishBears wrote:
| Amazon's product had confusing naming and positioning,
| and lagged in compatibility which created a headache for
| Elastic.
|
| And they were using an open source piece of software, but
| scaling it with closed source secret sauce on top of
| that. The license was saying they'd have to open up their
| secret sauce or pay, and their response was to leave the
| table instead.
|
| OpenSearch still lacks tons of really basic functionality
| from Elastisearch, and watching how far ahead
| Elasticsearch got as a product shows how much free lunch
| Amazon was getting... and how much they _actually_ cared
| about the product when it was time for them to put their
| money where their mouth was (despite AWS pulling Elastic
| 's _yearly_ revenue every 4 days).
|
| Elasticsearch has generally matured like it has a
| passionate builder with a vision. They pushed on two
| major fronts (LLMs and Observability) and managed to
| execute effectively without letting product quality slip.
|
| Meanwhile OpenSearch is still the place where tickets
| requesting 3+ year old ES functionality go to die.
|
| -
|
| I'm honestly on the opposite side: how is the hyperscaler
| offering a strictly inferior product with closed
| extensions and still managing to eat the main developers'
| lunches for the sole reason they already have sales
| pipelines established _not the bad guy?_
|
| I guess I'm not really someone who believes in infinite
| scaling rules: something that can work at the individual
| scale doesn't have to work when hyperscalers do it (like
| selling hosted clusters)
| motorest wrote:
| > Amazon's product had confusing naming and positioning,
| and lagged in compatibility which created a headache for
| Elastic.
|
| Irrelevant.
|
| Elastic decided to release software to the public with a
| license that granted everyone under the sun the right to
| use it how they saw fit. This included also selling
| services.
|
| That became a big part of their business model as it
| drove up it's adoption rates and popularity. If Elastic
| kept things like Elasticsearch proprietary, they would
| hardly have the same adoption rates.
|
| You can't have it both ways. Why do you think people drop
| these projects the moment these corporations decide to
| pull the rug from under their userbase?
| palata wrote:
| > You can't have it both ways.
|
| I believe that antitrust laws should prevent TooBigTech
| from being in that position in the first place.
|
| The problem is not the open source licence, but rather
| the fact that TooBigTech can screw the competition
| whenever they feel like it.
| motorest wrote:
| > I believe that antitrust laws should prevent TooBigTech
| from being in that position in the first place.
|
| Irrelevant. If you grant a right to everyone under the
| sun, you do not get to retroactively pull those rights
| from someone you decided to target.
| palata wrote:
| Of course it is relevant. TooBigTech is killing smaller
| companies just because it is too big.
|
| When there are issues like this ("we made a successful
| product and someone forked it and it's killing us"), the
| "someone" is generally a BigTech, not 3 students in a
| garage. Then people complain about open source
| working/not working, and forget that the root problem is
| the monopoly that is screwing them.
| growse wrote:
| Large companies using their scales to compete is a
| _feature_ of capitalism, not a bug.
|
| AWS only gets to compete using their source code because
| they opened it in the first place. The competition was
| explicitly invited.
| motorest wrote:
| > Large companies using their scales to compete is a
| feature of capitalism, not a bug.
|
| It's more fundamental that that. It's this idea that a
| corporation can arbitrarily change licensing terms
| already granted to end-users to extort them.
|
| This is not limited to any managed service provided by a
| random cloud provider. The core reasoning is a
| corporation identifying end-users who are profiting from
| a service that directly or indirectly involves a project
| they release to the public under a FLOSS license. They
| see people getting paid, and retroactively change terms
| to coerce them into paying them. The same argument they
| throw at AWS providing a managed service also applies to
| any company using their project. How does this make any
| sense?
| palata wrote:
| > It's this idea that a corporation can arbitrarily
| change licensing terms already granted to end-users to
| extort them.
|
| If contributors refused to sign CLAs, then corporations
| would either not get contributions or not be able to
| arbitrarily change the licence. It's also the
| contributor's fault if they contribute to a permissive
| project and give up their copyright. Is it extortion if
| they agreed to it?
|
| And then those contributors come whining because the
| corporation does whatever they want. Too bad, don't sign
| a CLA. And don't contribute to permissively-licenced
| projects if you don't want your code to end in
| proprietary products.
| palata wrote:
| > Large companies using their scales to compete is a
| feature of capitalism, not a bug.
|
| Large companies using their dominant position to compete
| is not a feature of capitalism. Antitrust laws prevent
| that. It's just that the US ignores them.
|
| > AWS only gets to compete using their source code
| because they opened it in the first place. The
| competition was explicitly invited.
|
| This part I agree with: if you build a permissively-
| licenced project, you don't get to whine when competitors
| use it in their own proprietary alternatives.
| motorest wrote:
| > Of course it is relevant.
|
| No, it is irrelevant. Try to think about it for a second.
| You release a project under a license that grants
| everyone the right to use it as they see fit, including
| building a business on it. Everyone starts using the
| project as they see fit.
|
| Do you believe you now have the right to retroactively
| pull the license on a whim?
|
| No, you do not.
| palata wrote:
| > No, it is irrelevant.
|
| Yes, it is relevant.
|
| Try to think about it for a second: multiple problems can
| exist in parallel:
|
| 1. Some company uses a permissive licence, sees a
| competitor making a proprietary product from their base,
| and starts whining. Too bad, they should have used a
| copyleft licence from the beginning on.
|
| 2. Some company makes a nice product. TooBigTech sees it
| and builds an alternative (be it a fork or from scratch,
| I don't care). TooBigTech offers it for free (because
| they can, because they are too big) and capture the
| market. The original smaller company dies, because they
| can't offer their product for free. Now TooBigTech can
| start enshittifying because they own the market, again.
|
| > Do you believe you now have the right to retroactively
| pull the license on a whim?
|
| If you own the copyright to the whole codebase, of course
| you can. All those contributors who signed a CLA and are
| now whining should think about that.
| nirvdrum wrote:
| > Elastic decided to release software to the public with
| a license that granted everyone under the sun the right
| to use it how they saw fit. This included also selling
| services.
|
| The original licensing decision was made well before the
| formation of Elastic the company. Maybe Shay didn't quite
| give it the full consideration. I don't know him super
| well, but like most developers starting open source
| projects, I don't think he has a legal background. I
| confess to a certain about of naivety, thinking that
| contributors would adhere to the spirit of contribution
| rather than the absolute letter of the license. I don't
| think it's unreasonable to have societal expectations
| above and beyond the legal requirements.
|
| I've been doing open source for ~25 years and it appears
| to me there's been a distinct shift in how companies
| approach open source. I feel like what I started with was
| almost a eutopic ideal and now I'm expected to just do
| free support work for companies that don't want to pay
| anything to anyone. I don't see any problem with devs
| realizing their mistake or changing their mind and
| updating the license accordingly. For my part, I used to
| use ASLv2 for everything and now I default to AGPL.
|
| > You can't have it both ways. Why do you think people
| drop these projects the moment these corporations decide
| to pull the rug from under their userbase?
|
| Just like you have no legal obligations above what the
| license says, they have no legal obligations to make
| their work available under the license you want. It's
| open source, so feel free to take the commit from version
| before the license change. Of course, it turns out it's
| quite a bit messier to have two incompatible versions
| floating around, but as long as we're limiting ourselves
| to legal requirements that's a non-issue.
|
| The most obvious reason these projects get dropped after
| a license change is because they now use a license that
| needs to be reviewed. It's a lot easier to justify
| spending on a new AWS service than it is getting a new
| license approved. But, that was more or less happening
| anyway. If you're already on AWS it's easier to add a new
| service than pay for hosting a service with a third
| party. I don't particularly fault Elastic for not wanting
| to be Amazon's R & D arm and support team.
|
| We have a lot of systems and infrastructure in place that
| only mostly work because both parties hold up their own
| end of an unspoken agreement. Large tech companies have
| decided they can save money by breaking breaking away
| from that and just sticking to the letter of the license
| text. Legally, they have that right, but the other
| parties have predictably responded. I think what it
| really shows is our licenses don't fit all scenarios.
| Maybe I'm okay with individuals and companies with a
| market cap < $1T using the software under terms akin to
| open source but don't want to be a de facto employee for
| a large company reselling my software. We're well past
| the point of open source being about software freedom.
|
| Most of these projects start off as a developer choosing
| a license without having the legal background to truly
| assess it and then they run into an 800 lbs. gorilla with
| loads of in-house counsel. Blaming them for not thinking
| it all the way through or realizing the implication of
| their license choice seems to me counter-productive.
| Okay, so they made a mistake. What now? They don't want
| to continue working under the framework where they feel
| being taken advantage of. I don't think they should be
| obligated to continue doing so because all of the non-
| Amazon folks don't want to incur the headache of forking.
| I'd love to see some of that ire aimed at the company
| willing to break the illusion to make some extra money
| than the folks that have freely given away their work for
| years.
| motorest wrote:
| > The original licensing decision was made well before
| the formation of Elastic the company.
|
| Yes. Those are the terms the software has been
| distributed with from the inception.
|
| No corporation has the right to pull those rights from
| end-users, no matter how profitable your shakedown scheme
| would be.
| jamespo wrote:
| Well they obviously do have the rights, are you saying
| they broke the law?
| motorest wrote:
| > Well they obviously do have the rights, are you saying
| they broke the law?
|
| No, they do not. They can release new versions with some
| other license if they get all contributors to agree. They
| absolutely cannot pull the FLOSS licenses from existing
| releases.
| nirvdrum wrote:
| > They can release new versions with some other license
| if they get all contributors to agree.
|
| Contributors must sign a Contributor License Agreement
| (CLA) before a contribution will be merged. The CLA
| signers gave Elastic the right to change licenses, among
| others, when they signed the agreement. Consequently,
| Elastic doesn't need to get individual sign-off from each
| contributor before changing the project license. The code
| wasn't based on copyleft license, so there's no
| compulsion to continue using the same licensing terms for
| all future distributions. That's a motivating factor for
| many CLAs. If you made a contribution prior to the
| introduction of the CLA then things get murkier.
| mola wrote:
| Yes, anti trust rules should have stopped amazon. But
| they didn't, this directly hurts open source.
|
| I don't think elastic would've tried the license change
| because of competition using the open source.
|
| The problem is Amazon, not elastic that's trying to
| survive.
| motorest wrote:
| > Yes, anti trust rules should have stopped amazon. But
| they didn't, this directly hurts open source.
|
| What absurd, twisted logic. No, it does not affect open
| source. What are you talking about?
|
| > The problem is Amazon, not elastic that's trying to
| survive.
|
| No, the problem is Elastic trying to coerce end-users to
| pay them for using FLOSS projects. It makes absolutely no
| difference if AWS provides a managed service or if I run
| Elasticsearch in a AWS EC2 instance I pay for.
| matt-p wrote:
| So how should the maintainers eat? Or there should be
| none? Should they be Amazon employees?
| growse wrote:
| Personally, as an un-paid OSS maintainer, I chose to go
| get a job. Other's might choose different paths.
| geodel wrote:
| They can create business with closed source software. No
| one demanded of them to create Apache License software.
| chuckadams wrote:
| > Yes, anti trust rules should have stopped amazon
|
| Which ones, specifically?
| BoorishBears wrote:
| > Irrelevant.
|
| You keep spamming this to anyone who replies to you:
| maybe your take is the irrelevant since it didn't stop
| them from pulling the rug in the first place?
|
| > people drop these projects the moment
|
| Noisy people always proclaim that they will, and
| hyperscalers gleefully market their forks... meanwhile
| it's mostly hyperscaler customers that they weren't going
| to get in the first place that _actually_ move.
|
| Elasticsearch was source available for 4 years and still
| saw massive growth.
|
| People tried to spin Redis db-engine rankings dropping as
| being due to Valkey, but their trendline doesn't seem to
| have been affected at all by the change: https://db-
| engines.com/en/ranking_trend/system/Redis
|
| -
|
| But to be more direct, I'm honestly unimpressed with this
| brand of reductionism.
|
| It's super easy to keep yelling IRRELEVANT THEY WERE
| RUNNING AN OPEN LIBRARY AND SHOULD HAVE EXPECTED SOMEONE
| TO SHOW UP WITH A HAULER TO TAKE ALL THE BOOKS, but it's
| not useful.
|
| I'd also rather have a software ecosystem that uses
| targeted defenses to counter hyperscalers (which are more
| like an invasive species) than one that throws up its
| hands at them.
|
| For anything that isn't Linux-scale, the alternative is
| that most of the well funded development ends up being
| from hyperscalers and that just concentrates their power.
| adastra22 wrote:
| > Whats the point of open source if you can't fork or
| sell hosted clusters?
|
| Is this sarcasm?
| mkhalil wrote:
| Most (all? _) open source licenses allow you to sell
| hosted clusters. They offered a hosted solution well
| before they changed its license. You can also fork it;
| but depending on the license, you might need to open-
| source any fork.
|
| _ : I don't know of any open source license ones that
| don't allow someone to sell hosted cluster. Even AGPL,
| which is copyleft, allows it; so long as the hosted
| version is either: the same as the open-source version,
| or it's version is also open-sourced.
| adrr wrote:
| It's a copyright license not a EULA. Grants rights for
| copying and can't put restrictions on the using part.
| palata wrote:
| > Whats the point of open source if you can't fork or
| sell hosted clusters?
|
| The problem here is that Amazon is in a position where
| they can fork and sell it for a loss in order to crush
| the competition.
|
| That would be the point of antitrust, I guess? I mean if
| regulations were actually enforced.
| growse wrote:
| This is not a suddenly emerging "gotcha".
|
| This risk has _always_ existed. It existed when they
| chose to open source it in the first place.
|
| Time and time again we see the lesson being learned the
| hard way that "if your business value _is_ your codebase,
| it 's hard to build a business whilst literally giving it
| away".
| larodi wrote:
| > "if your business value is your codebase, it's hard to
| build a business whilst literally giving it away".
|
| perhaps then it comes as no surprise that some very
| outspoken open-source proponents do not open-source their
| core business components. I can understand they do it in
| order to exist as a company, as busineses, but I don't
| understand why they have to endure being shamed for
| staying closed-source, while all their stack is open.
| many such companies exist.
|
| and let's add to this all the fact that everything
| released in 2025 as open-source gets slurped by LLMs for
| training. so, essentially, you feed bro's models
| breakfast with your open-source, like it or not. in the
| very near future we'll be able to perhaps prompt a
| 'retell' of Redis which is both the same software, but
| written so that it is not.
|
| in essence there seems to be now little reason to open-
| source anything at all, and particularly if this is a
| core-business logic. open-source if you can outpace
| everybody else (with tech), or else you shouldn't care
| about the revenue.
| palata wrote:
| I agree with the fact that LLMs are big open-source
| laundering machines, and that is a problem.
|
| I mostly see it as a problem for copyleft licences.
| Permissive don't protect the users in the first place,
| so...
| pbronez wrote:
| So who's gonna sue an AI company asserting that all code
| they produce is GPL due to being trained on GPL code?
| palata wrote:
| I feel like nobody cares. It sucks, I know. Like climate
| change, biodiversity loss, the energy crisis.
|
| Feels like we're pretty much screwed. Doesn't mean it's
| not a problem.
| growse wrote:
| How is training a model on GPL code and then having it
| write code any different to having a human read GPL code
| and then write code?
|
| Unless there's a specific copyright claim over a specific
| piece of code that was copied and published, it's hard to
| see how the GPL has any relevance.
| bccdee wrote:
| Because, unlike humans, LLMs reliably reproduce exact
| excerpts from their training data. It's very easy to get
| image generation models to spit out screenshots from
| movies.
| palata wrote:
| I see that argument over and over, and I don't understand
| how people can consider it makes sense.
|
| "My clipboard learned the code, just like a human would.
| So it should be fine to copy-paste anything and call it
| my own".
|
| "How is _killing a human_ any different to _killing a
| computer_? "
|
| "If humans can vote, why couldn't computers vote as
| well?"
|
| Can we start at "humans are not computers", maybe?
| growse wrote:
| > Can we start at "humans are not computers", maybe?
|
| Sure. So it stands to reason that "computers" are not
| bound by human laws. So an LLM that finds a piece of
| copyright data out there on the internet, downloads it,
| and republishes it has not broken any law? It certainly
| can't be prosecuted.
|
| My original point was that copyright protections are
| about (amongst other things) protecting distribution and
| derivative works rights. I'm not seeing a coherent
| argument that feeding a copyrighted work (that you
| obtained legally) into a machine is breaching anyone's
| copyright.
| palata wrote:
| > So an LLM that finds a piece of copyright data out
| there on the internet, downloads it, and republishes it
| has not broken any law?
|
| Are you even trying? A gun that kills a person has not
| broken any law? It certainly can't be prosecuted.
|
| > I'm not seeing a coherent argument that feeding a
| copyrighted work (that you obtained legally) into a
| machine is breaching anyone's copyright.
|
| So you don't see how having an automated blackbox that
| takes copyrighted material as an input and provides a
| competing alternative that can't be proven to come from
| the input goes against the idea of copyright protections?
| motorest wrote:
| > I agree with the fact that LLMs are big open-source
| laundering machines, and that is a problem.
|
| Why do you believe this is a problem? I mean, to believe
| that you first need to believe that having access to the
| source code is somehow a problem.
|
| > I mostly see it as a problem for copyleft licences.
|
| Nonsense.
|
| At most, the problem lies in people ignoring what rights
| a FLOSS license grants to end users, and then feigning
| surprise when end users use their software just as the
| FLOSS license intended.
|
| Also a telltale sign is the fact that these blind
| criticisms single out very precise corporations.
| Apparently they have absolutely no issue if any other
| cloud provider sells managed services. They single out
| AWS but completely ignore the fact that the organization
| behind ValKey includes the likes of Google, Ericsson, and
| even Oracle of all things. Somehow only AWS is the
| problem.
| palata wrote:
| > I mean, to believe that you first need to believe that
| having access to the source code is somehow a problem.
|
| How in the world did you get there from what I said? Open
| source code has a licence that says what the copyright
| owner allows or not. LLMs are laundering machine in the
| sense that they allow anybody to just ignore licences and
| copyright in all code (even proprietary code: if you
| manage to train on the code of Windows without getting
| caught, you're good).
|
| > At most, the problem lies in people ignoring what
| rights a FLOSS license grants to end users
|
| Once it's been used to train an LLM, there is no right
| anymore. The licence, copyright, all that is worthless.
|
| > Also a telltale sign is the fact that these blind
| criticisms [...]
|
| No clue what you are talking about here.
| motorest wrote:
| > LLMs are laundering machine in the sense that they
| allow anybody to just ignore licences and copyright in
| all code (...)
|
| No. Having access to the code does that. You only need a
| single determined engineer to do that. I mean, do you
| believe that until the inception of LLMs the world was
| completely unaware of the whole concept of reverse
| engineering stuff?
|
| > Once it's been used to train an LLM, there is no right
| anymore.
|
| Nonsense. You do not lose your rights to your work just
| because someone used a glorified template engine to write
| something similar. In fact, your whole blend of comment
| conveys a complete lack of experience using LLMs in
| coding applications, because all major assistant coding
| services do enforce copyright filters even when asking
| questions.
| palata wrote:
| > do you believe that until the inception of LLMs the
| world was completely unaware of the whole concept of
| reverse engineering stuff?
|
| The scale makes all the difference! A single determined
| engineer, in their whole life, cannot remotely read all
| the code that goes into the training phase. How in the
| world can you believe it is the same thing?
|
| > Nonsense. You do not lose your rights to your work just
| because [...]
|
| It is only nonsense if you don't try to understand what
| I'm saying. What I am saying is that _if it is impossible
| to prove that the LLM was trained with copyrighted
| material, then the copyright doesn 't matter_.
|
| But maybe your single determined engineer can reverse
| engineer any trained LLM and extract the copyright code
| that was used in the training?
| necovek wrote:
| AI companies have not shied away from slurping anything
| available with complete disregard for the licensing of
| the material.
|
| As such, code available is as much a boon to them as open
| source.
| miki123211 wrote:
| A sufficiently capable LLM might be good enough to do
| cleanroom design on its own, with little to no human
| assistance. That would destroy the entire idea of
| copyright as it exists for software.
|
| You need one agent that can write a complete
| specification of any piece of software, either just by
| using it and inferring how it works, or by reverse
| engineering if not prohibited by the license. You then
| have a lawyer in the middle (human or LLM) review it,
| removing any bits that are copyrighted. You then need
| another agent that can re-implement that spec. You just
| made a perfectly legal clone.
|
| Cleanroom design is a well-established precedent in the
| US, and has been used before, just with teams of humans
| instead of LLMs.
|
| I think some companies will be completely unaffected by
| this, as either the behavior of their code can't easily
| be infered just from API calls, or because their value
| actually lies in users / data / business relationships,
| not the code directly. Stripe would be my go-to example,
| you can't just reverse-engineer all their optimizations
| and antifraud models just by getting a developer API key
| and calling their API endpoints. They also have a lot of
| relationships with banks and other institutions, which
| are arguably just as important to their business as their
| code. Instagram, Uber or Amazon also fall into this
| bucket somewhat.
| palata wrote:
| > This risk has always existed.
|
| Doesn't mean it was not a problem.
| growse wrote:
| The solution to the old problem of "what if someone uses
| my code to compete with me" is "don't open source your
| code".
|
| This isn't complicated. It's trade secrets 101.
|
| I'm being disingenuous though. Of course the bait-and-
| switch merchants know this, they're just banking on
| getting enough product momentum off the free labour of
| others before they cash in. That's the plan all along.
| plufz wrote:
| I think that is a little unfair. I don't know anything
| about the companies behind Redis and Elastic. But another
| possibility is that they want to make a good open source
| product and create some sort of business around it and
| find it difficult to make a waterproof moat. I'm sure
| that there are many other open source companies with the
| same basic strategy that are just more lucky, e.g. don't
| get AWS as competition.
| vin047 wrote:
| This is exactly what the AGPL was made to combat against.
| But open source devs still choose more permissive
| licenses first - presumably to attract corporate clients
| to use their product (and because devs are suckers to
| large corporate interests)
| palata wrote:
| This. They choose a permissive licence, proudly advertise
| it ("use us instead of our competitor because they are
| copyleft and we are not"), and then come whining when
| other competitors benefit from the very fact that they
| chose a permissive licence.
| _msw_ wrote:
| There are different FOSS communities that hold different
| values. I come from the copyleft camp because I want to
| advance Software Freedom objectives for end-users. Others
| are more interested in advancing software developer
| freedom, and they find the obligations that are designed
| to advance end-user rights are unduly burdensome to the
| software developer. Articles like the one on the FreeBSD
| website [1] explain why they take a different position
|
| I choose to believe that both of these sub-communities of
| the larger FOSS community are principled in their
| beliefs. I don't see whining from FreeBSD folks about
| competitors, or for-profit companies using all the
| permissions they give with their choice of license.
|
| [1] https://docs.freebsd.org/en/articles/bsdl-gpl/
| palata wrote:
| > I don't see whining from FreeBSD folks about
| competitors
|
| Sure! Then that's all good! I have nothing against the
| use of permissive licences (though I am on the copyleft
| camp too, obviously). Or put it in the public domain.
|
| My problem is with those who do _and then_ whine about
| it.
| 7952 wrote:
| Do AWS really sell things at a loss?
| redditor98654 wrote:
| Not really. I have done multiple AWS pricing and costing
| exercises while launching services and there was never a
| direction from the VP to sell it lower than what it costs
| to build and operate. Cost to build and operate includes
| everything from salaries, infrastructure and many other
| line items. And usually things are projected 3-5 years
| into the future and P&L analysis must show that
| eventually the service will make a profit. It does make
| some assumptions about minimum customer adoption for the
| profit margins to materialize which eventually becomes
| part of the product and sales teams goals.
|
| The costing model does allow losses to be incurred in the
| initial years because building the thing is more
| expensive at first but then it should settle down and
| revenue should outpace expenses.
|
| What can happen with these open source products being
| launched as a service is that that initial cost can be
| cut down by as much as 50-75% but rarely more than that
| because you still need to build all the surrounding
| infrastructure, documentation, UI. It still gives AWS an
| advantage by relying on an existing body of work they can
| start with where many problems have been thought through
| and solved. Also you will likely get a good product
| roadmap skeleton ready to be prioritized which otherwise
| can be a huge time sink.
|
| In a nutshell, no. AWS won't sell a service at a loss
| (there are exceptions of course) but there is room to
| incur a loss at the beginning but it is priced to
| eventually turn a profit. Whether that happens for every
| service in reality is a different story.
| immibis wrote:
| No - that's why their pricing is so detailed and why
| their services have few limits you can't request them to
| increase.
|
| They can afford to maintain a better branch of Elastic
| Search or Redis or so on, an drive those companies out of
| business by the virtue of efficient free market
| competition. At which point they'll make sure their
| branch is _only_ useful on their servers, perhaps by
| adding dependencies on all their internal microservices -
| so technically they released the code but you can only
| run it if you 're Amazon.
| flaminHotSpeedo wrote:
| > At which point they'll make sure their branch is only
| useful on their server
|
| Can you think of any examples where they've done that?
| They certainly could, but I can't think of any times they
| have actually rug-pulled like that, and the motive to do
| so seems tenuous too. In order for Amazon to do something
| like this they would need established market dominance,
| as well as a belief that some new player will hurt their
| market share enough to justify alienating the FOSS
| community.
| palata wrote:
| Given what Amazon routinely does, this doesn't seem crazy
| at all. Just look at one of their countless anti-
| competitive behaviours.
| palata wrote:
| Sorry, I didn't want to imply that they do. This would be
| illegal as per antitrust regulations.
|
| What I wanted to say is that AWS using a permissively-
| licenced project is fine. The project should have thought
| about the licence beforehand and started with copyleft
| from the beginning on. Their problem now.
|
| But a more general problem I see is that even if you use
| a copyleft license for your project, you have the risk to
| be crushed by anti-competitive behaviours coming from
| TooBigTech. It's not rare, they do that all the time and
| the US doesn't enforce anything. And when others (like
| the EU) try to do it, the US put pressure because they
| defend their US TooBigTech.
|
| The latter is not a model or licencing issue, it's an
| antitrust issue. Now Amazon could compete with Redis
| without doing it illegaly, but they can only because they
| are so big. And the fact that they are so big is related
| to the lack of antitrust enforcement (it's documented,
| TooBigTech have all abused their dominance forever).
| motorest wrote:
| > The problem here is that Amazon is in a position where
| they can fork and sell it for a loss in order to crush
| the competition.
|
| Everyone can fork any FLOSS project. That's by design.
| There are also no restrictions on random people selling
| services directly or indirectly using said FLOSS
| projects.
|
| If a corporation changes their mind and decide it was a
| mistake for them to release software as FLOSS, they have
| the right to do what Redis just did. What they can't do
| is feign ignorance or do a bait-and-switch to try to
| coerce their userbase to cough up licensing fees for
| FLOSS projects.
| palata wrote:
| > Everyone can fork any FLOSS project
|
| But everyone is not in a position where they can put a
| ton of resources into a project in order to crush the
| competition and maintain their monopoly.
|
| Which is why I said that the problem is the fact that
| Amazon is in this position, not the licence.
| motorest wrote:
| > On principal I will not use the Amazon fork, because I
| don't want to support a company that would prefer to fork a
| project rather than fork over some cash.
|
| That's specious reasoning at best.
|
| The whole point of FLOSS is that anyone is free to use it
| how they see fit. Whether it's a hobbyist doing a pet
| project or a FANG using it as their core infrastructure,
| they are granted the right to use it how they see fit.
|
| That's exactly why they started to use it to begin with.
| Isn't it?
|
| When a random corporation decides to pull the rug on the
| established user base expecting to profit from the pain of
| migrating existing services, it is not the user base who is
| the bad actor.
| atombender wrote:
| NATS almost ended up doing it recently, too. Fortunately they
| caved in just today, after the CNCF and the community
| protested. [1] While the outcome is great, it was a bunch of
| drama for nothing, and their reputation has been harmed.
|
| [1] https://news.ycombinator.com/item?id=43863721
| PeterZaitsev wrote:
| Yep. Actually if Redis would end up in CNCF and Redis Labs
| could provide commercial hosting, extensions - this would
| be outcome I would be excited about
| golergka wrote:
| > Neither company has built in a legal safety mechanism to
| prevent themselves from pulling the rug again later
|
| Previous versions are still available under the original
| license, right? So if you don't want to use it with a new
| license, you're in the same situation as if company went out
| of business or stopped support and development for any other
| reason. There are no safety mechanisms for that either.
| palata wrote:
| An existing safety mechanism is to do exactly what Linux
| does: have a copyleft licence and no CLA. So that the
| copyright is shared between the contributors (so it's
| impossible to change the licence) and the licence enforces
| sharing your changes of the project.
| immibis wrote:
| The legal safety mechanism is the license. They gave you
| software under a certain license and you're in the clear as
| long as you follow it. You don't have to delete it if they
| give different software under a different license.
|
| If you do need constant updates, you may trust forks more not
| to switch license, but forks tend to disappear at about the
| same rate that originals switch license, so why does it
| matter? Such is the nature of relying on free stuff - you're
| at the mercy of the one who hands it out.
| bobsoap wrote:
| I agree. That ship has sailed, at least for the foreseeable
| future. We switched to Valkey and it's our choice for a couple
| upcoming projects as well. To switch back now after this whole
| ordeal would make no sense at all.
| tasuki wrote:
| > contributed a minor improvement to Redis under its original
| license [...] feeling betrayed as a contributor to a properly-
| FOSS-codebase
|
| How does this work legally? You write some code, contribute it
| under a certain license... and... a company can just re-license
| your code under any license they like?
| lolinder wrote:
| They require a Contributor License Agreement [0] whereby you
| grant them the copyright to your contribution. Which means
| they become the ultimate decision-maker for all contributions
| and can relicense however and whenever they wish.
|
| [0] https://redis.io/legal/redis-software-grant-and-
| contributor-...
| colordrops wrote:
| A contributor license agreement that does anything besides
| put your code under the project's standard OSS license is a
| huge red flag.
| assassinator42 wrote:
| I took a bit of umbrage with LineageOS for this.
|
| CyanogenMod required a CLA to assign them copyright to
| Cyanogen Inc, only for them to basically kill the
| project. They forked it as LineageOS only to still
| require a CLA.
| porker wrote:
| IMO the anger people direct at source available licences
| would be better directed at CLAs. They're what hands the
| power away.
|
| Don't contribute to projects with CLAs people without
| reading them carefully and understanding what can happen!
| Then you won't be surprised if a project is relicensed
| because you know you signed an agreement to let them do
| that.
| tasuki wrote:
| Mhm, so all the contributors to Redis ever have signed the
| Contributor License Agreement? It's certainly possible, but
| I'd be a little surprised.
| andix wrote:
| If you contributed before the license change/fork, you've also
| contributed to valkey and redict ;)
| gigatexal wrote:
| I get the feeling. I also live in the real world and know that
| nobody except for a few (most notably RedHat) have figured out
| how to make sustainable money in open source. These closed
| licenses didn't come out of nowhere. They came in response to
| places like AWS using the open source license to make a mint
| with a project -- and doing so legally (it's there in the
| license to do so) -- but then the project suffers. So the
| license change is done to prevent that so the project --
| ostensibly -- can survive. It makes sense. And so does wanting
| to live up to the promises of open source. It's a tough
| situation for sure.
| jeswin wrote:
| If anyone betrayed the spirit of Open Source, it is those who
| were trying to siphon off the entire commericial value of these
| projects while contributing little back to the project.
|
| Companies have to pay people to work on it. Hell, they are even
| entitled to profit from it. A world with commerically viable
| Open Source is way better than without it. Ditching OSS
| companies for trying to survive 90% of revenues going to $1T
| cloud vendors is counter productive.
| maxloh wrote:
| I am wondering why did you choose Redict over Valkey? The
| latter seems to be more popular.
| microflash wrote:
| Due to license rug pull, I started an org wide movement from
| Redis to Valkey early this year and now there's no turning
| back. It also does not help Redis that Valkey is cheaper
| offering by AWS (at least through Elasticache).
| Snakes3727 wrote:
| I contributed heavily to a project during its early days and
| spent almost 2.5 years helping it grow. For awhile i was one of
| the most active contributors.
|
| Then there was talk of turning the project into an actual
| business, and myself and a few of the original contributers
| were offered extremely poor paying jobs. That no one took. Then
| they got a CEO, investors and we were basically forced out of
| the project unless we joined the company.
|
| I distinctly remember being in a call where we were told they
| would be relicensing it eventually and launching a SaaS. To
| protect our work from being used by large companies. I laughed
| and pointed out the irony in that call that you were doing the
| same thing.
|
| After that they changed their policy such they do not accept
| outside PR's. It has killed any interest in supporting open
| source projects outside personal stuff.
| jjmarr wrote:
| If you're the most active contributor, you could've just
| forked it yourself, launched it as a SaaS, and been the CEO.
| your_challenger wrote:
| Not everyone wants to be a CEO. Some people just wanna
| write some good code and contribute to the world.
| Snakes3727 wrote:
| I just wanted to make a tool to help developers. Then when
| the SaaS launched they instead focused on adding $$$
| features instead of fixing bugs, and started heavily
| pushing their SaaS anytime you used the tool.
|
| They ended up switching to a terrible model with a previous
| release where if you were a business or in anyway making
| money you now needed to pay for licenses and it was
| comically expensive.
|
| The reality is I could have forked it but I don't have the
| time and patience to deal with everything that comes from a
| massive project.
| jamespo wrote:
| Come on, at least give us a hint what it is!
| _nalply wrote:
| Yes because "pics or it didn't happen"
| MYEUHD wrote:
| Did you sign a Contributor License Agreement? If not, then
| I'm pretty sure it's illegal to keep your changes while
| relicensing, without obtaining your consent.
| NetOpWibby wrote:
| It's a bold strategy, let's see if it works out for them.
|
| https://www.youtube.com/watch?v=9HVejEB5uVk
| xiphias2 wrote:
| ,,for companies rooted in open source, it has posed a fundamental
| challenge: how do you keep innovating and investing in OSS
| projects when cloud providers reap the profits and control the
| infrastructure without proportional contributions back to the
| projects that they exploit?''
|
| I don't see any exploitation happening. As DHH said, the main
| reason engineers open source their work is to give a gift to the
| world.
| immibis wrote:
| Open source is a gift to everyone (including Jeffrey Bezos);
| free software is a sharing economy. The difference is whether
| the sharing is reciprocal. With open source it's a one way gift
| from you to Jeffrey. He could have paid you for that. At the
| very least you can make him pay with reciprocal sharing.
| jraph wrote:
| I think you are not describing the difference between open
| source and free software but the difference between copyleft
| and permissive license.
|
| Open source and free software licenses are basically the same
| (there are a few exceptions). For me, the difference is the
| focus. Free software cares about user freedom first.
| immibis wrote:
| User freedom means not giving someone else the freedom to
| take away user freedom though, which is what doormat licenses
| (can we call them cuck licenses or is that too far for HN?)
| do.
| jraph wrote:
| > User freedom means not giving someone else the freedom to
| take away user freedom though
|
| This sentence does a shortcut that's worth expanding on,
| because it can give the impression that permissive licenses
| don't respect user rights, and because it doesn't cleanly
| apply to every situations.
|
| User freedom is full with a permissive license. If I get
| software under MIT, my freedom is fully respected.
|
| But it is true that forcing downstream developers to
| respect the freedom of their users through copyleft
| licenses is one of the strategies to improve user freedom
| overall (Personally, that's why I prefer the (A)GPL - I'm
| not keen on helping).
|
| There still are some situations where you might be better
| off using a more permissive license, when your code is
| small enough or would strongly benefit from the network
| effect, for instance if it's a codec, or if there already
| are alternatives that proprietary software can use [1,2].
|
| [1] https://www.gnu.org/licenses/license-
| recommendations.html
|
| [2] https://www.gnu.org/licenses/why-not-lgpl.html
| immibis wrote:
| That is true. I'm talking general purpose. If you're
| putting something you made on the internet, and there's a
| good chance it's useful to someone, I recommend AGPL
| unless you have a specific argument against it. Also
| notice that it's easier to grant more permission than to
| take it away.
| jraph wrote:
| I completely agree with you there.
| liviux wrote:
| Wishing all real-open-source projects best of luck, including
| valkey, OpenTofu and so on. These are my clear first choice!
| DetroitThrow wrote:
| Copyleft does not mean fake-open-source, I'd not consider Linux
| fake-open-source for example. Though plenty of reason to use
| permissive licenses instead of copyleft and vice versa
| depending on your situation.
| immibis wrote:
| Copyleft is Free Software, free as in freedom. Pushover
| licenses (such as MIT) are working for free for Amazon, Google
| and Oracle. Which is fine if your boss is paying you money to
| work for free for Amazon, Google and Oracle - it's their money.
| If it's your own spare time, you might not like it as much.
| infogulch wrote:
| Congrats antirez! I'm sure this was a huge effort internally, and
| I hope the Redis team can be successful releasing software under
| SSPL+AGPL.
| mmaunder wrote:
| Here's the play: Open source with AGPL, then offer an enterprise
| license. You get two wins. The OSS community applauds your
| adoption of an agressive OSS license. Enterprise customers can't
| use software under AGPL because it risks infecting their IP, so
| they're forced to buy an enterprise license.
| Zambyte wrote:
| s/can't/choose not to/ s/'re forced to//
| matesz wrote:
| Wait, AGPL is a good license for enterprise, they don't need to
| buy unless they want to modify source without releasing, am I
| wrong about this?
|
| Edit: Doubled checked with gpt, no cases of "infection" yet,
| there has also been many talks about this license being very
| good
| umbra07 wrote:
| the alternative is/was BSD.
|
| enterprise hates AGPL. AGPL is generally not a serious
| alternative to BSD/MIT in corpoland, because something
| something (A)GPL-poisoning.
|
| whether it's true or not doesn't matter. what matters is
| whether big tech considers AGPL infectious - which they do.
| jenadine wrote:
| > whether it's true or not doesn't matter
|
| It matters a lot. A company could potentially make choice
| that saves them a lot of money, so they better base their
| decisions on accurate information rather than rumours.
|
| (Note also that big tech have different incentives)
| immibis wrote:
| The goal of free software (noting that "open source" is a
| watered down version of "free software") is for everyone to
| share their sohrce code. To that end, licenses that require
| sharing of source code are used. LGPL says, roughly, you must
| share the source code of this software to anyone you shared
| the binary to. GPL is more extensive: anyone you shared the
| binary or the binary of something built on this software to.
| AGPL is even more aggressive: anyone you shared it to or gave
| access to it over a network. And SSPL is currently the most
| aggressive: you have to share the whole thing you built, not
| just what's linked with this software.
|
| The more aggressive a license you pick, the more likely a
| corporation won't want to use it. But that's by design.
| They're allowed to use it, even commercially - they just have
| to give the source code back. If the software is useful
| enough, they will. We should make software useful enough for
| corporations to consider the be benefits of using it to
| outweigh the cost of having to share their source code. (Also
| the more source you make them share, the less likely this is.
| The Linux kernel succeeded at this.
|
| SSPL is controversial and untested (and goes against the
| business interests of the OSI so will never be box-tick
| certified compliant) and likely counterproductive if it means
| you have to share things like Windows. AGPL is the normal
| "aggressively free" license. GPL is mostly for those who
| haven't discovered AGPL yet and MIT is for those who don't
| agree in the goal of source code freedom to begin with.
| kstrauser wrote:
| SSPL isn't recognized as either open source or free
| software. I don't think it earns being discussed in the
| same context.
| umbra07 wrote:
| only because OSI says so. I don't agree with the idea of
| OSI defining my philosophical positions and technical
| terms for me, just like I don't agree with the BSD people
| excluding GPL from the definition of open source.
| yjftsjthsd-h wrote:
| I'm sympathetic to the OSI not being the only authority.
| So, have the DFSG, FSF, any BSD, or _literally anyone
| credible_ endorsed it as Free and /or Open Source?
| pabs3 wrote:
| None of the folks you list have, only other FOSS-adjacent
| movements like Fair Source etc.
| immibis wrote:
| None of them have bothered to evaluate it or have
| explicitly decided it's not worth evaluating for now.
| They haven't endorsed it as Proprietary and/or Closed
| Source either.
|
| And notice the OSI's objection actually makes no sense
| and could apply to any copyleft license! By the same
| reasoning, AGPL isn't open source. Yet they say it is.
| yjftsjthsd-h wrote:
| > None of them have bothered to evaluate it or have
| explicitly decided it's not worth evaluating for now.
| They haven't endorsed it as Proprietary and/or Closed
| Source either.
|
| That's not quite true. Per
| https://en.wikipedia.org/wiki/Server_Side_Public_License
| , Debian _did_ explicitly reject it (in addition to
| listing OSI and Red Hat likewise), citing https://web.arc
| hive.org/web/20240226231216/https://bugs.debi... -
| However, the SSPL is clearly not in the sprit of the
| DFSG, yet alone complimentary to the Debian's goals
| of promoting software or user freedom.
| In light of this, the Project does not consider that
| software licensed under the SSPL to be suitable for
| inclusion in the Debian archive.
| bananapub wrote:
| > Edit: Doubled checked with gpt, no cases of "infection"
| yet, there has also been many talks about this license being
| very good
|
| what? why would you ask an LLM to generate some random text
| instead of looking up the actual answer?
| cdelsolar wrote:
| Hi, it's the year 2025
| doctoboggan wrote:
| I think you are thinking of GPL. Many companies are happy to
| use AGPL licensed software in their stack.
| kstrauser wrote:
| I think you're thinking of the LGPL. The AGPL is basically
| GPL plus some additional requirements. I could see a company
| being OK with ~AGPL~ GPL but not ~GPL~ AGPL. I can't imagine
| the opposite.
|
| Edit: Oops, typoed the license names.
| mindB wrote:
| I think you have a typo mixing up AGPL and GPL. I agree
| that it would be hard to imagine a company being okay with
| the AGPL but not the GPL. On the off-chance that it isn't a
| typo, could you explain why a company might be okay with
| AGPL but not GPL?
| kstrauser wrote:
| Oops, you're right. Yes. I could see them approving the
| GPL but not the AGPL. I can't imagine any company
| approving the AGPL but not the GPL.
| kstrauser wrote:
| > Enterprise customers can't use software under AGPL because it
| risks infecting their IP
|
| This is factually untrue. If you want to link an AGPL blob into
| your app and ship it to customers, sure. In the vastly more
| common case where you're using a permissive client library[0]
| to connect to an AGPL server, there's no risk whatsoever.
|
| At most, you might need to make your local changes to that
| server available to clients if they connect to it directly, as
| opposed to hosting a cloud SaaS setup where everything is
| internal to you. However, that's not the worst thing in the
| world. "Oh no, we improved a Free server our company depends
| on, and we have to share those improvements so that the person
| who gave us the server for free can also benefit from them" is
| pretty hard for me to sympathize with.
|
| This is vastly more business-friendly than the non-FOSS SSPL.
|
| [0]https://github.com/redis-rb/redis-
| client/blob/master/LICENSE...
| mperham wrote:
| > Enterprise customers can't use software under AGPL because it
| risks infecting their IP
|
| Yeah, this is BS.
|
| If you simply use AGPL software, it doesn't "infect" anything.
| If you *change* the AGPL software, you have to release the
| changes. It forces the big clouds to open source their Redis
| improvements.
| okanat wrote:
| For the type of software that Redis is intended for,
| integration over network is a must. Hence "just using it"
| isn't a viable option. AGPL isn't LGPL, it infects anything
| that uses it over a network. If Redis was AGPL when it was
| released, nobody would touch it.
|
| Most of the readers of HN make their living from closed
| source software. You know well enough that non-hostile open
| source is just a market entry strategy and the type of
| copyright-driven maximally selfish capitalist markets just
| force open source to be not viable for a single company to
| thrive. Projects like Linux kernel are exceptional
| infrastructure projects that external companies support not
| build businesses just to ship.
| kstrauser wrote:
| > Hence "just using it" isn't a viable option. AGPL isn't
| LGPL, it infects anything that uses it over a network.
|
| This is completely, factually, unequivocally, incorrect.
|
| You can connect to Redis using their first-party, MIT-
| licensed client library. You can write proprietary software
| using that library with no requirement whatsoever to
| release your software under any particular license
| (although of course you still have to comply with the MIT
| license's attribution requirements).
|
| If all software connecting to the AGPL'd service runs
| internally, you're not obligated to share your local
| changes to that service. This covers the vast majority of
| use cases. Using WordPress with a Redis cache? This doesn't
| affect you.
|
| If you host an AGPL'd version of a Redis server and your
| customers connect to it from their own networks, then the
| only obligation you have over the tried-and-true GPL is
| that you have to share changes you've made _to your Redis
| server_ with users. If you use Redis packages as-is like
| almost everyone does, this doesn 't affect you.
|
| So literally the only people who have to care about Redis
| being under the AGPL now are those who don't want to pay
| Redis for a commercial license, who expose their Redis
| server to customers, and who've made local changes to their
| Redis server. Everyone else gets to keep using it like they
| always had.
| cdelsolar wrote:
| It's amazing how much FUD there is over GPL/AGPL. I've
| seen at least 10 posts on this thread saying you have to
| open source your commercial software if you use the new
| Redis. I don't know how there could be such a fundamental
| misunderstanding of one of the most common software
| licenses out there.
| PeterZaitsev wrote:
| If you USE Redis, you do not have to if you Embed Redis
| you do. Same with GPL
| kstrauser wrote:
| I know, right? Corpos have done a great job convincing
| devs of the "dangers" of copyleft licenses, in favor of
| permissive licenses that purely coincidentally just
| happen to benefit those commercial users.
| Orygin wrote:
| Even users of APGL sometimes are clueless about its
| reach. One example is minio which is AGPL now, and the
| dev regularly make false statements about the license on
| their github: https://github.com/minio/minio/issues/13308
| #issuecomment-929...
| kstrauser wrote:
| That's just embarrassing. Stop that, guy.
| threatofrain wrote:
| Notably, Redis is about to sue Dragonfly for deliberate trademark
| confusion.
| tiffanyh wrote:
| While I applaud the effort to repair developer trust, do note
| that many organizations prohibit the use of AGPL.
|
| Linked below is Google's own stance on why AGPL is banned:
|
| https://opensource.google/documentation/reference/using/agpl...
| _msw_ wrote:
| My personal opinion: we shouldn't let Google's bad policy
| poison our brains. The people who wrote that policy had their
| reasons for taking this position. It might have been the right
| thing for Google at the time the policy was written.
|
| That doesn't mean it's the right position for you, or for every
| situation. Many organizations with a higher levels of maturity
| in open source matters will take a more nuanced approach when
| it comes to AGPLv3 licensed software.
| jraph wrote:
| Their loss, at some point...
|
| I'm quite fed up with this GAFAM FUD against the AGPL and the
| GPLv3.
| vvillena wrote:
| That's the license working as intended, isn't it?
| WD-42 wrote:
| So a hyperscaler bans the AGPL? Shocking. Seems to be working
| as intended.
| DetroitThrow wrote:
| I think the big drop in trust was the change in licensing away
| from permissive in the first place, but AGPL-today is a much
| better choice than SSPL-forever.
|
| You probably can't recover from a loss of trust in low single
| digit years unfortunately, but this is a good first step towards
| the project rebuilding the OSS community that existed around
| redis initially.
|
| Thanks for fighting for this. Hopefully this shows more companies
| stuck on source-available that you can achieve similar goals with
| OSS licenses.
| ibnurasikh wrote:
| Gladly, Valkey has other benefits besides its more permissive
| license compared to Redis. One of them is multi-threading
| support, which makes it pretty easy for someone like me--who has
| a bit of a skill issue with DevOps--to actually utilize all CPU
| cores for my caching layer.
| antirez wrote:
| The I/O threading was initially implemented by myself, when I
| was still working on the core before rejoining, and is also
| available in Redis. So this is actually another case of the
| benefits ValKey got for being able to clone Redis, receiving
| money from the hyper-scalers that just want to maximize their
| revenues...
|
| They made certain improvements later, but Redis 8 (see the
| release notes in my blog post if you are curious) improved this
| stuff a lot, too.
|
| Also, Redis 8 contains a new data structure, Vector Sets, that
| allows to do many useful things, together with more
| probabilistic data structures, single hash fields expires, and
| many other stuff. It is not factually correct that ValKey has
| any features edge over Redis I believe. We will see in the next
| year which project takes the best development path: this is
| what really matters.
| reconditerose wrote:
| The Valkey implementation of multi-threading is fundamentally
| different than what existed in Redis. The history dates back
| to work done in ElastiCache that was released as "Enhanced
| IO", https://aws.amazon.com/about-aws/whats-
| new/2019/03/amazon-el.... The version released in Redis could
| only do about 350k RPS because of poor memory locality of
| operations, the inability to do command processing while
| handling I/O, and the inability to offload much of the TCP
| read path. The new version in Valkey can achieve 1.2M RPS.
|
| "They made certain improvements later", should be "we threw
| away the old implementation and built a better one."
| antirez wrote:
| 1. The fundamental idea was mine. Ideas can be improved, of
| course, and that's good. That was my point. However, allow
| me to say that Redis is fundamentally a "software of ideas"
| than anything else. Technologically it is far from
| impressive (Redis, ValKey, all the forks).
|
| 2. Redis 8 improves the same idea, too, released today.
|
| 3. If you claim [in a different comment here] you provided
| a lot of code to Redis, why you didn't send a pull request
| for that? So, you are practically saying you were using, at
| Amazon, all the BSD code we provided, but could not provide
| an important part of the code to us? You see how broken
| such model was? At least stop defending it.
|
| 4. We can now copy the implementation: the parts are
| reversed (the irony!), and your code is BSD as our was for
| 15 years. When we avoid doing things like that, is because
| we have issues with how certain things were made.
|
| 5. I don't understand the motivations of you and other AWS
| people commenting here today. You work for a company that
| is creating issues to the OSS ecosystem: this is hard to
| deny. You cloned (and, yes, the license allowed for it) the
| code of Redis, and work on it so that hyperscalers can
| continued to do what they used to do. We bring Redis back
| to AGPL, and you are here to do the interests of Amazon in
| the comments. Did you see me commenting your stuff, when
| you release your things, with comments like "ah! But this
| is unfair"?
|
| There is to make choices. I understand that it was cool to
| continue to work at a Redis fork, and part of the
| incredible thing open source is, is that forks survive in
| the hands of different teams (but design ideas can be
| misunderstood and projects may turn into other projects).
| So if you are happy to hack on ValKey, I hope you'll have
| the best experience out of it. But there is to make choices
| on how/when to interact.
| _msw_ wrote:
| This exchange makes me sad. I know we can do better.
|
| I don't understand why so many people think that it's
| impossible to have open source in your heart while
| working for a big company in your day job. I don't
| understand why people who have dedicated a lot of their
| time and emotional energy to keep open source ways alive
| and help build a community effort are attacked because
| they work for a company that needs to be made the villain
| in the narrative.
|
| Of course Redis is free to copy BSD licensed code that
| Valkey contributors add to the project [1]. I only wish
| that the blog post about this advancement in Redis would
| give some credit, rather than claiming "We also improved
| the performance of CRC64 calculations" [2].
|
| We can all do better, and engage with one another with
| mutual respect and admiration for what has been freely
| given.
|
| [1] https://github.com/redis/redis/pull/13638
|
| [2] https://redis.io/blog/redis-8-0-m03-is-out-even-more-
| perform...
| crop_rotation wrote:
| Do you really want to know?
|
| > I don't understand why so many people think that it's
| impossible to have open source in your heart while
| working for a big company in your day job.
|
| Because a big company like Amazon has produced almost no
| open source work(yes some random collection of repos and
| 2 PRs here and there is not the same thing) compared to
| how much it has benefited from open source. (I know I
| know OSS allows for all that so not claiming anything
| wrong). But it does show what the company policy must be
| towards open source (Consume all you can, contribute only
| when absolutely essential for the company barring
| exceptional circumstances).
|
| > I don't understand why people who have dedicated a lot
| of their time and emotional energy to keep open source
| ways alive and help build a community effort are attacked
| because they work for a company that needs to be made the
| villain in the narrative.
|
| Antirez is not attacking anyone above. English is not his
| first language and he is just putting out some of his
| thoughts (which people are free to disagree with but
| those are what he thinks), like how you casually slipped
| that you didn't get credit for one commit copied from
| valkey (where the copier is giving due credit in the PR
| by linking the source PR and the authors inline). So they
| copied a PR from valkey, and the redis blog post should
| give lots and lots of credits? If that was the standard,
| so many of AWS services will spend all their reinvent
| time giving credits to their source OSS projects.
| _msw_ wrote:
| > Because a big company like Amazon has produced almost
| no open source work
|
| This may have been true a decade ago, but things are
| quite different now.
|
| > compared to how much it has benefited from open source.
|
| This is the nature of digital public goods. We are all
| going to disproportionately benefit from digital public
| goods relative to what can be produced as new digital
| public goods. No one will ever, EVER be able to
| "contribute proportionately" given the endless bounty of
| software made freely available for all to use.
|
| > If that was the standard, so many of AWS services will
| spend all their reinvent time giving credits to their
| source OSS projects.
|
| The observant should notice a change in this over the
| years. For example, the announcement for Amazon Q Code
| Transformation [1] acknowledged that OpenRewrite was used
| under the covers, even though it was an implementation
| detail that didn't have to be disclosed...
|
| Of course these disclosures and good-faith intentions to
| engage on open-source community terms under long-
| established community norms don't always work out the way
| we hope. [2]
|
| [1] https://aws.amazon.com/blogs/aws/upgrade-your-java-
| applicati...
|
| [2] https://github.com/spring-projects/spring-
| tools/issues/1443
| blibble wrote:
| > No one will ever, EVER be able to "contribute
| proportionately" given the endless bounty of software
| made freely available for all to use.
|
| so it sounds like we need a license mechanism that
| enforces this, fairly, based on potential ability to
| contribute
|
| idea: a benchmark to give a required level of
| contributions, maybe a logistic function of revenue
| generated/company size and time since initial usage
|
| and if you fall beneath it, your license is terminated
|
| carefully calibrated such that a burden is only placed on
| very large companies
| theamk wrote:
| Just make it closed source (or source-available) and give
| out no-cost licenses how you see fit. You are the author,
| you decide what to do with your code. This is a well-
| supported model too, plenty of products are like that.
|
| There are plenty of licenses around, lack of alternatives
| isn't why people use MIT or Apache.
| jimbokun wrote:
| > I don't understand why so many people think that it's
| impossible to have open source in your heart while
| working for a big company in your day job.
|
| The employment contract you signed.
| reconditerose wrote:
| > So, you are practically saying you were using, at
| Amazon, all the BSD code we provided, provide an
| important part of the code to us? You see how broken such
| model was? At least stop defending it.
|
| I'm not defending it, I'm trying to fix it. I want Amazon
| to contribute back. That's what I spend most of my time
| doing, but I can't just sit in a meeting and tell people
| we should give away code. It takes time to convince
| people that we should collaborate on the core and just
| compete on what we want to differentiate on. It takes
| time to convince people that building open-source in a
| vendor neutral space makes software that is better for
| everyone.
|
| I hope that makes sense.
| antirez wrote:
| Yes, makes sense. Thanks for the reply.
| _Wintermute wrote:
| This comment has inspired me to switch to Valkey, thanks.
| antirez wrote:
| You have all the rights. Usually I do my best to avoid
| confrontations of that kind, and to respect the work of
| others. But I see certain communication patterns that
| are, for me, too much, and I needed to tell it. I think
| go on HN, and comment in an aggressive way the work of
| competitors, during announcements days, is something
| fundamentally wrong.
| crop_rotation wrote:
| On the contrary it has made me appreciate antirez even
| more not just as a developer but as a true champion of
| open source who really wants open source to prosper and
| is willing to voice his opinions whenever required.
| yjftsjthsd-h wrote:
| > So this is actually another case of the benefits ValKey got
| for being able to clone Redis, receiving money from the
| hyper-scalers that just want to maximize their revenues...
|
| I don't think you want to sling that mud, unless Redis
| switched to being a nonprofit when I wasn't looking.
| WD-42 wrote:
| They aren't really comparable and you know that.
| yjftsjthsd-h wrote:
| They are and you shouldn't claim bad faith without _very_
| good reason.
| StreamingPanda wrote:
| lmao they absolutely are
| blotfaba wrote:
| Hashtag #ThankYouValkey?
| md3911027514 wrote:
| https://redis.io/blog/redis-license-bsd-will-remain-bsd/
| Zambyte wrote:
| Very interesting that this is happening at the same time that
| NATS is going proprietary. Obviously Redis is way more well
| known, but as someone who has built a bunch on NATS over the last
| few years, this makes Redis an interesting choice to migrate to
| again.
| nchmy wrote:
| apparently synadia is working with the linux foundation now to
| find a better way forward, and will release a joint statement
| soon. (CEO mentioned in their slack)
| Zambyte wrote:
| Cool, I'm definitely hoping for a sensible outcome. NATS has
| been a great tool to work with, and Synadia has also been
| great to work with.
| kermatt wrote:
| https://www.cncf.io/announcements/2025/05/01/cncf-and-
| synadi...
| williamstein wrote:
| Context:
|
| - https://news.ycombinator.com/item?id=43829008
|
| - https://github.com/cncf/toc/issues/1632
|
| - https://github.com/nats-io/nats-server/issues/6832
|
| I also built a lot on NATS Jetstream, and I'm questioning my
| decision in light of the threatened license change.
| snotreal wrote:
| Why? Have you actually ready Synadia's comments where they
| made it clear that they always intended to maintain the
| Apache 2 Version by contributing the stuff they build back to
| the main repo? It just won't be as fast, so they can make
| some money first which will fund them giving it away.
|
| You said "I also built a lot" Are you making money off those
| projects or get paid for your services for that use?
| captn3m0 wrote:
| - 8.0 - Tri-licensed under RSALv2/SSPLv1/AGPLv3
|
| - 7.4 - Dual licensed under RSALv2/SSPLv1
|
| - 7.2 and earlier - 3BSD
| zoogeny wrote:
| I am starting a new web app project and I wanted an in-memory
| store for session data. I just defaulted to Redis, literally
| yesterday doing the `npm install`.
|
| I mean, I remembered the whole Valkey saga after the license
| switch. I guess I'm just not as ideological as some here? I just
| thought "I need a fast in memory object store" and went with
| Redis as my default. I treat it like an appliance within my
| infrastructure.
|
| I also vaguely recall antirez going back to Redis (the company)
| during the AI boom to work on vector extensions to Redis. I
| believe he is a big part of why Redis is such a rock-solid piece
| of tech. I am more confident in this product with him influencing
| the trajectory.
|
| I also have the decision on license in the back of my mind. As I
| said, I am not an OSS zealot, but I do like the idea of an OSS
| license that has some protection against someone completely
| ripping off the code with no recourse. AGPL might be a decent
| compromise, especially with a dual license.
| immibis wrote:
| Flagged for misleading headline. SSPL is open source. It's just
| not the open source you want.
|
| It meets all the criteria and the only difference from AGPL is
| how much source code you have to release and when - which is also
| the difference between GPL and AGPL. It has problems, but being
| closed source isn't one of them.
|
| The OSI will never certify it, of course, because that would go
| against the business interests of the OSI members. The OSI is a
| consortium of companies who receive free labour from permissively
| licensed projects and to a lesser extent GPL projects, and it
| would like that to continue, which it cannot in practice under
| SSPL. The OSI article linked in a reply does not make a single
| point against the open-sourceness of the SSPL, and essentially
| just says they don't like it, and that some companies won't be
| able to comply, which is true of every free software license.
|
| The FSF, Debian, etc haven't decided one way or another because
| it's not a very widespread license and they can just use valkey
| instead of wasting the effort.
| kstrauser wrote:
| This is not a widely accepted claim. I do not see SSPL as open
| source, and neither do OSI[0] or FSF[1] or Debian[2].
|
| [0]https://opensource.org/blog/the-sspl-is-not-an-open-
| source-l...
|
| [1]https://www.gnu.org/licenses/license-list.en.html
|
| [2]https://www.debian.org/legal/licenses/
| ocdtrekkie wrote:
| We need to stop taking the OSI or FSF's positions on
| _anything_ as particularly valuable.
|
| The OSI is captured entirely by corporate sponsors. Amazon
| was paying a full-time salary a year to the OSI when the SSPL
| issue happened, the OSI had no ability to take a moral pro-
| labor stance without crippling their own operations. They
| still do not meaningfully answer to individual users: The OSI
| recently refused to disclose who won their board election and
| installed their preferred candidates.
|
| And it will be inherently unethical to even consider the
| position of the FSF as long as it lacks the moral fortitude
| to permanently punt RMS from the board.
|
| If the OSI wasn't owned by corporate interests, and had
| rightfully declared SSPL as a copyleft license... nobody
| would argue it isn't. The problem is we've let an extremely
| problematic organization "define" something in a way that
| does not serve our interests.
| kstrauser wrote:
| Which part of their explanation for rejecting it do you
| specifically disagree with?
| ocdtrekkie wrote:
| The entire claim of https://opensource.org/blog/the-sspl-
| is-not-an-open-source-l... holds down to "the right to
| make use of the program for any field of endeavor" and
| the SSPL does not prohibit the use of software in any
| field of endeavor.
|
| The OSI then strays into a lot of nonsense that
| demonstrates just how bought and paid for they are, such
| as "the understanding that their work was going towards
| the greater good", like apparently... being used by a
| company which does not open source it's platform and
| treats its employees so poorly they have to pee in
| bottles. And of course, they immediately claim that
| "now... contributions are embedded in a proprietary
| product" because of course, the OSI believes they own the
| term and definition of open source, and that everything
| they don't agree with is inherently "proprietary".
|
| And then of course, they suggest "relicensing is not
| evidence of any failure of the open source licensing
| model" even though it is very clear that businesses being
| unable to survive producing open source is kinda big flaw
| in the goal of promoting the public software commons.
| (Taking it a step further, if the _FSF_ argues free
| software is a moral imperative, not fixing this is
| outright immoral.)
| jhatemyjob wrote:
| Thank you and immibis for bringing this issue up. Always
| thought this was fishy. I don't fully understand this yet
| and will need to do more research. I bet these comments
| are unpopular because SSPL hurts GCP/AWS, which hurts YC.
|
| Not saying the mods of HN are conspiring to bury these
| comments. But the fish rots from the head in upvote-
| ordered comment trees
| ocdtrekkie wrote:
| I have had my disagreements with dang over the years, but
| to be clear: I think the HN mods do incredible work. I
| disagree with some of their choices, but I don't think
| they moderate with an eye on YC's bottom line.
|
| The OSI and the FSF are still _extremely_ popular
| organizations despite their very big issues, I fully
| expect to upset some people when I bring this up. ;)
| detaro wrote:
| Many people came to the same conclusion about SSPL just by
| reading it when it was released, before any OSI position on
| it.
| immibis wrote:
| Who, that wasn't using motivated reasoning or repeating
| something they heard from OSI or Amazon?
| merb wrote:
| The OSI and FSF make sense by prohibiting stuff like the
| sspl. Open source should express freedom and by putting
| restrictions on certain users no matter how evil they are
| wont express freedom at all
| ocdtrekkie wrote:
| You seem to be opposed to software freedom. The SSPL is a
| viral copyleft open source license, it merely _requires
| users to open source things_. The SSPL is only
| restrictive in the same way as the GPL is, it requires
| granting users software freedom.
| merb wrote:
| The sspl is basically hostile to a certain user base, one
| could say it's rassist. And that's against the spirit of
| the fsf.
| ocdtrekkie wrote:
| Racist against billionaires? C'mon.
|
| Also, you're wrong. The FSF's position is basically that
| software that is non-free is immoral, so any license
| which forces additional software to be released with a
| free license is inherently moral. A very copyleft license
| like the SSPL should be the peak of the FSF's goals.
| merb wrote:
| As said no. A license should not discriminate not even
| against billionaires. Either you start with x and keep it
| that way or you are not better than the billionaires.
| Bait and switch is even worse than being a asshole
| immibis wrote:
| So copyleft licenses are out?
|
| The OSI wrote some nonsense that implies copyleft
| licenses cannot be open source, and the FSF hasn't yet
| taken any position at all.
| jwitthuhn wrote:
| The difference is that SSPL is a license that was written in
| bad faith with the explicit intent that people can't comply
| with the parts about running a hosted service.
|
| https://www.mongodb.com/legal/licensing/server-side-public-l...
|
| See section 13, "Offering the Program as a Service". To comply
| with that you need to release all software used "to make the
| Program or modified version available as a service" under the
| SSPL.
|
| For something like redis this includes: redis itself, the os
| you are using to host redis, the drivers and firmware for the
| hardware you are using to host redis, and more. Also your whole
| deployment stack up to and including the mouse drivers you use
| to click on the "deploy" button.
|
| It is an absurd condition that effectively makes section 13 say
| "you can't offer a hosted version" and the OSI and FSF are
| right to reject that fig leaf of "it is like the agpl, but
| more".
| nailer wrote:
| If you care about open source, and would like Llama 3 to also be
| open source (instead of the current license which, like Redis'
| SSPL, isn't, depite Meta saying it is), you might want to add
| your vote to:
|
| https://github.com/meta-llama/llama3/issues/156
| edweis wrote:
| Mesmerizing number of views. I must admin I refreshed the page
| multiple times to see the count increase. If I increased the view
| count several times, I must admin I did not read the article
| multiple times.
| rdtsc wrote:
| That's great news. I never liked the newly sprung up licenses. I
| understand the background but always felt a burden having to read
| and understand them, and wonder how they'd hold up in practice.
| GPL licenses have been around for decades and is something
| people, including legal teams, know more about.
|
| And when I say "know", I don't mean "like": it could be that this
| will just make it easier for a particular team to decide that it
| doesn't want to deal with the AGPL, and they should go find
| something else, but at least it's clear what it is. As opposed to
| some BSSXYZWL license that you never heard of, which kind sounds
| like it's open source but kind of isn't...
| tombert wrote:
| I fairly recently dodge a bullet; I rewrote a large chunk of
| code I was working on using Akka because my idea lent itself
| fairly well to an actor system. I got it working fine with Akka
| on my local machine, I was about to make a PR for it at work,
| and then saw that it was using BUSL instead of Apache, which I
| had assumed it was using (since a lot of stuff in the Java
| world seems to use Apache).
|
| I did get my stuff working with Pekko (the Apache fork of
| Akka), and it did work, but I was so pissed off at the entirety
| of this that I ended up rewriting the entire thing again using
| Vert.x, which I double checked the license for before doing
| more work.
|
| I do understand why Akka feels like they have to use something
| like BUSL, it's hard to make money as a smaller software
| company, doubly so for open source software, and I also realize
| me complaining that "this free product made with free labor
| isn't free enough for me" is pretty entitled, but fundamentally
| I really don't think that the BUSL (and its similar licenses)
| are the right way forward. Whether or not it's fair, stuff like
| Akka _does_ have competition from stuff that has more OSS-
| friendly stuff, and fundamentally I 'm just going to use those,
| and if they're not up to snuff I'll augment them myself.
| antirez wrote:
| That's a good point, traditional OSS licenses, we can like them
| or not, but they are "understood".
| CaptainFever wrote:
| "Choose boring licenses."
| badmonster wrote:
| great news
| rustc wrote:
| They still require a CLA [1] so there's nothing stopping them
| from doing another relicense to a proprietary license tomorrow.
|
| The only way this remains open source forever is to accept AGPL-
| only licensed patches.
|
| [1]:
| https://github.com/redis/redis/blob/d65102861f51af48241f607a...
| Macha wrote:
| That's sort of fine. As a personal user, someone could fork and
| maintain redis in that case, which wasn't true in the SSPL era.
|
| Now AGPL+CLA is not a license I'd contribute under, but also
| Redis is so far down my priorities that it wasn't a project I
| was going to be issuing PRs for anyway.
| jenadine wrote:
| > AGPL+CLA is not a license I'd contribute under,
|
| Why not? Is it because only one company can make proprietary
| fork?
|
| Would you rather contribute to MIT software where everyone
| can make proprietary fork? Or AGPL without CLA where nobody
| can make proprietary fork?
| eitland wrote:
| > Would you rather contribute to MIT software where
| everyone can make proprietary fork?
|
| In my case that is it.
|
| I'm totally fine with people taking my MIT licensed code in
| a MIT licensed project and running with it.
|
| However, working for free on someone elses code base
| knowing that they can always go commercial with it or do
| whatever they want while I and the rest of the community is
| stuck with AGPL, that is something I'd rather avoid, if
| possible.
| Macha wrote:
| Yes, the asymmetry is a problem. If the terms the company
| has to use my contributions is more favorable to them than
| the terms under which I can use their contributions, then
| I'm not into playing that game.
| jenadine wrote:
| There is an asymetry anyway as the company is probably
| contributing more than 90% of the code, maintain the
| infrastructure for the CI and website, do the promotion
| of the software, and more.
|
| Depending of the motivation for your contribution, you
| get what you want, eg, the feeling of contributing to an
| open source project presumably used by many people, or
| having that entity to maintain your patch "for free".
|
| You can keep your change in a fork if you like, but the
| likelihood that your fork is getting used is not that
| big, and mean more work from your side to rebase the
| change.
| dbacar wrote:
| Thanks, maybe this will be exemplary behavior for Elastic and
| Mongo.
| simonw wrote:
| From this post on the Redis blog https://redis.io/blog/agplv3/ it
| looks like they've made a bunch of new features available under
| the new AGPL license too:
|
| > Integrating Redis Stack technologies, including JSON, Time
| Series, probabilistic data types, Redis Query Engine and more
| into core Redis 8 under AGPL
|
| Redis Query Engine is new-to-me (I stopped following Redis
| closely after the license change) - it looks like an in-memory
| alternative to a lot of the things you might do with
| Elasticsearch:
| https://redis.io/docs/latest/develop/interact/search-and-que...
|
| With syntax that looks something like this:
| FT.SEARCH places "museum @city:(san francisco|oakland)
| @shape:[CONTAINS $poly]" PARAMS 2 poly 'POLYGON((-122.5 37.7,
| -122.5 37.8, -122.4 37.8, -122.4 37.7, -122.5 37.7))' DIALECT 3
|
| (This is a smart move in terms of answering the question "Why
| would I switch back to Redis if I've moved to Valkey" - Redis
| just grew a bunch of new interesting features.)
| kragen wrote:
| Dismayingly, the CEO misspelled antirez's last name in this
| press release, https://redis.io/blog/agplv3/. That's so
| incredibly disrespectful:
|
| > _Following our license change, in November of 2024 Salvatore
| Sanfillipo (antirez) decided to rejoin Redis as a developer
| evangelist. Collaborating with Salvatore on new capabilities,
| company strategy and community engagement has been a true
| privilege that has made a major impact that will pay dividends
| into the future._
|
| If it's a true privilege, you should earn it by _not
| misspelling his name_. Actions speak louder than words.
|
| Pink Floyd has a song about this:
|
| _Well, I 've always had a deep respect and I mean that most
| sincere
|
| The band is just fantastic, that is really what I think
|
| Oh, by the way, which one's Pink?
|
| And did we tell you the name of the game, boy?
|
| We call it riding the gravy train
|
| We're just knocked out, we heard about the sell-out
|
| You gotta get an album out, you owe it to the people
|
| We're so happy we can hardly count
|
| Everybody else is just green, have you seen the chart?
|
| It's a hell of a start, it could be made into a monster
|
| If we all pull together as a team._
| dec0dedab0de wrote:
| So with redis being AGPL, who counts as a user?
|
| If you have a webapp that uses redis on the backend for a task
| queue, do the users of the webapp count as users of redis, and
| you then have to provide source to redis? Is there a chance that
| you might have to release your apps code to be compliant?
| jopsen wrote:
| I just read the AGPL and the FAQs and it's not entirely clear
| to me either.
|
| Probably why many companies find AGPL toxic.
| ensignavenger wrote:
| This is my number one objection to the AGPL. Still way better
| than the SSPL or BUSL, but I will stick with valley for now.
| kstrauser wrote:
| No. Users of Redis are the ones connecting to it. Furthermore,
| the Redis client library that you link into your program is MIT
| licensed. Unless you embed Redis directly into your app, you'd
| never have to release your own code to use it.
| sneak wrote:
| This is disappointing. The AGPL is a nonfree (and nonsensical)
| license.
|
| The fact that the FSF wants a EULA but can't have a EULA without
| violating Freedom 0 doesn't make the AGPL suddenly logically
| sound.
|
| marcan has written about it in more detail than I care to:
| https://news.ycombinator.com/item?id=30044019
|
| Stop using the AGPL. It violates the basic principles of free
| software.
|
| The ability to run a SaaS company with free software is a
| feature, not a bug.
| jraph wrote:
| You can run a SaaS company with AGPL-licensed software, no
| problem.
|
| What do you think is nonfree about AGPL?
| sneak wrote:
| Not a differentiated one.
|
| The AGPL, in its quest to be a EULA, violates free software
| Freedom 0 ("The freedom to run the program as you wish, for
| any purpose").
|
| https://www.gnu.org/philosophy/free-sw.en.html
|
| The AGPL literally demands specific functionality be present
| in the software that cannot be removed without breaking the
| license. The anticapitalist FSF zealots got so in love with
| the idea of closing what they call "the ASP loophole" that
| they wrote themselves a EULA.
| gkbrk wrote:
| > The freedom to run the program as you wish, for any
| purpose
|
| I can do this with AGPL software just fine. Which purposes
| are not allowed under AGPL?
| sneak wrote:
| You are not allowed to modify an AGPL program without
| adding a mandatory feature to provide the currently-
| running source code to a remote network user of the
| software. You are also not allowed to remove that
| functionality. It's a clear violation of freedom 0.
|
| I suggest that you read the actual text of the AGPL. It's
| madness. They wanted a EULA so badly.
| jraph wrote:
| > You are not allowed to modify an AGPL program without
| adding a mandatory feature to provide the currently-
| running source code to a remote network user of the
| software
|
| That's not true. You only need to provide the modified
| source code somewhere.
|
| _You_ might want to read it again :-) It seems like you
| have a wrong idea of what the AGPL does.
|
| edit: I see an immediate downvote. If whoever did this
| thinks I'm wrong, please share the exact AGPL excerpt
| that mandates actually building a feature to provide the
| source code currently in use in the network program
| itself.
| detaro wrote:
| The problematic clause is this one:
|
| > _if you modify the Program, your modified version must
| prominently offer all users interacting with it remotely
| through a computer network (if your version supports such
| interaction) an opportunity to receive the Corresponding
| Source_
|
| The application does not have to directly provide its own
| exact source code, but it must advertise where to find
| it.
|
| And it's quite unclear what exactly counts here. For a
| web application it's somewhat obvious how one might do
| that (although how many AGPL applications are prepared
| for it as a simple config option vs require you to do
| additional patching to add it), but for other
| applications its not.
|
| E.g. you interact with redis over a custom protocol thats
| self-described as being human-readable. Does that mean I
| need to inject the offer there somewhere? What if it is a
| much more opaque protocol? If you ask 5 lawyers, how many
| opinions on that do you get?
| jraph wrote:
| Fair enough! Thanks for the interesting comment.
| bk496 wrote:
| cool, does this means it works on Windows now?
| gray_-_wolf wrote:
| I am bit confused by the comments here. Sure, it remains to be
| seen whether Redis Ltd. can be trusted again, but cannot we just
| be a happy for a bit that we (again) have a good software under a
| free license?
| simonw wrote:
| Lots of cynical takes in this thread - and I get it, there isn't
| a guarantee they won't relicense again in the future (they have a
| CLA that would let them) and people feel betrayed by the last
| license change.
|
| I think we should celebrate this anyway. It's a smart decision,
| it's what the community wanted to happen and it would be great if
| other companies with janky licenses could see "Redis relicensed
| to open source and had a great boost out of it", not 'Redis
| relicensed to open source and it didn't help them at all".
|
| I'm delighted. Thank you, team Redis.
| antirez wrote:
| Thank you, Simon. I believe that cases like Elastic and Redis
| returning back to an open source license is like writing on the
| rock: "open source won", at least in the system software space.
| Companies get created, prosper and fail over time, but this
| message is here to stay with us for a long time, and shapes the
| society of tomorrow. It's a win of the software community
| itself.
| lolinder wrote:
| It's a win for the community _over_ and _against_ the
| corporations that are Redis and Elastic. They 're not the
| good guys for giving in to the pressure. They tried to ride
| FOSS to prominence and then extract wealth on the backs of
| the community and found that the community mattered more than
| they did.
|
| So sure, let's celebrate, but celebrate the community, not
| those who tried to pull the rug out from under them.
| antirez wrote:
| I said exactly that's a win of the community. But money are
| needed to pay the folks that work at open source software,
| and the companies that went for the SSPL were trying to
| protect their business (and, as a side effect, wanted or
| not, the ability to pay for such work). I believe the
| software world failed to protect open source software in
| the cloud era, but in general the environment that we
| collectively created made the open source software won.
| lolinder wrote:
| I don't buy that justification. These two companies (and
| the others like them) set up a model for funding their
| business knowing full well that they would have to
| compete with others who were able to provide the same
| service they were. That's always been baked into FOSS--
| you can't plan around a monopoly when you're releasing
| your code for free, that's part of the trade-off you
| make.
|
| When AWS and Co _did_ provide hosting and provided it
| better than these guys could, now it 's suddenly AWS who
| are the bad guys for using the FOSS software the way the
| license always said they could. Now we're suddenly
| supposed to ignore the terms on which FOSS has always
| been released and pick up our pitchforks against the big
| mean cloud provider.
|
| Instead of sticking to the fundamental principles of FOSS
| (principles which they won business by openly espousing)
| and adapting their business to the fact that Elastic and
| Redis lost in the competition they knowingly set up, they
| fixated on hosting (on top of AWS and Co, no less!) as
| the business model and changed the licenses to give
| themselves a monopoly on it.
| jimbokun wrote:
| There is no possible way to compete against someone else
| who doesn't need to fund the development of the software
| but can still take in all the revenues and profits from
| deploying it as a service.
| lolinder wrote:
| But that has always been true, from the beginning. It's
| baked in to the FOSS model and always has been.
|
| If the companies had made a bad call in structuring their
| business and owned up to it I think we'd be having a very
| different conversation than we are. We're here because
| they failed to own up to it and instead tried to get
| people to raise pitchforks against AWS. Never mind that
| their intended model was the obviously doomed model of
| reselling AWS's hosting with a commission on top, and
| never mind that it was the trade-off they chose when they
| chose to release their software as FOSS and get the boost
| in adoption that comes with.
|
| I do fully agree with antirez above that we need a new
| plan for funding FOSS. But I think that's a poor
| justification for the rug pulling and vilifying that the
| existing companies did.
| overfeed wrote:
| You make it sound like there is a way to compete against
| the same organizations if they funded the development of
| the software - it's not possible to compete against
| hyperscalers, period. Now that Amazon is funding a fork,
| is Redis, Inc in a better or worse position to compete?
| kodablah wrote:
| Not true, you can compete with the quality of the
| deployed service _separate_ from the development of the
| software. The quality of the service can include
| internal, at-scale optimizations that don't affect user-
| facing parity with the open-source software.
|
| Open source companies with SaaS offerings need to have
| plans to differentiate themselves on hosting quality, not
| features. Yes, you can do better at hosting your own
| product than Amazon in many cases with customized,
| closed-source optimizations (that are unrelated to
| feature parity and does not intentionally limit the open-
| source/self-hosted form), support, etc.
| spondyl wrote:
| > Not true, you can compete with the quality of the
| deployed service _separate_ from the development of the
| software.
|
| That is true in a literal sense but (anecdotally) from
| the point of view of an engineer deploying ie; Redis,
| there is no real space for that angle of competition when
| the choice is between having to go through procurement
| hurdles to sign a contract with Redis Labs versus say;
| spinning up Redis on AWS which has zero hurdles because
| there is already an organization wide agreement in place
| for example.
|
| The competition there isn't a level playing field as the
| deck is kind of stacked for most businesses where
| engineers don't have free reign to procurement what might
| be objectively the best hosting solution?
|
| I've never really thought through this in any depth
| before now so don't consider this a great fleshed out
| argument, just an observation from my personal
| experience.
| BoorishBears wrote:
| Honestly the idea that you can win by just being better
| is so deeply out of touch with enterprise that I assume
| anyone suggesting this doesn't understand the problem
| enough to be trying to argue against antirez of all
| people on Earth about this.
|
| And that's not an appeal to authority: there just so
| genuinely and obviously is no such guarantee in
| enterprise that quality will ensure success that
| explaining it feels like trying to break down an
| elementary element.
| fastball wrote:
| Silly take due to how these resources must be
| distributed. Redis corp is paying developers to work on
| Redis itself, so they have less money to spend on
| building out a cloud offering. AWS was not paying
| developers to work on Redis, so they have more money to
| spend on improving their cloud offering (of Redis).
|
| "Impossible to compete" is hyperbolic (you can almost
| always compete), but from a business fundamentals
| perspective it is not a level playing field and odds of
| success in that arena are very very low. And as my
| sibling comment points out, this is massively compounded
| by the fact that (by their very nature), hyperscalers are
| also hosting other infra for you, whereas Redis Cloud is
| only going to be offering hosted Redis. So even if the
| DX/UX is much better for Redis Cloud, it is still an
| uphill battle to convince corpos and even SMEs to split
| up their hosting like that.
| pydry wrote:
| Yeah, no. Customers will prefer to use redis in their
| existing AWS/Microsoft stack rather than use your
| deployed version in a different data center with a few
| micro optimizations.
|
| They will pay Microsoft and Amazon, not you, the author
| of the software to use your software.
| growse wrote:
| If you solely fund the development of the software, you
| _own the feature backlog_. If you can 't use that as a
| competitive advantage, I don't really know what to tell
| you.
| fc417fc802 wrote:
| > now it's suddenly AWS who are the bad guys for using
| the FOSS software the way the license always said they
| could
|
| That's not a fair representation of the objection. The
| thing under contention here is a behemoth freeloading for
| substantial profit. The reason it's viewed as bad is
| because that behavior undermines the community at large.
| Participants need to contribute back proportional to
| their benefit when realistically able lest the community
| decline over time.
|
| It's conceptually similar to the disapproval employers
| with poor workplaces are subjected to. Even if they
| _technically_ obey all the labor laws, by prioritizing
| their profits over worker health and well being they
| garner a bad reputation. "But we didn't do anything
| illegal" isn't going to get them out of it.
| lolinder wrote:
| > The reason it's viewed as bad is because that behavior
| undermines the community at large. Participants need to
| contribute back proportional to their benefit when
| realistically able lest the community decline over time.
|
| Why? No one has been able to articulate this for me. Why
| does Amazon using the software cause the community to
| decline? Doesn't it make the software more popular with
| broader reach?
|
| When you give software away for free, you've given it
| away for free. You're producing it with the intention of
| it being used. Why does that suddenly become a problem
| when it gets used on a large scale?
| fc417fc802 wrote:
| > Why does Amazon using the software cause the community
| to decline?
|
| It doesn't - at least directly.
|
| > You're producing it with the intention of it being
| used. Why does that suddenly become a problem when it
| gets used on a large scale?
|
| You're setting up a cause and effect here that I never
| put forward. It isn't the use _itself_ that suddenly
| becomes problematic.
|
| The behavior is the issue. If everyone else pitches in
| and you don't, you come out ahead. It's the game theory
| behind cooperative behavior. If only you abstain the
| community isn't necessarily worse off, but if everyone
| abstains then it is (ie compared to if they all
| contributed). The optimal outcome _for the group as a
| whole_ is for everyone to pitch in.
|
| I do get where you're coming from. Legally speaking it's
| quite silly for someone investing money not to
| proactively prevent this from the beginning.
|
| This isn't about the legality though. It's about social
| responsibilities. Entities with more resources -
| individuals, corporations, and even governments - are
| generally held to higher standards in the public eye. The
| legal system alone is not sufficient to make society a
| nice place to live.
| barotalomey wrote:
| > But money are needed to pay the folks that work at open
| source software
|
| Cute. Can I have a check for my redis contributions now
| please?
| thayne wrote:
| I strongly suspect there was pressure from within these
| companies, among developers as well.
| znpy wrote:
| I'd say that open source definitely lost, and lost real bad.
|
| Free Software won, as you ended up adopting the AGPL.
|
| It's an important distinction.
| fastball wrote:
| No its not.
| primitivesuave wrote:
| I also appreciate this perspective because you never know
| what's going on in the board room. I have seen some morally
| upstanding leaders make questionable decisions that were
| totally out of character for them, all for the sake of
| appeasing a narrow-minded investor.
| overfeed wrote:
| > it would be great if other companies with janky licenses
| could see "Redis relicensed to open source and had a great
| boost out of it", not 'Redis relicensed to open source and it
| didn't help them at all".
|
| If the other companies can't figure out that adopting a janky
| license and alienating the community is the self-inflicted
| problem, then they are beyond help. Relicensing to open source
| not helping the company may serve as a cautionary tale for
| other companies and may prevent them from repeating the same
| mistake. As an open source enthusiast, the worst case scenario
| is companies switching licenses tactically and frequently to
| test the waters and walking back with no consequences; I'd
| prefer the cost of such actions to be swift and severe.
| ksec wrote:
| >Lots of cynical takes in this thread - and I get it, there
| isn't a guarantee they won't relicense again in the future
| (they have a CLA that would let them) and people feel betrayed
| by the last license change.
|
| Oh good. There is still hope of it returning to the original
| BSD license. ( I am still using good old Memcached )
| mort96 wrote:
| I don't want companies to see, "re-licensing to janky licenses
| is risk-free, because we can always go back to the old license
| if people react too negatively". I would like them to see, "re-
| licensing to janky licenses is a death sentence which
| immediately makes your product almost completely irrelevant and
| causes the community to switch to a fork and never switch
| back".
| gloomyday wrote:
| It could be cynical, but I think it is important to show severe
| consequences for breaking trust between a company and its
| community. Anyone that saw their history and contributes to it
| must be aware they are doing unpaid work for a company.
| createaccount99 wrote:
| AGPL + selling under other licenses seems to be the way
| otterley wrote:
| If there's a lesson to be learned from this drama, it's that
| changing a software license from a liberal open-source one to a
| anti-competitive one (even if the source is still available and
| open to contribution) is a one-way door and loses trust. Once
| done, even if you recognize your error and revert the license,
| you're not getting that trust back.
| freeAgent wrote:
| The announcement just happened. I don't know that we know the
| results yet.
| lolinder wrote:
| Elastic announced they were switching back a few months ago,
| we should be able to measure the results by now.
| jonny_eh wrote:
| > you're not getting that trust back
|
| It's not black and white. They'll get _some_ trust back at
| least.
| otterley wrote:
| Anyone capable of pulling a rug once is capable of doing it
| twice.
| jonny_eh wrote:
| You can't win all the trust back at once, it's a process.
| ConanRus wrote:
| stop clowning around already
| umajho wrote:
| MinIO also switched to AGPLv3 a while back, and they stated that
| "the AGPL license requires that all software connecting with
| MinIO be 100% open source for you/your users not to be in
| violation of the license."[^1] Since Redis and MinIO are somewhat
| similar, (Both can be used to store and retrieve data. Redis uses
| a custom protocol, and MinIO uses an S3-compatible API.) Should I
| assume that this statement also applies to Redis?
|
| [^1]:
| https://github.com/minio/minio/issues/13308#issuecomment-929...
| pingiun wrote:
| I believe the AGPL doesn't actually require this, even though
| MinIO may think it does. I hope someone gets sued over this
| some day so we may find out
| merb wrote:
| It would not even make sense. Since you do not even always
| know what license the thing has you are connecting to. And
| not even the fsf sees it that way.
| jopsen wrote:
| Sure, if you're connecting to a service using AGPL, the
| service operator must offer the source along with a copy of
| the license.
|
| I'm no lawyer, but unless the software in question makes an
| exception for the particular API, I wouldn't feel
| confident.
|
| Or what is the distinction here?
| preisschild wrote:
| > Should I assume that this statement also applies to Redis?
|
| I dont think it applies to clients using the API at all. It
| just specifies that the modified source should be offered to
| clients connecting over the API, but not that the client itself
| has to be open source.
|
| https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
| jan_g wrote:
| Yeah, min.io really soured AGPL license, for me at least.
| Because of their stance I've switched away from min.io in our
| company and avoid everything AGPL like a plague. Having read
| the license many times and also all discussions around it, I
| understand that it should be fine to use an AGPL project in a
| commercial enterprise (without modifications, internally in
| backend network). However, if authors themselves of such a
| project believe and say otherwise, I'm really not going to risk
| anything and definitely not asking lawyers if "my specific use
| of min.io violates the license or not". I'm just using it as-is
| over network, internally in my backend deployment. Not modified
| and not exposed to external world.
| revskill wrote:
| Is it a business decision right ?
| ksynwa wrote:
| I ask this as a scrub end user. What are the implications of
| forking when it comes to a Redis? Specifically, what I am
| wondering about whether forks like valkey which are worked on by
| competent programmers[1] continue to be good choices or does
| Redis Inc. having founded redis give it a distict advantage?
|
| [1] I am assuming this because valkey comes under the Linux
| Foundation umbrella.
| ingen0s wrote:
| amen
| skrebbel wrote:
| I wonder whether they did deals with AWS and Google behinds the
| scenes. Something like "you poured money into Valkey, how about
| you give that kind of money to us instead and we'll switch to
| AGPL and you can stop confusing two customers with two
| practically identical but differently priced options". Could that
| ever work? (I have no idea)
| reconditerose wrote:
| Google is well known for having banned AGPL (https://opensource
| .google/documentation/reference/thirdparty...).
| skrebbel wrote:
| Oh nice! Smart move then. Makes me wonder why they went with
| SSPL in the first place.
| hsnice16 wrote:
| In time, I built this -
| https://github.com/hsnice16/golang_learning/tree/main/One2N/...
| eduction wrote:
| I'm always grateful for open source code, but on AGPL I can only
| quote the lawyer Kyle Mitchell:
|
| "Inebriated aliens might as well have beamed it down from space
| as a kind of practical joke..."
|
| "It's not just hard for lawyers, who have the legal picture and
| can parse the whole license very carefully without passing
| out...It's also hard for hackers, even those familiar with free
| software lore, who lack the legal side of the picture and a sense
| of what other ways things might have been said. Imagine how
| people who don't know software, law, legal drafting, software
| architecture, hacker culture, or the self-styled 'philosophical'
| musings of one Richard M. Stallman feel."
|
| https://writing.kemitchell.com/2021/01/24/Reading-AGPL
|
| As Mitchell implies folks who want network copyleft should look
| into the more straightforward OSL3, IMO.
|
| But it's something, and it's not my call to make because I didn't
| write the code, so properly I can only be grateful.
| skrebbel wrote:
| This is the first time I read about OSL3
| (https://opensource.org/license/osl-3-0-php).
|
| I'm bad at licenses, and I admit I don't completely get it. At
| first glance, it seems like a simpler more readable license
| that tries to accomplish something similar to AGPL. I think the
| "license terminates when you sue me for patent infringement"
| clause is nifty.
|
| But it says that an "external deployment" counts as
| "distribution" (ok, fair), which means you must OSL-license
| your changes too (ok, fair too).
|
| But how does that in practice prevent AWS and GCP from cloud-
| hosting your software without giving back? Seems to me that if
| Redis went OSL3, GCP could host it fine so long as they'd
| OSL3-distribute any changes they made.
| em-bee wrote:
| _how does that in practice prevent AWS and GCP from cloud-
| hosting your software without giving back_
|
| it doesn't. but neither does the AGPL. the only reason
| companies avoid the AGPL is because the AGPL stipulates that
| anything that the software is integrated with must be
| distributed as well. they are avoiding the GPL for the same
| reason. i don't know if the OSL does that too. if it doesn't
| then it would be less protective than the AGPL.
|
| the AGPL works to prevent competition because companies are
| scared of it, but that was not its intention. none of the GPL
| licenses are intended to prevent competition without giving
| back.
|
| and that is the real problem that redis and other companies
| are facing: how can we share source with our users without
| allowing well funded competitors to eat our lunch.
|
| there are several experimental licenses that are trying to
| address that problem, among others, FUTO is working on that,
| as is bruce perens. but so far no clear choice has emerged.
| and unfortunately many see the idea of limiting competition
| as against the spirit of FOSS. personally, i think that needs
| to change.
| eduction wrote:
| > But how does that in practice prevent AWS and GCP from
| cloud-hosting your software without giving back? Seems to me
| that if Redis went OSL3, GCP could host it fine so long as
| they'd OSL3-distribute any changes they made.
|
| What is your definition of "giving back?" To me that means
| open sourcing your changes, which as you note is what the
| license requires.
| skrebbel wrote:
| Yeah sorry, stupid choice of words given the subject. I
| meant paying them for the privilege somehow, which has been
| Redis (the company)'s goal this whole time. GP suggests
| OSL3 solves this and I'm trying to figure out how.
| eduction wrote:
| Oh I see. IANAL but if the plan with agpl is to sell
| commercial versions for people who don't want to worry
| about FOSS licensing/infection then it may be a great
| license for that precisely because of the lack of
| clarity. You can do similar with OSL - "pay us to get it
| under a different license where you can make a closed
| derivative work" - but OSL clearly allows linking
| (according to its author) without the mere linking
| requiring opening the thing that links it so it may be
| strictly worse for Redis.
|
| I was merely saying OSL is better than agpl as a license
| (imo). It's very clear. But lack of clarity can have
| strategic value.
| em-bee wrote:
| maybe if you are a lawyer, and if you are trying to get around
| the license somehow, or of you have to defend the license
| against an abuser then the AGPL is challenging, but as a FOSS
| user and developer, it is pretty straightforward: the software
| runs on a server, you connect to it, you get access to the
| source that is running on the server. if you believe in the
| spirit of Free Software then there is no question what you
| should do.
|
| if you are fussing about the details which code you need to
| share and which not then you are not following the spirit of
| Free Software. it's as simple as that.
|
| also, consider that the AGPL is trying to be compatible to the
| GPL. that forces it to be more complicated. the OSL doesn't
| have that problem, and the OSL is also not compatible with the
| GPL, which is only ok if you don't want to integrate any other
| GPL software. although i suppose since the GPL doesn't require
| distribution on network access, this may not be an issue. but i
| don't know, i am not a lawyer. and so to be sure, i'll prefer
| the AGPL.
| eduction wrote:
| > if you are fussing about the details which code you need to
| share and which not then you are not following the spirit of
| Free Software. it's as simple as that.
|
| Kyle's point is pretty clear: it's really hard to tell what
| agpl actually requires. So it's a bad, unclear license
| whatever your position is - whether you think your code
| should virally make everything that links it open source, or
| if you expressly don't want that and only want the library
| itself network copyleft. What does agpl actually require?
| Even lawyers are stumped.
| em-bee wrote:
| but my point is that if i just share everything, as a FOSS
| enthusiast is wont to do, then i don't need to worry about
| the details. the details only matter for those who are not
| into FOSS and are forced to comply with the license without
| having the desire to do so.
|
| one could argue that a complicated license reduces the
| attraction of my software, but again, if i am not out to
| become popular, i would not care about that. and for my
| paying customers they should not care either, because they
| are still getting more than they would from proprietary
| software, or they are paying me to get an exception.
|
| so if the license for my software is to complicated for
| you, tough luck. it's not my job to accommodate that.
| eduction wrote:
| > but my point is that if i just share everything, as a
| FOSS enthusiast is wont to do, then i don't need to worry
| about the details.
|
| That's only true if you also don't care what other people
| are required to do with your code. People who want
| copyleft enforced for their contributions will care if
| the license actually enforces it, and how.
|
| > if the license for my software is to complicated for
| you, tough luck
|
| Sure, fine. My whole point in the last comment is that
| it's complicated for the /creator/. Wasn't talking about
| the user. A badly written license cuts both ways.
| em-bee wrote:
| but it isn't complicated for me as creator. i just share
| the whole thing.
|
| and the difficulty to enforce i already addressed in my
| first comment: _if you have to defend the license against
| an abuser then the AGPL is challenging_. so i do accept
| that.
| Nemo_bis wrote:
| As noted by others, this is irrelevant unless Redis actually uses
| AGPL as the primary license for the software (that is, in an
| inbound=outbound fashion).
| https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
| rcarmo wrote:
| Great to see this. 12 years ago I wrote
| https://github.com/rcarmo/miniredis during a very slow weekend
| where I both wanted to get a feel for the internals of how Redis
| worked and have a little PubSub server I could call my own.
|
| I spent the entire weekend poring over the C code and found it
| some of the most beautiful C I'd ever read (ever since the heady
| years of SunOS), and now I feel I should at least go and update
| miniredis to asyncio/Python 3--for kicks...
| eGQjxkKF6fif wrote:
| Do it. I'm thinking of making one for node.
| rcarmo wrote:
| Already started. python3 branch. Claude removed all my nice
| idiomatic conditional expressions, but the (few) tests I have
| for the server already pass, and the aioserver is coming next
| :)
| theturtletalks wrote:
| When Antirez left Redis, he wrote an amazing blog post I go back
| to often [0]. In there he said:
|
| "I write code in order to express myself, and I consider what I
| code an artifact, rather than just something useful to get things
| done. I would say that what I write is useful just as a side
| effect, but my first goal is to make something that is, in some
| way, beautiful. In essence, I would rather be remembered as a bad
| artist than a good programmer."
|
| I'm glad Antirez was seeing his art losing it's beauty and now,
| is reclaiming it!
|
| 0. https://antirez.com/news/133
| parrit wrote:
| So nice to hear talk like that in the AI "your code is
| worthless age". Keep the craft going!
| radium3d wrote:
| Wow I chose to start using redis in the right week :)
| martinsnow wrote:
| They can seriously screw themselves with the rugpull they made. I
| reported so many bugs and helped diagnose them in the sentinel
| module. Seriously fuck them.
| tonyhart7 wrote:
| they realize that they dont have a "moat" and if entire industry
| try hard enough to replace them then its over for them
| foobarian wrote:
| I'm happy to see the news after having a chance to look at
| sources more closely (for unrelated reasons). The Redis
| geohash/gis related implementation is such a pleasure to read.
| alabhyajindal wrote:
| LMAAOO
| osigurdson wrote:
| I think a project has to be Linux or Postgres big to really
| operate as open source. Why? Because cloud providers can easily
| sell your product and contribute nothing back. So, for anything <
| Postgres in size you need to create a new license to allow you to
| run a managed service. The problem is, with something like AGPL,
| companies that aren't selling your stuff (just using it), now
| need to release their stuff as AGPL as well. With so many things
| using Redis, it seems that millions of companies will now be in
| violation of the license agreement upon a given update in the
| future.
|
| Personally, I think it is better just to call a spade a spade and
| release things with commercial licenses. Let all companies with <
| 1T market cap use your stuff for free. Companies that are making
| money will want a managed service or support anyway. Companies
| that want to host your stuff in their environment fall into the >
| $1T category.
|
| The above is a bit of a strawman but what we really want is for
| valuable projects to continue to exist.
| lukaslalinsky wrote:
| What about looking at it the other way around, neither Linux
| nor PostgreSQL is a commercial product, never were and never
| will be. Many people create commercial products on top of them,
| and that's OK, it's allowed by the license. Even Redis started
| as a fully open source project. But then it was sold to a
| company, and company cares more about making money than taking
| care of open source product. If you are a small company, and
| want to create an open source product, that's only free for
| personal use, just say so up front. Don't try to pretend the
| product is something else. It's really not about size, it's
| about motivation, and the motivation of a company is always
| making money in the first place.
| _tom_ wrote:
| Doesn't AGPL give you LESS rights? (fewer?)
|
| AGPL is pretty much a non-starter for any commercial development.
|
| The RSALv2 let you use Redis, unless you were a service provider.
| Now, you can't use it for anything (EVERYTHING is accessed over a
| network now) without sharing your source.
|
| So, before everyone but amazon could use it for commercial
| purposes, now no one can.
| skywhopper wrote:
| 1) you can still use it under RSAL.
|
| 2) you only have to share what you change. You don't have to
| change it to provide it as a service, but if you do, you have
| to share the code. That doesn't seem particularly harsh and
| certainly doesn't prevent providing it commercially.
| roetlich wrote:
| Unless you modify Redis, what do you want to share? You don't
| have to share any of your server code or anything. No reason to
| be so dramatic. :)
| _tom_ wrote:
| You have to make the choice about sharing at the start. If
| you use AGPL and later decide to make changes, you'll have to
| share. So most don't want to risk it.
|
| But more important, AGPL software is banned at many large
| corporations. It's simply not an option.
| aftbit wrote:
| From the CEO blog post - https://redis.io/blog/agplv3/
|
| >This achieved our goal--AWS and Google now maintain their own
| fork
|
| Was this really the goal though? Forcing your biggest users to
| fork your software and maintain their own divergent version is
| not really good for anyone. Sure, Amazon and Google (or AWS and
| GCP - type confusion in the source material) now have to
| contribute some more engineering hours to the open fork, but why
| would anyone still want to use Redis now that there's a
| permissively licensed alternative maintained by the same cloud
| hyperscalers who will end up running it for you?
| skybrian wrote:
| Are there compensating benefits? For web browsers, having
| multiple, competing implementations is considered good.
| jacobgkau wrote:
| Are there benefits to the ecosystem? Possibly.
|
| But the person you replied to was talking about Redis's goal,
| and I don't think it's likely their goal had anything to do
| with having a competitor to themselves around. Even if they
| did want that, they could've just bankrolled (or engineered)
| a fork; changing a license to one that causes your largest
| users to do the work themselves is a rather roundabout way to
| do it.
|
| I can almost kind of see the large users needing to work
| together on a replacement, meaning that replacement might as
| well be open-source, meaning Redis can get future
| improvements that were funded by the fork users (who Redis
| was upset wasn't paying them) as a semi-vindictive, semi-
| useful goal. But it's still roundabout. If that was really
| the plan, it could've been articulated better in this
| postmortem to make it clear the "goal" bit hadn't just been
| BS'd.
| Spivak wrote:
| Yeah this take kind of surprised me, you really _wanted_ Valkey
| to be the default option for cloud customers ensuring they 'll
| have no migration path to your own offering? I just don't get
| it. You were getting $0 and now you're getting $0.
| fastball wrote:
| How often were people migrating from AWS Redis to Redis Cloud
| in the first place? I'm guessing not a lot.
| bravetraveler wrote:
| +1. Not a lot, I'd guess. Every time I've used Redis _(or
| ValKey in more recent times)_ , latency more than 20ms or
| so would have been _terrible._
|
| I've seen workloads perform better without caching at all
| at 30ms
| fastball wrote:
| Isn't it though? They weren't contributing before and they
| weren't paying Redis corp before, now they are at least
| contributing to a fork (and still not paying Redis corp).
|
| Presumably some of the things being worked on in Valkey, etc
| can be upstreamed back to Redis in some form (not entirely
| straightforward since it is a hard fork with a diff license,
| but concepts can be borrowed back too).
|
| e.g. apparently Valkey has introduced some performance
| improvements. Redis can implement similar if it seems
| worthwhile. Without the fork those performance ideas might have
| never surfaced.
| mzi wrote:
| They were contributing a lot. So Redis-the-company lost a lot
| of engineering expertise when they all left for valkey.
| arthur-st wrote:
| > They weren't contributing before
|
| That is not true. Companies like AWS had paid staff working
| as OSS Redis core maintainers before the licencing schism.
| This talk of "achieving their goals" is just bluster serving
| no reason other than damage control.
| geysersam wrote:
| I don't get it, why don't gcp and aws just pay the Redis
| company instead of paying their own (expensive!) engineers to
| maintain a fork?
| ddorian43 wrote:
| Because they think it's cheaper/better for them.
| znpy wrote:
| The post is a bit misleading as the agpl is a licensing _option_
| but not _the_ license.
|
| It's a good trade-off though. Grafana does the same and they're
| doing just fine.
|
| I hope redis gets to live a long life now that's more open than
| ever (essentially it's free software now) :)
|
| After the redis troubles I hope more people start to realise that
| the GPL license is the way really, and that other licenses (like
| the BSD that Redis used to use) are really just too risky.
| fooker wrote:
| Does anyone use redis any more?
| gitroom wrote:
| was honestly waiting for something like this, but that trust hit
| doesn't really fade for me - you think companies ever recover
| from stuff like this or do folks just move on for good?
| bionhoward wrote:
| Again? Didn't it go from BSD to some infectious copyleft thing?
| Doesn't seem "open source again" to me if we can't use it in
| private work projects without being forced to open source our
| project. Isn't AGPL even WORSE than what they switched from?
| Wouldn't "open source again" imply going back to BSD?
| yjftsjthsd-h wrote:
| > Again? Didn't it go from BSD to some infectious copyleft
| thing?
|
| They went to SSPL, which isn't open source. (Whether it's
| copyleft is an interesting exercise left to the reader. I
| genuinely don't know, I'd have to stare at definitions for a
| bit to form an opinion.)
|
| > Doesn't seem "open source again" to me if we can't use it in
| private work projects without being forced to open source our
| project.
|
| Er, I'm not a lawyer, but why wouldn't you be able to use it in
| a _private_ work? AFAIK the viral parts of AGPL /GPL only say
| you have to share source with users of the software; if your
| only user is you then it's immaterial.
|
| > Isn't AGPL even WORSE than what they switched from? Wouldn't
| "open source again" imply going back to BSD?
|
| Worse/better is somewhat subjective, but AGPL is a (Free and)
| Open Source license. It was open source (BSD), then it wasn't
| (SSPL), then it was open source (AGPL).
| redbell wrote:
| Ironically, when Redis changed their license a couple of months
| ago, I commented back then [1]:
|
| _But who knows what the future holds? Maybe the Redis team will
| change their mind and revert back the decision like Elastic
| Search did a few weeks
| ago:https://news.ycombinator.com/item?id=41394797_
|
| Yeah, that future had come, and Redis is free again!
|
| Thanks antirez and to all the team behind Redis.
|
| _________________
|
| 1. https://news.ycombinator.com/item?id=41611636#41612750
| mkoubaa wrote:
| No need to trust them. Use it and if the license changes fork it
| again. Where is the problem?
| donatj wrote:
| Literally _the day_ after I started working on moving to
| Valkey... That 's how it goes.
| fastball wrote:
| Why the change yesterday? Were there developments happening in
| Valkey that made you feel like a switch would be worthwhile?
| senderista wrote:
| Why I will never try to monetize my own project:
|
| 1. To monetize a project, it must first gain wide adoption.
|
| 2. To gain wide adoption, it must have a permissive license.
|
| 3. To successfully monetize (after gaining wide adoption), it
| must have a restrictive license.
|
| 4. Changing a project's license to be more restrictive will
| alienate the community and hurt adoption.
|
| I see no solution to this dilemma.
| bpiroman wrote:
| I still don't understand what Redis does or why we need it as web
| devs...
| PeterZaitsev wrote:
| Note AGPL license is in completely different class compared to
| BSD. Where BSD was level playing field allowing anyone to do
| commercial derivatives, now only Redis can do it.
|
| I also question whenever this decision comes from the pure change
| of heart rather than threat of Valkey... and if so what else
| should we expect in the future
| sammy2255 wrote:
| Kati Perri Hot Cold.
| pabs3 wrote:
| I would love to see Amazon offer a Redis service, comply with the
| AGPLv3 instead of using the other Redis licensing options and do
| revenue sharing to incentivise more commercial source-available
| projects to go that route.
| antirez wrote:
| Microsoft does this.
| thr0waway001 wrote:
| AW YEEAH!
| fmxsh wrote:
| Not seen any mention of KeyDB... Maybe I miss something obvious,
| but it solved my small use case that would stretch to the other
| side of Redis pay wall. I'm very happy with KeyDB.
| bradgessler wrote:
| I got a really stupid email from Redis(r)* a year ago that wanted
| me to put a disclaimer on the "first page" where Redis(r)*
| appeared on a website, as if it was a paper legal document.
|
| That was the very moment Redis(r)* died for me--I've never
| encountered a tech company that was so aloof about how tech
| works.
|
| Hopefully that damage is undone.
|
| --
|
| *Redis is a registered trademark of Redis Ltd. Any rights therein
| are reserved to Redis Ltd. Any use by Brad Gessler is for
| referential purposes only and does not indicate any sponsorship,
| endorsement or affiliation between Redis and Brad Gessler.
| hodgesrm wrote:
| It's not the only company that does this. That's why
| foundations typically ask for the trademark and logos as part
| of donating code.
| antirez wrote:
| You are right, and this attitude was reverted. You can't
| imagine what law departments can do even without explicit
| mandate, if not correctly moderated. Redis grew very fast in
| the middle of a CEO switch and I believe this created many
| issues like this one. Now, we should be past that. To provide
| an example in a very important field, client libraries, the
| decision was to help with the code sending PRs and don't
| interfer with things like trademarks.
| nicman23 wrote:
| yeah no thanks
| FooBarWidget wrote:
| Cloud vendors have been strip-mining open source for years, yet
| judging by user and contributor sentiment on forums such as HN,
| and the lack of OSI-approved licensing innovation, there's been
| no meaningful progress toward a solution. If anything, I get the
| feeling that the community is effectively more on the side of
| cloud vendors than on the side of authors. It seems the community
| at large doesn't care about authors' businesses suffering.
| Meanwhile, they largely don't oppose cloud vendors forking the
| latest open source version either.
|
| AGPL protects better against cloud strip-mining than most opens
| source licenses, but doesn't solve the fundamental problem of big
| cloud vendors easily outcompeting authors' businesses. AGPL only
| compels source sharing when the software is modified and offered
| over a network. But cloud providers can sidestep that by hosting
| the unmodified version. They excel at operations at scale and
| sales. Most open source consumers seem to care more about
| benefiting from this than about the authors' struggles.
|
| Fair source licenses -- such as SSPL and Elastic License -- while
| not OSI-compliant, are designed thoughtfully to balance authors'
| business and user needs, and don't impact the vast majority of
| users. They often only restrict cloud-scale commercial hosting,
| not self-hosting or local use. Yet they trigger disproportionate
| outrage.
|
| This is part of a broader problem: the community's lack of
| empathy for authors. It is unsustainable. Open source maintainer
| burnout has been going on for a long time now. The "indie" open
| source author community is aging. Meanwhile, many big open source
| projects come from large coporations who use open source as a
| loss leader.
|
| My impression is that:
|
| 1. the community at large is too stuck in ideological purity, in
| an age where the original FOSS ideology is a bad fit. Permissive
| licenses made sense when open source was a grassroots movement
| fighting for adoption -- not when it's powering trillion-dollar
| clouds.
|
| 2. People prioritize their own short-term interests too much.
|
| Companies are doing open source because of the momentum we built
| over the past few decades. This momentum is being eroded by
| maintainer burnout, fragmented ecosystems, and declining trust
| between authors and users. Yet the open source consumer and
| authorities such as FSF and OSI effectively neglect indie author
| health. This is going to collapse one day.
|
| If we want open source to survive as more than just free labor
| for cloud providers, we need a new movement--one that defends
| both user freedom and author sustainability.
| globular-toast wrote:
| The increased use of AGPL is a good sign. Hopefully more people
| start to realise copyleft licences are what is good for us
| (people, communities). Permissive licences are for big
| corporations.
|
| Looking at the comments it's amazing how much damage
| Ballmer/Microsoft did to free software with their "infection"
| rhetoric. Amazing that people would choose something that's good
| for Microsoft. Hint: if Microsoft likes something then you (a
| person) almost certainly want the complete opposite.
| xolve wrote:
| From BSD clause to AGPL, I see it as a huge win!
| danielovichdk wrote:
| Some of these open source licenses are somewhat flawed when it
| comes to building a business on things that are "free".
|
| Wouldn't it be possible to add a clause to some of these licenses
| that if you are using open source software and generate a certain
| amount of revenue from it, something has to be given back to the
| project.
|
| I totally understand that the software is meant to be free but
| isn't there a balance here, where at some point it must be
| enforced that some the money it generates in a business, must
| flow back to its contributors/project ?
|
| I have worked plenty of places where Redis was a thing that
| served at least some backbone for success for a business. Those
| places could pay a fee for generating revenue based on free
| software ?
|
| Does it make sense ?
| Spivak wrote:
| Yes, and it's called proprietary software which is free for
| non-commercial use and companies under a certain size. Docker
| Desktop uses this license.
| Voultapher wrote:
| IMO for that to make sense the license would have to be
| infectious and even then you run into the anything but trivial
| and gameable issue of splitting royalties among the tree of
| dependencies. Redis itself uses other open source libraries and
| so on. It's a tricky problem but it shouldn't stop us from
| trying, any amount of no strings attached funding for open
| source is better than what we have today. Personally I'd like
| to see it solved by diverting some amount of tax payer money to
| open source project maintainers, via some hopefully non
| conflicted government agency that ascertains what projects are
| more funding worthy than others.
| saltysalt wrote:
| Great news antirez, well done!
| manupati wrote:
| Engineering/ Designing applications with Apache Foundation's
| software's might be the first option, less pain. It is extremely
| stressful to change the base architecture. As, AGPL threatening
| commercial apps to open source their code. It is unfair changing
| the license after getting popular.
| amaran1999 wrote:
| I guess so
| amaran1999 wrote:
| yeah
| yesterdayjones wrote:
| AGPL: Uselessly open-source. Anyone who wants to make money with
| it, even if it's just one of many components in your tech stack,
| would have to open-source everything. This drives people to adopt
| the paid versions of the same software over the open-source
| version, and that's no doubt the point. Adopting the AGPL is a
| cold, calculated move.
| rootnod3 wrote:
| Nah, as much as I loved the original Redis, they dropped the ball
| with the license change. To me it looks like they realized way
| too late. There was a window for them to turn back, but now it
| looks like they are bleeding some way or another and just trying
| to recuperate. In the meantime, other drop-in solutions took
| over.
|
| Can't say that I feel sorry for them though.
___________________________________________________________________
(page generated 2025-05-02 23:01 UTC)