Merging efforts with Redict #18
Comments
|
I don't see why we should go with copyleft for Placeholderkv. BSD is perfectly fine. You have to meet the community at the other end of the stick, after all :) |
To prevent another rug pull. |
|
I do think it's worth considering whether the future should involve a copyleft license. Ultimately the reason we're in this situation today is because it was permissively licensed and Redis Inc was allowed to do this through the terms of that license. Using the LGPL and distributing the copyright grant (ie not using a CLA to centralize the sublicense permission) effectively prevents that scenario from happening again. Redis' unusual extension mechanisms should largely be unaffected by this with the choice of the LGPL, as only the codebase itself is copyleft, while extensions and scripts can be whatever they want. As an aside for communications, I personally would prefer Matrix over Discord (and other non-free and more importantly closed platforms). GitHub vs Codeberg/Forgejo, however, is something that I think contributors are going to care much more for. I suspect that for various reasons, many of the contributors are going to prefer it being on GitHub. |
|
The key difference here is there is no "Redis Inc" to change the license. This is a community run project, similar to other community projects that have maintained permissive languages the entire time |
Nothing in the BSD license says "BSD or just whatever yolo!!!" — you can't just change a license because you own a company that stole an open source project more and more from a global community over the years. They clearly made an illegal license change to try and get more revenue out of their failing company.
I think anything non-AGPL is basically equivalent since the use case is almost always "hosted server platforms" — the GPL and LGPL restrictions only trigger if you send customers binary-only artifacts. Also, as above, nothing lets people change the license from BSD to just "whatever else you want because people feel like it." Source code licensing is weird because technically each person's copyright is to their contributed lines and not technically the entire file, so if you add a new license for new changes, the new license only applies to the new changes, etc. It's a huge mess unless you gather signatures from every contributor who ever had a PR merged since the beginning of time. Legally, it must stay BSD forever. Practically, you can rip out license headers and do whatever you want until somebody sues you (or unless you are an evil foreign corporation who thinks they don't have to respect copyright law). |
|
Drew your fork was the first I saw when the news started breaking and my biggest concern from the outside was that it was on codeberg. I understand your principals and admire them, but I think the biggest thing that would harm your fork becoming what everyone congregates to is that Redis is here on GitHub. All the contributors are here, the users are here, everything is here... Asking probably 99.998% of all users in the community to pick up and move to a different site, no matter how noble the reason, probably would be the biggest killer and people may settle on congregating around an inferior fork because they don't have to up and move somewhere else. The shakeup of Redis being forked I think is big enough friction to fight against, let alone adding "all communication and efforts have completely left where you knew them to always be.". Just my prospective as an outside user of Redis. |
|
On the other hand, it might be time for an exodus from GitHub and re-decentralization. Today, Microsoft owns GitHub, NPM, systemd (disputed), TypeScript, VSCode, ... Open Source got centralized and what is happening to Redis is just another symptom of the general direction. Heck, some people today even believe GitHub == Open Source:
I have never been a codeberg user, but Redict made me open an account there. I looked around and liked it - I might want to host own FOSS projects there. Drew's decision of hosting on codeberg could just be a step into the direction of fixing our broken, centralized FOSS ecosystem. |
The only constant I've seen in computing over the past 30 years is "mass market" developers will continue to get simpler and less informed over time. Centralized platforms will continue centralizing more things until every computer only has two buttons: "fun" and "work". You basically can't make money as a software company anymore unless everything you create is on some cloud "one click to deploy" console. click and launch and bill by the second. forever. never have control over your platform hierarchy ever again. The perhaps unexpected consequence of everything becoming so opaque and "simple" is we used to learn a lot by continuous troubleshooting. We had to understand our entire systems from CPUs and RAM to networking and storage types and failover and redundancy at five different levels, but these days you can have developers in their career for 10 years and never touch any of those things. Just "click to deploy" behind 37 layers of closed off abstractions you never have to bother learning, so you never know how anything actually works. We've lost all our technical learning by osmosis, so only advanced people seeking out advanced tools actually learn the state of the art anymore. Is the GitHub developer centralized control good? Probably not, but "everybody knowing GitHub" removes weeks of learning when joining a new company vs everybody using different random platforms. I'm not sure companies realize how many months of onboarding they just get to skip these days since everybody uses the same 3 hosted platforms and employee knowledge about them is perfectly transferable for an entire career without losing capability. |
|
We must be careful not to let external goals, no matter how good intentioned they are, interfere with our goals: to create the best possible fork of Redis. Centralization of Git repo hosting sites may be a problem, but it is not one we should be aiming to solve with this fork, especially since things are already confusing as they are. |
|
One interesting point I think people should fight over: what do people want redis to be? Redis has grown too bloated just because the company kept trying to "more feature more profit" maximize everything. It doesn't actually need all these features. It would be much easier to make it a perfect 100% solution to 80% of uses where it almost needs no development for those specific features going forward. Currently it has so many sprawling edge cases you could spend years running in circles fixing and building things almost nobody is using and almost nobody cares about even though stuff is technically weird/broken/wrong for some extreme use cases. Many features of redis were made as "just because they were fun" but it doesn't mean every feature needs to exist forever. Another approach: invert the system and make everything an external module so you could have a group of feature-complete core modules, a sprawling "use at your own risk" feature set (you break it you fix it), then an alpha/experimental feature set. |
|
I'm sorry I didn't respond directly to you Drew, yet, there is been a lot going on. Fundamentally, I don't care too much about the license or the name, but what I want out of this Redis fork diverges too much from what I think you want it to be. I really don't care about FOSS ideologically, I personally enjoy contributing to it but don't want to make decisions for the sake of keeping software open. I care more deeply about the end users of Redis and making sure they're getting a highly performant engine. I don't want to compromise on using tools people are more familiar in order to meet an end. I also don't want to compromise on working with corporations to get them to contribute, which is something I think I've been rather successful at within Amazon. The core of Redis is too bloated, and the things that need to be optimized aren't getting optimized. My major frustration with how the previous core team was running is we spent a lot of time on things that weren't important. We added random metrics for fields nobody asked us for "consistency". Redis needs to get better. We need to figure our multi-threading performance, it's sharding and replication system need to get dramatically more resilient, and I want it to be easier to add extended functionality with modules. In the spirit of what Matt said, "invert the system and make everything an external module so you could have a group of feature-complete core modules, a sprawling "use at your own risk" feature set (you break it you fix it), then an alpha/experimental feature set.", is the architecture I want to trend towards. All of this is stuff I want to focus on. I'm concerned about a rug pull again too though. I'm working to build a diverse maintainer group and am hoping to approach foundations to get the project into a stable governance. That's what I would rather do instead of trying to switch the license. |
|
Drew is a part of a small but vocal minority of FOSS opinionated diehards, which I respect. With that being said, please keep in mind that most developers and end users share a similar mindset of madolson - they use and/or participate in FOSS but don't have deep opinions on it. A vast amount of developers (including FOSS) use Macbooks, iPhones, have Github accounts, use Discord, use proprietary social media apps to talk with friends and family outside of FOSS work, and so on. Trying to convince them to switch platforms just because it is "more FOSS" is a non starter, because they already aren't FOSS absolutists and they won't be just because of a Redis fork. Acknowledging Github centralization is not enough to convince people to move off Github, because it is simply a non issue for them. It is a very hectic time right now - trying to use a different code forge and forms of communication (which, to be frank, most developers don't use) will only add confusion. Many of these alternate platforms may have quirks that FOSS diehards can put up with, but the average developer will find discomforting.
This is not the time for experimentation - we need something ASAP and Github is the best place to coordinate it. I don't think the BSD license is a big deal if the software is controlled by a community (as this fork is), not directly by a company driven by profit. Many BSD licensed programs that are community run have been doing just fine for decades. I firmly believe this project is in good hands. While the license could be up for further discussion, the project's best chance for success is unquestionably on Github. |
This is a very unfair and negative characterization of the issue. While it is true that folks like Drew and myself are a minority these days (both of us are community-centric open source developers who grew up alongside Linux and are heavily influenced by our experiences in that realm), that does not mean our analyses and concerns are not valid.
A community is made up of the people, and depending on who engages and why defines the culture and nature of a project. There is no governance in the world that can protect you from a company just hiring and closing the codebase. That is the story of Redis: a project that was created by an individual, a company sprung up around extending it, they hired the creator and consolidated developer resources, and finally closed it up. This is not an uncommon story with permissively licensed projects. Sometimes it results in a transition to copyleft (as what happened to Element and what Drew has done with Redict) and sometimes it results in a transition to non-FOSS (as what happened with Redis, MongoDB, et al). Copyleft/Reciprocal/Share-alike open source licenses exist to close this hole. And provided no CLA with a sublicense grant is ever offered, it's effectively permanent without going through a super-arduous relicensing effort (which guarantees that the community ultimately agrees to a license change). This is why you see the GNU AGPL being commonly used with Fediverse projects. Many of the folks who create those projects have been involved in other projects where stuff like what happened to Redis has happened, and they seek to avoid it for things that are intended to benefit the wider world.
I could debate this too, but I think this is also a point we can probably compromise on. The legacy of Redis is on GitHub, and that has value too, even if I personally don't like GitHub much either. |
No one claimed such. There is plenty of valid criticism to be had of Github, for example. The concerns regarding the fly-by-night Github clones are just as valid. The question is finding a solution that works for most of the people using and contributing to the project. No solution is going to be 100% perfect. However, most people from Redis team were on github - and we are using Github to host this discussion right now. It is the home of the original redis, and it has everything we need to get going quickly.
All those projects were managed by companies, not communities as I had previously stated. Clang and FreeBSD have been permissively licensed and is still permissive. Rust, Nim, Zig, pytorch, postgresql, tensorflow, and nodejs are other permissive software that have maintained their license, some of which even had large corporate involvement. It seems the "rugpull" you are describing is the rare exception, not the common occurrence. Regardless, in the exceedingly rare case a "rugpull" happens again, we fork it again and continue on. To be clear, we're still not 100% if this BSD to (L)GPL change is even legal. We would like to see proof that what Redict is doing with the license is perfectly legal. Mere speculation is not enough for legal matters - has Redict checked with their attorneys? Even if it is legal (which i highly doubt) it seems like a disrespectful spit in the face to the Redis contributors that contributed under a permissive license.
Studies have been done that show adding one extra "step" in an process significantly reduces the amount of people that finish it. We need the workflow to be as easy and friction less as possible. Drew himself recognizes this to some extent, which is one of the reasons he hosted it on Codeberg instead of Sourcehut. Choosing Codeberg is a implicit admission that meeting the people where they are is necessary for the success of the fork. Ultimately, the people are on Github and so Github is the place to be. |
|
Good morning, everyone.
Hi Madelyn. I have to admit that I'm honestly somewhat insulted that you would characterize the ideology of our fork as such. I tried to explain a few times, but we are not compromising on commercial user's needs, such as the needs of AWS, nor are we compromising on tools. The LGPL is well-suited to AWS's needs -- even if your employer would have a marginal preference for BSD, LGPL will not impose any additional compliance issues for the way that Amazon makes use of Redis, and was carefully selected over more strict copyleft licenses like AGPL or EUPL for this very reason. The concerns of commercial users have been instrumental in the choice of license, not a compromise we're "willing to make". As for tooling, Codeberg is simply where our work is being organized. We need somewhere to do the practical work of building a fork. You're welcome to participate in the consensus process for moving somewhere else, like GitHub, but -- come talk to us about it. Make your arguments and we'll listen to them. I guess we can discuss it in this thread, but I feel that we have to overcome some kind of block which prevents us from working together at all, first.
I don't think this is on-topic for this thread, but, for what it's worth, I'm in agreement. I'll look into setting up a Matrix channel -- I could use some help with that, since I'm not very familiar with Matrix. As for GitHub, I don't think it's necessary to decide right now, and I don't think there is a consensus on the matter. But if we agree that having Redict and placeholderkv work together is best for the ecosystem -- and I think it is -- we can start looking for those consensuses instead of just trudging on in our respective silos. You're invited to our silo -- are we invited to yours? Do we need a silo? Let's look for agreement on the license and then we can stop all of this fuss and sort out the rest together. |
|
Responding to some other comments in this thread, first, GitHub vs Codeberg. As I mentioned before, now is the best time to consider changes like this. Everything is already changing and GitHub => Codeberg is not a very traumatic change. I would like to hear some arguments in favor of GitHub beyond "it's what we're used to". Codeberg is very similar in terms of UX to GitHub. Regarding its maturity, I do not think this is an issue: the Codeberg CI is indeed not very mature but we have already set up working CI through builds.sr.ht, which is a mature and production ready CI system. The rest of Codeberg is perfectly well suited to our needs. I have opened a discussion on the matter on the Codeberg repository. Maybe those in this thread who prefer GitHub can meet us in the middle and come share their feedback there, much like we've extended the grace to join you for this discussion on GitHub? (in response to mattsta)
Redict isn't a software company and needn't be treated like one. Redis was a software company and look where that got us. If we build a viable fork of Redis, people will use it, and the platform is not particularly important. Most people never even interact with the platform, they just pull the container or install it from their Linux distro. (in response to mattsta's second comment):
I think this is a very important question indeed, but I want to reframe it. What are the values of the Redis community? This should guide our decision making. In order to understand what approaches are right -- license, infrastructure, etc -- we need to justify them through our values. I am of the opinion that our values should, at this crux of events, be informed by the fact that our entire community was upended by commercial interests monopolizing the project for their own profit and switching to a non-free license. Mattsta points out that Redis has been skewed in Redis, Ltd's commercial interest for years and the negative effect it has had on the project. If we focus on getting things set back up just the way they were before as quickly as possible without considering how these traumatic events have affected our values, then we are being reckless. Redict has taken this into consideration, and I'm not sure placeholderkv has. We have decided: we value Redis being free software, and we value free software generally. I believe that this is a principle we all hold, or else we haven't been here. I want you to reframe your thoughts on how to respond to Redis's non-free changes with these values at heart. Copyleft is an essential outcome of this framing, and the argument for considering free software platforms instead of GitHub is also well justified under this lens -- particularly in a longer term framing, where we ask ourselves the following: do our values only apply to Redis, and the trauma we have experienced here, or are these the values that we want to approach all software with? The grassroots, public collaborative processes of Redict are also a reflection of this; Redis should belong to its community, not to a cabal of commercial interests discussing the future of our community behind proprietary walled gardens. I don't want to paper over the wounds Redis Ltd. has caused us. I want to treat the underlying problem. Hence, Redict. I really hope you will join us. |
Inertia is a very powerful and good reason. People know Github, and have spent years using it. They teach people how to make Github accounts in the universities. People use Github in their work constantly. I take it you use sway window manager (you made it). Would you appreciate random people online insisting you to use Gnome or KDE plasma? Just as Sway works for you, Github works for us. You are the one responsible for explaining why we should move to this Github clone, not anyone else.
This seems true on the surface, but it's a different story when you dive deeper, UI/UX is a hard issue to get right - Github/Microsoft has spent millions perfecting their UI to be palatable. Codeberg, on the other hand, has ongoing issues with accessibility.
That is an false claim. Codeberg and builds.sr.ht is lacking in features compared to Github and Github Actions. For example, builds.sr.ht supports significantly less operating systems than Github Actions. The old redis repo tested Mac OS as part of their actions, something builds.sr.ht can not do. Using builds.sr.ht seems to require making a sourcehut account (correct me if i am wrong), which is a paid service. I think asking people to move to a paid solution is completely out of the question when there is a perfectly working free solution (Github). Github has built in code search and a larger user base (easier for people to contribute). A full list is available here: https://github.com/features. Github also has integrations with IDEs such as VS Code and IntelliJ's suite of editors. Here are some other problems:
As stated earlier, now is not the time to move to something new. Our goal is not to promote or "prop up" less functional and less popular code forges, no matter how admirable their goal is.
The fuss about "proprietary" websites is misplaced and outdated. The web browser itself is open source, which is the most important part. I find the concept of "non free" Javascript a misnomer because most sites either use mostly free JS or has readable Javascript. Many sites we need for work, school, and play require "non free" javascript. People are not going to forgo their salary just because a website has non-free Javascript. In other words, basically everyone is people fine with using a website with non-free Javascript (even you are right now), so trying to use it as an argument to get off Github won't work.
The legality of your license change is not an issue to be sidestepped. It needs to be addressed sooner rather than later, and I didn't see anything about it in your response. It seems there will always be a legal cloud hanging around Redict. In the early 1990s, AT&T sued the BSD operating system and even though BSD came out victorious the lawsuit and the worries was enough to kill off BSD's momentum. It's one of the reasons Linux was even created.
From your very first message it seems your intent is to get us to join your fork and get us to use broken, still in development websites, rather than actually trying to collaborate with us. |
|
Regarding Codeberg, on the whole I think your arguments are valid, though more discussion is required and on our side everyone seems satisfied with Codeberg. Given that the community we've established with our fork already has some inertia on Codeberg, I'm not going to bother working on a move until a consensus is formed on merging our forks.
I don't think this is a good reason. Either GitHub is or is not compatible with our values. If it's not, then that's a problem, and inertia is an immovable object that shuts down any argument and can never be overcome. Obviously, it has inertia. So what? We cannot meaningfully discuss any changes if we just assume inertia is a valid argument against them.
Both valid arguments in favor of GitHub, or at least in favor of solving these problems. I don't think the other features you mentioned are important, they are not necessary for Redis development. I could just as easily list irrelevant features of Codeberg or SourceHut or GitLab or even SourceForge that are not important for this project.
They had planned maintenance recently, sure, and it was a particularly large one. That's uncommon and I don't think it will generally be disruptive. GitHub has outages all the time. I "recognized" that they had one particular planned outage at one particular moment, I have not admitted that it forms any kind of pattern -- it doesn't.
This is probably something they are willing to work with us on.
This makes no sense. We as a community value free software and it is strategically wise to invest in free software platforms to benefit the broader ecosystem. And, of course, not all software is free, and it's not practical to use only free software websites. What of it? If there are free software tools suited to the task at hand, we should prefer to use them. I have written about this at length previously. I don't know what anyone's salary has to do with anything. Okay, setting aside Codeberg, the rest of your comment:
The license change is perfectly legal. It was not changed, but sublicensed. This is the same thing Redis Ltd did with Redis: they don't hold the copyright, either. Permissive licenses like BSD are defined by the fact that you can do this with them. Addressing this is the motivation behind switching to LGPL in the first place. Redict is perfectly in compliance with Redis OSS's BSD license. https://redict.io/docs/license/ BSD was sued in the 90's by AT&T because they republished proprietary Unix code without permission under the BSD license. Publishing authentically BSD licensed code is not the same thing, the BSD license is specifically designed to allow for this. |
|
Let's direct further discussion about GitHub vs Codeberg to the appropriate thread. You'll have to sign up for a Codeberg account to participate, though, which I think shows good faith anyway! Matters regarding which tools to use can be discussed at a later time, but right now what's important is figuring out if our forks are ideologically compatible and can be merged. If we don't hash this out now we're going to break the Redis community in two and both of our projects will be much worse off for it. |
|
All these discussions make me question whether Redict really is for the community or not. The focus should be Redis; the product itself, yet the majority of discussions are where it's going to be hosted.
I can understand the licensing but being committed to the name from the get-go gives me a wrong impression, even this fork hasn't decided on a name yet and it's not even the important part of what we should be focusing.
Right now you guys are trying really hard to convince people to move over, when in fact the entire community is here on GitHub. Not just the devs but the users aswell. Overall I feel like Redict isn't acting in the interest of the actual community, which is here on GitHub. The hosted platform wasn't even what caused all of this, not sure why the insistency on the move or it being brought up as a point of discussion to begin with. Again, it is not what we should be focusing on nor was it an issue.
Even the linked thread has barely any interaction going on, which should make it clear to you where the supporting community really is. |
|
Again, the choice of infrastructure is largely inconsequential. If there is a consensus to use GitHub then we will use GitHub.
It's exactly because it's not the most important thing we should be doing that it was committed to early. A lot of the other more important things to do kind of have a dependency on the name -- changing the name is (1) required to comply with trademarks and (2) highly labor intensive; Redict is already over +/- 27,000 lines on the diff from Redis and we're not even done yet. In order to get a move on we need to pick a name and move on, so we did. |
|
I have a lot of sympathy for the efforts of @ddevault, but I think the first priority should be to get currently active contributors to join and establish a governance and decision making process. After that a consensus on the license and name can be found. In this regard the efforts of @madolson seem more promising to me. I am also wondering if the names Redis and Redict might just be a little too close, so a judge might say this infringes on the trade mark rights of Redis. |
Understandable, most people are ok with the name anyway and the licensing is also agreed upon by most from what I've read. You got 2 out of your 3 points but are still persuasive about the 3rd point; the move. |
|
Code hosting discussion aside,
There are other forks in this space also making progress. Redict only started 2 or 3 days ago, we can absolutely catch up and get something going.
Even if it is, there will always be enough doubt in people's head that it might scare people away from the project. You might be convinced, but someone or someone's lawyer may be too unsure and would rather prefer a BSD licensed fork. In this time, we need people's full confidence and the BSD license is the best way to do that. Also, I don't think the name is very good. It could add extra legal drama to a project that is basically already bound to receive plenty of. |
I don't know that we have come to an agreement on the license and name. Have we? I do want to have a discussion about the infrastructure choices. If it seems that GitHub is the way to go then so be it, but let's agree to the merge before we put the work in. Everyone seems to want consensus but doesn't seem willing to invite the Codeberg users to it. Again, let's set this matter aside; we will figure it out if and when we agree to merge forks.
Yes, you can catch up, but why bother? All of the work is right there and freely available for you to use if we can get agreement on the license. You don't even need to get me to agree to leaving Codeberg, it's LGPL and you're perfectly welcome to just grab the code, pick up wherever we left off, and drop it on the platform of your choice. It's the obvious choice if you can get behind LGPL, and as far as I'm concerned it's a win for us if all we ended up doing is convincing y'all to adopt the LGPL and giving you a headstart even completely independent of our ad-hoc, temporary governance and infrastructure. The community forming around Redict is committed to a post-Redis world in which this codebase is protected by copyleft. If our forks cannot agree, we will both go ahead with our respective forks, and they will diverge and we will split the community in two. I'm here trying to reconcile our differences to avoid this outcome.
I just don't think that's true. This is just your misunderstanding of how licenses work, and it's easily clarified.
I don't believe that there's any trademark infringement here, but hey, if any of these commercial folks involved want to run it by the lawyers then by all means do. |
Right, that's my bad. "Agreed" was too strong of a word from my part. Putting legal stuff aside, it wasn't a deal breaker or a point of discussion I should say.
This again proves my point, moving to codeberg was a hill you would die on after all. The main community is here and the work of 3 days is not going to convince thousands and thousands of people to move over for no gain. GitHub IS the community. |
You misunderstand me. The hill I'm willing to die on is a copyleft license. Not Codeberg. |
Fair, thanks for clarifying. I'm also for the copyleft license to prevent a similar outcome in the future. |
Similar progress has been made under BSD licenses, we could just as well use their work. Redict hasn't solved the CAP theorem in these 2 short days - most of the commits done so far are renames and documentation cleanup. Most of that work can be done here, probably even faster.
I disagree with your framing, which is very dishonest and rude. The community is already here. The resources are here. You found your own, smaller, community which is fine, but the usage of a BSD license will not "split" anything as you are implying. We are also committed to a FOSS post-redis world, one that respects the spirit and environment that made redis so great in the first place. It's a bit hypocritical to change the license in response to Redis Labs changing their license. They spit in the faces of the community, and you are also spitting in the faces of the community.
For a legal matter we need more than what you just "think" or "believe". |
|
@ddevault but nobody asked you to die. Why suddenly such passion? Have you contributed to the project before? This is how it appears to an outsider like me: While Redis' current maintainers are still thinking on how to proceed with the fork, |
This encapsulates how I feel about this thread.
There will be places to collaborate, but I think for now our paths are going to diverge. There are several key issues present in the open-source Redis that need to get addressed, and we plan to do that ASAP here. (There is an issue when upgrading from Redis 6.0 -> Redis 7.2 that hasn't been resolved yet for example). @ddevault My plan is to open issues (and maybe PRs) for them to your fork when we have them merged here. I, and hopefully others, would be happy to explain any of our rational with what we are working on to help your fork as well. I've said on other threads my top priorities are to make sure former Redis user and developers aren't impacted by this, which would cover folks that choose to use your fork. |
Not a lawyer, but this also worries me a lot. Redis is "Remote dictionary server". From your docs, https://redict.io is "remote dictionary". Redis did change their trademark guidelines to be more strict, and I would rather not get on their bad sign. Folks have also been very supportive of including open in the name. |
also hilarious given how the current company known as "Redis" started out by blatantly stealing the name more and more aggressively over time (they used the open source project color scheme and font and even the open source logo directly for their private company to confuse customers into thinking they owned the entire project) just to get what they want without regard for any copyright or property rights or ownership of anything in the world: https://www.gomomento.com/blog/rip-redis-how-garantia-data-pulled-off-the-biggest-heist-in-open-source-history |
This sounds like a reasonable way to move forward if we're not in a position to merge forks. Thanks! |
it's depend on situation and each situation is unique. Sometimes permissive is fine and even better (e.g. lib which implement protocol) sometimes no. Just for example Postgres also use permissive license, but it's ok so far because they have no one stack holder and the main contributions split between ~5 big companies. If collaboration (share code and negotiations) more profitable for companies which contribute then permissive license is working fine, if not - project will died. This is why in a such cases GPL/LGPL help to change balance from companies interest into project interest. |
That's what I'm trying to do here. The 5 committers we have represent AWS, GCP, Alibaba, Erric, and huawei. I think have diverse stakeholders is the best way to insulate another rug pull, imo. |
|
Yes, but it's not looks sustainable yet (sorry) and LGPL at least for me looks much more trust without any cons. And as ex contributor to Postgres I can say, it's produced too much political games. |
There is always politics. |
yes, sure, but I hope you got my point what it's extra tension, and LGPL a little mitigate it. Anyway, thank you for your initiatives! PS with BSD Redis lab can use a such code without any feedback, it's sounds unfair in the current situation. |
There is no such company yet. Someone could go found one tomorrow. At one point, there was no Redis, Inc, either, and then someone went and founded it. |
I think the reality is there's no profit in this anymore. Software like redis isn't a core product. It's just a side car component complementing larger platforms. It's a fungible plastic fork in a world full of takeout and nobody wants to venture fund a plastic fork factory. When redis started in 2009, the world was just waking up to the reality of "you can't use disk for user services because now networks are fast and disks are slow, so everything must be in memory." In 2009, having a server with 32 GB RAM was impressive — and today my watch has 32 GB RAM and modern SSDs with their direct-to-CPU interface lanes are almost faster than RAM from 2009 (related: linus released a fun video on optane yesterday too https://www.youtube.com/watch?v=Al93JD5GExY) Today you can buy a single 1U server with hundreds of cores and 3 TB RAM for less than $100,000 USD. That's almost more capacity in one single 1.75" tall server than an entire 10 rack data center deployment from 15 years ago. Here's an article from 2008 showing RAM was around $125/GB: https://www.tomshardware.com/reviews/ddr3-1333-speed-latency-shootout,1754-26.html. Today, RAM costs around $2/GB and 1 TB of high quality SSD is around $50/TB (unless you use Apple Pricing of $400/TiB). Basically, my laptop today is more powerful than an entire 42U rack of servers 15 years ago. This also means people care less about high quality high performance software since even really poorly architected lazy programs just get fast with modern hardware (until you get hit with actual intractable scalability bottlenecks, but nobody thinks ahead that far anymore). The benefit of simple key-value databases got an industry/VC "noSQL" hype cycle between 2010-2016, but once you fall out of the hype cycle the world moves on. From what I've seen in the industry, it's mostly "nobody cares" anymore. I've been looking for a new job for a while and it appears there are only two roles left in the world:
Yesterday AWS gave anthropic almost $3 billion in funding/support, but when was the last time anybody seriously funded a database (and I mean seriously and not just a bridge round or a pity "we wasted money on you so far, so here's a little more" round)? Nobody funds databases anymore. We just live off talented passionate people throwing off free software worth billions of dollars in surplus value nobody can capture except hosting providers (and you can't "out hosting-provider" the top 3 platforms yourself). I've always thought a high efficiency high performance legacy redis-like platform is a great fit for what people call IoT — which includes things like tens of thousands of modern 5G distributed base stations and edge deployments (or anything you call a "station" or "edge" or "CPE" as a remote deployment). In remote, non-data-center, hardware deployment situations you really care about minimizing hardware footprint/spend via memory+compute efficiency and reliability (thus not duplicating hardware unnecessarily on-site where you have to roll a truck to fix things). Getting your products used in forward-deployed hardware is more of an enterprise big S&S sales cycle though instead of the open source "blog post -> clever intern trying new things for resume-oriented-development -> new ideas deployed as internal services -> becomes production service -> suddenly you're trapped into needing CYA support contracts" pipeline. overall? Best outcome: somebody pays "just for the good of the world" for experienced high productivity experts to maintain high quality public software under a guaranteed growth+maintenance agreement for decades. Modern world: eat it up and chew it out then complain when your cud doesn't taste like strawberries and rainbows anymore. |
|
@madolson hmm what you decided after all? Will your collaborate with Redict or not? |
|
In my opinion license change compared to what Redis used to have is a poor choice, because it ads another layer of friction - if you are serious organization which cares about license compnatibility you will need to run analyses here. In particular LGPL is not that common license those days. Also to successfully compete against Redis you want this software to be as usable as possible - easily embeddible in all kind of projects - both open source and proprietary. "Preventing someone else to pull what Redis did" is achieved with proper Governance with Trademark ownership. Imagine if Linux Foundation (or soe other non profit) would have owned Redis trademark ? The only thing Redis could do is to create another project and make that project under SSPL license, as well as stop contributing to Open Source version |
|
I work at large companies that require license reviews, and for many previous employers I've assisted in those reviews. LGPL is not added friction. We already know about it, it's already on the list. Personally I like it. GPL can be tough to reason about (or annoying to implement) but LGPL you don't have to care about if you're a user just like MIT. And then you get the sharing potential for modifications and improvements. I love that. I do agree a foundation governance is the best defense we need and I'm glad this project has it. |
|
@reconbot My point is not about LGPL being bad license, but rather if the goal to provide drop-in replacement and seamless migration for users of old Open Source Redis versions, it is best achieved if license is the same. While being Great license LGPL is not drop in for BSD in all cases. |
|
Well, there are several goals, aren't there? And there may have to be some compromise between them, to ensure the best possible outcomes. Two goals just off the top of my head:
Obviously there may be there goals held by others. But LGPL seems like a pretty good compromise between the needs of the community and the health of the OSS project going forward. I don't think @madolson is strongly opposed to LGPL as long as the project is on GitHub, nor is @ddevault strongly opposed to GitHub as long as the project is licensed as LGPL. It seems like a compromise should be reachable? |
|
The thing is LGPL does not solve the problem, because it is not the license problem. Think about issue with RedHat CentOS cituation for example. The issue is Governance, Trademark and means of distribution ownership. If Redis trademark would be owned by some foundation as in case of Valkey they would need to fork off to differently named project which does not have the same value. If product is LGPL licensed though it does not prevent some "corpotate interests" for example to keep their improvements to only version which is available as a cloud, even GPL does not as you can see with AWS Aurora MySQL. Furthermore you can look at the projects like Kubernetes or PostgreSQL both of those Permissively Licensed, have high commercial "hijacking" value but Found governed and you can see they have not been taken over by corporate interests In the nutshell the license change to LGPL will offer very limited protection compared to foundation governance alone while create additional friction. |
Seriously? This is nothing like that. The sources remain available to everyone through CentOS Stream, and the RHEL SRPMs are still available to customers. Ultimately, nobody "lost" the rights afforded to them as Red Hat customers if they use RHEL. |
Actually, it creates a very important piece of friction: proprietary changes to the core code is no longer possible. And with distributed copyright, the license can never be changed again without asking everyone who contributed, guaranteeing that a license change isn't going to happen willy-nilly. That's worth a lot for a lot of people, myself included. |
@PeterZaitsev but it solves the problem that the project owner was able to relicense the project because it had an extremely permissive license. In the future, Redict won't be vulnerable to this any more. But Valkey will (as things stand today). Governance teams come and go. In the beginning everything is great and everyone gets along. Then people and teams change and corporate interests take over. Why leave it to chance? Even a slightly stronger copyleft license like LGPL prevents the issue at its root rather than relying on the goodwill of all parties for all time to come. |
|
I appreciate everyone being so civil on this thread, I know it's a contentious topic and I'm glad everyone here has the opportunity to convey their thoughts.
This was my main priority, and I'm really happy with the support we've gotten from the LF and I think the future (at least the couple of year outlook) seems pretty secure to me. I'm more interested in keeping Valkey community driven in the long term, as opposed to one where it remains open but still potentially controlled by corporations that don't benefit the community. The case that yawaramin mentioned about corporate interests taking over already feels like a failure state to me, since they would have needed to acquire a majority of seats on the technical steering committee, and that means the community would have not tried to stop them. Just because they can't relicense it, doesn't mean they couldn't still use LGPL license to advance their aims. I suppose my question to advance this discussion is are people going to avoid contributing if we don't try to move to a more restrictive, but still FOSS, license? |
Sure, this seems unlikely now. But Redis is 15 years old. In another 5 or ten years from now, who knows? At the very least it seems pretty clear that Open Source software will continue to undergo churn. For example, who would have thought that, when antirez stepped down from Redis and the new maintainers promised it would stay OSS, that this would not be the case? Did the community get a chance to prevent relicensing? No, everyone was blindsided. It seems prudent to put in place a hard guarantee that despite any failure state, the Valkey project could not be co-opted in that way. But of course, as you said, the crucial question is what contributors will do. And I guess we'll see that play out with Valkey and Redict. |
|
I will say more, in my opinion pre-venting ability to have derived software with different license is actually harmful, as it is companies which end up making money around the project are those who end up spending resources on it. What should be prevented is the Open Source Project changing it license as it happened with Redis, which is governance issue. Look at PostgreSQL vs MySQL for example - one of the reasons PostgreSQL is so successful, many companies worldwide are free to build the products, including many commercial ones around PostgreSQL, where MySQL with GPL license prevented that (besides the cloud). Also note very big part of use case is NOT really protected by LGPL license (or even choosing GPL) - Many Valkey project members are Cloud vendors who can offer cloud version with some proprietary improvements, and I am quite sure some will. In the nutshell if the focus of the project is about attracting as many users and contributors as possible, keeping permission is the best, and I think this should be the main focus at this early point. |
The obvious counterexample being Linux with GPL license being used in almost every device and workload you can think of.
And if there are multiple goals that can be reconciled together, then a stronger copyleft license is quite possible. |
I think that most of what needs to be said on this issue has been said, but I do want to quickly correct this framing of the LGPL et al as "more restrictive". They are not more "restrictive" -- any license which restricts freedom of use is by definition non-free and/or non-open. They have some obligations, which is not the same thing. MIT also has obligations, like preserving the copyright notice. Permissive licenses like MIT come from the view where "freedom" means relatively few obligations; copyleft licenses like LGPL posit that freedom is a guarantee of rights. I don't think copyleft licenses are more "restrictive" but they are certainly more free. |
The historical artifact around "free software" is amusing because all the "free/libre!" software ideas were made by people who grew up in literal hippie communes and had everything given to them by a shared community without needing to do the whole capitalism "profit every day or die" dance. It's a great ideology if you have an unlimited source of personal funding and low-to-no personal growth ambitions (or live in low/no cost of living countries, or just get placed into a lifetime university appointment to promote "free software"), but we've seen it doesn't work to survive. I can release world class software, get it used by a million developers, have it deployed inside multiple multi-trillion-dollar companies to subsidize their private profit machines, yet the creators still can't afford a place to live. Every prominent "open source" developer/architect/maintainer survives off social status (or temporary VC funding before they realize "open source" isn't a business model) and not their actual work output (see: guido hopping between 5 companies just to keep getting paid because nobody is ever going to really pay for python, etc). We lost the game of "unlimited user freedom, but restricting private rights" a while ago and I'm not sure we can ever fully get it back. If you add restraints, everybody will duplicate your project to work around you anyway. If you don't add restraints, everybody will copy your project directly and never compensate developers for global value created. 🤷 — so the game becomes "do we do good work and enforce restrictions, but then become obsoleted by funded copies" or "do we do good work, let the world copy it with no restrictions, then maintain some social status as 'creator of the thing everybody uses but nobody pays for?'" |
At all points in time since I was added to the previous Redis core team, I thought there was a realistic chance that Redis would decide to relicense the core, because they had the right to do so and their leadership could believe it was in their interest. I obviously didn't know it would happen when it did, but I think people should be distrustful when a single entity controls an OSS project the way Redis did. The skepticism is healthy. |
|
Yes, and skepticism is healthy no matter which entity, individual, or committee controls a project. When they have the legal mechanism to do so, that means the risk of relicensing exists. Despite how great the technical leadership committee is today, it's prudent to think about a future where the leadership could change without anyone really noticing or foreseeing it. People don't say 'My driver is great, so I don't need to wear a seat belt', right? |
and others
Hi, I'm one of the people working on the Redict fork, and we would like to merge efforts if possible. Bringing the discussion here from #8 (and various private conversations) where there is some additional context.
The only thing we're really committed to is the name and the use of the LGPL license. If the folks working on this fork can get on board with that, then it does not make sense to split the community in two, but we are committed to the copyleft approach so we will need to get consensus on this to merge forks. The rationale behind LGPL has been explained in a few different places, but I've summarized it here.
As far as practical matters are concerned, there is the matter of infrastructure and communication. We're using Codeberg rather than GitHub right now, which should be very familiar to GitHub users and has the advantage of being free software, which we are strongly in support of using. I hope you're willing to give it a shot, but I don't think it's a hill worth dying on. Discord on the other hand, I can't speak for everyone involved in Redict but I think it's a very hard sell. We're using IRC right now, but we could be convinced to use Matrix, which is a bit more user friendly.
The text was updated successfully, but these errors were encountered: