Redis 再次开源

图0:Redis 再次开源

五个月前,我重新加入 Redis,并很快开始与同事们讨论转用 AGPL 许可证的可能性,却发现公司内部已经在进行讨论,而且是非常老的讨论。公司内部很多人都认为 AGPL 许可证比 SSPL 许可证更好,虽然最终 Redis 转用了 SSPL 许可证,但内部讨论仍在继续。

我试图给支持 AGPL 许可证的一方更多力量。我的感觉是,SSPL 在实际应用中未能被社区接受。OSI 不会接受它,软件社区也不会把 SSPL 视为开放许可证。没过多久,我就看到这个假设在公司的各个层面上得到了越来越多的支持。

老实说,我真的很希望我为新的向量集数据类型编写的代码能以开放源码许可证的形式发布。编写开源软件在我心里根深蒂固: 在我的职业生涯中,我很少写别的东西。我太老了,现在还不能开始。这可能有些幼稚,但我之所以满怀激情地编写 Vector Sets,正是因为我知道 Redis(以及我的新工作)将再次开源。

元素周期表

我知道,我们工作的核心是改进 Redis,继续构建一个有用、简单、能随软件栈需求变化的好系统。然而,回归开源许可是这些努力与 Redis 项目保持一致、为用户群所接受,以及为比任何一家公司都要庞大的人类集体努力做出贡献的基础。因此,老实说,虽然我不能为许可证的转换邀功,但我希望我为此做出了一点贡献,因为今天我很高兴。我很高兴,Redis 在 AGPLv3 许可证的条款下,再次成为开源软件。

现在,是时候回到终端,写出我所能写出的最好的代码,向Redis用户表示敬意,让Vector Sets更有用、更实用:我还有一些改进的想法,希望你们的反馈能激发我更多的想法(这已经在发生了)。黑客技术不错!

附注:Redis 8(Redis 的第一个新许可证版本)也于今天发布,它具有许多新功能,并对核心进行了速度改进:https://redis.io/blog/redis-8-ga/

您还可以在这里找到 Redis CEO 的博文:https://redis.io/blog/agplv3/

本文文字及图片出自 Redis is open source again

阅读余下内容
 

