7 điểm bởi xguru 2024-04-01 | 3 bình luận | Chia sẻ qua WhatsApp

Vì sao SSPL là tệ

  • SSPL(Server Side Public License) là một giấy phép tồi tệ đối với mọi người dùng, doanh nghiệp và nói chung là cả cộng đồng
  • Các sản phẩm dùng giấy phép SSPL không phải là mã nguồn mở, nhằm giết chết các đối thủ trong mảng dịch vụ đám mây và dịch vụ được quản lý, đẩy giá lưu trữ tăng lên, và giết chết mã nguồn mở
  • Mục đích của SSPL có thể gần với việc hoàn tiền cho nhà đầu tư hơn là thực sự đối đầu với các công ty lớn

SSPL là gì

  • SSPL là giấy phép được MongoDB, Inc giới thiệu vào năm 2008 nhằm hạn chế việc sử dụng MongoDB
  • Các sản phẩm như Elasticsearch, Kibana và Graylog hiện cũng dùng giấy phép SSPL
  • Theo điều 13, nếu muốn trực tiếp cung cấp sản phẩm cho khách hàng, bạn phải công khai cung cấp “mã nguồn dịch vụ”

Vì sao SSPL có hại cho tất cả mọi người

  • SSPL được đưa ra như một giải pháp tốt để ngăn một số công ty đám mây xấu kiếm lợi mà không đóng góp cho cộng đồng, nhưng trên thực tế đây là một giấy phép đe dọa tự do và triệt tiêu đối thủ
  • Giấy phép này rốt cuộc chỉ là cách nhốt các sản phẩm từng là mã nguồn mở vào trong sản phẩm thương mại, ẩn sau tinh thần giả tạo của chữ “miễn phí”. Có lẽ giờ nên gọi loại phần mềm này là phần mềm “Freemium”
  • MongoDB, Elasticsearch, Kibana và Graylog không còn là sản phẩm mã nguồn mở nữa, và các công ty này giờ có thể hoàn toàn quyết định ai được phép chào bán sản phẩm của họ. Đây chính là hành vi triệt tiêu đối thủ
  • Họ cũng có thể tự cung cấp giải pháp lưu trữ đám mây của riêng mình mà không cần đối thủ, không cần công khai mã nguồn, và giết chết cạnh tranh lẫn đổi mới bằng mức phí do chính họ đặt ra
  • Điều đó có nghĩa là với chúng ta, những khách hàng, chúng ta không còn quyền lựa chọn nhà cung cấp đám mây nữa
  • Một cách máy móc, giá lưu trữ sẽ tăng lên và lựa chọn duy nhất của chúng ta sẽ là duy trì một đội ngũ chuyên trách phần lưu trữ trên hạ tầng riêng. Chính là thứ mà vài năm qua chúng ta đã cố tránh bằng các giải pháp lưu trữ đám mây

Các công ty sử dụng SSPL

  • Các sản phẩm MongoDB đã dùng giấy phép SSPL từ năm 2018, với MongoDB, Inc đứng sau
  • Các sản phẩm Elasticsearch đã dùng giấy phép SSPL từ năm 2021, với Elastic NV đứng sau
  • Các sản phẩm Graylog đã dùng giấy phép SSPL từ năm 2020, với GrayLog, Inc. đứng sau

Một vài câu hỏi chúng ta nên tự đặt ra

  • Làm sao một công ty không còn dùng mã nguồn mở lại có thể yêu cầu người khác “đóng góp trở lại cho cộng đồng”?
  • Làm sao một công ty không công khai mã nguồn dịch vụ đám mây của chính mình lại có thể yêu cầu người khác công khai mã nguồn?
  • Làm sao một công ty dùng giấy phép không phải mã nguồn mở lại có thể tuyên bố mã nguồn mở là một phần trong DNA của mình?
  • Trong hơn 3000 nhân viên, có bao nhiêu người chia sẻ công việc và mã nguồn của mình với cộng đồng? (spoiler: ít hơn rất nhiều)
  • Đó là một công ty công nghệ muốn chia sẻ với cộng đồng, hay một công ty bán hàng muốn tăng lợi nhuận cho nhà đầu tư?

Những lập luận sai về SSPL

  • Lập luận “Tôi không phải nhà cung cấp đám mây nên chuyện này không liên quan” thực ra cần nhận ra rằng tất cả mọi người đều liên quan đến vấn đề này
  • Lập luận “Các công ty này cần tiền để tồn tại” cần hiểu rằng kiếm tiền từ mã nguồn mở không xấu, nhưng SSPL không phải là lời giải đúng
  • Lập luận “Đối thủ vẫn còn tồn tại. SSPL vẫn có thể thương lượng” thực chất có nghĩa là công ty kiểm soát thị trường sẽ có thể quyết định giá và điều kiện của đối thủ
  • Lập luận “SSPL là để chống lại các ông lớn đám mây và tốt cho doanh nghiệp nhỏ” cần nhận ra rằng SSPL trên thực tế có thể khiến các đối thủ nhỏ phá sản và biến mất

