跳转到主要内容

热门内容

今日:


总体:


最近浏览:


Chinese, Simplified

未来的Redis版本将继续在双RSALv2和SSPLv1许可证下提供免费和许可的源代码使用;这些版本将结合以前仅在Redis Stack中可用的高级数据类型和处理引擎。


从今天开始,所有未来版本的Redis都将使用源可用许可证发布。从Redis 7.4开始,Redis将在Redis源可用许可证(RSALv2)服务器端公共许可证(SSPLv1)下获得双重许可。因此,Redis将不再根据Berkeley Software Distribution(BSD)的三个条款进行分发。


从第一天开始,Redis就为支持现代互联网的应用程序和数据基础架构提供了性能和简单性的基础。现在,15年过去了,我们很自豪地通过支持世界每天依赖的实时应用程序,为全球数百万开发人员提供服务。我们已经在Redis Stack发行版下为我们的高级Redis模块实施了双重许可,这受到了社区的好评。事实上,超过50%的redis.io下载(来自redis 6及更高版本)来自redis Stack。我们现在认为,将此许可扩展到Redis本身将使我们能够继续为我们的用户发展最完整的数据模型集、处理引擎和开发人员功能。


新的可用源代码许可证允许我们持续地提供对源代码的许可使用。我们正在将Redis引入其下一个开发阶段,作为一个具有统一的客户端、工具和核心Redis产品的实时数据平台。Redis源代码将继续通过Redis Community Edition免费提供给开发人员、客户和合作伙伴。未来的Redis源可用版本将把核心Redis与Redis Stack统一起来,包括搜索、JSON、向量、概率和时间序列数据模型,作为一个免费、易于使用的软件包下载。这将允许任何人在各种上下文中轻松使用Redis,包括作为高性能密钥/值和文档存储、强大的查询引擎和支持生成AI应用程序的低延迟向量数据库。


Redis的成功带来了一系列独特的挑战。Redis一直在赞助大量的开发,同时还赞助了一个充满活力的开发人员社区,他们渴望做出贡献。然而,Redis的大多数商业销售都是通过最大的云服务提供商进行的,这些提供商将Redis的投资及其开源社区商品化。尽管我们努力支持社区主导的治理模型,并且希望维护BSD许可证,但同时交付多个软件分发版本——跨开源、源代码可用和针对不同内部部署和云平台优化的商业软件——与我们成功推动Redis进入未来的能力不一致。


根据新的许可证,托管Redis产品的云服务提供商将不再被允许免费使用Redis的源代码。例如,云服务提供商只有在与Redis代码的维护者Redis同意许可条款后才能交付Redis 7.4。这些协议将巩固对现有集成解决方案的支持,并提供对即将推出的Redis创新的完全访问。


“我们期待着继续合作,以最新的数据存储和管理创新来支持开发人员,”微软开发部门总裁Julia Liuson表示。“我们的合作继续支持Azure Cache for Redis等集成解决方案,并将为Microsoft客户提供对Redis产品中扩展功能的独占访问。”


在实践中,Redis开发人员社区不会发生任何变化,他们将继续在双重许可下享受许可。同时,Redis负责的所有Redis客户端库将保持开源许可。Redis将继续支持其庞大的合作伙伴生态系统——包括托管服务提供商和系统集成商——独家访问Redis通过其合作伙伴计划开发和提供的所有未来版本、更新和功能。现有Redis Enterprise客户没有变化。


我们的新许可方法在使Redis源代码广泛可用、以最小的限制支持开发人员社区和保护我们继续投资于功能丰富的免费软件和企业产品的能力之间取得了最佳平衡。


一如既往,我们的团队、社区、客户和合作伙伴将继续引领Redis作为领先的实时数据平台的创建、推进和部署。


有关更多信息,请阅读下面关于许可证更改的常见问题解答。

1.Redis今天发布了什么?


Redis宣布从BSD 3条款许可证过渡到Redis核心软件的双许可证方法,使用Redis源可用许可证版本2(RSALv2)或服务器端公共许可证版本1(SSPLv1),从Redis v7.4开始,并用于Redis的所有未来版本。
RSALv2是一个许可的非版权许可证,允许“使用、复制、分发、提供和准备软件的衍生作品”的权利,并且只有两个主要限制。在RSALv2下,您不能:

  • 将软件商业化或将其作为托管服务提供给他人;和
  • -删除或隐藏任何许可、版权或其他通知。


我们的双许可证方法并不新鲜;2022年11月15日,我们在双许可下发布了Redis模块(包括RedisJSON、Redis Stack等)。现在,我们正在为所有免费提供的软件转向双重许可。我们认为,RSALv2的许可方法和我们用来定义其局限性的标准措辞解决了我们社区提出的许多挑战。


这种双许可证方法允许用户在许可但不太知名的许可证RSALv2或更常用但保留版权的许可证(如SSPLv1)之间进行选择。


