Change license from BSD-3 to dual RSALv2+SSPLv1 #13157
Conversation
|
|
|
|
This reverts commit 0b34396.
|
booooo |
|
It would be nice to list the new forks in this pull-request along with the ones without CLA and shared copyrights with Developer Certificate of Origin. This would avoid this exact situation. |
There was a problem hiding this comment.
You shall NOT remove the BSD license header, since there are third-party contributions to those files (without signing a CLA), which were licensed under BSD-3-Clause. The same also applies to other files in src/*.
|
My contributions are made open source under the BSD license. You are not allowed to redistribute nor use them in source or binary forms without the original copyright notice and the BSD license. You must remove my contributions. |
|
Are you aware that you have just removed Redis from the vast majority of Linux distributions? 😒 This is a very bad decision that will not end well for you in the end. Look at ElasticSearch vs OpenSearch, MySQL vs MariaDB, Oracle JDK vs OpenJDK, OpenOffice vs LibreOffice etc. There are some precedents with Terraform, Elasticsearch, Red Hat, and a few other big players now dealing with a lot of their target users and potential customers depending on open source forks. As a business strategy alienating future users like that seems misguided. (source) If you want an example of how to do it better, check out TimescaleDB. |
|
Time for a Libredis fork! |
that'd be a way out, yes, but it would be so much less wasteful if we could convince you to take this change back. sure, making money producing open source software is tricky, but given the fact that this is carried out with such obvious mistakes as the unlawful removal of BSD headers, are you sure you have done your research and established this won't backfire? i am working for a commercial reddis user, and i am certainly going to look out for forks now. btw good reputation comes from reconsidering and fixing mistakes, not doubling down on them! :) |
Edit: please use sircwncmp's redict: https://codeberg.org/redict/redict
|
@zuiderkwast |
5.5 years it took for that to become untrue. |
|
Fork by Drew DeVault: https://codeberg.org/redict/redict |
|
freedis, here we come. |
|
This change is probably uncalled for since it has been claimed that AWS has funded one or more Redis developers for years. The relevant forks of Redis I see are:
Alternatively, the legacy of Redis may be the RESP protocol rather than Redis itself. Here is a list of projects that claim to support the Redis protocol: |
|
wow this is dumb |
|
no |
My commit 11cd983 to allow Redis modules to function with modern compilers was also made under the BSD license and permission is not granted for it to be used under any other license. Copyright for changes in this commit is held by my employer, Red Hat. |
|
no. |
|
👎 |
How does this have anything to do with “wokeness” LMAO. It is corporate greed not wokeness you dork. |
One thing for you to consider- The developers such as myself, who work for big companies... We get paid to produce quality code. Given, there is generally a large financial impact to said companies, based on the performance and reliability of said open source projects- I can assure you my development team will push a lot more high quality code, as opposed to random joe chilling at his house. That being said, I'd elect to stick with the fork, that has quality developers... the ones who understands unit tests, etc. |
|
Redict 7.3.0 is now available: https://redict.io/posts/2024-04-03-redict-7.3.0-released/
As for who writes better code, grassroots communities or commercial developers... I'll encourage anyone with doubts to browse our code, or our documentation in particular, and let you be the judge. Aside: here's the diffstat comparing Valkey (top) and Redict (bottom) in terms of divergence from Redis:
That's just the core codebase -- Redict also has comprehensive documentation and official containers ready to use. If you want to focus on where the development action is, Valkey has a long ways to go. Don't forget where Redis started, either. |
|
@ddevault Very fair. That being said though, instead of comparing the two- we should just celebrate that we are away from redis's proprietary license. |
Fair enough. Hooray for forks! 🎉 |
|
@ddevault Even the first line from the release notes made me stop reading any further.
You make it sound like as if that wasn't the goal of Valkey, which is again misleading. I'm sure there is more if I continued reading but it is getting rather weird how you're trying people to focus on your fork and the words you are using. |
This is not a slight against Valkey, it's a factual difference between our projects. Everyone wants to converge towards stability but it is a matter of fact, not opinion, that adding a bunch of new features and undertaking a lot of major refactoring creates churn and reduces stability, or at least makes it more difficult to achieve. This is a trade-off we make when fostering innovation -- and trade-offs are factual but value neutral. |
|
NO |
|
RIP redis, is Valkey the future? |
Sure its, lock Redis on the last BSD version in your package manager and wait for a stable Valkey release |
|
Redis made the worst decision. There's not much more to say except that https://github.com/valkey-io/valkey is the future. |
Reddit seems innocent😂 |
Better read it twice... |
I meannnnn |
|
I was not Redis for this. |
yeah i did a misstake i obviously mean Redis. |
|
lol |
This bothered me. Churn is a bad statistic for gauging productivity, and since I am certain @ddevault knows that, I thought I'd have a look at what was actually different. If one actually reads the diff between HEAD and e64d91c, the overwhelming majority of changes are @ddevault adding Since the changes were made by @ddevault, meaning that he knows that the amount of churn is mostly fluff, and since he knows that churn is a bad metric to begin with, I can't come up with a characterization of this other than to say it is intentionally misleading and relies on a lack of scrutiny (which, as a hacker, almost feels like a personal insult to me). That made his claim about the number of contributors suspect, so I thought I'd have a look. 85.4% of the commits in Redict are from @ddevault, who has made 88 of the 103 commits as of d2e5e9655, while in Valkey, the curve is much flatter, with the top contributor (@0del) producing 16.2% of the commits as of cc94c98a9. (Number of commits is about as misleading as churn; the numbers are cited only to demonstrate that the claim of open-source contributors stampeding towards Redict is also false. You can check this with To head off any suggestion of a hidden agenda, I don't have a dog in this fight: I'm not pushing either fork, just waiting for the dust to settle, and I have no corporate overlords. I just do not like FUD and misinformation, and I think the mudslinging in this thread is shameful. (I do think, long-term, a project probably has a better shot promising community governance rather than being run by someone that launches ad hominems against the other project, to say nothing of the misleading statistics, but looking at the commits, I see a trustworthy friend of mine involved in Redict.) |
|
I don't think that changed lines is the same thing is churn, and I also don't think changed lines is a measure of quality. What I'm measuring here has more to do with the tangible work that both Redict and Valkey have had to do in order to create a fork, which is the substantial effort of renaming everything and which necessitates a lot of lines changed. Valkey will have to complete a similar level of work in order to complete the forking process, and Redict is far ahead of them in this respect. That's all I'm pointing out with this comparison.
This "s/Redis/Redict/g" work is the bulk of the "churn", and it is not actually as simple as running "sed" over the codebase. It is a largely manual process which requires attention given to each case; in some respects it can be automated but in order to be done properly it requires a lot of manual attention and labor.
It is true that I have written most of the commits per-se as well as most of the lines changed, but as you said these are not a good measure of much. But, importantly, I have done most of the work for redict, i.e. the C language implementation of the Redict server and client, while other contributors have done most of the work in other respects; equally valuable and necessary work which, as it happens, has also mostly been completed on Redict whereas Valkey hasn't really started. This includes forking and cleaning up hiredict, which was led by Anna, most of the work on the Redict containers, which was done by Hugo and Micke, as well as writing and rewriting Redict's comprehensive documentation, which includes both content derived from the CC-BY-SA portions of the Redis documentation as well as original content written for Redict, most of which was led by Lucas.
Redict does have an agenda, though it's not hidden, which is to create a grassroots, community-governed fork of Redis with a copyleft license to protect our community from future exploitation. Valkey is only "community" led insofar as the main commercial interests in Redis constitute a community, as they are the sole decision makers and leaders of the Valkey community. This is not some kind of slander or ad-hominem, but a value-neutral statement of fact; in fact I acknowledge that some users of Redis would prefer the project to be led by commercial interests. |
|
Quoting @ddevault:
As Valkey is not changing licenses (yet) and not moving away from Github (yet?), no, none of those things need to be done. Licensing headers don't need to be added to example scripts at all, and are not a hard requirement to have a viable fork. You know this.
I'm aware. It is still not a meaningful change and is not an indicator that Valkey is somehow "behind", and it doesn't do anyone any good to suggest that. MariaDB kept the exported symbols and executable/library names for the sake of compatibility; I imagine Redis Labs is far less litigious than Oracle. There's plenty of value in doing things that way: merges from upstream are easier, people have less to rewrite, and eventually merging forks is easier.
What I meant to head off was the repeated insinuations Redict's self-appointed BD has been making about Valkey; they wouldn't apply in my case.
This is disingenuous. They have professed an aim to produce a community-led effort; that's as much as you have said. There's not been time for a community to coalesce. Digging trenches and encouraging a rush to judgment is a very bad move, the opposite of trying to get a community to coalesce. The sensible thing to do, if a project actually were community-led, would be to keep alterations minimal until there's some kind of consensus, and there is no consensus until there are enough people for a consensus to be meaningful. It seems like even if they moved to the LGPL, you'd not be interested in merging the forks: is this accurate? (I would like for it to not be accurate, but I suspect that if it were not true, then you'd have said as much already.)
It is completely impossible to construe this as fact with a straight face. Making various and sundry claims about their motivations is FUD, and claiming that this is an objective, verifiable fact is impossible for me to perceive as good faith. It is a fact that some companies that do not like Redis's new license have started backing Valkey: that is a fact, that's verifiable. You could say it's probable that they prefer a license that lets them continue business as usual, or that they are making a conservative move to the fork that has not changed licenses yet. If you said that, I'd agree that it was probable, though not a fact. Several steps past this, declaring that it's because Valkey (who seem to have expressed some openness about changing licenses to something more free in this thread) wants all of us crushed under the corporate boot is neither a fact nor probable, but FUD. Speculating about their motivations is absolutely an ad hominem, and antagonizing them instead of asking is indicative of of nothing good. I could drop the qualifiers on this kind of speculation and start insisting things I say about your motivations are value-neutral statements of fact, but it seems extremely unhelpful to do so. It seems like a better idea to figure out common ground: there might not need to be so many forks. That'd be a much better outcome for everyone, but it's impossible to get to that outcome while you're antagonizing them and producing these "facts". (If I'm composing a wish list, I'd prefer whichever fork drops the line-editor and builds cleanly on Plan 9, but I'm fairly certain I'm in a small enough minority that I'd have to do the latter myself. On the other hand, I suspect that more people would agree that one fork would be more manageable than N forks that all hate each other--some of which have introduced intentional breaks in compatibility--and probably that LGPL would be a preferable license.) |
I could summarize this in a single word |
Read more about the license change here: Redis Adopts Dual Source-Available Licensing
Live long and prosper 🖖