From where I left(antirez.com)
antirez.com
From where I left
https://antirez.com/news/144
460 comments
"Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc"
I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
With open-source software, a license is as much a social contract as it is a legal one. People contribute because they want to be part of a community building something which is beneficial to everyone. Everyone contributes where they can, and in turn takes what they need.
Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
Open source is a gift economy. Receiving a gift does not form a social contract that entitles you to future gifts. It is not a "rug pull" for someone to stop giving you gifts. The old versions of Redis are yours for all time. No one can take that away from you. In fact, Redis is still giving you gifts to this day, just with a different wrapping. The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
> Open source is a gift economy. Receiving a gift does not form a social contract that entitles you to future gifts
I think op was talking about contributors, who essentially gifted back. One might take offense if they were exchanging gifts with someone, and they open a pop-up store and sell what was gifted.
Also, it's also a tiny bit hypocritical to expect revenue sharing with Amazon without doing the same for contributors.
I think op was talking about contributors, who essentially gifted back. One might take offense if they were exchanging gifts with someone, and they open a pop-up store and sell what was gifted.
Also, it's also a tiny bit hypocritical to expect revenue sharing with Amazon without doing the same for contributors.
I guess there's a blind spot here.
antirez gave
community gave
most people assume that this create a new thing, a group, which has a shared past and value .. and should continue (i would agree to that personally)
"pure" open source advocacy would claim "nothing is ever to be expected in any future" (i can understand that too but find it a bit sad)
antirez gave
community gave
most people assume that this create a new thing, a group, which has a shared past and value .. and should continue (i would agree to that personally)
"pure" open source advocacy would claim "nothing is ever to be expected in any future" (i can understand that too but find it a bit sad)
I wonder how the oss community will react if the sequence of events were a little different.
1. Redis Inc creates a fork of Redis and names it say RedisNext or anything else(xyz) without a reference to Redis name at all.
2. Announces that, xyz is a fully compatible next gen version of Redis with enterprise features but it is only available under SSPL license.
3. Also announces that original Redis software is feature complete and will be under maintenance with only critical bug fixes.
This will be them playing by the same rules as any other third-party.
Will the community still manage to find fault with Redis Inc?
Will it feel entitled to continued updates or the Redis brand demanding a project handover to a different "group"?
1. Redis Inc creates a fork of Redis and names it say RedisNext or anything else(xyz) without a reference to Redis name at all.
2. Announces that, xyz is a fully compatible next gen version of Redis with enterprise features but it is only available under SSPL license.
3. Also announces that original Redis software is feature complete and will be under maintenance with only critical bug fixes.
This will be them playing by the same rules as any other third-party.
Will the community still manage to find fault with Redis Inc?
Will it feel entitled to continued updates or the Redis brand demanding a project handover to a different "group"?
Cannot speak for the community, but I'd assume that the right thing would be to handover Redis brand to a FOSS foundation.
Anything else just complicates things, like we see today, where Valkey and others are referenced as being Redis compatible (at least as far as RESP is concerned), and we either have specific clients (such as valkey-go), or existing Redis clients, that seem to want to maintain compatibility with most (all?) of them.
Anything else just complicates things, like we see today, where Valkey and others are referenced as being Redis compatible (at least as far as RESP is concerned), and we either have specific clients (such as valkey-go), or existing Redis clients, that seem to want to maintain compatibility with most (all?) of them.
Redis has a CLA so contributors can't use their gifts as leverage to control others.
https://redis.io/legal/redis-software-grant-and-contributor-...
https://redis.io/legal/redis-software-grant-and-contributor-...
I don't think you should conflate CONTROL with resentment or distaste or feeling betrayed or feeling misled. They aren't the same.
Even without a CLA, Redis was originally licensed BSD. Releasing code under a BSD license is making a promise that you are OK with people using your code for commercial purposes. If you as a developer express personal feelings of dissatisfaction that someone is doing with your gift what you gave them permission to do, in such a way that could be construed as reneging on your promise, then that would make you dishonorable and untrustworthy.
> Releasing code under a BSD license is making a promise that you are OK with people using your code for commercial purposes.
That's just a microcosm of the larger issue, isn't it? Contributors : Redis :: Redis : AWS - Redis gave Amazon the permission to host and make money off of Redis, but Redis was evidently salty about the state of affairs. I think contributors have reason to be salty too.
That's just a microcosm of the larger issue, isn't it? Contributors : Redis :: Redis : AWS - Redis gave Amazon the permission to host and make money off of Redis, but Redis was evidently salty about the state of affairs. I think contributors have reason to be salty too.
> in such a way that could be construed as reneging on your promise
Nothing could be construed in such a way, because such a reneging is not possible.
Nothing could be construed in such a way, because such a reneging is not possible.
Well in this case, antirez literally promised[1] they wouldn't change the license of the core away from BSD, and then Redis Labs did just that, and now antirez is speaking favorably of that decision.
[1]: https://antirez.com/news/120
[1]: https://antirez.com/news/120
Wow, I wasn't aware. @jart, do you have any harsh comments on the actual reneging of an actual promise? @antirez, do you have any kind of comments?
That post was from literally thousands of days ago and seems to be in relation to some confusion at that time.
Honestly to me you can see the tensions that led to the license change in that post. It’s largely consistent with what antirez has said in the post and in this thread.
Honestly to me you can see the tensions that led to the license change in that post. It’s largely consistent with what antirez has said in the post and in this thread.
They're also stealing the name of the community.
I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
It's honestly pretty horrible that a group of people can take centuries of man hours away from the community and tell the community to kick rocks when the software they're stealing would NEVER NEVER NEVER have had the traction it has if it were not OPEN SOURCE SOFTWARE TO BEGIN WITH.
There is a rash of thefts going on in broad daylight, and I think people need to start litigating. Its obscene and soulless and doesn't belong as an acceptable thing to do in society.
I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
It's honestly pretty horrible that a group of people can take centuries of man hours away from the community and tell the community to kick rocks when the software they're stealing would NEVER NEVER NEVER have had the traction it has if it were not OPEN SOURCE SOFTWARE TO BEGIN WITH.
There is a rash of thefts going on in broad daylight, and I think people need to start litigating. Its obscene and soulless and doesn't belong as an acceptable thing to do in society.
It is absurd to call this license change stealing when the previous work is still available under the original license. This is more like someone who is giving to the community, still continuing to give, but with a slightly more strict license. Do you expect someone who is doing philantropic work, gets contributions from others, but later becomes less philantropic to change their name?
> NEVER NEVER NEVER have had the traction
There is plenty of even closed source software which has traction in many domains, let alone software released under a license which as anti-rez points out allows the users to freely run their websites on redis, modify and redistribute code etc.(with the exception of running hosting services like Amazon).
For instance, it would be amazing and a great improvement if there was a top-quality CAD program with a similar license to Redis.
> NEVER NEVER NEVER have had the traction
There is plenty of even closed source software which has traction in many domains, let alone software released under a license which as anti-rez points out allows the users to freely run their websites on redis, modify and redistribute code etc.(with the exception of running hosting services like Amazon).
For instance, it would be amazing and a great improvement if there was a top-quality CAD program with a similar license to Redis.
You clearly feel very strongly about this topic; out of curiosity, are you a Redis contributor? If so, was your contribution done via your day job (paid time) or was it an outside/independent contribution?
> I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
Who should enforce such a requirement, and under what mechanism?
Open source licenses are copyright licenses, whereas product names are trademarks. These are separate legal concepts. Meanwhile "the community" isn't even a legal entity at all. As I understand it, there's nothing to "start litigating" here, and no one to litigate it.
Are you proposing that the OSI should change the OSD such that open source licenses must include mandatory trademark assignment to an independent nonprofit foundation? That's a rather extreme view if so.
> I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
Who should enforce such a requirement, and under what mechanism?
Open source licenses are copyright licenses, whereas product names are trademarks. These are separate legal concepts. Meanwhile "the community" isn't even a legal entity at all. As I understand it, there's nothing to "start litigating" here, and no one to litigate it.
Are you proposing that the OSI should change the OSD such that open source licenses must include mandatory trademark assignment to an independent nonprofit foundation? That's a rather extreme view if so.
> Receiving a gift does not form a social contract that entitles you to future gifts.
Certainly, but if you exchange gifts with someone every christmas, have been doing so for a decade, and they suddenly stop giving you one, or give you an unpolished one where they previously cleaned it to a shine, you are perfectly within your rights to be a bit miffed at that, and withold your own.
People can say the new license is reasonable (and by all reasonable measures it probably is) but that’s not how it feels, and that’s the important part.
Certainly, but if you exchange gifts with someone every christmas, have been doing so for a decade, and they suddenly stop giving you one, or give you an unpolished one where they previously cleaned it to a shine, you are perfectly within your rights to be a bit miffed at that, and withold your own.
People can say the new license is reasonable (and by all reasonable measures it probably is) but that’s not how it feels, and that’s the important part.
Reciprocality over time building trust is in fact the basis of gift economies. Please read some David Graeber.
Open source is not a gift economy, and is in fact a different, and long established social contract. Never has this misplaced metaphor been used to describe open source, nor do the contributers demand any return that amounts to an "entitlement to future gifts".
If a company's survival is threatened by people using its open-source software, then maybe it shouldn't be open source. Open source software (to me) says I should be able use the software for any purpose, including commercial ones.
That isn't really the case here. It didn't start with a company. The company came along independently, effectively took control of an open source project that was already well established. They found that support alone wasn't enough to be profitable on and have been lashing out at the community that built around the original project, including independent opensource clients.
It's not that the company shouldn't have the code as open source. The company shouldn't exist in the first place and we're all suffering for it.
It's not that the company shouldn't have the code as open source. The company shouldn't exist in the first place and we're all suffering for it.
I agree. It seems that "open core"[1] is a failed experiment. I'm hopeful the idea will be replaced either by governments being smarter about the computers, or companies agreeing to sponsor foundations, or... something. But clearly taking venture investment to build OSS and turn it into a profitable enterprise is an idea that has been thoroughly shown to be flawed.
[1] aptly named if you think about the nuclear power analogy :)
[1] aptly named if you think about the nuclear power analogy :)
It’s the entire premise of public goods, and the sustainable funding model for that would be through government funding or funding of open source foundations like the CNCF. For example, the IETF standards body is founded by the global charitable organization the Internet Society. How do we continue to build on this public goods funding model for projects like this?
> seems that "open core"[1] is a failed experiment.
I don't think the jury is out. If you look at nginx, you won't see a lot of complains over nginx plus. The nginx brand still has a lot of goodwill and a few open source projects seem to be peacefully building upon it without any issue.
I don't think the jury is out. If you look at nginx, you won't see a lot of complains over nginx plus. The nginx brand still has a lot of goodwill and a few open source projects seem to be peacefully building upon it without any issue.
> It is not a "rug pull" for someone to stop giving you gifts.
I'm not sure that the developers contributing code from outside the company see it that way. An easy way to tell if contributors see a license change as a rug pull is if the forks that happen after the rug pull get traction.
> The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
Most of the time, though, open source limits growth - and doesn't threaten the original author's startup. This is a really important distinction because there is a trade-off in choosing open source as a marketing strategy - you do potentially face competition from other contributors, users and parasites that will moderate growth.
I'm not sure that the developers contributing code from outside the company see it that way. An easy way to tell if contributors see a license change as a rug pull is if the forks that happen after the rug pull get traction.
> The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
Most of the time, though, open source limits growth - and doesn't threaten the original author's startup. This is a really important distinction because there is a trade-off in choosing open source as a marketing strategy - you do potentially face competition from other contributors, users and parasites that will moderate growth.
It absolutely is though. Do you not see any value in bug fixes? Do you think software never needs to be updated? We all know security updates are crucial, and pretending you can just run the old version forever is insane. If I contributed to redis in the past I did so under the assumption that I was contributing to a product that I could actually keep using. But instead they took all those contributions and gave the contributors a huge middle finger by denying them security updates and fixes.
And sure, you can say "just do the bug fixes yourself". But if I knew that was going to be the case, I'd never have bothered to contribute.
And sure, you can say "just do the bug fixes yourself". But if I knew that was going to be the case, I'd never have bothered to contribute.
> If I contributed to redis in the past I did so under the assumption that I was contributing to a product that I could actually keep using
It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
You're asking "Do you not see any value in bug fixes? Do you think software never needs to be updated?" from the contributors' and users' point of view. But the same exact issue exists from the maintainers' point of view.
A lot of people in this thread are commenting as if an open source contribution is a purely altruistic act by the contributor which then solely benefits the maintainers. That's far from the case in reality. Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
You're asking "Do you not see any value in bug fixes? Do you think software never needs to be updated?" from the contributors' and users' point of view. But the same exact issue exists from the maintainers' point of view.
A lot of people in this thread are commenting as if an open source contribution is a purely altruistic act by the contributor which then solely benefits the maintainers. That's far from the case in reality. Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
> It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
Correct, that's generally how open source works. You make a contribution, they merge it, and then the assumption is that it is maintained by the maintainers. You seem to act like this is an odd assumption, even though it is and has been the reality for pretty much every open source project ever.
> But the same exact issue exists from the maintainers' point of view.
Right, it's their "job". Maintaining the software. It's pretty much in the name. That's what happens when you accept contributions. They get merged into the software project, and then you (the maintainer) are responsible for maintaining it, or removing the functionality in a subsequent release. That's why code review happens where you consider the maintenance burden, and features sometimes don't get merged.
If this doesn't sound appealing then don't become the maintainer of an open source project.
> Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Sure, and they could've kept it private so it only benefits them and/or their employer. But instead they chose to open source it in the hopes that
1) The maintainers will maintain it
2) It might benefit someone else
That's the whole deal. You're essentially trading your contributions for future maintenance.
Correct, that's generally how open source works. You make a contribution, they merge it, and then the assumption is that it is maintained by the maintainers. You seem to act like this is an odd assumption, even though it is and has been the reality for pretty much every open source project ever.
> But the same exact issue exists from the maintainers' point of view.
Right, it's their "job". Maintaining the software. It's pretty much in the name. That's what happens when you accept contributions. They get merged into the software project, and then you (the maintainer) are responsible for maintaining it, or removing the functionality in a subsequent release. That's why code review happens where you consider the maintenance burden, and features sometimes don't get merged.
If this doesn't sound appealing then don't become the maintainer of an open source project.
> Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Sure, and they could've kept it private so it only benefits them and/or their employer. But instead they chose to open source it in the hopes that
1) The maintainers will maintain it
2) It might benefit someone else
That's the whole deal. You're essentially trading your contributions for future maintenance.
I'm well acquainted with open source maintenance; one of my open source projects has been downloaded over 2 million times, and another is imported by over 8000 other repos on GitHub. I'm not "acting like this is an odd assumption" but rather my point was to consider the economic side from the maintainers' point of view, which many people in this thread are completely ignoring.
As you said above, maintainers don't have to accept your contribution, and if they do, they always have the option of removing it in a future release. And if the maintainers use a CLA or other copyright assignment mechanism, they also have the option of changing the license for future releases. So why are you assuming you can keep using future versions of the product forever if you contribute to it and sign a CLA?
> Sure, and they could've kept it private so it only benefits them and/or their employer
But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
My point in all this is that contributing to open source often benefits the contributor more than the maintainer, and yet people act like it primarily is an altruistic gift from the contributor which solely benefits the maintainer / product owner.
As you said above, maintainers don't have to accept your contribution, and if they do, they always have the option of removing it in a future release. And if the maintainers use a CLA or other copyright assignment mechanism, they also have the option of changing the license for future releases. So why are you assuming you can keep using future versions of the product forever if you contribute to it and sign a CLA?
> Sure, and they could've kept it private so it only benefits them and/or their employer
But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
My point in all this is that contributing to open source often benefits the contributor more than the maintainer, and yet people act like it primarily is an altruistic gift from the contributor which solely benefits the maintainer / product owner.
> But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
Well yeah, that's the point. Trading contributions vs maintenance burden.
> My point in all this is that contributing to open source often benefits the contributor more than the maintainer
And yet they choose to do it... Why?
Well yeah, that's the point. Trading contributions vs maintenance burden.
> My point in all this is that contributing to open source often benefits the contributor more than the maintainer
And yet they choose to do it... Why?
I said it provides more benefit to the contributor than the maintainer, but I did not say that it provides no benefit to the maintainer. Your question doesn't logically follow.
That's exactly my point: It still benefits the maintainer. So they benefited from contributors, then fucked them over later, violating the social contract (but not necessarily the software license because CLAs yadda yadda).
Again, my point in response is that the contributor received more benefits (in the form of code review and ongoing maintenance) than the maintainer. We're talking in circles here.
As long as the contributor isn't a cloud provider, they can continue to use the software unimpeded under the new license. Their contribution continues to be maintained by the maintainers. The contributor hasn't been "fucked over" in any way.
If the contributor is a cloud provider, they can choose to enter into a commercial licensing / revenue share agreement and continue to use the software unimpeded. Or they can decline and use/create a fork, in which case any so-called fucking-over is clearly mutual, because the contributor wants to profit from the software explicitly without making its ongoing development financially sustainable for its original maintainers. That's parasitic behavior.
I must ask, have you contributed to Redis? Or are you just expressing outrage on behalf of other people who actually contributed to Redis and may not actually even share in said outrage?
If the latter, why are you so emotionally invested in this topic? And have you ever been on the other side of the coin, maintaining a widely-used open source project?
As long as the contributor isn't a cloud provider, they can continue to use the software unimpeded under the new license. Their contribution continues to be maintained by the maintainers. The contributor hasn't been "fucked over" in any way.
If the contributor is a cloud provider, they can choose to enter into a commercial licensing / revenue share agreement and continue to use the software unimpeded. Or they can decline and use/create a fork, in which case any so-called fucking-over is clearly mutual, because the contributor wants to profit from the software explicitly without making its ongoing development financially sustainable for its original maintainers. That's parasitic behavior.
I must ask, have you contributed to Redis? Or are you just expressing outrage on behalf of other people who actually contributed to Redis and may not actually even share in said outrage?
If the latter, why are you so emotionally invested in this topic? And have you ever been on the other side of the coin, maintaining a widely-used open source project?
It is really hard to believe that no one defends antirez&co as protecting themselves from greedy overpriced SaaS businesses who were parasiting others hard work. What about them saases breaking a social contract of giving reasonable prices adequate to the effort put into a product (or a wrapper around the product)?
It's possible to hold both positions at the same time.
Lots of people defend these licenses on exactly those grounds. I, too, find it pretty mystifying that this seems to be a minority perspective here. At least this seems to be the case among the people who speak up when this comes up here. It's hard to know if there is a less noisy majority who feels differently about it.
I think the "silent majority" is just fine with this change. The OSS "extremists" will certainly be the noisiest about this - everyone else will continue on with life as usual, especially if they have an understanding of the concept of business pressures.
That's what I think too, but it's hard to know for certain.
If you just call SaaS "hosting" does that change your view of things? Because I remember when commercial hosting for free software was actively encouraged.
Yeah, this is weird. The one restriction is one you probably dont care about because you're not amazon or azure yet some people still freak out like youve taken their toys away.
Truly odd.
Truly odd.
It's not that weird. With a FOSS license, I know I can use a program for anything I choose to and the terms will never change. I might launch a startup with a friend tomorrow using a package and complying with its license terms, and a million dollars later we're still legally entitled to use it.
Adding constraints later is a non-fallacious slippery slope. The restrictions Redis added aren't directly onerous to 99.999% of users, but now the world is divided into people who are allowed to use it at will, and people who can only use it in certain ways (or not at all). That's an enormous change from a FOSS license. And if they change it today specifically to lock out Amazon, will they change it again tomorrow to lock out my startup? The thing is, now that they've established precedent, there's no way of knowing what'll happen later.
Again, I know I can use GPL or MIT or BSD software for anything I want as long as I play by the exact same rules as everyone else. There's nothing that says you can use it but I can't. The difference between Free to non-Free is vast, even when I'm not affected (yet).
Adding constraints later is a non-fallacious slippery slope. The restrictions Redis added aren't directly onerous to 99.999% of users, but now the world is divided into people who are allowed to use it at will, and people who can only use it in certain ways (or not at all). That's an enormous change from a FOSS license. And if they change it today specifically to lock out Amazon, will they change it again tomorrow to lock out my startup? The thing is, now that they've established precedent, there's no way of knowing what'll happen later.
Again, I know I can use GPL or MIT or BSD software for anything I want as long as I play by the exact same rules as everyone else. There's nothing that says you can use it but I can't. The difference between Free to non-Free is vast, even when I'm not affected (yet).
Your answer is "it's not that weird what if I wanted to launch a startup competing with azure and amazon"?
Well, Id say in that case youve got waaaay bigger problems than a license.
>Adding constraints later is a non-fallacious slippery slope.
No, it's very much a fallacious slippery slope. Constraints are the very essence of licenses and contracts.
Well, Id say in that case youve got waaaay bigger problems than a license.
>Adding constraints later is a non-fallacious slippery slope.
No, it's very much a fallacious slippery slope. Constraints are the very essence of licenses and contracts.
> But something far more valuable was lost: the community's trust.
But before that the community turned its back on Redis Ltd., when it let those cloud offerings from others thrive. Once the “community” got that going, these consequences were inevitable.
But before that the community turned its back on Redis Ltd., when it let those cloud offerings from others thrive. Once the “community” got that going, these consequences were inevitable.
> With open-source software, a license is as much a social contract as it is a legal one
Funny how when these license changes started happening people said the exact opposite - that the license is the license and if they didn’t want to be Jeff’d they should have used a difference license.
Funny how when these license changes started happening people said the exact opposite - that the license is the license and if they didn’t want to be Jeff’d they should have used a difference license.
> Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers?
Thing is, this sentence could equally be applied to the big cloud free riders.
Why should anyone, business or volunteer, write software that benefits FAANGs that don't pay their fair share?
Thing is, this sentence could equally be applied to the big cloud free riders.
Why should anyone, business or volunteer, write software that benefits FAANGs that don't pay their fair share?
No well-known permissive open software license includes any promise to do future development, much less to make it available under the same license terms. A key draw of permissive licensing is that anyone can fork and put new work under new and different terms.
Who would promise perpetual maintenance for nothing? What organization would sign up to be the only one that can't change terms for improvements?
I don't think "social contract" makes sense here. There's no sovereign power involved. In the sense used, "social contract" essentially means "not in the contract"---as in not in the terms. It's a back door for saying things that were never put down ought to be treated like they were in the license file, just because one side really wants them and doesn't want to DIY or pay for them.
If there are disappointed expectations, that's another thing. But being even very disappointed, and being able to find other like-minded people who would prefer no disruption and new freebies forever, doesn't make unfounded expectations enforceable, nor should it.
I'd be extremely careful speaking of any singular "community". And of assuming that everyone in it expected Redis or another similar project to work just like Linux or other exceptional projects. Most devs dealing with open source have a project relicense---among many others than simply grind to a halt---at some point in their career. For some devs, Redis may have been the first. Others "adopted" Redis knowing the risk and accepting it.
Who would promise perpetual maintenance for nothing? What organization would sign up to be the only one that can't change terms for improvements?
I don't think "social contract" makes sense here. There's no sovereign power involved. In the sense used, "social contract" essentially means "not in the contract"---as in not in the terms. It's a back door for saying things that were never put down ought to be treated like they were in the license file, just because one side really wants them and doesn't want to DIY or pay for them.
If there are disappointed expectations, that's another thing. But being even very disappointed, and being able to find other like-minded people who would prefer no disruption and new freebies forever, doesn't make unfounded expectations enforceable, nor should it.
I'd be extremely careful speaking of any singular "community". And of assuming that everyone in it expected Redis or another similar project to work just like Linux or other exceptional projects. Most devs dealing with open source have a project relicense---among many others than simply grind to a halt---at some point in their career. For some devs, Redis may have been the first. Others "adopted" Redis knowing the risk and accepting it.
> With open-source software, a license is as much a social contract as it is a legal one
Says who? I completely disagree. A license only applies to the current work done. It does not compel someone to keep dedicating time to a project for free because they also did that in the past. People are allowed to change, even if they once released some code under a different license.
Is the old code still available under the same license ? That’s the only contract I care about , both legal and social.
I am just as much a member of this FLOSS community as others , and I never got the memo about this social contract story. I don’t think it’s true. My trust hasn’t been affected at all.
I understand your point I just get annoyed being lumped into it. Not everyone feels that way.
(But of course my opinion does matter less than actual contributors to Redis ! That’s totally fair.)
Says who? I completely disagree. A license only applies to the current work done. It does not compel someone to keep dedicating time to a project for free because they also did that in the past. People are allowed to change, even if they once released some code under a different license.
Is the old code still available under the same license ? That’s the only contract I care about , both legal and social.
I am just as much a member of this FLOSS community as others , and I never got the memo about this social contract story. I don’t think it’s true. My trust hasn’t been affected at all.
I understand your point I just get annoyed being lumped into it. Not everyone feels that way.
(But of course my opinion does matter less than actual contributors to Redis ! That’s totally fair.)
And it's obviouse that when contributors feel their efforts may be co-opted or undermined, they’re less likely to engage
I read this as you saying...
You gave us a bunch of stuff for free. You are now putting some conditions on that for new stuff you do. And that makes me sad.
I get the "feelings" part of this. When the world changes, even for the better, it can make us sad.
Equally this license better supports the stuff I am getting for free, and penalizes some giant corporation with buckets of money. And I keep getting stuff for free. So (frankly) I'm happy.
So meh. Is trust broken? Is the community harmed? Should we expect more moves along these lines? Do I see all decisions as clearly black and white - good or evil? Or is there more nuance?
For those upset at AWS no longer getting Redis for free, you can of course fork it and carry on developing for AWS. Those who don't like new redis can carry on running the old one. Those who want new redis can, well, download and use it.
Frankly they didn't hurt my feelings. They're developing. I still get it. I'm happy, not sad.
You gave us a bunch of stuff for free. You are now putting some conditions on that for new stuff you do. And that makes me sad.
I get the "feelings" part of this. When the world changes, even for the better, it can make us sad.
Equally this license better supports the stuff I am getting for free, and penalizes some giant corporation with buckets of money. And I keep getting stuff for free. So (frankly) I'm happy.
So meh. Is trust broken? Is the community harmed? Should we expect more moves along these lines? Do I see all decisions as clearly black and white - good or evil? Or is there more nuance?
For those upset at AWS no longer getting Redis for free, you can of course fork it and carry on developing for AWS. Those who don't like new redis can carry on running the old one. Those who want new redis can, well, download and use it.
Frankly they didn't hurt my feelings. They're developing. I still get it. I'm happy, not sad.
I'm embarrassed to admit that I hadn't fully taken into account that those contributions do at least remain under the BSD license and hence stay open under those original terms. Thanks for reminding me of that.
Note though, the code is not Music, it rots quickly without maintenance. The "social contract" of contributing the code is what it will be maintained by collective community, otherwise many companies would just keep it as private forks.
It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions
It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions
That may be true of node.js codebases, but last time I checked Redis was written in C and only depends on ISO and POSIX standardized stuff. I doubt there's been any leftpads that have broken the old versions by now.
It is not just compatibility, there are bugs, but most important security issues which are constantly being discovered.
Which makes rot a good metaphor actually. The DNA of a tree which becomes infected with a new mutation of a fungus didn't change, the fungus did.
Code in which a vulnerability is discovered is in the same position. It's developed a susceptibility to a new force malevolent to its purpose. It doesn't have to change to rot, it suffices for the world to change around it.
Code in which a vulnerability is discovered is in the same position. It's developed a susceptibility to a new force malevolent to its purpose. It doesn't have to change to rot, it suffices for the world to change around it.
It's not an error at all, Simon! Because different setups in the past lead exactly to the scenario that you depicted. Examples: projects that requested signed copyright transfer for each patch (even GNU projects required this). But also what is more insidious is that very complex projects, while sometimes BSD or similarly licensed, were made completely proprietary (and not under the MongoDB / Redis circumstances, but just to turn proprietary for other reasons) but they were so complex internally that basically you can't do anything with the code, without paying like... 50 engineers to study it for six months. So it is an actual danger, but not in the case of BSD + projects that have an acceptable barrier to entry to be understood, fixed, modified, ...
That is true, and that is how Valkey and other forks are moving forward. But the value wasn't just in the code- many folks contributed value by writing blog posts, making videos, and writing books or otherwise promoting "Redis". The Redis trademark owners had every legal right to change what "Redis" means by changing the license, but it creates a massive headache and a practically impossible task for everyone that gave so much to promoting the project to change all of these references.
Folks like to cite MongoDB as some great example, but Redis had significant community contributions in recent years. And AWS never used any Mongo code.
Folks like to cite MongoDB as some great example, but Redis had significant community contributions in recent years. And AWS never used any Mongo code.
In a sense valkey is the main line and redis is now the fork. Valkey is about the same except losing the trademark. It’s similar to Hudson and Jenkins. It’s not so clear cut with OpenSearch.
IMHO the "real" Redis is not about licensing, but about design (as long as the license is acceptable, as I think it is in both cases). We will see.
That’s a nice way of looking at it. It’s quite an influential project. I’m just now thinking of taking more direct inspiration from it for a micro-library for webassembly.
I wish you success in Redis Labs and thanks for Redis. In my other comment I said I never considered using Redis under the new license, but I didn’t say that I never would consider it, and I think I would if I found myself on a project that needs a key value database with enterprise support or more bells and whistles. I think it has its place, and to me it is an awful lot like postgres and EnterpriseDB, especially if Redis Labs gives its blessing, directly or tacitly, to adding this new vector type to valkey.
I wish you success in Redis Labs and thanks for Redis. In my other comment I said I never considered using Redis under the new license, but I didn’t say that I never would consider it, and I think I would if I found myself on a project that needs a key value database with enterprise support or more bells and whistles. I think it has its place, and to me it is an awful lot like postgres and EnterpriseDB, especially if Redis Labs gives its blessing, directly or tacitly, to adding this new vector type to valkey.
What’s valkey?
It's the Redis fork with the most resources and the most backing. It's well funded and it sits under the Linux foundation: https://www.linuxfoundation.org/press/linux-foundation-launc...
and remains truly open-source, unlike Redis.
Redis from Redis Labs, available under a choice of its own license or the SSPL, is pretty close to truly open-source, IMO closer to it than the BUSL, which is another source-available license. It is pretty similar to the AGPLv3, and they even credibly applied to get it OSI-approved.
https://blog.tidelift.com/what-i-learned-from-the-server-sid... https://opensource.stackexchange.com/questions/11291/how-to-...
What it isn't close to is the original license, which is a permissive open source license.
The license switch-up is why a fork was needed. Matrix did a similar thing with the AGPL which alas, doesn't have a major fork. https://element.io/blog/element-to-adopt-agplv3/ Although it's technically still open source, they didn't do right by the contributors to it.
https://blog.tidelift.com/what-i-learned-from-the-server-sid... https://opensource.stackexchange.com/questions/11291/how-to-...
What it isn't close to is the original license, which is a permissive open source license.
The license switch-up is why a fork was needed. Matrix did a similar thing with the AGPL which alas, doesn't have a major fork. https://element.io/blog/element-to-adopt-agplv3/ Although it's technically still open source, they didn't do right by the contributors to it.
Every license is a unique snowflake, but if you're going to stay sane and get on with your life you need some categories and lines. Redis is not available under a license that is open-source in any of the usual senses - not OSI-approved, not DFSG-compatible, not FSF-approved. That is a big deal. Matrix remains open source under a license that meets all those criteria. It's not a technical distinction, it's the line in the sand that stops open-source from being whittled away to nothing.
It's not truly open source if the most basic freedom, freedom to use code for any purpose, is not fulfilled.
I hate that people feel the need to so strongly attach the generic term open source to Open Source InitiativeⓇ OSI Certified™ license's marketing (anti Stallman) propaganda as the one and only true open source. Redis' license is open in all the ways that matter.
OSI has nothing to do with being anti-Stallman. (I think the most anti-Stallman person is, unfortunately, Stallman himself, having done so much to destroy his own reputation.)
Even Stallman would agree that nothing can be open source if the freedom 0, freedom to use software for any purpose, is not provided. SSPL does not grant this freedom.
Even Stallman would agree that nothing can be open source if the freedom 0, freedom to use software for any purpose, is not provided. SSPL does not grant this freedom.
fork of redis https://github.com/valkey-io/valkey just before the transition to their new source available licenses
Ah thanks. Is this by AWS or similar?
Yes: https://www.linuxfoundation.org/press/linux-foundation-launc...
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey.
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey.
Cloud providers offer productized versions of Redis, so their interest in Valkey should be obvious :)
Yep. It is still a bit ironic that the community rallied behind Big Tech instead of a small startup though. Just saying.
The community rallied around a community fork with an open source licence instead of a VC funded startup with a penchant for changing licences.
Microsoft appears to be the only major player that isn't going with Valkey and established some sort of licensing deal with Redis [0].
[0]: https://redis.io/blog/introducing-azure-managed-redis
[0]: https://redis.io/blog/introducing-azure-managed-redis
Microsoft also last year released their own Redis-client-compatible key-value store, Garnet: https://github.com/microsoft/garnet
> Yep. It is still a bit ironic that the community rallied behind Big Tech instead of a small startup though. Just saying.
The community rallied behind the project that ensures the software they care about remains free and open and available to all without the risk of being blind-sided.
The community rallied behind the project that ensures the software they care about remains free and open and available to all without the risk of being blind-sided.
Around competitive prices and terms rather than a monopoly.
Interesting to see Google there. They have LevelDB.
Redis and LevelDB are very different, with different use cases.
LevelDB is a key-value storage library that writes to disk. It's the sort of thing you could use as the storage layer for a relational database.
On the other hand, Redis is an in-memory key-value database server.
LevelDB is a key-value storage library that writes to disk. It's the sort of thing you could use as the storage layer for a relational database.
On the other hand, Redis is an in-memory key-value database server.
I've only looked briefly at leveldb, but IIRC redis is _hugely_ more featureful than leveldb (which I'm sure is a great fit where it's used).
Persistent key-value database with network interface https://packages.debian.org/testing/database/valkey-server
"I can understand that, but the thing about the BSD license is that such value never gets lost."
That is one side of the coin: value never gets lost!
The other side is that the BSD license is very clear what it allows. It's a good thing that there are licenses that allow what Redis did. It is also a good thing that there are other licenses which can help prevent what Redis did.
It is our choice as developers and we should never blame others for exercising the rights we granted them.
That is one side of the coin: value never gets lost!
The other side is that the BSD license is very clear what it allows. It's a good thing that there are licenses that allow what Redis did. It is also a good thing that there are other licenses which can help prevent what Redis did.
It is our choice as developers and we should never blame others for exercising the rights we granted them.
Put another way, many people have contributed to Bezos' bottom line for free. The restriction is annoying but there should probably be a better way to get a piece of that huge value for everyone who generates it, mostly thanklessly. Some kind of OSS tax proportional to profitability would make some sense, as annoying as that might be to implement or deal with.
This idea is similar to what some countries do around music: artist register with an government identity that collects copyright fees from venues that play music - live or otherwise (bars, clubs, theatres included).
The government identity then distributes those monies to the artists according to playlists collected from said venues.
It works for big acts, for small acts the overhead tends to consume the payouts.
The government identity then distributes those monies to the artists according to playlists collected from said venues.
It works for big acts, for small acts the overhead tends to consume the payouts.
> However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
You can do this without fucking over past contributors. Just... Don't change the license. Then still do all that other stuff. They're not contradictory.
You can do this without fucking over past contributors. Just... Don't change the license. Then still do all that other stuff. They're not contradictory.
What I dislike about the license change is that by trying to extract an extra dollar from Amazon&Google, the entire community gets hurt in the process.
Can I "dnf/apt install redis" on my Fedora or Debian install? I cannot, it's no longer packaged because it's no longer open source.
Can I go buy a shared hosting plan and get Redis? Or a small PaaS that sits on top of AWS? I cannot, because we have decided that every hoster is now as exploitative as Amazon, regardless of their margin.
For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
Disclaimer: I work for a PaaS.
Can I "dnf/apt install redis" on my Fedora or Debian install? I cannot, it's no longer packaged because it's no longer open source.
Can I go buy a shared hosting plan and get Redis? Or a small PaaS that sits on top of AWS? I cannot, because we have decided that every hoster is now as exploitative as Amazon, regardless of their margin.
For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
Disclaimer: I work for a PaaS.
> Can I "dnf/apt install redis" on my Fedora or Debian install? I cannot, it's no longer packaged because it's no longer open source.
to be fair that's more an issue with linux distrib than with redis
to be fair that's more an issue with linux distrib than with redis
> For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
Yeah, but the Internet community at large took care about funding. MySQL always had the commercial support leg to stand on, and Apache httpd... looking at the contributor list [1], it's a healthy mix of universities, large companies (IBM, HP), ISPs (Vodafone, Cable & Wireless), hosters (Rackspace), small consultancies and individual private contributors.
In contrast, the megacorporations are largely absent from FOSS contributions (the exceptions being Netflix and partially, where it suits them, Google, Microsoft and Apple).
[1] https://httpd.apache.org/contributors/
Yeah, but the Internet community at large took care about funding. MySQL always had the commercial support leg to stand on, and Apache httpd... looking at the contributor list [1], it's a healthy mix of universities, large companies (IBM, HP), ISPs (Vodafone, Cable & Wireless), hosters (Rackspace), small consultancies and individual private contributors.
In contrast, the megacorporations are largely absent from FOSS contributions (the exceptions being Netflix and partially, where it suits them, Google, Microsoft and Apple).
[1] https://httpd.apache.org/contributors/
Valkey, the Redis fork, is currently sponsored by Ampere, AlmaLinux OS Foundation, Broadcom, DigitalOcean, Memurai, NetApp, Aiven, Alibaba Cloud, AWS, Canonical, Chainguard, Ericsson, Heroku, Huawei, Google Cloud, Oracle, Percona, Snap Inc and Verizon[0].
There is enough interest in sponsoring the development of infrastructure software. But if you want to build a "commercial arm", get VC funding[1][2] and earn millions, then it will never be enough. And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
[0] https://www.linuxfoundation.org/press/valkey-welcomes-new-pa...
[1] https://redis.io/press/redis-labs-raises-100-million-series-...
[2] https://redis.io/press/redis-labs-110-million-series-g-led-b...
There is enough interest in sponsoring the development of infrastructure software. But if you want to build a "commercial arm", get VC funding[1][2] and earn millions, then it will never be enough. And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
[0] https://www.linuxfoundation.org/press/valkey-welcomes-new-pa...
[1] https://redis.io/press/redis-labs-raises-100-million-series-...
[2] https://redis.io/press/redis-labs-110-million-series-g-led-b...
How much did AWS and those contribute until they got locked out of using Redis? That's what's interesting. That they now have to sponsor an alternative isn't exactly surprising.
How do they manage the payout to the individual contributors?
If I fix a typo, do I get a payout at the end of year for my work?
IMO that’s what it comes down to, that contributors that work for these companies have they contributions reimbursed through their salary. Other contributors might not earn that salary.
If I fix a typo, do I get a payout at the end of year for my work?
IMO that’s what it comes down to, that contributors that work for these companies have they contributions reimbursed through their salary. Other contributors might not earn that salary.
One of my clients is using OpenSearch instead of Elastic.
Big mistake. It's already behind elastic search, and worse too. It has bugs, weird behaviour and updates are already slowing.
On top of that, elastic have cunningly changed parts of their offerings to mean OpenSearch users can't use the elastic examples. For example they completely changed their .Net Core library so all new documentation in elastic is totally useless for OpenSearch.
They've added a way in the dashboard to run SQL for quick queries, etc. The OpenSearch version of that is buggy as hell, and for all intents and purposes useless because if you get the SQL wrong it just shows a blank screen instead of the error.
I'd be very aware of those problems, which appeared pretty rapidly, when going to these big corporation supported branches.
You are asking for trouble and are totally dependant on the company keeping that branch going who have little incentive to maintain or improve it now you're locked into their PaaS.
Big mistake. It's already behind elastic search, and worse too. It has bugs, weird behaviour and updates are already slowing.
On top of that, elastic have cunningly changed parts of their offerings to mean OpenSearch users can't use the elastic examples. For example they completely changed their .Net Core library so all new documentation in elastic is totally useless for OpenSearch.
They've added a way in the dashboard to run SQL for quick queries, etc. The OpenSearch version of that is buggy as hell, and for all intents and purposes useless because if you get the SQL wrong it just shows a blank screen instead of the error.
I'd be very aware of those problems, which appeared pretty rapidly, when going to these big corporation supported branches.
You are asking for trouble and are totally dependant on the company keeping that branch going who have little incentive to maintain or improve it now you're locked into their PaaS.
Sort of. "Locked in" is a strong word, considering Redis will run on AWS just fine, either by buying their product or spinning up a couple EC2s and `docker run redis` (which is allowed under the license since you aren't reselling it). Yes, harder than clicking a button in the AWS console, but it's not like you're stuck completely.
I understand it more for OpenSearch, because scaling that is annoying, but Redis has built in cluster mode stuff that works fine without having Amazon's magic control plane.
(we're also using OpenSearch hosted by AWS but not for anything complicated, so haven't encountered what you have. seems like Elastic 7.10, frozen in time, which is fine for us. they forked the old version of the .NET library for people to continue using, but I guess you need to use the archived docs.)
I understand it more for OpenSearch, because scaling that is annoying, but Redis has built in cluster mode stuff that works fine without having Amazon's magic control plane.
(we're also using OpenSearch hosted by AWS but not for anything complicated, so haven't encountered what you have. seems like Elastic 7.10, frozen in time, which is fine for us. they forked the old version of the .NET library for people to continue using, but I guess you need to use the archived docs.)
> Valkey, the Redis fork, is currently sponsored by Ampere, AlmaLinux OS Foundation, Broadcom, DigitalOcean, Memurai, NetApp, Aiven, Alibaba Cloud, AWS, Canonical, Chainguard, Ericsson, Heroku, Huawei, Google Cloud, Oracle, Percona, Snap Inc and Verizon[0].
Took 'em long enough to realize. I 'member the Heartbleed catastrophe and what pittances OpenSSL got [1]. And as always, there's an XKCD fitting just too damn well [2].
> And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
That's the thing... conflicting interests, incentives and most especially expectations. Let's say I'm unhappy with the current state of managing a fleet of hardware servers and VMs, especially after the VMware disaster.
I could bite the bullet and pay VMware. I could go and get OpenStack running. It would be an utter pain to set up and run (because it is funded primarily by universities who don't have the constraint of "administration time effort" because that's what you have aspiring student volunteers for, but instead do have the constraint that it's hard to get hardware so OpenStack has to be flexible enough to support a ton of crap that any enterprise would have sent off to e-waste a decade ago). I could go and get Proxmox up and running, but it's AGPL so corporate legal may chew up my ass. Or I could whip up my own orchestrator, fit to work for my needs, and say I open-source it... and it might even be decent enough others may want to use it as well.
But then, many of these "others" won't be willing to pay for support, but they'll flood the Github issue tracker with all kinds of stuff that I now have to care about (because who wants to present a Github repository with dozens if not hundreds of open issues?), tons of feature wishes and demands (because obviously while I may run Cisco network gear for SDN, someone else may be a Juniper or whatever shop, and wants integration for that), and in the worst case someone gets 0wned because of some vulnerability that I might not even have realized - and I get the shitstorm for it, my name gets dragged through the mud like it was for OpenSSL or log4j.
So, basically I'm left with the choice between either accepting being labeled "lazy" (for not caring about "my project" enough) or to raise enough money to get the product competitive with what the other players are offering, and the only way for that is to go the VC route. And unfortunately, unlike old-school "startup capital", modern VCs want (or rather, because they're following spray-and-pray in their hunt for the 1-out-of-100 unicorn chance, have to aim for) the expectation of insane hyper-growth.
And then, one day, Amazon might go and say "hey, this FOSS thing is pretty cool, we'll add some glue code to integrate with IAM, backups and high availability, a fancy web UI and sell it on towards our customers". And suddenly, people would flock towards Amazon, who'd not be required to contribute back (because I chose either the MIT or GPL license to make adoption by others easier)... but I as well as the investors who enabled the product to grow to the stage where it was usable and popular enough for Amazon to commoditize would not see a single cent of it.
And everyone but Amazon loses out. I may be lucky enough to have gotten a few years worth of salary from VC funding (the reality is, most startup founders prioritize ramen lifestyle), the VC and their investors in turn lose out because why contract with me when they already got a frame contract with AWS, and the developers who worked with me also lose out for the same reason.
[1] https://news.ycombinator.com/item?id=7575210
[2] https://xkcd.com/2347/
Took 'em long enough to realize. I 'member the Heartbleed catastrophe and what pittances OpenSSL got [1]. And as always, there's an XKCD fitting just too damn well [2].
> And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
That's the thing... conflicting interests, incentives and most especially expectations. Let's say I'm unhappy with the current state of managing a fleet of hardware servers and VMs, especially after the VMware disaster.
I could bite the bullet and pay VMware. I could go and get OpenStack running. It would be an utter pain to set up and run (because it is funded primarily by universities who don't have the constraint of "administration time effort" because that's what you have aspiring student volunteers for, but instead do have the constraint that it's hard to get hardware so OpenStack has to be flexible enough to support a ton of crap that any enterprise would have sent off to e-waste a decade ago). I could go and get Proxmox up and running, but it's AGPL so corporate legal may chew up my ass. Or I could whip up my own orchestrator, fit to work for my needs, and say I open-source it... and it might even be decent enough others may want to use it as well.
But then, many of these "others" won't be willing to pay for support, but they'll flood the Github issue tracker with all kinds of stuff that I now have to care about (because who wants to present a Github repository with dozens if not hundreds of open issues?), tons of feature wishes and demands (because obviously while I may run Cisco network gear for SDN, someone else may be a Juniper or whatever shop, and wants integration for that), and in the worst case someone gets 0wned because of some vulnerability that I might not even have realized - and I get the shitstorm for it, my name gets dragged through the mud like it was for OpenSSL or log4j.
So, basically I'm left with the choice between either accepting being labeled "lazy" (for not caring about "my project" enough) or to raise enough money to get the product competitive with what the other players are offering, and the only way for that is to go the VC route. And unfortunately, unlike old-school "startup capital", modern VCs want (or rather, because they're following spray-and-pray in their hunt for the 1-out-of-100 unicorn chance, have to aim for) the expectation of insane hyper-growth.
And then, one day, Amazon might go and say "hey, this FOSS thing is pretty cool, we'll add some glue code to integrate with IAM, backups and high availability, a fancy web UI and sell it on towards our customers". And suddenly, people would flock towards Amazon, who'd not be required to contribute back (because I chose either the MIT or GPL license to make adoption by others easier)... but I as well as the investors who enabled the product to grow to the stage where it was usable and popular enough for Amazon to commoditize would not see a single cent of it.
And everyone but Amazon loses out. I may be lucky enough to have gotten a few years worth of salary from VC funding (the reality is, most startup founders prioritize ramen lifestyle), the VC and their investors in turn lose out because why contract with me when they already got a frame contract with AWS, and the developers who worked with me also lose out for the same reason.
[1] https://news.ycombinator.com/item?id=7575210
[2] https://xkcd.com/2347/
> Many people had contributed their efforts to the Redis project for free
It's worth noting that the bulk of the code was written by antirez with only ~12 others exceeding 100+ commits [1]. And if you continue scrolling the number of commits-per-user drops off fast. It's striking given how famous the project is.
[1] https://github.com/redis/redis/graphs/contributors
It's worth noting that the bulk of the code was written by antirez with only ~12 others exceeding 100+ commits [1]. And if you continue scrolling the number of commits-per-user drops off fast. It's striking given how famous the project is.
[1] https://github.com/redis/redis/graphs/contributors
It goes far beyond the actual codebase to the long tail of supporting projects, conference talks, blog posts, etc
Agree. Writing code is (TBH, only a tiny) part of the project - creating packages for different OSes and distros, testing, filling bug reports, promoting project, writing tips and ticks, articles... Many projects remain unpopular not because the authors aren’t actively maintaining them but because these essential components are missing.
As one of those 12 other people, number of commits is not a good metric in this context. When you have a single maintainer, like antirez was for a long time, he could commit 10+ commits for a single small feature but I needed to get someone else to approve my commit before merging.
>there are a number of other high-profile license rug-pulling projects. I'm sad about that.
It also severely sets the industry back every time one of these rug pulls happens and we have to scramble to find a replacement. Sure it might drive some minor innovation, but it also wastes a ton of resources by splitting communities and leading to tons of rewrote just to get back to a place of stability.
It also severely sets the industry back every time one of these rug pulls happens and we have to scramble to find a replacement. Sure it might drive some minor innovation, but it also wastes a ton of resources by splitting communities and leading to tons of rewrote just to get back to a place of stability.
The question of what constitutes a "service" seems very murky, and although it's obviously not the intention of all these source-available, BSL style things, in a dark timeline it seems like there's a lot of room for litigious actors to behave very badly. The uncertainty is what makes it scary, I'd also like a lot more clarity.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
the issues of sspl have been frequently and loudly been brought up previously, and nothing has happened. just to reiterate, this section is ridiculously expansive:
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source 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, all such that a user could run an instance of the service using the Service Source Code you make available.
it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules.
sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft.
> You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license).
note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source 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, all such that a user could run an instance of the service using the Service Source Code you make available.
it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules.
sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft.
> You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license).
note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use
> it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere.
It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL.
I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure).
[0] https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL.
I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure).
[0] https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
I believe that the original reason why they didn't just say "you're not allowed to provide this program as a service" is that MongoDB were trying to get SSPL approved by the OSI. The OSI didn't approve it because as you mention, it's basically impossible for a cloud provider to actually attempt to comply with the SSPL. Not only would they have to release the code to all software used to make the program available, they would have to do so under the SSPL. I'm not sure why MongoDB didn't change the wording when they gave up on getting the license classified as "open source".
Redis puts Redis into the open, and companies exposing Redis put everything they use to expose Redis into the open too.
The key enabler in that whole business is still Redis, so the knowledge exchange appears fair.
The key enabler in that whole business is still Redis, so the knowledge exchange appears fair.
I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license?
It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway.
I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality.
This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.
It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway.
I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality.
This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.
> Redis, Inc. could some day be acquired by Oracle
This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
TBH oracle have been better stewards of MySQL since they bought Sun than Redis the company has been of Redis for the last five or so years.
I personally have wondered if Oracle's behavior with MySQL is partly motivated by the fact that if they try to rug-pull it will most likely just push all of the cloud providers over to MariaDB anyways, which has been doing just fine, and I think is already supported by Amazon RDS anyways. Ultimately I am totally fine with a fork-heavy ecosystem, the only thing I would erase if I could is the normalization of signing CLAs, as I think they make the normally-symmetrical prospect of contributing to open source projects highly asymmetrical, and the consequences are not always so obvious to people.
MariaDB is one of the biggest ironies to me: it was started because people claimed Oracle was going to do Oracle things with it, and somehow make it not open any more.
What actually happened is:
- Oracle has just made MySQL better, and continues to release new tooling (e.g. mysql router) for it under the same license (gpl2).
- MariaDB releases the bare minimum database engine under the GPL, and uses closed licenses for the tooling which is, to quote them: "an essential element to any production database environment".
What actually happened is:
- Oracle has just made MySQL better, and continues to release new tooling (e.g. mysql router) for it under the same license (gpl2).
- MariaDB releases the bare minimum database engine under the GPL, and uses closed licenses for the tooling which is, to quote them: "an essential element to any production database environment".
I wouldn't really put too much weight into the marketing speak, MariaDB feels like the same MySQL offering that always existed, at least to me (and I do run it in production, albeit only on a small scale.) And MariaDB has done plenty of work that is available in the open source product: performance improvements, new storage engines and so on. The only thing that's surprising is that MySQL continued to do the same.
I don't think what MariaDB is doing today is what everyone was really worried about Oracle doing. Rather, Oracle simply never did what everyone thought they would. Personally, I think MariaDB keeps them honest, and if MariaDB ceased to exist as a serious alternative there is a good chance the lawnmower would fire back up.
Though who knows. Maybe Oracle is different. However, I would prefer not to waste the openness of my mind. I reckon if they thought they could pull the rug they would do so.
I don't think what MariaDB is doing today is what everyone was really worried about Oracle doing. Rather, Oracle simply never did what everyone thought they would. Personally, I think MariaDB keeps them honest, and if MariaDB ceased to exist as a serious alternative there is a good chance the lawnmower would fire back up.
Though who knows. Maybe Oracle is different. However, I would prefer not to waste the openness of my mind. I reckon if they thought they could pull the rug they would do so.
I wasn't suggesting it's the exact same scenario, but it definitely seems a little disingenuous to create a fork of something that you chose to sell, and complain (https://web.archive.org/web/20201003111459/https://www2.comp...) about it becoming "open core", only to then make everything you do a paid product with the one exception.
That's before we get into his claims about maintaining drop-in compatibility "as long as MySQL has a larger user base than MariaDB".
That's before we get into his claims about maintaining drop-in compatibility "as long as MySQL has a larger user base than MariaDB".
MySQL and MariaDB have diverged over the years. They each have some interesting major features that the other one lacks, and there's an ever-growing list of incompatibilities between them.
Amazon RDS does offer a MariaDB option, but Amazon Aurora does not. And other clouds often don't offer it. As far as I can tell from a quick search, Google CloudSQL does not offer a managed MariaDB product. Azure offers one, but they're officially retiring it next year.
This discussion is also a bit ironic because MariaDB created the BSL (for use in their proxy product), which is typically attacked alongside SSPL in these types of threads.
Not taking sides here, to be clear. I use both MySQL and MariaDB and am glad they both exist. And personally I have no problems with BSL (or SSPL etc) software, since I am not a cloud hosting provider.
Amazon RDS does offer a MariaDB option, but Amazon Aurora does not. And other clouds often don't offer it. As far as I can tell from a quick search, Google CloudSQL does not offer a managed MariaDB product. Azure offers one, but they're officially retiring it next year.
This discussion is also a bit ironic because MariaDB created the BSL (for use in their proxy product), which is typically attacked alongside SSPL in these types of threads.
Not taking sides here, to be clear. I use both MySQL and MariaDB and am glad they both exist. And personally I have no problems with BSL (or SSPL etc) software, since I am not a cloud hosting provider.
I would like to clarify since I am one of the people who is always present in these threads debating these licenses:
I think these licenses suck compared to even kind-of-bad open source licenses, like AGPL, though some suck more than others. For example, the SSPL is a poorly-conceived liability nightmare. BUSL, on the other hand, may not be much better, but it is pretty interesting. Software that is BUSL today is theoretically open source eventually. As long as this holds up in court, it is an intriguing alternative to other "business" licenses.
However: it was never about this. My complaints always center squarely around two things:
- One, deception. If you release a product and you call it "open source" or otherwise try to imply it is open, but actually it is not open source, this is bad. This is bad because like it or not, people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this while also deceiving people into thinking it's the same thing they've come to know.
- Two, violation of expectations. I get that the contributions made by open source contributors rarely compares much to the contributions made by those employed at companies, but even still, the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to, and I think that this aspect of CLAs is troublesome. That aside, I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day. Don't get it twisted, I think Redis is great software that can stand on its own, but it doesn't matter: it didn't. It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
However, despite that... I am not ideologically opposed to closed-source, source-available, or any other kind of software. It's fine. I use software that is "non-free". I pay for software. I pay for JetBrains Toolbox. This does not bother me and is not my issue. It's literally just those two things that bother me.
So why don't I care about MaxScale? Honestly, it's pretty simple: It's outside of my purview. It may very well be an important project used by a lot of people, but it just doesn't seem like it was ever a huge open source project: according to GitHub, it has a total of 39 all-time contributors, most of which seemingly after the relicensing, versus Redis's 729. I've never used MaxScale and I'm not sure what depends on it. If someone else is mad about this relicensing, I do not necessarily blame them, but I just simply have no dog in the race.
MySQL and MariaDB themselves remain as open as ever, and that's really all most people are concerned with IMO.
I think these licenses suck compared to even kind-of-bad open source licenses, like AGPL, though some suck more than others. For example, the SSPL is a poorly-conceived liability nightmare. BUSL, on the other hand, may not be much better, but it is pretty interesting. Software that is BUSL today is theoretically open source eventually. As long as this holds up in court, it is an intriguing alternative to other "business" licenses.
However: it was never about this. My complaints always center squarely around two things:
- One, deception. If you release a product and you call it "open source" or otherwise try to imply it is open, but actually it is not open source, this is bad. This is bad because like it or not, people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this while also deceiving people into thinking it's the same thing they've come to know.
- Two, violation of expectations. I get that the contributions made by open source contributors rarely compares much to the contributions made by those employed at companies, but even still, the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to, and I think that this aspect of CLAs is troublesome. That aside, I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day. Don't get it twisted, I think Redis is great software that can stand on its own, but it doesn't matter: it didn't. It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
However, despite that... I am not ideologically opposed to closed-source, source-available, or any other kind of software. It's fine. I use software that is "non-free". I pay for software. I pay for JetBrains Toolbox. This does not bother me and is not my issue. It's literally just those two things that bother me.
So why don't I care about MaxScale? Honestly, it's pretty simple: It's outside of my purview. It may very well be an important project used by a lot of people, but it just doesn't seem like it was ever a huge open source project: according to GitHub, it has a total of 39 all-time contributors, most of which seemingly after the relicensing, versus Redis's 729. I've never used MaxScale and I'm not sure what depends on it. If someone else is mad about this relicensing, I do not necessarily blame them, but I just simply have no dog in the race.
MySQL and MariaDB themselves remain as open as ever, and that's really all most people are concerned with IMO.
> people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this
That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
> the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to
It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
> I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day.
A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
> It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
But I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
> the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to
It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
> I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day.
A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
> It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
But I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
> That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
> And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
As far as I can tell, the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998, so while it does sort of sound like a generic term, I don't think they were conflating much with any existing term in widespread use. The OSI themselves[1] also seem to suggest that they believe they were responsible for making the phrase ineligible for trademark:
> Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream.
[1]: https://opensource.org/pressreleases/certified-open-source.p...
--
> It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
Personally, I only contribute to projects with CLAs when I have pretty much no other choice, due to constraints outside of my control. Example: I have begrudgingly made contributions to Qt because I have no control over the upstream that KDE uses.
To be fair, I guess this does technically still count as a mutually beneficial relationship, but to me, it feels a lot more like a toxic one. But yes, that's true.
> A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
> So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
Well, from my perspective, a perfectly-reasonable, common assumption became an unreasonable without much warning.
As much as people have misgivings about how Red Hat has handled RHEL, they still proved for a very long time that it is possible to run a sustainable business even when the primary thing you do is work on open source projects. They are not alone: there are others. Off the top of my head, Collabora, Ltd. is often right alongside Red Hat. I think all of the misgivings people have with Red Hat are also after the IBM acquisition, so it's hard to be sure exactly what went wrong there.
What's happening today feels very different, though. In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
And I won't say that people shouldn't take caution and mind the risk. They are! I think a lot of people are more skeptical of business models than ever. Even on the consumer end, the mantra of "If you're not paying for the product, then you are the product" has entered the mainstream thanks to Facebook, and many are skeptical of startups like Discord as well for similar reasons.
But even then, I feel deeply that companies should take responsibility when the expectations are misaligned. If you have a CLA on your project with the explicit intent to be able to relicense the project later, please communicate this very clearly to your users and contributors. Prior to recently, a very good justification for a CLA was actually just legal book-keeping: it killed many birds with one stone, like allowing a contribution to be used in a dual-licensed product with a commercial license, additional assurance that the person who is contributing the code has the legal right to contribute it, and allowing for good-faith relicensing when it would be helpful (e.g. transitioning from GPLv2 to GPLv2+ or something like that.) I didn't expect CLAs to be used the way they are used today, and needless to say I'm pretty disappointed.
So sure. Users should beware. But, I think that doesn't absolve companies from not setting proper expectations. We should expect companies to not do things that will leave everyone feeling bamboozled. Just as arguably the people should've known better, companies like Redis, Inc. should've known better, too.
> Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
In some cases, I am legitimately not permitted to use or run SSPL software. To be clear though, it's not like I disagree: I feel like SSPL is a trash fire that, if brought from the metaphorical realm into the physical, could be seen from space. It is less a copyright license to me and more of an extended middle finger.
In other cases, I choose open source for practical reasons. For example, if I am using Linux, many distributions will flat-out not package software that is not open source. This is both for ideological and practical reasons. Working with non-open-source software in an otherwise-fully-open-source project feels like dealing with toxic waste. And it's not entirely unreasonable, as it can be surprising. If I install the Redis package one day and it's open source, then the package updates in a system upgrade and it's SSPL, that would be a rather huge problem! So this clearly can't work, and we have to very clearly distinguish what software is safe to use and what software might be quite unsafe to use.
Even if it is technically possible for me to use SSPL software, I would greatly prefer to not do so anyways. If I wanted to contribute upstream to a project I use, I'd greatly prefer it to be one that doesn't use a CLA. Valkey doesn't use a CLA. Therefore, if I use Valkey, I don't have to sign a CLA to contribute upstream.
> And meanwhile I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
Definitely, but actually, I think this sort of model is exactly what has always worked best for open source: all of the cloud providers contributing to it get to benefit equally from it. To me this is what Linux kernel development also looks like, along with many other successful projects.
Is it a bit sad that Redis, Inc. and the folks who made Redis what it is today will ultimately lose out if Valkey winds up dominating the mindshare in the long run? Absolutely, it's a terrible end result. But the way I see it, it feels like it's either that, or the rest of the world loses out on having an open source Redis-compatible database. I don't think Redis, Inc. really needs to be rewarded infinitely forever for the work that they did, even as much as I value it, so this temporary situation, as unfortunate as it may be, seems like a good tradeoff for the longer haul.
I think the story of Redis and many other such projects will wind up being a cautionary tale, and we're just now finding out to whom it will be to. Though, even if I don't like it, it's looking more and more likely that the cautionary tale is to us, the users.
> And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
As far as I can tell, the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998, so while it does sort of sound like a generic term, I don't think they were conflating much with any existing term in widespread use. The OSI themselves[1] also seem to suggest that they believe they were responsible for making the phrase ineligible for trademark:
> Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream.
[1]: https://opensource.org/pressreleases/certified-open-source.p...
--
> It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
Personally, I only contribute to projects with CLAs when I have pretty much no other choice, due to constraints outside of my control. Example: I have begrudgingly made contributions to Qt because I have no control over the upstream that KDE uses.
To be fair, I guess this does technically still count as a mutually beneficial relationship, but to me, it feels a lot more like a toxic one. But yes, that's true.
> A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
> So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
Well, from my perspective, a perfectly-reasonable, common assumption became an unreasonable without much warning.
As much as people have misgivings about how Red Hat has handled RHEL, they still proved for a very long time that it is possible to run a sustainable business even when the primary thing you do is work on open source projects. They are not alone: there are others. Off the top of my head, Collabora, Ltd. is often right alongside Red Hat. I think all of the misgivings people have with Red Hat are also after the IBM acquisition, so it's hard to be sure exactly what went wrong there.
What's happening today feels very different, though. In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
And I won't say that people shouldn't take caution and mind the risk. They are! I think a lot of people are more skeptical of business models than ever. Even on the consumer end, the mantra of "If you're not paying for the product, then you are the product" has entered the mainstream thanks to Facebook, and many are skeptical of startups like Discord as well for similar reasons.
But even then, I feel deeply that companies should take responsibility when the expectations are misaligned. If you have a CLA on your project with the explicit intent to be able to relicense the project later, please communicate this very clearly to your users and contributors. Prior to recently, a very good justification for a CLA was actually just legal book-keeping: it killed many birds with one stone, like allowing a contribution to be used in a dual-licensed product with a commercial license, additional assurance that the person who is contributing the code has the legal right to contribute it, and allowing for good-faith relicensing when it would be helpful (e.g. transitioning from GPLv2 to GPLv2+ or something like that.) I didn't expect CLAs to be used the way they are used today, and needless to say I'm pretty disappointed.
So sure. Users should beware. But, I think that doesn't absolve companies from not setting proper expectations. We should expect companies to not do things that will leave everyone feeling bamboozled. Just as arguably the people should've known better, companies like Redis, Inc. should've known better, too.
> Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
In some cases, I am legitimately not permitted to use or run SSPL software. To be clear though, it's not like I disagree: I feel like SSPL is a trash fire that, if brought from the metaphorical realm into the physical, could be seen from space. It is less a copyright license to me and more of an extended middle finger.
In other cases, I choose open source for practical reasons. For example, if I am using Linux, many distributions will flat-out not package software that is not open source. This is both for ideological and practical reasons. Working with non-open-source software in an otherwise-fully-open-source project feels like dealing with toxic waste. And it's not entirely unreasonable, as it can be surprising. If I install the Redis package one day and it's open source, then the package updates in a system upgrade and it's SSPL, that would be a rather huge problem! So this clearly can't work, and we have to very clearly distinguish what software is safe to use and what software might be quite unsafe to use.
Even if it is technically possible for me to use SSPL software, I would greatly prefer to not do so anyways. If I wanted to contribute upstream to a project I use, I'd greatly prefer it to be one that doesn't use a CLA. Valkey doesn't use a CLA. Therefore, if I use Valkey, I don't have to sign a CLA to contribute upstream.
> And meanwhile I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
Definitely, but actually, I think this sort of model is exactly what has always worked best for open source: all of the cloud providers contributing to it get to benefit equally from it. To me this is what Linux kernel development also looks like, along with many other successful projects.
Is it a bit sad that Redis, Inc. and the folks who made Redis what it is today will ultimately lose out if Valkey winds up dominating the mindshare in the long run? Absolutely, it's a terrible end result. But the way I see it, it feels like it's either that, or the rest of the world loses out on having an open source Redis-compatible database. I don't think Redis, Inc. really needs to be rewarded infinitely forever for the work that they did, even as much as I value it, so this temporary situation, as unfortunate as it may be, seems like a good tradeoff for the longer haul.
I think the story of Redis and many other such projects will wind up being a cautionary tale, and we're just now finding out to whom it will be to. Though, even if I don't like it, it's looking more and more likely that the cautionary tale is to us, the users.
You've made a lot of great points above, more than I can reply to, so please excuse my cherry-picking of just a few in my response here.
> the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998
There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
> a perfectly-reasonable, common assumption became an unreasonable without much warning
In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
> In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
> the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998
There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
> a perfectly-reasonable, common assumption became an unreasonable without much warning
In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
> In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
A cynical view is that it's not just 2-3 providers, its any competition to their cloud-hosting business. See for example the recent wordpress drama, which concerns a small competitor.
SSPL and related licenses are ambiguous and scary enough to ward off anyone potentially competing with the copyright owner, and I doubt that's seen as a downside.
SSPL and related licenses are ambiguous and scary enough to ward off anyone potentially competing with the copyright owner, and I doubt that's seen as a downside.
This is a really good example of why software with a license that is basically "this could hurt you but, like, trust me bro" isn't worth building with/extending/learning. It feels a LOT like a landmine waiting to detonate.
Even if I'm doing completely non commercial work I never ever ever will want to productize in any way I'd rather build my skills and familiarity with something portable (and I don't want to have to remember when I can and can't safely use each part of my stack). Anything else is just asking for a future nightmare.
The oracle and wordpress stuff recently are devastating. Can you imagine having to grind your entire company to a halt looking for anything that uses anything that uses anything that uses redis/java/whatever?
I'm an engineer. I can't justify a fixed amount of upside for an unbounded downside if I ever get on some stranger's bad side for whatever reason.
Even if I'm doing completely non commercial work I never ever ever will want to productize in any way I'd rather build my skills and familiarity with something portable (and I don't want to have to remember when I can and can't safely use each part of my stack). Anything else is just asking for a future nightmare.
The oracle and wordpress stuff recently are devastating. Can you imagine having to grind your entire company to a halt looking for anything that uses anything that uses anything that uses redis/java/whatever?
I'm an engineer. I can't justify a fixed amount of upside for an unbounded downside if I ever get on some stranger's bad side for whatever reason.
For the companies who "are copyright holders of the code" the uncertainty and litigation potential is not a bug, it's a feature.
This feature could actually be the overwhelming value of acquiring the copyright. When trillion dollar companies go to war with each other this kind of thing is a fantastic weapon in the arsenal.
This is a great point, it'll probably take the better part of the next decade for all this to shake out. It'll be interesting to see where it goes.
No one is expected to use any of the code licensed in this way commercially. You enter a contract with the vendor, tell them what you need, and negotiate a price. At that point, it doesn't really matter what the copyright license says.
So the entire license is just a bad faith trap? I could see it being used that way, potentially, but I don't believe that's actually Confluent's, MongoDB's, Elastic's, Hashicorp's, or Redis Labs' intent. In fact they've all explicitly stated the opposite. Are they all lying?
I don't think it's in bad faith. A lot of people still believe that they have to pay one of AdaCore/Baylibre/Embecosm/Red Hat/SUSE/Wind River if you want to use GCC commercially, to cover GPL-related risk.
AFAIK, the reason for these changes is basically "prevent AWS from eating our business". Is that right?
If so, are these trends harmful to open source? Are we not choosing between:
1. A world where all revenue in OSS infrastructure ultimately flows to a few big platform companies.
2. A world where these carve-outs are commonplace.
Meta's carve-out with Llama is so interesting because it practically calls the big companies out by name. Should there be a similar standard license for open source infrastructure?
If so, are these trends harmful to open source? Are we not choosing between:
1. A world where all revenue in OSS infrastructure ultimately flows to a few big platform companies.
2. A world where these carve-outs are commonplace.
Meta's carve-out with Llama is so interesting because it practically calls the big companies out by name. Should there be a similar standard license for open source infrastructure?
> Should there be a similar standard license for open source infrastructure?
Yes, I think there should be. The tech world is basically a monopoly at this point, and that's dangerous for a thousand reasons. The least those monopoly owners can do is financially contribute if they want to use these tools.
It's sad to me that the tech world is rallying around Valkey, which is Big Tech's fork: AWS et al are the ones behind it. We continue to give more and more power to the biggest players.
Yes, I think there should be. The tech world is basically a monopoly at this point, and that's dangerous for a thousand reasons. The least those monopoly owners can do is financially contribute if they want to use these tools.
It's sad to me that the tech world is rallying around Valkey, which is Big Tech's fork: AWS et al are the ones behind it. We continue to give more and more power to the biggest players.
Affero GPL-style copyleft licenses are an option, although they are treated as radioactive by most companies. A clause that triggers the extensions over GPL only for companies beyond a certain size might make them more platable.
> although they are treated as radioactive by most companies
Isn't this reason enough to not consider it an option?
Isn't this reason enough to not consider it an option?
AFAIK, the main issue of the GPL family of licenses is that they are rather poorly drafted. The GNU project has great evangelists but ideological-minded people make bad lawyers. Their licenses are long winded and hard to interpret, and often make assumptions about unsettled bits of copyright law. Their legal theories (eg. "GPL is not a contract") have been rejected by courts.
In short, if you're a company wanting to use some AGPL-like license, you'd probably want to use a license that's better drafted over the original AGPL.
In short, if you're a company wanting to use some AGPL-like license, you'd probably want to use a license that's better drafted over the original AGPL.
Can you link some info on the portion about contracts having been rejected by the courts? I’m having trouble finding specifics on that myself.
I'm not sure it even matters.
If it gets to court you've got a plaintiff either claiming that defendant violated copyright or the defendant failed to follow the terms of GPL.
In both cases the defendant will respond that they followed the terms of GPL.
In both cases the court has to determine what the license means and then whether or not defendant followed the terms of the GPL. To do that the court has to decide what those terms actually mean.
For that I don't think it matters if GPL is considered to be a "contract" or "license" because as far as I have been able to tell the rules of interpretation are the same no matter how you characterize the document.
Maybe it could make a difference in the remedies that are available if plaintiff wins. If it is seen as not being a contract then it might be that the only remedies would be those under copyright law. Those would generally be an injunction ordering defendant to stop infringing and monetary damages. Actual monetary damages would be near zero so plaintiff would probably ask for statutory damages.
If it is seen as being a contract then potentially the remedy could include an order that the defendant release their source code. If the GPL infringement was distributing binaries without making source available this would probably be the remedy plaintiff wants.
Ordering the defendant to obey the terms of the contract is called "specific performance" and I believe is usually disfavored by courts if monetary damages are sufficient but since infringing GPL generally doesn't cause any monetary losses to the copyright owner and the whole point of the contract was to make source available I'd expect a decent chance plaintiff could get specific performance.
Note that this means that it is actually better for GPL to be seen as a contract.
If it gets to court you've got a plaintiff either claiming that defendant violated copyright or the defendant failed to follow the terms of GPL.
In both cases the defendant will respond that they followed the terms of GPL.
In both cases the court has to determine what the license means and then whether or not defendant followed the terms of the GPL. To do that the court has to decide what those terms actually mean.
For that I don't think it matters if GPL is considered to be a "contract" or "license" because as far as I have been able to tell the rules of interpretation are the same no matter how you characterize the document.
Maybe it could make a difference in the remedies that are available if plaintiff wins. If it is seen as not being a contract then it might be that the only remedies would be those under copyright law. Those would generally be an injunction ordering defendant to stop infringing and monetary damages. Actual monetary damages would be near zero so plaintiff would probably ask for statutory damages.
If it is seen as being a contract then potentially the remedy could include an order that the defendant release their source code. If the GPL infringement was distributing binaries without making source available this would probably be the remedy plaintiff wants.
Ordering the defendant to obey the terms of the contract is called "specific performance" and I believe is usually disfavored by courts if monetary damages are sufficient but since infringing GPL generally doesn't cause any monetary losses to the copyright owner and the whole point of the contract was to make source available I'd expect a decent chance plaintiff could get specific performance.
Note that this means that it is actually better for GPL to be seen as a contract.
TBH I don't know why the FSF had been pushing for this 'not a contract' narrative for so long either.
Maybe bad lawyering. Or some aversion to anything that looks like an EULA or that kind of radical-ideological shit.
PS: I found this link when digging in my archives:
https://www.technollama.co.uk/us-court-declares-gpl-is-a-con...
That the GPL is a contract hardly came as any surprise to people familiar with the law. Lawyers and judges view any collection of terms as a contract, and tear-open licenses are the norm these days. But the FSF had its own reasons to say it’s a license, reasons that might be more important to the philosophy of Free Software than the court. Contracts require consent between two parties who join in the contract, if they are to be enforced. The GPL (and many other licenses that come with products) doesn’t have a signature page, so there is no explicit consent. If there is consent at all, it’s the implied consent that has become standard for “tear-open” licenses. Your acceptance of the license is indicated by some action, in this case integrating the code into your product. The default under copyright law is all rights reserved, which means “you can’t do anything with this” with some minor exceptions that are called “fair use”. Thus, if you integrate the software into your product, distribute it, or perform some other action that is restricted by copyright, you must have accepted the license because your alternative would be all rights reserved. Thus, the FSF asserts that the GPL is a license because they feel consent isn’t really necessary, they don’t want to argue about consent in court, and they believe that they can do all of the enforcement they need using a complaint of copyright infringement. Also, tear-open licenses were a much more foggy issue in law when the GPL came about. And then there’s the philosophical matter:
Maybe bad lawyering. Or some aversion to anything that looks like an EULA or that kind of radical-ideological shit.
PS: I found this link when digging in my archives:
https://www.technollama.co.uk/us-court-declares-gpl-is-a-con...
That the GPL is a contract hardly came as any surprise to people familiar with the law. Lawyers and judges view any collection of terms as a contract, and tear-open licenses are the norm these days. But the FSF had its own reasons to say it’s a license, reasons that might be more important to the philosophy of Free Software than the court. Contracts require consent between two parties who join in the contract, if they are to be enforced. The GPL (and many other licenses that come with products) doesn’t have a signature page, so there is no explicit consent. If there is consent at all, it’s the implied consent that has become standard for “tear-open” licenses. Your acceptance of the license is indicated by some action, in this case integrating the code into your product. The default under copyright law is all rights reserved, which means “you can’t do anything with this” with some minor exceptions that are called “fair use”. Thus, if you integrate the software into your product, distribute it, or perform some other action that is restricted by copyright, you must have accepted the license because your alternative would be all rights reserved. Thus, the FSF asserts that the GPL is a license because they feel consent isn’t really necessary, they don’t want to argue about consent in court, and they believe that they can do all of the enforcement they need using a complaint of copyright infringement. Also, tear-open licenses were a much more foggy issue in law when the GPL came about. And then there’s the philosophical matter:
Some of this is being tested in court right now.
https://sfconservancy.org/copyleft-compliance/vizio.html
https://sfconservancy.org/copyleft-compliance/vizio.html
Historically collecting damages were not the goal of GPL enforcement. Specific performance, or stop infringement by no longer distributing the software were the remedies. The latter is not always an option for the infringing party, and that's what submits them into compliance.
I didn't say contracts being rejected by the courts.
I said the FSF had a legal theory that "GPL is a license, not a contract", which was rejected by the courts.
Some reading: https://www.technollama.co.uk/us-court-declares-gpl-is-a-con...
Further cases: https://news.ycombinator.com/item?id=24478769
I said the FSF had a legal theory that "GPL is a license, not a contract", which was rejected by the courts.
Some reading: https://www.technollama.co.uk/us-court-declares-gpl-is-a-con...
Further cases: https://news.ycombinator.com/item?id=24478769
The SFC think the GPL is a contract (as well as a license), and that is being tested in court at the moment:
https://sfconservancy.org/copyleft-compliance/vizio.html
https://sfconservancy.org/copyleft-compliance/vizio.html
Being radioactive is the reason why it is considered an option.
I think it comes down to the initial choice to make something open source. At that point you're well aware that big companies might use your code and profit more than you ever will. If you don't want that, don't open source and they will never use your code.
It's having your cake and eating it when you get popular by being open source and then add restrictions when you have success.
I think there should be a change to licenses where the trademark is tied to the license. You can go proprietary but you can't take back the name.
It's having your cake and eating it when you get popular by being open source and then add restrictions when you have success.
I think there should be a change to licenses where the trademark is tied to the license. You can go proprietary but you can't take back the name.
What is wrong with a non-commercial open source license for those that want to use your software for personal use and a paided up commercial license (something like Business Source License[1]) for the big tech corporations of the world?
How much open source software is being incorporated into closed source software and then being resold back to the original open source developers - to get an idea, check the licenses on a Apple phone (Settings -> General -> Legal & Regulatory -> Legal Notices)[2]. It's the who's who of open source licenses! I wonder how much Apple has contributed to those projects? Perhaps each FOSS developer mentioned there should receive - at least - a free iPhone ...
The argument of "social contract" or "moral rights" or whatever else a FOSS developer faces when changing their license to something that prevents BigTech making money off their work is unfair and unnecessary. Its their work, their choice. Just as politicians aren't held to the promises they made yesterday, so too are FOSS developers human and can change their direction/mind and license.
In addition to this, many have vested interests in these companies continuing their use of "free" (in the sense of money) software since they are themselves shareholders or employees. License fees effect the bottom line of those corporations. Imagine AWS paying a license fee for their Linux boxes ...
A corporation also has a "social contract" to fulfil, yet its the FOSS developer that needs to fulfil theirs first. Or perhaps a corporation only faces "legal contract" and for the sake of profit, a "social contract" isn't applicable to a corporation. In which case, neither should a "social contract" be applicable to a FOSS developer - when dealing with corporations.
[1] https://mariadb.com/bsl11/
[2] can also be viewed online --> https://gist.github.com/gorenje/a775f44bb9307852911f7f353466...
How much open source software is being incorporated into closed source software and then being resold back to the original open source developers - to get an idea, check the licenses on a Apple phone (Settings -> General -> Legal & Regulatory -> Legal Notices)[2]. It's the who's who of open source licenses! I wonder how much Apple has contributed to those projects? Perhaps each FOSS developer mentioned there should receive - at least - a free iPhone ...
The argument of "social contract" or "moral rights" or whatever else a FOSS developer faces when changing their license to something that prevents BigTech making money off their work is unfair and unnecessary. Its their work, their choice. Just as politicians aren't held to the promises they made yesterday, so too are FOSS developers human and can change their direction/mind and license.
In addition to this, many have vested interests in these companies continuing their use of "free" (in the sense of money) software since they are themselves shareholders or employees. License fees effect the bottom line of those corporations. Imagine AWS paying a license fee for their Linux boxes ...
A corporation also has a "social contract" to fulfil, yet its the FOSS developer that needs to fulfil theirs first. Or perhaps a corporation only faces "legal contract" and for the sake of profit, a "social contract" isn't applicable to a corporation. In which case, neither should a "social contract" be applicable to a FOSS developer - when dealing with corporations.
[1] https://mariadb.com/bsl11/
[2] can also be viewed online --> https://gist.github.com/gorenje/a775f44bb9307852911f7f353466...
> I do also see these kinds of license trends as harmful to open source generally
I've re-read this a few times and I'm still not sure what "harmful to open source" means in this sentence, could you expand on this a bit when you have time? (readings I considered: this will dissuade people from using OSI licenses, this will dissuade people from trying to monetize open source components, this will dissuade people from using open source components in their products all together, this will dissuade people from contributing to open source)
> Many people had contributed their efforts to the Redis project for free
This one is not directly addressed at OP but I would be interested to see what the contribution numbers are like for Redis and other projects post-license change.
In my own limited experience (project with >10k, <100k end users), I received no meaningful code contributions when the project was MIT licensed, but contributions of significant features and large bug fixes skyrocketed after switching away from it (not saying that the license change is the reason for that, just that it didn't dissuade some people who are willing to contribute significant effort from contributing to the project).
Editing this post to say thanks for the response and clarity, I don't have anything else to add!
I've re-read this a few times and I'm still not sure what "harmful to open source" means in this sentence, could you expand on this a bit when you have time? (readings I considered: this will dissuade people from using OSI licenses, this will dissuade people from trying to monetize open source components, this will dissuade people from using open source components in their products all together, this will dissuade people from contributing to open source)
> Many people had contributed their efforts to the Redis project for free
This one is not directly addressed at OP but I would be interested to see what the contribution numbers are like for Redis and other projects post-license change.
In my own limited experience (project with >10k, <100k end users), I received no meaningful code contributions when the project was MIT licensed, but contributions of significant features and large bug fixes skyrocketed after switching away from it (not saying that the license change is the reason for that, just that it didn't dissuade some people who are willing to contribute significant effort from contributing to the project).
Editing this post to say thanks for the response and clarity, I don't have anything else to add!
I see the open source movement as being about developers sharing their work in order to raise all ships and dramatically accelerate the rate at which participants in that community can build cool software.
A lot of that benefit comes from not having to worry about licenses: pick platform components with known open source licenses, build cool things with them.
I think the rise in not-quite-open-source licenses (especially projects switching to those licenses) undermines the things that I value about open source, and further encourages more projects to make those decisions in the future.
A lot of that benefit comes from not having to worry about licenses: pick platform components with known open source licenses, build cool things with them.
I think the rise in not-quite-open-source licenses (especially projects switching to those licenses) undermines the things that I value about open source, and further encourages more projects to make those decisions in the future.
One of the motivations of copyleft licenses like GPL which are a part of open source, was the freedom for users to see and modify code. The fact that the user works with the software in a browser rather than inside a native app is a technicality which shouldn't mean that the principle becomes invalid.
Of course, this makes it harder for developers to monetize their work. But, instead of framing the discussion in terms of these conflicting interests and finding a balance, the term 'open source' becomes a debate target (even though the OSI definition includes AGPL which is also radioactive if one wants to monetize the work.)
So we have three parties 1) Users 2) App Developers who write commercial closed source code for the user facing app 3) Dependency Developers who write code used by App Developers.
(There is a simplification here as 2 can be a startup writing selling a closed source dependency used by other developers)
Just as App developers would like to monetize via user payments, some licenses allow the same option for Dependency developers while simultaneously allowing source code to be available and modified.
The basic idea behind such a license is 'free of cost and inspectable/modifiable code for almost all users, but commercial for large companies making a significant revenue from the software'.
There needs to be some work done, to make the license predictable - which users it requires to pay, and the price involved.
Of course, this makes it harder for developers to monetize their work. But, instead of framing the discussion in terms of these conflicting interests and finding a balance, the term 'open source' becomes a debate target (even though the OSI definition includes AGPL which is also radioactive if one wants to monetize the work.)
So we have three parties 1) Users 2) App Developers who write commercial closed source code for the user facing app 3) Dependency Developers who write code used by App Developers.
(There is a simplification here as 2 can be a startup writing selling a closed source dependency used by other developers)
Just as App developers would like to monetize via user payments, some licenses allow the same option for Dependency developers while simultaneously allowing source code to be available and modified.
The basic idea behind such a license is 'free of cost and inspectable/modifiable code for almost all users, but commercial for large companies making a significant revenue from the software'.
There needs to be some work done, to make the license predictable - which users it requires to pay, and the price involved.
[deleted]
> this will dissuade people from using OSI licenses
Yes, because other projects will follow the pattern of successful ones.
> this will dissuade people from using open source components in their products all together,
Yes, because now there is a very real risk that after you have invested in using an open source license, the owner might change the license on you, which makes potential users more wary of open source projects.
> this will dissuade people from contributing to open source
Yes, for similar reasons to the above.
Yes, because other projects will follow the pattern of successful ones.
> this will dissuade people from using open source components in their products all together,
Yes, because now there is a very real risk that after you have invested in using an open source license, the owner might change the license on you, which makes potential users more wary of open source projects.
> this will dissuade people from contributing to open source
Yes, for similar reasons to the above.
Successful open source projects historically involve a bunch of companies lowering their costs by commoditizing expensive commercial functionality. Server operating systems, version control, programming environments used to be very expensive.
Linux, git, Python, Postgres, etc weren’t about getting rich, but about making something cheap and easy.
The paradox of these single company backed OSS projects is somehow making a big chunk of it free/open but collecting money off of other services. To me, I’m not sure that’s worked yet. Many will even say that these companies aren’t really doing open source in the traditional sense, but acting as commercial vendors that let you look at the code.
Linux, git, Python, Postgres, etc weren’t about getting rich, but about making something cheap and easy.
The paradox of these single company backed OSS projects is somehow making a big chunk of it free/open but collecting money off of other services. To me, I’m not sure that’s worked yet. Many will even say that these companies aren’t really doing open source in the traditional sense, but acting as commercial vendors that let you look at the code.
In this matter, that pretty phrase “social contract” is at root a demand for ego massage from a) contributors that don’t actually believe in the freewheeling spirit of the BSD/MIT licenses but used it anyway, and b) noncontributors whose sense of entitlement is projecting as loss aversion.
The revised license is nevertheless a problem for component selection. Usage caveats are a landmine and thereby a coherent motivation for the Valkey fork.
The revised license is nevertheless a problem for component selection. Usage caveats are a landmine and thereby a coherent motivation for the Valkey fork.
"A demand for ego massage" is a pretty rude way to try to dismiss away someone's expressed feeling about something they cared about fundamentally changing.
I think it's a stretch to attack everyone who liked the idea of a totally open license as either disingenuous or selfish.
I think it's a stretch to attack everyone who liked the idea of a totally open license as either disingenuous or selfish.
I agree, it would be, so I take issue with the extreme interpretation of the remark. These are merely two cases of foolishness. The first is of one’s choices not actually being in harmony with one’s preferences, the latter is simply a common cognitive bias. I’m not characterising talk of a “social contact” as malicious, but naive. Folks who want community obligations attached to their contributions can and probably should choose a copyleft license. Realising this in hindsight is a matter of personal growth.
I advise against relating to software as an emotional construct. Certainly for noncontributors but also even for contributors and primary authors. Redis is not your cat.
I advise against relating to software as an emotional construct. Certainly for noncontributors but also even for contributors and primary authors. Redis is not your cat.
I'm ruffled by your repeated dismissals and arrogance BUT now I really want to name a pet redis so maybe you're coming out ahead in my personal calculus.
You taking issue with my "extreme interpretation" seems like a bad faith statement. Perhaps you really do feel mistreated by it; if that's the case I'm sorry because my intent is directly addressing the language you're using but not you personally.
To ape some of your phrasing, I advise against taking offense when others disagree with your approach or severity when you are attacking strangers, dismissing their reactions, gatekeeping who should get to care, patronizing them about personal growth, and calling them foolish at best.
You taking issue with my "extreme interpretation" seems like a bad faith statement. Perhaps you really do feel mistreated by it; if that's the case I'm sorry because my intent is directly addressing the language you're using but not you personally.
To ape some of your phrasing, I advise against taking offense when others disagree with your approach or severity when you are attacking strangers, dismissing their reactions, gatekeeping who should get to care, patronizing them about personal growth, and calling them foolish at best.
I can only beg your pardon for my lack of emotion or delicate language in offering these admittedly blunt and unflattering assessments.
switched away to what? To a source-available license? copy-left?
Initially to a PolyForm license[1], which I then forked to create my own[2]. I informally refer to it as an "edu source" license (the source available is primarily available for educational purposes).
[1]: https://polyformproject.org/licenses/strict/1.0.0/ (hn discussion: https://news.ycombinator.com/item?id=24804223)
[2]: https://github.com/LGUG2Z/komorebi-license
[1]: https://polyformproject.org/licenses/strict/1.0.0/ (hn discussion: https://news.ycombinator.com/item?id=24804223)
[2]: https://github.com/LGUG2Z/komorebi-license
> It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms.
I'm not familiar with what's happening in this Redis licence change.
But if it was Open Source at version N, and you built your business (or stack, etc) on top of that, N will remain forever available to you as FLOSS, not?
Is the problem maybe that ppl expect future updates, maintenance to remain Open Source? Something that, AFAIK, no Open Source licence guarantees? So, misaligned expectations?
> That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects.
It's not new. MySQL, Redhat and many others have done this for ages in the floss community.
I'm not familiar with what's happening in this Redis licence change.
But if it was Open Source at version N, and you built your business (or stack, etc) on top of that, N will remain forever available to you as FLOSS, not?
Is the problem maybe that ppl expect future updates, maintenance to remain Open Source? Something that, AFAIK, no Open Source licence guarantees? So, misaligned expectations?
> That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects.
It's not new. MySQL, Redhat and many others have done this for ages in the floss community.
Note his "build a business on it" angle. It's not an open source problem. Greedy techbros want free support forever from the community while contributing almost nothing back. Same for large corporations.
They see this as "rug pulling". I think developers need to do a lot more of that for things to change.
They see this as "rug pulling". I think developers need to do a lot more of that for things to change.
OP wrote
> The license language is almost the same as the AGPL, with changes regarding the SAAS stuff. So, not OSI approved? Yes, but I have issues calling the SSPL a closed license.
What is it that changed from AGPL in SSPL that was absolutely needed? Why can't we have an AGPL 1.1 or 2.0 if it is a breaking change? I am not saying anyirez is wrong. I would like to learn why this was necessary, if at all.
> The license language is almost the same as the AGPL, with changes regarding the SAAS stuff. So, not OSI approved? Yes, but I have issues calling the SSPL a closed license.
What is it that changed from AGPL in SSPL that was absolutely needed? Why can't we have an AGPL 1.1 or 2.0 if it is a breaking change? I am not saying anyirez is wrong. I would like to learn why this was necessary, if at all.
> What is it that changed from AGPL in SSPL that was absolutely needed?
https://opensource.stackexchange.com/a/8028
Big cloud players would put a thin layer on top and ignore the AGPL.
https://opensource.stackexchange.com/a/8028
Big cloud players would put a thin layer on top and ignore the AGPL.
>Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc - and when they did that it was under the understanding that project would remain under the same open source license. It honestly felt like a betrayal of trust
I'm not seeing this being a factor in the broader community of users. Redis is still 'go-to' solution in its space. Haven't yet had anyone bring this up.
>I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
I think the biggest thing is - that you acknowledge- that companies (particularly big businesses, like the cloud and service providers) build entire lines of business on this tech without contributing back, monetarily or otherwise, or even worse, try to shorehorn a project into prioritizing what they want over what may be better for the long term health of the community.
These license changes I've seen so far are all attempts to address that. How else are they able to do it with any long term success? They already aren't getting the funding they're looking for, clearly, while businesses build multi million and in some cases billion+ dollar businesses on top of the technology.
I'd argue that old permissive licenses aren't sustainable in the long run for any project like Redis
I'm not seeing this being a factor in the broader community of users. Redis is still 'go-to' solution in its space. Haven't yet had anyone bring this up.
>I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
I think the biggest thing is - that you acknowledge- that companies (particularly big businesses, like the cloud and service providers) build entire lines of business on this tech without contributing back, monetarily or otherwise, or even worse, try to shorehorn a project into prioritizing what they want over what may be better for the long term health of the community.
These license changes I've seen so far are all attempts to address that. How else are they able to do it with any long term success? They already aren't getting the funding they're looking for, clearly, while businesses build multi million and in some cases billion+ dollar businesses on top of the technology.
I'd argue that old permissive licenses aren't sustainable in the long run for any project like Redis
> It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms.
By "used to be" you mean for a brief period in the 2000s, right? Because this extremely generous open source landscape we have seen in the past 20 years were not the normal state of software for most of software's existence.
A generous open source landscape is something we -- you, I, the readers of HN -- have to actively maintain by shouldering the burden of maintaining the correctly licenced software. We cannot trust this important job to profit-making corporations.
By "used to be" you mean for a brief period in the 2000s, right? Because this extremely generous open source landscape we have seen in the past 20 years were not the normal state of software for most of software's existence.
A generous open source landscape is something we -- you, I, the readers of HN -- have to actively maintain by shouldering the burden of maintaining the correctly licenced software. We cannot trust this important job to profit-making corporations.
[deleted]
> 1. Many people had contributed their efforts to the Redis project for free - both in terms of code [...] it was under the understanding that project would remain under the same open source license.
The whole point of the MIT/BSD licenses versus licenses like the GPL is to not be limited by that.
> It honestly felt like a betrayal of trust.
It feels like total ignorance from. If such license change bother you, you should only contribute to projects that are licensed under GPL or similar licenses and that don't force contributors to sign a CLA.
I don't like current Redis license, but nobody lost any code and any contributor can still contribute to any fork that started using the last open source version.
The whole point of the MIT/BSD licenses versus licenses like the GPL is to not be limited by that.
> It honestly felt like a betrayal of trust.
It feels like total ignorance from. If such license change bother you, you should only contribute to projects that are licensed under GPL or similar licenses and that don't force contributors to sign a CLA.
I don't like current Redis license, but nobody lost any code and any contributor can still contribute to any fork that started using the last open source version.
> you could pick an open source project and build a business on it and expect that the project would stay available to you
Why not just stay on the last version with the license of your original choice?
Why not just stay on the last version with the license of your original choice?
The license change is a necessary evil, otherwise BigCo will continue EEE and extract value from the project without giving anything back. It's time to hit them where it hurts. The world will be a better place if Google collapsed tomorrow. FOSS must adapt to SaaS and the modern rent-seeking behaviors of BigCos.
MIT + popularity = commercial license
Yep, when people contribute to a project, they invest more than just code; they invest trust in its principles
> However, during the “writing years” (I’m still writing, by the way), I often returned to coding, as a way to take breaks from intense writing sessions (writing is the only mental activity I found to be a great deal more taxing than coding)
This has been my experience too. With both "Game Programming Patterns" and "Crafting Interpreters", writing the code was a joy while writing the prose was hard work. Gratifying, but mentally draining in a way that programming isn't.
This has been my experience too. With both "Game Programming Patterns" and "Crafting Interpreters", writing the code was a joy while writing the prose was hard work. Gratifying, but mentally draining in a way that programming isn't.
Totally agree. It's very hard, especially since when writing fiction, and the kind of fiction I wanted to write, there are a lot of things you doubt about yourself: is my style as good as I wish? Are my stories and my characters strong enough, with the right motivations? And I bet many of this ingredients are still there even when writing technical books if the goal is to do a very good job. Teaching in written form, with a book, is like a long story that must fit, chapter after chapter, sentence after sentence.
Please keep writing, I want to read your fiction. I cal tell you have style from your blog entries. Lean into the style and readers will love you for it.
Thanks! I can write better in Italian :D But appreciate that you found the blog post to have the right tone.
I find, even in the short stories I write, that managing the story arc is so much harder than managing code execution…
Dropping by in the comments to say many thanks for both of these books.
I have hardcopies of both and "Crafting" remains my all-time favorite programming book.
It's delightful, educational, and beautiful.
I have hardcopies of both and "Crafting" remains my all-time favorite programming book.
It's delightful, educational, and beautiful.
Where did you get the hardcopy? (I already have the paperback for "Crafting Interpreters", but I prefer to buy hardcopies if available)
As far as I was aware, there are only paperbacks.
As far as I was aware, there are only paperbacks.
There are only paperbacks. By "hardcopy", they meant "printed".
I sell print editions through Amazon KDP and IngramSpark. Amazon is the lion's share, so I designed the print edition based on the formats they offer. At the time I started working on it, KDP only supported soft covers. They added hard covers right as I was finishing the book, and I didn't want to have to go back and redo everything.
I have to admit that "Crafting Interpreters" is pushing the limits for what you can get away with on a soft cover. When I first started writing the book, I expected it to be (much) shorter, but I just estimated wrong.
If I had a time machine, I might go back and tell myself to print it as two separate volumes.
I sell print editions through Amazon KDP and IngramSpark. Amazon is the lion's share, so I designed the print edition based on the formats they offer. At the time I started working on it, KDP only supported soft covers. They added hard covers right as I was finishing the book, and I didn't want to have to go back and redo everything.
I have to admit that "Crafting Interpreters" is pushing the limits for what you can get away with on a soft cover. When I first started writing the book, I expected it to be (much) shorter, but I just estimated wrong.
If I had a time machine, I might go back and tell myself to print it as two separate volumes.
I love Crafting Interpreters, it's a fantastic book, and is on my desk beside me right now. Everything about it is just so well...crafted!
I know Amazon is a must for authors, but as an Amazon avoider, I was delighted to able to order it through my local bookshop.
I know Amazon is a must for authors, but as an Amazon avoider, I was delighted to able to order it through my local bookshop.
I'm glad you support a look bookstore too. Those sales are a very small fraction of what I make, but they're the fraction I love the most.
I'm not sure how these services work, but are you planning to offer hard covers as well for a "next print"?
I've had my eye on Crafting Interpreters for a bit now, and I don't mind paying extra for a nicer version — especially if it's going into the pockets of an independent writer.
I've had my eye on Crafting Interpreters for a bit now, and I don't mind paying extra for a nicer version — especially if it's going into the pockets of an independent writer.
If I do a second edition, I'll probably think about it then. I don't have any plans to touch the book any time soon. I worked on it every single day for six years, so when it was done, I was really ready to be done working on it.
I think they meant hardcopy as in “physical copy” not as in “hardcover”
You're welcome! I'm glad you enjoyed them. :)
It's because the audiences for each are different. The audience of programs are CPU cores that have a well defined set of behaviors. An i7 isn't going to one day decide it doesn't like the SHL instruction or offended by having to perform too many MOVs.
The human by comparison is more taxing to write for as your brain is the compiler and checker for the instructions of your language. You write, proof read, correct, proof read again, correct more, delete, re-write, etc. I get why AI tools for writing are in high demand. Hell, sometimes I spend what feels like forever writing some of the comments here on HN as I have to compress a lot of thought into a few, clearly written sentences.
The human by comparison is more taxing to write for as your brain is the compiler and checker for the instructions of your language. You write, proof read, correct, proof read again, correct more, delete, re-write, etc. I get why AI tools for writing are in high demand. Hell, sometimes I spend what feels like forever writing some of the comments here on HN as I have to compress a lot of thought into a few, clearly written sentences.
It's that but even more so: you aren't writing for a single human, but for the superposition of all possible readers of the book.
It's sort of like trying to write a program that is simultaneously valid Perl, C, Ruby, etc.
It's sort of like trying to write a program that is simultaneously valid Perl, C, Ruby, etc.
"Game Programming Patterns" has been of huge help throughout my career and it's always my go to recommendation for new game programmers and reading your comment makes me feel even more grateful that you made the effort of writing it, thanks for writing such a great book!
You're welcome!
Does it have something to do with the ambiguity of our language (english, spanish, _et cetera_) in contrast with formal languages? Like, it would require more mental effort to describe something in the English language, compared to describe an algorithm using language constructs: you know the constructs, and you know your restrictions in the programming language; in the English language, you don't know in advance what can you say and what you cannot, and you have to imagine what is your message going to get across in reader's minds. Well, who knows?
Anyway, absolutely love your books, have the Crafting Interpreters print copy (which has been inadvertently unboxed by my friend; did want it to be still in the plastic) despite using only the website version, and looking forward to buy the Game Programming Patterns. I hope you continue to be successful in your endeavours (especially if they result in legendary books like these :D). Also, could we be looking forward to a version of yours of a CPU architecture book, a la Nand2Tetris ( ͡° ͜ʖ ͡°)?
Anyway, absolutely love your books, have the Crafting Interpreters print copy (which has been inadvertently unboxed by my friend; did want it to be still in the plastic) despite using only the website version, and looking forward to buy the Game Programming Patterns. I hope you continue to be successful in your endeavours (especially if they result in legendary books like these :D). Also, could we be looking forward to a version of yours of a CPU architecture book, a la Nand2Tetris ( ͡° ͜ʖ ͡°)?
Our language centers evolved to build our "natural" languages and our "natural" languages evolved to take the best (most?) use of our language centers. Whether or not it is ambiguity or simplified context or some other "complexity mechanism", if you agree with the Chomsky hierarchy that our "formal" languages are pure subsets of our "natural" languages, then that alone would imply we use only a smaller subset of our language centers when working in "formal" languages.
Though yeah, that does feel awfully reductive as an argument, and leans on a lot of assumptions in Chomsky's theories. I know that there are axes where "formal" languages feel more orthogonal to "natural" languages than "pure subsets". Some parts of "formal" languages to me feel a lot more visual like poetry than linguistic in the same way as prose.
Though yeah, that does feel awfully reductive as an argument, and leans on a lot of assumptions in Chomsky's theories. I know that there are axes where "formal" languages feel more orthogonal to "natural" languages than "pure subsets". Some parts of "formal" languages to me feel a lot more visual like poetry than linguistic in the same way as prose.
I have had the same experience. With coding I can be in that coveted state of flow for 10 hours straight. With creative writing, I feel exhausted after 3 or 4 hours. I didn’t expect this and don’t fully understand why.
There are a couple of reasons as far as I can tell. Programming can be adequately gamified or fulfill basic dopaminergic feedback loops in a way that “true” creative expression (outside of an effort-action-reward feedback loop) cannot. With fiction, the value is strictly non-instrumental or context-specific. While the parsimony of the (formal) language you deploy can be (reflexively) satisfying to look back on, the real joy of art for its own sake is the response from the reader, which is necessarily slower than that of a computer, as it requires a more complicated system of evaluation than pure utility.
> Game Programming Patterns
Huh, I own this in a print copy. Thank you so much for writing it :)
Huh, I own this in a print copy. Thank you so much for writing it :)
Would Game Programming Patterns help someone who wants to build a slot machine? I’ve built a wall mounted machine for my home but I never got the software side done. I think a book could help but most of them cover very different mechanics these days.
Why the down-votes? Are people specifically opposed to gambling or is it something else I said? I'm just wanting to write a hobby slot machine because they fascinate me but the mechanics of a slot machine UI are quite different than a 2D scroller or a 3D game engine.
I do appreciate the author answering. Thank you.
I do appreciate the author answering. Thank you.
Honestly, probably not. It's about software architecture for games, and not about game mechanics specifically.
That's really interesting - was chatting to a few friends who are very into using tools like cursor to generate code. They've been complaining of feeling extremely drained after a day of prompt writing.
I'm really interested in this bit: "the fracture with the community is not about licensing, or at least it’s not mainly about licensing"
I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?
I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?
For somebody, like you and many others, it was very important to retain an OSI license. But I feel that in general given that the new license is IMHO good for almost every user, from the POV of what they can do with the code, and that the cloud situation was quite self evident, I believe that with better communication, and immediate developments/merges in the core, to counter balance the license switch, many people would understand the license matter.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
> is IMHO good for almost every user, from the POV of what they can do with the code
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
> I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't.
Hum, I have not considered this aspect before - I mean I've realized that AWS probably cannot use Redis [until they pay back], but that users (customers) would be affected...likely I'm biased here cuz not using managed services of that sort, sat having Redis + Sentinel setup of our own.
Hum, I have not considered this aspect before - I mean I've realized that AWS probably cannot use Redis [until they pay back], but that users (customers) would be affected...likely I'm biased here cuz not using managed services of that sort, sat having Redis + Sentinel setup of our own.
It sounds like your opinion is that the communication around the relicensing was the issue rather the relicensing itself, but from the standpoint of the people who decided there was enough of an issue to switch away from Redis, is that the case? As an outsider to the Redis community both before and after the schism, I don't know that you're wrong, but I have to imagine that if I were someone concerned enough to consider forking (or switching to a fork), I wouldn't be happy with someone involved in the project making a blanket statement about whether my motivations were actually about the licensing or not. Ironically, this seems like it's exactly the type of communication that could exacerbate concerns around licensing.
How many, outside a few vocal voices, actually cares about the licensing? My company would choose Redis 100/100 times, because it's the known and trusted brand, and not some fork they've never even heard of. And the license change doesn't affect us in any way.
Additionally, I think it's a bit entitled to be so up in arms about a product everyone is using for free. There is a big issue with how open source is unmaintainable to do in our industry, and I applaud Redis' attempt at trying to fix it.
Additionally, I think it's a bit entitled to be so up in arms about a product everyone is using for free. There is a big issue with how open source is unmaintainable to do in our industry, and I applaud Redis' attempt at trying to fix it.
I don't personally have a strong opinion about relicenses to try to prevent competitors from selling cloud-bases services (either in the case of Redis or in general; if anything, having worked at MongoDB at the time when it was relicensed to SSPL biases me a little bit in favor of companies who do relicenses like this). My perception is that there's a non-trivial contingent of users who migrate whenever something like this occurs, but you're not wrong that this might be influenced by a smaller number of louder voices.
I do agree with you about open source developers being within their rights to maintain as they see fit. My personal philosophy is that while open source maintainers have no obligation to maintain in a way that conforms to user expectations, users still have the right to voice their opinions on that (although the maintainers are free to ignore it, per the previous point). To me, the distinction that matters isn't about whether users are "entitled" or not but whether they're voicing opinions about an open source project (including decisions about how to maintain it) versus personal insults at individuals. I don't see anything wrong with someone being vocally upset about a license change; I just also don't see anything wrong with a maintainer choosing not to care about it.
I do agree with you about open source developers being within their rights to maintain as they see fit. My personal philosophy is that while open source maintainers have no obligation to maintain in a way that conforms to user expectations, users still have the right to voice their opinions on that (although the maintainers are free to ignore it, per the previous point). To me, the distinction that matters isn't about whether users are "entitled" or not but whether they're voicing opinions about an open source project (including decisions about how to maintain it) versus personal insults at individuals. I don't see anything wrong with someone being vocally upset about a license change; I just also don't see anything wrong with a maintainer choosing not to care about it.
> I do agree with you about open source developers being within their rights to maintain as they see fit.
I used to agree with this, but it now seems a rather narrow view of how open source actually works. Open source projects tend to make a big deal about being a "community," and this is certainly true of many that are backed by commercial vendors. To me the use of community does imply mutual obligations between developers and users or the word has no meaning.
Unless, that is, you think community is just a synonym for "marketing funnel."
I used to agree with this, but it now seems a rather narrow view of how open source actually works. Open source projects tend to make a big deal about being a "community," and this is certainly true of many that are backed by commercial vendors. To me the use of community does imply mutual obligations between developers and users or the word has no meaning.
Unless, that is, you think community is just a synonym for "marketing funnel."
One thing is the normal user concerns, that are granted, and I understand and respect them. Another thing is forking, that in the specific case of ValKey was an effort whose impulse was provided by companies having an economic damage because of the license switch. So I think those are two orthogonal questions.
Hmm, I think I see. If I understand correctly, your opinion is that independent of the motivations of the forks, independent users switching to the forks could have been avoided with better communication? I guess that's a fair stance, although I'm not sure I fully agree with it. From what I can tell, there's a fairly large contingent of open source users who won't be happy with a license being changed to something they don't consider open source regardless of the rationale.
I hear you, but at the same time it was badly done. I’ve been referring to Redis as “a proprietary fork of Valkey,” and that message has clearly resonated.
Isn't that just lying?
Why? The original opensource lineage is valkey, it just changed the name. Redis is where the oss history forks and turns proprietary.
That's like saying Xfree86 is a fork of X.org, MySQL is a fork of MariaDB, or OpenOffice is a fork of LibreOffice. "Forking" is an event that happens in time, so project A cannot be a fork of project B if A existed before B.
They both were the same project with the same codebase and the same contributors before they split. It was as much project A as it was project B.
> It was as much project A as it was project B.
Valkey is as much Redis as it is Valkey? Then why isn't it called "Redis"? Clearly there's a distinction or the fork would never have happened. Is Redis also as much Valkey as it is Redis?
Names signal who has control over a project, not anything about its history/implementation/license. Otherwise every piece of software that goes through a rewrite should change its name.
Valkey is as much Redis as it is Valkey? Then why isn't it called "Redis"? Clearly there's a distinction or the fork would never have happened. Is Redis also as much Valkey as it is Redis?
Names signal who has control over a project, not anything about its history/implementation/license. Otherwise every piece of software that goes through a rewrite should change its name.
Projects also don’t necessarily change names when control over them changes either. It’s the Ship of Theseus kind of thing. There is no single property that would delimit when software stops being itself. And the name is hardly the most important part.
After all, the identity of ever-changing entities is ephemeral and is only in our heads.
After all, the identity of ever-changing entities is ephemeral and is only in our heads.
"Valkey" is not called "Redis" because as much as the development is shared by the community, the trademark isn't.
A lot of developers and users are sticking with the community and the license instead of sticking with the trademark holder.
> Names signal who has control over a project
Trademark is a specific form of intellectual property and there are many others. I don't understand how you got to that conclusion to be honest. A restaurant in my neighborhood had to change name recently because it was too similar to a big chain, does that mean it's a different restaurant now?
A lot of developers and users are sticking with the community and the license instead of sticking with the trademark holder.
> Names signal who has control over a project
Trademark is a specific form of intellectual property and there are many others. I don't understand how you got to that conclusion to be honest. A restaurant in my neighborhood had to change name recently because it was too similar to a big chain, does that mean it's a different restaurant now?
> But I feel that in general given that the new license is IMHO good for almost every user
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.
I care about getting things done but don't want to take on the risk of an encumbered license and the volatility that comes with license changes.
To me, these products are booby traps that are more likely to need replaced in the future when something changes again.
Put another way, it's a sign of an unhealthy ecosystem.
There's so much gray area in these terms you have to keep the lawyers involved not only in the initial indentation but product features in the future to make sure you don't accidentally cross a very poorly defined line.
To me, these products are booby traps that are more likely to need replaced in the future when something changes again.
Put another way, it's a sign of an unhealthy ecosystem.
There's so much gray area in these terms you have to keep the lawyers involved not only in the initial indentation but product features in the future to make sure you don't accidentally cross a very poorly defined line.
> I care about getting things done
Yes. But you care about more than just that....
Yes. But you care about more than just that....
I'm a vendor of some packaged on-premise solution. We are using a Redis as a cache layer inside. Risk of being forced to GPL out our installer is unacceptable for us.
In your use case, you could not even use the AGPL, basically? Is that what you mean? Thanks. That would be an interesting point, but it goes over the borders of the SSPL itself. Would be more BSD/MIT vs all the rest.
No, we can provide proprietary scripts that install GPLed software (i.e. setup Linux machines), but can't provide proprietary scripts that install AGPL.
Thanks for directly expanding on this.
also, lack of japanese and korean support... and non-willingness to integrate this when developers native speakers even want to and volunteer to improve it.
something is off in redis execution
hope with this guy comes back it improves!
something is off in redis execution
hope with this guy comes back it improves!
Yeah, I have the same question, I wasn't sure if he had said what he does think the fracture was mainly about and I missed it.
you can see there is shift from roots in redis. original over-the-write protocol was human-redable by design. now more and more over last couple years API and instrumentation, docs, gets non-human readable at all (mix of ASCII and hex binary encoding, say in FT.SEARCH, speaking of FT.SEARCH it is barely readable even when in non-binary form...)
Yeah, even if the split isnt entirely about licensing (and I do think it mainly is), the rest is a result of the licensing changes as well in terms of the implications and side-effects. Its the way people felt rug pulled and eroding the trust, which is now forever lost.
Techbros and large corporations still have the original source code they built their business on. What they want is free community updates and support forever while they give almost nothing back. So it's not a licensing problem. It's not a free software problem. It's a "free as in beer" support problem.
AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.
AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.
That's not been my experience. My limited experience at a large corporation was "throw money at vendors for enterprise support"
The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.
The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.
I appreciate redis, but believe me when I say, I never considered using redis under anything but its original license, and I am just as grateful for valkey as I am for redis. It is very easy to move and I will keep moving anytime there is a license switch-up like this. I prefer a fork rather than an alternative, but if a good fork hadn't emerged, I would have moved to something different with its own technical advantages and drawbacks.
What parts of the new licence are particularly critical for this decision? Just curious.
Love this, welcome back Salvatore -- hopefully it's fulfilling and fun. You authoring some new vector primitives seem to indicate to me you might be back in your sweet spot.
Getting a 100x engineer back to making new things is great for the world.
Some thoughts on vectors and embeddings and etc; there was a spate of companies that launched RAG-related "new" databases a couple of years ago, and obviously we have plugins to major databases now. I appreciate the idea that some low level tools, properly tuned, will be maximally useful. There was a lottt of overhead playing with those vector dbs, and often in testing I would just want to throw up like 10,000 embeddings and do some things with them; I didn't want to have to choose a pytorch variant in a docker image to do so.
Anyway. It makes me wonder what else would be useful to have on the AI support side. I'll look forward to playing around with the module.
Getting a 100x engineer back to making new things is great for the world.
Some thoughts on vectors and embeddings and etc; there was a spate of companies that launched RAG-related "new" databases a couple of years ago, and obviously we have plugins to major databases now. I appreciate the idea that some low level tools, properly tuned, will be maximally useful. There was a lottt of overhead playing with those vector dbs, and often in testing I would just want to throw up like 10,000 embeddings and do some things with them; I didn't want to have to choose a pytorch variant in a docker image to do so.
Anyway. It makes me wonder what else would be useful to have on the AI support side. I'll look forward to playing around with the module.
Another thing that kinds of sucks about this whole "license rug-pull" kind of business is that other teams (like ours) who are publishing open-source software/tools are now suspects too.
Folk ask themselves, why contribute to this thing (MIT/GPL licenses) if there some for-profit entity involved?
Folk can't take us at face-value (I'd argue demonstrated value) and level (unfounded) accusations at us; because some other player did things "dirty".
Well, other folk wanted to pay for support/customisation and in USA you make a for-profit entity to do that. So the corporate part of the open-source project is, nearly, a requirement.
Folk ask themselves, why contribute to this thing (MIT/GPL licenses) if there some for-profit entity involved?
Folk can't take us at face-value (I'd argue demonstrated value) and level (unfounded) accusations at us; because some other player did things "dirty".
Well, other folk wanted to pay for support/customisation and in USA you make a for-profit entity to do that. So the corporate part of the open-source project is, nearly, a requirement.
"Folk ask themselves, why contribute to this thing (MIT/GPL licenses) if there some for-profit entity involved?"
You put MIT or GPL in the same bucket here, but really shouldn't because the difference is all that matters.
There is no "rug-pull" as you call it. What happened with Redis is what the BSD license allows and what people should expect to happen.
The combination of GPL (or AGPL) with a large enough and diverse set of contributors who keep their rights in their contributions is a proven way to prevent what happened with Redis.
It is our decision as publishers of open-source projects which way we want to go. It is our decision as contributors which open-source projects we support.
Both ways are fine, but blaming others that you regret your decision is not.
You put MIT or GPL in the same bucket here, but really shouldn't because the difference is all that matters.
There is no "rug-pull" as you call it. What happened with Redis is what the BSD license allows and what people should expect to happen.
The combination of GPL (or AGPL) with a large enough and diverse set of contributors who keep their rights in their contributions is a proven way to prevent what happened with Redis.
It is our decision as publishers of open-source projects which way we want to go. It is our decision as contributors which open-source projects we support.
Both ways are fine, but blaming others that you regret your decision is not.
> The combination of GPL (or AGPL) with a large enough and diverse set of contributors who keep their rights in their contributions is a proven way to prevent what happened with Redis.
Also the lack of a CLA (and/or copyright assignment) because many "modern" projects under the GPL ask you to waive your rights away, thus nullifying the license. Do not contribute to them if you have any self-respect.
https://drewdevault.com/2021/04/12/DCO.html
Also the lack of a CLA (and/or copyright assignment) because many "modern" projects under the GPL ask you to waive your rights away, thus nullifying the license. Do not contribute to them if you have any self-respect.
https://drewdevault.com/2021/04/12/DCO.html
I have self-respect and have no problem contributing to projects with a CLA and copyright assignment. I recognize that I don't control what happens with my contributions, as I have consciously agreed to their terms. Controlling what happens in the future of a project simply has never had anything to do with my motivations for contributing to a project.
[deleted]
Good to point out CLAs and thanks for the link. It is a good read.
Mongo was AGPL until 2018. The AGPL didn’t stop Amazon from abusing the open source social contract, hence why Mongo modified the license.
Yep, but developers signed away their rights to MongoDB Inc. That is why I wrote "contributors who keep their rights in their contributions" above.
It is what makes all the difference between MongoDB and Linux, for example. What happened to MongoDB could never happen to Linux.
It is what makes all the difference between MongoDB and Linux, for example. What happened to MongoDB could never happen to Linux.
Disclosure: I work for Amazon.
AWS never offered a service based on the AGPLv3 version of the MongoDB server. Therefore the change of license terms to SSPLv1 was not directly caused by Amazon’s use of the software as part of an offered service, and had no impact to Amazon DocumentDB as an independently developed interoperable protocol implementation.
There were cloud providers headquartered in Asia that did offer AGPLv3 based MongoDB server as a service.
AWS never offered a service based on the AGPLv3 version of the MongoDB server. Therefore the change of license terms to SSPLv1 was not directly caused by Amazon’s use of the software as part of an offered service, and had no impact to Amazon DocumentDB as an independently developed interoperable protocol implementation.
There were cloud providers headquartered in Asia that did offer AGPLv3 based MongoDB server as a service.
The BSD license doesn't allow changing it to another license any more or less than GPL.
Yes it does. You can make a private, proprietary app that’s just tweaking a few bits of a BSD project. You can’t do that with the GPL.
Following that, unless the project has a CLA (so that the owner of the project reserves all rights of the code that’s contributed and essentially owns the contribution), any contributions made under the GPL cannot be made closed source, can’t be switched to an incompatible license, etc, because the contribution itself is GPL’d.
Following that, unless the project has a CLA (so that the owner of the project reserves all rights of the code that’s contributed and essentially owns the contribution), any contributions made under the GPL cannot be made closed source, can’t be switched to an incompatible license, etc, because the contribution itself is GPL’d.
Creating a commercial version of a thing is not a license change.
Of course, I said proprietary. You said commercial.
Proprietary refers to ownership and licensing. While I somewhat conflated it with closed-source in my comment, it nevertheless applies since we are talking about the ability to make it closed source.
You can relicense derivative works of MIT or BSD software provided that you satisfy the original license requirements (attribution). This is irrelevant of commercializing it.
Conversely, and to your point, you can sell GPL software you didn’t write, or sell a derivative work of it, but because of the copyleft nature, your derivative work must also be licensed under a compatible GPL license.
Proprietary refers to ownership and licensing. While I somewhat conflated it with closed-source in my comment, it nevertheless applies since we are talking about the ability to make it closed source.
You can relicense derivative works of MIT or BSD software provided that you satisfy the original license requirements (attribution). This is irrelevant of commercializing it.
Conversely, and to your point, you can sell GPL software you didn’t write, or sell a derivative work of it, but because of the copyleft nature, your derivative work must also be licensed under a compatible GPL license.
I look at bun in the JS ecosystem like this. They are open source for now but also backed by VCs. They will have to make money at some point.
I have no interest in engaging with that product just to have a new pricing model thrown my way and disrupt everything.
I have no interest in engaging with that product just to have a new pricing model thrown my way and disrupt everything.
It is not even the for-profit thing, it is the VC, because they will be expect to make millions and millions off the project and that is not really possible with just support contracts and similar
You don't need to ask people to rely on your promises. Just make sure that you are not able to do a rug pull, and explain that. It's generally pretty easy (just don't require a CLA) but you can make it clearer. For example, clarify that you don't own everyone's copyright by writing a copyright notice which includes all of the project's contributors.
There are some practical suggestions at https://reuse.software/tutorial/
There are some practical suggestions at https://reuse.software/tutorial/
What would you feel if you did all the work, but other companies made all the money by redistributing your software? Wouldn't you find that unmaintainable in the long run?
Hehehe,
Reading between the lines. Redis is Hurting, Valkey is making a real difference at pulling the customers away. Elastic and OpenSearch were in similar situation, so Elastic went on to change license back to (more restrictive) Open Source License.
Redis went different route by bringing Redis founder back. I wonder if they go back on their license change next or do they think Redis founder endorsing license change, despite his previous promises of Redis being Open Source forever is enough ? Time will tell.
Reading between the lines. Redis is Hurting, Valkey is making a real difference at pulling the customers away. Elastic and OpenSearch were in similar situation, so Elastic went on to change license back to (more restrictive) Open Source License.
Redis went different route by bringing Redis founder back. I wonder if they go back on their license change next or do they think Redis founder endorsing license change, despite his previous promises of Redis being Open Source forever is enough ? Time will tell.
Except this is not true: I mean, I asked to rejoin, not because I evaluated the situation of the company, but since I wanted to do more hacking / community stuff. So you see what happens trying to read too much between the lines? That you invent what satisfies your needs as a reader, but drives you away from what actually happened. P.S. at Redis they didn't expected this at all and were really surprised.
And about switching to a more open license, who knows? Maybe we will be doing that as well if it offers enough protection - I'm not in charge for such decision but... I can suggest things -, so thank you for the idea (kidding apart, I was already talking about this possibility inside the company).
And about switching to a more open license, who knows? Maybe we will be doing that as well if it offers enough protection - I'm not in charge for such decision but... I can suggest things -, so thank you for the idea (kidding apart, I was already talking about this possibility inside the company).
Perhaps. I've seen people seen/write all kind of stuff when serious money are involved, and I also was offered to just just that on number of occasions.
I appreciate your honesty in disclosing what you still have Redis Labs stock, and assuming it is anything reasonable their value at future IPO would be much larger than any cash compensation which you might be getting as the part of the deal.
Reality is you did not fulfil (chose to or could not, I do not know) your public promise to keep Redis Open Source https://antirez.com/news/120
I hope your return will positively impact Redis as Open Source Project. Yet I'm disappointed to read your position on the Redis License - seeing cloud non compete license "basically as good as open source", as I far as I'm concern for many users which want to have software ran for them, and consume it as DBaaS it is no different to proprietary license, as it prevents competition.
I appreciate your honesty in disclosing what you still have Redis Labs stock, and assuming it is anything reasonable their value at future IPO would be much larger than any cash compensation which you might be getting as the part of the deal.
Reality is you did not fulfil (chose to or could not, I do not know) your public promise to keep Redis Open Source https://antirez.com/news/120
I hope your return will positively impact Redis as Open Source Project. Yet I'm disappointed to read your position on the Redis License - seeing cloud non compete license "basically as good as open source", as I far as I'm concern for many users which want to have software ran for them, and consume it as DBaaS it is no different to proprietary license, as it prevents competition.
It's wild to me that the prevailing opinion seems to be "It is only TRUE Open Source if megacorps can modify the software and resell it without sharing their modifications".
The hosted vs. distributed loophole is just that, a loophole. If, when the GPL was first published, the world was cloud-hosted and SaaS-ful, the GPL would either have included some provision like the SSPL, or it would have had relatively little impact on the world.
I understand complaints about a lack of clear boundaries or overreach in these licenses. But acting like these aren't attempting to close a loophole being abused seems crazy to me.
The hosted vs. distributed loophole is just that, a loophole. If, when the GPL was first published, the world was cloud-hosted and SaaS-ful, the GPL would either have included some provision like the SSPL, or it would have had relatively little impact on the world.
I understand complaints about a lack of clear boundaries or overreach in these licenses. But acting like these aren't attempting to close a loophole being abused seems crazy to me.
What loophole was being abused that caused Redis the company to pull the proverbial rug?
The "big evil corporation" that usually gets referenced is AWS. One of the core comitters to the Redis project when it was open source, was paid to do so, by AWS, and continues to be paid to do so, on the open source fork, ValKey.
It's fine to make an argument about "take it and give nothing back" when comparing the potential differences of permissive vs copyleft licenses. I likely wouldn't agree with you about which is ultimately a better choice, but I think it's fine to make that argument there.
But this isn't a hypothetical. It's an actual situation, where a permissively licensed project had significant outside contributions... and still people are screaming about "the evil mega corp"... who is now even more involved in maintaining a permissively licensed fork of said software.
I'm far from an AWS fan. I avoid it whenever possible, and I've made good money migrating customers off of AWS' overpriced services, but I've yet to see a single example of them doing anything that fulfils the "evil mega corp" shoe, w.r.t Redis.
The "big evil corporation" that usually gets referenced is AWS. One of the core comitters to the Redis project when it was open source, was paid to do so, by AWS, and continues to be paid to do so, on the open source fork, ValKey.
It's fine to make an argument about "take it and give nothing back" when comparing the potential differences of permissive vs copyleft licenses. I likely wouldn't agree with you about which is ultimately a better choice, but I think it's fine to make that argument there.
But this isn't a hypothetical. It's an actual situation, where a permissively licensed project had significant outside contributions... and still people are screaming about "the evil mega corp"... who is now even more involved in maintaining a permissively licensed fork of said software.
I'm far from an AWS fan. I avoid it whenever possible, and I've made good money migrating customers off of AWS' overpriced services, but I've yet to see a single example of them doing anything that fulfils the "evil mega corp" shoe, w.r.t Redis.
This argument about "evil megacorp" is problematic because you can't really isolate those from the small and wonderful startups.
Specifically I've been directly involved in MongoDB ecosystem with FerretDB and there are so many small indie providers worldwide would love to offer MongoDB Atlas alternative to their customers, but can't because of SSPL license.
I know, for many it is hard to make piece with it - Open Source, for real means EVERYONE can use it for ANY PURPOSE, and this means for good and for evil, both "good guys" and "bad guys"
Specifically I've been directly involved in MongoDB ecosystem with FerretDB and there are so many small indie providers worldwide would love to offer MongoDB Atlas alternative to their customers, but can't because of SSPL license.
I know, for many it is hard to make piece with it - Open Source, for real means EVERYONE can use it for ANY PURPOSE, and this means for good and for evil, both "good guys" and "bad guys"
Small indie providers should absolutely be able to sell their MongoDB / Redis / XYZ as a service, but they should absolutely also be required by the license to contribute back their modifications to the software.
Like I said, I understand the complaints about the line-drawing issues with these licenses. I don't understand the viewpoint that the current state of OSS, where hosting != distribution, is acceptable.
Like I said, I understand the complaints about the line-drawing issues with these licenses. I don't understand the viewpoint that the current state of OSS, where hosting != distribution, is acceptable.
So just use AGPL. It covers hosting, it requires providing modifications, it's actually Open Source without caveats.
AGPL covers users interacting with the software remotely through a computer network which is not the same as covering hosting. There's often overlap but if it really is hosting that a project doesn't want to allow then they need something other than AGPL.
If you want to prohibit hosting then yes you're going to need a non-OSS license (by definition), but that's moving the goalposts: I was replying to a post that said others should be allowed to sell the software as a service, but that they should be forced to share their changes even if they're "hosting" and not "distributing"... AKA the exact point of the AGPL existing.
AGPL's tying that to users remotely interacting with the software over a computer network still leaves a lot of uncertainty about when it applies.
Consider this case. Suppose there is a chess server that users can interact with remotely over a computer network to play chess against other users or against a chess engine.
On the same host that is running the chess server there is a database server, which is only accessible via a Unix domain socket on that host. The chess server uses that database to store game scores, an opening database, and some endgame databases.
The database server is AGPL. Are users of the chess server entitled to the source to any local modifications that have been make to the database server?
Does it depend on whether it was the people running the chess server who modified the AGPL code or of the modified AGPL database was provided by the hosting company?
Most of the incidents I remember where a software developed was unhappy with someone offering a hosted version of their software were cases where the hosted version was mostly being used by clients of the hosting service and being accessed over the hosting services internal network rather than cases were someone was hosting a version of the software to provide that software's services to end users.
Consider this case. Suppose there is a chess server that users can interact with remotely over a computer network to play chess against other users or against a chess engine.
On the same host that is running the chess server there is a database server, which is only accessible via a Unix domain socket on that host. The chess server uses that database to store game scores, an opening database, and some endgame databases.
The database server is AGPL. Are users of the chess server entitled to the source to any local modifications that have been make to the database server?
Does it depend on whether it was the people running the chess server who modified the AGPL code or of the modified AGPL database was provided by the hosting company?
Most of the incidents I remember where a software developed was unhappy with someone offering a hosted version of their software were cases where the hosted version was mostly being used by clients of the hosting service and being accessed over the hosting services internal network rather than cases were someone was hosting a version of the software to provide that software's services to end users.
I think the "root" of the problem goes to what is the purpose of Open Source ?
I see a lot of VC Funded founder convinced what Open Source should make their business model easy, hence licenses such such as SSPL should be called Open Source.
I believe Open Source is about software users and maximizing their freedom, which among other things choice of truly independent vendors in all circumstances, as such non compete licenses as SSPL are not
Are they better than Oracle-like proprietary licenses ? Of course! but they are not Open Source
I believe Open Source is about software users and maximizing their freedom, which among other things choice of truly independent vendors in all circumstances, as such non compete licenses as SSPL are not
Are they better than Oracle-like proprietary licenses ? Of course! but they are not Open Source
Yep. It is exactly the same as with Oracle - you can use it IF you buy the license... but this also has requirements of playing the Vendor game and as provider you really use freedom to really take care of your customers
> If, when the GPL was first published, the world was cloud-hosted and SaaS-ful, the GPL would either have included some provision like the SSPL, or it would have had relatively little impact on the world.
Well, no on the first one. We know exactly what the GPL looks like to protect users against proprietary network hosted software: the GNU Affero General Public License.
Well, no on the first one. We know exactly what the GPL looks like to protect users against proprietary network hosted software: the GNU Affero General Public License.
But SSPL is already a modification of AGPL, so its terms don't seem to have be sufficient.
The SSPL's network provision also requires SaaS companies to release the source of any other services and APIs they made the original software dependent on; hard to tell if that's still a valid copyright licence or more of a contract.
Contrast them with EUPL, which represents the strongest copyleft the EU commission thinks a licence, as opposed to a contract, could get away with under EU directives (ignoring its compatibility clause). I'm personally wary of AGPL/SSPL not because their terms, but because the viral claises are likely to be a legal fiction where I live.
The SSPL's network provision also requires SaaS companies to release the source of any other services and APIs they made the original software dependent on; hard to tell if that's still a valid copyright licence or more of a contract.
Contrast them with EUPL, which represents the strongest copyleft the EU commission thinks a licence, as opposed to a contract, could get away with under EU directives (ignoring its compatibility clause). I'm personally wary of AGPL/SSPL not because their terms, but because the viral claises are likely to be a legal fiction where I live.
Meanwhile, it’s wild to me that you seem to think open source means “free for everyone… except them - they make too much money.”
That's not even remotely what I'm saying.
I'm saying if a company modifies open source software and distributes it, they should be required to distribute the modified source as well. I'm further claiming that providing a hosted service is a form of distribution.
> “free for everyone… except them - they make too much money.”
Free for everyone, and if you make changes to improve it, and let others use the software you changed, you contribute those changes back. That's the basic principle of OSS, no?
I'm saying if a company modifies open source software and distributes it, they should be required to distribute the modified source as well. I'm further claiming that providing a hosted service is a form of distribution.
> “free for everyone… except them - they make too much money.”
Free for everyone, and if you make changes to improve it, and let others use the software you changed, you contribute those changes back. That's the basic principle of OSS, no?
> That's the basic principle of OSS, no?
No, only for GPL. If the project has a BSD or MIT licence you may distribute the compiled version and keep the changes secret.
No, only for GPL. If the project has a BSD or MIT licence you may distribute the compiled version and keep the changes secret.
Apologies for the caricature.
It’s clearly up for debate, but I’ve always thought that imposing obligations for how people use the product/code, or implying obligations for what the project is “owed” by users, isn’t free as in freedom, or beer. So I don’t think it’s a basic principle of open source. I think some people want it to be though.
I get it though. People see aws et al making a business model of hosting FOSS and making boatloads of money doing it, and they don’t like it.
It’s clearly up for debate, but I’ve always thought that imposing obligations for how people use the product/code, or implying obligations for what the project is “owed” by users, isn’t free as in freedom, or beer. So I don’t think it’s a basic principle of open source. I think some people want it to be though.
I get it though. People see aws et al making a business model of hosting FOSS and making boatloads of money doing it, and they don’t like it.
This opinion seems to require the idea that targeted license changes that are intentionally devastating (going from "do anything" to requiring relicensing all/some of your stack) will only ever be used against "the bad guys" tm and OF COURSE we agree on who "the bad guys" tm are and OF COURSE that will never be me or you _trust me bro_.
Feels like a cliche "first they came for the richest saas providers and we said nothing..."
Feels like a cliche "first they came for the richest saas providers and we said nothing..."
> At some point my daughter, who is now 12, and is a crucial person in my life, enlightening my days with her intelligence, creativity and love, wanted to visit NYC for her birthday.
I know this wasn't the point of the post, but it was the most beautiful thing I've read all week, and really sums up how I feel about my own children. A small aside in a much longer post but incredibly humanizing and wonderful.
I know this wasn't the point of the post, but it was the most beautiful thing I've read all week, and really sums up how I feel about my own children. A small aside in a much longer post but incredibly humanizing and wonderful.
I'm not a christmas person. Lights are pretty and I may throw up a piece of tinsel and a reef to make it seasonal but overall not a fan of the holiday.
I went down to the cafeteria today at work and they had school children carol singers. Seven/Eight years old singing Christmas tunes. I have to say it touched me, they were really putting their hearts in to it. The warm innocent spirit of something they believed in.
I then grabbed my styrofoam tasting lunch and then fell back in to my cynical self for the rest of the day. But it's pleasant to keep memory of.
I went down to the cafeteria today at work and they had school children carol singers. Seven/Eight years old singing Christmas tunes. I have to say it touched me, they were really putting their hearts in to it. The warm innocent spirit of something they believed in.
I then grabbed my styrofoam tasting lunch and then fell back in to my cynical self for the rest of the day. But it's pleasant to keep memory of.
That vector sets design outlined towards the end of the article is delightful - it's exactly the kind of API design I appreciate from Redis over the years: simple, elegant and feels obviously correct to me.
Very happy to read this from you, Simon!
Where would a Redis vector store play a part though? Maybe you'd load up relevant embeddings for a particular user while they're interacting with their dataset, to make their responses quicker? You've already spent the effort on hydrating their data out of persistence though. I guess step one is likely being a more trusted alternative to the in-memory vector solutions like HNSW, Faiss, and a potentially faster engine than pg_vector. I've always seen Redis as an augmentation, but maybe in this role it can take the helm?
It's exactly that. Redis is an in-memory data structure server that you can outsource index-style operations to. Vector similarity is a type of index search. I think it's an exact fit for Redis.
Cool. Redis in front of Postgres always brought peace-of-mind that will likely be welcome for the vector data use-case.
P.s.: Appreciate the llm command line tool.
P.s.: Appreciate the llm command line tool.
yeah! much better than FT.SEARCH monstrosity...
This piece, while providing context, makes me question basically everything about Redis, despite it's lovely API.
Antirez extolling the virtue of the current LLM wave of hype coupled with his bizarre apologism for Redis Labs behavior is less strange than "why is this guy not 1)personally extremely wealthy 2)having reserved some key powers and control from Redis Labs from day1 such that he could have steered this, aka why content to be a somewhat powerless entity throughout the whole story of what happens to rhe software he wrote"
I also felt like the entire essay felt milquetoast as if Antirez was assigned to do damage control and upon recitation of the actual events, felt the need to defend his own choices to himself, as if he didn't even believe himself, defensive?
I have a huge amount of respect for the core design and its philosophy, FWIW
Antirez extolling the virtue of the current LLM wave of hype coupled with his bizarre apologism for Redis Labs behavior is less strange than "why is this guy not 1)personally extremely wealthy 2)having reserved some key powers and control from Redis Labs from day1 such that he could have steered this, aka why content to be a somewhat powerless entity throughout the whole story of what happens to rhe software he wrote"
I also felt like the entire essay felt milquetoast as if Antirez was assigned to do damage control and upon recitation of the actual events, felt the need to defend his own choices to himself, as if he didn't even believe himself, defensive?
I have a huge amount of respect for the core design and its philosophy, FWIW
What's truly bizarre is the popularity on this site of questioning someone's own stated experience with finding LLM tools useful. On a site called hacker news, that usually celebrates useful computer tools. I'll never understand the obvious luddism here.
Why do you think they would be extremely wealthy, given it's a product they're giving away for free, and it was everyone else (like cloud providers) making money off of it?
Redis is valued at roughly $2 billion. The author owned all of it at some point. It is not strange to assume they would be wealthy.
Why do you assume that he isn’t extremely wealthy?
Given the timeline leaving before the change and coming back after with the mentioned stock options one could almost assume it was his idea.
Given the timeline leaving before the change and coming back after with the mentioned stock options one could almost assume it was his idea.
"Hapless" is the word that comes to mind.
I mean, if the OSS you write gets commercialized and you aren't the one commercializing it...
To play devil's advocate, even though I'll probably never write anything remotely close to as popular as Redis, if by some cosmic accident I accidentally make something open source with enough popularity that it could be made into a business, I wouldn't have any desire to be the one to do it because I have zero interest in owning or running a business in the first place. I don't think it's really that bizarre or hard to imagine that someone like making things that people find useful but not want to have to spend the immense time and emotional energy into being in charge of turning it into something that makes a profit. Some people are genuinely not motivated by money beyond enough to be comfortable, and I firmly believe that's not a bad thing!
Really enjoyed the Salvatore's write up. Two things grabbed my attention:
1. He is also an admirer of the Claude! I can't emphasize this enough but coding has almost always been an isolating state for me. But now, you can feel some support with some intelligence! This is sci-fi! it's much more efficient than Google Search and docs. Not sure about the value added here, but when Salvatore explains how he's using the Gen AI for writing software, I really get to grips with my impostor syndrome.
2. Second: "One thing I particularly liked about the article was that Salvatore explained how he is using the Claude (any Gen AI) in his work. Salvatore is one of the programming figures for me (started professional programming in 2016~2017) and I am feeling really relived that these people confess using the Gen AI trick for writing software." this is were SWE ends and product starts!
Absolutely, I get any help I can, to do better work.
Trick for the sci-fi story I used. Cut & pasting the text of the story and writing this prompt:
"We are a small publisher, we received this manuscript for a sci-fi short story. We only publish top quality stuff, we don't want any garbage. Please tell us if this story is worth publishing in our high quality series, and what we should reply to the author."
This way it is really sharp and identifying what is lacking. It's like an editor review. Then you go back to work for 2/3 days. And check back to see if your work improved. But the important part here is that many bad things he says you know are true. You needed somebody to tell you, to put more efforts into it.
With programming, while I have some knowledge of math, sometimes for the kind of programming I want to do I need to explore stuff I didn't study or know. And also in this regard Claude has been totally incredible. And so forth.
I also use it to find potetial issues in my desing ideas. Of course if it says something that I don't recognized as a true issue, I just don't care.
Trick for the sci-fi story I used. Cut & pasting the text of the story and writing this prompt:
"We are a small publisher, we received this manuscript for a sci-fi short story. We only publish top quality stuff, we don't want any garbage. Please tell us if this story is worth publishing in our high quality series, and what we should reply to the author."
This way it is really sharp and identifying what is lacking. It's like an editor review. Then you go back to work for 2/3 days. And check back to see if your work improved. But the important part here is that many bad things he says you know are true. You needed somebody to tell you, to put more efforts into it.
With programming, while I have some knowledge of math, sometimes for the kind of programming I want to do I need to explore stuff I didn't study or know. And also in this regard Claude has been totally incredible. And so forth.
I also use it to find potetial issues in my desing ideas. Of course if it says something that I don't recognized as a true issue, I just don't care.
I got similar experiences with Claude, it's so convenient to use it to get an idea for a concept and being able to go back-and-forth with it about some kind of a feature that needs to be built.
> I can't emphasize this enough but coding has almost always been an isolating state for me. But now, you can feel some support with some intelligence!
This part from the original commenter resonates so well with me. Working basically as a solo dev, it's fantastic to have something that provides feedback and can challenge the ideas I have, so that the final result is good.
> I can't emphasize this enough but coding has almost always been an isolating state for me. But now, you can feel some support with some intelligence!
This part from the original commenter resonates so well with me. Working basically as a solo dev, it's fantastic to have something that provides feedback and can challenge the ideas I have, so that the final result is good.
All the conversations about SSPL seem to go the same way:
- Someone complains about the extra restrictions imposed on AWS (lets be real, it's basically just about AWS)
- People point out that SSPL is basically AGPL+, and that for the vast vast majority of people it doesn't make any difference
- People counter that the SSPL is written ambiguously/untested in court, and so while it might seem like it's AGPL+ and doesn't matter for most users, you can't rely on that
- People complain about rug pulling (valid, IMO)
My question is this: Can there be a AGPL+ that is OSI approved? Could there be a "AAGPL" that GNU releases that covers this (very common, and IMO valid) "need" for open source companies to not be cannibalized by cloud providers?
Is this conceptually unacceptable, or is it just that the SSPL is poorly executed?
- Someone complains about the extra restrictions imposed on AWS (lets be real, it's basically just about AWS)
- People point out that SSPL is basically AGPL+, and that for the vast vast majority of people it doesn't make any difference
- People counter that the SSPL is written ambiguously/untested in court, and so while it might seem like it's AGPL+ and doesn't matter for most users, you can't rely on that
- People complain about rug pulling (valid, IMO)
My question is this: Can there be a AGPL+ that is OSI approved? Could there be a "AAGPL" that GNU releases that covers this (very common, and IMO valid) "need" for open source companies to not be cannibalized by cloud providers?
Is this conceptually unacceptable, or is it just that the SSPL is poorly executed?
> Is this conceptually unacceptable, or is it just that the SSPL is poorly executed?
In my opinion it's the latter. There's a minor change you could make to the SSPL that would take it from "practically impossible to comply with" to something that just about anyone building a service with FOSS dependencies could comply with: https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
Essentially, add EUPL-like license compatibility clauses for dependencies to the SSPL.
I'm not saying this is exactly what we should do to accomplish that goal, but I think it's worth considering, and probably has a reasonable shot at being considered a free software license.
In my opinion it's the latter. There's a minor change you could make to the SSPL that would take it from "practically impossible to comply with" to something that just about anyone building a service with FOSS dependencies could comply with: https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
Essentially, add EUPL-like license compatibility clauses for dependencies to the SSPL.
I'm not saying this is exactly what we should do to accomplish that goal, but I think it's worth considering, and probably has a reasonable shot at being considered a free software license.
Problem comes down to, what is cloud provider?
My company has a piece of software we will sell you that requires Redis/PostGres. For fee, we also offer hosting of said software. Are we now a service provider? Our software does come with ability to manipulate the data in Redis so do we have open source our entire code base? Would we get stuck in lawyer battle royale?
We have resellers coming on board so interface is being built that lets them deploy our software for their customers so Redis will be deployed by us and given to reseller? Are we cloud provider then?
Now, I think reality is Redis wouldn't see as cloud provider because we don't go "Here is Redis, do whatever you want." Lawyers however get paid to think of worst thing that could happen and our lawyers said "Eh...... I'd hate to have these terms hanging over your head."
That's why alot of people recoil at SSPL.
Luckily, Valkey is drop-in replacement for us, testing is almost completed and likely we will switch when paperwork is all completed.
My company has a piece of software we will sell you that requires Redis/PostGres. For fee, we also offer hosting of said software. Are we now a service provider? Our software does come with ability to manipulate the data in Redis so do we have open source our entire code base? Would we get stuck in lawyer battle royale?
We have resellers coming on board so interface is being built that lets them deploy our software for their customers so Redis will be deployed by us and given to reseller? Are we cloud provider then?
Now, I think reality is Redis wouldn't see as cloud provider because we don't go "Here is Redis, do whatever you want." Lawyers however get paid to think of worst thing that could happen and our lawyers said "Eh...... I'd hate to have these terms hanging over your head."
That's why alot of people recoil at SSPL.
Luckily, Valkey is drop-in replacement for us, testing is almost completed and likely we will switch when paperwork is all completed.
I agree with your analysis and I sympathize with Redis in some way.
It seems to me that it's painfully obvious what a cloud provider is, but that everyone is afraid of what a lawyer could convince a judge in the Eastern District of Texas to think a cloud provider is.
The technical definition should be something akin to offering raw R/W connectivity to redis databases for arbitrary purposes.
Offering a redis-backed SaaS should not be covered.
It seems to me that it's painfully obvious what a cloud provider is, but that everyone is afraid of what a lawyer could convince a judge in the Eastern District of Texas to think a cloud provider is.
The technical definition should be something akin to offering raw R/W connectivity to redis databases for arbitrary purposes.
Offering a redis-backed SaaS should not be covered.
Tbh it seems far past time for the OSI to come out with a blessed license with well defined terminology so we can stop watching every large OS project invent their own way of combating AWS/etc
Why would the Open Source Initiative bless a non-open source license?
They already have AGPL, these are just a slight step further.
actually the sspl can’t be a fork of the agpl. Because osi and thus the agpl do not discriminate users and this includes cloud providers. A license like the sspl discriminates a certain user base.
> not be cannibalized by cloud providers
That would be discrimination against certain groups/persons, so not acceptable under the OSD.
https://opensource.org/osd
That would be discrimination against certain groups/persons, so not acceptable under the OSD.
https://opensource.org/osd
People keep talking about how the licence change was to prevent the likes of AWS from "taking and giving nothing back"... and completely ignore that AWS was paying an engineer to contribute to Redis in a significant way.
Well, I see this as great news. I've been tinkering with vector search myself and really don't like the APIs, query structures, even the embedding steps required. Anything that makes it simpler (and faster) is most welcome.
I do hope Salvatore keeps doing emulators for MCUs, though :)
I do hope Salvatore keeps doing emulators for MCUs, though :)
Thank you Rui, my target is: API that can be learned and used under 120 seconds. I don't think more of this is needed, for the basic usage. Then there could be other stuff, but it must be incremental. Easy things must be easy.
Well, the VSIM example I got inside of 10 seconds, so at least for now you're on track :)
TLDR API:
VADD key [VALUES <float float ...> | FP32 <binary blob>] element
VSIM key [VALUES ... | FP32 ... | ELE ...] [COUNT <count>] [EPSION <max distance>]
VCARD key (number of elements)
VDIM key (dimension of the vectors)
VDEL key <ele>
And so forth. However there are nice things you can enable, if you want. For instance VADD has the [REDUCE] option that implements random projection in order to reduce the dimensionality of your embeddings. Less memory, and it is faster. And so forth.
Will work on it during xmas, it's quite fun.
It implements on-insertion normalization and int8 quantization. The algorithm to insert nodes inside the HNSW attempts to never leave isolated nodes and to get good quality links and so forth. More hacking needed.
VADD key [VALUES <float float ...> | FP32 <binary blob>] element
VSIM key [VALUES ... | FP32 ... | ELE ...] [COUNT <count>] [EPSION <max distance>]
VCARD key (number of elements)
VDIM key (dimension of the vectors)
VDEL key <ele>
And so forth. However there are nice things you can enable, if you want. For instance VADD has the [REDUCE] option that implements random projection in order to reduce the dimensionality of your embeddings. Less memory, and it is faster. And so forth.
Will work on it during xmas, it's quite fun.
It implements on-insertion normalization and int8 quantization. The algorithm to insert nodes inside the HNSW attempts to never leave isolated nodes and to get good quality links and so forth. More hacking needed.
yes loving this! please PLEASE be the hero we need in unfucking the unholy mess of misdirection and useless abstraction that is storing some vectors somewhere for similarity search right now
U mean there are too much leaky abstractions in the field now ?
Huh Charles actually can code? We’ll then.
chroma's api i think takes something like 20 seconds
I've never had a use for Redis, but I was very happy to read this, and sincerely wish him the very best of luck. He seems to have his priorities straight.
I am 62, and write more software, now, than I ever did. This time, though, it's for free. I make it a point to treat my projects as "top-shelf" professional-grade shipping software, as opposed to the "hobby-grade" that I see from many folks I know that write non-commercial software.
That's just me, and the way I do things. WFM. YMMV.
Anyway, hats off to him, and the best of luck!
I am 62, and write more software, now, than I ever did. This time, though, it's for free. I make it a point to treat my projects as "top-shelf" professional-grade shipping software, as opposed to the "hobby-grade" that I see from many folks I know that write non-commercial software.
That's just me, and the way I do things. WFM. YMMV.
Anyway, hats off to him, and the best of luck!
> I make it a point to treat my projects as "top-shelf" professional-grade shipping software, as opposed to the "hobby-grade" that I see from many folks I know that write non-commercial software.
What are the practical differences in the end result?
My mind leapt to documentation, but I bet you meant more than that.
What are the practical differences in the end result?
My mind leapt to documentation, but I bet you meant more than that.
That's part of it, but then, there's architectural integrity, code quality, testing, testing, and more testing, then there's testing, and some more testing, then, there's taking care of all the "boring" release stuff, like testing. Then, of course, you can't have a release without testing.
Getting an idea of what I mean? Finding a pattern in there?
I generally don't have a ticket system, beyond the GitHub Issues, and I have yet to go over one digit.
That's not because I write perfect code. In fact, I'm constantly finding problems. It's just that I never stop looking, and fix issues -comprehensively- when I find them. Usually, the finding and fixing is so fast, that it isn't even worth it to log the issue. The changelog has what I need, as does the checkin history.
Just because I release something, doesn't mean that I stop testing, documenting, or maintaining it.
In January, we released an app (which I won't link, here). It is currently up to version 1.7.0 (I've been busy), and I'm working on a 1.8.0 version. This will be a basically "behind the scenes" release that won't result in any real user interface changes, but will set the stage for adding a fairly considerable upgrade, down the road (maybe a 2.0 version, but we'll see).
I write code that can have a fairly significant impact on the lives of the folks that use it. It's a Responsibility. I take that fairly seriously.
Getting an idea of what I mean? Finding a pattern in there?
I generally don't have a ticket system, beyond the GitHub Issues, and I have yet to go over one digit.
That's not because I write perfect code. In fact, I'm constantly finding problems. It's just that I never stop looking, and fix issues -comprehensively- when I find them. Usually, the finding and fixing is so fast, that it isn't even worth it to log the issue. The changelog has what I need, as does the checkin history.
Just because I release something, doesn't mean that I stop testing, documenting, or maintaining it.
In January, we released an app (which I won't link, here). It is currently up to version 1.7.0 (I've been busy), and I'm working on a 1.8.0 version. This will be a basically "behind the scenes" release that won't result in any real user interface changes, but will set the stage for adding a fairly considerable upgrade, down the road (maybe a 2.0 version, but we'll see).
I write code that can have a fairly significant impact on the lives of the folks that use it. It's a Responsibility. I take that fairly seriously.
Thanks for a great reply.
I’m amazed Antirez didn’t fork Redis and start fresh like Monty did MySQL. AWS, Azure and GC would be thrilled to support his work on an OSS fork. After 9 years surely any contractual constraints have expired? Maybe a sense of moral obligation? Or perhaps Redis Inc recruited him to prevent exactly this?
Either way we all very much appreciate the work you have done. Redis has been a game changer for many of us running small businesses on tiny budgets.
Either way we all very much appreciate the work you have done. Redis has been a game changer for many of us running small businesses on tiny budgets.
He has stock options in redis labs, so existing financial ties - although he mentions in his blog his comp for coming isn't wild, I wonder what the option package looks like
> He has stock options in redis labs, so existing financial ties
I was thinking "just divest," but they're not public yet, so you're right that it's a possibility.
I was thinking "just divest," but they're not public yet, so you're right that it's a possibility.
I think people are not afraid of the current change on licensing, but the magic is broken as soon as a company starts wandering around. Yes the current license is not that bad, but while we have valkey on the side now, how can I trust "Redis Inc." will not decide another small change which does not affect me, then the next one, until it makes something which does affect me.
> how can I trust "Redis Inc." will not decide another small change which does not affect me
Good point: the key is that, starting from now, Redis Inc. should make small changes that positively affect you.
Good point: the key is that, starting from now, Redis Inc. should make small changes that positively affect you.
Is this snarky or real? If real, how would this work? If snarky, then :(
Absolutely real: focus on the community, merge things that were now in payed versions of Redis into the core, so that everybody can benefit, contribute positively to the clients space, improve the documentation, and so forth.
[deleted]
Well written and thoughtful piece - I don't have problems with the license - they control the project, they can do what they want, I can use it or not as I want.
The thing that's interesting to me is the idea that these things have to continue to "evolve." Like we need to keep adding features to keep people engaged to have an active community, yada yada.
In my mind, and maybe I'm wrong, some of these projects are just sorta finished - they've evolved to a completed state more or less and just need maintenance. Memcached has sorta went this route afaict - it's still tremendously useful for some things and it's not constantly trying to add data types to compete with other things.
The thing that's interesting to me is the idea that these things have to continue to "evolve." Like we need to keep adding features to keep people engaged to have an active community, yada yada.
In my mind, and maybe I'm wrong, some of these projects are just sorta finished - they've evolved to a completed state more or less and just need maintenance. Memcached has sorta went this route afaict - it's still tremendously useful for some things and it's not constantly trying to add data types to compete with other things.
I think there are two important factors here that the author overlooked:
- the vast, vast majority of end users will get their software from a package manager, and for something as relatively feature stable (for what the vast majority of people use it for) as redis/clones, there's a good chance it's coming from a distro repo. Practically no one is installing it by building from source. The licence change means it won't be (at least new versions) in those distro repos any more, but the direct fork and spiritual successor (valkey) likely will be, and in some cases valkey will likely take over the redis name in those repos.
- this isn't the first time Redis the company has pulled this kind of trick, and I think it's foolish to believe the community is going to hang around and wait for the next time they say "I am altering the deal, pray I don't alter it any further"
- the vast, vast majority of end users will get their software from a package manager, and for something as relatively feature stable (for what the vast majority of people use it for) as redis/clones, there's a good chance it's coming from a distro repo. Practically no one is installing it by building from source. The licence change means it won't be (at least new versions) in those distro repos any more, but the direct fork and spiritual successor (valkey) likely will be, and in some cases valkey will likely take over the redis name in those repos.
- this isn't the first time Redis the company has pulled this kind of trick, and I think it's foolish to believe the community is going to hang around and wait for the next time they say "I am altering the deal, pray I don't alter it any further"
Just wanted to acknowledge the humanity of antirez. To many of us, they're a folk hero, but they're just a normal human being with a family who wants good things for the world and their family.
Thanks for opening up to us so much and for what you've contributed to the world antirez! And welcome back!
Thanks for opening up to us so much and for what you've contributed to the world antirez! And welcome back!
Antirez, I am just wondering about something...
Given that you probably already have retirement-sized exit from Redis. Isn't it more liberating to start something completely new? Or maybe forked Redis as the foundation of something new? Is there a need to re-join the old company?
Given that you probably already have retirement-sized exit from Redis. Isn't it more liberating to start something completely new? Or maybe forked Redis as the foundation of something new? Is there a need to re-join the old company?
That's a good question. The problem is that: I would end doing something in the vector search space probably, or other stuff that are tangent to AI. I can do the same but in public, as examples of hacking with this stuff, to share with the community. In the process I can add a solid vector indexing capability to Redis. It looks like a nice way to continue hacking.
From the blog post, looks like he contemplated that (I'm sure that while playing around with code, he would've thought of that) but ended up going in another direction. You can disagree, but you've got to respect his decision to try and do what is best for him, and what he believes is best for Redis.
I suspect he is going to make a lot of money coming back to save Redis from the negative press they have been having recently as well as the threat of Valkey. I sort of have to view it in light of all the other events that have been happening to Redis.
I covered this in the blog post: no big money involved, I asked to rejoin and without a big paycheck on purpose because to be free to act you should not get too much money, otherwise it's all fake.
But if you wanted to have influence without a big pay check, why not join Valkey? Redis, the company, in your absence has gotten a reputation as a predatory company that has attacked open source projects in other to further those goals.
https://arstechnica.com/information-technology/2024/04/redis...
https://news.ycombinator.com/item?id=39858144
https://news.ycombinator.com/item?id=42239607
https://arstechnica.com/information-technology/2024/04/redis...
https://news.ycombinator.com/item?id=39858144
https://news.ycombinator.com/item?id=42239607
I want to help Redis to find a good path forward (while I respect the work of everybody). I was sponsored by this company for ages, I know the core hackers there, and they are strong and are good people. I talked with the CEO and he is very interested in finding novel ways to play, so I rejoined Redis and not ValKey.
Honestly even if Redis public image has not been stellar recently, I know the people that work at Redis, many engineers are there since the start, and I believe they have huge design abilities and can do what is needed to make Redis more useful for the community.
Honestly even if Redis public image has not been stellar recently, I know the people that work at Redis, many engineers are there since the start, and I believe they have huge design abilities and can do what is needed to make Redis more useful for the community.
At least you go into this seeing the reputation that Redis Labs has worked hard on earning recently.
Could you not have stayed separate from them while contributing again?
Could you not have stayed separate from them while contributing again?
What motivated me was the company idea that with the license change the attitude could change significantly towards providing as much value as possible back to Redis. So merging what is super useful and has been, so far, only available to paying customers, and so forth. Also the company is interested in changing attitude. All these things made me feel that my efforts were better spend doing some bridging work between the community and the company.
Don't hate the player, hate the game.
The player in this context has an outsized influence on the game, the people managing the game are using their work, and contributing more to it is effectively influencing the game in a big way.
I don't really hate or care about anyone in this game, but it's a non-trivial move in the game.
I don't really hate or care about anyone in this game, but it's a non-trivial move in the game.
> why not join Valkey?
Valkey is making it possible for hyperscalers to continue appropriating open source and charging fat margins to everyone else.
In a sense, Valkey is the bad guy here.
And just look at all the support Valkey is getting from Amazon, Google, Oracle, etc. They're perpetuating the problem.
The same thing happened with Elasticsearch. Unfortunately ICs without decision-making power started lambasting the Elasticsearch leadership for attempting to fend off AWS and their ilk from absorbing all of the revenues derived from their hard work.
Open source is just a commodity feature for hyperscalers. It's time we stop giving it to them for free.
This is all about power. We're ceding it to trillion dollar companies because we've been trained that "open source" is ethical. Meanwhile, we don't question the ethics of these companies profiting off of this work while charging us absurd margins. None of the hyperscaler infra is open source.
Valkey is making it possible for hyperscalers to continue appropriating open source and charging fat margins to everyone else.
In a sense, Valkey is the bad guy here.
And just look at all the support Valkey is getting from Amazon, Google, Oracle, etc. They're perpetuating the problem.
The same thing happened with Elasticsearch. Unfortunately ICs without decision-making power started lambasting the Elasticsearch leadership for attempting to fend off AWS and their ilk from absorbing all of the revenues derived from their hard work.
Open source is just a commodity feature for hyperscalers. It's time we stop giving it to them for free.
This is all about power. We're ceding it to trillion dollar companies because we've been trained that "open source" is ethical. Meanwhile, we don't question the ethics of these companies profiting off of this work while charging us absurd margins. None of the hyperscaler infra is open source.
Many of the Redis developers left to form Valkey, so that they could keep working on the Open Source project they wanted to work on. Valkey is continuing a project that was released under Open Source terms, after the original company rugpulled the Open Source project in favor of a proprietary one.
Or, in other words, Valkey is Jenkins here, and Redis is Hudson.
Or, in other words, Valkey is Jenkins here, and Redis is Hudson.
> Many of the Redis developers left to form Valkey
What's the point of spreading informations that are not true? I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer). So I'm not understanding who joined ValKey from Redis folks.
Everybody is working at Redis: me, Oran, Yossi, Meir, many others.
What's the point of spreading informations that are not true? I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer). So I'm not understanding who joined ValKey from Redis folks.
Everybody is working at Redis: me, Oran, Yossi, Meir, many others.
> I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer).
It is probably more correct to say a bunch of Redis contributors left the Redis GitHub project and moved over to Valkey.
You can see there are a bunch of contributors listed on this page who seem to predate the fork and who have continued to contribute:
https://github.com/valkey-io/valkey/graphs/contributors
Particularly these contributors standout:
https://github.com/enjoy-binbin
https://github.com/madolson
https://github.com/soloestoy
https://github.com/hwware
https://github.com/zuiderkwast
https://github.com/hpatro
https://github.com/pizhenwei
It is probably more correct to say a bunch of Redis contributors left the Redis GitHub project and moved over to Valkey.
You can see there are a bunch of contributors listed on this page who seem to predate the fork and who have continued to contribute:
https://github.com/valkey-io/valkey/graphs/contributors
Particularly these contributors standout:
https://github.com/enjoy-binbin
https://github.com/madolson
https://github.com/soloestoy
https://github.com/hwware
https://github.com/zuiderkwast
https://github.com/hpatro
https://github.com/pizhenwei
Nearly all of them work at cloud providers so they literally just followed their income stream.
> Nearly all of them work at cloud providers so they literally just followed their income stream.
Sure. And same for Redis employees who continue to work on the Redis Github project. All my significant contributions to open source have had financial incentives as well.
Sure. And same for Redis employees who continue to work on the Redis Github project. All my significant contributions to open source have had financial incentives as well.
I know this doesn't mean much, but I spent a lot of time outside of work helping to maintain the Redis codebase. I attended our meetings and responded to issues on vacation because I cared about the community, it was more than just a paycheck for me. I don't regret doing any of that.
Indeed. The project had continuity. The trademark exited the building.
> In a sense, Valkey is the bad guy here.
Are all the open source libraries that Redis depends on [1] also evil? Or are we just focused on declaring Redis competitors evil today?
[1] https://github.com/redis/redis/tree/unstable/deps
Are all the open source libraries that Redis depends on [1] also evil? Or are we just focused on declaring Redis competitors evil today?
[1] https://github.com/redis/redis/tree/unstable/deps
as much as I dislike the hyperscalers parasitising open source...
"redis ltd" the company did not originate redis
"redis ltd" was originally "Garantia Data": a company that offered hosted redis as a service
fundamentally they are/were doing the same thing as AWS/Google: taking an existing open source product they did not originate, and selling hosting for it
they may have hired its creator (several years after he wrote it), and since then changed their name to "redis", but they're not any different to GCP/AWS
other than the complaining about others more successful business models
this is very different to e.g. sentry
"redis ltd" the company did not originate redis
"redis ltd" was originally "Garantia Data": a company that offered hosted redis as a service
fundamentally they are/were doing the same thing as AWS/Google: taking an existing open source product they did not originate, and selling hosting for it
they may have hired its creator (several years after he wrote it), and since then changed their name to "redis", but they're not any different to GCP/AWS
other than the complaining about others more successful business models
this is very different to e.g. sentry
And Valkey with backing from AWS, GCP, and Oracle don't make any money at all ... wait aren't those trillion dollar monopolies?
The pot calling the kettle black
The pot calling the kettle black
Valkey also has the backing of The Linux Foundation. So maybe it just has a lot of backing in general.
https://www.linuxfoundation.org/press/linux-foundation-launc...
BTW are you an employee of Redis? You seem to have created this account just to reply to me.
https://www.linuxfoundation.org/press/linux-foundation-launc...
BTW are you an employee of Redis? You seem to have created this account just to reply to me.
The Linux Foundation is a mouthpiece of the closed source, trillion dollar hyperscalers.
They're using the deceptive good feels to stop you from questioning their fat margins.
Why isn't the entire stack of AWS infra open source, again?
Open source has been twisted against us. The big players know where the money and value and power accumulates.
They're using the deceptive good feels to stop you from questioning their fat margins.
Why isn't the entire stack of AWS infra open source, again?
Open source has been twisted against us. The big players know where the money and value and power accumulates.
> Why isn't the entire stack of AWS infra open source, again?
This line of argument is untethered from reality.
The Linux Foundation actually is the parent of the Cloud Native Computing Foundation (https://www.cncf.io/about/join/), which actually is infrastructure for cloud services: containers, envoy, etcd, helm, istio, Kubernetes, prometheus, etc.
This line of argument is untethered from reality.
The Linux Foundation actually is the parent of the Cloud Native Computing Foundation (https://www.cncf.io/about/join/), which actually is infrastructure for cloud services: containers, envoy, etcd, helm, istio, Kubernetes, prometheus, etc.
> This line of argument is untethered from reality.
You had a business that was acquired by Amazon. I don't know if you're giving this a fair assessment.
When the copyright holders of large open source infrastructure projects want revenue from their hard work, Amazon forks them or provides funding to their direct competitors.
Amazon can strategically launch free and open source competition to commercialized open source products as a means of keeping more of the cloud spend budget for themselves.
The hyperscalers want to commoditize anything that impinges upon their margins. The software should be free, it should run on their clouds, and it should lead to increased cloud spending. Other companies shouldn't dip their hands into the pot.
Moreover, hyperscalers get to hoover up "managed" versions of open source software and collect even thicker margins. Redis, Elasticsearch, etc. fly in the face of this strategy, which is why they attack it so relentlessly.
The Linux Foundation and CNCF serve its industry contributors. The microservice ecosystem is booming business for AWS, Azure, and GCP.
I don't see how this is "untethered from reality". This is cutthroat business, and it's how the trillion dollar companies throw their weight around.
If you build open source infrastructure products and don't have an anti-cloud provision, you'll get picked clean by the hyperscalers.
You had a business that was acquired by Amazon. I don't know if you're giving this a fair assessment.
When the copyright holders of large open source infrastructure projects want revenue from their hard work, Amazon forks them or provides funding to their direct competitors.
Amazon can strategically launch free and open source competition to commercialized open source products as a means of keeping more of the cloud spend budget for themselves.
The hyperscalers want to commoditize anything that impinges upon their margins. The software should be free, it should run on their clouds, and it should lead to increased cloud spending. Other companies shouldn't dip their hands into the pot.
Moreover, hyperscalers get to hoover up "managed" versions of open source software and collect even thicker margins. Redis, Elasticsearch, etc. fly in the face of this strategy, which is why they attack it so relentlessly.
The Linux Foundation and CNCF serve its industry contributors. The microservice ecosystem is booming business for AWS, Azure, and GCP.
I don't see how this is "untethered from reality". This is cutthroat business, and it's how the trillion dollar companies throw their weight around.
If you build open source infrastructure products and don't have an anti-cloud provision, you'll get picked clean by the hyperscalers.
And who funds the Linux Foundation? - it is the CSPs themselves - https://chatgpt.com/share/67587e4c-bde8-800b-9f0a-fc824d3d6f...
Any thoughts on CSPs making money from open source projects while the open source developers (e.g., Redis, Mongo, Hashi) suffer)?
Any thoughts on CSPs making money from open source projects while the open source developers (e.g., Redis, Mongo, Hashi) suffer)?
No one organization in the world funds the LF in a way that is more than 1% of the total LF revenue... it has nearly ~2000 members across the world. You can usually get some of this from the LF Annual Report: https://www.linuxfoundation.org/resources/publications/linux...
[deleted]
Good luck!
I like Redis, it was my first queue system and it worked great. I used it for this project https://edwarddeaver.me/portfolio/control-my-lights to pass messages from multiple inputs into a central funnel.
Looking forward to reading more of your posts.
I like Redis, it was my first queue system and it worked great. I used it for this project https://edwarddeaver.me/portfolio/control-my-lights to pass messages from multiple inputs into a central funnel.
Looking forward to reading more of your posts.
Welcome Back. Antirez! ( Surprised This blog post is submitted just 2 min after it was posted )
I am wondering if Valkey has moved so far off from Redis the codebase couldn't be merged again? I am reading the top contributor to ValKey are now from Tencent Cloud, Google, Amazon and Ericsson.
Could someone help with me with SSPL, is it essentially AGPL v3 except instead of releasing the source code only you have to release the whole system that is able to run the services you are currently operating on top of ?
Just wondering these things from the sideline. As I am still on the memcached camp.
I am wondering if Valkey has moved so far off from Redis the codebase couldn't be merged again? I am reading the top contributor to ValKey are now from Tencent Cloud, Google, Amazon and Ericsson.
Could someone help with me with SSPL, is it essentially AGPL v3 except instead of releasing the source code only you have to release the whole system that is able to run the services you are currently operating on top of ?
Just wondering these things from the sideline. As I am still on the memcached camp.
Hi ksec! Thanks. ValKey and Redis are not so different codebases so far, but I have the feeling they will diverge more and more. I hope that at least at protocol level they will stay compatible, to be able to use the same clients. I doubt the projects can be rejoined, because the backers have different goals. Amazon / Google / Alibaba / ... wants to keep using it without any revenue sharing, and Redis instead does not want Redis to be sold SAAS style since the cloud three-poly makes it very hard to penetrate the market without any agreement. I'm not a business person but this is how I see the current matter.
[deleted]
You have to release the whole system under the SSPL. So there could be a reading where you can't use Linux, you can't use systemd, you can't use glibc, etc.
>So there could be a reading where you can't use Linux, you can't use systemd, you can't use glibc, etc.
Thank You. That makes a lot more sense why certain people dont like SSPL.
Thank You. That makes a lot more sense why certain people dont like SSPL.
I am a big fan your work, including your lua c64 coding thing which actually was a great educational tool for my small cousins and for some friends. Also works well on the go. Just wanted to say that.
I appreciated a lot reading your comment. I feel silly sometimes when I use months of time to write something like LOAD81, I question my sanity, but then I see that other people had some good time with it and I'm so happy: and also I'm sure that I used my time in the best way.
It is a work of art for me as a c64 80s guy so I put it on too many people to learn coding. It is great!!! Thank you.
I for one partially wrote a few mobile games with LOAD81 ; I was travelling and only had my Pandora with me; I wrote all the logic tested them all out with load81. Of course I had to actually get them on a mobile platform device and create a better UI, however all the logic and most of the UX was all done in lua on load81.
Is Claude really that much better than ChatGPT? I Use ChatGPT Plus on a daily basis and have no complaints but is it worth cancelling it and get one for Claude?
If you find ChatGPT useful, pay just one month of Claude AI and use both. I bet you'll discover that Claude AI can help you a great deal more. If that will be the case, you gained a much better AI assistant. Otherwise it's just 20 bucks... For me the difference is huge.
I have used Claude(Free) for coding and architecture-related questions and found it pretty solid but I found chatGPT a generalist LLM that is good at many things. Is Claude the same? Or you found Claude better for coding related tasks?
or maybe through perplexity he can try both (and more)
I think both are really capable. However anecdotally, I notice myself doing way less of the "annoyed, cancel response, extend prompt instructions, regenerate" cycles with Claude as compared to chatgpt.
Also, I am not sure if it has my writing style preferences saved somewhere, but Claude uses the terse style I prefer to read explanations in, without me needing to mention it. ChatGPT can do it too but it needs to be prompted lest it do the whole "repeat question, bullet points, summary" ceremony. ChatGPT gets really annoying when you have do the "slightly more detailed, slightly more terse, there we go" ceremony as well. For similar reasons, I prefer it for code.
One place where ChatGPT absolutely takes the cake though is mathematical proofs heavy with symbols. Nothing else comes close in my experience. It's also better at latex typesetting (seems to be more fluent with common packages like amsmath).
Also, I am not sure if it has my writing style preferences saved somewhere, but Claude uses the terse style I prefer to read explanations in, without me needing to mention it. ChatGPT can do it too but it needs to be prompted lest it do the whole "repeat question, bullet points, summary" ceremony. ChatGPT gets really annoying when you have do the "slightly more detailed, slightly more terse, there we go" ceremony as well. For similar reasons, I prefer it for code.
One place where ChatGPT absolutely takes the cake though is mathematical proofs heavy with symbols. Nothing else comes close in my experience. It's also better at latex typesetting (seems to be more fluent with common packages like amsmath).
I was in the same boat. I gave Claude a try, just to see what I was missing, and I ended up never returning to ChatGPT except to generate pictures (which Claude can't do). Give it a try for a month. It's worth a shot. They have improvements beyond just generally being smarter. For instance, Claude can _edit_ a prior code block rather than just emitting a new one. It can build React components and show them to you, rather than just giving you the code.
We use both, in my anecdotal experience it depends on what you use them for. The engineering teams which build solar plants use them as “an extra set of eyes” for increased quality control, and they chose ChatGPT. It discovered something to do with cable sizes and efficiency which ended up saving/making a lot of money. I’m sorry I can’t be more precise than that, but I know they had a much better result rate with ChatGPT. For my team which is software development, we favour Claude. It’s obviously rather anecdotal but it has been much better at Go than ChatGPT. For other languages like Python I don’t think there is any real difference. If you feed them both the same prompt they’ll often give you an extremely similar output, and neither will consistently be better than the other.
So I think it’s mainly to work with the one which works for you. I’ve seen some of our more junior developers first use Claude and then ChatGPT to refine their output, or the reverse.
So I think it’s mainly to work with the one which works for you. I’ve seen some of our more junior developers first use Claude and then ChatGPT to refine their output, or the reverse.
For writing code, I've found Claude far better at conventional/framework based code. I've found ChatGPT better at reasoning about more complex/nuanced code.
As other commenters have said, that is just my personal opinion, I have zero evidence to back that up lol
As other commenters have said, that is just my personal opinion, I have zero evidence to back that up lol
I have been an open source contributor since age 24. I am now 53.
I have seen tremendous contributors get nothing in return except the satisfaction of having helped build something of value (which is huge, mind you).
I have seen opportunists fork, relabel projects as cloud services and tremendously profit in the process.
Since I am mo longer young, or naive, and since I have thought about it for quite some time, I must say it would be good to tie a token offering and a royalty scheme to open source projects. I feel contributors should profit in some measure when big corporations profit from their labor.
I have seen tremendous contributors get nothing in return except the satisfaction of having helped build something of value (which is huge, mind you).
I have seen opportunists fork, relabel projects as cloud services and tremendously profit in the process.
Since I am mo longer young, or naive, and since I have thought about it for quite some time, I must say it would be good to tie a token offering and a royalty scheme to open source projects. I feel contributors should profit in some measure when big corporations profit from their labor.
Thank you antirez for all your OSS and social contributions. I love reading both your code and your prose. Welcome back and I look forward to the next chapters.
Something stated periodically, and certainly in these comments, is how the license upset Redis OSS contributors. I understand there are many perspectives on the story, but this is generalized projection to support a viewpoint.
Speaking just for myself as an Redis OSS contributor -- a very very minor one but I've spent hundreds of hours dedicated to Redis dev over the decade -- I wasn't bothered by it with respect to my donated time or IP. Beyond that, my opinion is that license holders have the right to do as the licenses permit, including changing it.
Without a survey, we don't know about the rest of the contributors and do we somehow weight their approval by the extent of their contribution? In the end, these opinions don't matter directly and what matters is the actions individuals and organizations take, which KV store they chose to support with time or money.
Clearly some contributors and their backers didn't like the change and forked Valkey. I have since started collaborating with Valkey. But as antirez pointed out how it would go, it's because of technical grounds, not because of license angst. Valkey was open to rejiggering its Lua integration, something Redis wasn't open to previously; so I took the opportunity to advance that with Valkey.
As Redis becomes useful to me again, e.g. with this Vector API, I would collaborate there too. We can have different tools for different purposes. Either way, it will be interesting to see how these two codebases advance...
Something stated periodically, and certainly in these comments, is how the license upset Redis OSS contributors. I understand there are many perspectives on the story, but this is generalized projection to support a viewpoint.
Speaking just for myself as an Redis OSS contributor -- a very very minor one but I've spent hundreds of hours dedicated to Redis dev over the decade -- I wasn't bothered by it with respect to my donated time or IP. Beyond that, my opinion is that license holders have the right to do as the licenses permit, including changing it.
Without a survey, we don't know about the rest of the contributors and do we somehow weight their approval by the extent of their contribution? In the end, these opinions don't matter directly and what matters is the actions individuals and organizations take, which KV store they chose to support with time or money.
Clearly some contributors and their backers didn't like the change and forked Valkey. I have since started collaborating with Valkey. But as antirez pointed out how it would go, it's because of technical grounds, not because of license angst. Valkey was open to rejiggering its Lua integration, something Redis wasn't open to previously; so I took the opportunity to advance that with Valkey.
As Redis becomes useful to me again, e.g. with this Vector API, I would collaborate there too. We can have different tools for different purposes. Either way, it will be interesting to see how these two codebases advance...
When someone puts a significant and useful software under an open license (like BSD) and nurtures a vibrant open-source community around it, sure, everyone else can definitely take it and use it for free. But nobody serious will use it just because it is free. They will consider other intangible but critical aspects like risks to themselves w.r.t future viability of the project, ability to get custom work done to it or around it, keeping up with hardware and software ecosystem trends etc. These things have second order implications – how healthy the broader developer ecosystem is, is there a broad base of core committers we can hire, how easy it is to upstream our changes, who else is using it at similar scale, criticality, cost efficiency; is commercial support available (sometimes 3rd party commercial business support ecosystem is essential due to regulatory/compliance reasons), do hardware vendors actively participate in the open-source community and ensure it runs well on their hardware etc.
Apart from free users, even the contributors have very similar considerations for their participation.
But the starting point is the license – it has to be a clear and unambiguous open-source license that is widely well-understood – especially w.r.t the blast-radius or infection radius of the license. Does it infect the library code that is linked/loaded into it? Does it infect the independent binary/processes that scaffold around it (say, control-plane, orchestrator, proxy etc)? What are the obligations if it does? If we have to get lawyers involved to answer these questions because it is a custom license that is vaguely written or it has never been challenged in a court or the license holder is of unknown reputation, these are huge red flags.
Another equally important consideration is the motivations of the stewards of the project. While this isn't explicitly stated, one cannot be naive about it. Contributors and users will have to consider a gamut of scenarios – best/base/worst scenarios and make their judgement. With smaller steward organizations, there are one kind of risks while with larger organizations open-sourcing there are other kinds of risks. If they are competitors in some way that's another challenge. If there is no natural alignment of use-cases functionally or non-functionally, that's another issue etc.
With recent changes in Redis, all these things have become less clear and straightforward.
Apart from free users, even the contributors have very similar considerations for their participation.
But the starting point is the license – it has to be a clear and unambiguous open-source license that is widely well-understood – especially w.r.t the blast-radius or infection radius of the license. Does it infect the library code that is linked/loaded into it? Does it infect the independent binary/processes that scaffold around it (say, control-plane, orchestrator, proxy etc)? What are the obligations if it does? If we have to get lawyers involved to answer these questions because it is a custom license that is vaguely written or it has never been challenged in a court or the license holder is of unknown reputation, these are huge red flags.
Another equally important consideration is the motivations of the stewards of the project. While this isn't explicitly stated, one cannot be naive about it. Contributors and users will have to consider a gamut of scenarios – best/base/worst scenarios and make their judgement. With smaller steward organizations, there are one kind of risks while with larger organizations open-sourcing there are other kinds of risks. If they are competitors in some way that's another challenge. If there is no natural alignment of use-cases functionally or non-functionally, that's another issue etc.
With recent changes in Redis, all these things have become less clear and straightforward.
Thanks for sharing a bit of your internal thought process on career and life decisions. It’s very interesting for me to see how people at different stages of their career think of these things.
I think this licensing fracture that’s happening across the industry is unfortunate, there’s a been a lot of broken trust. The SSPL is on the face of it more reasonable than the BSL. It clearly states that it only becomes viral when “offering a service the value of which entirely or primarily derives from the value of the Program”. So it seems it should be pretty safe to use Redis as a cache or session store within a larger system. Contrast with hashicorp, which forbids use in any product they consider a competitor. But I also empathize with people who are scared of using any license that’s untested in court.
Tangential: I love Inconsolata as a terminal font (and I appreciate the “hacker” aesthetic of a monospaced blog) but perhaps consider using a body font for your longer articles. Although I’m sure most of your readers know how to change the font if they want to, one of the great things about plain HTML :)
I think this licensing fracture that’s happening across the industry is unfortunate, there’s a been a lot of broken trust. The SSPL is on the face of it more reasonable than the BSL. It clearly states that it only becomes viral when “offering a service the value of which entirely or primarily derives from the value of the Program”. So it seems it should be pretty safe to use Redis as a cache or session store within a larger system. Contrast with hashicorp, which forbids use in any product they consider a competitor. But I also empathize with people who are scared of using any license that’s untested in court.
Tangential: I love Inconsolata as a terminal font (and I appreciate the “hacker” aesthetic of a monospaced blog) but perhaps consider using a body font for your longer articles. Although I’m sure most of your readers know how to change the font if they want to, one of the great things about plain HTML :)
I'm somewhat surprised no one has mentioned Commons Clause.
https://commonsclause.com
https://commonsclause.com
Perhaps because it's old news and a failed model which companies have now started rolling back (see ElasticSearch)?
https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
Seems like that explicitly allows SaaS kind of offerings so it wouldn’t si what Redis wants as I understand.
That is great news.
Redis remains my favorite database. I've had the opportunity to work extensively with it, not only professionally but also through open-source projects like redis-dict[0], a Python dictionary with Redis as the backend.
How can we follow your progress on the vector set feature?
[0] https://github.com/Attumm/redis-dict
Redis remains my favorite database. I've had the opportunity to work extensively with it, not only professionally but also through open-source projects like redis-dict[0], a Python dictionary with Redis as the backend.
How can we follow your progress on the vector set feature?
[0] https://github.com/Attumm/redis-dict
[deleted]
I don't have any involvement in OSS besides using it at my job, but I still enjoyed the post because of the notes on AI. I have noticed a similar disconnect in technical discussions between those who see the use of AI as a multiplier and those who don't yet see the value in it.
The company I work for has embraced Copilot heavily and its been an absolute game changer in terms of productivity. When you have a clear problem, it is quite amazing at producing working code that then can be modified. I've really enjoyed the edit in place feature as well. Yeah, I could go through and do all the work manually, but why waste the time? AI is a big time saver.
The company I work for has embraced Copilot heavily and its been an absolute game changer in terms of productivity. When you have a clear problem, it is quite amazing at producing working code that then can be modified. I've really enjoyed the edit in place feature as well. Yeah, I could go through and do all the work manually, but why waste the time? AI is a big time saver.
This type of genuine openness mixed with the excitement of passion is so joyful to read, especially from a high achiever with strong technical capabilities and a history of business success.
Salvatore is definitely high on my list of role models.
Salvatore is definitely high on my list of role models.
> However, during the “writing years” (I’m still writing, by the way), I often returned to coding, as a way to take breaks from intense writing sessions (writing is the only mental activity I found to be a great deal more taxing than coding)
I wrote and published my first book in a weekend frenzy and it’s one of my favorite accomplishments.
I’ve published half a dozen small books since then, the most popular of which is about how to write and publish your own book.
Over the past couple months I’ve been preparing a system to help others publish their own book. If you have any interest in writing and publishing, please reach out. I’d love to help.
I wrote and published my first book in a weekend frenzy and it’s one of my favorite accomplishments.
I’ve published half a dozen small books since then, the most popular of which is about how to write and publish your own book.
Over the past couple months I’ve been preparing a system to help others publish their own book. If you have any interest in writing and publishing, please reach out. I’d love to help.
Why say Claude is ahead of the rest? (I don't keep up to date, only using mainstream tools in ides)
Right now I use Amazon Q to buy integrate into phpstorm and its ok. It's free so a major advantage.
Is it just terms of using their chat models?
Right now I use Amazon Q to buy integrate into phpstorm and its ok. It's free so a major advantage.
Is it just terms of using their chat models?
Think of it as "taste".
People have different tastes, artists and chefs have different tastes.
Claude and ChatGPT are crafted by different people hence you'll only see these nuances once you experience it first-hand, and you might not even be able to articulate it very well, you'll just find yourself gravitated towards one thing over another.
I suggest you try both.
People have different tastes, artists and chefs have different tastes.
Claude and ChatGPT are crafted by different people hence you'll only see these nuances once you experience it first-hand, and you might not even be able to articulate it very well, you'll just find yourself gravitated towards one thing over another.
I suggest you try both.
I think it just depends on what you're working on. In my experience, Claude usually has the edge over ChatGPT for most coding or logic problems; however, there are situations where Claude goes too deep the wrong way and ChatGPT wins out by staying more high level. Claude and ChatGPT are also "free" too, btw.
The author is of course mainly talking about the fact that the current Claude models are one of the best for programming. Only o1 can rival 3.5 Sonnet, but o1 is way more expensive and takes more time to run.
With all due respect, would it be more transparent for antirez to disclose whether he holds equity in Redis Labs and, if so, how much? While I understand he signed documents transferring ownership to Redis Labs, it seems ethical, especially in light of recent controversies, to clarify his position. Transparency on whether he benefits from Redis Labs’ decisions, or even a statement acknowledging that he cannot or will not discuss this would help address potential conflicts of interest and maintain trust within the open-source community.
It is literally written inside the post.
> more extensively thanks to Redis Labs later: a freaking Robin Hood of open source software, where I was well compensated by a company and no, not to do the interests of the company itself, but only to make the best interests of the Redis community.
Governments should do this and tax companies to pay for it.
Re: vector embeddings, two projects I've had recent exposure to--Memgraph and FalkorDB (previously RedisGraph)--are implementing similar functionality. I think the lego approach is really awesome, I wish this concept was more broadly adopted. All that is to say, this seems exciting!
Governments should do this and tax companies to pay for it.
Re: vector embeddings, two projects I've had recent exposure to--Memgraph and FalkorDB (previously RedisGraph)--are implementing similar functionality. I think the lego approach is really awesome, I wish this concept was more broadly adopted. All that is to say, this seems exciting!
I really appreciated the section about OSI licenses as someone who this year stopped using them entirely for new work.
(Snippets from the article below)
> I wrote open source software for almost my whole life. Yet, as I’m an atheist and still I’m happy when I see other people believing in God, if this helps them to survive life’s hardships, I also don’t believe that open source is the only way to write software.
> Moreover, I don’t believe that openness and licensing are only what the OSI tells us they are. I see licensing as a spectrum of things you can and can’t do.
(Snippets from the article below)
> I wrote open source software for almost my whole life. Yet, as I’m an atheist and still I’m happy when I see other people believing in God, if this helps them to survive life’s hardships, I also don’t believe that open source is the only way to write software.
> Moreover, I don’t believe that openness and licensing are only what the OSI tells us they are. I see licensing as a spectrum of things you can and can’t do.
See, I read that and immediately was reminded that I don't exactly love the OSI being the one true definer of Open Source... but somehow the only people who ever argue that immediately try to use it as an excuse to pretend their stuff is open for marketing reasons while avoiding actually giving users the same rights. Besides, it's not that "openness and licensing are only what the OSI tells us they are"; it's that the OSI and FSF and DFSG all agree.
I've been a redis / elasticsearch user since the early days. Seeing these companies grow has been sources of inspiration for me.
I'm glad you're back and look forward to redis's future. There is still a lot of work to be done.
In terms of licensing there is no right answer, large companies evidently abuse opensource, at the same time community is required to make projects like redis / elasticsearch grow.
This is a good move and I think the future is long with redis. So much to explore and so much more that can be done.
I'm glad you're back and look forward to redis's future. There is still a lot of work to be done.
In terms of licensing there is no right answer, large companies evidently abuse opensource, at the same time community is required to make projects like redis / elasticsearch grow.
This is a good move and I think the future is long with redis. So much to explore and so much more that can be done.
Welcome back!
And good timing... our brute force cosine similarity scan on Redis-stored vectors needs some help at the core level (ANN, nearest neighbor, k-mean clustering, anything would be an improvement!)
And good timing... our brute force cosine similarity scan on Redis-stored vectors needs some help at the core level (ANN, nearest neighbor, k-mean clustering, anything would be an improvement!)
Will be interesting to see how the Valkey community reacts to this
I don't think it changes the negative business actions that the company Redis has been doing. But it likely means that Redis may actually evolve now, rather than being a static target.
Valkey maintainer here. ¯\_(ツ)_/¯
I worked with antirez a bit before he left the project in 2020, and I still look fondly back on that time since he was a wonderful person and he helped me learn a lot. I wish he had considered coming to work with Valkey instead of Redis, but maybe we'll find some some way to work together that benefits both communities.
I worked with antirez a bit before he left the project in 2020, and I still look fondly back on that time since he was a wonderful person and he helped me learn a lot. I wish he had considered coming to work with Valkey instead of Redis, but maybe we'll find some some way to work together that benefits both communities.
I think antirez has made very rational economic decision. For Open Source Redis/Valkey community though it would be better if he had joined Valkey of course.
Note though it is not certain he even could - the Non Compete when you have significant compensation in cash or equity can be much stronger and run a lot longer than employment related
Note though it is not certain he even could - the Non Compete when you have significant compensation in cash or equity can be much stronger and run a lot longer than employment related
Appreciate your kind words, and I'm very happy it was a good experience to work together, it was cool for me too. I hope there will be ways to exchange infos and hack :)
Everything we do is open-source, so you're free to take it and incorporate it back into Redis. (Although I'm more into rewriting the data structures to more efficient on modern CPU hardware). Keep some comments out in the open like your discussion about vector sets to keep the conversation going. For the record, I really don't like the vector set idea, but I'm not one to dish out hot takes on hacker news.
Thank you, I'll encourage my colleagues to take everything we can from ValKey, because this is how it works: as the BSD allowed the fork, the BSD allows less liberal licenses to take back. The magic of very liberal licenses is that: they speed up human evolution (and we tried hard to retain the BSD for this reason).
About Vector Sets: it's absolutely ok to disagree here; but what is a good thing about having multiple forks of the original Redis is that you can see it as an optimization to search for the better Redis :D The Vector Set stuff, just to be clear, was not "company stimulated", it's something that I really want and I which I strongly believe.
About Vector Sets: it's absolutely ok to disagree here; but what is a good thing about having multiple forks of the original Redis is that you can see it as an optimization to search for the better Redis :D The Vector Set stuff, just to be clear, was not "company stimulated", it's something that I really want and I which I strongly believe.
Were these cloud companies, their product managers and execs were not ethical enough to contribute let's say just 2% of the revenue to the base open source projects and even directly label it as "Open Source Sustainability Surcharge (OSSS) in the invoices and UIs?
That would have been enough to stop forks and license switches. May be a little less wines, watches, women and yatches for the execs though.
That would have been enough to stop forks and license switches. May be a little less wines, watches, women and yatches for the execs though.
I think this is much less straight forward when the OSS is glued to a commercial company.
Giving money to a competitor is different than giving money to an open initiative.
Does Redis Labs give back to the Linux Foundation and OpenSSL?
Giving money to a competitor is different than giving money to an open initiative.
Does Redis Labs give back to the Linux Foundation and OpenSSL?
Good question. But I still believe a percentage based revenue share would have been a far greater deal than none at all.
Amazing read, thanks for sharing.
And thanks for building redis! It's an amazing piece of software, no idea how we managed to do without it.
And thanks for building redis! It's an amazing piece of software, no idea how we managed to do without it.
Very exciting!
I sympathise with the Redis "lego" way. But don't you think that hybrid search ha meaningful use cases? E.g searches that combines BM25 or piplned search in more sophisticated way than simple filter + knn / hnsw then filter?
Or maybe its more for a search engine than a cache
I think that hybrid is useful in many contexts, but that providing hybrid as a bundle with other filtering techniques, API-side, is not necessarily the best way. Just a trivial example, you want to filter by documents year for similarity. With Redis vector indexes you didn't even care about hybrid, you create different keys for different years. This is the usual Redis tradeoff, it's very similar to the past but applied to a novel field.
However I don't deny that in the future maybe, if elements of vector sets happen to be JSON documents (maybe just with the attributes you want to filter with, and a document ID), it may be useful to have VSIM options to filter by such scalars.
However I don't deny that in the future maybe, if elements of vector sets happen to be JSON documents (maybe just with the attributes you want to filter with, and a document ID), it may be useful to have VSIM options to filter by such scalars.
Bentornato ;)
I think Valkey now took over redis maintenance and I don't expect bigger users will reach out for Redis anymore. It seems like a better maintained project at this point. In my opinion, the licensing changed things permanently.
Welcome back to the project!
I love to see original creators continue to work on their projects until the very end, e.g. Linus and D. Richard Hipp of sqlite. I think this produces the best quality software over the long term.
I love to see original creators continue to work on their projects until the very end, e.g. Linus and D. Richard Hipp of sqlite. I think this produces the best quality software over the long term.
It's too late for Redis, IMO.
We loved it at the start, but it's really hard to get it to scale.
The official client library for C/C++ is missing Cluster support.
The cloud offerings (MemoryStore) are a rip-off.
We loved it at the start, but it's really hard to get it to scale.
The official client library for C/C++ is missing Cluster support.
The cloud offerings (MemoryStore) are a rip-off.
It’s really sad that antitez and other people involved with Redis have to deal with all that backlash and what’s even more sad is that people are going for Valkey now. All this breach of trust bullshit imo comes from blind purism that ignores the real reason behind the license change. Valkey is largely sponsored by AWS and other big tech companies so they can have community maintained storage because they cannot use Redis anymore. I hope people will open their fucking eyes for a moment and see that Redis is trying to prevent the big tech to make enormous profits from what people were thanklessly building and maintaining together for many years.
Welcome back Salvatore!
> hint: (Claude AI is in its own league)
Is there a good way to use the Anthropic models as a private person? It's my understanding you can only pay for them as a business.
Is there a good way to use the Anthropic models as a private person? It's my understanding you can only pay for them as a business.
Claude is available for free (with usage limits) if you register for an account. Then you can pay for a $20/month Claude Pro account as an individual.
You can also create a paid API account as an individual and use it via their API, which is almost certainly cheaper than the $20/month Pro account for personal use.
I use the Pro account because I really like the Claude Artifacts and Claude Projects features.
You can also create a paid API account as an individual and use it via their API, which is almost certainly cheaper than the $20/month Pro account for personal use.
I use the Pro account because I really like the Claude Artifacts and Claude Projects features.
You can use the API and Claude as a private individual. I've been doing so for a couple of years.
Edit: Go here and create an account: console.anthropic.com
Edit: Go here and create an account: console.anthropic.com
> You can use the API and Claude as a private individual. I've been doing so for a couple of years.
You're using Claude since a "couple of years". You really must be an early adopter ; )
You're using Claude since a "couple of years". You really must be an early adopter ; )
I checked and I got access to the Anthropic Console in April 2023, so not quite 2 years, but not far off.
As sibling comments have said, you can pay per month to use the web interface, pay for use of the API via self-signup or you can even use them via openrouter.
Nope it's like ChatGPT. 20 bucks / month.
wish redis worked better with the community! improved language support (japanese, korean) for FT.SEARCH; accepted contributions; listened to devs for API design (some of it just so odd); made it convenient to contribute to redis (and not a giant wall of ice...); profit sharing with contributors to redis would be great too...
I love that Antirez is on Bluesky and not X. We should all turn off X and migrate out of that toxic platform.
Disagree. Bluesky is a political circle jerk echo chamber designed for weaklings who need authorities to hold their hand in the face of dissenting opinions.
At least Bluesky isn't hostile to people without BlueSky Accounts. I could read his entire Bluesky account despite not having one.
Welcome back, Salvatore and thank you for the post. It's good to have you back in the fray.
Truly psychotic community response.
History of this pattern:
- There is an open source project, someone wants to work on it full time.
- They set up a SaaS version of their project.
- Other SaaS interlopers eventually come about, but typically none of them can keep up with the main project's SaaS offering as they're at cutting edge and usually most competent and familiar with the project
- Then, a player like Amazon comes in and simply competes on the infrastructure front in a way that the original SaaS offering can't compete with, nor can anybody else.
At this point, the original project isn't able to exist as a business. If your reaction to this is "that's fine, the community can take over from here." Then that is literally the exact option on the table today. From the very moment that Redis Labs was made non-viable by AWS under their original license, the fork was right there for the open source community to take over. It's exactly the same as if the company had gone under. Go nuts with it.
But then when it comes to the license they come up with: it is literally the most obvious and reasonable thing I could possibly think of. Do whatever you want with this software, just don't release the project directly as SaaS.
It is so crazy to me! Nobody's labor was stolen. Every contributor to every patch of the project's work is preserved under the license under which they contributed. Go make Rediss. Go make Reredis. Or just keep contributing to Redis, knowing we can all keep using it, we just can't go make Reredis Labs. I think I'll survive.
History of this pattern:
- There is an open source project, someone wants to work on it full time.
- They set up a SaaS version of their project.
- Other SaaS interlopers eventually come about, but typically none of them can keep up with the main project's SaaS offering as they're at cutting edge and usually most competent and familiar with the project
- Then, a player like Amazon comes in and simply competes on the infrastructure front in a way that the original SaaS offering can't compete with, nor can anybody else.
At this point, the original project isn't able to exist as a business. If your reaction to this is "that's fine, the community can take over from here." Then that is literally the exact option on the table today. From the very moment that Redis Labs was made non-viable by AWS under their original license, the fork was right there for the open source community to take over. It's exactly the same as if the company had gone under. Go nuts with it.
But then when it comes to the license they come up with: it is literally the most obvious and reasonable thing I could possibly think of. Do whatever you want with this software, just don't release the project directly as SaaS.
It is so crazy to me! Nobody's labor was stolen. Every contributor to every patch of the project's work is preserved under the license under which they contributed. Go make Rediss. Go make Reredis. Or just keep contributing to Redis, knowing we can all keep using it, we just can't go make Reredis Labs. I think I'll survive.
Honestly working as a back-end Web dev is kind of a dream job just because you have these stack apps that are super fast, super stable and do exactly what they say they do. Nginx and PostgreSQL are typical examples, and I consider Redis one as well.
[deleted]
Hesitating to put this because it's not related to the topic at hand, but I find monospace font for blogs hard on my eyes. I think I'm getting old, but Arial (and other sans-serifs) are easier to read.
I am not sure what is going on with k:v stores and I do not understand how to hell we ended up with Redis. Using Redis in production for some time I am not impressed.
Redis does not natively scale across multiple cores in a traditional multi-threaded sense, you can still scale it horizontally (across multiple machines or instances).
This horizontal scaling is also problematic. Some of the cloud solutions we used would die during a scaling event.
I went on the hunt to find an alternative but not sure what to replace it with. At this stage the interface has to be Redis compatible because devs really like it.
I found this so far: https://medium.com/@shafreeck/titan-a-distributed-redis-prot...
¯\_(ツ)_/¯
Redis does not natively scale across multiple cores in a traditional multi-threaded sense, you can still scale it horizontally (across multiple machines or instances).
This horizontal scaling is also problematic. Some of the cloud solutions we used would die during a scaling event.
I went on the hunt to find an alternative but not sure what to replace it with. At this stage the interface has to be Redis compatible because devs really like it.
I found this so far: https://medium.com/@shafreeck/titan-a-distributed-redis-prot...
¯\_(ツ)_/¯
whatever floats your boat man, thanks for redis!
btw qdrant did some interesting benchmarks against redis and elasticsearch here
https://qdrant.tech/benchmarks/
https://qdrant.tech/benchmarks/
Other comments on https://lobste.rs/s/u0mrjp/from_where_i_left
[deleted]
I love redis. I'm sure the vector feature vector will turn out great as usual.
So yeah, of course rooting for antirez and his family to get a nice slice of the AI cake!
So yeah, of course rooting for antirez and his family to get a nice slice of the AI cake!
Welcome back, Salvatore!
bro is entering his midlife crisis
rkgany(4)
Can we please just move to using OSS licenses with a clause namely targeting cloud providers? e.g this MIT license is applicable to everyone except for the following companies: Amazon, Microsoft, Google.
Leave the rest of us poor folk alone so we don’t have to seek expensive legal counsel.
Leave the rest of us poor folk alone so we don’t have to seek expensive legal counsel.
I think the right solution for this problem, and many others, is not to allow the "platform" to compete inside their own garden.
So if you offer infrastructure, you cannot offer managed DBs there, if you have a market place you cannot sell on it, if you have an app store, you cannot sell apps there. Etc etc
So if you offer infrastructure, you cannot offer managed DBs there, if you have a market place you cannot sell on it, if you have an app store, you cannot sell apps there. Etc etc
That would not be an OSS license under the OSD.
https://opensource.org/osd
https://opensource.org/osd
What if they had named Facebook in that list, and then Facebook became Meta?
I don't know anything about the legal side of things, but although I can see the appeal of a short blacklist, I think it would be a can of worms.
I don't know anything about the legal side of things, but although I can see the appeal of a short blacklist, I think it would be a can of worms.
Most of the Facebook companies are still called Facebook, see for example FACEBOOK IRELAND HOLDINGS UNLIMITED COMPANY https://opencorporates.com/companies/ie/466405 and some of its connected companies.
Still, you'd probably need a license steward to keep the list of companies up to date, and you'd keep the list in an annex. Alternatively you'd need to pick some objective thresholds, such as "more than 1 T$ market cap or more than 100 G$ global annual revenues". This is the approach the EU followed with the Digital Markets Act.
(I'm not saying that I'm endorsing such an approach.)
Still, you'd probably need a license steward to keep the list of companies up to date, and you'd keep the list in an annex. Alternatively you'd need to pick some objective thresholds, such as "more than 1 T$ market cap or more than 100 G$ global annual revenues". This is the approach the EU followed with the Digital Markets Act.
(I'm not saying that I'm endorsing such an approach.)
> The license language is almost the same as the AGPL, with changes regarding the SAAS stuff. So, not OSI approved? Yes, but I have issues calling the SSPL a closed license.
The AGPL is a nonfree license, despite being erroneously classified as a free one. It is a nonsensical EULA masquerading as a copyright license, and I’m not the only person to point this out.
Comparing your nonfree license to the AGPL might seem like an argument in favor of the open-ness of your license, but in reality it is a condemnation.
It is insane to think that you should be able to dictate what happens to software that other people run on their own computers that you have given away as free software.
The AGPL and SSPL both demand this, for different reasons. Both are nonfree and both are wrong.
The AGPL is a nonfree license, despite being erroneously classified as a free one. It is a nonsensical EULA masquerading as a copyright license, and I’m not the only person to point this out.
Comparing your nonfree license to the AGPL might seem like an argument in favor of the open-ness of your license, but in reality it is a condemnation.
It is insane to think that you should be able to dictate what happens to software that other people run on their own computers that you have given away as free software.
The AGPL and SSPL both demand this, for different reasons. Both are nonfree and both are wrong.
@antirez, if you manage to see this, can you tell me what you think of [1] as a funding model?
[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... , though just read until you get to https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... .
[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... , though just read until you get to https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... .
1. Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc - and when they did that it was under the understanding that project would remain under the same open source license. It honestly felt like a betrayal of trust.
2. From a purely selfish point of view, my favourite thing about open source licenses is that they let me know exactly what I'm allowed to do and build on that software without having to consult a license. Licenses like the new Redis one leave me potentially needing to get my own legal advice depending on what I'm building on the software. I don't want to spend my time, energy or money on that stuff!
I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
(And yes, I do understand and dislike the trend of businesses building on open source without contributing back. There are no clearly correct answers here.)