需要明确的是,RSALv2和SSPL都不是OSI批准的许可证,并且每个许可证都有其限制。简单地说,RSALv2对软件的商业化设置了一些限制。SSPLv1要求,如果您将产品作为服务提供,则必须在SSPL下公开发布管理层的任何修改和源代码。


云时代源代码可用许可证的必要性已经讨论了许多次,我们很自豪地通过采用开发人员已经知道和使用的标准来为这项工作做出贡献。我们认为,双许可证为Redis开发人员提供了如何利用我们最新技术的清晰性和灵活性。


与Redis相关的其他许可授权技术,如各种特定于语言的客户端库、Terraform和Pulumi提供商等,不受此更改的影响。


此外,从Redis 8开始,我们计划在默认情况下在我们的产品中包括新的数据类型和处理引擎,这些引擎以前是作为Redis Stack的一部分在RSALv2或SSPLv1下许可的。


因此,由于这一变化,我们还宣布一旦Redis 8可用,Redis Stack的生命周期将结束。不再需要提供这些功能的单独构建,因为它们将是Redis本身的一部分,从Redis 8开始。

2.为什么Redis Inc.会做出这种改变?


我们希望所有开发人员都能获得我们提供的最佳技术。但是,我们必须做所有这些模块体操来推进Redis本身的核心内容。我们没有忠实于最初的宣言——我们反对复杂性。因此,这一更改以一种方式调整了许可,我们可以以简单和一致的方式简化其他数据类型的打包和发布。


我们坚信公开共享源代码的价值,并使从业者能够解决他们的问题、构建社区和创造透明度。Redis免费为社区提供功能丰富的产品,与我们合作的商业客户使开发成为可能。通过转向此许可证,Redis可以更好地管理我们源代码的商业使用,并继续投资于我们蓬勃发展的从业者社区,其中一些人也是贡献者,以不会阻碍他们工作的方式。

3.这一变化对Redis开源产品的最终用户有何影响?


对于使用Redis开源版本Redis和新版本的最终用户,无论是内部使用还是个人使用,都不会有任何变化。

4.这一变化对利用Redis的第三方库有何影响?


对于使用Redis构建客户端库或其他集成的集成合作伙伴,没有变化。

5.这一变化对Redis商业客户的影响是什么?


Redis的商业客户没有变化。这些客户根据单独协商的许可条款获得我们的技术。

6.谁受此变化的影响?


向Redis提供竞争产品的组织将不再被允许在任何一个双许可证下免费使用Redis源代码的新版本。商业许可条款可用,并且可以启用超出RSALv2或SSPLv1许可限制的用例。如果您正在构建一个利用Redis的解决方案,但不专门与Redis本身竞争,则不会产生影响。如果您有具体的担忧或问题希望讨论,请发送电子邮件至redis_licensing@redis.com.

7.Redis RSALv2或SSPLv1许可证下定义的“竞争产品”是什么?


“竞争产品”是一种销售给第三方的产品,包括通过付费支持安排销售的产品,它源自Redis的代码库,并与Redis商业产品的功能显著重叠。例如,该定义将包括托管或嵌入Redis,作为与我们的商业版本Redis(Redis Enterprise Software或Redis Cloud)竞争销售的解决方案的一部分。还可以使用自定义许可条款来提供更清晰的内容,并支持超出RSALv2或SSPLv1限制的用例。如果您需要关于特定用例的进一步澄清,您可以通过电子邮件redis_licensing@redis.com.

8.RSALv2或SSPLv1在其下一版本中将涵盖哪些产品?


这一变化有效地将我们所有源可用模块的许可与Redis核心相结合。

9.什么是SSPLv1许可证?


SSPL基于GNU事务通用公共许可证(AGPL),修改了第13节,要求将SSPL许可软件作为“服务”的一部分提供给第三方(修改或未修改)的人必须发布整个服务的源代码,包括但不限于SSPL下的所有“管理软件、用户界面、应用程序界面、自动化软件、监控软件、备份软件、存储软件和托管软件,所有这些都使得用户可以使用您提供的服务源代码运行服务的实例”。MongoDB是此许可证的发行者。您可以在此处找到他们关于许可证的原始常见问题解答。

10.如果我修改根据SSPL许可的软件的源代码,我是否可以在另一个许可证下重新分发我的修改版本?


不可以。您修改的版本由原始软件和您的修改组成,它们一起构成原始软件的衍生作品。SSPL许可证不会授予您在其他许可证下重新分发的权利。
然而,如果您选择使用RSALv2许可证(在双许可证下),则可以修改和重新分发代码,前提是您不将软件或修改版本的功能作为服务提供给第三方,或者以使软件的功能可供第三方使用的方式分发软件或修改的版本

11.我可以继续使用根据原始3条款BSD许可证提供的产品版本吗?