《 “Redis 再次开源” 》 有 775 条评论

  1. 我曾在 Redis 的原始许可证下对其进行了微小的改进(但在我看来还是很不错的:p),但当他们宣布将许可证意外地更改为 SSPL 时,我个人就转而使用 redict 了–作为一个正式的自由和开源软件代码库的贡献者,我感觉自己被背叛了。(如果他们立即改用 AGPL,从道德角度讲,我完全可以接受这一变更,真的)。

    我非常尊重 antirez,认为他是 FOSS 社区中善良、仁慈的一员,但无论 Redis 公司宣布或做了什么,他们已经永远失去了我的信任,只要 Redis forks 还存在,我就会继续使用下去。

    • 是啊,我们刚刚经历了 Elastic [0] 的整个过程:公司把许可证从社区下面改掉,社区造反,公司放弃,又改回来。两家公司甚至都以同样的 “成功了 ”为借口(“虽然很痛苦,但成功了”,“这实现了我们的目标”)。

      两家公司都没有建立法律安全机制,以防止日后再次扯皮,而且两家公司都表明自己是不值得信赖的管理者。当事实证明社区的善意真的很重要时,他们又卑躬屈膝地回来了,但这绝对是 “愚弄我两次,我感到羞耻 ”的情况。

      [0] https://news.ycombinator.com/item?id=41394797

      • 我不知道 Redis 如何,但对于 Elastic 而言,我仍然为他们被亚马逊像布娃娃一样扔来扔去感到遗憾。原则上,我不会使用亚马逊的分叉,因为我不想支持一家宁愿分叉项目也不愿意出钱的公司。亚马逊非常愿意亏本卖给你他们的 Elasticsearch fork,只要他们最终能在 Elastic 不可避免地消亡时挽回损失。到那时,他们自然会放弃开源的分叉项目,以更慢的速度继续私有化开发,同时将 AWS 服务的价格翻倍。到那时,你别无选择,只能付钱,因为已经没有竞争对手了。

        • 如果不能分叉或出售托管集群,开源还有什么意义?

          同样来自 https://en.wikipedia.org/wiki/OpenSearch_(软件):

          > 2024 年 9 月 16 日,Linux 基金会和亚马逊网络服务公司宣布成立 OpenSearch 软件基金会。[15][16] OpenSearch 软件的所有权从亚马逊转移到 OpenSearch 软件基金会,该基金会作为 Linux 基金会的一个开放技术项目组织起来。

          OpenSearch 采用 Apache 许可证 2.0。你可以随心所欲地使用它。在你心目中,Elastic 是怎样的好人?

          • 亚马逊的产品命名和定位混乱,兼容性落后,这让 Elastic 很头疼。

            而且,他们使用的是开源软件,却在其基础上添加了封闭源代码的秘密调料。许可证规定他们必须开放自己的秘密酱汁,否则就得付钱,而他们的回应是离开谈判桌。

            OpenSearch 仍然缺乏 Elastisearch 的大量基本功能,而 Elasticsearch 作为一款产品能取得如此长足的进步,说明亚马逊获得了多少免费午餐……而当他们需要把钱花在刀刃上时,他们又是多么关心这款产品(尽管 AWS 每 4 天就会扣掉 Elastic 的年收入)。

            Elasticsearch 总体上已经成熟,就像它有一个充满激情和远见的构建者一样。他们在两条主要战线(LLM 和 Observability)上奋力推进,并在不影响产品质量的前提下有效执行。

            与此同时,OpenSearch 仍然是要求提供 3 年以上 ES 功能的申请单的夭折之地。

            老实说,我站在相反的立场上:提供劣质产品和封闭式扩展的超级分销商怎么就不是坏人呢?

            我想我并不是一个相信无限扩展规则的人:在单个规模上可行的东西,在超级分频器上就不一定行得通(比如销售托管集群)。

            • > 亚马逊的产品命名和定位混乱,兼容性滞后,这让 Elastic 非常头疼。

              无关紧要。

              Elastic 决定向公众发布软件,并授予天下所有人以他们认为合适的方式使用软件的权利。这也包括销售服务。

              这成为了他们商业模式的重要组成部分,因为这推动了软件的采用率和受欢迎程度。如果 Elastic 保留了 Elasticsearch 等专有技术,他们就很难获得同样的采用率。

              鱼与熊掌不可兼得。你认为为什么人们会在这些公司决定从他们的用户群中抽身的那一刻放弃这些项目?

              • > 鱼与熊掌不可兼得。

                我认为,反垄断法首先就应该防止 TooBigTech 陷入这种境地。

                问题不在于开放源代码许可证,而在于 TooBigTech 可以随时随地与竞争对手作对。

                • > 我认为反托拉斯法应该首先阻止 TooBigTech 公司处于这种地位。

                  无关紧要。如果你赋予天下所有人一项权利,你就不能追溯性地从你决定针对的人那里收回这些权利。

                  • 当然有关系。TooBigTech 正在扼杀小公司,就因为它太大了。

                    当出现这样的问题时(“我们做了一个成功的产品,但有人分叉了它,这要了我们的命”),“有人 ”通常是大科技公司,而不是车库里的三个学生。然后,人们就会抱怨开放源码行得通/行不通,却忘了根本问题是垄断者在坑害他们。

                    • > 当然有关系。

                      不,这无关紧要。试着想一想。你在许可证下发布了一个项目,授予每个人以他们认为合适的方式使用它的权利,包括在此基础上建立业务。每个人都开始以他们认为合适的方式使用该项目。

                      你认为你现在有权随心所欲地收回许可吗?

                      不,你没有。

                    • > 不,这无关紧要。

                      是的,有关系。

                      试着想一想:多个问题可以同时存在:

                      1. 1. 某公司使用许可协议,看到竞争对手用他们的基础知识制作专利产品,就开始抱怨。太糟糕了,他们从一开始就应该使用 Copyleft 许可证。

                      2. 某公司生产了一款不错的产品。TooBigTech 发现了这一点,并开发了一个替代产品(无论是分叉还是从头开始,我都不在乎)。TooBigTech 免费提供(因为他们可以,因为他们太大了)并占领市场。原来的小公司死了,因为他们无法免费提供自己的产品。现在,TooBigTech 公司又可以开始 “enshittifying ”了,因为他们又拥有了市场。

                      > 你认为你现在有权随心所欲地收回许可吗?

                      如果你拥有整个代码库的版权,当然可以。那些签署了 CLA 但现在却在抱怨的贡献者们应该好好想想这一点。

                    • > 无关紧要

                      我觉得这个词的意思和你想的不一样。

                    • 大公司利用自身规模进行竞争是资本主义的一个特点,而不是一个缺陷。

                      AWS 之所以能利用自己的源代码进行竞争,是因为他们一开始就开放了源代码。竞争是被明确邀请的。

                    • > 大公司利用自己的规模进行竞争是资本主义的一个特征,而不是一个错误。

                      这是更根本的问题。企业可以任意改变已经授予最终用户的许可条款,以此敲诈用户。

                      这并不局限于由随机云提供商提供的任何托管服务。其核心推理是,一家公司发现有最终用户从一项服务中获利,而这项服务直接或间接涉及到他们根据自由和开放源码软件许可向公众发布的项目。他们看到有人得到了报酬,就追溯性地修改条款,强迫他们付钱。他们针对 AWS 提供托管服务的论点同样适用于任何使用其项目的公司。这有什么意义呢?

                    • > 公司可以任意更改已经授予最终用户的许可条款,以此来敲诈他们。

                      如果贡献者拒绝签署 CLA,那么企业要么得不到贡献,要么就不能任意更改许可。如果贡献者对许可项目做出贡献并放弃版权,那也是贡献者的错。如果他们同意了,这算不算敲诈?

                      然后这些贡献者就会因为公司为所欲为而牢骚满腹。太糟了,别签 CLA。如果你不希望自己的代码最终成为专利产品,就不要为许可项目做贡献。

                    • > 大公司利用其规模优势进行竞争是资本主义的一个特征,而不是一个缺陷。

                      大公司利用其支配地位进行竞争不是资本主义的特征。反垄断法阻止了这种行为。只是美国无视这些法律。

                      > AWS 之所以能利用自己的源代码进行竞争,是因为他们一开始就开放了源代码。竞争是被明确邀请的。

                      这部分我同意:如果你建立了一个许可项目,当竞争对手将其用于自己的专有替代品时,你就不能抱怨了。

              • > Elastic 决定向公众发布软件,并授予天下所有人以他们认为合适的方式使用软件的权利。这也包括销售服务。

                最初的许可决定是在 Elastic 公司成立之前做出的。也许谢伊没有充分考虑到这一点。我对他不是很了解,但和大多数启动开源项目的开发者一样,我认为他没有法律背景。我承认自己有些天真,以为贡献者会遵守贡献精神,而不是许可证的绝对条文。我认为,社会期望高于法律要求也不是没有道理的。

                我从事开源工作已有 25 年,在我看来,公司对待开源的方式已经发生了明显的转变。我觉得我一开始的理想几乎是中规中矩的,而现在我只能为那些不想向任何人支付任何费用的公司提供免费的支持工作。我不认为开发人员认识到自己的错误或改变主意并相应更新许可证有什么问题。就我而言,我过去一直使用 ASLv2,现在则默认使用 AGPL。

                > 你不能两全其美。你觉得为什么这些公司一决定从用户群中撤出,人们就会放弃这些项目呢?

                就像你没有高于许可证规定的法律义务一样,他们也没有法律义务按照你想要的许可证提供他们的作品。这是开放源代码,所以你可以随意使用许可证变更前的版本。当然,如果有两个不兼容的版本,情况会更糟糕,但只要我们把自己限制在法律要求的范围内,这就不是问题。

                许可证变更后,这些项目被放弃的最明显原因是它们现在使用的许可证需要审查。要证明在新的 AWS 服务上的花费是合理的,比获得新许可证的批准要容易得多。但无论如何,这种情况或多或少都会发生。如果你已经在使用 AWS,那么添加一项新服务比支付第三方托管服务的费用要容易得多。我并不特别责怪 Elastic 不想成为亚马逊的研发部门和支持团队。

                我们有很多系统和基础架构之所以能正常运行,主要是因为双方都遵守了自己的协议。大型科技公司认为,他们可以打破这种局面,只遵守许可文本的规定,从而节省开支。从法律上讲,他们有这个权利,但其他各方的反应是可以预见的。我认为,这真正说明了我们的许可证并不适合所有情况。也许我可以接受市值小于 100 万美元的个人和公司在类似开源的条款下使用软件,但不想成为大公司转售我的软件的实际雇员。我们已经过了开源软件自由的阶段。

                大多数项目一开始都是开发人员在没有法律背景的情况下选择许可证,然后他们遇到了一个拥有大量内部法律顾问的 800 磅大猩猩。在我看来,指责他们没有考虑周全或没有意识到许可证选择的影响只会适得其反。好吧,他们犯了一个错误。现在怎么办?他们不想继续在他们觉得被占了便宜的框架下工作。我不认为他们有义务继续这样做,因为所有非亚马逊用户都不想承担分叉的麻烦。我更希望看到的是,比起那些多年来无偿奉献自己作品的人们,那些愿意打破幻想赚点外快的公司才是他们的目标。

                • > 最初的许可决定是在 Elastic 公司成立之前做出的。

                  是的,软件从一开始就是按照这些条款发布的。

                  任何公司都无权剥夺最终用户的这些权利,无论你的敲诈计划有多有利可图。

                    • > 你是说他们违法了吗?

                      不,他们没有。如果他们得到所有贡献者的同意,他们可以用其他许可证发布新版本。他们绝对不能从现有版本中删除 FLOSS 许可证。

                    • > 如果得到所有贡献者的同意,他们可以用其他许可证发布新版本。

                      贡献者必须签署贡献者许可协议 (CLA),才能合并贡献。CLA 的签署者在签署协议时赋予 Elastic 更改许可证等的权利。因此,Elastic 在更改项目许可证之前不需要得到每个贡献者的单独同意。代码并不是基于 Copyleft 许可的,因此也没有强制要求所有未来的发行版继续使用相同的许可条款。这也是许多 CLA 的动机之一。如果你的贡献发生在 CLA 引入之前,那么事情就会变得更加扑朔迷离。

              • > 与此无关。

                你一直在向所有回复你的人灌输这个观点:也许你的观点才是无关紧要的,因为这并没有阻止他们从一开始就拉开地毯?

                > 人们放弃这些项目的那一刻

                聒噪的人们总是宣称他们会放弃,而超级分销商们则兴高采烈地推销他们的分叉项目……与此同时,真正放弃的大多是超级分销商的客户,而这些客户本来就不是他们的目标。

                Elasticsearch 的源代码可用了 4 年之久,但仍有大规模增长。

                人们试图把 Redis 数据引擎排名下降说成是 Valkey 的功劳,但他们的趋势线似乎根本没有受到这一变化的影响:https://db-engines.com/en/ranking_trend/system/Redis。

                说得更直接一点,老实说,我对这种还原论并不感冒。

                我们很容易就会大喊 “不可能”,“他们经营的是开放式图书馆,应该预料到会有人用拖车把所有的书都拖走”,但这并没有什么用。

                我也宁愿拥有一个使用有针对性的防御措施来对抗超大规模服务器(这更像是一种入侵物种)的软件生态系统,而不是一个对它们束手无策的生态系统。

                对于任何非 Linux 规模的软件来说,另一种选择是,大部分资金充足的开发项目最终都来自超级计算机,这只会集中它们的力量。

              • 是的,反信任规则本应阻止亚马逊。但他们没有这么做,这直接伤害了开源。

                我不认为 elastic 会因为开放源代码的竞争而尝试更改许可证。

                问题在于亚马逊,而不是试图生存下去的弹性。

                • > 是的,反信任规则本应阻止亚马逊。

                  具体是哪些?

                • > 是的,反信任规则本应阻止亚马逊。但他们没有,这直接伤害了开源。

                  多么荒谬、扭曲的逻辑。不,这不会影响开源。你在说什么?

                  > 问题在于亚马逊,而不是试图生存的 Elastic。

                  不,问题在于 Elastic 试图胁迫最终用户为使用自由和开放源码软件项目付费。如果 AWS 提供的是托管服务,或者我在 AWS EC2 实例中运行 Elasticsearch,我支付了费用,这完全没有区别。

                  • 那么维护者应该怎么吃饭?还是不应该有?他们应该是亚马逊的员工吗?

                    • > 那么维护者应该怎么吃饭?

                      如果一家公司想在 FLOSS 的基础上建立商业模式,那么他们有责任想办法做到这一点。他们不能做的是滥用 FLOSS 许可证,对他们的用户群进行诱骗,迫使他们达到自己的收入目标。

                    • 他们确实想通了。贡献者签署了 CLA,因此他们的许可证变更是绝对合法的,也符合大家的共识。当你开始使用该产品时,你就应该知道这一点。

                      明白我的意思了吗?

                    • 就我个人而言,作为一名无偿的开放源码软件维护者,我选择了去找一份工作。其他人可能会选择不同的道路。

                    • 他们可以用封闭源代码软件创造业务。没有人要求他们创建 Apache 许可软件。

          • > 如果不能分叉或出售托管集群,开源还有什么意义?

            这里的问题是,亚马逊现在的处境是,他们可以分叉并亏本出售,以压制竞争对手。

            我想这就是反垄断的意义所在吧?我的意思是,如果法规真正得到执行的话。

            • 这不是一个突然出现的 “难题”。

              这种风险一直存在。当他们一开始选择开放源代码时,这种风险就已经存在了。

              我们一次又一次地看到这样的惨痛教训:“如果你的商业价值就是你的代码库,那么你就很难在把代码库拱手让人的同时建立起自己的业务”。

              • > “如果你的商业价值就是你的代码库,那么你就很难在建立业务的同时把代码库拱手相让”。

                或许,一些直言不讳的开源支持者不开源其核心业务组件也就不足为奇了。我可以理解他们这样做是为了公司和企业的生存,但我不理解为什么他们要忍受闭源的耻辱,而他们所有的堆栈都是开放的。

                在不久的将来,我们或许就能看到 Redis 的 “复述”,它既是相同的软件,但写出来却不一样。

                从本质上讲,现在似乎没有什么理由去开源任何东西,尤其是如果这是一个核心业务逻辑的话。如果你(在技术上)能超越其他人,就开源吧,否则你就不应该在乎收入。

                • 一个有足够能力的大语言模型(LLM)可能足以独立完成洁净室设计,几乎不需要人工协助。这将破坏软件版权的整个理念。

                  你需要一个能为任何软件编写完整规范的代理,它可以通过使用软件并推断出软件的工作原理,也可以在许可证不禁止的情况下进行逆向工程。然后,中间有一个律师(人类或大语言模型(LLM))对其进行审查,删除任何受版权保护的部分。然后,你需要另一个可以重新实现该规范的代理。你只是做了一个完全合法的克隆。

                  洁净室设计在美国是一个成熟的先例,以前也使用过,只是使用的是人类团队而不是 LLM。

                  我认为有些公司完全不会受此影响,因为他们的代码行为不容易从 API 调用中推断出来,或者因为他们的价值实际上在于用户/数据/业务关系,而不是直接的代码。Stripe 就是我最喜欢的例子,你不能仅仅通过获取开发者 API 密钥和调用他们的 API 端点,就能反向推导出他们所有的优化和反欺诈模型。他们还与银行和其他机构建立了大量关系,可以说这些关系对他们的业务和代码一样重要。Instagram、Uber 或亚马逊也多少属于这种情况。

                • 我同意 LLM 是大型开源洗钱机器的说法,这是一个问题。

                  我认为这主要是版权许可的问题。许可首先并不保护用户,所以……

                  • 那么谁会起诉一家人工智能公司,声称他们生产的所有代码都是 GPL 代码,因为他们是在 GPL 代码的基础上训练出来的?

                    • 在 GPL 代码上训练一个模型,然后让它写代码,这和让人阅读 GPL 代码然后写代码有什么区别?

                      除非对某段被复制和发布的代码有具体的版权要求,否则很难看出 GPL 与此有关。

                    • 因为,与人类不同,LLMs 能可靠地复制训练数据中的精确摘录。让图像生成模型吐出电影截图非常容易。

                    • 这并不意味着用 GPL 代码训练的大语言模型(LLM)的所有输出都是衍生作品(因此也是 GPL 的)。

                    • 我反复看到这种说法,我不明白人们怎么会认为这种说法有道理。

                      “我的剪贴板学会了代码,就像人类一样。所以我可以复制粘贴任何东西,并称之为我自己的东西”。

                      “杀死人类和杀死电脑有什么区别?”

                      “如果人类可以投票,为什么电脑不能投票?”

                      也许我们可以从 “人类不是电脑 ”开始说起?

                    • > 我们可以从 “人类不是电脑 ”开始吗?

                      当然,因此 “计算机 ”不受人类法律约束也是情理之中。那么,一个大语言模型(LLM)在互联网上找到一段版权数据,下载并重新发布它,就没有触犯任何法律吗?它当然不会被起诉。

                      我最初的观点是,版权保护是为了(除其他外)保护发行权和衍生作品权。我看不出有什么连贯的论据可以证明,把(你合法获得的)受版权保护的作品输入机器就是侵犯了任何人的版权。

                    • > 那么一个大语言模型(LLM)在互联网上找到一段版权数据,下载并重新发布,就没有触犯任何法律?

                      你到底想说什么?一把枪杀了人就没有触犯任何法律?这当然不能被起诉。

                      > 我没有看到一个连贯的论点,说把受版权保护的作品(你合法获得的)输入机器就侵犯了任何人的版权。

                      所以,你不明白拥有一个自动黑盒子,将受版权保护的材料作为输入,并提供一个无法证明来自输入的竞争性替代品,怎么就违背了版权保护的理念?

                    • > 所以,你不明白拥有一个自动黑盒,将受版权保护的材料作为输入,并提供一个无法证明来自输入的竞争性替代方案,是如何违背版权保护理念的?

                      从语义上讲,这与人类读完汤姆-克兰西(Tom Clancy)的所有作品,然后写出一部快节奏的动作/战争/紧张小说是一样的。

                      这违反版权保护吗?

                      版权保护的是思想的表达。而不是思想。

                    • > 版权保护的是思想的表达。而不是思想。

                      版权法是在法学硕士之前制定的。新技术可以完全绕过法律,但这并不意味着新技术可以绕过法律。

                      如果我写了一部小说,我理应获得荣誉,我理应有权出售这部小说,并有权阻止他人以自己的名义出售这部小说。如果允许我复制任何一本书并出售,我可以以更便宜的价格出售,因为我没有花一年的时间来写这本书。而作者就惨了,因为人们会买我的版本(更便宜),甚至可能从未听说过原作者(比如说,如果我复制一切的过程足够好,我做了一个 “偷书网红”)。

                      现在,如果我把书拿去用程序自动翻译,然后以我的名义出售,这也是非法的,对吗?尽管这可能更难发现:比如我把一本西班牙文书籍翻译成普通话,那么就需要有人意识到我 “偷 ”了这本西班牙文书籍。但我们不希望这样做是合法的,不是吗?

                      而大语言模型(LLM)则更难察觉。在大语言模型(LLM)时代,如果我写一篇技术博客,没有人会看到,因为他们会从我博客上培训的大语言模型(LLM)那里获得信息。如果我公开源代码,如果他们可以直接请他们的大语言模型(LLM)写一整个程序来做同样的事情,就不会有人看到。但大语言模型(LLM)有可能在没有接受过我的代码培训的情况下做不到这一点。所以,大语言模型(LLM) 是在 “偷窃 ”我的成果。

                      你可以说 “解决的办法是不开放任何东西的源代码”,但这还不够:艺术(电影、书籍、绘画……)从根本上说必须被展示,因此也可以被训练。大语言模型(LLM)将我们带向这样一个境界:开源、可用源代码或专有源代码,这些概念都不重要:如果你设法在这些代码(甚至是非法泄露的专有代码)上训练你的大语言模型(LLM),那么你就从根本上窃取了这些代码,而窃取的方式可能根本无法察觉。

                      这听起来怎么像是一个令人向往的未来?

                    • > 一把枪杀了人就没有触犯任何法律?当然不能起诉。

                      是啊,老兄……它是一个无生命的物体。

                    • 也许我需要解释一下:我的观点是,要负责任的是枪背后的人……或者说是大语言模型(LLM)背后的人。所谓 “大语言模型(LLM)不可能做违法的事,因为它不是人 ”的说法是无稽之谈:它是由人操作的。

                    • 我觉得没人在乎。这很糟糕,我知道。就像气候变化、生物多样性丧失、能源危机一样。

                      感觉我们差不多都完了。但这并不意味着问题不存在。

                  • > 我同意法律硕士是大型开源洗钱机器的说法,这是一个问题。

                    你为什么认为这是一个问题?我的意思是,要相信这一点,你首先需要相信获取源代码在某种程度上是个问题。

                    > 我认为这主要是版权许可的问题。

                    胡说八道。

                    大多数情况下,问题在于人们忽视了自由和开放源码软件许可证赋予最终用户的权利,当最终用户按照自由和开放源码软件许可证的意图使用他们的软件时,他们却假装惊讶。

                    还有一个明显的迹象是,这些盲目的批评只针对非常精确的公司。显然,他们对其他云提供商销售托管服务完全没有意见。他们单挑 AWS,却完全忽视了 ValKey 背后的组织包括谷歌、爱立信甚至甲骨文等公司。不知为何,只有 AWS 才是问题所在。

                    • > 我的意思是,要相信这一点,你首先需要相信,获取源代码在某种程度上是个问题。

                      你到底是怎么理解我的话的?开放源代码有许可证,上面写着版权所有者允许或不允许的内容。LLM 是洗钱机器,因为它允许任何人无视所有代码的许可证和版权(甚至是专有代码:如果你能在不被发现的情况下对 Windows 代码进行训练,那你就成功了)。

                      > 问题最多在于人们忽视了自由和开放源码软件许可证赋予最终用户的权利。

                      一旦它被用来训练大语言模型(LLM),就不再有权利了。许可证、版权,所有这些都一文不值。

                      > 此外,这些盲目的批评[……]也是一个明显的迹象。

                      不知道你在说什么。

                    • > LLM 是洗钱机器,因为它允许任何人无视所有代码的许可证和版权(……)。

                      不,只要能接触到代码,就能做到这一点。你只需要一个坚定的工程师就能做到这一点。我的意思是,你相信在法律硕士诞生之前,全世界都完全不知道逆向工程的概念吗?

                      > 一旦被用来培养大语言模型(LLM),就再也没有正确的了。

                      胡说八道。你不会因为有人用一个美化过的模板引擎写出类似的东西,就失去对自己作品的权利。事实上,你的整个混合评论表达了你完全缺乏在编码应用中使用 LLM 的经验,因为所有主要的助理编码服务都会执行版权过滤,即使在提问时也是如此。

                    • > 你是否认为,在 LLM 诞生之前,全世界都完全不知道逆向工程的概念?

                      规模决定一切!一个意志坚定的工程师,终其一生也无法读懂进入培训阶段的所有代码。你怎么能相信这是一码事呢?

                      > 胡说。你不会因为[……]而失去对自己作品的权利。

                      如果你不理解我的意思,那就是胡说八道。我的意思是,如果无法证明大语言模型(LLM) 是用受版权保护的材料训练出来的,那么版权就不重要了。

                      但也许你一个意志坚定的工程师可以对任何经过训练的大语言模型(LLM)进行逆向工程,并提取出训练中使用的版权代码呢?

                • 人工智能公司毫不犹豫地攫取一切可用资源,完全无视材料的授权。

                  因此,可用代码与开放源代码一样,都是它们的福音。

              • 这正是 AGPL 所要打击的。但开放源代码开发者仍会首先选择更宽松的许可证–大概是为了吸引企业客户使用他们的产品(因为开发者是大企业利益的吸铁石)。

                • 这一点。他们选择一种许可,自豪地宣传(“使用我们而不是我们的竞争对手,因为他们是 Copyleft,而我们不是”),然后当其他竞争对手从他们选择许可这一事实中获益时,他们就开始抱怨。

                  • 不同的自由和开放源码软件社区持有不同的价值观。我来自 Copyleft 阵营,因为我想为最终用户推进软件自由目标。其他人则对促进软件开发者的自由更感兴趣,他们认为旨在促进最终用户权利的义务对软件开发者来说是不适当的负担。FreeBSD 网站上的文章[1]解释了他们采取不同立场的原因

                    我相信这两个 FOSS 社区的子社区都有自己的原则。我没有看到 FreeBSD 社区的人抱怨竞争对手或营利性公司使用他们选择的许可证所提供的所有权限。

                    [1] https://docs.freebsd.org/en/articles/bsdl-gpl/

                    • > 我没有看到 FreeBSD 用户对竞争对手的抱怨

                      当然!那就好!我并不反对使用许可(虽然我也是 Copyleft 阵营的一员)。或者将其置于公共领域。

                      我的问题是那些这样做却又抱怨的人。

                    • 是啊,这也让我很不爽。

                      尤其让我不爽的是,一些公司在博客上大叫 “滥用”,而他们之所以能成为一家公司,是因为别人给了他们必要的权限,让他们能在并非自己开发的软件上开展业务!

              • > 这种风险一直存在。

                这并不意味着它不是一个问题。

                • 解决 “如果有人用我的代码与我竞争怎么办 ”这个老问题的办法就是 “不要开源你的代码”。

                  这并不复杂。这是商业机密 101。

                  不过,我这是虚情假意。钓饵商人当然知道这一点,他们只是寄希望于在套现之前从他人的免费劳动中获得足够的产品动力。这就是他们一直以来的计划。

                  • 我觉得这有点不公平。我对 Redis 和 Elastic 背后的公司一无所知。但另一种可能是,他们想做一个好的开源产品,并围绕它创建某种业务,却发现很难形成防水的护城河。我相信,还有很多其他开源公司也有同样的基本策略,只是它们更幸运,比如没有 AWS 作为竞争对手。

            • > 这里的问题是,亚马逊处于一个可以分叉并亏本出售以压制竞争对手的位置。

              每个人都可以 fork 任何 FLOSS 项目。这是设计使然。对于直接或间接使用上述自由和开放源码软件(FLOSS)项目随机销售服务的人,也没有任何限制。

              如果一家公司改变了主意,认为以自由和开放源码软件的形式发布软件是个错误,他们有权像 Redis 那样做。他们不能做的是假装无知,或采取诱骗手段,试图胁迫他们的用户群为自由和开放源码软件项目支付许可费。

              • > 每个人都可以 fork 任何 FLOSS 项目

                但每个人都不可能在一个项目中投入大量资源,以压制竞争对手,维持自己的垄断地位。

                这就是为什么我说问题在于亚马逊处于这种地位,而不是许可证。

            • 在我看来,意图决定一切。

              亏本销售不是坏事。为了建立市场份额或消灭竞争对手而亏本销售通常是坏事。

              问题是,以前的公司通常利用这一点来建立市场份额,因此没有其他竞争手段。其他策略还包括游说、专利霸凌等。

              尽管 Uber 很糟糕,但看看大城市的出租车是如何形成的就知道了。

              再看看其他国家的劳动法。

              在当前任何现代国家的法律/政治结构下,没有剥削就没有胜利,这也是我拒绝创业的原因。

              • 不–这就是为什么他们的定价如此详细,为什么他们的服务几乎没有限制,你不能要求他们增加。

                他们有能力维持 Elastic Search 或 Redis 等更好的分支,并凭借高效的自由市场竞争机制将这些公司赶出企业。在这一点上,他们会确保自己的分支只在自己的服务器上有用,也许是通过在所有内部微服务上添加依赖关系–所以从技术上讲,他们发布了代码,但你只能在亚马逊上运行它。

                • > 在这一点上,他们会确保他们的分支只在他们的服务器上有用。

                  你能想到他们这样做的例子吗?他们当然可以这么做,但我想不出他们有哪次真的这么做了,而且这么做的动机似乎也很脆弱。亚马逊要想做这样的事,就必须确立市场主导地位,并相信一些新的参与者会损害他们的市场份额,从而有理由疏远自由和开放源码软件社区。

                  • 考虑到亚马逊的惯常做法,这似乎一点也不疯狂。看看他们数不胜数的反竞争行为就知道了。

              • 抱歉,我并不想暗示他们会这么做。根据反垄断法规,这样做是违法的。

                我想说的是,AWS 使用许可项目是没有问题的。该项目应该事先考虑许可证问题,并从一开始就使用 Copyleft。现在是他们的问题了。

                但我看到的一个更普遍的问题是,即使你的项目使用了 Copyleft 许可证,你也有可能被 TooBigTech 的反竞争行为击垮。这种情况并不罕见,他们经常这样做,而美国却没有强制执行。而当其他国家(如欧盟)试图这样做时,美国就会施加压力,因为他们维护自己的美国 TooBigTech 公司。

                后者不是模式或许可问题,而是反垄断问题。现在,亚马逊可以在不违法的情况下与 Redis 竞争,但他们能这样做只是因为他们太大了。而他们之所以如此庞大,与缺乏反垄断执法有关(这是有据可查的,TooBigTech 公司永远都在滥用他们的支配地位)。

              • 其实不然。我在推出服务时进行过多次 AWS 定价和成本核算工作,副总裁从未指示要以低于构建和运营成本的价格出售服务。构建和运营成本包括工资、基础设施和许多其他细列项目。通常情况下,这些成本都是未来 3-5 年的预测成本,损益分析必须显示服务最终会盈利。成本核算模型对实现利润率的最低客户采用率做了一些假设,这些假设最终会成为产品和销售团队目标的一部分。

                成本核算模型确实允许在最初几年出现亏损,因为一开始构建产品的成本较高,但随后就会趋于稳定,收入也会超过支出。

                这些开源产品以服务形式推出后,初始成本可以降低 50-75%,但很少会超过这个水平,因为你仍然需要构建所有的周边基础设施、文档和用户界面。AWS 依靠现有的工作体系,在许多问题已经得到思考和解决的情况下,它仍然具有优势。此外,您还可能获得一个良好的产品路线图骨架,以确定优先级,否则将耗费大量时间。

                总而言之,不行。AWS 不会亏本出售服务(当然也有例外),但在开始时有亏本的空间,但其定价最终会实现盈利。至于现实中是否每项服务都会出现这种情况,那就另当别论了。

          • 大多数(全部?)开源许可证都允许销售托管集群。他们在修改许可证之前就提供了托管解决方案。你也可以对其进行分叉;但根据许可证的不同,你可能需要对任何分叉进行开源。

            : 我不知道有哪种开源许可证不允许出售托管集群。只要托管版本与开源版本相同,或者其版本也是开源的,那么即使是属于版权保护的 AGPL 也是允许的。

            • 没有人知道 AGPL 到底说了什么,因为法庭(至少在欧盟)还没有对其做出足够的裁决,这也是为什么大多数公司都将该许可证列入黑名单的原因。

              如果你想获得除 AWS 之外的其他公司的采用,你仍然不能使用 AGPL。

              我觉得应该有一种许可证,既不允许超级计算机在不发布源代码的情况下单独分叉,又能让小公司接受。

            • 这是版权许可,不是 EULA。授予复制权,不能对使用部分施加限制。

          • > 如果不能分叉或出售托管集群,开源还有什么意义?

            这是讽刺吗?

              • 你用 “自由 ”这个词很有意思。早在开源软件出现之前,它就被称为 “自由软件”,使用限制要求衍生软件交还他们的修改是其全部意义所在。

                • 除了那些不是重点的情况。每个社区的人都喜欢把关。

        • > 原则上,我不会使用亚马逊的分叉版,因为我不想支持一家宁愿分叉一个项目也不愿意出钱的公司。

          这充其量只是一种似是而非的推理。

          自由和开放源码软件(FLOSS)的全部意义就在于,任何人都可以按照自己的方式自由地使用它。无论是业余爱好者做宠物项目,还是方正集团将其作为核心基础架构,他们都有权以自己认为合适的方式使用它。

          这正是他们开始使用它的原因。不是吗?

          当一个随意的公司决定把地毯铺在已建立的用户群上,期望从迁移现有服务的痛苦中获利时,用户群就不是坏人了。

          • Aws 通过不正当的反竞争策略干掉了一家奥斯公司,并免费继承了他们的代码,这当然不符合奥斯精神。

            因此,如果您只是说这是他们的权利,那么,根据 CLA 的规定,oss 公司有权更改新版本的许可证。

            你在开始使用时也知道这一点。既然你知道会发生这种情况,为什么现在还要说这是 “拉毯子 ”呢?

        • > 被亚马逊像布娃娃一样扔来扔去

          你能详细说明亚马逊到底对 Elastic 做了什么吗?我读了他们所有的博文,唯一的收获就是 “他们出售托管 Elastic 的价格比我们便宜”,鉴于 Elastic 其实只是打包了 AWS/GCP/Azure 的云基础架构,这一点也不足为奇。这并不一定是 AWS 在亏本销售,AWS 只是不需要为自己买单。

          根据我所读到的所有资料,亚马逊确实为 Elastic 的开发做出了贡献,直到 Elastic 将许可证转给他们。在这一点上,他们进行了分叉,但当他们被故意锁定在原始项目之外时,就很难责怪他们了。

          我所见过的大多数针对亚马逊与 Elastic 的争论往往都是基于情绪的。亚马逊欺负 Elastic,因为亚马逊一向如此!这种说法似是而非,但 Elastic 认为他们可以利用亚马逊的糟糕声誉作为武器来对付亚马逊,而没有任何实质内容,这种说法也似是而非。

          • Elastic 和所有编写开源软件的公司一样,陷入了同样的困境。当一个超级分销商可以以更薄的利润出售产品时,它就没有办法实现货币化。

            要么把产品捐给基金会,要么母公司死掉。

            虽然从技术上讲,亚马逊并没有做 “错 ”什么,但他们实际上是在挤压生态系统的氧气。

            问题的参数相对较新。SAAS–现在软件交付的标准,与开源–已经过时–不能混为一谈,激励结构完全错位。各公司都在探索如何摆脱这一困境。Mongodb 通过 SSPL 定下了基调,其他中型企业也纷纷效仿,还有什么可做的,还有什么其他方法可以采取?现在,随着后果开始明朗化,关于哪些方法可行、哪些方法不可行的信息越来越多,各家公司都在进行调整。

            这并不可怕,可怕的是残酷的现实,大科技公司正在扼杀市场,而小公司正在想办法,先尝试一种方法,再尝试另一种方法。

            • > Elastic 和所有编写开源软件的公司一样,陷入了同样的困境。无法盈利

              很难让客户(尤其是企业)为免费赠送的东西付费。

          • 据我所知,争议主要涉及商标。这里有一个链接:https://www.elastic.co/blog/why-license-change-aws(2021 年的原始许可证变更,而不是最近的变更)。

        • 我真希望我生活的世界里,反竞争监管机构不是一个笑话。

          • 你认为将开源产品作为服务提供到底有什么反竞争之处?

            • 处于一个可以复制任何东西并压制竞争的位置是个问题。

              就反垄断而言,我认为如果你能证明亚马逊分叉并提供服务的目的是为了压制竞争,那么这就是彻头彻尾的违法行为。目前的一个案例是 Meta:当年,扎克伯格(在内部)兴高采烈地写道,Facebook 需要收购 WhatsApp、Instagram 和 Snapchat,以防止它们之间的竞争。这就是反竞争。

              这篇文章很好地解释了这一点:https://pluralistic.net/2025/04/18/chatty-zucky/#is-you-taki…

              • 以销售开源软件为生的公司将自己置于这样一个境地:其他任何人都可以复制它们,并仅凭价格与它们竞争。这显然是开源软件的劣势。开源软件有很多优点,这也是人们采用开源软件的原因,但开源软件不可能只有优点而没有缺点。

                将产品开源是一项风险投资,与所有风险投资一样,可能会有回报,也可能没有回报。

                • 正如我之前所说,我认为使用许可授权是个坏主意。我见过多个项目选择许可式许可证作为与已建立的版权共享项目竞争的方式,只是因为它更容易被公司采用。我觉得这不公平,但也有点愚蠢:通过使用许可协议,他们允许任何人用专有的分叉版与他们竞争。

                  不过,还有一个反垄断问题(略微有些矛盾):如果 TooBigTech 可以亏本(比如免费)提供类似产品,直到占领市场,那就有问题了。他们之所以能这样做,是因为他们太大了,这就是反垄断问题。

              • 他们不能 “复制任何东西”。

                他们只能复制法律明确允许的内容。

                Elastic 就明确允许 AWS 复制和使用他们的源代码,然后还抱怨了一番。

                • 我的意思是,他们有足够的资源来复制任何产品,从而击垮竞争对手。

                  比如,他们可以建立一个开源项目的替代品,免费(即亏本)提供数年,直到占领市场,然后开始 “enshittifying”。这是一个反垄断问题。

                  > Elastic 明确允许 AWS 复制和使用他们的源代码,然后对此喋喋不休。

                  是啊,至少他们应该一开始就使用 Copyleft 许可。

                  • 我明白你的意思了。是的,我同意。但这与开放源码软件无关,正如你所说,这是一个注册问题。

                  • 在替代品也是免费的情况下,很难说有人在市场下销售,试图占领市场。

                    • 如果有公司从中支付工资,那就不完全是免费的了。

        • 如果你不能自己运行,或者不能为他人运行,那又有什么用呢?

          这不就是整个想法吗?

      • 这种情况不断发生:

        1. 人们在构建数据库方面投入了大量工作。许可证的选择是开放源码软件(OSS)/自由开放源码软件(FOSS)。

        2. 社区中的一些人(原作者、社区领导)围绕数据库成立了一家公司,并持续开发多年。他们有时会筹集风险资本来扩大业务。

        3. 亚马逊/谷歌/微软提供数据库的管理版本,并从中获利。轻松获得数百万美元的收入。原始创建者/公司得不到任何收益,超级分销商也没有义务支付。

        4. 公司决定更改许可证,迫使亚马逊/谷歌/微软加入并支付费用。

        5. 亚马逊/谷歌/微软分叉数据库。社区造反。有时造反的人是超级计算机公司的员工,有时只是讨厌 “源代码可用 ”许可或重新许可的自由和开放源码软件爱好者。

        6. 数据库公司被迫收回变更。仍然没有收入。

        解决方案很明确:从第一天起,就使用 “公平源代码/源代码可用 ”许可证启动新数据库。没有人会抱怨重新许可的问题,因为你的许可一开始就能处理超大规模。

        如果你想防止亚马逊卷款逃跑,基本上你的许可证需要以下几项之一:

        – 超级分销商条款,规定任何托管产品必须(1)完全开源,(2)支付一定费用,或(3)完全禁止。

        – MAU / ARR 条款,使超级分销商处于爆炸半径内。请注意,这也会打击你的客户。

        • > 解决方案很明确:从第一天起,就以 “公平来源/来源可用 ”许可证启动新数据库。没有人会抱怨重新许可证的问题,因为你的许可证一开始就能处理超大规模的问题。

          是的,这样做是诚实的,但人们不会这样做,因为使用非自由和开放源码软件许可证会让你失去被采用的机会。你在你的小时间表中忽略了一个步骤,那就是项目之所以能起飞,并变得足够大,以至于有人能从中赚钱,唯一的原因就是它是开源的。专有数据库、编程语言和类似的东西已经输得一塌糊涂,而且这种情况不会很快改变。

          因此,真正的情况是,这些自由和开放源码软件公司想把自己的蛋糕也吃掉。他们想免费发布代码,让其他开发者使用,然后从项目中赚钱,同时以某种方式禁止其他公司也从中赚钱。

          • 我们缺少的正是开源获胜的原因。这是不可能的。如果维护者(这是一个精心挑选的词)试图 “拉地毯”,你可以直接用 Elastic 或 Redis 来对付他们。如果产品是封闭的,这是不可能的,你只能听命于你所依赖的人。开源是最终的修复权。一切都在按计划运行。

            • > 一切都在按计划运行。

              如果这是真的,那我们就需要别的东西。

              否则,预计在未来十年中,新的自由和开放源码软件会减少很多,这将是一场惨败。

              如果自由和开放源码软件不能满足时代的需求,它就需要更新或被取代。

              • 销售软件是一条死路。没有哪个正常人会为软件买单,因为风险太大。如果你想建立技术业务,那就销售服务和支持。

                • 那么是与 AWS 竞争,还是根本不赚钱?

                  这真是一个奇怪的现实,似乎超大规模企业真的赢了,而开放源码软件同时也死了。

              • 大多数软件始终是专有的。GNU 是一个革命性的想法。企业通过赠送产品来获得青睐,这只是利润率下降的自然趋势。

          • 这种纯粹主义思想正在扼杀开源的长期生存能力。如果超级计算机能从成功的项目中赚钱,而开源创始人却不能,那么 10 年后,我们的开源项目就会越来越少。

            许可自由并不一定是全有或全无,也不一定适用于世界上的每一个人。它可以是开源的,也可以有限制。否则,开源就会变成一种宗教。

            • 不是宗教,而是一个有特定含义的术语,其含义意味着一系列无歧视的自由。我们欢迎人们使用取消这些自由的许可证,但称它们为自由与开放源码软件(FOSS)会造成混淆,把水搅浑。

              请看 Llama 的许可证:如果它既可以是开源的,同时又有限制,那么有一个 “可接受使用政策 ”也是可以的,不是吗?那么 Redis 就可以创建一个许可证,禁止在托管成人内容、星球大战同人小说或包含字母 R 的文件的情况下使用它?

              如果开放源代码并不意味着不加区分地授予一系列特定自由的许可证,那么它作为一个术语就毫无用处–我听到它时只知道一个项目的源代码是可用的。这倒提醒了我,我们已经有一个术语来表达这个意思了: 源代码可用。

              • 语言是由社会而不是由某个基金会定义的

                开放源代码的含义正是人们所说的含义,也是他们想要理解的含义

            • 这与宗教信仰无关。PostgreSQL 开发人员确实赚了钱,对吗?尽管有 RDS。

              • 差不多吧,在过去十年中,已经有一连串的PostgreSQL开发公司倒闭了。有些是出于常规原因,但我不想贬低 RDS 的影响。

                不过,我认为 Postgres 有点不同。它的市场更大,应用也更广泛。无论哪种平台提供数据库服务器,都需要调整服务,因此云托管有一定的盈利空间。

          • > 所以,真正的情况是,这些自由和开放源码软件公司想把自己的蛋糕也吃掉。

            说到踢倒。所以,你就不能对那些大公司说点狠话吗?这些公司虽然没有做出任何贡献,但却凭借其庞大的规模和规模优势,攫取了企业价值的绝大部分?

            • >毫无贡献

              这句话很容易被人挂在嘴边,但我听到的每一份评估都说,大公司对这些项目的贡献相当大。

              > 获取企业价值的绝大部分?

              啊,马特-穆伦维格的逻辑又在悄然出现了[0]!这基本上是他对 DHH 的嘲讽(不过,至少你是用它来喊冤,而不是戏弄!): “尽管他发明了价值约 5 万亿美元的好点子,但大部分价值已被他人攫取”。

              这就是我认为对云提供商的攻击的主要来源:这些公司中的相当一部分已经接受了这样的观点:如果他们不能从开源项目中获取大部分价值,他们就是失败的。当你将其作为风险投资的业务时,这种想法是可以理解的,但考虑到自由与开放源码软件一直以来都是为了促进集体利益,而不是为了赚钱,这种想法就毫无意义了。

              [0] http://web.archive.org/web/20241014235025/https://ma.tt/2024

              • 如果你的最后一句话是真的,你会更喜欢这样一个世界:超级计算机不分叉和关闭自由和开放源码软件项目的源代码,而自由和开放源码软件项目却继续蓬勃发展。

                由于大多数公司都禁止版权复制,这意味着没有可行的自由和开放源码软件商业模式。

                目前的现实是,许多自由和开放源码软件的贡献者在业余时间免费提供服务。许多重要的基础设施都依赖于这种善意的开发。但是,随着惬意的薪水和工作保障的下降,有时间免费工作的人会越来越少。与没有超级计算机相比,我们将减少福斯、减少创新、减少新的可行项目。

                这怎么能促进公共利益呢?

              • > 大狗都是相当多产的贡献者

                好吧,当然,但也有贡献和贡献之分。

                > 这些公司中有相当多的人认为自己是个失败者……

                好吧,有道理。但在你所描绘的平衡状态下,只有 AWS 这样的公司才能将开源货币化,尤其是因为软件交付和 SAAS 在 2025 年基本上是等同的,而 SAAS 是一种微利游戏,小公司无法与之竞争。

                风险投资也是开源软件在业界迅速深入人心的杠杆。因此,当一个从业者从 Redis 或 ElasticSearch 等成熟的工具和广泛的用户群中获益时,不仅是因为它便宜(开源),还因为它得到了大量的支持(风险投资)。

                > 我认为,对云提供商的攻击实际上大多来自……

                我的意思是,你说得没错,但不一定称其为侵略。

                现在的软件平台已不同于 20 年前。如果我们想要一个繁荣的开源生态系统,我们就需要解决这样一个问题,即大型科技公司可以在后起之秀–既是项目的先驱_又是项目扩张的资金提供者–有机会之前盘踞战利品。

          • 我不认为选择许可证是因为采用的原因–除了少数特殊情况,许可证通常不会阻碍你的工具/项目被更广泛地采用。

            我过去写的代码是用 GPL 许可证编写的,而现在我可能会使用另一种许可证(现在我更喜欢 BSD 3-clause,不过我更喜欢通用的非商业许可证)。我并没有费心去重新授权,因为……这最终并不重要,反正这些项目都是超级小众的。我选择 GPL 是因为 “大家都在用”。

            人们总喜欢把敢于放弃 GPL 的人妖魔化,而事实很简单……也许有些产品在现代市场上就是无法使用 GPL。超标量器是一个相当大的问题,而 GPL 的支持者却只能给出 “它按计划运行”/“去你妈的贪婪 ”这样的陈词滥调,而不是承认 GPL 在这些环境中可能行不通,这……并不好。

            这并不是在为 SSPL 或类似的东西辩护(它是个相当糟糕的许可证),但这些实体不断编写新许可证而不是 “保留所有权利,我们发布源代码是出于礼貌,你不能将其用于任何用途 ”是有原因的(即使他们有效地关闭了所有贡献,他们仍想尝试使用许可许可证。

            从根本上说,选择许可协议的考虑因素往往并不像你想象的那么复杂。它可能只是 “如果大家都这么做,也许他们做的是对的”。而不是 “GPL 能让你获得更多的贡献者”。

            • 我认为这可能取决于业务。在某些地方,开源是 “安全之选”(尤其是如果你不销售软件,也不担心 GPL 等问题)。而在另一些地方,许可证问题则是个大问题。

        • 或者从一开始就使用 AGPL,而不是推卸责任的许可证,如果超标者需要,还可以向他们出售替代许可证。

          • 我真的很想这样做,但我在咨询公司工作时了解到,大多数公司都禁止使用 AGPL,因为它的具体规定完全不明确,需要在法庭上讨论(或难以接受)。

            在精神上,AGPL 是我们所需要的,但在实践中,它却扼杀了任何企业对它的采用。

            针对超大规模企业或按收入计算的许可证可能是更好的选择。

            也许能写出更清晰的许可证,也许不能。

          • 你知道亚马逊有托管 Grafana 服务吧?AGPL 并不是超级计算机吸走维护者创造的大部分价值的保证性障碍。

            • 他们没有吸走,因为他们为此向 Grafana 实验室支付了费用。

        • > 亚马逊/谷歌/微软提供数据库的托管版本,并从中获利。收入动辄数百万。原始创建者/公司得不到任何好处,而超级分销商也没有义务付费。

          事实并非如此。一家名为 Garantia Data 的公司将自己更名为 Redis Labs,并获得了 Redis 商标。他们不是原来的公司,他们使用了一种命名技巧,把自己说成是官方公司(现在是了,他们所做的一切都不违法)。

          https://news.ycombinator.com/item?id=42256757

          https://www.gomomento.com/blog/rip-redis-how-garantia-data-p

        • 所有的公司都应该这样做……如果有的话,这样我们就知道什么不能用了。

          任何一种专有产品(无论是完全封闭源代码、源代码可用,还是 “有限制的开放源代码”)都存在风险。你很高兴地使用 X 数据库,但他们被 Broadcom 收购了,现在他们的产品价格是以前的 100 倍。你现在该怎么办?

          这就是为什么采用开放源码要安全得多–最坏的情况是公司倒闭,但你仍然可以无限期地使用上一个发布的版本,并希望有新的实体(甚至可能是 hyperscaler!)分叉代码。如果你有足够的资源,也可以在公司内部进行分叉。

          “公平源代码 “许可证意味着这不是一个选项。新产品应该比开源产品好很多很多,这样才会被考虑。

          • > 最坏的情况是公司倒闭了,但你仍然可以无限期地使用上一个发布的版本,并希望有新的实体(甚至可能是 hyperscaler!)分叉代码。

            但这并不总是最坏的情况,不是吗?如果许可是许可性的,那么超级分销商就可以把它分叉出来,做成专有产品。

            这就是没有 CLA 的 Copyleft 许可的原因。没有人能把 Linux 变成专有产品,因为版权是由许多人/公司共享的。

            • 他们说的是对客户最不利。你说的是对供应商最不利。

              • 我不明白你在说什么。供应商 “与此有关吗?

                Copyleft 总是对客户最好的。Copyleft 说的是 “客户有权利”。许可说的是 “你想做什么就做什么,只要在署名中保留我的名字”。

                • 产品(这里指软件)由供应商或销售商提供给客户。这是商业 101 吗?

                  对供应商来说,最坏的情况通常是他们提供了产品却拿不到钱,而对客户来说,最坏的情况通常是他们给了钱却得不到产品。

                  如果采用 Copyleft 协议,供应商更有可能拿不到钱,但客户却可以从中获益,因为如果供应商倒闭,客户可以自己继续维护软件。供应商希望这能帮助他们获得并留住客户,其中许多客户会付钱,从而使他们继续经营下去。

                  • > 这是商业常识吗?

                    我明白什么是供应商。我不明白这和我说的有什么关系。

                    > 特别是在 Copyleft 的情况下,供应商更有可能拿不到钱。

                    这说不通。无论供应商是以许可方式还是 Copyleft 方式开源代码,都不会对获得报酬的可能性产生任何影响。

                    但如果他们以许可方式发布代码,竞争者就可以制造一个专有的分叉。可能会不断从上游引入新的改进,并专注于差异化。而如果以 Copyleft 方式发布,竞争者就必须分享他们的改动,而上游可以从中获益。

                    因此,对于供应商来说,如果你想这么说,最好还是以 Copyleft 的形式授权代码。除非整个想法是要被公司采用,但在这种情况下,当他们使用你的代码并构建专有产品而不贡献任何东西时,你就不要抱怨了。

            • 在这种情况下,到底是谁在受苦?

              原公司已经倒闭,不复存在,所以他们显然不在乎。

              软件用户也不在乎。好吧,有人做了一个专有的分叉,而这个 “有人 ”是一家超级分销商……那又怎样?最后发布的版本仍然存在,仍然可以按原样使用/由你维护/由其他第三方维护。

              新的维护者/fork 作者也不应该关心这些。他们以最后发布的版本为基础,他们的分叉版本不会受到某些超级缩放器的任何影响。

              (我想你可以说专有分叉版可能会从开源分叉版中抽走用户/资源……但我不认为这是个大问题。如果用户一开始就选择了开源版本,他们为什么要转用专有分叉版呢?)

        • 这个细分问题很尖锐,因为它不仅涉及商业模式,还涉及信任。

          开源之所以成功,是因为它创建了共享的公共基础设施。但超级计算机把它变成了提取基础设施:挖掘代码,跳过管理。

          结果呢?我们把 “开放 ”与 “强权自由 ”混为一谈。

          现在是时候了,不要再假装许可证就足够了。这关系到激励、管理和复原力。下一代的 “开放 ”必须包含对抗力量–否则它只是垄断者的食槽。

          • 在从许可转为非开源许可之前(因为它们对 TooBigTech 有例外),一个简单的步骤就是使用 Copyleft 许可,不是吗?

              • 这是不对的:正如另一条评论所指出的,他们向 Grafana Labs 支付了专利使用费:

                https://lwn.net/Articles/1019686/#CommAnchor1019710

                > Grafana 就是一个很好的例子。AWS 和 Azure _本可以将未经修改的 AGPL Grafana 作为一项服务出售,或者发布它们修改过的版本,但它们都与 Grafana Labs 达成了专有许可和共同营销协议。

          • 测试我的大语言模型(LLM) 检测能力。这是你自己写的吗?还是大语言模型(LLM) 制作的?

            我觉得这些措辞超级像 GPT。

        • > 公司决定修改许可证,迫使亚马逊/谷歌/微软加入并支付费用。

          你能不能在许可证中加入一个条款,列出你所担心的那些特定公司,并让它们以及它们的任何子公司支付费用?

          这样一来,软件周边的小企业仍然可以存在,没有人会因为许可证中列出了特定的超级计算机公司(社区中对它们并无好感)而过于担心,而且你还能让它们支付合理的份额。

          为什么人们要试图用限制性过强的 SSPL 毁掉一切,把其他人都卷入爆炸区,或者试图编写一些适用于所有情况的巧妙许可证?只要指出那些正在吃你午餐的公司就行了!

           Hyperscaler Anti-Freeloading License (HAFL):如果你属于以下任何一家公司,或者是它们的子公司,或者运营以下任何一个云平台并想在那里提供服务,请付费: 亚马逊网络服务(亚马逊)、谷歌云平台(谷歌)、微软 Azure(微软)、阿里巴巴云(阿里巴巴集团)、IBM 云(IBM)、甲骨文云基础设施(甲骨文)、腾讯云(腾讯)、SAP 云平台(SAP)。此列表可由我们酌情更改。
          • >一份以后可以更改的清单?
            任何法律部门都不会批准使用这样的许可软件。谁愿意冒着成为下一个新增名单的风险?

        • > 超级分压器条款规定,任何托管产品都必须(1)完全开源,(2)支付一定费用,或者(3)完全禁止。
          从一开始就使用 Copyleft 许可证(不一定是 GPL,也有 MPL 和 EUPL)就可以实现(1),而不需要新的许可证。
          但人们 “不希望有附加条件”,更乐于使用许可,然后他们就会抱怨。

          • 你错了。除了超级计算机之外,人们希望任何公司都能采用。如果超大规模公司不是直接竞争对手,人们会很乐意在保留代码的同时出售服务合同等。
            但现实情况是,目前的版权许可意味着大多数公司的法律部门会立即将其列入黑名单。
            这也是为什么几乎所有的共享软件公司都提供共享软件和企业许可,尽管在 99% 的情况下,这与共享软件的精神毫无关系,因为公司只是想在一些完全无关的内部项目或其他项目中导入和使用这个该死的软件包。
            不明确的法律先例和公司管理的结合意味着,目前的 Copyleft 并不能如大多数人所希望的那样发挥作用。

            • > 但现实情况是,目前的版权许可意味着大多数公司的法律部门会立即将其列入黑名单。
              因为他们总能找到许可的替代品!有许多不同的版权许可(不仅是 GPL 系列,还包括 MPL 或 EUPL)可以使用,而且不会 “病毒式 ”传播。
              > 不明确的法律先例和公司管理的结合意味着,目前的 Copyleft 许可证并不能如大多数人所希望的那样发挥作用。
              这是不对的。它的意思是,公司管理并没有正确处理这个问题,因为他们并不需要这样做。
              如果一个项目因为想取悦公司而采用了许可制,他们就不应该在这样做的时候抱怨。否则,他们就应该使用 Copyleft 许可证,让小公司知道他们其实完全可以使用这种许可证!

              • Copyleft 许可证在欧盟有争议的后果是事实,这使得它们有固有的风险

                • 我读过一些关于版权复制的文章,但我个人在agpl方面遇到过这种情况。

        • “带着你的钱一走了之”
          这是所有这些愚蠢行为的核心。没有 “你的钱 ”可以让别人拿走。没有任何东西被盗。
          如果你想出售软件或出租软件使用权,那就从一开始就老老实实地做。祝你好运。除非别无选择,否则我不会使用它,我也不会为它做出任何贡献,哪怕是开发使用它的东西或帮助人们解决使用它的问题等。换句话说,我不会以任何方式对它进行投资。但是,嘿,也许你会做出一些不可或缺的东西,而且做得比别人更好,也许你还会得到其他一些客户。
          如果你想从开源带来的采用、商誉和免费工作大军中获益,那就去做吧。
          从事开源工作的真正原因是,你自己已经认识到,因为开源,你免费获得了多少实用工具,并希望将其付诸实践,从根本上为全人类做出贡献。你从中得到的回报与其他人是一样的,都是软件本身的使用,加上你的名字。
          但是,如果你授权他人使用开源软件,除了遵守归属和类似共享条款外,你根本不在乎别人怎么做,那么你就失去了开源的意义。你一心只想 “抢夺 ”本来就不属于你的东西。你无权拥有亚马逊的数十亿美元,即使是他们通过托管你偶然编写的开源软件拷贝而获得的那部分。亚马逊出售的不是你的财产,而是托管服务。你无权从中获得收益。托管的软件是一种社区资源,每个人都可以使用,就像空气或水一样,只不过与雀巢公司从其他人那里拿走水不同的是,其他人仍然拥有该软件。
          如果说在所有这些案例中,所谓的受害方都是不良社区成员,因为他们往往一开始就虚伪地使用开放源码软件。他们一开始就使用 MIT/BSD 类型的许可证,因为他们知道很多公司对 GPL 不感冒。但他们为什么如此不能容忍 GPL 呢?因为 GPL 不允许他们偷窃,但 MIT 允许他们偷窃。因此,他们一开始使用 MIT 类型的许可证,因为它 “对商业友好”,然后再哭诉有人 “偷窃 ”了他们的 B S freaking D 许可证软件。
          这样做的人从一开始就不是为了加入社区池而编写开源软件。这要么是不诚实的,要么充其量可能是诚实的,但在这种情况下就是令人难以置信的无能和无知。

          • 你活在理论的幻想世界里。
            是啊,如果一切都是开源的,大家都很开心,那该多好。
            但事实并非如此。Redis 和 Elastic 之所以流行,正是因为背后有整个公司在不断维护、保护和添加功能。
            如果你想在工作中使用开源软件,这是一个硬性要求。不,你不能使用 Timmy 利用空闲时间开发的 “MySillyKeyValueCache”,而不考虑安全性或兼容性问题。
            公司运营需要成本。谷歌和 AWS 利用开源工作牟利,却没有提供足够的支持。这才是你真正应该生气的地方。互联网巨头们正在实实在在地扼杀开源。
            如果他们得逞,你将只能使用他们的专有软件。在实践中,AWS 已经做到了这一点。

            • > 公司运营需要成本。谷歌和 AWS 利用开源工作牟利,却没有提供足够的支持。
              我不明白这种说法,如果谷歌/AWS/微软决定托管你的服务,并发现了一些漏洞,那么你就可以免费获得安全研究,你的产品要么仍然存在漏洞,要么就会有其他人提出同样的漏洞。
              您拥有代码,因此您可以决定只有特定人员才能提交 PR,并可以选择关闭任何功能请求问题。
              如果某个云提供商决定使用你的产品,那是因为他们认为这样做是合理的,或者他们可以向上游分叉/贡献。
              这就是开放源码软件的定义。
              你可以用 MIT 等许可证发布代码,然后再也不碰它。
              如果你是一家现有公司,并开源了自己的代码,Facebook/react,那么你可能已经赚到足够的钱来支持自己的开发,或者打算停止开发。
              如果你开源的代码是你的核心业务,而有人 “偷走了你的午餐”,那么你就上了重要的一课,希望你不会再犯同样的错误。如果你决定重新授权,而社区却抛弃了你,并在互联网上引起轩然大波,那么你将为自己的行为付出代价,接受现实吧。

              • 问题在于,超级计算器不会托管你的产品。他们会分叉、关闭源代码,而你却得不到任何好处,甚至连安全研究都得不到。
                如果你使用 Copyleft,就不会有人使用你的产品(或要求使用非自由和开放源码软件的商业许可证)。

              • 听着,原则上我不反对你说的任何话。
                不过,我认为开放源码软件对整个行业来说是一个净积极因素,我希望看到它继续如此。
                开放源码软件的传统盈利方式是有偿提供托管和支持。
                现在,互联网巨头们正在把这块蛋糕全部据为己有。
                如果我们同意希望开放源码软件成为未来的可行选择,并且同意需要钱来雇佣开发人员以成功维护一个大型开放源码软件项目,那么你有什么建议?

                • > 我们同意你需要钱来雇用开发人员来维护一个成功的大型开放源码软件项目。
                  这就是我们的分歧所在,你不需要。如果你是亚马逊,而上游愿意接受请求,那么亚马逊就可以雇佣开发人员,如果有人吃了他们的蛋糕,那么这些开发人员最终会迁移到新的地方。
                  作为一个为开放源码软件做了初始工作的人,我把代码放在那里,如果我不喜欢分叉的方向,我可以不理会分叉,继续开发我自己的版本,为什么我需要使用他们正在使用的版本。
                  归根结底,你为什么要启动一个开放源码软件项目,如果目的是为了赚钱或雇佣其他员工,那你就从根本上误解了任务。
                  如果你做了一个满足你自己需要的项目,决定让其他人也能从中受益,于是你把它作为自由和开放源码软件在网上发布,它获得了大量的关注,这怎么会改变你的需要呢?你可能没有理由让它在商业上可行,它仍然在满足你的需要。
                  现在,如果它被分叉了,而分叉后的版本被证明质量更好,仍能满足你的需求,那么你就可以为了自己的个人需求而改用分叉后的版本,但现在维护工作由别人来做了,所以你最终成了 “吃白食的人”。
                  我已经讨论过 “维护者的负担”,如果这是一个问题的话,就关闭对问题和拉取请求的访问。就不会再有负担了。

                  • 分叉通常是闭源的,因此你无法从中获益,公众也无法从中获益。
                    当然,这意味着你永远都不应该使用许可授权,因为它并没有提供人们所认为的奥斯能提供的许多关键利益。你可以使用 Copyleft,但我想对于 llms 来说,这也是一样的。

                  • 如果亚马逊需要做足够多的维护工作,他们会直接将其分叉,并在自己的专有版本上进行维护。他们确实已经这么做了。
                    这又回到了我的原点。你活在幻想中。

                    • 我不觉得这有什么问题。对他们有好处。这对你有什么影响?

                    • 这个幻想世界的本质到底是什么?我必须说我想要或期待什么,这样说才有意义。你毫无根据地提出愚蠢的主张。这不是争论。
                      事实上,这恰恰相反。指望同时享受开放源码软件的好处和收取租金的好处,这简直是天方夜谭。

            • 那就卖软件。我已经说过了。这哪里是幻想?
              如果你不理解,以至于认为这是天方夜谭(尽管有大量的现有软件可以证明这一点,而且有无数从事这项工作的人发表宣言,说明他们为什么这样做),那么这是你的问题,而不是我或其他人的问题。
              你不明白,没关系,那就干脆不明白,也不要参与这项你认为是疯狂的活动。
              关于什么是合理利用你的时间和精力,你可以自由发表意见。
              但不要假装你明白一些参与者不明白的事情。我们都在吃非梦幻食物,不知何故,我们都吃得很好。

              • 如果他们试图出售他们的软件,你自己也承认,你不会消费它。这才是重点。幻想的是某些开源产品甚至可以作为封闭源代码的专有商业模式。

                • 那就别卖了。或者做一些人们离不开并且愿意花钱购买的其他东西,而不是自己花钱写一个等价的东西,而不是永远向你支付租金,不管怎样,这与我或其他人有什么关系?
                  你想做什么就做什么,但如果你不知道该怎么做,那就不是别人的问题了。
                  你在这里没有争辩的余地。

                  • 我不同意你的很多观点,但你说得很对。
                    如果你想做生意,那就去做生意。建立企业的一个关键方面是了解你的知识产权和商业秘密是什么,它们如何影响你的底线,然后对它们进行适当的控制。

                  • 问题是,如果 Redis 和 ElasticSearch 等项目背后没有业务,你也不会使用它们。你使用的将是微软或甲骨文的随机产品。
                    我猜你也不希望如此,所以请想办法确保 Redis 能够获得所需的资金支持,以雇佣工程师来完成我们这样的兼职贡献者不愿意做的全职工作。

                    • 问题的关键在于,我没有必要想出这样的办法。
                      并不是说如果没有 redis,我就会使用 MS 或 Oracle 的产品。如果实用的话,我可能会用。或者有人已经发明了 redis,或者我可能已经发明了 redis,如果这是一个仍然需要填补的空白,而不知何故没有人去做的话。
                      这就好比说,如果没有 linux,我们都会使用 NT。
                      这完全荒谬。不,我们不会。BSD 早已存在,如果没有它,minix 克隆版或其他人也会开始使用其他的 unix 克隆版。当时已经有几个小型的 unix 克隆版和其他完整的操作系统,它们都是由完全小型的开发团队制作的,甚至是一个人在商业上制作的。如果一个人就能完成这项工作(不管他们是为了销售),那就说明这项工作并不是无限大的,因此完全可以由几个自发的志愿者来完成,尤其是考虑到这种工作没有截止日期。
                      只是 “志愿者 ”这个词用得不对,因为他们不是什么奇怪的圣人,他们只是为了你我做一些事情。他们是在为自己做事,而你也可以拥有它。
                      所有事情都是如此。Redis 也不例外。Redis 并不神奇。每天都会有这样的事情发生。如果 Redis 不存在,这就是一个无稽的无效前提,因为只要有需求,就会有 12 个 Redis 类似物存在。我以前没有这样做并不重要,我现在也不需要这样做,这不仅仅是因为redis碰巧存在。

                    • 这又回到了我的原点。你活在幻想中。
                      实际上,事情并非如此。如果要使用 Redis,你的公司必须指派专人负责维护工作,那么你就不能使用 Redis。没错,你会使用 MS Redis,因为没有一个克隆产品的安全性和支持程度足以让你放心使用。

                    • 那又怎样?如果某些公司不使用 Redis 或其他软件,关我什么事?

            • > 谷歌和 AWS 利用开源工作牟利,却没有提供足够的支持。这才是你真正应该生气的地方。互联网巨头们正在从字面上扼杀开源。
              如果这些项目使用 Copyleft 许可证,他们就必须公布自己的修改。Copyleft 许可证并不强制要求 “回馈”,但却强制要求公开修改内容,让社区从中受益。

              • 我喜欢 Copyleft 许可证!
                但它们并不能解决云提供商将基于开源公司的公司从地毯下拉出来的问题。

                • 我不太理解你的意思。如果你使用的是没有 CLA 的 Copyleft 许可,那么版权就会在所有贡献者之间分配,这就使得更改许可几乎不可能。而且,由于是版权拷贝,这就意味着需要向用户分发源代码。
                  因此,TooBigTech 公司可以在一个版权受限项目的基础上构建一项服务,但他们必须发布他们所做的修改,这意味着社区可以从中受益。我在这里了解到的一个例子是 Grafana: AWS 不想使用他们的 AGPL 版本,所以显然他们付钱给 Grafana 以获得商业许可。当然,这只是因为 Grafana 拥有整个代码库的版权。例如,Linux 就不可能这样做,因为没有人有权力授予商业许可,因此每个人都可以使用 GPLv2。
                  这并不妨碍 TooBigTech 通过为开源项目提供服务来参与竞争,但我认为这更像是一个反垄断问题。

                  • 我明白你的意思了。
                    我不知道 Grafana。听起来不错。
                    也许你说的反垄断问题是对的。

                  • 令人遗憾的是,Copyleft 在法律上并不明确,这也是为什么基本上没有公司使用 Copyleft 许可证的原因,即使他们应该使用。
                    我的意思是,apgl 的意图是完全正确的,但在实践中,这意味着你永远无法在公司中使用它,即使你真的不想以任何方式改变它、出售它或将它单独托管。
                    这实在令人沮丧。我见过的大多数内部授权工具都会把任何直接的 Copyleft 输入列入黑名单。

                    • > 很遗憾,Copyleft 在法律上并不明确
                      你指的真的是 Copyleft 还是 GPL 系列?
                      那 MPL 和 EUPL 呢?我听说过 GPL 的法律问题,但从未听说过 MPL 和 EUPL 的法律问题。

                    • 基本上是的。虽然在我所见过的使用案例中,弱版权保护是没有问题的,但这种区别和许可证还需要在欧盟法庭上进行测试。
                      因此,在这个问题上有许多法律选择,因此,在我所见过的大多数合规部门看来,这是一个很难拒绝的问题。

                • 没有问题可以解决,因为没有地毯可以揭开。Redis 没有被拖欠任何东西,也没有人从他们那里偷走任何东西。
                  当我试图通过托管 http 服务器副本来开展业务时,我并没有从真正编写 http 服务器的 nginx 手中抢走地毯。
                  而当 AWS 做得比我更好时,他们也没有从我这里拿走任何东西,至少没有以任何方式对任何涉及的软件进行特殊处理,只是普通的大企业对小企业,就像 Safelite 对 Joe the Glass Guy 一样。

                  • 好吧,朋友,等你想出一个不被互联网巨头摧毁的支持开放源码软件的商业模式时,告诉我一声。

                    • 没人需要想出什么。开放源码软件已经很好了。我不知道你想要什么,但这似乎是你从未有过的权利,没有人需要想出什么办法来满足你。

                    • 说别人都错了很容易,但如今大多数创新和新项目都来自于人们想做奥斯,同时还想用它来支持生意。也就是说,它不仅仅是一种业余爱好。
                      现在,你可以说这本身就是一种误解,也许你是对的,但我认为你也忘记了软件的现实已经发生了变化,事实上,曾经有一段时间,全职 oss 是可行的。
                      现在的现实是,除了封闭源代码或 oss 之外,没有其他商业模式,而且不可避免地会出现某种拉锯战。
                      这不应该是

                    • 其他人并没有错,我也没有说他们错了,所以你试图以此为基础进行的任何争论在开始之前就已经是无效的废话了。
                      有些人是错的。说这话很容易,因为世界上任何事情都是如此。这个话题也不例外。
                      如果你想说你没有错,或者说我错了,你必须提出一个站得住脚的论据,而不是别的什么。
                      没有人欠任何人销售开放源码软件的生意,即使是开放源码软件的作者。如果你写的东西想通过销售赚钱,那么你就对参与开放源码软件不感兴趣。就是这样。仅此而已。
                      诚实地销售你的软件。
                      “但如果不是……我就不能” 那又怎样?好吧,那就别卖。你对开放源码软件存在的原因、它的好处以及人们为什么要花时间或精力为它做贡献有错误的认识,这不是别人的问题。
                      所有其他的哀嚎和哭泣都源于你从一开始就无权拥有的废话。不只是法律上或技术上,还有道德上和常识上。

                    • 我觉得这个问题很有趣。在你看来,谁应该在什么情况下生产奥斯?您担心奥斯的可持续性吗?

                    • > “但如果不是……我就不能……” 那又怎样?好吧,那就别卖。
                      有趣的是,当这番话来自 TooBigTech 时,他们显然很乐意说 “但如果不滥用版权,我们就无法制作可行的 LLM”(是的,他们说了)。很显然,这很有效。
                      不过,我并不是不同意你的观点:出售开放源码软件并不欠任何人的。

                    • 大语言模型(LLM) 供应商正在侵犯版权。我不知道这和这次谈话有什么关系。

        • 问题在于开源的定义是由开源计划控制的,而开源计划已经被超级计算机所控制。
          这有点滑稽,因为 “开源 ”这个词本身就是为了让人们能够寻求资金来建立公司,而建立公司的基础是(疯狂的?
          20 年后的今天,这个行业的结构已经发生了变化,现在 “开源 ”的存在是为了养活亚马逊、微软和谷歌。
          如果不能改变定义,将许可条款纳入其中,让超大规模企业之外的其他企业也能持续创造价值,那么这个词就不再适用,我们需要一个新的词
          “公平软件”?

          • 其实不然。当 OSI 试图推行一个社区不喜欢的定义时,他们很快就会失去公信力(参见开源 AI 风波)。
            OSI 和 FSF 都同意,对特定用例有禁令的可用源不是 FOSS。当理查德-斯托尔曼(Richard Stallman)反对你的时候,你必须做得更好,而不仅仅是大喊 “企业占领”。与他的 “自由 ”理念打交道,而不是树立稻草人。

            • OSI 和 FSF 出于不同的原因达成了共识
              > OSI 和 FSF 都同意,对特定用例有禁令的可用源不是自由和开放源码软件。
              嗯……是的,因为他们决定了术语的定义
              > 当理查德-斯托尔曼(Richard Stallman)反对你的时候,你必须做得更好,而不仅仅是大喊 “企业占领”。与他的 “自由 ”理念打交道,而不是树立稻草人。
              斯托尔曼对自由(本身就是一个多层面的术语)有非常特别的看法
              他完全拒绝接受 “开源 ”一词,这一点非常有名
              我们现在所处的局面是,三个日益邪恶的实体控制并攫取了编写和销售源代码软件所产生的 100% 的价值
              如果你是这些实体的雇员,那就太好了
              对我们其他人来说,这是一个糟糕的处境
              当然也不可能产生另一个红帽公司

              • AGPLv3 或更高版本既自由又开源,在我看来,它应该是大规模采用的首选许可证。

            • 我同意 OSI 和 FSF 被其最铁杆的追随者所困,无法有效改变,假设他们甚至想改变的话。
              至于斯托尔曼……他的自由理念范围非常狭窄。尤其是,他对业余爱好者和巨型公司不加区分,在经济学方面完全盲目。
              它把业余爱好者和公司混为一谈,犯了把人权延伸到公司的错误。当然,这在美国并不是什么新鲜事,自 1886 年臭名昭著的圣克拉拉县诉南太平洋铁路公司的法庭案件确立了公司的 “人格 ”以来,这就不是什么新鲜事了。

              • 公司是人类的集合体。在某些方面,将人权延伸到公司是错误的,但允许公司使用免费软件并不是其中之一:要么公司中的个人能够使用软件,要么他们不能,如果他们不能,那么软件就不是免费的。

          • 看看 Debian 的哲学:https://www.debian.org/social_contract#guidelines
            这比 OSI 的定义还要早。其理念是关于什么能赋予用户权力。商业模式(或其挑战)与此无关。
            赋予用户权力的同时也赋予了竞争对手权力。

            • > 赋予用户权力的同时也赋予了竞争对手权力。
              在我看来,版权许可对用户更有利,而许可对竞争者更有利。但人们仍在继续使用许可。

              • 亚马逊提供的托管 Grafana 服务是 AGPL。我不太确定。

                    • 谢谢,有意思!
                      在这种情况下,这意味着它不是 AGPL,而是专有的。这也证明了我的观点:他们显然是在付钱给 Grafana Labs,以避免 AGPL 的限制。如果 Grafana 是允许的,他们肯定不会付钱。

            • 你不会把十诫作为唯一的道德指南。
              格局已经改变。谷歌、亚马逊和微软正积极试图摧毁开源商业模式。不要因为过于执着于自己的意识形态,而让豹子吃掉你的脸。

              • > 不要让豹子吃掉你的脸,因为你太执着于自己的意识形态。
                你在混淆意识形态。以用户为中心的意识形态不在乎商业模式。豹子不会吃自己的脸。它们在哪里都很好。
                以商业模式为中心的意识形态可能会在乎,但 AGPL 已经存在,并且符合 Debian 的要求。那些在乎的人可以根据自己的意愿选择使用或不使用。

          • > 问题在于,开源的定义是由开源计划控制的,而开源计划已被超级计算机所控制。
            感谢您指出这一点。
            这是我在过去十年中注意到的:
            围绕着开源,出现了很多虚假的、被俘虏的组织。有一次,我在兔子洞里试图列出一个清单,很快就发现了十几个这样的组织。我们总是很难理解这些组织是做什么的,它们雇用了一群通常从未写过一行代码的人。
            Fedora 网站上的一个例子是 “数字公共产品联盟” [0] [0]
            – [0] https://www.digitalpublicgoods.net/

          • > 问题在于开源的定义是由开源计划控制的,而开源计划已经被超级计算机所控制。
            我不确定这是真的。OSI 对开源的定义似乎从 2001 年[1]–AWS 成立之前–就没有改变过,而且从 1997 年开始就以各种形式存在。
            这是微软 2001 年的 “共享源代码许可证 ”时代,该许可证故意与 GPL 不兼容;该定义的作者 Bruce Perens 写道:”微软的共享源代码计划认识到,开放源代码模式的开放性、社区参与和创新有许多好处。但这一模式最重要的组成部分,也是使其他所有模式发挥作用的组成部分,就是自由。[2](佩伦斯还认为第一版 “苹果公共源代码许可证 ”不够自由[3])。
            他们一直认为,不仅可以查看源代码,还可以对其进行修改、重新发布修改后的版本、将其合并到其他软件项目中、将其用于商业用途,等等等等。
            碰巧的是,早在 AWS 出现之前就采取的这一立场对 AWS 来说非常有效。
            [1] https://web.archive.org/web/20020126171934/http://opensource… [2] https://web.archive.org/web/20010813210224/http://perens.com… [3] https://web.archive.org/web/20010430042835/http://www.perens

            • 我认为,这并不是 “碰巧 ”让 AWS 受益,而是因果关系: 开源创造了 AWS。AWS 的结构就是为了从开源中获益,而它也正是从开源中获益才发展到现在的规模。
              在很多方面,像 AWS 这样的东西正是 OSI 向企业推销自由软件理念时想要创造的。这就是他们的推销。

          • > 公平软件”?
            这是最常用的术语!我看到许多不同的努力都开始围绕这个主题展开。
            https://fair.io/
            这也是一个非常不错的许可证:
            https://defold.com/license/
            我们需要这样的许可证来对抗亚马逊、谷歌和微软。现在,“开源 ”就是他们的骗局。

        • 没错。事实上,如果Redis最终能加入CNCF,Redis实验室能提供商业托管和扩展,这将会是一个令我兴奋的结果。

      • 有趣的是,他们的首席执行官称 AWS 和 Google 将 Redis 分叉并单独维护是他们一直以来的 “目标”。因为碎片化显然是好事?

        • > 因为碎片化显然是好事?
          我认为这更像是 “他们不再免费搭我们的便车”。
          我还认为他们真正想要的是“……而且他们还付了我们钱”。

          • ValKey 的分叉之所以发生得如此之快,是因为 AWS 已经在赞助开源 redis 项目的开发人员了。

            • 而且不仅仅是 “一些开发者”,而是 Redis 核心团队的一名成员:https://redis.io/blog/redis-core-team-update/

              • 是啊,“他们什么也没给 ”这句话可能是围绕这些变更的公关中最糟糕的部分。对于熟悉生态系统的人来说,这显然不是真的,这在最重要的人眼中损害了 Redis 论点的可信度。

      • > 两家公司都没有建立法律安全机制,防止日后再次出现问题
        以前的版本在原始许可证下仍然可用,对吗?因此,如果你不想使用新许可证,你的处境就和公司倒闭或因其他原因停止支持和开发一样。在这方面也没有安全机制。

        • 现有的安全机制就是像 Linux 那样:使用版权许可,不使用 CLA。这样,贡献者之间就可以共享版权(因此不可能更改许可证),而且许可证会强制要求共享你对项目的修改。

      • 法律安全机制是许可证。他们根据特定许可证向你提供软件,只要你遵守许可证的规定,就没有问题。如果他们以不同的许可证提供不同的软件,你也不必删除它。
        如果你确实需要不断更新,你可能会更相信分叉软件不会转换许可证,但分叉软件消失的速度往往与原版软件转换许可证的速度差不多,这又有什么关系呢?这就是依赖免费东西的本质–你只能任由发放者摆布。

      • 这似乎正在加速。我猜,点燃投资资金并假装火焰等于成功的时代即将结束。
        当然,除非你是一家人工智能初创公司。

    • 在一个项目的早期,我为它做出了巨大贡献,并花了将近两年半的时间帮助它成长。有一段时间,我是最活跃的贡献者之一。
      后来有人说要把这个项目变成一个真正的企业,我和几个最初的贡献者都得到了薪水极低的工作。没人接受。后来他们有了首席执行官和投资人,我们基本上被迫退出了项目,除非我们加入公司。
      我清楚地记得,在一次通话中,我们被告知他们最终会重新授权,并推出 SaaS。为了保护我们的工作不被大公司使用。我笑着指出,在那次通话中,你们也在做同样的事情,这真是讽刺。
      之后,他们改变了政策,不接受外部公关。这让他们对支持个人项目之外的开源项目失去了兴趣。

      • 你签署了贡献者许可协议吗?如果没有,那么我敢肯定,在未征得你同意的情况下,保留你的修改并重新授权是违法的。

      • 如果你是最活跃的贡献者,你完全可以自己把它分叉,作为 SaaS 推出,然后当首席执行官。

        • 不是每个人都想当 CEO。有些人只是想写一些好代码,为世界做出贡献。

        • 我只是想做一个帮助开发者的工具。但当 SaaS 推出后,他们却把重点放在了添加价值数美元的功能上,而不是修复错误,并且在你使用该工具的任何时候都开始大力推广他们的 SaaS。
          最后,他们在上一个版本中改用了一种糟糕的模式,即如果你是一家企业,或者无论如何都要赚钱,你现在就需要支付许可证费用,而且费用高得离谱。
          现实情况是,我本可以将其分叉,但我没有时间和耐心去处理一个大型项目带来的所有问题。

      • 不完全是。公司可以随时轻松更改许可证。没有附加条件。

        • 我相信 AGPL + 时间 + 贡献者会让这变得非常困难。这也意味着,如果你有一个使用 Redis 的商业产品,你需要开源你的东西,所以并不是净更好的 imu。如果我说错了,请指正。

          • 这完全取决于他们是否有 CLA。有 CLA == 继续轻松拉毯子,没有 CLA == 随着时间的推移,拉毯子越来越难。

          • 不,这并不意味着如果你的商业产品使用 Redis,你就需要将其开源。AGPLV3 并非如此。如果你对 Redis 做了任何改动,如果你的产品是通过网络发布的,你就需要开源。

            • > 你需要开源你对 Redis 所做的改动
              我很确定,AGPL 会让你把修改内容发布给用户,而不是 Redis。

              • 典型的运算符优先级混淆。不过这句话写得很好:
                你需要(开源)(你对 Redis 所做的修改)
                即 “您需要将[您对 Redis 代码库所作的更改]开源”。

    • 同样。我很尊重 antirez 和他所做的一切,但他重新雇用开发人员的做法让人感觉像是在 Redis 公司的荒唐举动之后试图吸引开发人员回来。
      既然有可行的替代方案,我认为没有理由再在 Redis 上投入时间(我们正在使用 Valkey 作为替代方案)。

      • 考虑其他选择并没有错,但 Redis 公司并没有邀请我重新加入。我找到他们,希望能做一些类似于布道者的工作,并在内部带回一些社区愿景。然后……如果你会编码,你就会经常编码,我没有做布道者,而是写了向量集数据类型:D 只是想澄清一下,我重新加入并不是什么 “赢回社区计划”。我写了很多关于这一切的文章,甚至明确指出,即使是薪水也不高(以避免经济动机的利益冲突)。

      • 我基本上在每个项目中都会使用 Redis,而这一 “荒唐 ”的举动对我使用 Redis 的影响简直为零,所以这可能有点夸张。
        SSPL 并不像开放源码软件社区假装的那样糟糕(除非你是一个超级分压器)。

    • 我同意。至少在可预见的未来,这艘船已经扬帆起航。我们已经换成了 Valkey,而且它也是我们即将开展的几个项目的首选。在经历了这番折腾之后,现在再换回来就完全没有意义了。

      • Garnet 让我着迷。他们的基准测试甚至称其优于 Redis 和 Dragonfly。有没有任何论文或文章可以解释 Garnet 为什么这么快? 我知道它是基于 FASTER 的

        • 简而言之,它只是一个连接到 TCP 服务器并带有日志的无锁哈希表。简单的获取/设置操作经过了高度优化,因此在高批处理的情况下,它们能够高效地获取大量数据。当添加线程和统一数据访问时,该架构的扩展性非常好。
          在某些类型的工作负载(如热键)上,这种架构会有些吃力,比如重击单个排序集。这是一个很酷的架构。

          • 除了拥有一个快速的哈希表,它还有更多的功能:https://www.microsoft.com/en-us/research/wp-content/uploads/…
            (我想,实现弹性存储和大于内存数据大小的机制将是难点所在)

          • 这… 和你对 KV 存储的期望差不多。这是网络上的哈希表。

            • 不同的是,Redis 是单线程的,Redis 的价值主张是快速(内存中)、简单(单线程)服务器,提供比传统 DB 快得多的服务。它非常适合 Ruby/Rails 社区等使用,并广受欢迎,因为与 Redis 这样的快速服务器相比,这些环境与传统 SQL 服务器结合在一起就显得非常吃力。
              虽然 Redis 很好,但现代计算机的多核性能可能会大打折扣。Garnet 似乎是一个设计精良的多线程 KV 存储(不过遗憾的是,即使简单的情况看起来不错,基准页面也没有列出更复杂对象的基准)。

      • 是的,这完全是用纯 C# 重新实现的。它建立在 MSR 的 FASTER KV / Tsavorite 项目之上。

      • 不错。我一直使用 Memurai (https://www.memurai.com/) 在 Windows 上进行开发(原生,没有 WSL 或 Docker,原因是),但这个看起来要好得多。
        编辑:奇怪的是,作为微软的一个程序(好吧,它是微软研究院的,所以这大概可以解释得通?),它没有安装程序,也不能作为服务单独运行。

        • readytorun 压缩包中包含一个服务 exe,它确实需要 “sc create binpath= ‘’等才能作为服务运行。

        • 10 年前 HN 上的传统观点认为,微软研究院只是付钱给一些顶级研究人员(他们有商业利益),让他们继续做自己的事情。我不会因为他们的雇主而不信任那里的任何人。这是一个对微软不甚了解的人说的。

          • 哦,别误会,我不是不信任他们,只是微软研究院的一些项目比较粗糙!

      • 哇 第一次听说石榴石。MS 应该将其打包部署为 Azure SAAS 产品中的一项服务。

          • 微软有 “伪造 ”开放源代码的习惯。尤其是在 Github 上。
            所谓 “伪造”,我的意思是微软在很大程度上把他们的开源代码库当作闭源的、内部专有的代码库,碰巧让公众查看。
            他们偶尔也会接受 PR,但大多数情况下,Issues 和 PR 被用作 UserVoice 的免费替代品。
            每一个决定都是闭门做出的(实际上可能是 MS Teams 电话),你会发现他们的员工在这些项目上是多么的头重脚轻(在任何给定的 repo 上都有半打员工的头衔是 “经理”)。
            乞丐是没有选择的,我很高兴他们涉足自由和开放源码软件领域……但他们在 Github 上的项目并没有给我带来自由和开放源码软件的感觉。

            • 开源并不意味着接受他人的贡献。它指的是源代码是可用的,人们可以自由获取并自行修改。你使用的定义……并不完全错误,因为定义就是定义,但肯定不是其他人使用的定义。

            • 你混淆了开源和开放贡献。难道 SQLite 不是开源的吗?

                • 拥抱、扩展、消灭 “来自于开源还不是基础设施默认设置的时代。
                  我不知道你怎么能消灭一个获得 MIT 许可、在全球拥有一百万份拷贝的东西。

                    • 让我印象深刻的是,微软竟然没有将其 Redis 竞争对手命名为 “Cache”,而是像其他许多产品一样污染了密钥空间。

                  • 我想这取决于你对 “熄灭 ”的定义和其他一些事情,但是:
                    在麻省理工学院授权的 VSCode 代码库上疯狂地打手势
                    是的,他们并没有篡改 VSCode 的源代码,但通过锁定市场(并且从未提供真正开源的 VSCode,即开发者眼中的 “VSCode”),他们正在锁定分叉。

                    • 啊,这就像安卓的开源(几乎)总是扯淡一样。你必须跳各种谷歌舞蹈,才能在上面安装谷歌应用。
                      有道理!这是一个试图消灭的好例子。

                    • 我非常同意对 Android 的比较,几天前我也对 VSCode 做了同样的比较:https://news.ycombinator.com/item?id=43787009

                • 微软会在 2025 年这样做吗?
                  说真的,我已经很久没有听说他们这么做了。我知道他们在 90 年代和 00 年代很糟糕,这一点我完全没有异议。但在过去的十年里,他们有继续这样做的例子吗?
                  此外,当时做出这些决定的人中有很大一部分已经不在公司了,负责人也换了,等等。业界已经改变了与开源软件的关系–公司董事会已经不再害怕在服务器上加载开源软件的后果,合法性和责任问题也已经解决,MS 甚至不再有能力拉动这些恐惧的杠杆。MS 本身已经在行业中重新定位–他们在计算领域的全面统治梦想已经破灭:windows 的衍生产品已经不可能再拥有服务器市场,浏览器或消费者操作系统也没有利润可言(甚至 MS 在游戏领域的统治地位也因为 valve 的努力而出现了裂痕)。关键是–他们再去尝试 EEE 任何东西,会有战略意义吗?
                  注:我与 MS 几乎没有任何关系。在 covid 之前,我就没有使用过 MS 操作系统或桌面软件(无论以何种身份,甚至是在运行 Windows 的电脑上移动鼠标)。我个人或专业上都不使用他们的任何 SaaS 产品。我帮助构建的产品与 azure 之间有集成,但这些并不是我雇主的主要收入来源,而且我做的工作也很少涉及这些东西。重点是–我在生活中非常不喜欢 MS,也没有任何忠诚度或动机去维护它们。我确实对他们在 90 年代和 00 年代的 EEE 行为深恶痛绝,这些行为至今仍让我感到愤怒……但这并不能成为假定一家公司的不同员工会采取与老派员工相同行为的理由。

                  • 几天前刚读到这篇文章,所以也许行为比以前好了,但仍然如此。链接如下:https://news.ycombinator.com/item?id=43750535

              • 也许吧……当我看到一个开源代码库时,我希望它不仅有你可以阅读的源代码,而且还有一种贡献和与代码库创建者互动的方式,而不仅仅是错误报告(又名 Github Issues)。
                虽然从技术上讲,微软的代码库可能是开源的,因为它有许可证,而且你可以从字面上去查看源代码,但微软却把这些代码库当作专有代码库来运营。每一个决定都是在公开的情况下做出的,如果他们有自己的内部跟踪器来跟踪 “真正的 ”积压项目,我也不会感到惊讶。在 Github 上,微软员工的讨论几乎为零,即使有,也是经过公关过滤的。
                就像我说的,乞丐是没有选择的,有总比没有好,但我真的不认为微软已经掌握了自由和开放源码软件的真正概念。
                > SQLite 不是开源的吗?
                在我看来也不是。你根本无法做出贡献……你能做的就是在论坛上就你希望解决的特定问题大吵大闹。因此,虽然从严格意义上讲它是开源的,但从一般意义上讲它不是开源的。

                • 一个项目是由社区开发的,还是由掌握所有钥匙的单一实体开发的,这与是否是开源/自由软件完全无关。将一种项目置于另一种之上并没有错,但如果你想保持交流,你可能需要修改 “你的观点”,因为只有当人们对术语和定义的含义达成一致时,它们才是有用的。

                • 我认为大多数项目都是这样的,即使是那些更认真地接受外部贡献的项目。我理解你为什么会把开放贡献与开放源代码联系起来,但我认为把这种关系视为必要而非常见是错误的。
                  如果你还没读过,兄弟姐妹的评论中包含了一些对微软更尖锐的批评。

                •  > 你能做的最好的事情就是在论坛上对你希望解决的某个问题大肆抨击。
                  

                  关于 SQLite,你有什么具体问题吗?

                  另外,您是否有自己编写、维护并接受贡献的开源项目?

            • 我做了一个开源的、MIT 许可的软件。我不接受不请自来的贡献,但我在文档中说明人们可以自由地 fork 代码,并提供如何在你的机器上开发、测试和构建的说明。

              我是 “假开源 ”吗?

              • 在我看来,开源的精神不仅仅是把代码扔到墙上让人看。在我看来,它意味着接受用户的参与,接受他们的意见,并在必要时做出贡献。

                在我看来,要想真正做到开源,我就应该能够修复我遇到的一个错误,或实现积压功能中的一个功能,并将其贡献给上游。如果上游无视我的贡献,假装它不存在,或者仅仅因为这个原因就拒绝它,那么这个代码库就是在假装开源。

                这并不是说你必须接受所有的贡献,我是说你应该对以下贡献持开放态度:A)节省你的时间;B)增强代码库;C)修复已确认的错误。

                就微软而言,我并没有看到很多这样的贡献。我看到的是大量的问题(错误报告)、一些公关,但大部分都是不透明的决策,以及对微软公司方面还不想发表评论的事情的完全沉默。这就是问题所在–它是一个企业项目,运行起来就像一个专有项目,但你可以去看看代码。同样,有总比没有好,但我认为这不是真正的开源。

                • > 在我看来,开放源代码的精神不仅仅是把代码扔到墙上让人看。在我看来,这意味着接受用户的参与,接受他们的意见,并在必要时做出贡献。

                  我不同意。开放源代码或各种开放源代码许可都不要求接受社区的参与和/或贡献。

                  开源意味着允许修改,并分享这些修改。大多数许可证都规定,软件按原样提供,不提供担保。

                  > 在我看来,要想真正做到开源,我就应该能够修复我遇到的错误,或实现积压功能中的某项功能,并将其贡献给上游。如果上游对我的贡献视而不见,假装它不存在,或者仅仅因为这个原因就拒绝它,那么这个代码库就是在假装开源。

                  一个不接受外部贡献的项目仍然是开源的,而不是假装开源,它的美妙之处在于–如果你想让它接受外部贡献,你可以分叉它,在你自己的分叉上接受贡献,或者分享你的修改。但原始开发者/所有者绝对没有义务接受或参与社区的任何贡献。许可证中规定,软件按原样提供,没有任何担保。

                  也许应该创造一个新词–“社区软件”(community software),以明确区分社区开发(接受贡献)与不接受贡献的项目。

                • 哇,这也太夸张了吧?

                  我想说的是,开源的精神在于他人可以自由修改代码,仅此而已。这需要一个良好的许可证、分叉的可能性、一些文档和自己构建项目的方法。

                  但为什么需要接受贡献呢?

                  • 很多人都很有权利。他们认为开源项目赋予了对项目提出要求/需求的权利。即使他们愿意自己撰写贡献,他们仍然认为自己有权让拉取请求被接受。他们忘记了:1)这可能超出了项目的范围;2)项目所有者必须实际维护他们提交的代码。太疯狂了。

                • 如果你想实现某个功能,但他们却没有时间检查并确保其安全性,或者支持未来的错误,那该怎么办?看看 xz(IRC)的黑客攻击–不是每个人都有大量的空闲时间。

                  他们需要在发布代码后多长时间内保持这种状态?他们需要在 5 个工作日内回复你的请求吗?

                  如果他们退休或转到另一个项目,源代码是否就不再开源了?

                • 我也有同感。我已经习惯了基础设施以民主的方式运行,而不仅仅是 “在 GPL/BSD/MIT 下提供源代码”。(当然,这是件大事,但我不介意做大事)。

              • 我认为不是。开放源代码的定义并没有提到要求外部贡献,而且从一开始,开放源代码的精神就与此无关。

                它是关于能够访问、分叉/修改和重新发布软件。这才是最重要的–我可以修改我使用的软件,如果我想这么做,许可证允许我重新发布这些修改,而专有软件则不能修改或重新发布。

                我不知道为什么时代的潮流从上述变成了 “所有开源软件都必须是社区软件,必须与用户互动并接受贡献”,因为这从来不是它的初衷。当然,这是某些项目的好处,但归根结底,重要的不是项目是否接受贡献,而是我是否有权力和许可来按照自己的喜好修改某些东西,如果我喜欢,就把它分叉,和/或重新发布我的修改。

            • 这怎么是 “假的”?开放源代码项目根本不需要外部人员的贡献。

            • 这种认为开源项目不欢迎所有贡献就不算真正开源的想法是世界上最愚蠢的想法之一。

              • 我曾在一些拥有大型开源项目的地方工作过,看到这种观念如此普遍,真是大开眼界。我感觉在我的一生中,开放源码软件的价值/期望/要求/定义已经从 “源代码是可用的,如果需要,我可以对我自己的拷贝/文件进行修改 ”转变为 “源代码是可用的,我会要求你为我进行修改”。

                • > 源代码可用,我会要求你为我修改它

                  这里似乎有些脱节。我同意,要求别人为你做修改是很没品位的。问题是,有些项目在宣传自己是开放源代码的同时,却没有任何有意义的方式将修改意见反馈给上游–即开放源代码的精神。

                  如果我免费使用你的程序,并遇到了一个错误,我应该能够修复它,并把它贡献回上游,让每个人都受益。这是我 “回报 ”和帮助社区的方式。拒绝贡献或使贡献变得困难的项目不符合开放源代码的精神,即使它们在技术上是通过许可证开放源代码的。

                  这就是我所说的 “假 ”开源–你只想获得开源的正面形象。

                  • 为了 “帮助社区”,你可以自由地 fork 他们的代码、添加你的修正、开放错误跟踪系统、开设论坛、保证响应时间等等。

                    不是每个人都有时间做第二或第三份全职工作的。

                  • > 这里似乎有些脱节。我同意,要求别人为你做修改是很没品位的。问题是,有些项目一方面标榜自己是开源的,另一方面却没有任何有意义的方式将修改贡献给上游–即开源的精神。

                    我的意思是,你并没有要求别人做修改。你只是要求他们参与进来,围绕他们的项目建立一个社区,以及由此带来的一切。

                    只要许可证是合理的,其他人都可以接手这个项目,并围绕它开展社区建设。Apache HTTP 服务器就是围绕 NCSA httpd 的社区补丁开发的。我不认为 hitch(来自为你带来 Varnish 的公司)是众所周知的,但它也是以社区补丁的方式开始的。如果像这样的东西流行起来,发起者要么也开始使用社区补丁,要么就不使用;这是他们的选择。

                    在此期间,作为用户,我可以从源代码提供的任何修改中获益,也可以随心所欲地打补丁,修复我发现的问题。这适用于代码转储开源和社区开源。

            • Garnet 有一个 Discord 服务器,而且一直在积极接受社区 PR,所以我不知道你在说什么胡话。

              .NET有什么让你不得不撒谎的?

              另外,正如兄弟姐妹的评论所指出的,FOSS 和开放贡献是两码事。

                • MIT 是限制最少的许可证之一。

                  如果你不这么认为,我建议你看看头上有没有铝箔。

                  • 自由软件的许可证可以保护你的自由。MIT 许可证则不然。

                    你真的不知道这一点吗?如果是,为什么?是年龄问题还是你受到了某种程度的庇护?

                    • 自由软件就是你可以自由使用或修改的软件。

                    • 太含糊了。自由软件是指你不能拿去修改,然后把你的修改隐藏起来或归你所有,从而剥夺你的用户和社区获取这些修改的权利。

                      MIT 许可证允许这样做,因此它不是自由软件许可证。因为大公司不喜欢自由,所以他们毒化了围绕软件自由的讨论,并发起了公关活动,试图用开放性或开放源代码来代替自由。在某种程度上,他们已经成功了,本主题中的相关讨论就是证明。

                  • 作为最终用户,我觉得这很有限制性。有些软件我可能无法分叉/修改,因为它们是麻省理工学院的。我不再是软件的所有者了。

                    • “MIT 许可 (MIT) 版权 © 2025 <版权所有者>。

                      特此免费允许任何获得本软件及相关文档文件(“软件”)副本的人不受限制地使用本软件,包括但不限于使用、复制、修改、合并、发布、分发、再许可和/或出售本软件副本的权利,以及允许任何人……”

                      https://mit-license.org

                    • MIT 许可证始终允许您分叉/修改项目。你不是你的 fork 中现有代码的版权所有者,但你可以是项目的所有者,也可以是你添加的任何新代码的版权所有者。

    • 我有这种感觉。我也生活在现实世界中,知道除了少数几个公司(最著名的是 RedHat),没有人知道如何在开源领域持续赚钱。这些封闭式许可证并不是凭空出现的。它们的出现是为了应对 AWS 等公司利用开源许可在项目中牟利的情况,而且这样做是合法的(许可中规定可以这样做),但这样一来项目就会受到影响。因此,修改许可证就是为了防止这种情况发生,这样项目表面上就能存活下来。这是有道理的。想要实现开源的承诺也是如此。这确实是个棘手的问题。

    • 失去信任是肯定的。如果 Valkey 不存在,谁知道 Redis 现在会不会是 AGPL。

    • 在这类项目中使用非版权许可的唯一真正原因就是能够进行 “拉地毯”,所以你应该预料到这一点,而不是觉得被背叛了。

      我猜他们现在会要求外部贡献者转让版权或类似的东西,以便能在商业许可证下重新许可新代码。

      • 像 AGPL 这样的版权许可并没有阻止 MongoDB 的肆意妄为。我认为,AGPL 以及随之而来的版权转让会让 “rugpull ”变得更容易,因为与闭源公司相比,“分叉 ”实体在维持正常运营方面处于极为不利的地位。另一方面,非版权许可使分叉公司更容易覆盖与原公司相同的所有利基市场,从而使剽窃变得更加困难。

          • MongoDB 曾经是 AGPLv3。首次公开募股一年后,他们意识到 “该死的,华尔街想要的是持续增长,仅仅盈利是不够的”,于是决定迁移到一个全新的许可证–SSPL,该许可证旨在将软件周围的一切纳入版权保护范围。这意味着,如果亚马逊提供 MongoDB,他们也必须发布所有 AWS RDS[0] 软件,让用户可以下载使用。

            社区对此一点也不喜欢,但 MongoDB 不需要关心社区的想法,因为他们已经对所有贡献者进行了 CLA。也就是说,如果你想在 MongoDB 上游获得某些东西,你必须给予 MongoDB 对软件的完全版权所有权。这使他们免于 Copyleft[1]。Copyleft 的关键部分之一是 “不再限制 ”规则;否则,Copyleft 就只是附加了额外步骤的专有权而已。

            [0] 我不记得他们是将 MongoDB 作为 RDS 的一部分托管,还是其他什么。

            [1] 正如我们在 Neo4J 诉讼案中看到的,版权许可不能束缚版权所有者的手脚。要想让版权许可发挥作用,唯一的办法就是让贡献者之间形成墨西哥式的对峙,如果其中任何一个贡献者决定在社区未达成一致共识的情况下重新授权,他们就会互相起诉,直至对方死亡。

            • AWS 从未提供 AGPLv3 许可版本的 MongoDB 服务器作为任何托管服务的一部分。中国有一些大型云提供商确实提供了 MongoDB 服务。他们还提供了相应的源代码[1]。尽管有迹象表明他们遵守了许可义务,但他们还是起草了 SSPL。

              因为一旦软件即服务显然是一种令人信服的模式,给予每个人将软件作为服务的一部分提供所需的权限(AGPLv3 的设计初衷)就不再有吸引力了。

              改变许可证似乎奏效了,因为最终宣布了合作关系[2]。

              [1] https://github.com/Tencent/CMONGO

              [2] https://www.mongodb.com/company/newsroom/press-releases/tenc

      • > 在这类项目中使用非版权许可的唯一真正原因就是可以拉地毯。

        这有点夸张。绝大多数许可项目从来没有也永远不会 “拉地毯”。这可能是选择这种许可的一个原因,但远远不是唯一的原因。

      • 你知道版权所有者可以根据他们想要的任何条款重新授权,即使是 GPL 这样的版权许可,对吗?

        • 除非 CLA 将版权转让给项目所有者,否则版权所有者就是项目的每一位历史贡献者。每项贡献都归贡献者个人所有,只有他们才能授予权利。

          内容共享协议通常试图通过让贡献者在贡献时赋予项目所有人特殊权利来减轻这种情况。

          (请注意,即使是重新授权,这本身也不能取消为先前版本授予的许可,除非该许可中特别写明了撤销)。

          • 是的,一个项目只有在所有贡献者都签署了转让许可权(而非所有权)的 CLA,或者所有代码都归重新许可的实体所有的情况下才能重新许可。至于是在版权许可、许可许可还是专有许可下,这都无关紧要。

      • 我们有充分的法律理由避免使用 GPL;关于 GPL 及其变体是否可以执行,还存在一些法律问题。

        •  > 关于 GPL 及其变体是否可以执行,还存在一些法律问题。
          

          在历史上,曾有多起违反 GPL 者被送上法庭并败诉或和解的法律案件。参见 BusyBox 和 Linksys/OpenWrt。

          GPL v3 还有一个很好的条款,允许公司 “修复/恢复 ”他们的违规行为。

           > 此外,如果版权持有者以某种合理的方式通知您违反了本许可,这是您第一次收到该版权持有者关于违反本许可(任何作品)的通知,并且您在收到通知后 30 天内纠正了违反行为,那么您从特定版权持有者处获得的许可将永久恢复。
          

          红帽公司也有一篇很好的博文,介绍了他们对使用法律系统来强制遵守的看法:https://www.redhat.com/ja/about/gplv3-enforcement-statement。

        • 您的评论在逻辑上有缺陷

          如果这是你避免使用 GPL 的 “良好法律理由”,那么这也同样是你根本不开源你的作品的 “良好法律理由”:如果 GPL 不可执行,那就意味着你使用了非版权许可,而根据你的说法,这正是你出于良好法律理由想要避免的。

          • 我没说你应该避免使用非版权许可?事实上,我自己的所有开放源码软件项目都是非版权许可的。

            • 宽泛地说:

              原因是什么?因为 “无法执行”,所以你排除了 gpl 的考虑,而主张使用非版权保护许可。

              你同意我的观点吗?

              但 gpl 的 “不可执行性 ”只能意味着它变成了一种非版权法许可,而你说人们不应该使用这种许可,所以如果人们不应该使用 gpl,因为实际上它是一种非版权法许可,那么你一定是反对非版权法许可的。

              为了清楚起见,我再说一遍: “不要使用 gpl,因为 copyleft 是不可执行的,所以 gpl 只是 MIT 下的许可证,我再说一遍,不要使用它 “是建议不要使用 MIT 许可证。

              • 请链接到我说不要使用 Copyleft 许可证的地方。请仔细检查用户名。

                请注意,我不同意 GPL 和 MIT 是等同的,也不同意 GPL 在不可执行的情况下成为非版权保护的开源许可证。虽然我不懂法律,但无论你在哪里发布软件,都可能会恢复正常的版权法,而不是开源许可证。

                • 老实说,你不喜欢 GPL。你不喜欢 GPL 的原因并不是因为它不可执行,而是因为你不想执行它,或受到它的约束。正如我所指出的,你说你使用 MIT 是因为 GPL 无法执行,这种说法毫无意义。

                  (另外,GPL 是可以执行的,而且已经执行,但这是另一个话题)。

      • 所有优势都归属于 hyperscaler “托管 ”版本。这可比 “拉地毯 ”操蛋多了。

        亚马逊可以从你的产品中赚取数百万美元。

        带有 MAU / ARR 限制、超级分销商转售限制和类似 AGPL 的 “整个堆栈必须开放 ”条款的 “公平源代码 ”许可才是王道。这是对亚马逊、谷歌和微软的 “去你妈的”,让你无动于衷。

        如今,开源就是超级分销商的农奴制。在裸机上运行 Redis 的组织少之又少,而公平的源代码许可可以始终支持裸机情况。

        • 作为一个开源爱好者,钱是如何毁掉这一切的,真让人难过

          • 如果你开放源代码,那些富有的万亿美元公司就会窃取它。

            如果你能接受,那很酷。但他们会从你的工作和劳动中获利。最糟糕的是,在规模上,开源总和的优势被用来与你竞争,并对你的薪水和职业选择施加价格压力。换句话说,超大规模企业可以利用开源技术,抓住你无法抓住的市场机遇,并以此与你的企业或其他企业竞争,而这些企业可能会给你更高的薪水。

            开源需要反谷歌/亚马逊/微软条款。

            • 他们没有窃取任何东西,他们使用的是项目开发者授予的权利。

            • Affero GPL v3 不是涵盖了这一点吗? 我看到一些项目使用了它,我认为它限制了软件的服务器运行部分等。

              • 是的,确实如此!AGPL3 的 “问题 ”在于,它没有为规模小于亚马逊、微软或谷歌的公司提供例外条款。如果使用 AGPL,就必须开源整个软件栈。

                不是每个人都认为传染性的版权/自由软件是个问题。但这意味着,如果你使用 AGPL3,你的软件栈的每一部分都必须开放。这对每个人都不适用。

                这就是为什么 “公平源代码”/“公平源代码 ”越来越受欢迎的原因。你可以使用 Apache 这样的许可证,并在其中加入 MAU/ARR/Hyperscaler 限制条款,这样几乎每个人都可以使用你的软件。

                • 不,SSPL 要求您开源整个堆栈。这就是 OSI 和 FSF 拒绝它的原因。

                  AGPLv3 规定,如果你修改了软件并将其放到网络上,你必须提供一个链接,让任何访问该软件的人都能下载修改后的源代码。这种安排有许多起草和技术上的问题[0],但你必须发布的堆栈中的唯一部分是 AGPLv3 所涵盖的程序的实际部分。

                  强版权 “策略[1]是找出我们不喜欢的限制自由的特定行为,并加以禁止。我们不是在说 “亚马逊不得使用该软件”,而是在说 “任何将该软件转化为服务的人都需要提供一种方法来分叉该服务,并在不损失任何东西的情况下拿回软件”。如果这样的版权许可碰巧吓到一家公司购买许可例外,那也是意外之喜。

                  相比之下,公平源代码并没有提到自由,它只是说 “这些人需要支付许可费”。这不是自由和开放源码软件,这是共享软件。在自由和开放源码软件中,搭便车不是错误。AWS 的问题不在于他们不支付许可费,而在于他们在社区项目中建造蟑螂旅馆。

                  [0]我本想链接到 Hector Martin 在 Mastodon 上发表的有关此主题的信息,但他在从 LKML 崩溃后删除了自己的账户。作为替代,我将总结一下我朦胧的记忆:

                  – 遵从机制的目的是让你的应用程序成为一个奎因;但这只对用 PHP/Python 等编写的网络应用程序有意义。有人真的把 AGPLv3 放到了以太网堆栈上–你该如何遵守呢?

                  – 目前还不清楚在拉取请求驱动的 Git 工作流程中如何遵守许可协议。如果你在本地运行服务器进行测试,而有人访问了它,你是否违反了许可协议?

                  – 你可以使用不受 AGPLv3 保护的 HTTP 代理过滤掉源代码。这似乎是一个非常大的漏洞,而 FSF 显然认为这个漏洞是可行的。

                  [1] 例如 AGPL、SSPL、OpenWatcom 等。

                • AGPL 并不要求你开源整个堆栈。如果您通过网络与 AGPL 软件进行交互,则只需更改您对 AGPL 软件所做的更改。

                  AGPL 不会也从未阻止超级计算机为获得 AGPL 许可的软件创建托管服务。

                  这就是为什么 mongo 创建了服务器端公共许可证,这确实需要开源整个堆栈。在此之前,MongoDB 是 AGPL

                  • 谢谢你的花絮,我以前不知道,现在对自由和开放源码软件许可有了更多了解

            • 带有反谷歌/亚马逊/微软条款的开源软件被称为 AGPL。

              然而,不知何故,人们一直在 MIT 许可下开发新项目。

    • 如果你在许可证变更/分叉之前做出了贡献,那么你也为 valkey 和 redict 做出了贡献;)

    • > 在原始许可证下对 Redis 做了一个小改进[……],作为一个正式的自由和开源软件代码库的贡献者,感觉被背叛了

      这在法律上是如何运作的?你写了一些代码,在特定的许可证下贡献出来……然后……一家公司就可以在他们喜欢的任何许可证下重新许可你的代码?

        • 如果贡献者许可协议除了将您的代码置于项目的标准开放源码软件许可之下之外,还做了其他任何事情,那就是一个巨大的红旗。

          • 我对 LineageOS 的这种做法有点不满。

            CyanogenMod 要求 CLA 将版权转让给 Cyanogen 公司,而他们却基本上扼杀了该项目。他们将其分叉为 LineageOS,但仍然需要 CLA。

        • 在我看来,人们对源代码可用许可证的愤怒最好是针对 CLA。因为它们将权力拱手相让。

          如果不仔细阅读并了解可能发生的情况,就不要为有 CLA 的项目做出贡献!这样,如果一个项目被重新授权,你就不会感到惊讶了,因为你知道你签署的协议允许他们这样做。

        • 那么 Redis 的所有贡献者都签署了贡献者许可协议?当然有可能,但我会有点惊讶。

    • 如果说有谁背叛了开源精神,那就是那些试图抽走这些项目的全部商业价值,却对项目贡献甚微的人。

      公司必须付钱请人工作。见鬼,他们甚至有权从中获利。一个有商业价值的开源世界比没有商业价值的世界要好得多。为了让 90% 的收入流向价值 1,000,000 美元的云计算供应商而抛弃开放源码软件公司,只会适得其反。

    • 由于许可证问题,我在今年年初开始在全组织范围内从 Redis 转向 Valkey,现在已经没有回头路了。Valkey 是 AWS 提供的更便宜的产品(至少通过 Elasticache),这对 Redis 也没有帮助。

    • 我想知道你为什么选择 Redict 而不是 Valkey?后者似乎更受欢迎。

    • 我认为我们需要回到在文字和精神上都认真对待软件许可证的状态。Redis 所做的过渡在法律和道德层面上都是纯洁的。感觉被背叛是绝对不应该的。

      • > Redis 所做的转变在法律和道德层面上都是完美的。

        是的,当然。

        > 是的,当然。感觉被背叛是绝对不应该的。

        呃,不,那是毫无根据的飞跃。

        • 我不明白为什么 Redis 会被指责为 “揠苗助长”。他们并没有重新授权旧版本。他们只是说:“对不起,我们不想再按照那些条款支持这个项目了”。无论是法律上还是道德上,他们都没有义务这么做。不喜欢?没问题,把它分叉,自己维护(很多人都这么做了)。但如果其他人不愿意,就不要要求他们继续按照这些条款支持该项目。这就是自由和开放源码软件的初衷。

          所有这些人都为 FOSS 版本做出了贡献。他们的贡献在所有的分叉中都得到了延续,包括自由和开放源码软件和专有软件(亚马逊等公司,以及今天之前的 Redis)。所以,我不知道 “背叛 ”究竟发生在哪里。也许是亚马逊也使用了他们的贡献?

      • 撒谎不好吗?他们曾公开声明 “将始终保持 BSD”,https://redis.io/blog/redis-license-bsd-will-remain-bsd/。

        • 在 GPL 可以使用的情况下,他们选择了 BSD,这已经是一个强有力的声明了。这比某些反映他们一时计划的博客文章要有力得多。

          只是,人们不会听到他们不想听到的东西。每一个 BSD 或 MIT 都是一个响亮而明确的声明,否认保证衍生作品将保持自由和开放。

        • 允许人们和公司改变观点,为什么会有人责怪 Redis 或 Elastic 而不是亚马逊拿走了这一切?

          • 因为 Redis 说过他们永远不会做某件事情,然后又改变了主意(这使得说永远不会做某件事情的整个概念变得毫无用处),而亚马逊从未说过他们不会免费使用开源软件(这是他们的权利)。

            • 你不是在为个别公司的诚信而争辩,你是在为利益机制而争辩。

            • 作为实体,我还是更相信 antirez 而不是亚马逊。

              永远不要相信公司。

              • 如果安提雷兹为另一家公司工作,相信他对我有什么帮助?

  2. 这个主题中有很多愤世嫉俗的观点–我明白,他们不能保证将来不会再重新获得许可证(他们有 CLA,可以让他们重新获得许可证),而且人们觉得上次许可证变更背叛了他们。

    无论如何,我认为我们应该为此庆祝。这是一个明智的决定,也是社区所希望发生的事情,如果其他公司也能看到 “Redis重新授权开源并从中获得巨大收益”,而不是 “Redis重新授权开源却对他们毫无帮助”,那将是多么美好的事情。

    我很高兴。谢谢你,Redis 团队。

    • 谢谢你,西蒙。我认为,像 Elastic 和 Redis 这样回归开源许可的案例就像在岩石上写字:“开源赢了”,至少在系统软件领域是这样。随着时间的推移,公司会创建、繁荣和失败,但这一信息将长期伴随着我们,并影响着未来的社会。这是软件社区自身的胜利。

      • 这是社区对 Redis 和 Elastic 公司的胜利。他们不是屈服于压力的好人。他们试图借助自由和开放源码软件(FOSS)崭露头角,然后在社区的支持下攫取财富,结果发现社区比他们更重要。

        所以,当然,让我们庆祝吧,但庆祝的是社区,而不是那些试图从他们脚下夺走地毯的人。

        • 我说这正是社区的胜利。但是,开源软件的工作人员需要钱来支付报酬,而那些支持 SSPL 的公司则是为了保护自己的业务(从侧面来说,无论他们是否愿意,他们都有能力为这些工作支付报酬)。我相信,在云时代,软件世界没能保护好开源软件,但总的来说,我们共同创造的环境让开源软件赢得了胜利。

          • 我不相信这个理由。这两家公司(以及其他类似的公司)建立了一种为其业务提供资金的模式,他们清楚地知道,他们将不得不与其他能够提供与他们相同服务的公司竞争。这一直是自由和开放源码软件的固有特性–当你免费发布你的代码时,你就不能围绕垄断进行规划,这是你所做权衡的一部分。

            当 AWS 和其他公司确实提供了托管服务,而且比这些人提供得更好时,现在突然间 AWS 成了坏人,因为他们按照许可规定的方式使用自由和开放源码软件。现在,我们突然应该无视自由和开放源码软件一直以来的发布条款,拿起我们的干草叉来反对这个卑鄙的大云提供商。

            他们没有坚持自由和开放源码软件的基本原则(他们通过公开支持这些原则赢得了业务),也没有调整业务以适应 Elastic 和 Redis 在他们故意设置的竞争中失利的事实,而是将托管(在 AWS 和 Co 的基础上,毫不逊色!)作为业务模式,并修改了许可证,让自己垄断了托管业务。

            • 我们不可能与不需要为软件开发提供资金,但仍能从将其作为服务部署的过程中获取所有收入和利润的其他人竞争。

              • 不是这样的,你可以在部署服务的质量上与软件开发分开竞争。服务的质量可以包括内部的、大规模的优化,而这些优化并不影响开源软件面向用户的平等性。

                提供 SaaS 产品的开源公司需要制定计划,在托管质量而非功能方面实现差异化。是的,在许多情况下,你可以通过定制化的闭源优化(与功能均等无关,也不会有意限制开源/自托管形式)、支持等,将自己的产品托管得比亚马逊更好。

                • 由于这些资源必须如何分配,因此采取了愚蠢的做法。Redis 公司支付给开发人员的是 Redis 本身的开发费用,因此他们用于构建云产品的资金较少。AWS 不向开发人员支付 Redis 的开发费用,因此他们有更多的资金用于改进其云产品(Redis)。

                  “不可能竞争 “是夸张的说法(几乎总是可以竞争的),但从商业基础的角度来看,这并不是一个公平的竞争环境,在这个领域成功的几率非常非常低。正如我的同胞评论所指出的,超大规模服务器还为你托管其他基础设施(就其本质而言),而 Redis Cloud 只提供 Redis 托管服务,这就大大加剧了竞争的激烈程度。因此,即使 Redis Cloud 的 DX/UX 要好得多,要说服企业甚至中小型企业像这样拆分其托管服务仍是一场艰苦的战斗。

                • > 不是这样的,你可以将部署服务的质量与软件开发分开来竞争。

                  从字面上看确实如此,但从(轶事)部署 Redis 的工程师的角度来看,在必须通过采购障碍才能与 Redis Labs 签订合同与在 AWS 上启动 Redis 之间做出选择时,并不存在真正的竞争空间。

                  对于大多数企业来说,工程师无法自由采购客观上最好的托管解决方案,因此竞争并不公平。

                  在此之前,我从未真正深入思考过这个问题,所以我不认为这是一个充实的论据,这只是我的个人经验之谈。

                  • 老实说,“只要做得更好就能获胜 ”的想法与企业的发展严重脱节,我认为任何提出这种建议的人都是不了解问题所在,才会试图与世界上所有的人中的 Antirez 争论这个问题。

                    这并不是在诉诸权威:在企业中,质量并不能保证成功,这一点是如此真实而明显,以至于解释它就像是在试图打破一个基本要素。

                • 是的,不行。客户更愿意在他们现有的 AWS/微软堆栈中使用 redis,而不是在不同的数据中心使用你的部署版本,并进行一些微优化。

                  他们会付钱给微软和亚马逊,而不是软件作者你来使用你的软件。

              • 但从一开始就是这样。这是自由和开放源码软件模式的一部分,而且一直如此。

                如果这些公司在构建其业务时做出了错误的决定,并对此承担责任,我想我们现在的对话就会截然不同。我们之所以在这里,是因为他们没有承认这一点,而是试图让人们举起干草叉反对 AWS。别忘了,他们想要的模式是转售 AWS 的主机并从中收取佣金,这种模式显然是注定要失败的;也别忘了,当他们选择以自由和开放源码软件(FOSS)的形式发布自己的软件并获得相应的采用率时,他们选择了这种取舍。

                我完全同意上文 antirez 的观点,即我们需要一个新的计划来资助自由和开放源码软件。但我认为,这并不能成为现有公司诋毁和诽谤的理由。

              • 你说得好像如果他们资助软件开发,就有办法与同样的组织竞争–与超大规模公司竞争是不可能的,就是这样。现在亚马逊正在资助一个分叉,Redis 公司在竞争中的地位是更好还是更差?

              • 如果你只出资开发软件,你就拥有了功能积压。如果你不能利用这一点作为竞争优势,我真的不知道该告诉你什么。

            • > 现在突然变成 AWS 是坏人了,因为他们按照许可证规定的方式使用自由和开放源码软件。

              这样说并不公平。这里争论的是一个巨无霸在攫取巨额利润。之所以说它是坏事,是因为这种行为破坏了整个社区。参与者需要在现实可行的情况下按比例回馈自己的利益,以免社区随着时间的推移而衰落。

              这在概念上类似于工作场所不佳的雇主所受到的不认可。即使他们在技术上遵守了所有的劳动法,但由于将利润置于工人的健康和福利之上,他们也会赢得不好的名声。但 “我们没有做任何违法的事 ”并不能让他们摆脱困境。

              • > 之所以被视为坏事,是因为这种行为破坏了整个社区。参与者需要在现实可行的情况下按比例回馈自己的利益,以免社区随着时间的推移而衰落。

                为什么?没有人能给我解释清楚。为什么亚马逊使用软件会导致社区衰落?难道这不会让软件更受欢迎,覆盖范围更广吗?

                当你免费赠送软件时,你已经免费赠送了它。你制作软件的初衷就是希望它被使用。为什么当它被大规模使用时,这就突然成了问题?

                • > 为什么亚马逊使用该软件会导致社区衰落?

                  至少直接不会。

                  > 你生产软件的初衷是希望它被使用。为什么当它被大规模使用时,突然就成了问题?

                  你在这里设定了一个我从未提出过的因果关系。并不是使用本身突然成了问题。

                  行为才是问题所在。如果其他人都参与进来,而你没有,那你就赢了。这是合作行为背后的博弈论。如果只有你弃权,社区的情况不一定会变得更糟,但如果所有人都弃权,情况就会变得更糟(即与所有人都捐款相比)。对整个群体来说,最佳结果是每个人都参与进来。

                  我明白你的意思。从法律上讲,投资人如果不从一开始就积极主动地防止这种情况发生,那就太傻了。

                  但这与合法性无关。而是社会责任。拥有更多资源的实体–个人、公司,甚至政府–在公众眼中一般都有更高的标准。仅靠法律制度不足以让社会成为一个美好的生活场所。

          • > 但需要钱来支付开源软件工作人员的工资

            可爱。现在能给我一张支票来支付我对 redis 的贡献了吗?

        • 我强烈怀疑这些公司内部和开发人员之间也存在压力。

      • 我想说,开源肯定输了,而且输得很惨。

        自由软件赢了,因为你们最终采用了 AGPL。

        这是一个重要的区别。

          • 又有一款重要软件不再是开源软件(BSD),而是自由软件(AGPL)了。

            每当有人谈论开源许可时,我们就会想起 Redis 曾经是 BSD,后来变得如此糟糕(所有人都逃往 Valkey),他们不得不将其重新授权为 AGPL(自由软件)。

            如果这还不算输…

    • > 如果其他公司能看到 “Redis重新授权为开源软件,并从中获得了巨大的收益”,而不是 “Redis重新授权为开源软件,却对他们毫无帮助”,那该有多好。

      如果其他公司还不明白,采用蹩脚的许可证并疏远社区是自找的麻烦,那他们就无能为力了。重新许可开放源码对公司没有任何帮助,这对其他公司可能是一个警示,可以防止他们重蹈覆辙。作为一个开源爱好者,最坏的情况是公司为了试水而策略性地频繁更换许可证,然后不计后果地回头;我更希望这种行为的代价是迅速而严重的。

    • 这可能是愤世嫉俗的说法,但我认为,重要的是要让人们看到公司与其社区之间失信的严重后果。任何看到他们的历史并为之做出贡献的人都必须意识到,他们是在为一家公司做无偿的工作。

    • 我不希望公司看到:“重新授权给那些低级的许可证是没有风险的,因为如果人们的反应过于消极,我们可以随时回到旧的许可证”。我希望他们看到的是:“重新授权给低劣的许可证是一个死刑判决,会立即让你的产品变得几乎完全无关紧要,并导致社区转而使用分叉版,再也不会转回来”。

    • >在这个主题中,有很多愤世嫉俗的观点–我明白,他们不能保证将来不会再重新授权(他们有 CLA,可以让他们重新授权),而且人们觉得上次许可证变更背叛了他们。

      哦,那就好。它仍有希望回到最初的 BSD 许可证。(我仍然在使用古老的 Memcached)

    • 我也很欣赏这种观点,因为你永远不知道会议室里发生了什么。我见过一些道德高尚的领导者为了迎合心胸狭窄的投资者,做出了完全不符合他们性格的决定。

  3. 从 Redis 博客 https://redis.io/blog/agplv3/ 上的这篇帖子来看,他们也在新的 AGPL 许可下提供了一系列新功能:

    > 将 Redis Stack 技术(包括 JSON、时间序列、概率数据类型、Redis 查询引擎等)集成到 AGPL 下的 Redis 8 核心中

    Redis 查询引擎对我来说很新鲜(许可证变更后我就不再密切关注 Redis 了)–它看起来像是 Elasticsearch 的内存替代品:https://redis.io/docs/latest/develop/interact/search-and-que…

    语法如下

     FT.SEARCH places "museum @city:(san francisco|oakland) @shape:[CONTAINS $poly]” PARAMS 2 poly "POLYGON((-122.5 37.7, -122.5 37.8, -122.4 37.8, -122.4 37.7, -122.5 37.7))' DIALECT 3
    

    (从回答 “既然我已经转到 Valkey,为什么还要转回 Redis ”这个问题的角度来看,这是一个明智之举–Redis 刚刚增加了许多有趣的新特性)。

    • 令人沮丧的是,首席执行官在这份新闻稿中拼错了 antirez 的姓,https://redis.io/blog/agplv3/。这实在是太不尊重人了:

      > 在我们的许可证变更之后,2024 年 11 月,Salvatore Sanfillipo(antirez)决定重新加入 Redis,成为一名开发者布道者。与 Salvatore 在新功能、公司战略和社区参与方面的合作是一种真正的殊荣,这种合作产生了重大影响,并将在未来带来回报。

      如果这是一种真正的殊荣,那么你就应该通过不拼错他的名字来赢得这种殊荣。行胜于言。

      平克-弗洛伊德(Pink Floyd)有一首歌就是这样唱的:

      我一直怀着深深的敬意,我是真心的。

      这支乐队真是太棒了,这就是我的真实想法

      对了,哪个是平克?

      我们告诉你游戏的名字了吗?

      我们叫它 “坐上肉汁列车

      我们只是被击倒了,我们听说唱片卖光了

      你得出唱片,这是你欠大家的

      我们高兴得数不清

      其他人都是绿色的,你看到排行榜了吗?

      这是个好的开始,它可以成为一个怪物

      如果我们团结一致

  4. 我很好奇,在此之后,社区是否会再次信任 Redis 公司,或者他们会选择坚持使用 Valkey。另一个值得关注的问题是,至少一些大公司的法律部门对 AGPL 软件心存戒备,这使得仍然是 BSD 的 Valkey 对他们更有吸引力。

    编辑:不管怎么说,还是要感谢你和 Redis 内部的其他成员,感谢他们推动将其带回开放源码软件!

    • 我们一直在使用 redis,许可证的变更从未影响到我们。我们没有理由更换。

      • 我想有相当一部分(大多数)用户也是这么想的。

        这并不是说这不是一个重要的讨论!

        • 许多人转而使用 Valkey,却浑然不知。这就像许多用户使用 MariaDB,却以为自己在使用 MySQL。

          几个主要的 Linux 发行版都透明地切换到了 Valkey,而用户却毫不知情。例如,在 Fedora 上,“sudo dnf install redis ”只会安装 Valkey。

          • 这就是不使用发行版的理由,对吧?如果我输入 “sudo dnf install redis”,我想安装的是 redis 而不是 Valkey。

            • 如果我更新了软件包,而开源软件突然被闭源软件取代,我会责怪我的发行版。发行版用它们拥有的最好的软件包替换这样的软件包是完全正常的。

              • 我认为这完全不正常,绝对不应该被正常化。

                让我的软件包管理器安装一个完全不同的软件,比让我的软件包管理器安装一个我要求的软件的新版本要糟糕得多,因为后者现在有不同的许可证。另外,SSPL 并不是闭源的。

                如果发行版想做什么,他们可以抛出一个警告:”此软件包已获得 SSPL 许可,你还想安装吗?请尝试安装 valkey,以获得 BSD 许可的替代软件”。但实际上,安装我没有要求的软件是件坏事。

                • 你来得有点晚了。几乎从发行版存在的那一刻起,它就已经被规范化了。

                  不,你不会在某天随机安装了一个不同的软件包,至少在主流发行版上是这样。下一个发行版就会包含新软件包。无论出于什么原因,你都可以去安装另一个你想要的软件包,只是它不会成为默认软件包库的一部分。

                  一般来说,替换软件包与被替换软件包的比例是 1:1,而且/或者在安装过程中会包含兼容性垫片。这就是无缝安装。此外,软件包管理器通常会告诉你它要安装什么。

                  主要的 Linux 发行版在这方面都非常谨慎。最大的两个发行版拥有庞大的企业用户群,从来没有出现过问题。

                  许多 Linux 发行版对默认软件包库中的内容非常有主见,这也是你选择某些发行版的主要原因。你把对软件包、兼容性、错误/安全修复、许可证等问题的关注都交给了发行版的维护者。他们会非常小心,避免破坏现有系统,也不会在某天突然给你带来重大的破坏性改变。举例来说,如果他们用 Valkey 取代 Redis,那么下一个重要的操作系统版本中就会出现,而且是直接替换(所有 Redis 命令都能继续工作等),你在安装软件包时就有机会看到这一变化。这可不是 npm 式的 “枪打出头鸟”…

                • 在 Arch Linux 上,系统会明确询问你是否要用(发行版)指定的后续软件包替换某个软件包。

                • > 另外,SSPL 并不是闭源的。

                  它也不是自由和开源软件许可证。这使得使用它的软件没有资格进入各种发行版的主软件仓库。

                  不过,似乎某种用户提示是可以接受的。

                • > 但安装我没有要求的软件其实也不好。

                  除了它是个分叉版,所以它就是你要的。当然,名称变了,管理安排也不同了。但使用发行版的全部意义就在于把诸如信任哪些开发者和软件源之类的决定权交给维护者。

                  如果你想自己做这些决定,那么你显然应该从源代码开始克隆和构建。我不是随口说说,我自己也是这么做的。

                  如果你不关心许可证的纯净性,那么也许就不要使用明确对此进行过滤的发行版。

              • 如果你编写的脚本会查找在你的机器上运行的名为 “redis ”的进程,那就糟透了。

                  • 即使有符号链接,运行的进程也会被称为 valkey,而不是 redis

                    • 只有在 valkey 启动后明确更改了程序名,或直接在程序上调用 exec 的情况下才会这样。至少在 linux 上是这样。

            • 我不同意,可能是因为我已经习惯了。大多数主流发行版都会这么做,包括 Fedora 和 Debian(两个最大的发行版)。通常这是因为许可证问题。

            • > 这就是不使用发行版的理由,对吗?如果我输入 “sudo dnf install redis”,我想安装的是 redis 而不是 valkey。

              使用按你的方式处理事情的发行版是你的特权。我认为大多数安装软件包的人关心的是软件包提供的功能,而不是品牌名称,因此对于旨在吸引广泛用户群的发行版来说,这似乎是一个公平的默认设置。

              • > 使用按你的方式处理事情的发行版是你的特权。我想大多数安装软件包的人关心的是它们提供的功能,而不是品牌名称。

                这真是一个 “人的两面性 ”的有趣例子,因为我刚在苹果主题中读了一堆大意为 “用户应该对他们能从 App Store 安装哪些应用程序拥有最终决定权 ”的评论。

                • 但在这种情况下,你确实有最终决定权。你可以以各种方式重新配置主流软件包管理器,建立自己的软件仓库,做任何你想做的事。

                  我使用发行版是因为我没有时间或精力自己做这些事。这是一种纯粹的自愿安排,不像现代社会越来越多地建立在 iOS/Android 双头垄断的基础上。

              • 不仅仅是品牌名称,还有二进制名称。我掌握的所有支持代码都希望二进制文件命名为 “redis”。

                另外,如果功能发生偏移会怎样?

                • 所以 redis 软件包将其重命名为 redis。没什么大不了的。

                  你的想法好像上游是主要的。实际上,当你使用发行版软件包时,发行版对软件包的内容拥有最终决定权。

            • 我明白你的意思,但发行版主要就是这样处理许可证问题的。我相信这才是正确的做法,我们应该努力在发行版中开展开放源码软件项目,并将其作为重点。

            • 其实不然。关闭源代码后,名为 “Redis ”的东西才是真正的分叉,而 Valkey 则是最初的社区构建产品。如果用户希望现有配置能以相同的条件继续工作,则需要 “安装 Redis ”命令,以免破坏其许可预期。

              • 首先,他们没有 “关闭源代码”。新的许可证并不是封闭源代码。你可以争论为什么你认为许可证不好,但它不是闭源的。

                其次,我不知道你怎么想,但对于我管理的系统来说,以同样的方式继续运行是我的首要需求。当我的配置系统按名称安装一个软件包时,我希望它能以和以前一样的方式运行。转换二进制名称则会打破这一承诺。

                我的设置中有一些脚本,比如检查名为 “redis ”的进程是否在运行……如果该进程现在被称为 “valkey”,那么这些脚本就会失效。

                我感觉所有评论者都生活在某种疯狂的另类世界里,在那里许可证的纯净度比系统的稳定性更重要。

                • > 当我的配置系统按名称安装软件包时,我希望它能像以前一样工作。

                  但你该把责任推给谁?

                  是发行版做出的改变,还是 redis 公司破坏了你的软件栈?

                  • 听着,我知道授权决定很重要,很多人都很在意。

                    但对我和我的公司来说,这并不重要。我们使用 Redis 的方式并不会与许可证产生冲突,所以这对我来说并无影响。Redis 并没有因为许可证的变更而破坏我的软件栈。很抱歉,我实在没有精力去关心他们选择哪种许可证。如果这能帮助他们赚钱,那就去做吧。我可没那么多精力去支持亚马逊。

            • 100%,如果他们想停止提供 Redis,就应该直接删除 Redis 软件包。

      • 从博文来看,现有用户似乎仍在使用 Redis,但新用户则采用了其他替代方案。

        • > 从博文来看,现有用户似乎一直在使用 Redis。

          我是 Redis 的用户,自从 Redis 出现后,我就把我的服务器(约 15 台)换成了 Valkey – 部分原因是这些诡计,部分原因是 Arch 正在把 Redis 移到归档文件中。

        • 在我目前所在的公司(类似于数十亿美元的公司),即使不是全部,也是大部分 Redis 已被 Valkey 所取代。

          Redis 对公司构成了威胁,因此公司非常重视许可证变更,就像对待所有与法律相关的威胁一样。

      • 我也一样。社区的反应是有效的,但基本上对我们没有影响。

    • 撇开这些不谈,Redis 公司的销售人员是我在这个行业长期工作以来遇到的最不圆滑的销售人员。就像二手车销售一样。

      再加上他们的许可证,我绝不会考虑与他们打交道。

      • 据我所知,销售团队最近已从零开始重建。如果最近发生了这种情况,请告诉我,我一定会向您汇报。谢谢。

    • 我们在 Elasticache 实例上改用了 Valkey,并立即注意到我们的用例性能有了提高,从而减少了实例数量。目前,我们对转回 Redis 并不感兴趣。

    • 我也是这么想的,采用 AGPL 实际上可能会让更多人转向 Valkey。

      虽然我还没查过 ValKey 在分叉后是否有任何实质性的发展。

      • 亚马逊非常鼓励在 elasticache 面板上使用 Valkey。有一个广告横幅宣传更低的价格,而且当你创建一个程序时,它被列在下拉菜单的第一位。默认设置确实很强大。

        • 当然,但新客户和他们的决定需要很长时间才能影响净统计数据。我能找到的所有证据,无论在哪个领域或背景下,都表明 Redis 与 Valkey 的市场份额大约相差 99%/1%。

        • 我想知道 CLA 在法律上是如何运作的。如果最初编写代码的人不是签署 PR 的人。我想律师应该已经签过字了。

          他们是否按照 BSD-3 的要求保留了作者的版权声明?

        • 现在 Redis 再次成为开源甚至自由软件,这种情况应该会有所改变。

      • 我一直在使用 Valkey,只是因为在我更新到最新的 Fedora 版本之后,它放弃了 Redis,转而指向了 Valkey。我想随着越来越多的发行版这么做,越来越多的人更新他们的系统,Valkey 的用户群也会越来越大。但也许有了 AGPL Redis,情况就不会再是这样了。

      • 这种说法真的需要一些支持,否则就只是噪音。老实说,我不知道 Valkey 的使用统计数字是多少–与 Redis 相比,它可能只是九牛一毛。但我不知道。你能证明这一点吗,或者这只是你的直觉?

      • 是啊,所有开源发行版和大多数开源项目转用 Valkey 肯定是 “无名小卒”。

      • 我在一家隶属于 FAANG 的公司工作,我们的整个工程组织都被告知要改用 Valkey,而且运营部还规定了内部期限。我所在的团队支持面向公众的服务,我们在两个月前完成了切换。

        这非常简单,只需修改一下配置,再进行一些性能测试,就能确保它在大规模使用时运行良好。

        也许没有人在网上谈论这件事,但有些人肯定已经切换了。

      • 我不知道 Valkey 的情况,但我听说 Nvidia 正在放弃 Redis。

      • 是的。它可以直接替代 Redis,而且速度更快、成本更低。

    • 我非常怀疑,在 PaaS 提供商转回只提供 Redis 本体之后,还会有人坚持使用 Valkey。

      • PaaS 提供商为什么要转回提供 Redis?他们显然都已经在 Valkey 上投入了大量资金(AWS、GCP、Heroku)。

        • AWS、GCP 肯定已经投入了:他们为 ValKey 付了钱,他们分叉是为了避免以任何方式与 Redis 进行收入分成:D 我认为这是社区做什么的问题,而这反过来又取决于我们开发 Redis 的能力。

          这不仅仅是许可和超标量的问题,也是开发质量和方向的问题。例如,在 Redis 中,你可以找到更多 ValKey 中没有的东西,包括哈希项过期、对很多事情都非常有用的向量集、Redis 8 中刚刚引入的概率数据结构等等。

        • 如果 Redis 更胜一筹,那么坚持使用 Valkey 无异于舍本逐末。希望这些公司有足够的能力理解沉没成本的概念。

          也许 Valkey 已经达到了迫使 Redis 合作的目的。

          我只是在回答 “为什么”。至于 Redis 是否比 Valkey 更好,或者是否值得换回来,我就不得而知了。

        • AWS 和 GCP 提供基于 Valkey 的产品版本,这些版本通常基于 Redis,但这些版本目前一般都是预览级,而且据统计,没有客户在使用它们。它们仍然提供这些产品基于 Redis 的原始版本,据统计,100% 的客户都在使用这些版本。

          • 你有数据支持你的说法吗?我在这里看到了很多客户对 Valkey 的评价,https://aws.amazon.com/elasticache/customers/。AWS 或 GCP 产品都没有预览版。

          • >据统计,没有客户在使用它们

            你已经说过两次了,但却没有提供任何数据,甚至连可能的来源都没有提供,这样其他人就可以去获取数据并查看了。

            如果是统计上的东西,统计在哪里?

            • 大约 9 个月前,valkey 作为 Redis 的选择性替代品被引入,作为主要云提供商提供的特定产品的实施选择。一般来说,valkey 显示为预览版、测试版或其他选项。没有人对现有客户执行过任何形式的从 Redis 到 valkey 的自动或默认过渡。

              我真诚地希望,我所说的统计上没有(云提供商)客户在使用 valkey 应该是不言自明的。

              • >我的说法是,从统计数据来看,使用 Valkey 的(云提供商)客户数量为零,我衷心希望这一点不言自明。

                我不知道实际统计数字是多少。但不,我不认为你所说的 “统计上的 0%”是不言自明的,尤其是考虑到本主题中的其他评论和链接,以及我在其他地方听到的情况。

                既然你说得如此自信,我还希望你能提供比 “相信我 ”更多的东西。在另一条评论中,你说你有市场份额的证据,也许你可以把它贴出来?

                • 他们的统计数据是 “我问了一个大语言模型(LLM)”,不,这不是玩笑,请看这个主题:https://news.ycombinator.com/item?id=43860256

                  • 我的统计不是 “我问了一个大语言模型(LLM)”,那是我对一个具体评论的回复,走开

                    • 如果你的统计数据不是来自 “相信我 ”或大语言模型(LLM),你能不能直接公布你的市场份额统计数据是从哪里来的?

                    • 但如果这就是你的典型研究方法,那么我有个坏消息要告诉你,你所依赖的统计数据质量很差。

              • 我最近转到了一家新公司,但我之前的公司在生产中部署了相当大规模的 Elasticache Redis(在 us-east-1 中有 50 多个大型集群),由于节省了成本、提高了性能并减少了内存使用量,我们正在向 Valkey 进行全面迁移。

                我们已经完成了几个大型生产集群的迁移,我可以自信地说,迁移过程非常顺利,没有出现任何差错。

                Valkey 已经为生产做好了准备(至少在 AWS 上是这样)。我们的团队期待着加快并完成迁移。

              • >没有人为现有客户执行过任何形式的从 Redis 到 Valkey 的自动或默认过渡。

                >我真诚地希望,我所说的统计上没有任何(云提供商)客户在使用 valkey 的说法应该是不言自明的。

                但事实并非如此。例如,Aiven(一家云计算服务提供商)在三月底完全终止了对Redis的支持,并将现有用户迁移到了Valkey。https://aiven.io/docs/platform/reference/end-of-life#aiven-f…

  5. 我喜欢Redis的一个重要原因是,它成为了我学习新技术和探索数据的工具。比如,新的矢量集功能让我真正探索了密集矢量、自定义搜索、分类映射等各种对我来说似乎门槛很高的领域,但现在我只需使用嵌入模型将数据流导入 llama.cpp,然后存储在 Redis 中,就能在不同数据集之间超高效地进行映射。

    其中很大一部分原因是 API 的设计–我想不出还有哪个系统能像 Redis API 一样考虑周全–它简单得令人难以置信,正因为如此,我无需等待客户端库加入新的 Redis 功能–它们都能正常工作,因为它们都会说 RESP,我只需发送原始命令即可。

    说了这么多,我想说的是,当我听说 Antirez 重新开始研究 Redis 时,我真的非常高兴,而且它带来的回报远远超出了我的想象。人们可以用 Valkey 或其他任何东西来替代 Redis,但我喜欢 Redis,因为它总是在不断向前推进,让我能够探索新事物,否则我就不会像在 Redis 中那样感觉 “触手可及”。

    • 非常感谢你的赞誉!我很努力地通过矢量数据集(Vector Sets)来追随你所说的 “浪潮”,希望我能做到。谢谢。

    • 能否请您链接一下您所谈论的任何博文,我觉得我对这些东西也是一知半解。

  6. 摘自首席执行官博文 – https://redis.io/blog/agplv3/

    >这实现了我们的目标–AWS 和 Google 现在维护着自己的分叉。

    这真的是我们的目标吗?强迫你的最大用户分叉你的软件并维护他们自己的不同版本,这对谁都没有好处。当然,亚马逊和谷歌(或 AWS 和 GCP–在源材料中键入混淆)现在不得不为开放分叉贡献更多的工程时间,但既然有了由最终会为你运行 Redis 的同一家云计算超级计算机维护的许可替代方案,为什么还有人愿意使用 Redis 呢?

    • 你真的想让 Valkey 成为云客户的默认选项,确保他们无法迁移到你自己的产品?我真不明白。你原来得到的是 0 美元,现在得到的是 0 美元。

      • 人们从 AWS Redis 迁移到 Redis Cloud 的频率有多高?我猜不是很多。

        • +1. 我猜不是很多。我每次使用 Redis(或最近的 ValKey)时,延迟超过 20 毫秒左右就会非常糟糕。

          我见过完全没有缓存的工作负载在 30 毫秒时表现得更好

    • 难道不是吗?他们之前没有做出贡献,也没有付钱给 Redis 公司,现在他们至少为一个分叉做出了贡献(但仍然没有付钱给 Redis 公司)。

      据推测,Valkey 等正在开发的一些东西可以以某种形式回流到 Redis(由于它是一个具有不同许可证的硬分叉,所以并不完全直截了当,但概念也可以借用回来)。

      例如,Valkey 显然引入了一些性能改进。如果值得,Redis 也可以实现类似的功能。如果没有分叉,这些性能改进的想法可能永远不会浮出水面。

      • 他们贡献良多。因此,Redis 公司失去了很多工程方面的专业人才,因为他们都去了 Valkey。

      • > 他们之前没有贡献

        事实并非如此。在授权分裂之前,AWS 等公司就有受薪员工担任 OSS Redis 核心维护者。关于 “实现他们的目标 ”的说法只是虚张声势,除了损害控制之外没有任何其他原因。

    • 我不明白,为什么 gcp 和 aws 不直接付钱给 Redis 公司,而要付自己的(昂贵的)工程师来维护一个分叉?

    • 有补偿性的好处吗?对于网页浏览器来说,有多个相互竞争的实现被认为是好事。

      • 生态系统有好处吗?有可能。

        但你回复的那个人说的是 Redis 的目标,我认为他们的目标不可能是让自己身边出现一个竞争对手。即使他们真的想这样做,他们也可以直接资助(或设计)一个分叉;把许可证改成让你的最大用户自己来做,是一种相当迂回的做法。

        我几乎可以这样理解:大用户需要共同开发一个替代品,这就意味着替代品最好是开源的,这就意味着 Redis 可以获得由分叉用户(Redis 对分叉用户不付钱感到不满)资助的未来改进,这是一个半报复、半有用的目标。但这仍然是迂回的。如果真的是这样的计划,那么在这次事后总结中就可以阐述得更清楚一些,让人明白 “目标 ”这一点并不只是骗人的。

  7. 我们公司已经改用 Valkey,我们已经为此投入了数百个工程小时。我不认为我们会在这个时候切换回来,尤其是在 Redis 很明显会再次轻易上钩的时候。

    • 你的公司投入了数百个工时从 Redis 转向 Redis 的干净分叉?

      • 对于一家中型公司来说,我很容易理解这一点。

        虽然把 valkey 放进去很容易,但创建新实例、将应用程序迁移到这些新实例,以及确保没有一些隐藏的回归(即使是 “放进去”)都需要时间。

        乐观估计,每个应用程序至少需要 1 或 2 个小时。

        我的公司有数百个应用程序(微服务万岁)。在我看来,“几百个小时 ”是非常合理的。

        我们公司并没有大量使用 redis,但如果有的话,切换也需要一些时间。

        编辑:我还没来得及回复就死了,但我觉得还是值得回复一下。

        > 这只是 redis 换了个名字而已,有什么好测试的?

        我在开源项目中见过不少这种情况,“X 只是换了个名字叫 Y”,但其中的微小改动却与我们的使用方式相冲突。例如,可能某些应用程序并不保证顺序,但我们的应用程序(以一种愚蠢的方式)却依赖于顺序。这对我们来说肯定是个错误,但在更新 redis 或切换之前不会出现。

        也有可能是我们依赖的是旧版本的 redis,而切换到 valkey 后,我们必须引入 redis 的新变化,而我们可能还没有测试过。

        这些情况当然不太可能发生(这也是为什么要估计 1 或 2 个小时的原因,如果这些问题更常见,需要的时间会更多)。然而,这些问题确实存在,而且我在进行其他依赖关系更新时也遇到过。

        至少,只要确保没有人在新的 valkey 地址上做手脚,或者没有弄乱部署的 terraform,就需要时间来测试和验证。

        • > 我的公司有数百个应用程序(微服务万岁)。在我看来,“几百个小时 ”是非常合理的。

          在我看来,这似乎是贵公司选择软件架构的一个巨大劣势。

          • 这种方法肯定有利有弊。

            优点是每个服务都是一座孤岛,在需要时可以独立更新和管理。扩展性也比较好,因为你只需要在重负载下扩展服务,而不是大型服务。

            它还能更好地分离系统。foo 系统会得到一个 foo 数据库,当两者都处于负载状态时,我们只需讨论增加 foo 系统/数据库的硬件,而不需要增加 everything 数据库的硬件。

            缺点是更加复杂,一致性几乎不可能实现(尽管我们在很大程度上是一致的)。这也意味着,如果我们需要在全系统范围内更换某个服务(如 redis),你必须访问我们的 100 多个服务,看看谁依赖于它。这种情况很少出现,因为大多数公司都不会像 redis 那样做。

          • 的确如此。热衷于微服务的 “架构师 ”喜欢忽略每个微服务所需的工作以及服务间协作的开销。他们会花上几年时间假装以任何有意义的方式解决这个问题,然后换一家公司制造类似的混乱。

          • 在不了解公司情况的情况下,这样的说法太夸张了。

            有时,大公司收购小公司后,会在旧系统中保留一段时间。他们甚至可能不使用类似的技术堆栈!

            有时,他们希望将收购的系统干净利落地纳入现有架构,但这可能需要数年的开发时间。

            有时,拥有一个分布式系统是有益的。优点/缺点。

            有时只是一家有很多人并行工作的大公司,很难在单一管道中将所有内容部署为单一网络应用。

        • 据我所知,Valkey 是直接从 redis 分支出来的。因此,假设你在分叉时间点进行迁移,那么从字面上看,它就是相同的代码。

          • 是的,但基础架构、配置和文档不一样。任何合理的操作都需要验证和保证。如果你有一个相当规模的运营,这些工作就会加在一起。对于拥有大量员工、大量数据和大量实例的运营来说,“数百小时 ”也并不是什么巨大的规模。

            你所考虑的部分并不是耗时的部分。

      • 我相信。有些公司投入了数百个工程小时,将 master 更名为 main。

        • 这就更可笑了,至少改用 Redis 的干净分叉是有商业原因的。而追随最新的文化潮流,就没那么简单了。

        • 你很难相信,我们是如何经常把 “master ”硬编码到软件的每一个角落,而这些软件又是如何接触到任何 VCS 的。

      • 至少你必须验证所有接触到 redis 的内容,这意味着你必须找到所有接触到 redis 的内容。内部工具和文档也需要更新。

        谁知道是否有人采用了分叉后的功能?

        如果这是一个支持核心业务的生产系统,那么数百个小时似乎是相当合理的。当然,对于能够承受 “YOLO ”的小型企业来说,这应该很容易。

        • 但是,除非他们是提供 Redis 即服务的托管服务提供商,否则他们为什么要花时间从 Redis 迁移到其他地方呢?

          我并不知道许可证对内部私人使用有任何负面影响。

          • 负面影响是,你必须重新聘请律师,而他们往往会对可能被视为提供 “Redis 即服务 ”的行为采取极为保守的立场。

            • 他们会吗?我的经验是,在选择软件时,律师会签字同意,但之后就不会再征求他们的意见了。

              之后就只是更新版本号。律师不会在版本升级上签字,我为什么要向他们提出这个问题?

          • 当发生具有新闻价值的许可证变更时,许多法律部门无法承受细微的变化。最直接的反应就是换掉,以降低任何业务风险。

            • 我怀疑让律师审查您的使用情况比花费数百小时的开发时间进行迁移更昂贵。

          • 我们的律师查看了 SSPL,因为我们为客户托管了软件,而且它确实使用了 Redis!

      • 我说的切换是指所有新项目都使用 Valkey 而不是 Redis,我们在这些新项目上投入了数百个小时。

      • 有些公司使用成千上万个 Redis 实例来存储数百万用户的 PB 级数据。

        现在考虑一下无停机时间迁移。你认为这需要多长时间来设计和执行?

      • 即使是基础架构的切换和测试也需要大量时间,而应用级测试等则需要更多时间。

    • 你为什么不向 Redis 购买许可证?我真的很好奇。你是觉得被未来可能上涨的许可费束缚着不舒服,还是觉得太贵了?

    • Valkey不是一个 “即插即用 ”的替代品吗?我换了几次部署,它 “就是管用”,但也许是我太单纯了。

    • 如果你使用的是像 redis 这样的琐碎协议,更换后端怎么会花上几百个小时?

      也许问题出在没有使用可插拔的适配器? 你的业务逻辑是否与特定的数据库客户端 API 相耦合?

      我知道集群客户端是不同的(我也经历过),但几百个小时,真的吗?

      • 我想你可能低估了几百个小时是多么的短暂。完成一项任务的前 100 个小时是非常非常容易的,比如每周工作 40 小时,3 个工程师 = 120 个小时。

        如果 valkey 能正常工作,为什么还要花时间还原到 redis,而把时间花在真正有价值的事情上呢?

      • 如果你必须进行测试/基准测试、更改配置、部署系统、观察指标等,这似乎很有可能。

      • 我的公司规模相对较小。大概有 6 个独立的 redis 实例部署在不同的地方(k8s、裸机、暂存和 prod 环境),有几十个(微)服务在使用它们,在这一点上,迁移所有东西可能至少需要 40 个小时(一个人一周)。此外,还有一些问题,如文档、仍在运行但没人愿意花时间更新的遗留应用程序、随处可见的命名问题(在不停机的情况下重命名 “redis ”将是一件非常麻烦的事)、过时的文档、CI、CD 和 e2e 测试中可能存在的更新,以及可能在规模扩大后变得明显的更多问题。

        老实说,我们的规模并不大。对于一家中等规模的公司来说,几百个小时听起来是合理的。对于大公司来说,工作量肯定非常惊人。

      • 我说的转换是指所有新项目都使用 Valkey 而不是 Redis,我们在这些新项目上投入了数百个小时。我们还尝试了 Valkey Glide 客户端。

    • 这还算好的。作为个人用户,有人可以在这种情况下分叉并维护 redis,这在 SSPL 时代是不可能的。

      现在,AGPL+CLA 并不是我愿意贡献的许可证,但 Redis 在我的优先级中太低了,反正我也不会为它发布 PR。

      • > AGPL+CLA 不是我愿意采用的许可证、

        为什么?是不是因为只有一家公司可以做专有的 fork?

        你愿意为每个人都可以进行专有分叉的 MIT 软件做贡献吗?还是不含 CLA 的 AGPL(没有人可以进行专有分叉)?

        • > 你愿意为每个人都可以进行专有分叉的 MIT 软件做出贡献吗?

          对我来说就是这样。

          我完全同意人们在 MIT 许可的项目中使用我的 MIT 许可代码。

          但是,在别人的代码库上免费工作,知道他们可以随时将其用于商业用途或做任何他们想做的事,而我和社区的其他成员却只能使用 AGPL,如果可能的话,我宁愿避免这种情况。

        • 是的,不对称是个问题。如果公司使用我的贡献的条款比我使用他们的贡献的条款对他们更有利,那么我就不想玩这个游戏。

          • 无论如何,这都是一种不对称,因为公司可能贡献了 90% 以上的代码、维护了 CI 和网站的基础设施、进行了软件推广等等。

            根据你的贡献动机,你会得到你想要的东西,例如,为一个可能有很多人使用的开源项目做出贡献的感觉,或者让该实体 “免费 ”维护你的补丁。

            如果你愿意,也可以将你的修改保留在分叉中,但你的分叉被使用的可能性并不大,而且这意味着你需要做更多的工作来重置修改。

  8. 当 Antirez 离开 Redis 时,他写了一篇很棒的博文,我经常翻阅 [0]。他在文章中说

    “我写代码是为了表达自己,我认为我所写的代码是一件艺术品,而不仅仅是完成工作的有用工具。我想说的是,我写的东西有用只是副作用,但我的首要目标是在某种程度上做出美丽的东西。从本质上说,我宁愿被人记住的是一个糟糕的艺术家,而不是一个优秀的程序员。

    我很高兴安提雷茨看到他的艺术正在失去美感,而现在,他正在重新找回它!

    0. https://antirez.com/news/133

    • 在人工智能 “你的代码一文不值 ”的时代,能听到这样的言论真是太好了。让这门手艺继续传承下去!

  9. 一年前,我收到一封来自Redis®*的非常愚蠢的电子邮件,它希望我在Redis®*出现在网站上的 “首页 ”写上免责声明,就像纸质法律文件一样。

    就在那一刻,Redis®*在我心中夭折了–我从未遇到过一家对技术工作方式如此冷漠的技术公司。

    希望这种伤害能得到弥补。

    *Redis是Redis有限公司的注册商标。Redis 是 Redis 有限公司的注册商标。Brad Gessler 的任何使用仅供参考,并不表示 Redis 与 Brad Gessler 之间存在任何赞助、认可或附属关系。

    • 你是对的,这种态度得到了纠正。你无法想象,即使没有明确的授权,如果没有正确的管理,法律部门也能做出什么事来。Redis 在首席执行官换届期间发展非常迅速,我相信这造成了很多类似的问题。现在,我们应该已经过去了。举个例子,在客户端库这个非常重要的领域,我们的决定是帮助代码发送 PR,而不是干涉商标之类的事情。

    • 这样做的公司并非仅此一家。这就是为什么基金会在捐赠代码时通常会要求提供商标和徽标。

  10. 如果说从这场闹剧中可以吸取什么教训的话,那就是将软件许可证从自由的开源许可证变更为反竞争许可证(即使源代码仍然可用并开放贡献)是一扇单向门,会失去信任。一旦这样做了,即使你认识到了自己的错误并恢复了许可证,你也无法重新获得信任。

      • Elastic 几个月前就宣布要转回许可,我们现在应该可以衡量结果了。

    • > 你无法重新获得信任

      这不是非黑即白的问题。他们至少会找回一些信任。

      • 任何一个人,只要有能力扯一次地毯,就有能力扯第二次。

        • 你不可能一下子赢回所有的信任,这是一个过程。

  11. 这解决不了任何问题,Redis 已经证明了它愿意 “拉地毯”,而且在 “拉地毯 ”的时候,他们愿意对社区造成多大的伤害(接管客户端库等)。我看不出有什么理由要从 Valkey 回归。Redis Labs是Redis最糟糕的地方,我很高兴我们现在有了其他选择。

  12. 具有讽刺意味的是,几个月前 Redis 更改许可证时,我当时就发表了评论 [1]:

    但谁知道未来会发生什么呢?也许Redis团队会改变主意,像几周前Elastic Search那样重新做出决定:https://news.ycombinator.com/item?id=41394797。

    是的,未来已经到来,Redis 又免费了!

    感谢 antirez 和 Redis 背后的所有团队。

    _________________

    1. https://news.ycombinator.com/item?id=41611636#41612750

  13. 我认为信任度大幅下降的原因是许可方式从一开始的 “允许 ”变为了 “今天的 AGPL”,但 “今天的 AGPL ”比 “永远的 SSPL ”要好得多。

    不幸的是,你可能无法在较低的个位数年内从信任度下降中恢复过来,但这是项目朝着重建最初围绕 redis 存在的 OSS 社区迈出的良好的第一步。

    感谢你们为此而战。希望这能让更多受困于源代码可用性的公司看到,使用开放源码软件许可证也能实现类似的目标。

  14. 这真是个好消息。我从不喜欢新出现的许可证。我了解它们的背景,但总觉得阅读和理解它们是一种负担,而且不知道它们在实践中能起多大作用。GPL 许可证已经存在了几十年,包括法律团队在内的人们对它了解得更多。

    我说的 “了解”,并不是指 “喜欢”:这可能只是让某个团队更容易决定不想使用 AGPL,他们应该去找别的东西,但至少它是什么是很清楚的。与之相反的是一些你从来没听说过的 BSSXYZWL 许可证,听起来像是开源的,但实际上不是……

    • 我最近躲过了一劫;我用 Akka 重写了一大段代码,因为我的想法非常适合演员系统。我在本地机器上用 Akka 编写的代码运行得很好,我正准备在工作中对它进行公关,然后发现它使用的是 BUSL 而不是 Apache,而我一直以为它使用的是 Apache(因为 Java 世界中的很多东西似乎都使用 Apache)。

      我用Pekko(Akka的Apache分叉)写的东西确实能用了,但我对整个过程非常生气,最后我又用Vert.x重写了一遍,在做更多工作之前,我仔细检查了Vert.x的许可证。

      我理解为什么 Akka 认为他们必须使用 BUSL 这样的许可证,因为作为一家小型软件公司很难赚钱,对于开源软件来说更是如此,而且我也意识到我抱怨 “这个用免费劳动力生产的免费产品对我来说不够免费 “是很有权利的,但从根本上说,我真的不认为 BUSL(及其类似许可证)是正确的发展方向。无论是否公平,像 Akka 这样的产品都会与那些对开放源码软件更友好的产品竞争,而从根本上说,我只是打算使用那些产品,如果它们不符合要求,我就会自己对它们进行扩充。

    • 说得好,传统的开放源码软件许可证,我们可以喜欢,也可以不喜欢,但它们是 “被理解的”。

  15. 值得庆幸的是,与 Redis 相比,Valkey 除了拥有更宽松的许可证之外,还有其他优点。其中之一就是支持多线程,这让像我这样在 DevOps 方面有点技术问题的人可以很轻松地将所有 CPU 内核都用于缓存层。

    • I/O 线程最初是由我自己实现的,当时我还在重新加入核心工作,Redis 中也提供了这种线程。因此,这实际上是 ValKey 因能够克隆 Redis 而获得利益的另一个案例,从那些只想最大化收益的超级计算机那里收钱……

      他们后来做了一些改进,但 Redis 8(如果你好奇,请参阅我博文中的发布说明)也在这方面做了很多改进。

      此外,Redis 8 还包含一种新的数据结构–矢量集(Vector Sets),可以做很多有用的事情,还有更多概率数据结构、单哈希字段过期以及其他很多东西。我认为,ValKey 在功能上比 Redis 更胜一筹的说法与事实不符。我们将在明年看到哪个项目走的是最佳发展道路:这才是真正重要的。

      • Valkey 的多线程实现与 Redis 中的多线程实现有本质区别。其历史可以追溯到 ElastiCache 中的工作,该工作以 “增强型 IO “的形式发布,https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-el….。Redis 中发布的版本只能达到约 350k RPS,原因是操作的内存定位性差,无法在处理 I/O 的同时进行命令处理,也无法卸载大部分 TCP 读取路径。Valkey 的新版本可以达到 120 万 RPS。

        “他们后来做了某些改进”,应该是 “我们抛弃了旧的实现,构建了更好的实现”。

        • 1. 基本想法是我的。当然,想法可以改进,这很好。这是我的观点。不过,请允许我指出,Redis 从根本上说是一款 “创意软件”,而非其他任何东西。在技术上,它远非令人印象深刻(Redis、ValKey、所有的分叉)。

          2. 今天发布的 Redis 8 也改进了同样的理念。

          3. 如果你声称(在这里的另一条评论中)你为 Redis 提供了大量代码,那你为什么不为此发送拉取请求?所以,你实际上是在说,你在亚马逊使用了我们提供的所有 BSD 代码,但却不能向我们提供代码的重要部分?你知道这种模式有多糟糕吗?至少别再为它辩护了。

          4. 我们现在可以复制代码的实现了:部分代码是相反的(真是讽刺!),而你们的代码是 BSD 的,就像我们 15 年来一直使用的代码一样。当我们避免做这样的事情时,是因为我们有

          5. 我不明白你和今天在这里发表评论的其他 AWS 人员的动机。你供职的公司正在给开放源码软件生态系统制造问题:这一点很难否认。你们克隆了 Redis 的代码(是的,许可证允许这样做),并在此基础上开展工作,以便让超大规模用户可以继续做他们以前做的事情。我们将 Redis 带回了 AGPL,而你则在评论中维护亚马逊的利益。你看到我在评论你的东西时,当你发布你的东西时,你会说 “啊!但这不公平 “吗?

          这是要做出选择的。我明白,继续在 Redis fork 上工作很酷,开源的不可思议之处就在于 fork 能在不同团队手中存活(但设计理念可能会被误解,项目也可能会变成其他项目)。因此,如果你愿意在 ValKey 上进行 hack,我希望你能从中获得最好的体验。但在如何/何时进行交互方面,还是要做出选择。

          • 这种交流让我很难过。我知道我们可以做得更好。

            我不明白为什么有那么多人认为,在为大公司工作的同时,心中不可能装着开源。我不明白,为什么那些投入大量时间和情感精力,致力于保持开源方式的生命力,并帮助建立社区努力的人,会因为为一家公司工作而受到攻击,而这家公司需要在叙述中成为反派。

            当然,Redis 可以自由复制 Valkey 贡献者添加到项目中的 BSD 许可代码[1]。我只希望关于 Redis 这一进步的博文能给予一些肯定,而不是声称 “我们还提高了 CRC64 计算的性能”[2]。

            我们都可以做得更好,并在相互尊重和钦佩的基础上参与到无偿奉献的活动中来。

            [1] https://github.com/redis/redis/pull/13638

            [2] https://redis.io/blog/redis-8-0-m03-is-out-even-more-perform

            • 你真的想知道吗?

              > 我不明白为什么有那么多人认为,在为大公司工作的同时,心里不可能装着开源。

              因为像亚马逊这样的大公司,与它从开源中获益的程度相比,几乎没有任何开源作品(是的,这里和那里随意收集的一些 repos 和 2 个 PRs 并不是一回事)。(我知道我知道开放源码软件允许所有这些,所以我并没有说错什么)。但这确实表明了公司对开放源码必须采取的政策(尽你所能地使用,除非在特殊情况下,只有在对公司绝对必要时才做出贡献)。

              > 我不明白为什么那些投入了大量时间和情感精力来保持开源方式的活力并帮助建立社区努力的人们会受到攻击,因为他们为一家公司工作,而这家公司需要在叙述中成为恶棍。

              Antirez 并没有攻击上面的任何人。英语不是他的母语,他只是把自己的一些想法说出来(人们可以不同意,但这些都是他的想法),就像你随口说的,你没有为从 valkey 复制的一个提交获得信用(复制者在 PR 中通过链接源 PR 和内联作者给予了应有的信用)。所以他们从 valkey 复制了一个 PR,而 redis 的博文就应该给出很多很多的信用?如果这是标准的话,那么很多 AWS 服务就会把他们所有的再发明时间都花在给源 OSS 项目致谢上了。

              • > 因为像亚马逊这样的大公司几乎没有产生过开源作品

                十年前也许是这样,但现在情况大不相同了。

                > 相比之下,亚马逊从开源项目中获益良多。

                这就是数字公共产品的本质。相对于新的数字公共产品,我们都将不成比例地从数字公共产品中获益。鉴于有无穷无尽的软件可供所有人免费使用,没有人能够 “按比例做出贡献”。

                > 如果这是标准,那么许多 AWS 服务就会把所有的再发明时间都花在为开源软件项目提供积分上。

                善于观察的人应该会注意到这些年来这方面的变化。例如,亚马逊 Q 代码转换[1]的公告就承认,OpenRewrite 被秘密使用了,尽管这是一个无需披露的实施细节……

                当然,这些披露和根据长期建立的社区规范参与开源社区条款的善意意图并不总能如我们所愿。[2]

                [1] https://aws.amazon.com/blogs/aws/upgrade-your-java-applicati

                [2] https://github.com/spring-projects/spring-tools/issues/1443

                • > 鉴于有无穷无尽的软件可供所有人免费使用,没有人能够 “按比例贡献”。

                  因此,听起来我们需要一种许可机制,根据潜在的贡献能力,公平地执行这一点。

                  想法:设定一个基准,给出所需的贡献水平,也许是创收/公司规模和首次使用时间的逻辑函数

                  如果你达不到这个标准,你的许可证就会被终止

                  仔细校准,只给大公司造成负担

                  • 让它成为封闭源代码(或可获得源代码),并以你认为合适的方式发放免费许可证。你是作者,你可以决定如何处理你的代码。这种模式也得到了很好的支持,很多产品都是这样。

                    现在有很多许可证,人们使用 MIT 或 Apache 并不是因为缺乏替代方案。

            • 我的朋友,亚马逊在法律上可以像个笨蛋一样行事,但这并不意味着社区不能指出这一点并对此进行抱怨。AWS (合法地)利用开源项目,这是事实。

              生活中有许多行为和举止并不违法,但如果你去做了,就会导致整个社会的恶化。作为开放源码软件主要贡献者的公司被迫采取严厉措施,这只是 AWS 缺乏团队精神的后果,你至少应该体面地不在这里发表评论。

              注 我没有参与这场竞赛,我也不是 Redis 用户,我只是对以下情况感到震惊

            • > 我不明白为什么那么多人认为,在为大公司工作的同时,心中不可能装着开源。

              你签的劳动合同。

          • > 所以,你实际上是说,你在亚马逊使用了我们提供的所有 BSD 代码,并将代码的重要部分提供给了我们?你知道这种模式有多糟糕吗?至少别再为它辩护了。

            我不是在为它辩护,我是在努力修复它。我希望亚马逊能做出回馈。这就是我花了大部分时间做的事情,但我不能只是坐在会议上告诉大家我们应该赠送代码。我们需要时间来说服人们,我们应该在核心方面进行合作,而只是在我们想要实现差异化的方面进行竞争。我们需要时间来说服人们,在一个厂商中立的环境中构建开源软件,才能为所有人带来更好的软件。

            我希望这是有道理的。

            • 你拥有所有权利。通常,我都会尽力避免此类冲突,并尊重他人的工作。但我看到某些交流模式对我来说太过分了,我需要说出来。我认为,在公告日期间,在 HN 上以咄咄逼人的方式评论竞争对手的作品,从根本上说是错误的。

            • 相反,这让我更加欣赏 antirez,他不仅是一位开发者,更是一位真正的开源拥护者,他真正希望开源能够繁荣发展,并愿意在需要的时候发表自己的意见。

      • > 因此,这实际上是 ValKey 因能够克隆 Redis 而获得利益的另一个案例,它从那些只想最大化收益的超级计算机那里收钱…

        我不认为你想泼脏水,除非 Redis 趁我不注意改成了非营利组织。

  16. 首席执行官提供的更多信息:https://redis.io/blog/agplv3/

    听起来 SSPL 没有达到预期效果。

    很高兴现在可以选择 AGPL。

    • 它确实产生了预期的结果: 谷歌和 AWS 不再使用它了。

      • 如果你所说的预期结果是指分裂开发者社区,然后把他们赶走,转而使用新分叉的竞争对手,而现在所有云提供商和喜欢开源的用户都在广泛使用它;那就完全成功了!

        但我怀疑这是不是他们希望的结果。他们创造了一个庞大而成功的竞争对手,而这个竞争对手由于是分叉的,所以做的事情完全一样。要与自己竞争并与自己的产品区分开来是很难的。

        老实说,我认为 Redis 公司在只有一个代码库的时候会更好。AGPL 只会让他们进一步边缘化。许多公司的法务部门都无法接受 AGPL 许可证。因此,这类公司必须购买商业许可证。例如,财富 500 强公司、上市公司,以及几乎所有拥有名副其实的法律部门的公司。请注意 Redis 是如何将 AGPLv3 作为 “可用许可证之一 “进行宣传的。该许可证的全部意义在于销售商业许可证。

        在这一点上,Valkey 是稳定的、受支持的、可替代的。对于那些对购买商业许可证不感兴趣的人来说,它几乎是默认的选择。有了这个许可证,精灵就不会再回到瓶子里了。

        更重要的是,Valkey 是一个相当活跃的 Github 项目,上个月就有数十位贡献者。是 Redis 的两倍还多。这些提交并不会流向 Redis。而且,如果你试图贡献,Redis 仍然要求你有权重新授权你的提交。这也是他们一开始能使出这一招的原因。我怀疑很多 Valkey 的贡献者都会回到这种现状。

      • 你是怎么得出这个结论的?GCP 仍在为 Redis、Valkey 和 Memcached 提供 Memorystore。https://cloud.google.com/memorystore。

      • 我不知道超大规模云转而使用 Redis Labs 无法从中获得任何价值或贡献的兼容/竞争项目是一种怎样的胜利。

  17. 真正的问题:我想启动一个项目,从根本上说,我想将其开源。我希望人们,尤其是在公司工作的人使用我的项目。

    但是,我也希望如果项目成功,我能够以此为生,即在此基础上开展业务。我想,如果该业务纯粹与托管拷贝竞争,那也没有问题。

    但是,我不希望任何超级计算机分叉和关闭项目源代码。我希望所有利益都能继续存在。

    因此,我似乎应该选择 Agpl。但我知道,在大多数公司,这会导致被列入黑名单,尤其是在欧盟,因为在那里,AGPL 的法律含义并不明确。如果没有企业的支持,我看不到这个项目会获得牵引力,所以我只想为自己做这件事。

    有了许可授权,要想全职从事这项工作,似乎就不可避免地要经历一场拉锯战。

    怎么办?

  18. 非常有趣的是,这发生在 NATS 走向专有的同时。显然,Redis 的知名度要高得多,但作为一个在过去几年中使用 NATS 构建了大量系统的人来说,这让 Redis 再次成为一个有趣的迁移选择。

  19. MinIO 不久前也改用了 AGPLv3,他们表示:”AGPL 许可证要求所有与 MinIO 连接的软件都必须 100% 开源,这样你/你的用户才不会违反许可证。”[^1] 由于 Redis 和 MinIO 有些相似,(两者都可以用来存储和检索数据。Redis 使用自定义协议,而 MinIO 使用与 S3 兼容的 API)。我是否应该认为这句话也适用于 Redis?

    [^1]: https://github.com/minio/minio/issues/13308#issuecomment-929

    • 是啊,至少对我来说,min.io 真的让 AGPL 许可证变味了。因为他们的立场,我们公司已经不再使用 min.io,而是像躲避瘟疫一样躲避所有 AGPL 协议。在多次阅读许可证和所有相关讨论后,我明白在商业企业中使用 AGPL 项目应该是没有问题的(在不做修改的情况下,在后端网络内部使用)。但是,如果此类项目的作者自己不这么认为,也不这么说,我真的不会冒任何风险,也绝对不会去问律师 “我对 min.io 的具体使用是否违反了许可证”。我只是通过网络在我的后端部署中按原样使用它。没有修改,也没有暴露给外部世界。

      • > 我认为在商业企业中使用 AGPL 项目(不做修改,在后台网络中内部使用)应该没问题。

        进行修改也没问题,只要这些修改也被分发出去。”源代码与二进制文件一起发布 “是一般规则。你甚至不必开放你的整个堆栈(那是 FUD),只需在 AGPL 下开放你修改过的部分,而且只在你发布时开放。公司可以而且一直在内部使用这些项目,没有任何风险。

    • 我相信 AGPL 实际上并不要求这样做,尽管 MinIO 可能认为它要求这样做。我希望有一天有人会因此被起诉,这样我们就可以知道了。

      • 这根本没有意义。因为你甚至不一定知道你正在连接的东西拥有什么许可证。甚至连联邦调查局都不这么认为。

        • 当然,如果你连接的是使用 AGPL 的服务,服务运营商必须提供源代码和许可证副本。

          我不是律师,但除非相关软件对特定的 API 作了例外处理,否则我不会有信心。

          或者说,这里有什么区别?

          • 只是因为 OSI 是这么说的。我不同意 OSI 替我定义哲学立场和技术术语,就像我不同意 BSD 人士将 GPL 排除在开源定义之外一样。

            • 我同意 OSI 不是唯一的权威。那么,DFSG、FSF、任何 BSD 或任何可信的人都认可它是自由和/或开源的吗?

              • 他们都没有费心去评估它,或者已经明确决定它暂时不值得评估。他们也没有认可它为专有和/或封闭源代码。

                请注意,OSI 的反对意见实际上毫无意义,可以适用于任何版权许可!根据同样的推理,AGPL 也不是开放源代码。但他们却说它是。

              • 您所列举的人都没有,只有其他与 FOSS 相关的运动,如公平源代码等。

  20. 为什么我永远不会尝试将自己的项目货币化:

    1. 要使一个项目货币化,它必须首先获得广泛采用。

    2. 要获得广泛应用,它必须拥有许可授权。

    3. 要成功实现货币化(获得广泛采用后),必须拥有限制性许可。

    4. 4. 将项目的许可证改为限制性更强的许可证会疏远社区,不利于项目的采用。

    我看不到解决这一难题的办法。

  21. 玩法是这样的: 使用 AGPL 开源,然后提供企业许可证。你将一举两得。开放源码软件社区对你采用积极的开放源码软件许可证表示赞赏。企业客户不能使用 AGPL 下的软件,因为这有可能感染他们的知识产权,所以他们不得不购买企业许可证。

    • > 企业客户不能使用 AGPL 下的软件,因为这有可能感染他们的知识产权

      这与事实不符。如果你想把一个 AGPL blob 链接到你的应用程序中,然后发给客户,当然可以。在更常见的情况下,你使用一个许可客户端库[0]连接到 AGPL 服务器,则没有任何风险。

      https://redis.io/blog/redis-license-bsd-will-remain-bsd/

  22. 为什么我永远不会尝试将自己的项目货币化:

    1. 要使一个项目货币化,它必须首先获得广泛采用。

    2. 要获得广泛应用,它必须拥有许可授权。

    3. 要成功实现货币化(获得广泛采用后),必须拥有限制性许可。

    4. 4. 将项目的许可证改为限制性更强的许可证会疏远社区,不利于项目的采用。

    我看不到解决这一难题的办法。

  23. 玩法是这样的: 使用 AGPL 开源,然后提供企业许可证。你将一举两得。开放源码软件社区对你采用积极的开放源码软件许可证表示赞赏。企业客户不能使用 AGPL 下的软件,因为这有可能感染他们的知识产权,所以他们不得不购买企业许可证。

    • > 企业客户不能使用 AGPL 下的软件,因为这有可能感染他们的知识产权

      这与事实不符。如果你想把一个 AGPL blob 链接到你的应用程序中,然后发给客户,当然可以。在更常见的情况下,你使用一个许可客户端库[0]连接到 AGPL 服务器,则没有任何风险。

      • > 编辑:与 gpt 进行了双重检查,还没有 “感染 “的案例,也有很多关于该许可证非常好的讨论。

        你为什么要让一个法学硕士随机生成一些文本,而不是查找实际答案?

      • 替代方案是/曾经是 BSD。

        企业讨厌 AGPL。在公司内部,AGPL 通常不是 BSD/MIT 的重要替代方案,因为有些东西(A)会毒害 GPL。

        这是否属实并不重要,重要的是大科技公司是否认为 AGPL 具有传染性–他们确实这么认为。

        • > 无论真假都不重要

          这很重要。一家公司可能会做出节省大量资金的选择,因此他们最好根据准确的信息而不是谣言做出决定。

          (还要注意的是,大型科技公司有不同的动机)

    • > 企业客户不能使用 AGPL 下的软件,因为这有可能感染他们的知识产权

      是的,这是胡说八道。

      如果只是使用 AGPL 软件,它不会 “感染 “任何东西。如果对 AGPL 软件进行*更改,则必须发布更改内容。这将迫使大型云计算公司开源他们对 Redis 的改进。

      • 对于 Redis 所针对的软件类型而言,网络集成是必须的。因此,”仅仅使用它 “并不是一个可行的选择。AGPL 不是 LGPL,它会感染任何通过网络使用它的东西。如果 Redis 在发布时是 AGPL,就不会有人碰它。

        HN 的大多数读者都以闭源软件为生。你很清楚,无敌意的开放源码只是一种市场进入策略,而版权驱动的最大化自私资本主义市场只会迫使开放源码无法在单个公司茁壮成长。像 Linux 内核这样的项目是特殊的基础设施项目,需要外部公司的支持,而不是为了出货而建立业务。

        • > 因此,”只是使用它 “并不是一个可行的选择。AGPL 不是 LGPL,它会感染任何在网络上使用它的东西。

          这是完全错误的。

          你可以使用 Redis 第一方的 MIT 许可客户端库连接 Redis。你可以使用该库编写专有软件,而无需在任何特定许可证下发布软件(当然,你仍然必须遵守 MIT 许可证的归属要求)。

          如果连接到 AGPL 服务的所有软件都在内部运行,则您没有义务共享对该服务的本地更改。这涵盖了绝大多数使用案例。使用带有 Redis 缓存的 WordPress?这对你没有影响。

          如果你托管一个 AGPL 版本的 Redis 服务器,而你的客户从他们自己的网络连接到该服务器,那么与久经考验的 GPL 相比,你唯一的义务就是必须与用户共享你对 Redis 服务器所做的修改。如果你像几乎所有人一样按原样使用 Redis 软件包,这对你并无影响。

          因此,现在唯一需要关心 Redis 是否适用 AGPL 的人,就是那些不想向 Redis 支付商业授权费用、向客户公开自己的 Redis 服务器、对自己的 Redis 服务器进行本地修改的人。其他人则可以像以前一样继续使用。

          • 关于 GPL/AGPL 的 FUD 之多令人惊讶。我在这个主题上至少看到 10 个帖子,说如果你使用新的 Redis,就必须开源你的商业软件。我不知道人们怎么会对最常见的软件许可证之一存在如此根本的误解。

            • 即使是 APGL 的用户,有时也对其适用范围一无所知。其中一个例子就是现在采用 AGPL 的 minio,开发人员经常在他们的 github 上对许可证做出虚假声明:https://github.com/minio/minio/issues/13308#issuecomment-929…

            • 我知道,对吧?公司在说服开发人员相信版权许可的 “危险性 “方面做得很好,他们更倾向于使用那些纯属巧合、恰好有利于商业用户的许可。

            • 如果你使用Redis,你就不必这样做;如果你嵌入Redis,你就必须这样做。GPL 也一样

        • > AGPL不是LGPL,它会感染任何在网络上使用它的东西。

          别撒谎了。这是谣言。必须以极端的偏见来无视它。AGPL 必须保持自由,任何通过网络与之交互的人都必须有机会获得 AGPL 软件的原始版本或修改版本,仅此而已。没有人说过要开放整个网络堆栈。那是 SSPL 的领地。

    • > 企业客户不能使用 AGPL 下的软件,因为这有可能感染他们的 IP,所以他们不得不购买企业许可证。

      这是谎言。这是 FUD。我们应该以极端的偏见无视它。别说了。

      首先,AGPL’d 软件必须保持自由。他们可以在自己的堆栈中使用它。规则是他们必须指出 AGPL’d 软件的来源。如果他们对 AGPL’d 软件进行了修改,并且用户与之进行了交互(即使是通过网络),那么他们必须公开对 AGPL’d 软件的修改。就是这样。他们不必开放整个堆栈。这就是 SSPL,所以不要再散布这种谣言了。

      其次,这不是他们的知识产权。他们没有编写 AGPL’d 软件。他们必须遵守其条款。

      第三,即使他们选择(强调是 “选择 “而不是 “强迫”)使用 AGPL’d 软件,他们也可以简单地公开他们对该软件所做的修改。几乎没有理由不这样做。事实上,如果软件能满足他们的需要,他们几乎没有理由不这样做。AGPL 的存在是为了保护软件自由,因此如果他们认为这一点令人反感,那么只能得出这样的结论:他们有意损害自由软件。

    • 我想你想到的是 GPL。许多公司都乐于在他们的堆栈中使用 AGPL 许可的软件。

      • 我想你想到的是 LGPL。AGPL 基本上就是 GPL 加上一些附加要求。我认为公司可以接受 ~AGPL~ GPL,但不能接受 ~GPL~ AGPL。我无法想象相反的情况。

        编辑:哎呀,许可证名称打错了。

        • 我觉得你把 AGPL 和 GPL 弄混了。我同意,很难想象一家公司能接受 AGPL 而不接受 GPL。万一这不是错别字,你能解释一下为什么一家公司可以接受 AGPL 而不接受 GPL 吗?

          • 哎呀,你说得对。是的。我知道他们会批准 GPL,但不会批准 AGPL。我无法想象任何公司会批准 AGPL 而不批准 GPL。

  24. 在穆伦维格的所作所为之后,在博客首席执行官的时代,我不得不愤世嫉俗。

    瓦尔基

    • 呵!虽然我很欣赏你的观点,但我认为这与 WordPress 恰恰相反。这基本上是一个首席执行官在说,哎呀,我们搞砸了,让我们来解决这个问题吧,这与加倍努力并最终对簿公堂有着本质的区别。

      • 对不起,你说得对。集成电路、首席技术官和首席执行官。哦,天哪。请原谅我不同意再玩一次问责的空壳游戏。我再次给穆伦维格打电话。

        /s,以防我说得不够厚,造成影响。

        请阅读 TFA [0] 的最后一个链接,以及上一次出现此问题 [1] 时的链接(注意时间跨度),并根据需要进行推断。

        0: https://redis.io/blog/agplv3/(首席执行官)

        1: https://redis.io/blog/redis-license-bsd-will-remain-bsd/(首席技术官)

        或者不要,我不在乎。观点/修正已经提出。

        • 我不太清楚你的观点是什么。Salvatore Sanfilippo(又名 antirez,本博文作者)从未担任过 Redis Ltd. 的首席技术官或首席执行官。Redis 并非由他创办,他也只是在那里短暂工作过(相对于公司成立的时间而言)。

          • antirez不是我愤怒的焦点,别说了。他们只是不幸距离太近。真正的首席技术官告诉我们 “永远是 BSD”。现在萨尔瓦托告诉我们,它并没有完全失效。好极了!

            只是……首席执行官忘了。这是关于 AGPL 和 “大坏云 “的一课。饶了我吧,不然我也要休息一下了。

            冒着进一步混淆视听的风险 YouTube正在泄密,这就是我的观点。再次道歉,我没有详尽地表达我的批评。

            最后再试一次: 我很高兴能有这样的传播,但我不太喜欢重复许可证的讨论。所有员工的博客增加了一个令人沮丧的因素。现在这已经成为一种趋势,遍及各个企业。

            对于穆伦维格的所作所为,另一位健忘的首席执行官,我(不得不承认,过于)愤世嫉俗。

            你怎么会认为我是在说 antirez 是 CEO 呢?我很难相信你说的是真话,而是在耍我。完全是无稽之谈/复合推理的失败。

            •  ~ $ curl -s 'https://news.ycombinator.com/user?id=fastball'
               [...]
               I used to argue on the internet too much.<p>Co-founder and tinker at supernotes.app
              

              啊,现在都说得通了。另一个批评点。或者,一个超级笔记,如果你愿意的话: S/used to//

              • 我并不是在和你争论(因为你的评论中并没有可供争论的实质内容),我只是对你的一系列无理取闹感到困惑。在一篇博文下提起穆伦维格,而博文的作者并不是另一家公司的首席执行官,这家公司迄今为止的行为与穆伦维格大相径庭,这实在是……没有多大意义。因此,我善意地假定你可能不了解公司的实际动态,并据此进行了报道。¯_(ツ)_/¯

                • 不需要也不想要你的错位施舍。过去一天的投票和出轨比例告诉我,你是个异数。这很有趣,保重。希望更有效。

  25. 恭喜你,antirez!我相信这是内部的巨大努力,希望 Redis 团队能成功发布 SSPL+AGPL 下的软件。

  26. 那么,如果 Redis 采用 AGPL 协议,谁算用户?

    如果你有一个在后台使用 redis 作为任务队列的 webapp,那么 webapp 的用户算不算是 redis 的用户,然后你就必须向 redis 提供源代码?是否有可能需要发布应用程序代码才能符合要求?

    • 我刚刚读了 AGPL 和常见问题解答,我也不太清楚。

      也许这就是为什么很多公司觉得 AGPL 有毒的原因。

    • 不,Redis 的用户是连接到 Redis 的人。此外,你链接到程序中的 Redis 客户端库已获得 MIT 许可。除非你直接在应用程序中嵌入 Redis,否则你永远不必发布自己的代码来使用它。

    • 这是我反对 AGPL 的首要原因。它仍然比 SSPL 或 BUSL 好得多,但我现在还是坚持使用谷。

  27. 正如其他人所指出的,除非 Redis 实际使用 AGPL 作为软件的主要许可证(即入站=出站方式),否则这一点无关紧要。https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

  28. 要在 “免费 “的基础上建立业务,其中一些开源许可证是有缺陷的。

    难道不可以在某些许可证中增加一项条款,规定如果你使用开源软件并从中获得了一定的收入,就必须向项目提供一定的回报。

    我完全理解软件免费的初衷,但难道就没有一个平衡点吗?

    在我工作过的许多地方,Redis至少是业务成功的支柱。这些地方可以为基于免费软件的创收支付费用吗?

    这合理吗?

    • 在我看来,这样做的意义在于许可证必须具有感染力,即便如此,你也会遇到在依赖关系树中分割版税的问题,而这个问题并不琐碎,也不难解决。Redis 本身使用其他开源库,等等。这是一个棘手的问题,但这并不妨碍我们去尝试,任何数量的无附加条件开源资金都比现在的情况要好。就我个人而言,我希望通过一些希望不存在冲突的政府机构来确定哪些项目比其他项目更值得资助,从而将纳税人的一些钱转给开源项目的维护者,从而解决这个问题。

    • 是的,这就是所谓的专有软件,对于非商业使用和一定规模以下的公司是免费的。Docker Desktop 使用的就是这种许可证。

  29. 我很希望亚马逊能提供 Redis 服务,遵守 AGPLv3 而不是使用其他 Redis 许可选项,并进行收入共享,以激励更多商业源代码可用项目走这条路。

      • 有意思,有更多相关公开信息吗?如果没有,你/Redis 是否考虑过将其写入博客?

        • 早在 11 月份就已经宣布了:https://redis.io/blog/introducing-azure-managed-redis/

          • 那是在 AGPL Redis 发布之前,所以听起来不像我说的那样。听起来更像是只给微软的自定义许可证。

  30. – 8.0 – 根据 RSALv2/SSPLv1/AGPLv3 获得三重许可

    – 7.4 – 基于 RSALv2/SSPLv1 的双重许可

    – 7.2 及更早版本 – 3BSD

  31. 没有看到任何关于 KeyDB 的提示… 也许我错过了什么显而易见的东西,但它解决了我的一个小用例,这个用例可以延伸到 Redis 付费墙的另一侧。我对 KeyDB 非常满意。

  32. AGPL: 毫无用处的开源。任何想用它赚钱的人,即使它只是你技术栈中的众多组件之一,也必须开源所有组件。这就促使人们采用同一软件的付费版本,而不是开源版本,这无疑是关键所在。采用 AGPL 是一个经过深思熟虑的冷酷举动。

    • > 将不得不开源一切

      别撒谎了。这是谣言。必须以极端的偏见加以蔑视。这完全是不正确的。

      你可以使用 Redis 第一方的 MIT 许可客户端库连接 Redis。你可以使用该库编写专有软件,而无需在任何特定许可证下发布软件(当然,你仍需遵守 MIT 许可证的归属要求)。你甚至可以向用户提供该软件。唯一的条件是,你必须根据 AGPL 许可证的条款,向你的用户分发原始源代码或你对堆栈中的 AGPL 部分软件所做的修改。没人说你必须开放整个堆栈。那是 SSPL 的领地。

  33. 这里的评论让我有些困惑。当然,Redis Ltd.能否再次获得信任还有待观察,但我们就不能为(再次)拥有一款免费许可证下的优秀软件而高兴一下吗?

  34. 很高兴看到这个。12 年前,我在一个非常清闲的周末编写了 https://github.com/rcarmo/miniredis,当时我既想了解 Redis 的内部工作原理,又想拥有一个自己的 PubSub 服务器。

    我花了整个周末的时间研究 C 代码,发现这是我读过的最漂亮的 C 代码(自从 SunOS 的辉煌年代以来),现在我觉得我至少应该去把 miniredis 升级到 asyncio/Python 3 –为了好玩……

      • 已经开始了。python3 分支。克劳德删除了我所有漂亮的惯用条件表达式,但我对服务器的(少量)测试已经通过,接下来将对 aioserver 进行测试:)

  35. 在有机会更仔细地查看了源代码之后,我很高兴看到这个消息(出于一些无关的原因)。阅读 Redis geohash/gis 相关的实现真是一种享受。

    • 我能理解 SSPL 许可证的问题,但我不能理解 AGPL 许可证的问题。如果你免费使用 SAAS 服务的软件,并对其进行了修改,你就应该与他人分享这些修改。这是免费软件,不是给你的企业的礼物。

  36. 又是免费软件?它不是从 BSD 变成了某种有感染力的 Copyleft 吗?在我看来,如果我们不能在私人工作项目中使用它而不被迫开源我们的项目,那么它就不是 “再次开源”。AGPL 不是比他们原来用的更糟糕吗?再次开源 “不就意味着回到 BSD 吗?

    • > 再次开放源代码?它不是从 BSD 转向了某种有感染力的 Copyleft 吗?

      他们用的是 SSPL,它不是开源的。(至于它是否是 Copyleft,读者可以自行判断。我真的不知道,我得盯着定义看一会儿才能形成看法)。

      > 在我看来,如果我们不能在私人工作项目中使用它,而不被迫将我们的项目开源,那么它就不是 “再次开源”。

      我不是律师,但为什么你不能在私人作品中使用它呢?据我所知,AGPL/GPL 的病毒部分只说你必须与软件用户共享源代码;如果你的用户只有你自己,那就无关紧要了。

      > AGPL 不是比他们原来的版本更糟糕吗?再次开放源代码 “不是意味着回到 BSD 吗?

      更糟/更好有点主观,但 AGPL 是一种(自由和)开源许可证。它曾经是开源的(BSD),后来不是了(SSPL),然后又是开源的(AGPL)。

  37. Elasticsearch 也采取了类似的举措,在其现有的可用源许可证上附加了 AGPL。[1]

    与高管相比,通常由开发人员选择和拥护的产品(商业化开源)会看到诱饵和转换对其受欢迎程度的危害。由于他们的竞争对手更加放任,除非 Valkey 在功能上失去明显优势,否则我看不到有多少开发者会回头。

    [1] https://ir.elastic.co/news/news-details/2024/Elastic-Announc

  38. 不,虽然我很喜欢最初的 Redis,但他们在许可证变更后就放弃了。在我看来,他们似乎意识到得太晚了。他们本有机会回头,但现在看来,他们正在以某种方式流血,并试图恢复元气。在此期间,其他的临时解决方案取而代之。

    但我并不为他们感到遗憾。

  39. 这个帖子有点误导,因为 agpl 是一个许可选项,而不是许可证。

    不过,这是一个很好的权衡。Grafana 也是这么做的,而且做得很好。

    我希望 redis 能长命百岁,现在它比以往任何时候都更加开放(本质上它现在是自由软件了):)

    在 redis 出事后,我希望更多的人开始意识到 GPL 许可证才是真正的途径,而其他许可证(如 Redis 曾经使用的 BSD)则风险太大。

  40. 使用 Apache 基金会的软件进行工程设计/应用程序设计可能是首选,这样痛苦较少。改变基础架构的压力非常大。因为 AGPL 会威胁商业应用程序开源其代码。在流行之后再改变许可证是不公平的。

  41. 我是以擦洗终端用户的身份提出这个问题的。分叉对 Redis 有什么影响?具体来说,我想知道的是,像 valkey 这样由有能力的程序员[1]开发的分叉是否仍然是好的选择,还是 Redis Inc.

    [1] 我之所以这么想,是因为 valkey 属于 Linux 基金会旗下。

  42. 我想知道他们是否在幕后与 AWS 和 Google 达成了协议。比如 “你们在 Valkey 上投入了大量资金,不如把这些钱给我们,我们就改用 AGPL,你们就不用再用两个几乎完全相同但价格不同的选项来迷惑两个客户了”。这能行得通吗?(我不知道)

  43. 我一直对开放源代码心存感激,但关于 AGPL,我只能引用凯尔-米切尔(Kyle Mitchell)律师的话:

    “醉醺醺的外星人还不如把它从太空中传送下来,作为一种恶作剧……”

    “这不仅对律师来说很难,因为他们掌握了法律知识,可以非常仔细地分析整个许可证而不会昏过去……对黑客来说也很难,即使是那些熟悉自由软件传说的人,他们也缺乏法律方面的知识,不知道事情还可能是怎么说的。试想一下,不懂软件、法律、法律起草、软件架构、黑客文化或 Richard M. Stallman 自诩的’哲学’思考的人是什么感受?

    https://writing.kemitchell.com/2021/01/24/Reading-AGPL

    正如米切尔所暗示的,想要获得网络版权的人应该研究更直接的 OSL3。

    但这是件好事,而且不是我能决定的,因为代码不是我写的,所以我只能心存感激。

    • 如果你是一名律师,如果你试图以某种方式绕过许可证,或者如果你必须对滥用许可证的人进行辩护,那么 AGPL 就具有挑战性,但作为自由和开放源码软件的用户和开发者,它是非常简单的:软件运行在服务器上,你连接到它,你就可以访问服务器上运行的源代码。

      如果你纠结于哪些代码需要共享,哪些不需要共享,那么你就没有遵循自由软件的精神。就这么简单。

      另外,考虑到 AGPL 试图与 GPL 兼容,这就迫使它变得更加复杂。OSL 就没有这个问题,而且 OSL 也与 GPL 不兼容,这只有在你不想集成任何其他 GPL 软件的情况下才可以。不过我想,由于 GPL 并不要求在网络访问上发布,这可能不是一个问题。

      • > 如果你对哪些代码需要共享、哪些不需要共享的细节斤斤计较,那么你就没有遵循自由软件的精神。就这么简单。

        凯尔的观点非常明确:我们很难说清楚 agpl 究竟需要什么。因此,无论你的立场是什么–你是认为你的代码应该让所有链接它的东西都成为开放源代码,还是你明确表示不希望这样,只希望库本身成为网络版权。agpl 究竟需要什么?连律师都一筹莫展。

        • 但我的观点是,如果我像自由和开放源码软件爱好者那样分享一切,那么我就不需要担心细节问题。细节问题只对那些不喜欢自由和开放源码软件、被迫遵守许可证而又不想这样做的人有影响。

          有人可能会说,复杂的许可证会降低我的软件的吸引力,但同样,如果我不是为了流行起来,我就不会在意这些。对于我的付费用户来说,他们也不应该在意,因为他们得到的仍然比从专有软件中得到的要多,或者说他们付钱给我是为了得到一个例外。

          所以,如果我的软件许可证对你来说太复杂,那就运气不好了。

          • > 但我的意思是,如果我像自由和开放源码软件爱好者那样分享一切,那么我就不需要担心细节问题。

            只有当你也不关心其他人需要对你的代码做什么时,你才会这么想。那些希望对自己的贡献实施版权保护的人会关心许可证是否真的实施了版权保护,以及如何实施。

            > 如果我的软件许可证对你来说太复杂,那就祝你好运吧。

            当然,好吧。我在上一条评论中的整个观点是,这对/创造者/来说很复杂。我说的不是用户。写得不好的许可证是双向的。

            • 但对作为创作者的我来说并不复杂。

              我已经在我的第一条评论中提到了实施的困难:如果你必须为许可证辩护,以对抗滥用者,那么 AGPL 就具有挑战性。

    • 这是我第一次读到 OSL3 (https://opensource.org/license/osl-3-0-php)。

      我对许可证很不了解,我承认我没有完全理解它。乍一看,它似乎是一种更简单、更易读的许可证,试图实现与 AGPL 类似的目标。我认为 “当你起诉我专利侵权时,许可证终止 “的条款很有意思。

      但它说 “外部部署 “也算 “发布”(好吧,公平),这意味着你也必须为你的改动颁发 OSL 许可证(好吧,也公平)。

      但在实践中,这如何防止 AWS 和 GCP 云托管你的软件而不给予回报呢?在我看来,如果 Redis 采用 OSL3,GCP 可以托管它,只要他们对所做的任何修改进行 OSL3 发布即可。

      • 在实践中,这如何阻止 AWS 和 GCP 云托管你的软件而不提供任何回报?

        公司避免使用 AGPL 的唯一原因是,AGPL 规定与软件集成的任何东西都必须同时发布。他们避免使用 GPL 也是出于同样的原因。我不知道 OSL 是否也这样做。

        AGPL 阻止竞争是因为公司害怕竞争,但这并不是它的初衷。

        这正是 Redis 和其他公司面临的真正问题:我们如何才能与用户共享源代码,同时又不让资金雄厚的竞争对手吃掉我们的午餐。

        目前有几种实验性的许可证正试图解决这个问题,其中包括 FUTO 正在研究的许可证,布鲁斯-佩伦斯(Bruce Perens)也在研究这个问题,但到目前为止还没有明确的选择。

      • > 但在实践中,这如何防止 AWS 和 GCP 云托管你的软件而不给予回报?在我看来,如果 Redis 采用 OSL3,GCP 可以托管它,只要他们对所做的任何修改进行 OSL3 分发即可。

        你对 “回馈 “的定义是什么?在我看来,这意味着将你所做的修改开源,正如你所指出的,这正是许可证所要求的。

        • 是的,对不起,考虑到主题,我选错了词。我的意思是以某种方式向他们支付特权费用,而这正是 Redis(公司)一直以来的目标。GP 建议 OSL3 解决这个问题,我正在想办法。

          • 哦,我明白了。虽然我不是很懂,但如果 agpl 的计划是向那些不想担心 FOSS 许可/感染问题的人出售商业版本,那么正因为缺乏明确性,它可能是一个很好的许可。你也可以用 OSL 来做类似的事情–“付钱给我们,让我们用另一种许可来获取它,在那里你可以制作封闭的衍生作品”–但 OSL 显然允许链接(根据其作者的说法),而仅仅是链接并不需要打开链接它的东西,所以严格来说,它对 Redis 来说可能更糟。

            我只是说 OSL 作为许可证比 agpl 好(我认为)。它非常清晰。但不明确也有战略价值。

  44. 假以时日,我将建立这样一个网站–https://github.com/hsnice16/golang_learning/tree/main/One2N/…

  45. 在此期间,我相信有很多替代方案(大多与 redis 协议兼容,因此可以直接替换)出现了。

    是否已就其中一种达成共识?有没有胜出者?

    我喜欢 Redis,可能会一直用下去。只是好奇而已。

      • 此外,Heroku 等 PaaS 也采用 Valkey 作为 Redis 的直接替代品。

      • 它是最新oss版本的一个分叉,对吗?我以为引入了一些全新的实现。

        • 这不仅仅是一个分叉,Valkey 已经发布了两个版本,提高了性能和内存效率。Redis 喜欢散布一个谎言,说在分叉时只有他们自己的员工在开发核心引擎,但 Valkey 上的大多数工程师都是直接从 Redis OSS 工作过来的。最近的一个例子是,我们对哈希表进行了一些现代化改进:https://valkey.io/blog/new-hash-table/.

          • 没有人愿意否认 Redis 从外部开发者那里获得了贡献。但从根本上说,在过去的 8 年中,几乎所有的实质性贡献都是由 Redis 的员工创造的。

            我们有提交历史、GitHub贡献图。一切都是公开的。当前的代码库大部分是由几个人编写的,另一小部分是由社区中所有随机人员编写的,还有一小部分是由现在在 ValKey 工作的人编写的。

          • 这篇 Lwn 文章支持许多云提供商为 Redis 做出贡献的论点:https://lwn.net/Articles/966631

            > 云提供商没有贡献的说法也很难与 Redis 仓库的实际提交情况相一致。使用 gitdm 对 7.0.0 发布以来的提交进行的快速检查显示,在此期间有 967 次提交:

                Top changeset contributions by employer
                (Unknown)         331     34.2%
                Tencent           240     24.8%
                Redis             189     19.5%
                Alibaba            65     6.7%
                Huawei             50     5.2%
                Amazon.com         50     5.2%
                Bytedance          19     2.0%
                NetEase            13     1.3%
            

            > 腾讯公司的朱彬彬负责了该项目近 25% 的提交。一些没有明确雇主的贡献者肯定是 Redis 的员工,但很明显,Redis 并非孤军奋战。

            • 如果你进入任何一个分叉的 GitHub,查看贡献页面,就会发现这些数据并不正确。可能我所有的提交都在这个 “未知 “里,因为我大部分时间都是用 @gmail.com 账户推送的,没有加入任何组织。

              这可能是某些特定 fork 或类似组织的部分数据。

              • LWN 的文章正在研究 7.0.0 发布后的 976 次提交。我不认为你在那段时间有任何提交?

                在软件项目中,早期作者在修订历史中的比例通常会过高。我仍然是红帽 Linux 最初使用的 Anaconda 安装程序 [1]、RHEL、Fedora 和其他软件的第 4 位贡献者,尽管我已经二十年没有贡献代码了。

                [1] https://github.com/rhinstaller/anaconda/graphs/contributors

  46. AGPL 使用的增加是一个好迹象。希望更多的人开始意识到,版权许可对我们(人类、社区)有利。许可协议是为大公司准备的。

    看看这些评论,就知道鲍尔默/微软的 “感染 “言论对自由软件造成了多大的损害。人们竟然会选择对微软有利的东西。提示:如果微软喜欢某样东西,那么你(一个人)几乎肯定想要完全相反的东西。

  47. Redis 现在就应该挺身而出,资助一个独立的基金会,并鼓励 Valkey 做出相关贡献。

    在 3 条款 BSD 和 AGPLv3 下的一些代码可能会很有趣。

      • 我不知道这样做能达到什么目的?将 GPLv3 和 AGPLv3 下的程序结合起来是可能的(产生的作品属于 AGPLv3 下)。

        • 我认为 _msw_ 所指的不平衡是 Valkey 无法既从 GPL 许可的 Redis 中获取代码,又保留其许可。

          所以,要么他们重新授权,要么他们不能从 Redis 处获取代码,但 Redis 可以从 Valkey 处获取代码。

          • 我明白了,我理解错了。我把它理解为试图阻止 Redis 从 Valkey 获取代码。

            不过,如果意图是相反的(允许 Valkey 从 redis 处获取代码),那么 Valkey 也应该选择 AGPL,如果代码共享是许可证变更的动机,那么就没有什么理由选择 GPL 了。

        • 免责声明:我不是律师,这不是法律建议。

          从理论上讲,人们无法在其他许可证(特别是 RSALv2 和 SSPLv1)下提供一个组合程序,因为这些许可证与 GPL 义务有冲突。

          通过单独的贡献者许可协议,向 Redis 项目的直接贡献可以避免这个问题。这只意味着 Redis 开发人员不能单方面从 Valkey 复制代码。

          我并不是说 Valkey 社区应该这样做。我个人认为,Valkey 最好还是作为一个 BSD-3 许可的项目,由社区来履行其他人做出的承诺,即它将始终如此。

  48. 他们这样做真是自作自受。我在哨兵模块中报告了那么多 Bug 并帮助诊断了它们。真他妈操蛋。

  49. 我正在启动一个新的网络应用项目,我想要一个会话数据的内存存储。我只是默认使用 Redis,就在昨天进行了 `npm install`。

    我的意思是,我还记得许可证切换后的整个 Valkey 传奇。我想,我只是不像这里的某些人那么意识形态化吧?我只是觉得 “我需要一个快速的内存对象存储空间”,所以默认使用 Redis。我把它当作基础设施中的一个设备。

    我还依稀记得,在人工智能热潮期间,antirez 回到 Redis(公司),从事 Redis 的向量扩展工作。我相信,Redis 之所以能成为一项坚如磐石的技术,他功不可没。在他的影响下,我对这款产品更有信心。

    同时,我也在考虑许可证的问题。正如我说过的,我不是开放源码软件的狂热分子,但我确实喜欢开放源码软件许可证的理念,它能提供一定的保护,防止有人完全盗用代码而无处追索。AGPL 可能是一个不错的折中方案,尤其是双重许可证。

    • 昨天为什么有变化?是瓦尔基的发展让你觉得值得一换吗?

  50. 没必要相信他们。使用它,如果许可证发生变化,再叉掉它。问题出在哪里?

  51. 请注意,AGPL 许可证与 BSD 完全不同。BSD 允许任何人进行商业衍生,而现在只有 Redis 可以这样做。

    我还想知道,这个决定是否纯粹是出于Valkey的威胁,而不是出于内心的改变……如果是这样,我们还能期待什么呢?

    • 我个人认为:我们不应该让谷歌的不良政策毒害我们的大脑。制定该政策的人有他们采取这一立场的理由。在制定政策时,这对谷歌来说可能是正确的。

      但这并不意味着对你或对任何情况都是正确的。许多在开源事务方面成熟度较高的组织在处理 AGPLv3 许可软件时会采取更加细致入微的方法。

    • 这么说,一台超级计算机禁止使用 AGPL?令人震惊。看来是按计划运行了。

    • 他们的损失,在某些时候…

      我已经受够了 GAFAM 针对 AGPL 和 GPLv3 的 FUD。

  52. AGPL 给你的权利不是更少吗?(更少?)

    对于任何商业开发而言,AGPL 几乎都是不可行的。

    RSALv2 允许你使用 Redis,除非你是服务提供商。现在,如果不共享源代码,你就不能将它用于任何用途(现在所有东西都可以通过网络访问)。

    因此,以前除了亚马逊,其他人都可以将其用于商业目的,而现在没人可以了。

    • 1) 你仍然可以在 RSAL 下使用它。

      2) 你只需共享你修改的内容。你不必为了提供服务而修改它,但如果你修改了,就必须共享代码。这似乎并不特别苛刻,当然也不会妨碍商业提供。

    • 除非你修改了Redis,否则你想共享什么?你不必共享任何服务器代码或其他东西。没必要这么夸张。)

      • 你必须在一开始就选择共享。如果你使用 AGPL,但后来决定进行修改,你就必须共享。所以大多数人都不想冒这个险。

        但更重要的是,许多大公司都禁止使用 AGPL 软件。这根本就不是一种选择。

  53. 我仍然不明白 Redis 是做什么的,也不明白作为网络开发人员我们为什么需要它……

  54. 值得注意的是,Redis 即将起诉 Dragonfly 故意混淆商标。

  55. 多年来,云计算厂商一直在掠夺开放源代码,但从用户和贡献者在 HN 等论坛上的情绪,以及缺乏 OSI 认可的许可创新来看,解决方案并没有取得有意义的进展。如果有的话,我感觉社区实际上更多地是站在云计算厂商一边,而不是站在作者一边。整个社区似乎并不关心作者的业务是否会受到影响。同时,他们在很大程度上也不反对云计算厂商分叉最新的开源版本。

    与大多数开源许可证相比,AGPL 能更好地防止云剥离,但并不能从根本上解决大型云厂商轻易超越作者业务的问题。只有当软件被修改并通过网络提供时,AGPL 才会强制要求共享源代码。但云供应商可以通过托管未经修改的版本来规避这一问题。他们擅长规模化运营和销售。大多数开放源代码消费者似乎更关心从中获益,而不是作者的挣扎。

    公平的源代码许可(如 SSPL 和 Elastic License)虽然不符合 OSI 标准,但在设计时考虑周全,兼顾了作者的业务和用户需求,不会对绝大多数用户造成影响。它们通常只限制云规模的商业托管,而不限制自托管或本地使用。然而,它们却引发了极大的愤怒。

    这是一个更大问题的一部分:社会对作者缺乏同情。这是不可持续的。开源维护者的职业倦怠由来已久。独立 “开源作者社区正在老化。与此同时,许多大型开源项目都来自大型企业,它们将开源作为亏损的领头羊。

    我的印象是

    1. 整个社区过于拘泥于意识形态的纯粹性,在这个时代,最初的自由和开放源码软件(FOSS)意识形态并不适合。当开放源代码还是一场为采用而战的草根运动时,许可是有意义的,而当它为价值万亿美元的云提供动力时,许可就没有意义了。

    2. 人们过于优先考虑自己的短期利益。

    公司之所以采用开源,是因为我们在过去几十年中建立了良好的发展势头。维护者的倦怠、生态系统的支离破碎以及作者与用户之间信任度的下降正在侵蚀着这种势头。然而,开源消费者和权威机构(如 FSF 和 OSI)实际上忽视了独立作者的健康。这种情况总有一天会崩溃。

    如果我们想让开源不仅仅作为云提供商的免费劳动力而存在,我们就需要一场新的运动–一场捍卫用户自由和作者可持续发展的运动。

  56. 我认为,一个项目必须是 Linux 或 Postgres 大型项目,才能真正作为开源项目运作。为什么这么说呢?因为云服务提供商可以轻松地销售你的产品,却不会做出任何贡献。因此,对于任何规模小于 Postgres 的项目,你都需要创建一个新的许可证,以便运行托管服务。问题是,有了 AGPL 这样的许可证,那些不销售你的产品(只是使用)的公司现在也需要以 AGPL 的形式发布他们的产品。有这么多东西在使用 Redis,似乎数以百万计的公司在未来更新时都会违反许可协议。

    我个人认为,最好的办法就是实话实说,用商业许可证发布东西。让所有市值小于 1T 的公司免费使用你的东西。反正赚钱的公司都会想要托管服务或支持。希望在其环境中托管你的东西的公司属于市值大于 100 万美元的那一类。

    以上有点像稻草人,但我们真正希望的是有价值的项目能够继续存在。

    • 反过来看,Linux 和 PostgreSQL 都不是商业产品,过去不是,将来也不会是。许多人在它们的基础上开发商业产品,这没有问题,这是许可证允许的。即使是 Redis,最初也是一个完全开源的项目。但后来它被卖给了一家公司,而这家公司更关心的是赚钱,而不是照顾开源产品。如果你是一家小公司,想创建一个开源产品,但只能供个人免费使用,那就先说清楚。不要试图假装产品是其他东西。这其实与规模无关,而是与动机有关,而公司的动机永远是把赚钱放在第一位。

  57. 他们意识到自己没有 “护城河”,如果整个行业都想努力取代他们,那么他们就完了

  58. 老实说,我一直在等待这样的事情发生,但这种信任打击对我来说并没有真正消失–你认为公司会从这样的事情中恢复过来吗?

  59. 这令人失望。AGPL 是一种非自由(而且毫无意义)的许可证。

    事实上,FSF 想要一个 EULA,但在不违反 “自由 0 “的情况下又不能有一个 EULA,这并不能使 AGPL 突然在逻辑上合理起来。

    marcan 在这方面写得比我还详细:https://news.ycombinator.com/item?id=30044019。

    停止使用 AGPL。它违反了自由软件的基本原则。

    使用自由软件运行 SaaS 公司的能力是一个特征,而不是一个错误。

    • 你可以使用 AGPL 许可的软件运行 SaaS 公司,没问题。

      你认为 AGPL 有什么不自由之处?

      • 没有区别。

        AGPL 在寻求成为 EULA 的过程中,违反了自由软件的自由 0(”为任何目的按自己的意愿运行程序的自由”)。

        https://www.gnu.org/philosophy/free-sw.en.html

        从字面上看,AGPL 要求软件必须具有特定的功能,否则就不能删除,否则就破坏了许可证。反资本主义的 FSF 狂热者们如此热衷于堵住他们所谓的 “ASP 漏洞”,以至于他们自己也写了一份 EULA。

        • > 以任何目的随意运行程序的自由

          我用 AGPL 软件就可以做到这一点。哪些用途在 AGPL 下是不允许的?

          • 您不得修改 AGPL 程序而不增加一个强制性功能,即向软件的远程网络用户提供当前运行的源代码。您也不得删除该功能。这明显违反了自由 0。

            我建议你阅读 AGPL 的实际文本。这太疯狂了。他们太想要一份 EULA 了。

            • > 如果不添加强制功能,向软件的远程网络用户提供当前运行的源代码,你就不能修改 AGPL 程序。

              不是这样的。您只需在某处提供修改后的源代码。

              你可能需要再读一遍 🙂 看来你对 AGPL 的理解有误。

              编辑:我看到了一个立即取消的投票。如果有人认为我错了,请分享 AGPL 的确切摘录,其中规定实际构建功能时必须提供网络程序本身当前使用的源代码。

              • 有问题的条款是这一条:

                > 如果您修改了程序,您修改后的版本必须在显著位置向所有通过计算机网络与其进行远程交互(如果您的版本支持这种交互)的用户提供接收相应源代码的机会。

                应用程序不必直接提供自己的准确源代码,但必须公布在哪里可以找到它。

                而这里的具体内容并不明确。对于网络应用程序来说,如何做到这一点是显而易见的(尽管有多少 AGPL 应用程序将其作为一个简单的配置选项,而不是要求你做额外的补丁来添加它),但对于其他应用程序来说却并非如此。

                例如,你通过自定义协议与 redis 进行交互,该协议自称是人类可读的。这是否意味着我需要在某处注入提议?如果是更不透明的协议呢?如果你问 5 个律师,会得到多少意见?

                • 一个特殊的端点,例如列出 AGPL 条款和源代码链接的 /about 或 /license,就足够了。这一点都不难,也不是不合理。

  60. 祝他们好运,每个人都在向 Valkey 转移,尤其是有了它的大力支持和更好的表现。

  61. 令人惊叹的浏览量。我必须多次刷新页面才能看到浏览量的增加。如果浏览量增加了好几次,那我一定是没有多次阅读文章。

  62. 对于扎根于开源领域的公司来说,这提出了一个根本性的挑战:当云提供商获得利润并控制基础设施时,你如何继续创新并投资于开源软件项目?

    ‘”我看不出有任何利用的情况发生。正如 DHH 所说,工程师将其工作开源的主要原因是向世界赠送礼物。

    • 开源是给每个人(包括杰弗里-贝索斯)的礼物;自由软件是一种共享经济。区别在于共享是否对等。对于开源软件来说,这是你送给杰弗里的单向礼物。他可以为此付钱给你。至少,你可以通过互惠共享让他付出代价。

      • 我认为你描述的不是开源软件和自由软件之间的区别,而是版权许可和许可许可之间的区别。

        开源软件和自由软件的许可证基本上是一样的(有一些例外)。对我来说,区别在于侧重点不同。自由软件首先关注的是用户自由。

      • 用户自由意味着不给他人剥夺用户自由的自由,而这正是 “门童许可证”(我们可以称其为 “绿帽子许可证 “吗?

        • > 用户自由意味着不给他人剥夺用户自由的自由,尽管

          这句话是一个值得深入探讨的捷径,因为它会给人一种许可不尊重用户权利的印象,也因为它并不完全适用于所有情况。

          用户的自由在许可授权下是充分的。如果我得到的是 MIT 下的软件,我的自由就会得到充分尊重。

          不过,通过版权许可迫使下游开发者尊重其用户的自由确实是提高用户整体自由度的策略之一(就我个人而言,这也是我更喜欢 (A)GPL 的原因–我并不热衷于帮忙)。

          但在某些情况下,当你的代码足够小或能从网络效应中获得巨大利益时,使用更宽松的许可证可能会更好,例如,如果它是一个编解码器,或如果已经有了专有软件可以使用的替代品[1,2]。

          [1] https://www.gnu.org/licenses/license-recommendations.html

          [2] https://www.gnu.org/licenses/why-not-lgpl.html

          • 没错。我说的是通用性。如果你要把自己制作的东西放到互联网上,而且很有可能对别人有用,我建议使用 AGPL,除非你有特别的反对理由。还要注意的是,授予更多权限比剥夺权限更容易。

  63. 当 Valkey 决定闭源时,这一点将非常重要。

    当然,这比之前的状态要好,但如果之前的许可证变更没有发生,情况会更好。

    就像法国人说的那样:骗我一次,你就会感到羞耻……

    • 愚弄我不能再被愚弄

      不过说真的,valkey 变为封闭源代码的可能性很低。它由 Linux 基金会管理。这就好比暗示 Node.js 可能会闭源一样…

      • 显然,他们是在俏皮地评论,而不是认真地暗示 Valkey 可能会走向专有。

        • 这太荒唐了,以至于我都没注意到,尽管大多数时候我都会注意到这类事情。好吧。

    • Valkey 是 Linux 基金会的一个项目。谈论许可证变更纯属无理取闹。

    • 区别在于云提供商如何处理合规问题。遵守 AGPL 要求发布作为服务托管的程序的源代码。遵守 SSPL 要求根据 SSPL 条款发布 “您用来将程序或修改版本作为服务提供的所有程序,包括但不限于管理软件、用户界面、应用程序界面、自动化软件、监控软件、备份软件、存储软件和托管软件 “的源代码。这对于任何云提供商来说都是不可能遵守的(这需要巨大的工程努力来重写用于传输服务的每一个软件),这也是为什么 OSI 没有将其批准为开源许可的原因。

      • 口头上是,行动上不是。我反复强调: COSS 初创公司采用 AGPL 并不是因为他们想优先考虑用户自由,而是作为一种防御手段。

        • 绝对是这样。

          他们的动机与你不同,但这并不妨碍用户自由。任何分享变化和改进的行为都是用户的改进。

        • 我并不关心他们为什么采用,只关心他们是否采用。AGPL 是我可以使用的许可证,而 SSPL 则不行。

    • 为什么?对它的投资已经完成,而且很多地方仍然会更喜欢它的许可证。我认为已经发生了足够多的事情/过去了太多的时间,这并不意味着每个人都会悄悄地转回 Redis。

  64. 祝所有真正的开源项目好运,包括 valkey、OpenTofu 等。这些显然是我的首选!

    • Copyleft 并不意味着假开源,比如我就不认为 Linux 是假开源。尽管有很多理由使用许可而不是 Copyleft,反之亦然,这取决于你的情况。

    • Copyleft 是自由软件,自由是指自由。对于亚马逊、谷歌和甲骨文来说,推许许可(如 MIT)是免费的。如果你的老板给你钱,让你为亚马逊、谷歌和甲骨文免费工作,这也没什么,因为那是他们的钱。如果这是你自己的业余时间,你可能就不那么喜欢了。

  65. AGPL 是癌症。Valkey 已经存在,人们已经更换了它,它已经出现在许多发行版中。我不认为会有人回头,尤其是当 Valkey 得到一些大公司的支持时。

    就我个人使用而言,Rails 8 默认将 Redis 功能移至数据库中,效果很好。

    • RMS 是一位天才,他了解开源软件的潜力,并通过 GPL 和他的宣传(以及他的大量代码)以及自由软件运动,为我们创造了现在的软件世界。AGPL 反映了这样一个事实,即他比所有人都更早地意识到软件作为一种服务正在发生着什么。

      我喜欢 BSD 许可证,但现在说 AGPL 是毒瘤的人是在帮少数几家大公司的大忙,这些公司想滥用催生现代开放软件的最初梦想。时代在变,最好的许可证也要与时俱进。

      • 尽管 RMS 批准了由 Affero 发起的对 GPL 的分叉,从而创建了 AGPLv1,但他并不认为 Affero 条款作为一般规则是个好主意。 因此,在 GPLv3 的起草过程中,他并不支持在 GPLv3 中增加网络版权保护义务。

        RMS 长期以来一直对 “作为软件替代品的服务”[1] 表示担忧,我认为他之所以犹豫是否批准 AGPL,是因为这与他关于 “作为软件替代品的服务 “的危险性的理念相冲突。

        亨利-普尔(Henry Poole)提出了这一问题,他应该受到表彰;布拉德利-库恩(Bradley M. Kuhn)和埃本-莫格伦(Eben Moglen)则应该受到表彰,因为他们推动了许可证的发展,解决了这一问题。

        自由软件基金会花了很长时间才在 AGPLv3 的发布后接受了其管理下的 GPL 的 Affero 版本。

        因此,也许他确实比很多人更早地意识到,服务业对他的社会运动构成了一些挑战。但我认为,他更倾向于自力更生和最大限度的 “自由”,在自己拥有的硬件上运行计算机程序,以此作为补救措施,而不是将版权义务延伸到网络上。

        [1] https://www.gnu.org/philosophy/who-does-that-server-really-s

        • 没有 AGPL,你仍然可以得到 SaaSS,但它是 GPL,所以你得不到任何源代码。GPL 本应包含 Affero 条款,以满足 Stallman 的要求。否则,公司显然会通过使用 SaaSS 来绕过许可证。

    • AGPL 是癌症[0],这与 GPL 是癌症的原理完全相同,因为它被有意设计成*是*癌症(或至少是先天性癌症)。

      如果你修改了 GPL 代码,你就应该将这些修改开源,而 AGPL 则是将 GPL 适应于网络世界,如果你修改了 AGPL 代码以服务于某些东西,你也应该将这些修改开源,否则你就违反了 GPL 的最初精神,而 GPL 的设计时代并不像今天这样永远由互联网(和 SaaS)驱动。

      如果你想要一个真正自由的许可证,BSD 或 MIT 都能满足你的要求,但你不应该指望公司会给予回报。

      Linux 与各种 BSD 的对比就是一个很好的例子。BSD 在家用电器领域比你想象的要受欢迎得多,但随着 Linux(尽管有 GPL)在公司的回馈下取得了巨大进步,其受欢迎程度开始减弱,在某些情况下,”免费许可 “的 BSD 已不再被视为足够好。人们并不倾向于回馈 BSD。

      [0]: https://blog.jamesbayley.com/2014/01/17/gpl-living-with-canc

    • > AGPL 是癌症。

      很好,你可以认为它是癌症并远离它。你不喜欢它,就不要使用它。这就像亚马逊河流域那些颜色鲜艳的毒蛙。这总比一些新编的与众不同的许可证要好,而且你不得不怀疑它在实践中会如何成立。

      • 我同意这比他们之前编造的许可证要好。但它并不能挽回所有离开的人。这艘船已经扬帆起航。他们应该采用 GPL。

    • > Rails 8 默认将 Redis 功能移至数据库中,这样做效果很好。

      数据库总能做到 Redis 所做的事情。Redis 带来的不是功能,而是速度。如果数据库缓存、pub/sub 和流对你的用例来说已经足够好了,那就没有理由再为建立 Redis 而支付额外的实例费用。

    • AGPL 不是癌症。它是为了解决一个特殊问题而存在的许可证:自由软件在网络服务世界中的扩散。

      如果你不喜欢它,就不要使用 AGPLv3 软件。我们这些喜欢它的人会继续编写 AGPLv3 软件。

  66. 因误导性标题而被标记。SSPL 是开源的。只是不是你想要的开源。

    它符合所有标准,与 AGPL 的唯一区别在于你必须在何时发布多少源代码–这也是 GPL 与 AGPL 的区别。它有问题,但封闭源代码不是问题之一。

    当然,OSI 永远不会对其进行认证,因为这有悖于 OSI 成员的商业利益。OSI 是一个由公司组成的财团,这些公司从许可项目中获得免费劳动力,在较小程度上也从 GPL 项目中获得免费劳动力。OSI 在回复中链接的文章没有对 SSPL 的开放源代码性提出任何反对意见,基本上只是说他们不喜欢 SSPL,而且有些公司无法遵守 SSPL,每种自由软件许可证都是如此。

    FSF、Debian 等组织还没有做出这样或那样的决定,因为这并不是一个非常普遍的许可证,他们可以直接使用 Valkey,而不用浪费精力。

    • 这并不是一个被广泛接受的说法。我不认为 SSPL 是开放源代码,OSI[0] 或 FSF[1] 或 Debian[2] 也不这么认为。

      [0]https://opensource.org/blog/the-sspl-is-not-an-open-source-l…

      [1]https://www.gnu.org/licenses/license-list.en.html

      [2]https://www.debian.org/legal/licenses/

      • 我们不能再把 OSI 或 FSF 在任何事情上的立场视为特别有价值。

        OSI 完全由企业赞助。在 SSPL 事件发生时,亚马逊每年向 OSI 支付全职薪水,OSI 没有能力在不削弱自身运营的情况下采取支持劳工的道德立场。他们仍然没有对个人用户做出有意义的回答: 最近,开放社会协会拒绝透露谁在董事会选举中获胜,以及谁是他们心目中的候选人。

        而且,只要 FSF 缺乏将 RMS 永久赶出董事会的道德勇气,那么即使考虑 FSF 的立场也是不道德的。

        如果 OSI 不是由企业利益集团拥有,并且理所当然地宣布 SSPL 为版权许可……没人会说它不是。问题在于,我们让一个极有问题的组织以一种不符合我们利益的方式来 “定义 “某些东西。

        • 许多人在 SSPL 发布时,在 OSI 对其采取任何立场之前,就通过阅读 SSPL 得出了相同的结论。

          • 谁,不是在使用动机推理或重复他们从 OSI 或亚马逊那里听到的东西?

        • OSI 和 FSF 禁止 sspl 这样的东西是有道理的。开放源码应该表达自由,而对某些用户施加限制,无论他们有多邪恶,都无法表达自由。

          • 你似乎反对软件自由。SSPL 是一种病毒式的版权开放许可,它只是要求用户开放源代码。SSPL 的限制性与 GPL 相同,它要求给予用户软件自由。

            • SSPL 基本上对某些用户群抱有敌意,可以说是一种种族主义。这有悖于 fsf 的精神。

              • 针对亿万富翁的种族主义?得了吧。

                还有,你错了。FSF 的基本立场是,非自由软件是不道德的,因此任何强制其他软件发布自由许可证的许可证本质上都是道德的。像 SSPL 这样非常版权许可协议应该是 FSF 的最高目标。

                • 如前所述,不是。许可证不应区别对待,甚至不应歧视亿万富翁。要么从 X 开始并保持不变,要么就比不上亿万富翁。诱饵和调包比混蛋更糟糕

          • 这么说 Copyleft 许可证被淘汰了?

            OSI 写了一些废话,暗示 Copyleft 许可证不能开源,而 FSF 还没有采取任何立场。

          • https://opensource.org/blog/the-sspl-is-not-an-open-source-l 的全部主张……归结为 “在任何领域使用程序的权利”,而 SSPL 并不禁止在任何领域使用软件。

            然后,OSI 又说了一大堆废话,表明他们是如何被收买的,比如 “理解他们的工作是为了更大的利益”,很显然……被一家不开源平台、对待员工差到只能在瓶子里撒尿的公司使用。当然,他们马上又声称 “现在……贡献被嵌入到了专有产品中”,因为 OSI 当然相信他们拥有开源的术语和定义,他们不同意的一切本质上都是 “专有 “的。

            当然,他们还认为 “重新授权并不能证明开放源代码授权模式的失败”,尽管很明显,企业无法在生产开放源代码的过程中生存是促进公共软件公地目标的一大缺陷。(更进一步说,如果自由软件基金会认为自由软件是一种道德要求,那么不解决这个问题就是彻头彻尾的不道德)。

            • 我认为你的整个评论可以归结为,你认为基于使用情况的某些有限的歧视是可以接受的,市场动态也证明了这一点。这种观点很好,但它根本不是 “开源 “的公认定义。你可能没有意识到这一点,或者你可能认为如果不是这样的话,我们都会过得更好,但这些都无法改变这样一个现实:事实上,”开源 “一词有一个广为人知的定义。

              人们之所以对这个定义如此执着,是因为这个词背后的历史赋予了它很大的分量。允许意识形态上的任何偏离,都会让那些与历史不符的东西搭上之前项目的顺风车。

              值得注意的是,如果 SSPL 真的如此有益,没有或几乎没有缺点,那么就没有必要一开始就卷入关于意识形态的争论。只要明确指出它不是 “开放源代码”,说清楚两者的区别,就不会有人抱怨了。你甚至可以创造一个新名词,为许可证的变体留出空间。如果这是一种有益的安排,那么人们自然会使用这种许可证。

              • 不过,让我感到奇怪的是,GPL 被认为是开放源代码,而 SSPL 却不是。在 GPL 发布之初,它要求所有链接模块都必须获得 GPL 许可,这与今天 SSPL 在网络层面上执行的要求并无太大区别。我认为 SSPL 类似于 GPL,而 AGPL 类似于 LGPL,本质上都放宽了对链接(LGPL 相对于 GPL)或网络交互(AGPL 相对于 SSPL)的要求。

                • > 当 GPL 首次发布时,它要求所有链接的模块都必须获得 GPL 许可,这与今天 SSPL 在网络层面上执行的要求并无太大区别。

                  所有链接模块 “这一点并没有出现在 GPL 首次发布时的文本中,也没有出现在任何后续版本中(它出现在某些版本的 GPL 常见问题中,但从版权法的角度来看,可以说与相应的许可证文本相矛盾)。

                  但这至少与对版权下单个作品边界的善意解释(即使实际上是错误的)有一定的联系,而不是试图将许可条款强加给只是碰巧一起使用的不相关作品。此外,该解释仅限于一份旨在根据法律解释许可的文件,即使该解释可能是错误的,也不属于许可本身的一部分。

                • 当然,我认为你的比喻是合理的。就版权法而言,功能单元的边界可以在许多不同的地方合理划定。在选择许可证时,在这方面有多种选择并没有错。

                  我同意你的比喻。SSPL 确实有点像在弥补 AGPL 的漏洞(AGPL 本身也可以说是在弥补 GPL 的漏洞)。与此同时,我并不觉得在意识形态中划清界限有什么问题。

                  一种解释是,这是一种选择,即意识形态租户可以包括通过网络与你的程序直接交互的用户,但不能扩展到后台网络交互。

                  另一种解释是,问题不在于后台网络交互,而在于对程序目的的解释。GPL 和 AGPL 可以说是基于技术上的区别进行监管–功能单元是否使用特定组件构建,功能单元是否驱动用户交互。另一方面,SSPL(特别是被撤销前提出的最终版本[0])包含 “此类软件即服务的主要目的或功能 “和 “此类软件即服务的软件组件的价值”。

                  但另一种解释是,现任宗教领袖现在只是不想捅这个马蜂窝。从实用角度讲,SSPL 似乎对一种非常特殊的商业模式产生了不成比例的影响,而现有的许可证则更接近于中立(至少在这方面)。

                  如果边界确实划错了地方,那么只要能清楚地证明错误,就会得到纠正。如果 SSPL 或实质上类似的东西被广泛采用,并最终在实践中促进了意识形态目标的实现,那么人们可能会被说服,更新他们的观点。即使不会,只要用户的需求得到了满足,我也不认为 OSI、FSF 或其他什么人在他们的清单上列出什么有什么关系。错误的否定(即遗漏)在这里似乎并不特别重要,而错误的肯定(即错误的包含)却很重要。

                  [0] https://lists.opensource.org/pipermail/license-review_lists….

            • 谢谢你和 immibis 提出这个问题。我一直觉得这里面有猫腻。我还不完全明白,需要做更多的研究。我打赌这些评论之所以不受欢迎,是因为 SSPL 会伤害 GCP/AWS,而 GCP/AWS 又会伤害 YC。

              我并不是说 HN 的版主在密谋掩盖这些评论。但是,在按向上投票顺序排列的评论树中,鱼会从头开始腐烂。

              • 多年来,我一直与当当存在分歧,但我要明确一点:我认为 HN 版主的工作非常出色。我不同意他们的某些选择,但我不认为他们在管理时会考虑到 YC 的底线。

                尽管 OSI 和 FSF 存在着很大的问题,但它们仍然是非常受欢迎的组织,我完全有理由相信,当我提出这个问题时,会惹恼一些人。)

    • 不同的是,SSPL 是一份恶意编写的许可证,其明确意图是让人们无法遵守有关运行托管服务的部分。

      https://www.mongodb.com/legal/licensing/server-side-public-l

      参见第 13 节 “将程序作为服务提供”。要遵守该条款,你需要根据 SSPL 发布所有用于 “将程序或修改后的版本作为服务提供 “的软件。

      对于 Redis 这样的软件,这包括:Redis 本身、用于托管 Redis 的操作系统、用于托管 Redis 的硬件的驱动程序和固件等。还有你的整个部署堆栈,包括你用来点击 “部署 “按钮的鼠标驱动程序。

      这是一个荒谬的条件,它实际上使第 13 节规定 “你不能提供托管版本”,而 OSI 和 FSF 拒绝接受这种 “它就像 agpl,但更多 “的无稽之谈是正确的。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注


京ICP备12002735号