Merging efforts with Redict

[ddevault]

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.

[likecrazy1]

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 :)

[LeoniePhiline]

I don't see why we should go with copyleft for Placeholderkv.

To prevent another rug pull.

[Conan-Kudo]

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.

[likecrazy1]

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

[mattsta]

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.

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.

The only thing we're really committed to is the name and the use of the LGPL license.

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).

[joshmanders]

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.

[LeoniePhiline]

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'm a bit skeptical since it's not hosted on GitHub. as is the standard for open-source projects, so I'm wondering why this fork wasn't hosted here instead of some other site I'm not familiar with. It makes me question the legitimacy of it.

https://github.com/redis/redis/pull/13157#issuecomment-2016624891

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.

[mattsta]

some people today even believe GitHub == Open Source

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.

[likecrazy1]

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.

[mattsta]

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.

[madolson]

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.

[likecrazy1]

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.

• IRC requires you to pay for the ability to see messages when you are away, while Discord does that for free. Matrix could be better, but it comes with its own problems: https://telegra.ph/why-not-matrix-08-07
• Codeberg doesn't have as many features as Github, and it is still very much still in development. As an specific example, the CI/CD is still a work in progress as shown via their webpage: https://docs.codeberg.org/ci/ . It clearly states CI might "break at any time and for an undefined period of time"

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.

[Conan-Kudo]

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.

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.

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.

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.

While the license could be up for further discussion, the project's best chance for success is unquestionably on Github.

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.

[likecrazy1]

that does not mean our analyses and concerns are not valid.

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.

This is not an uncommon story with permissively licensed projects ... Redis, MongoDB

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.

I could debate this too, but I think this is also a point we can probably compromise on.

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.

[ddevault]

Good morning, everyone.

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.

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.

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 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.

[ddevault]

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)

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.

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):

One interesting point I think people should fight over: what do people want redis to be?

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.

[likecrazy1]

I would like to hear some arguments in favor of GitHub beyond "it's what we're used to".

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.

Codeberg is very similar in terms of UX to GitHub.

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.

The rest of Codeberg is perfectly well suited to our needs.

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:

• Codeberg seems to have slowness and availability issues - and multiple friends from other countries reported they could access Github but not Codeberg for whatever reason. They have weekly "maintenance" periods where the site simply does not work, which Drew recognizes. Maybe that's fine for hobby projects, but for serious production projects Github has a significantly better uptime record.
• They have a limit on how many gmail addresses can sign up for "spam" reasons. This inevitably means some people that use gmail are shut out of the platform, which then does nothing to help them.

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.

Redis should belong to its community, not to a cabal of commercial interests discussing the future of our community behind proprietary walled gardens.

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.

Copyleft is an essential outcome of this framing

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.

I really hope you will join us.

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.

[ddevault]

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.

Inertia is a very powerful and good reason.

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.

Codeberg, on the other hand, has ongoing issues with accessibility.

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.

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.

Codeberg seems to have slowness and availability issues. They have weekly "maintenance" periods where the site simply does not work, which Drew recognizes.

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.

They have a limit on how many gmail addresses

This is probably something they are willing to work with us on.

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.

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 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.

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.

[ddevault]

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.

[PenguRinPrivate]

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.

The only thing we're really committed to is the name and the use of the LGPL license.

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.

I hope you're willing to give it a shot, but I don't think it's a hill worth dying on.

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. Why is it that thousands of devs and users should be switching platforms just to fulfill the views of a fraction of the community when GitHub is already matured and well established. This is where the community is and it sounds like this is a hill you want to die on.

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. Everything about Redict so far was to suit the ideals of a few devs rather than thinking about the actual community.

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!

Even the linked thread has barely any interaction going on, which should make it clear to you where the supporting community really is.

[ddevault]

Again, the choice of infrastructure is largely inconsequential. If there is a consensus to use GitHub then we will use GitHub.

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.

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.

[kamulos]

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.

[PenguRinPrivate]

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

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. Right now you want everyone to agree to all 3 terms and if you really care about the product you would compromise on your side and keep GitHub as the hosted platform. You being adamant on using codeberg is what will split the community.

[likecrazy1]

Code hosting discussion aside,

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. Redict is already over +/- 27,000 lines on the diff from Redis and we're not even done yet.

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.

The license change is perfectly legal.

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.

[ddevault]

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. Right now you want everyone to agree to all 3 terms and if you really care about the product you would compromise on your side and keep GitHub as the hosted platform.

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.

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.

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.

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.

I just don't think that's true. This is just your misunderstanding of how licenses work, and it's easily clarified.

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 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.

[PenguRinPrivate]

I don't know that we have come to an agreement on the license and name. Have we?

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.

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.

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.

[ddevault]

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.

[PenguRinPrivate]

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.

[likecrazy1]

All of the work is right there and freely available for you to use if we can get agreement on the license.

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.

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 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.

I just don't think that's true. I don't believe that there's any trademark infringement here,

For a legal matter we need more than what you just "think" or "believe". This is an admission that you are posting your crackpot theory of how licenses work, and not one backed up by actual legal sources.

[romange]

@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, a group of energetic newcomers, previously uninvolved with the project, have already chosen a fork name, hosting platform, and the license. And now they ask for the original team to "meet them in the middle". Also, they say Redis is already perfect as it is, so I guess they also decided on its roadmap. The whole discussion looks like a DDOS attack on maintainers. Why do they need to defend their position and their (subjective) preferences. Did not they earn the moral right to decide on keeping the status quo?

