Redis áp dụng giấy phép kép source-available
(redis.com)- Từ Redis 7.4, Redis ngừng phân phối theo BSD 3-Clause và từ nay cung cấp Redis theo RSALv2 hoặc SSPLv1, làm thay đổi đáng kể ranh giới cấp phép
- Mã nguồn tiếp tục được cung cấp miễn phí dưới dạng Redis Community Edition, nhưng các giấy phép mới không phải là mã nguồn mở theo định nghĩa của OSI
- Redis dự định hợp nhất Core và Stack, gom tìm kiếm, JSON, vector, cấu trúc dữ liệu xác suất và mô hình dữ liệu chuỗi thời gian vào một gói miễn phí duy nhất
- Việc sử dụng nội bộ/cá nhân, thư viện client, đối tác tích hợp và khách hàng Redis Enterprise hiện tại không bị ảnh hưởng, nhưng dịch vụ được quản lý mang tính cạnh tranh không thể dùng miễn phí mã nguồn Redis mới
- Từ Redis 8, các tính năng Redis Stack dự kiến sẽ được đưa vào chính Redis, sau đó bản build Redis Stack riêng sẽ đi đến hết vòng đời
Phạm vi thay đổi giấy phép Redis
- Redis sẽ phân phối tất cả các phiên bản Redis sắp tới theo giấy phép source-available
- Từ Redis 7.4, phần mềm Redis Core có thể được sử dụng theo một trong hai giấy phép: Redis Source Available License v2 hoặc Server Side Public License v1
- Không còn được phân phối theo giấy phép BSD 3-Clause
- Mã nguồn Redis tiếp tục được cung cấp miễn phí dưới dạng Redis Community Edition thông qua kho GitHub của Redis
- Cả RSALv2 và SSPLv1 đều không phải là giấy phép được OSI phê duyệt, và mỗi giấy phép đều có các hạn chế sử dụng riêng
Hợp nhất Redis Stack và thay đổi cấu hình sản phẩm
- Các bản phát hành source-available trong tương lai sẽ hợp nhất Redis Core và Redis Stack
- Phạm vi hợp nhất gồm tìm kiếm, JSON, vector, cấu trúc dữ liệu xác suất và mô hình dữ liệu chuỗi thời gian
- Sẽ được cung cấp dưới dạng một gói tải xuống miễn phí duy nhất, và Redis có thể được dùng cho các mục đích sau
- Kho khóa/giá trị hiệu năng cao
- Kho tài liệu
- Công cụ truy vấn
- Cơ sở dữ liệu vector độ trễ thấp cho ứng dụng AI tạo sinh
- Từ Redis 8, các kiểu dữ liệu mới và engine xử lý từng được cung cấp trong Redis Stack hiện tại theo RSALv2 hoặc SSPLv1 dự kiến sẽ trở thành thành phần mặc định
- Sau khi Redis 8 được cung cấp, bản build Redis Stack riêng sẽ không còn cần thiết, dẫn đến Redis Stack hết vòng đời
Bối cảnh thay đổi và lập trường của Redis
- Redis cho biết họ đã áp dụng cấp phép kép cho các module Redis nâng cao trong bản phân phối Redis Stack, và hơn 50% lượt tải xuống từ redis.io kể từ Redis 6 đến từ Redis Stack
- Redis cho rằng cấu trúc duy trì đồng thời nhiều bản phân phối mâu thuẫn với định hướng phát triển tương lai của họ
- Bản phân phối mã nguồn mở
- Bản phân phối source-available
- Phần mềm thương mại được tối ưu cho nền tảng on-premises và cloud
- Redis cho rằng các nhà cung cấp dịch vụ cloud lớn đang thương mại hóa khoản đầu tư của Redis và cộng đồng mã nguồn mở
- Thay đổi này là biện pháp nhằm quản lý việc sử dụng thương mại để tiếp tục đầu tư vào phần mềm miễn phí giàu tính năng và các sản phẩm enterprise
- Với thay đổi này, Redis không còn là mã nguồn mở theo định nghĩa của OSI
Ảnh hưởng tới người dùng và đối tác
- Người dùng cuối sử dụng phiên bản mã nguồn mở hiện có của Redis hoặc bản phát hành cấp phép kép mới cho mục đích nội bộ/cá nhân sẽ không bị ảnh hưởng
- Các đối tác tạo thư viện client hoặc các tích hợp khác làm việc với Redis cũng không có thay đổi
- Tất cả thư viện client Redis do Redis chịu trách nhiệm sẽ duy trì giấy phép mã nguồn mở
- Khách hàng Redis Enterprise hiện tại không bị ảnh hưởng vì họ nhận công nghệ theo các điều khoản giấy phép đã đàm phán riêng
- Các đối tác tích hợp và dịch vụ được quản lý sử dụng Redis Community Edition hoặc Enterprise theo hình thức không cạnh tranh có thể tiếp tục xây dựng, vận hành và cung cấp giải pháp thông qua quan hệ đối tác với Redis
- Partner Program trong tương lai sẽ cung cấp quyền truy cập độc quyền vào công nghệ, tính năng và bản phát hành của Redis
Hạn chế với dịch vụ cloud và sản phẩm cạnh tranh
- Theo giấy phép mới, nhà cung cấp dịch vụ cloud cung cấp dịch vụ hosting Redis không thể sử dụng miễn phí mã nguồn Redis
- Ví dụ, nhà cung cấp dịch vụ cloud chỉ có thể cung cấp Redis 7.4 sau khi thống nhất điều khoản giấy phép với Redis, bên bảo trì mã Redis
- “Dịch vụ cung cấp mang tính cạnh tranh” của Redis chỉ sản phẩm phái sinh từ codebase Redis, có chức năng chồng lấn đáng kể với sản phẩm thương mại của Redis và được bán cho bên thứ ba
- Bao gồm cả việc bán thông qua hợp đồng hỗ trợ trả phí
- Ví dụ là trường hợp host hoặc nhúng Redis trong giải pháp được bán theo cách cạnh tranh với Redis Enterprise Software hoặc Redis Cloud
- Các giải pháp dù sử dụng Redis nhưng không cạnh tranh cụ thể với bản thân Redis sẽ không bị ảnh hưởng
- Các câu hỏi về trường hợp sử dụng cụ thể được hướng dẫn gửi tới redis_licensing@redis.com
Điều kiện của RSALv2 và SSPLv1
- RSALv2 là giấy phép cho phép mang tính không copyleft, cho phép quyền sử dụng, sao chép, phân phối, cung cấp và chuẩn bị tác phẩm phái sinh của phần mềm
- Các hạn chế chính của RSALv2 gồm hai điểm
- Không được thương mại hóa phần mềm hoặc cung cấp phần mềm cho người khác dưới dạng dịch vụ được quản lý
- Không được gỡ bỏ hoặc che khuất giấy phép, bản quyền và các thông báo khác
- SSPLv1 dựa trên AGPL, và nếu cung cấp dưới dạng dịch vụ thì phải công khai mã nguồn của toàn bộ dịch vụ theo SSPL
- Bao gồm phần mềm quản lý, giao diện người dùng, API, phần mềm tự động hóa, giám sát, sao lưu, lưu trữ và phần mềm hosting
- MongoDB là bên phát hành giấy phép này
- Phiên bản đã sửa đổi của phần mềm được cấp phép theo SSPL không thể được phân phối lại theo giấy phép khác
- Trong cấp phép kép, nếu chọn RSALv2, có thể sửa đổi và phân phối lại trong phạm vi tuân thủ các hạn chế của RSALv2, chẳng hạn như không cung cấp chức năng dưới dạng dịch vụ cho bên thứ ba
Phiên bản BSD hiện có và bản vá bảo mật
- Thay đổi giấy phép không có hiệu lực hồi tố
- Tất cả mã nguồn và bản phát hành trước thay đổi vẫn nằm dưới giấy phép BSD 3-Clause
- Người dùng có thể tiếp tục sử dụng vô thời hạn các phiên bản BSD hiện có miễn là tuân thủ các điều khoản của giấy phép đó
- Redis dự định tiếp tục cung cấp bản cập nhật bảo mật và bản sửa lỗi quan trọng cho các bản phát hành đó theo chính sách bảo mật hiện hành cho đến khi Redis Community Edition được cung cấp
- Các bản backport vá bảo mật quan trọng cho phiên bản BSD 3-Clause hiện có sẽ được cung cấp cho đến trước khi Redis Community Edition 9.0 ra mắt, sau đó các bản vá sẽ được cung cấp theo giấy phép kép mới
Tên gọi, đóng góp và điều kiện trộn mã
- Redis 7.2 và các bản phát hành trước đó tiếp tục được gọi là Redis OSS
- Từ Redis 7.4, phiên bản được cung cấp công khai và miễn phí được gọi là Redis Community Edition
- Không còn được dùng “Redis” hoặc “for Redis” trong tên sản phẩm, nhưng có thể nêu trong mô tả sản phẩm rằng sản phẩm tương thích với Redis hoặc dựa trên legacy-Redis
- Cộng đồng vẫn có thể đóng góp, nhưng cần đồng ý với Contributor License Agreement để Redis xem xét đóng góp
- Mã RSALv2 hoặc SSPLv1 có thể được sử dụng cùng mã theo giấy phép khác với điều kiện mỗi thành phần giữ giấy phép riêng của mình và không trộn với mã copyleft mạnh như GPL
- Việc host Redis dưới dạng dịch vụ trong nội bộ tổ chức được phép, và tổ chức bao gồm cả công ty liên kết và công ty con
1 bình luận
Ý kiến trên Hacker News
Điều này rất có khả năng sẽ làm Redis Labs hỏng như cách Hashicorp bị đẩy vào thế yếu và phải tìm nơi bán mình, mà có lẽ cũng không ngăn được những bên muốn sao chép Redis Labs
Bên chịu thiệt thật sự là các startup nhỏ chỉ muốn dùng cache Redis mà không vướng rắc rối pháp lý. AWS có thể fork Redis, và nếu họ còn phát hành fork đó dưới một giấy phép dễ dãi hơn, phía Redis Labs có thể trở thành lựa chọn tệ hơn về mặt giấy phép
Đây là một lựa chọn khó, nhưng tôi nghĩ tốt hơn là hoặc giữ mã nguồn độc quyền, hoặc bám theo Apache hoặc MIT. Việc đổi giấy phép giữa chừng thật sự rất tệ và có vẻ định sẵn sẽ phản tác dụng
Mã nguồn mở là để người dùng có thể sở hữu phần mềm. Nếu cố lách điều đó bằng các mánh khóe pháp lý để kiếm tiền, người bị tổn hại không phải là đội ngũ ở các tập đoàn lớn mà là người dùng. Redis luôn là một dự án mã nguồn mở dễ dãi, và chính điều đó đã làm nên thành công của nó. Nếu thay đổi điều kiện đó, phép tính trong tương lai cũng thay đổi, báo hiệu kết quả xấu cho tất cả những người liên quan
Cần nhìn rõ hơn sự khác biệt giữa phần mềm do quỹ sở hữu như PostgreSQL và mã nguồn mở do doanh nghiệp sở hữu. Khi trọng tâm là “tối đa hóa giá trị cổ đông”, mục tiêu bảo vệ quyền tự do của người dùng rốt cuộc tất yếu sẽ bị đẩy xuống phía sau
Với cộng đồng Redis, có lẽ sẽ tốt hơn nhiều nếu Antirez tách quan hệ tuyển dụng khỏi quyền sở hữu dự án và giao nó cho một tổ chức phi lợi nhuận. Một mô hình như Apache Redis sẽ tốt hơn cho cộng đồng, và Redis Labs vẫn có thể xây dựng các phần mở rộng độc quyền cùng mảng kinh doanh cloud xung quanh nó
Khi một công ty phát hành phần mềm cốt lõi dưới giấy phép dễ dãi, tôi đã liên tục thấy các đối thủ lớn hơn bước vào và bán các giải pháp phân phối lại chính phần mềm đó
Nếu mục tiêu trung tâm của công ty là lợi nhuận, đây là mối đe dọa sống còn. Ngược lại, nếu mục tiêu của công ty là làm người quản lý phi lợi nhuận để phần mềm tiếp tục tồn tại, thì đây là một thành công lớn
Lập luận này không áp dụng cho phần mềm phụ trợ không phải sản phẩm cốt lõi, chẳng hạn các công cụ hữu ích được tạo ra trong quá trình phát triển nhưng không phải thứ trực tiếp bán để kiếm tiền
Lần đổi giấy phép này chính là nhằm giải quyết vấn đề đó, tức không để các gã khổng lồ cloud đi nhờ miễn phí
Với tôi, nó nghe giống một AGPL tốt hơn. Tôi không quan tâm đến sắc thái triết học hay danh sách phê duyệt của OSI; rốt cuộc nó ít hạn chế hơn AGPL rất nhiều. Có mã nguồn, có thể chạy cục bộ, và có thể dùng theo cùng một cách trong dự án của tôi, dự án thương mại, ở công ty, trên bare metal, VM, Docker, k8s, Azure
Việc Microsoft phải chia một phần khoản premium mà họ vốn đã thu không liên quan gì đến tôi. Trái lại, việc tìm ra một mô hình kinh doanh bền vững là điều đáng hoan nghênh
Nhà phát triển OSS nắm giữ bản quyền. Trừ public domain, chỉ tác giả mới có thể thay đổi giấy phép và điều kiện. Người dùng nhận được giấy phép cho phép làm nhiều việc với phần mềm và mã nguồn, chứ không nhận được quyền sở hữu
Tôi hoàn toàn đồng ý, và cảm giác như đây là thêm một ví dụ nữa cho luận điểm của Cory Doctorow
Có lẽ đến lúc này đã có fork đang được tiến hành rồi. Hơi buồn khi thấy một công ty tự cắt đứt với chính cộng đồng nhà phát triển của mình
Tôi hiểu vì sao họ làm vậy, nhưng không nghĩ cách này hiệu quả về dài hạn
Phần lớn người dùng Redis chưa từng trả một xu nào cho công ty đứng sau, và tôi cũng vậy. Tôi hiểu họ làm thế để kiếm tiền, nhưng hành vi của tôi sẽ không thay đổi. Tôi sẽ chỉ dùng fork. Đại đa số người dùng Redis khác, các contributor bên ngoài, và tất cả các nhà cung cấp cloud từng cung cấp Redis theo hướng thương mại cũng sẽ làm vậy; theo thời gian, khá nhiều nhân viên Redis hiện tại cũng có thể chuyển sang phía đó
Vì có nhiều người dùng thương mại và nhà cung cấp cloud, tôi nghĩ sẽ không mất nhiều thời gian để họ tổ chức lại với nhau. Vì đã có nhiều người dùng trả tiền, trên thực tế gần như họ buộc phải làm vậy
Terraform, Elasticsearch, Red Hat, v.v. cũng đã có những tiền lệ tương tự. Việc khiến phần lớn người dùng mục tiêu và khách hàng tiềm năng phải dựa vào một fork mã nguồn mở có vẻ là một hướng đi sai lầm về chiến lược kinh doanh
Khi Oracle tiếp quản các dự án mã nguồn mở của Sun, chẳng hạn như mysql, hudson, openoffice, họ cũng nhanh chóng mất phần lớn quyền kiểm soát. Nỗ lực thuyết phục mọi người dùng sản phẩm đóng của Oracle không mang lại nhiều kết quả. Ngay cả Java cuối cùng cũng phải lùi một phần, và ngày nay trung tâm là openjdk. Ngoài một vài ngân hàng, hầu như không ai dùng Oracle JDK. Không cần thiết phải làm vậy, và Oracle từ lâu cũng đã thôi giả vờ rằng nó có ưu điểm. Mọi phát triển đều diễn ra trong OpenJDK, và cũng có nhiều công ty cung cấp các bản build được chứng nhận
Cá nhân tôi làm tư vấn về Elasticsearch và Opensearch, và gần đây phần lớn khách hàng mặc định chọn Opensearch. Mọi chuyện cứ tự nhiên diễn ra như vậy. Ai cũng chọn phương án miễn phí và mã nguồn mở
Kết luận chỉ có một. Sẽ có một fork Redis mà đa số người dùng Redis hiện tại sẽ sử dụng
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
Về phía doanh nghiệp, họ có thể chấp nhận tăng giá để khỏi phải di chuyển hoàn toàn, hoặc trong ngắn hạn trong khi đang migration
Để ngăn churn trong ngắn hạn, nhà cung cấp cũng có thể “mua thời gian” bằng cách giữ giá thấp, rồi tăng giá sau khi dự án đã khác fork đủ nhiều khiến việc chuyển đi khó hơn rất nhiều
Dù theo cách nào, về dài hạn họ có thể kiếm được nhiều tiền từ một số ít doanh nghiệp hơn là tiếp tục hỗ trợ nhiều công ty ở đủ quy mô khác nhau. Tôi không thích điều đó, nhưng có vẻ nó có thể hoạt động
Chỉ riêng việc chia rẽ cộng đồng MySQL, làm suy giảm mức sử dụng và phát triển bên ngoài, đồng thời làm chậm toàn bộ dự án cũng có thể đã mang lại ROI tốt
Động lực lớn của những dự án kiểu này vẫn là doanh thu hosting, và vì vậy các thay đổi giấy phép xảy ra
Nhìn vào xu hướng, có vẻ loại mã nguồn mở phù hợp với công ty sở hữu dự án chỉ là thư viện. Nếu là chương trình, ví dụ phần mềm server như cơ sở dữ liệu, thì nó phải trở thành source-available hoặc nằm dưới một foundation. Đây là chuyện khó và tôi không biết câu trả lời là gì
Tôi muốn thấy một mô hình có thể đưa các giấy phép mã nguồn mở permissive trở lại cho các chương trình phức tạp, nhưng vẫn chưa thấy cách nào khả thi. Có thể là thực thi quyền thương hiệu kết hợp với mã nguồn mở, và chỉ cung cấp các bản build được cấp phép
Dù sao, chúng ta vẫn sẽ tiếp tục thấy sự trỗi dậy và suy tàn của phần mềm mã nguồn mở phổ biến, hoặc các thay đổi giấy phép. Lợi ích để nhà phát triển và công ty bắt đầu bằng mã nguồn mở ban đầu là quá lớn, và áp lực muốn thay đổi về sau cũng quá lớn
Ít nhất tôi muốn thừa nhận rằng giá trị Redis mang lại cho thế giới lớn hơn rất nhiều so với giá trị nó lấy đi. Thật sự là chênh lệch áp đảo
Sẽ rất thú vị để xem fork xuất hiện và thành công nhanh đến mức nào, cũng như đường cong tăng trưởng doanh thu của công ty Redis sau 5 năm sẽ ra sao
Tôi không rõ về giấy phép, nhưng rất đồng cảm với tình cảnh các công ty nhỏ và vừa tạo ra công nghệ nền tảng bị những gã khổng lồ cloud mang tính độc quyền nhóm hàng hóa hóa rồi bán lại với giá cao. Ngược lại, tôi còn ngạc nhiên là chuyện này mất lâu đến vậy
Nếu nói rằng cả doanh nghiệp lẫn mã nguồn mở đều muốn một hệ sinh thái lành mạnh, tôi tò mò ngoài việc đổi giấy phép ra còn có lựa chọn nào khác
Đã có nhiều trường hợp một công ty đơn lẻ về cơ bản “fork” ra khỏi foundation và rời đi, và cuối cùng cộng đồng vẫn gặp cùng một kết cục
https://spdx.org/licenses/AGPL-3.0-or-later.html
Những người tạo công cụ làm việc cũng phải trả hóa đơn
Theo một nghĩa nào đó, chính các nhà phát triển cũng có trách nhiệm trong thất bại của giấc mơ FOSS
Chúng ta đang từ từ quay lại thời kỳ public domain và shareware
Mọi người luôn nói rằng mô hình kiếm tiền từ mã nguồn mở là dịch vụ hỗ trợ. Ví dụ, nếu một công ty dùng Postgres, chuyên gia sẽ hỗ trợ cấu hình on-premises và xử lý sự cố giúp họ.
Nhưng trong thời đại “cloud”, các công ty chỉ dùng dịch vụ được quản lý do Amazon, Microsoft, Google, v.v. cung cấp, và cơ hội tài chính của những người bảo trì dự án cùng những người xung quanh về cơ bản biến mất. Không ai muốn làm việc cật lực cho OSS rồi nhìn AWS kiếm hàng triệu đô la mà không trả lại gì cả.
Madelyn Olson, trong thời gian được AWS tuyển dụng, đã làm việc vất vả suốt nhiều năm, giành được sự tin cậy của các nhà phát triển cốt lõi Redis khác và trở thành maintainer cốt lõi. Cô ấy và các nhà phát triển AWS khác đã đóng góp rất nhiều cho engine cốt lõi của Redis. Có thể nói họ cũng đã làm việc chăm chỉ vì cộng đồng Redis.
Có thể đọc thêm về các đóng góp liên quan tại đây: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
Nhiều dự án mã nguồn mở hơn nên áp dụng SSPL, hoặc thử nghiệm cách giới hạn quy mô công ty được sử dụng miễn phí như Llama 2. Chẳng hạn, là mã nguồn mở nhưng không áp dụng cho các hyperscaler cloud trị giá hàng chục tỷ đô la.
Khi các nhà phát triển cá nhân đóng góp, họ không hề có ý định tạo điều kiện cho AWS đi nhờ miễn phí.
Lý do lớn nhất khiến các dự án bị đẩy sang các giấy phép hạn chế hơn là AWS. Điều đúng đắn AWS lẽ ra nên làm là tôn trọng công sức của tác giả hoặc công ty ban đầu, và tiếp sức cho sản phẩm do nhà phát triển gốc hỗ trợ. Thay vào đó, khi AWS thấy một sản phẩm OSS thành công, họ tạo ra sản phẩm cạnh tranh. Nhờ tích hợp chặt chẽ hơn và sức mạnh marketing, nhà cung cấp bên thứ ba không có cửa thắng.
Hơn nữa, Amazon và AWS là những bên hưởng lợi lớn từ mã nguồn mở, có lẽ là lớn nhất, nhưng lại gần như không đóng góp lại. Google, Microsoft, thậm chí Oracle cũng đóng góp cho mã nguồn mở nhiều hơn Amazon.
Tôi chưa từng đóng góp cho dự án có CLA, và cũng không có ý định làm vậy trong tương lai trừ khi nhà tuyển dụng trả tiền cho tôi.
Nhưng để FOSS có thể tồn tại lâu dài, có thể chúng ta cần các hạn chế nhằm tự bảo vệ mình trước các tập đoàn khổng lồ trên thực tế đang khai thác các nhà phát triển FOSS.
Redis, Mongo, ES, bộ sản phẩm HashiCorp và toàn bộ hệ sinh thái big data đã được biết đến rộng rãi hơn nhờ việc AWS cung cấp chúng. Cũng có nhiều cơ sở dữ liệu ít được biết đến, đã được phát triển trong nhiều năm nhưng đến nay mọi người vẫn không biết vì AWS hoặc các nhà cung cấp cloud lớn khác không thúc đẩy.
Ngoài ra, nhờ giấy phép tự do, khi mức sử dụng và độ phổ biến tăng lên, nhiều dự án nhận được các đóng góp như báo cáo lỗi, PR, bản vá. Tôi không mấy muốn đóng góp cho những thứ mang giấy phép kiểu SSPL, BSL, vì không muốn lãng phí thời gian vào thứ mà sau này không thể dùng tự do.
Nếu Redis xuất hiện ngay từ đầu với các hạn chế tương tự Llama 2, nó đã thất bại từ vạch xuất phát. Người dùng chính là doanh nghiệp, còn lý do chủ yếu khiến Llama 2 trở nên phổ biến là vì nó sớm cung cấp một LLM chất lượng cao mà cá nhân có thể dùng cho mục đích cá nhân.
Một kho key-value tương thích RESP không phải là thứ gì đặc biệt ghê gớm. Microsoft cũng vừa phát hành garnet, bản triển khai riêng của họ, theo giấy phép MIT. Giá trị của Redis luôn nằm ở việc nó miễn phí và mã nguồn mở, cùng cộng đồng đã nâng đỡ điều đó. Giờ thì Redis đã vứt bỏ lý do lớn nhất để người ta dùng nó.
Nhưng theo tôi biết, về cơ bản chỉ có trường hợp đó; gần như mọi trường hợp khác như MongoDB, Redis, Memcached, MySQL, PgSQL, v.v. thì không.
Redis Inc. đang chuyển dự án https://github.com/redis/redis/ từ giấy phép BSD 3 điều khoản sang giấy phép kép gồm hai giấy phép không được OSI phê duyệt.
Trước đây họ từng nói “Redis core license được cấp phép theo 3-Clause-BSD và sẽ luôn như vậy”. (https://redis.com/blog/redis-labs-modules-license-changes/)
Nếu lo ngại về việc chấm dứt hỗ trợ, Redis 7.4 sẽ là bản phát hành đầu tiên theo giấy phép mới, còn 7.2 là bản phát hành cuối cùng theo giấy phép cũ
Redis hỗ trợ thêm 2 bản phát hành tại một thời điểm nhất định: latest major.(minor-1), (major-1).(last-minor)
Nói đại khái, điều này có nghĩa là khi 8.0 ra mắt thì hỗ trợ cho 6.2 sẽ kết thúc, và khi 7.6 hoặc 8.0 ra mắt thì hỗ trợ cho 7.2 sẽ kết thúc
Nhìn vào các bản phát hành trước đây, dự kiến 8.0 sẽ ra vào khoảng tháng 3~5/2025. Vì vậy, nếu bạn phụ thuộc vào Redis theo giấy phép 3BSD, cần lập kế hoạch tương ứng
Ubuntu đóng gói redis trong kho
universe, nên các bản nâng cấp bảo mật chỉ được cung cấp cho khách hàng Ubuntu Pro. Vì vậy, với Ubuntu 20.04, các bản nâng cấp redis sẽ dừng vào tháng 4/2024, ngoại trừ người dùng ESM của Ubuntu ProDebian 11/12 theo Redis 6.0/7.0, nên họ có trách nhiệm backport các bản vá của 7.2. Nếu 7.2 không nhận cập nhật bảo mật và chỉ được cung cấp qua nhánh 7.4 thì chưa rõ chuyện này sẽ diễn ra thế nào
Ngay cả khi cách bạn sử dụng trực tiếp phù hợp với giấy phép mới, bạn vẫn có thể bị ảnh hưởng gián tiếp. Vì khả năng cao các bản phân phối sẽ loại redis khỏi kho chính thức trong bản phát hành tiếp theo, nên cần tính đến điều này trong chu kỳ nâng cấp bản phân phối kế tiếp
(Tôi đang duy trì https://endoflife.date/redis, nên nếu ai biết rõ việc chấm dứt hỗ trợ và hỗ trợ sẽ bị ảnh hưởng ra sao thì có thể merge PR)
Giấy phép mới SSPL rất có khả năng không phải là mã nguồn mở, ít nhất là vì hạn chế về lĩnh vực sử dụng: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
https://opensource.org/definition-annotated#6
Đây chính là cốt lõi của mã nguồn mở, và ở một khía cạnh nào đó là của phần mềm tự do. Giấy phép copyleft có các ràng buộc, nhưng nếu tuân theo các ràng buộc đó thì bạn có thể tạo bất cứ thứ gì mình muốn bằng phần mềm đó. Các giấy phép SSPL, FSL, BUSL chặn hẳn việc cạnh tranh theo một số cách thương mại nhất định
Việc phần lớn mô hình kinh doanh không muốn tuân theo copyleft không có nghĩa nó không phải là mã nguồn mở. Chỉ là nó không phù hợp với mô hình kinh doanh đó mà thôi
Các giấy phép mới như SSPL, BSL, FSL đang ngày càng phổ biến, và cũng có lý do của nó. 20 năm trước không có tình huống AWS bán lại FOSS trên toàn thế giới, nên điều kiện khi đó rất khác hiện nay
Vì các hạn chế nên chúng không phải là “mã nguồn mở”, nhưng thuật ngữ gần nhất tiếp theo là “source-available” cũng không phản ánh đúng thực tế. Nó giống như chỉ nói rằng mã nguồn về mặt kỹ thuật có tồn tại ở đâu đó
ElasticSearch, Sentry, v.v. vẫn được phát triển công khai, người không liên quan đến dự án vẫn có thể gửi PR, và nếu không định công khai cạnh tranh với công ty đứng sau dự án thì ai cũng có thể làm điều mình muốn
Cùng lúc đó Microsoft công bố Garnet: https://github.com/microsoft/garnet
Thời điểm thật hợp lý
Lập luận là MS sẽ thả mồi rồi đổi giấy phép khi cần, nên Redis, vốn sẽ luôn duy trì giấy phép mã nguồn mở, là lựa chọn tốt hơn. Một dự đoán quá xuất sắc
Có vẻ các nhà sáng lập kỹ thuật của Redis và Hashicorp đều đã rời đi trước khi công ty của họ rời xa FOSS và gặp bão lớn. Ý là nếu lịch trình không sai
Tôi tò mò liệu họ đã biết trước chuyện này và phản đối, hay biết nhưng muốn tránh thiệt hại danh tiếng. Dù đồng ý với động thái này hay không thì vẫn có tổn hại về danh tiếng. Hay chính vì họ rời đi nên thay đổi mới có thể được thúc đẩy
Hoàn toàn là suy đoán, nhưng điều từng thấy ở Hashi dường như đang lặp lại ở Redis nên khá đáng chú ý
Tôi cũng không bỏ qua điểm tương đồng với Hashi