Lời khuyên cho các dự án mã nguồn mở

  • SSPL ban đầu có thể trông như một giải pháp tốt, nhưng tôi khuyên đừng mắc sai lầm đó
  • Nếu có vấn đề với một số nhà cung cấp đám mây thì không thể phớt lờ, và tất cả chúng ta phải cùng nhau đấu tranh. Rời khỏi thế giới mã nguồn mở để chiến đấu không phải là cách làm tốt
  • Nếu cần lợi nhuận, hãy dùng giấy phép doanh nghiệp và hỗ trợ cao cấp: “Nếu bạn cần hỗ trợ, chúng tôi có đội ngũ tốt nhất cho việc đó.”
  • Hãy dùng giấy phép copyleft để doanh nghiệp có thể đóng góp trở lại cho cộng đồng: “Nếu bạn sửa mã của chúng tôi, hãy chia sẻ với cộng đồng”
  • Nếu bạn vẫn chọn giấy phép SSPL thì... bạn sẽ:
    • Mất nhiều người đóng góp độc lập và cả những người đóng góp là nhân viên của các công ty lớn
    • Phản bội những người đóng góp đã nỗ lực cải thiện phần mềm mã nguồn mở
    • Rời bỏ thế giới mã nguồn mở để phát triển phần mềm thu phí một phần (Freemium)
    • Gắn sản phẩm của mình với tiếng xấu rất lớn
    • Mất đi lợi ích từ vô số bên tham gia khác nhau đang giúp quảng bá sản phẩm trên toàn thế giới, từ đó làm tăng nhu cầu đối với hỗ trợ cao cấp

3 bình luận

 
aer0700 2024-04-04

Vì là mã nguồn mở nên có thể chọn, nhưng cũng vì là mã nguồn mở nên đôi khi lại bị loại khỏi các lựa chọn.
Có lẽ đây là giấy phép xuất hiện vì AWS lấy MongoDB rồi tạo ra DynamoDB, nên với những người yêu thích mã nguồn mở thì có thể cảm thấy hơi đáng ngờ.

 
coremaker 2024-04-01

Nếu so sánh cả với AGPL thì có vẻ cũng sẽ khá thú vị.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

 
xguru 2024-04-01

Như có thể thấy từ tên miền và tên trang SSPL is BAD, đây là một website được tạo ra với chủ đích nhất định.
Cũng có phần cường điệu hóa khá mạnh. Hãy xem cùng với các ý kiến trên Hacker News bên dưới.

Ý kiến trên Hacker News

  • Có ý kiến phản đối SSPL về mặt nguyên tắc, nhưng đồng thời cũng có sự thấu hiểu về bối cảnh dẫn tới nó. Cũng có phê bình rằng cách mô tả Điều 13 mang tính giật gân nhiều hơn là phân tích khách quan.

    • MongoDB và Elastic đã không lường trước việc AWS sẽ đóng gói lại sản phẩm của họ thành dịch vụ và trở thành đối thủ cạnh tranh. Giấy phép Apache mà Elasticsearch từng dùng cho phép điều đó, nhưng có ý kiến cho rằng về mặt đạo đức thì đáng ra phải ngăn chặn.
    • AWS lẽ ra có thể xây dựng quan hệ 'win-win' thông qua hợp đồng OEM hoặc quan hệ đối tác, nhưng đã không làm như vậy, từ đó dẫn tới kiểu ngăn chặn khó chịu như SSPL.
    • Có sự bất mãn rằng SSPL được tạo ra để làm hài lòng các nhà đầu tư, nhưng cũng có ý kiến không hiểu vì sao mọi người chỉ trích Elastic hay MongoDB mà không chỉ trích AWS, trong khi ngay cả phần mềm nguồn mở thì công ty đứng sau nó cũng không phải là tổ chức phi lợi nhuận.
  • Có lập luận rằng SSPL gây hại cho người dùng, vì nó thúc đẩy độc quyền và làm giảm sự tham gia của cộng đồng, cuối cùng ảnh hưởng đến tất cả người dùng.

  • Việc mọi người muốn kiếm tiền là điều tự nhiên, và người dùng cũng có thể chọn không sử dụng các dự án SSPL. Có quan điểm cho rằng phần mềm phát hành theo giấy phép SSPL vẫn tốt hơn là không có phần mềm đó.

  • Có ý kiến cho rằng hệ sinh thái hiện nay đã rất khác so với 10 năm trước, và các công ty nhỏ cần có con đường để tồn tại và phát triển trong cạnh tranh. Những giấy phép như BSL (Business Source License) có thể không hoàn hảo, nhưng có thể được xem là nỗ lực tìm kiếm một lối đi trung dung lành mạnh.

  • Có ý kiến cho rằng thật kỳ lạ khi chỉ trích SSPL mà lại không nhắc đến AGPL. Đồng thời cũng chỉ ra những người muốn dùng phần mềm tự do nhưng lại không muốn đóng góp.

  • Có ý kiến cho rằng không nên nghiêng hẳn về một phía, mà cần tiếp cận khác nhau tùy từng trường hợp. SSPL có thể tốt với một số công ty đang cố sống sót trước các gã khổng lồ đám mây, nhưng cũng có thể xấu với một số công ty đang lợi dụng người đóng góp.

  • Việc trực tiếp chào bán các sản phẩm MongoDB, Elasticsearch và Graylog cho khách hàng bị cấm. Từ 'trực tiếp' trong SSPL tạo ra khoảng trống cho tranh cãi pháp lý, và đó là điều khiến nhiều người lo ngại.

  • FSL (Functional Source License) là một giấy phép thay thế tốt, tự động chuyển sang Apache 2.0 hoặc MIT sau 2 năm. Nó đơn giản, công khai mã nguồn và đưa ra một cách hợp lý để các công ty SaaS có thể hoạt động.

  • Có đính chính rằng thông tin SSPL được đưa ra vào năm 2008 là sai. Trên thực tế, nó được giới thiệu vào năm 2018.

  • Có ý kiến phê phán cách nhìn phiến diện về tương lai của bản quyền.