[ddevault]

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.

I don't think this is hypocritical at all. Redis Labs changed the license in a manner that only benefits them at the expense of everyone else. The Redict license change protects the project while preserving everyone's interests and retaining its status as free and open source software. I don't think this is comparable by any stretch of the imagination.

For a legal matter we need more than what you just "think" or "believe". This is an admission that you are posting your crackpot theory of how licenses work, and not one backed up by actual legal sources.

I don't think I'm bringing forward crackpot theories. With respect, you are the one who doesn't understand the BSD license or the Unix copyright debacle. I would prefer that you don't characterize my clarifications of your understandings as crackpot theories -- let's keep this polite and respectful. There are not really established moderators or a code of conduct for this fork yet, but I don't think this kind of remark is in line with community standards.

[ddevault]

@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, a group of energetic newcomers, previously uninvolved with the project, have already chosen a fork name, hosting platform, and the license. And now they ask for the original team to "meet them in the middle". Also, they say Redis is already perfect as it is, so I guess they also decided on its roadmap. The whole discussion looks like a DDOS attack on maintainers. Why do they need to defend their position and their (subjective) preferences. Did not they earn the moral right to decide on keeping the status quo?

I have worked with Redis before, yes, though never as a regular maintainer, but upstream and downstream. But what of it? Leave ad hominem out of it and address my points, please.

[likecrazy1]

let's keep this polite and respectful

I have been nothing but polite and respectful here. I have not used any slurs or strong language - and it is very distasteful for you to imply otherwise.

If anything, you started with the grandstanding about how your fork is the greatest thing in the world.

With respect, you are the one who doesn't understand the BSD license or the Unix copyright debacle.

You just insulted my understanding here, yet you are accusing me of not being respectful.

[ddevault]

let's keep this polite and respectful

I have been nothing but polite and respectful here. I have not used any slurs or strong language - and it is very distasteful for you to imply otherwise.

With respect, you are the one who doesn't understand the BSD license or the Unix copyright debacle.

You just insulted my understanding here, yet you are accusing me of not being respectful.

You called me a crackpot, my friend, moreover dishonest and rude; I have been none of these things. Factually stating that your understanding is mistaken is not rude. Take your vitriol elsewhere.

[likecrazy1]

You called me a crackpot, my friend, moreover dishonest and rude; I have been none of these things.

I didn't call you a crackpot. I said "crackpot theories" - I was dismissing the dubious legal theory itself.

Nevertheless, this is sidestepping the real issue: the legal theories you are propounding have no legal basis and let us not pretend otherwise. This is all based off your belief - as you stated earlier when you said "I think....."

[ddevault]

I think this thread has served its purpose, and I don't see much reason to keep up with what is becoming a rather unpleasant argument. My points have been made. We're going to get back to work and the offer to collaborate with us stands.

[stalkerg]

1. LGPL is perfect, it's what should be at the beginning.
2. Codeberg - after Postgres and Linux dev process it's ideal, almost same as GitHub or GitLab.
3. IRC it's ok but not so good as Zulip https://github.com/zulip/zulip about Matrix I am not sure... it's not looks good for development.
4. Still need common platform to discuss about future. For first few months, Codeberg + IRC/Matrix should be ok but after it should be community decision.
5. This issue contain too much text about nothing.

[stalkerg]

BSD aligns with the status quo

A such status quo was a reason for forks and all this situations.

makes legal matters easier

it's identical, if you suppose sub-licensing to LGPL not possible than Redis Lab also can't do it. Really, is not big deal in the current situation.

[likecrazy1]

A such status quo was a reason for forks and all this situations.

The thousands of other projects with permissive licenses have maintained the status quo and have had no hostile license changes. I don't know why people are ignoring this fact all of a sudden

[joshmanders]

FWIW: This repository has not only the correct license, but a name that doesn't infringe on trademarks, even though it's literally just a placeholder name AND actual significant contributors to the project backing it.

I'm sorry Drew, I wanted to be on your side, but all of your responses in this thread have been very aggressive and demanding of everyone migrate to your fork because you had already settled on a name and DIFFERENT license?

You're doing more harm to progress Redict than anything.

[impredicative]

I don't see why we should go with copyleft for Placeholderkv.

To prevent another rug pull.

How on earth does LGPL prevent a rugpull? It doesn't. LGPL has its benefits such as mandating code sharing of derivative works, but preventing a rugpull is not one of them.

[madolson]

This issue contain too much text about nothing.

This encapsulates how I feel about this thread.

We're going to get back to work and the offer to collaborate with us stands.

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.

[madolson]

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.

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.

[mattsta]

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.

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

[ddevault]

This issue contain too much text about nothing.

This encapsulates how I feel about this thread.

We're going to get back to work and the offer to collaborate with us stands.

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.

This sounds like a reasonable way to move forward if we're not in a position to merge forks. Thanks!

[stalkerg]

The thousands of other projects with permissive licenses have maintained the status quo and have had no hostile license changes. I don't know why people are ignoring this fact all of a sudden

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. Linux kernel is a good example.

[madolson]

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.

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.

[mattsta]

The 5 committers we have represent

[stalkerg]

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.

[madolson]

it's produced too much political games.

There is always politics.