是的。许可证更改是不可追溯的。这意味着在更改之前的所有源代码和版本都将保留在3条款BSD许可证下。您可以在原始许可证下无限期地继续使用这些版本,只要您遵守其条款和条件。Redis计划继续提供安全更新,并解决这些版本中的其他关键缺陷,直到Redis Community Edition根据我们当前的安全策略可用为止。

12.在3条款BSD许可下,Redis是否会将安全补丁反向移植到以前的版本?


在Redis Community Edition 9.0发布之前,Redis将继续根据3条款许可证将关键安全补丁(如果可用)反向移植到现有版本,以符合当前的安全策略。该日期之后的任何修补程序都将在新的双许可证下提供。

14.Redis现在是如何指以前称为开源(OSS)的产品的免费版本的?


我们将产品的版本称为开源(OSS)、企业或云。Redis v7.2及以前的版本将继续称为Redis OSS。从Redis v7.4开始,我们将开放、免费的版本称为Redis Community Edition。RSALv2和SSPL v1许可证都提供了对Redis Community Edition底层源代码的开放和免费访问。然而,它不符合OSI定义的开源定义,这就是为什么我们将产品称为“社区版”,而不是像我们以前那样的“开源”版本。在我们的网站上有许多关于开源的参考,我们正在积极努力,在未来几周内澄清这些语言变化。

16.我正在构建(或已经构建)一个嵌入Redis的产品,我担心您可能会认为它具有竞争力。如何明确我的产品是否会违反RSALv2或SSPLv1许可证?


请与我们联系。我们很高兴与您交谈。开始对话的最佳方式是redis_licensing@redis.com.我们可以及时反馈您的问题,并讨论建设性的解决方案,包括潜在的豁免和/或合作安排

17.我是一个开源项目的作者,该项目以非竞争的方式使用Redis。如果其他人使用我的项目来生产具有竞争力的产品或托管服务(例如,开始在他们的SaaS解决方案中使用我的工程),我是否有被认为具有竞争力并违反双重许可的风险?我是否需要跟踪我的项目的所有用户并报告涉嫌侵权的使用?


只有以竞争方式嵌入或托管Redis产品的人才违反许可证。违反行为不包括不这样做的项目所有者,也不要求他人代表其这样做。项目所有者没有义务监督或报告其他人如何使用他们的项目。

18.我能否继续围绕Redis产品提供专业服务?


是的。我们有一个由系统集成商合作伙伴组成的大型生态系统,提供咨询和专业服务,帮助用户部署、管理和操作我们的产品以供内部使用。我们许可证的更改并不旨在阻止合作伙伴提供这些服务,我们将继续鼓励和支持这些类型的系统集成商合作伙伴。相反,RSALv2只是防止以与我们竞争的方式嵌入或托管我们的社区产品。

19.在我的项目中,我可以将在RSALv2或SSPLv1下提供的代码与在不同许可证(即Apache、MPL等)下提供的编码混合吗?


是的,前提是每个组件都保留自己的许可证,并且不要将RSALv2或SSPLv1代码与强版权许可代码(如GPL)混合。对于某些许可许可证(如Apache),您也可以在RSALv2或SSPLv1下提供整个程序,但包括Apache部分的通知(这是可能的,因为Apache与其他一些开源许可证不同,授予了再许可的权利)。请记住,如果在不同的许可证下混合代码,则可能无法以符合所有许可证的方式重新分发它。

20.我可以将Redis作为组织内部的服务托管吗?


是的。RSALv2或SSPLv1的条款允许所有非生产和生产使用,但向嵌入或托管我们的软件的第三方提供竞争产品除外。允许托管供组织内部使用的产品。组织包括其子公司和子公司。这意味着一个部门可以托管Redis供另一个内部部门使用。

21.如果Redis将来发布新的产品或功能,使我的项目具有竞争力,该怎么办?


如果Redis将来创建的产品与您已经在生产中提供的产品竞争,则您继续使用托管或嵌入式Redis产品不会被视为违反RSALv2或SSPLv1,只要您使用的版本是在Redis发布其新产品之前发布的。

22.在我的产品名称中使用“Redis”是否有更新的要求?


是的,在产品名称中使用“Redis”有更新的要求。您不能再在产品名称中使用“Redis”或“for Redis”,但您可以在产品描述中使用“Redis”名称,或者指定您的产品兼容Redis或基于传统Redis。有关Redis名称和徽标使用的其他信息,请参阅我们的商标政策。

24.Redis是否接受新许可下的社区贡献?


Redis仍然是开源哲学的支持者,并维护了大量开源项目。对于那些希望贡献的人,我们仍然愿意接受未来的贡献——就像我们在过去五年中对可用源模块所做的那样。展望未来,贡献者接受贡献者许可协议(CLA)是必要的,以便我们考虑贡献

本文地址
最后修改
星期六, 三月 23, 2024 - 21:45
Article