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. |
|
👎 |
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 |
|
rip |
|
Oh, so Elastic admits it was a mistake after all... who would've guessed? 😏 |
|
Damage is done. If there's one thing that is hard to regain is trust. I have already moved on to |
That is neither what we said nor as simple as something being right or wrong — it's much more actions and reactions. https://www.infoworld.com/article/3499400/elastics-return-to-open-source.html has a more nuanced take from someone who was at AWS when the OpenSearch fork happened — if you're actually interested. It also touches on Redis and Valkey. PS: Having been involved in one relicense and following others closely, it's interesting how the context is still so different in each. |
Thanks for the link. Like with Redis, the trust issue goes beyond resolving trademark disputes with AWS. |
|
I think that comes back to the different context to some degree: For Elastic >95% of the code came from Elastic employees and while open for collaboration, it was never an open governance (and that's also a separate topic than open source licensing). |
I would be really pissed off. Crossed fingers, you will solve this and get your rights. And I wish Redis happy rebasing. |
The BSD license is what lets them do this. Since anyone can use such code in projects licensed differently, they can use these contributions in a proprietary library. Yes, they still have to obey the license terms (i.e. keep the original license text around[0]) and everyone can still use those files using the old license[2]. But the new changes copyrighted by Redis Ltd. are not BSD-licensed. If you don't like it, you should look into share-alike (aka copyleft) licenses like the GPL or the MPL. 0: They do. See the file |
Yup, but those BSD-3 parts of code should be marked as BSD-3. Only the new code is under the new license. Except for the code where the authors explicitly allowed relicensing (not sure about this part). 725 contributors, I bet they didn't ask a single one about the relicensing. And just deleted their licence under which they published their work. |
Do they? I don't see any such clauses in the license. It does mandate that both the license and any copyright notices have to be retained when distributed in source form, so I guess one could argue that it has to be within the same file. But that's not really stated so we can only know if a court rules one way or the other. But even if they had to keep it in all those files, they could simply prepend something like this to each one and call it a day. They definitely do not have to keep their new proprietary code in separate files. That's what the Mozilla Public License had to be created for.
They are sub-licensing that code. It's a general consensus that you can sub-license permissively-licensed code under any license you want. |
Read more about the license change here: Redis Adopts Dual Source-Available Licensing
Live long and prosper 🖖