1. 151
    1. 68

      “Redis remains a proponent of the open source philosophy and maintains a large number of open source projects.”

      … just not, well, Redis itself. What a crock. “Open-washing” yet again.

      1. 17

        SSPL is AGPL but also requires to release source of the surrounding software (e.g. admin panels, backups, APIs, monitoring, etc.) to the extent that users could run their own instance if they wanted. Just saying.

        1. 21

          SSPL is not recognized as a free/libre (nor as open source) license by anyone that matters. So the original comment is spot on.

          1. 18

            Recognition is a formalism. SSPL very much follows the philosophy, I don’t think anyone can honestly deny that. And Redis will integrate and release currently proprietary bits under both licenses. So it doesn’t look like spot on to me.

            1. 38

              The way to tell a license written in good faith from a fake poison pill used as a marketing tactic for proprietary software is to see if anyone is willing to accept contributions under said license and comply with it themselves. Everyone publishing code under SSPL requires contributors to sign a CLA offering it to the company under another license such that they alone can sell it as proprietary software. There are notable examples of AGPL projects that accept contributions without a CLA where everyone including the primary copyright holder have follow the AGPL, but SSPL seems to always be part of a dual-licensing scheme.

              1. 4

                golang has similar CLA

                1. 20

                  And to be fair: golang has been widely criticized for this AND the main reason it can ignore that criticism is because it has one of the largest software engineering organizations (and an impressive money printing machine) backing it.

                  Redis probably doesn’t.

                  1. 5

                    I don’t remember the widely criticism of golang. Any pointers?

                    1. -1

                      I can’t help but notice my comment has 20 upvotes and yours has five, if you’d like to get a sense of the ratios of folks who would criticize golang for this.

                      CLAs are in general widely critiqued and there are as many reasons to dislike them as there are entities demanding them.

              2. 1

                I don’t believe I currently have any professional relationships with companies stewarding projects under SSPL. But I wouldn’t be surprised to learn those companies approve use of each other’s SSPL-licensed projects for their primary use cases—say, Elastic NV using Mongo for an internal dashboard, or Mongo using Elasticsearch for their website—much as other users have.

                On the project front, requiring CLAs and also licensing under proprietary terms doesn’t make an open-licensed project closed. Nobody who isn’t a customer has to care what the paid license terms for customers say, just what the free license terms say, and whether they allow what they want to do. I don’t follow arguments that SSPL isn’t “free” or “open” because of things SSPL the license doesn’t say or do. Why impugn motives to authors when you can just read the text?

                Meanwhile, as I saw it, the major user base of AGPL was, for years, predominantly startup companies. I don’t think writing a license that ended up getting used for dual licensing makes the FSF guilty of self-sabotage, any more than I think writing a license intending to dual license means the license can’t be an earnest attempt at open. I read Mongo’s reasoning behind the SSPL—their longer e-mails to the OSI’s accursed license-review list are worthwhile—and the intent made earnest sense to me. It was implementation and presentation that drove my face into my palm.

            2. 25

              Not being recognized by neither the OSI, nor the FSF, nor RedHat, nor Debian, nor anyone else that matters means that it makes no difference whether it follows the spirit of open source (hint: it does not, section 13 of the SSPL directly and very deliberately contradicts the 6th criteria of open source), because it is practically not an open source license.

              You can’t say you follow the open source philosophy while your license deliberately contradicts a core criteria of it. Not even if the rest of the license would be in spirit, you have to treat it as a whole.

              1. 10

                You’re making excellent point that Open Source, as defined is open for exploitation and is unwilling to do anything to address it. Or as ~academician points out is actively rejects any action in that direction.

                1. 8

                  This is like saying that water is unwilling to address the problem that it’s wet when people want it to be dry. The entire point of OSS licenses is to define an equal playing field for every player. If some players want to use non-OSS licenses, they are free to do so. It’s a free market.

            3. 20

              It’s not just not recognized - it’s been outright rejected as “fauxpen source” by the OSI.

              1. 1

                Reading that announcement again, it strikes me that the substance of their argument is a picked quote from an Elastic blog post, not anything Mongo, which wrote the license, had to say, nor from the actual license terms.

                The SSPL doesn’t prohibit making the software available as a cloud service. It requires that when you do, you share and license source code alike. Like the GPLs do, when you make GPL-licensed code available as an installed program.

        2. 7

          Personally, I reject the notion that AGPL is a FOSS license. It clearly violates the established software freedoms.

          1. 7

            In which way?

            1. 1

              Whenever you modify an AGPL code base, you have to either modify it in such a way as to make it able to self-serve its code, or you need to host the code somewhere, for an unspecified amount of time. This seems incompatible with the freedom to change and tinker with code however you please.

          2. 2

            ‘Reality is that which, when you reject it, does not go away.’

        3. 4

          Probably with exactly enough ambiguity that every lawyer won’t allow its use.

          Example: https://opensource.google/documentation/reference/using/agpl-policy

          1. 5

            I’m a lawyer, and I’ve approved AGPL projects for use by clients. I know colleagues who’ve approved it, too.

            It’s almost always assessed use case by use case, rather than by blanket policy, because of the unfortunate way it was written.

    2. 51

      Isn’t Redis already completed as a software project? It seems like an open source community could maintain a fork of Redis from before this license change, and easily maintain it by doing almost nothing for decades to come.

      What’s the value-add to the software project itself provided by Redis Labs?

      1. 11

        I came to the same conclusion. Native TLS support was the last big ticket item, so I can’t really see what new functionality is required now.

      2. 8

        Follow-up: looks like Drew DeVault is taking this task on: https://codeberg.org/redict/redict

      3. 7

        It’s the old story that “enterprises” need a throat to choke when something goes wrong. Even if its “feature” is complete from a technology side, companies still need to know they have access to the company behind it. (especially with how deep Redis is in some ecosystems.)

        Someone will fork it, OpenTofu and OpenBao happened, Open(whatever Redis can be nicknamed) can’t be too far off.

        1. 4

          Also, there’s protocol-compatible competitors. Like https://github.com/microsoft/garnet and https://www.dragonflydb.io/

          1. 8

            When Garnet was announced just a couple of days ago, I saw comments on HN about how they were definitely going to stick with Redis because they didn’t trust Microsoft to keep Garnet open.

            1. 4

              Truely amazing how a handful of hours can change the landscape of our industry.

          2. 2

            Dragonfly is not OSS, so it’s kinda ironic to bring it up now.

        2. 2

          Aren’t these sort of places likely to be using an “enterprise” or “supported” linux anyway (for the same reasons), and thus just get the packaged Redis that is included in the distro repo?

    3. 49

      From the Q+A in the announcement:

      Third, changing the license term to protect one’s brand and IP has become a natural part of the evolution of many open source projects in order for commercial entities which back those technologies to survive and thrive as businesses.

      This is a fascinating assertion. It is always provocative to say something is “natural”. In this particular case it seems to me to be trying to suggest that replacing permissive licenses with source-available licenses just makes sense for a mature business as using a permissive license made sense for a new business. Or, you know, for a non-business or pre-business project made by some person who doesn’t work there anymore.

      I suspect that this is wrong in a couple of ways. Businesses relicensing their core product well after they gave away the farm to the cloud hyperscalers don’t overtly seem to get much out of this move other than cranky posts and public forks generously sponsored by Amazon. And I’d rather be an infrastructure-type business that launches with a permissive-enough source-available core than one trying to get my lunch money back from Andy Jassy. This might well be wrong; idk if anyone has yet made a thing that everyone needs, put a profit-monopolizing source-available license on it, and achieved both virality and financial success, but I think someone could.

      In any event it is starting to feel like permissively-licensed software maintained by robust staffs at startup companies was a purely zero-interest-rates, VC-financed phenomenon.

      1. 10

        In any event it is starting to feel like permissively-licensed software maintained by robust staffs at startup companies was a purely zero-interest-rates, VC-financed phenomenon.

        …. maybe? We’ll see how Sourcehut pans out. I’m optimistic there, at least.

      2. 10

        Businesses relicensing their core product well after they gave away the farm to the cloud hyperscalers don’t overtly seem to get much out of this move other than cranky posts and public forks generously sponsored by Amazon

        Indeed. It seems super unlikely this generate much in the way of extra business for them

      3. 9

        In any event it is starting to feel like permissively-licensed software maintained by robust staffs at startup companies was a purely zero-interest-rates, VC-financed phenomenon.

        I disagree with that, I know quite a few companies that make a good business on an open source stack. They are all not VC financed.

        The calculation here is:

        • Redis is estimated at 2 billion $ value
        • It reportedly has a received 380 million $ of investment
        • That’s 5.5x, not 10x

        They are even top of the class in that environment, if this source is too be trusted.1

        Redis is not doing bad by quite some measures. What they are trying to do is here is frame hardship and “natural evolution” to become more billionaire.

        They can license their product any way they want from my perspective. But I’m very careful to see billion dollar companies trying to argue themselves as “this is just how it goes”.

        1. 2

          Oh I don’t mean that the associated businesses are necessarily going to fail. More that investors getting anxious about an exit in the current financial landscape are going to lean on levers like relicensing in an attempt to boost revenue, now that revenue is a thing they suddenly care about.

      4. 3

        In any event it is starting to feel like permissively-licensed software maintained by robust staffs at startup companies was a purely zero-interest-rates, VC-financed phenomenon.

        while it’s still technically open-source, Element’s relicensing of matrix-synapse to AGPL comes to mind

      5. 2

        Good quote call-out. I read the post, but ran out of time for FAQs.

        I agree that “natural” smacks of self-soothing. “We’re OK. It’s perfectly natural.” Ditto all the defensiveness about “believing in open”, which I’d rather just see left out, even where true.

        As for having more fun at the scrappy upstart stage, licensing permissive, I wouldn’t miss the fact that not just investors of all kinds, including the dread VCs, but also potential employees, cofounders, suppliers, and everyone in the biz are also seeing these “Amazon v. upstart” stories. I’d expect an effect availability of resources of many kinds to new projects and companies in the genre. There’s a lag, but when the conveyor belt to the money breaks down, things can pile up at the start.

        You mentioned viral source-available winners. I can highly recommend Richard Moss’ book Shareware Heroes, published about a year ago, to basically anyone interested in software and Internet business history. There was a link going around a few days ago to an old vid of Brand and Wozniak talking IP and companies. I saw a lot of comments chortling in recognition of Brand’s “wants to free / wants to be expensive” bars, but not much for the names he dropped as part of his answer.

    4. 30

      You remember when Redis Lab changed their module license to a proprietary license, the community was disappointed. Some were saying “it’s only the begining.” Redis Lab kept saying “no, no, it’s just for the modules developed by the company ‘Redis Labs’, this not for the Redis software itself, Redis will always be free”

      I’m pretty sure these people have now migrated to memcached, and are now eating popcorn when seeing the drama. :)

    5. 15

      Becoming more downstream agnostic, removing e.g. example systemd or upstart services

      Seems like an odd change to me, I don’t see why having example service files around is necessarily a bad thing. (Maybe it’s because Redis’ invocation is so simple?)

      1. 5

        Yeah that one seems odd for things like capabilities for instance. Who’s more aware of the category of syscalls used by its application than the developers?

      2. 6

        Drew DeVault loves removing functionality from things even if people like it, usually because the thing is so simple it didn’t need that functionality, or if there’s a simpler alternative to having that functionality. For all his flaws he’s written some good work on this subject, but he does take it too far (see Hare). Most people just want to type <install> redis and subsequently use redis, though, so I hope it doesn’t catch on.

    6. 13

      I say “semi-open” to avoid injecting too much opinion into the headline, but one of the dual licenses is confusing and appears to bar distribution and forking, which to me is a closed source license if that’s true.

      1. 22

        I agree, & I’d support a re-wording to “proprietary”, which seems like just a statement of fact.

        1. 11

          You have convinced me and I have changed it.

    7. 9

      I hope this one succeeds! What struck me is that Drew put the thing on Codeberg and not SourceHut. I assume the reason for this is that Codeberg is more familiar / GitHub like, but I have to call out Drew’s commitment to “the right way” even though growing SourceHut is in his (financial) best interests. Truly a fascinating person that I am glad exists in this world.

      (Yes, I am aware the Drew doesn’t seem to be motivated by money… but I still assume SourceHut pays his bills)

      1. 2

        I assumed it was because Codeberg is run by a non-profit, whereas Sourcehut is a business. Which speaks even more highly of his motivations.

        1. 1

          He mentioned the non-profit status in his post, so, yes. That definitely played a factor in why CodeBerg and not GitHub.

    8. 9

      Can someone explain what’s the exact problem with SSPL? I’m certainly not a lawyer but after reading the summary of this license on Wikipedia it sounds very much in the spirit of free software, even more so than AGPL.

      1. 6

        Section 13, “Offering the Program as a Service”, which restricts a very specific use of the software, while the open source definition requires the software to be used for any purpose whatsoever, and as such goes directly against the 6th criteria of the Open Source Definition.

        1. 13

          I don’t think I agree with you. Section 13 doesn’t say you can’t offer the program as a service. It just requires you to release the source code to the entire service, and defines that:

          “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

          This is very similar to what the AGPL did; it took the GPL and expanded the definition of “distribution” (which is what triggers the need to release source) to include the act of providing access over a network. FSF/OSI/etc. consider the AGPL to be a “free software” license.

          This SSPL section 13 now seems to be taking the AGPL and expanding the definition of “derived work” to cover all the software needed to offer the service in question when that expanded definition of “distribution” is invoked.

          You may have a reasonable argument that it goes against the 9th criterion of the OSD, but I don’t think I see how it runs afoul of the 6th.

          1. 5

            People started citing the no-discrimination line against GPLv2 at least as early as when OSI ripped the example licenses section off the bottom of the Debian Free Software Guidelines and made it what became the OSI-approved list. I would not be surprised if it started earlier, within Debian, but alas, many of those lists were never public in the first place.

            GPL kicked off what’s now called “open licensing”. RMS had GPL written precisely to discriminate against proprietary developers and development. It has never behooved any relevant institution to express this succinctly in writing.

            I’d strongly encourage you not to waste more time pondering the Open Source Definition like a technical document. It’s not—not in an engineering sense, and not in any legal one—much less any kind of deeper revelation. Debian doesn’t claim that DFSG works that way, and it’s basically the same document in all the most troublesome parts.

            Functionally, the importance of the glitteriest OSD generalities—the nondiscrimination criteria—is that they remain available to be cited with implied authoritativeness by anyone against any license they oppose. If it’s not good for them, that’s discrimination, and therefore can’t be open.

            There is no formal or tacit process within OSI to enforce any consistent reading—more recently, they have explicitly rejected the idea of binding precedent or approval by analogy to past licenses—nor to contain interpretations of criteria like non-contamination (9), clearly born in and for the distro-on-CD scenario, but written in plain terms for people to read, and not to be parsed over like a statute, court order, or source code.

            It’s a trap. The definitional politics, and the way the OSD tries to frame them, are a burn pile for human potential. I watched many hours of my life crackle and pop over that flame to bring you this information.

            1. 3

              It’s a trap. The definitional politics, and the way the OSD tries to frame them, are a burn pile for human potential. I watched many hours of my life crackle and pop over that flame to bring you this information.

              Fair point. And if I’m honest, I consider the amount of time and energy we spend on minute details of just how we’re going to license a thing we intend to give away for free to be mostly wasted. Obviously, I both understand and am myself subject to that impulse. But on a certain level, it really feels like an unproductive distraction.

            2. 2

              I sympathise with most of what you’re saying, but how do you think “open source” / “free software” / whatever should be defined? Arguably some early free software licences were written purely as an unopinionated shortest route to getting something else done, but the GPL wasn’t, and I’d argue that after the GPL no software licence can claim to be politically neutral.

              So this is clearly (imv) a political issue, not a purely technical one, and I think that means we can expect the axioms to be a bit woolly at the best of times. But I really am curious how you’d improve the OSD.

              1. 1

                Neither “free” nor “open” should be defined that way. That’s assuming “free” and “open” are somehow the property of particular people or institutions with the power to declare a meaning and police use. Definitions of words that aren’t anybody’s proprietary IP describe how they are used, not prescribe how they can or should be. OSI can proclaim as loud as it wants that it bestows on itself supreme power and authority to say what “open source” means, but I didn’t vote for them and they have no power over me.

                Name another umbrella movement-cum-marketing term that’s equally broad, but technocratically controlled. They’re all fuzzy and contested: “green”, “organic”, “handmade”, “fair trade”, “carbon neutral”. Contrast certifications that speak for the orgs that control them, rather than pretending to speak on behalf of a whole movement: LEED certified, UL listed, “Blue Oak Certified”. OSI has “Open Source Initiative Approved License” as a trademark, but not “open source” alone.

                “Open” won the mindshare war, and people understand “open” quite well for themselves, through experience. Very few have or will ever read OSD or DFSG or any number of other definitions that have been published, nor should they have to. I’d improve the OSD by identifying it accurately as a rebranded manifesto published to promote OSI when it was founded, and ceasing to pretend it’s a technical standard, a legal definition, or otherwise still important.

                Ditto the “Free Software Definition”. We got that, best I can tell, because RMS got jealous of the attention ESR was getting for Peren’s rebranded guidelines, leading him to cobble one together one of his own.

                1. 3

                  OSD is not important because of technical or legal reasons. It’s important because at least they made the effort to define something, to set out some criteria. Notice that everyone who disagrees with OSD defines themselves in opposition to OSD and never actually provide their own useful definition. Or they define a playing field that is inherently anti-competitive. OSS is the great competition playing field equalizer.

                  1. 1

                    Nobody has to agree that “open” should be defined prescriptively, instead of descriptively, like the rest of the common English language. Much less that it should be controlled by OSI in particular, just because they made some effort twenty years ago. There isn’t any such “definition” for other terms that matter in software, and we get along. Parallel concepts like “shareware”, “freeware”, “demoware”, and so on were all fluidly understood, often contested.

                    People who’ve agreed that defining “open source” could be useful have absolutely offered alternative definitions. Larry Rosen, who was for a long time OSI’s lawyer, offered a much shorter one in his book, years ago. Others have defined it as simply software under a very short list of specific licenses. Is anyone with a different definition “in opposition to OSD”, just because their definition isn’t OSD? Is Debian, for continuing to use the Free Software Guidelines?

                    I’d strongly encourage you to reexamine whether open source inevitably levels playing fields. Many very large companies make enormous “contributions” that nobody else could afford precisely to distort markets in their favor. For a recent example, consider TensorFlow. That release let many more players onto the machine learning field, but that field is intentionally tilted toward Google, their infra, and even their hardware, in the form of TPUs. Meanwhile, we’re seeing companies like Redis move away from permissive licenses in large part because lack of restrictions along the licensing axis lets those with advantages in other dimensions—like dominating positions in cloud services, or control of app stores—better leverage those advantages over smaller players.

                    It’s tempting to see free/open/good versus closed/proprietary/evil as the whole story of software, and in pure black and white. But software reality is a whole lot more complex than that. Open licenses, infrastructure, and practices are just a few components of a much larger system.

                    1. 1

                      Larry Rosen, who was for a long time OSI’s lawyer, offered a much shorter one in his book, years ago

                      OK, what is it?

                      Others have defined it as simply software under a very short list of specific licenses.

                      Great, but that’s a definition by fiat. What justifies those specific licenses? At least OSI’s definition attempts to answer this question.

                      Is Debian, for continuing to use the Free Software Guidelines?

                      Debian Free Software Guidelines don’t claim to provide a definition for Open Source.

                      No license, open source or proprietary, can guarantee equal outcomes in a competition with deep-pocketed market players. Using this in an argument about OSS licensing is simply ignoring reality. That’s not how the world works. All OSS licenses do is guarantee a fair playing field to use the projects that they control. They don’t claim to and never could guarantee anything else.

    9. 9

      I think this is the inevitable direction for all corporate-built, server-side software. They all have to find a way to make a profit even while the cloud providers are way more successful at monetizing their work.

      1. 2

        But this wasn’t “corporate built”. It was corporate bought.

        Also relevant: AWS had a paid staff engineer on the Redis core contributor team when it was BSD3 licensed.

        1. 1

          Fair point. “Corporate owned” may be a better term. Please note that I didn’t say it was right, just that it seems inevitable.

          1. 1

            It’s only “inevitable” if people sell out the projects they control to corporate interests.

            Both Redis and HashiCorp have taken a similar route, after the original founder stepped away; I don’t think this is a coincidence.

    10. 8

      I’m quite curious to see how this type of change will affect the distro packaged versions.

      With the recent-ish addition of native TLS support, Redis feels like a project that could quite easily be considered “finished”, IMO (barring security updates), and thus I see no issue with e.g. Debian eventually catching up to 7.3 or whatever the last BSD version is, and then just maintaining that as-is.

      Will the upstream version add new features over time? I’m sure they will. Will those new features actually be needed by 99% of users? I doubt it.

      1. 4

        imo distros will probably stop packaging redis, just like they don’t package mongodb. debian might stick to a sane version for a while, but it’ll be probably be dropped from their repositories because of the licence.

        1. 1

          The change of licence doesn’t prevent them from keeping any version up to it, and as discussed in several threads (here and on the orange site) Redis, for probably 90%+ of users, is feature complete, it’s “done”, barring bug/security patches.

          It’s not like keeping it at v7.2.whatever is going to cause some massive issue because the upstream version has some fundamental ground breaking new feature - with the exception of adding native TLS several years ago, Redis hasn’t gained much in the way of really useful new features for quite a while.

    11. 7

      I wonder if antirez sold his copyright to Redis Ltd. There’s a whole lot of copyright reassignment in their relicensing diff. There are also other copyright holders who aren’t associated with Redis Ltd whose code is being relicensed. It’s a good reminder that if you publish code under a permissive license copyright assignment is meaningless.

      1. 2

        … if you publish code under a permissive license copyright assignment is meaningless.

        I don’t understand. Would you mind elaborating?

        1. 3

          The redis copyrights aren’t just held by Redis Ltd but they can relicense it anyway. They didn’t need anyone to assign copyright to do that.

          1. 1

            Maybe I’m missing something. How can you change the license on code you don’t own?

            1. 3

              If I write some code and publish it under a license that says you can do whatever you want so long as you leave my copyright in the source code then you can take that code and distribute it under any terms, provided you leave the copyright in the source code. This is how Microsoft got BSD sockets in Windows - I’m sure the Berkeley copyrights are still in the relevant parts of Windows source.

            2. 1

              Right. It’s really an annoucement that their updates will be under a new license. But that matters.

              1. 1

                The current code is also available under the new license. The current code also still available under a BSD license.

        2. 1

          Basically the previous version can be used under the new license forever. So unless the new versions are substantially useful people can just ignore them and use the old stuff.

    12. 5

      So we can just find a group of capable contributors, and fork Redis just below the commit with updated license?

      Call it Fredis, CacheRevolt, or something. Then fund them with $1mm and legally obligate to make it MIT (as long as not GPL or proprietary).

      I’m sure you can get some companies that really rely on Redis and would prefer a pure open source version to consider throwing in if you included their devs in the governance, then outpace Redis itself. Just need the initial sponsor to get it going.

      1. 26

        as long as not GPL

        Why not? That would actually prevent this from happening again.

        1. 3

          The SSPLv1 option appears to be a variant of GPL.

          1. 4

            GPL may have its place, but for many cases copyleft discourages companies from adopting and contributing to a project, especially a new non-entrenched one like a serious fork of Redis.

            1. 13

              It’s irrational, though.

              When it’s separated by network, internally deployed GPL component does nothing problematic license-wise. It behaves like Apache or MPL licensed code.

              Even AGPL works like that.

              You would have to ship it in an integrated solution to a 3rd party to be forced to accommodate for its terms.

              1. 4

                yes but you have to understand: lawyers at companies have very little time for nuance. they need easy, thick lines for “okay” or “not okay”. “it’s gpl, therefore not okay” is about all they have time for in the vast majority of orgs.

                1. 8

                  Are you sure? I’ve met people at Grafana Labs events, in some cases from pretty huge companies, who use all the Grafana AGPL software under AGPL. We have advice from our own lawyers about it that I can’t quote verbatim but boils down to “don’t make it part of our proprietary product”—which I think aligns pretty much exactly with what the people who chose AGPL wanted.

                2. 8

                  These companies don’t use Linux? No one back in the day used MySQL? Let’s not kid ourselves that places are so scared of GPL that they won’t even run a service with GPL’d code in it. This isn’t a library or dependency.

                  1. 3

                    Linux and some other entrenched are an exception, but it is avoid as dependency if it’s part of product. And its a pain and process at many companies if you bring in gpl into the stack, in general, and has to get review by execs and legal. Corporate law firms regularly defend clients against gpl infringement. One GPL dependency, as I was told by a law firm partner on the way to defend a client against a gpl case, poisons the whole software chain. Don’t kid yourself, GPL is the plague to most companies as dependency and library software. Many others, reach for FreeBSD or others with permissive licenses if they’re developing and packaging an OS.

                    1. 3

                      Again, we’re explicitly not talking about a dependency, but a service. The source code is not even going to enter into it, just running the binary on a server somewhere, so no mixing with product code can possibly occur, even by accident. This is why things like MySQL are accepted so widely by places that might otherwise fear GPL as you say.

                      1. 1

                        I think you make a fair point, actually. And I’m not anti-gpl. I’m for a path forward forward for permissively licensed software (libraries, and server-side). If GPL works for your project. Good. Right now, the permissive license ecosystem is crumbling. We have to at least try to avert, and maybe do better. And the GPL movement hasn’t stopped this from happening. These dual-licenses adopt GPL ideas, but then pervert it.

                        The reality right now is that companies that started with permissive licenses for projects or actually moving to dual-licenses, like Redis. They can patent their technology, and if you sue them for infringing patents, or vice versa, you lose the license. And they can revoke your license, regardless, along with a bunch of other restrictions.

                        1. 1

                          It’s unsurprising that GPL doesn’t prevent the ‘crumbling’ if the GPL is not actually used.

                    2. 1

                      most companies

                      I’m dubious that we know anything about most companies. Especially since it’s an international issue.

                3. 4

                  Hmm… Sounds like most lawyers are completely our of their depth, have virtually no hands on experience with software development and thus do half assed job that actually costs their employer viable opportunities. The only reason why this is still going on is that they can very easily FUD around and shift the burden of proof on somebody else and thus have little to no incentive to actually learn to do a better job.

                  What I don’t understand is why it’s the developers who should always be the understanding ones.

                  Sorry for the rant. No need to react. :-)

                4. 4

                  lawyers at companies have very little time for nuance.

                  Have you ever actually conferred with a lawyer? All they deal with is nuance. Context is core to the legal system, it’s why we have 3rd degree manslaughter vs 1st degree murder, etc.

          2. 2

            I don’t see what that has to do with using or not using GPL, which is a strong copyleft OSS license. SSPL is not OSS. Are you equating projects like Linux, which use GPL, to projects which use SSPL?

        2. [Comment removed by author]

      2. 3

        you can fork redis. good luck without core contributors

        1. 4

          Redis has quite some mindshare outside of redis.

          1. 1

            My gesture below stands for any other critical projects that are dual-licensed or under-risk. Get such contributors in front of VCs, Angels and CTOs with real capital who are passionate about keeping open source open and I chat regularly with them about it. People are fed up.

        2. 4

          Plenty of contributors leave a project or join other ones (see other forks Vim –> Neovim, or even Redis, like KeyDB snaped up by Snap).

          For others, who’d rather beat these “dual-source” startups at their own game: any contributors (just 2 or 3) with viable skills for such a fork and forms a C-Corp in Delaware that adopts Bylaws (MIT license, guarantee) in spirit of CacheRevolt, I can contribute up to $20k for legal and help float their payroll for a bit until they land a $1mm SAFE investment. DM me, folks.

        3. 4

          I think your take is correct, but for maybe a different reason than you intended.

          The reason you don’t see even more Redis forks is that many people in the world of distributed systems and databases do not think very much of Redis’s design decisions. What you need to fork and maintain Redis is people who care about a Redis-shaped thing with Redis’s exact properties.

          Many people do in fact work on things that could easily replace Redis, and some even speak Redis’s protocol. These things often have superior operational characteristics, competitive performance, and better reliability guarantees.

          1. 1

            Don’t doubt that. But Redis remains upstream, which helps downstream drop-in replacements. Upstream makes your life easier, as others offer up and cooperate with feature changes, as they prefer to have them upstream if possible. Redis defines the protocol, which unifies the ecosystem to my understanding. The dual-license really is going to make downstream players, even if superior in some areas, a bit nervous (or should). Add risks to fragmentation, and a move away from the protocol by alternatives. Redis can patent tech. And if there is any lawsuit over it, there goes your license, and host of other risk and limitations. The dual-license permits this. Correct me where I’m wrong, but the simple, good old Redis (such as a fork), could be widely adopted by a lot of people who just use Redis. Thus keeping stable the protocol and the ecosystem of drop-in-replacements.

    13. 5

      Now let us never forget the broken promise of Redis remaining under “open source, BSD license.”

      https://web.archive.org/web/20240322135735/https://news.ycombinator.com/item?id=17819392

    14. 5

      These claim to be drop-in replacements:

      1. 12

        The former is owned by Snapchat (inexplicably not bankrupt) and the latter is owned by a VC-backed startup.

      2. 6

        Dragonfly Business Source License

        Not really seeing how that is an improvement over Redis?

    15. 3

      Like many of you, I was disappointed when I learned that Redis®1 was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one.

      But why? This is stated as if this is some uncontroversial, obvious thing. Redis has committed “an evil”. And yet I see no problem at all, and I actually have no clue why this copy left fork would be superior.

      and we do not see any reason to discourage cloud providers from making use of Redict.

      lol well yeah, of course you don’t, you didn’t pay for the first decade of Redis to be built, you don’t have a business built on it. What happens when you need to pay people?

      Redict will function as a drop-in replacement for Redis® OSS 7.2.4,

      Right, and presumably no further, as obviously the two projects will diverge. Who’s going to maintain compatibility? Will they break completely? Will they strive for compatibility?

      This all makes sense, I’m sure, if you believe that a very specific way of distributing software is good and that any divergence from that way is bad, but I don’t know why people believe that or seemingly believe that this shouldn’t be controversial, as it was very controversial up until very recently when “open source” started to mean one very very specific set of rules.

    16. 2

      Ddvault explains why Redict is hosted on Codeberg (instead of the more obvious choices, GitHub or SourceHut).

      This is a traumatic moment for the Redis community, but also for the free software community. This has happened too many times: MongoDB, ElasticSearch, now Redis, and many other projects, hell, even Solaris, and many projects with commercial stewards are transparently keeping the same strategy in their back pocket with CLAs and copyright assignments from contributors. We could just repeat history, gather the diaspora, and try to rally behind a hastily made fork, throw it up on GitHub, BSD license it, get the commercial interests on board, and press on like everything is normal. But, I think that this is an important moment to question our values, and how we ended up here, and what kind of changes we need to make to curtail this trend.

      (yes, there’s more!)

    17. 2

      Drew should drop a donations link on Redict’s page for everyone. Maybe to help hire some full-time core contributors who are capable enough or have worked on Redis-like projects?

      I don’t agree with GPL, I support permissive licenses, but I get where they’re coming from and want Redict to succeed. It’s still on the good side, unlike dual-licenses IMO.

      Better yet, if he sets up a real entity with clear governance over the project, count me in for sponsorship. Hope he considers some aspects of CacheRevolt Bylaws, even if it’s copyleft.

      My offer still stands for a capable group that forms an org and adopts the spirit of CacheRevolt Bylaws w/an MIT or other suitable permissive license for an open Redis fork - $20k. First come, first served, expires in 30 days. I’ll consider other projects too, no time limit.

      1. 7

        I like how it pushes for Attribution-Based Economics. ABE would go someways to ameliorating the fact that contributors are being screwed out of compensation for their work when a project closes off.

        Still, we’re paying the consequences of the Free Software movement using non-economic criteria from the beginning, as Perens’s slides concede. The AGPL has failed, and we’re going to see situations like Redis recur over and over when unicorns get all the economic benefit of OSS’s free labor.

        We’re so hyper-focused on the rules and narrow freedoms of FOSS licenses, we keep ignoring how they enable exploiting free labor for the likes of Amazon. If that’s a consequence of FOSS licenses, it’s a situation to be fixed, not tolerated, imo.

        1. 1

          The problem with ABE is that it seems impossible to implement in practice. Software is a global effort, but a global financial entity to implement these things is pretty unimaginable in the current geopolitics.

          The best sort of value we’ve seen handed back to projects is source code and active project effort. It allows the freest form of value transfer over the largest number of geopolitical environments. ABE does not reflect this reality very well.

          And, I will note that every could force Amazon, Microsoft, Google, Vercel and others to contribute back by just agreeing the AGPL is a baseline standard.

      2. 3

        One challenging aspect of this topic is the insistence that the real aggrieved parties are the people (like Bruce Perens) hoping that licenses will continue to extract massive value from the open source software community without actually having to give back anything other than pennies to people who contribute via specific vectors.

        If we were to scale the ABE approach out to its logical conclusion, it’d destroy not only the corporate software world as it exists (which is maybe good, or maybe bad, I’ll leave you to judge) but also most of entire free-as-in-gratis world as well. The net result would be only the largest economic actors are permitted to produce any software at all.

      3. 2

        Bruce Perens is one of the architects of this pseudo-free sewer we’re trawling through, along with his crony Eric S. “Bathrobe” Raymond. They tried to form a licensing cartel by founding OSI but couldn’t get the trademark for “Open Source”. The only thing that should come after Bruce Perens is an angry mob with torches, pitchforks etc.

        1. 1

          Eric S. “Bathrobe” Raymond

          Ya’ can’t drop that without linking some context, please!

          1. 4

            https://twitter.com/mjg59/status/1382859041941057537

            Years ago I got told a story about how at some Sci Fi convention there was going to be a party in someone’s room and RMS thought it would be hilarious to tell ESR that it was going to be an orgy and so ESR turned up wearing nothing but a bathrobe

            1. 14

              This is a funny prank on RMS’s part, but there’s nothing inherently wrong with participating in an orgy at a sci-fi convention and I dislike seeing this anecdote used as a way to imply that he is disreputable.

            2. 9

              I am not a fan of either of those people but if someone invites me to an orgy I am going to dress for an orgy.