Cuộc đối đầu giữa AWS và Elastic xoay quanh Elasticsearch
(blog.opsnow.com)Gần đây, sau khi đọc các bài viết về việc Elasticsearch từ bỏ mã nguồn mở, tuyên bố chuyển sang SSPL, và việc AWS tách riêng để fork rồi duy trì một cộng đồng mã nguồn mở theo giấy phép Apache License 2.0, tôi đã thử tóm tắt lại cuộc đối đầu giữa hai bên đã diễn ra từ trước đến nay.
Nếu có chỗ nào còn thiếu hoặc chưa chính xác, hãy để lại bình luận để tôi phản ánh và cập nhật.
10 bình luận
Cá nhân tôi không thực sự hiểu vì sao OSI lại hủy việc công nhận SSPL là giấy phép mã nguồn mở. Đây là một giấy phép được cụ thể hóa hơn từ AGPL, và tôi hiểu nó là yêu cầu các nhà cung cấp dịch vụ SaaS phải công khai toàn bộ mã nguồn, nhưng tôi không hiểu rõ vì sao OSI lại diễn giải điều đó là "hạn chế" SaaS.
Ngay cả khi đọc tuyên bố lập trường của OSI 1, họ chủ yếu chỉ trích ý đồ của Elastic khi áp dụng SSPL chứ không giải thích điều khoản nào của SSPL đang "hạn chế" việc sử dụng. Đọc nội dung thì tôi cũng không rõ liệu nó có đặt thêm "hạn chế" nào so với AGPL hay không. Không biết có phải tôi đang hiểu sai cách diễn giải giấy phép hay không...
Việc rút lại liên quan đến giấy phép là từ phía MongoDB. Không phải do OSI từ chối. Tất nhiên, phía OSI cũng phản ứng rằng khó có thể công nhận đây là mã nguồn mở đối với những điểm còn gây tranh cãi, nhưng MongoDB đã nắm bắt tình hình này từ trước và tự rút đơn đăng ký.
Cảm ơn bạn đã đính chính. Có vẻ như phần mô tả của tôi hơi thiếu chính xác. Dù vậy, đúng là MongoDB đã rút lại trước, nhưng ngay cả khi nhìn vào bài đăng của OSI được nêu trong liên kết thì cũng thấy rõ rằng OSI hiện không có ý định chấp nhận phiên bản SSPL hiện tại... nên có lẽ bối cảnh trước sau không quá quan trọng.
Tôi đồng ý. ^^
Tôi cũng đang tìm kiếm vì có chút nghi vấn, nên thử chia sẻ đường link này.
https://ceart.kr/component/file/…
Trích đoạn
Trước hết, điểm khác giữa SSPL và AGPL là như sau. AGPL trước đây, ngay cả khi một phần mềm không được phân phối mà chỉ chạy ở phía máy chủ, cũng giống như GPL ở chỗ nhà cung cấp dịch vụ phải công khai toàn bộ mã nguồn của các phần đã sửa đổi và bổ sung đối với phần mềm đó; tuy nhiên phạm vi chỉ giới hạn ở chính máy chủ đó.
Ngược lại, SSPL yêu cầu không chỉ mã của phần đó mà còn cả mã của mọi phần mềm mà người vận hành dịch vụ As-a-Service sử dụng để cung cấp dịch vụ, như phần mềm quản trị cần thiết đi kèm, giao diện người dùng, API, phần mềm tự động hóa, phần mềm giám sát, phần mềm sao lưu và lưu trữ, v.v., đều phải được công khai. Nói cách khác, khi các nhà cung cấp dịch vụ đám mây cung cấp MongoDB dưới hình thức dịch vụ, họ sẽ phải công khai cả mã nguồn của toàn bộ phần mềm mà họ tạo ra để duy trì lợi thế cạnh tranh cho dịch vụ của mình.
Tôi cũng định tìm hiểu cả về MongoDB và Redis nữa... hóa ra ở đây đã giải thích rất rõ rồi!
Ngoài ra, nếu xem file PDF thì cũng có phần giải thích những điểm nào không phù hợp với OSI. Theo đó, vấn đề là sự hạn chế đối với quyền tự do và giới hạn đối với các tác phẩm riêng biệt.
Ồ... đây đúng là một bản PDF được viết rất tốt trên tổng thể. Cảm ơn vì đường link.
Nhìn theo cách này thì tôi có thể hiểu điểm khác với AGPL và lý do không chấp nhận SSPL, nhưng cũng khiến tôi nghĩ rằng OSI có phần hơi nghiêng về phía permissive.
Toàn bộ lịch sử được sắp xếp rất rõ ràng nên tôi đã đọc rất thoải mái. Cảm ơn bạn!
Xem các bài viết liên quan
https://vi.news.hada.io/topic?id=3620 - AWS công bố fork mã nguồn mở của Elasticsearch và Kibana
https://vi.news.hada.io/topic?id=3606 - Elastic thay đổi giấy phép để AWS không thể sử dụng