MongoDB SSPL
|
Chúng tôi sử dụng elaticsearch 7. 17. 4. Nexus-iq báo cáo nhóm mối đe dọa giấy phép 'Bị cấm' ('MongoDB-SSPL-1. 0') Show Máy chủ Nexus IQ là công cụ chính sách của Sonatype. Sonatype có MongoDB-SSPL-1. 0 trong danh sách bị cấm Lỗi chính sách xuất phát từ nhiều plugin và mô-đun elaticsearch khác nhau Chúng tôi có giấy phép elaticsearch. Nó có nên bao gồm tất cả các giấy phép cần thiết khác theo elaticsearch không? MongoDB hơi khó chịu khi một số nhà cung cấp đám mây — đặc biệt là ở châu Á — đang sử dụng mã nguồn mở của họ và cung cấp phiên bản thương mại được lưu trữ trên cơ sở dữ liệu của họ cho người dùng của họ mà không tuân thủ các quy tắc nguồn mở. Để chống lại điều này, hôm nay MongoDB đã thông báo rằng họ đã cấp giấy phép phần mềm mới, Giấy phép Công cộng Phía Máy chủ (SSPL), sẽ áp dụng cho tất cả các bản phát hành mới của Máy chủ Cộng đồng MongoDB, cũng như tất cả các bản sửa lỗi cho các phiên bản trước Trước đây, MongoDB đã sử dụng giấy phép GNU AGPLv3, nhưng hiện tại nó đã gửi SSPL để phê duyệt từ Open Source Initiative Đối với hầu như tất cả người dùng thông thường hiện đang sử dụng máy chủ cộng đồng, không có gì thay đổi vì những thay đổi đối với giấy phép không áp dụng cho họ. Thay vào đó, đây là về những gì MongoDB xem là việc sử dụng sai giấy phép AGPLv3. “MongoDB trước đây đã được cấp phép theo GNU AGPLv3, điều đó có nghĩa là các công ty muốn chạy MongoDB như một dịch vụ có sẵn công khai phải mở nguồn phần mềm của họ hoặc lấy giấy phép thương mại từ MongoDB,” công ty giải thích. “Tuy nhiên, sự phổ biến của MongoDB đã khiến một số tổ chức kiểm tra ranh giới của GNU AGPLv3. ” Vì vậy, mặc dù SSPL không khác mấy so với GNU GPLv3, với tất cả các quyền tự do thông thường để sử dụng, sửa đổi và phân phối lại mã (và hầu như cùng một ngôn ngữ), SSPL tuyên bố rõ ràng rằng bất kỳ ai muốn cung cấp MongoDB như một dịch vụ “Thị trường đang ngày càng tiêu thụ phần mềm như một dịch vụ, tạo ra một cơ hội đáng kinh ngạc để thúc đẩy một làn sóng mới của phần mềm phía máy chủ mã nguồn mở tuyệt vời. Thật không may, một khi dự án nguồn mở trở nên thú vị, các nhà cung cấp đám mây chưa phát triển phần mềm sẽ dễ dàng nắm bắt tất cả giá trị mà không đóng góp gì cho cộng đồng,” Eliot Horowitz, CTO và đồng sáng lập của MongoDB cho biết. . “Chúng tôi đã đóng góp rất nhiều cho — và được hưởng lợi từ — nguồn mở và chúng tôi đang ở vị trí duy nhất dẫn đầu về một vấn đề ảnh hưởng đến nhiều tổ chức. Chúng tôi hy vọng điều này sẽ giúp truyền cảm hứng cho nhiều dự án hơn và bảo vệ đổi mới nguồn mở. ” Tôi chắc chắn rằng động thái này sẽ xù lông. Thật khó để thảo luận về các giấy phép nguồn mở mà không tôn giáo về ý nghĩa của phong trào này. Và bởi vì MongoDB là tổ chức thương mại đằng sau phần mềm và quản lý các đóng góp bên ngoài cho mã, nên nó có khả năng kiểm soát mã thực tế tốt hơn so với các dự án khác do một nền tảng nguồn mở lớn quản lý, chẳng hạn như. Đối với một số người, chỉ riêng điều đó thôi đã là lời nguyền rủa đối với mọi thứ mà họ nghĩ rằng nguồn mở nên đại diện cho. Đối với những người khác, nó chỉ đơn giản là một cách thực dụng để phát triển phần mềm. Tuy nhiên, dù bằng cách nào, điều này sẽ khởi động một cuộc thảo luận về cách các công ty như MongoDB quản lý các dự án mã nguồn mở của họ và mức độ kiểm soát mà họ có thể thực hiện đối với cách mã của họ được sử dụng. Tôi, trước hết, nóng lòng muốn đọc các cuộc thảo luận trên Hacker News hôm nay Sự thiếu rõ ràng xung quanh định nghĩa của SSPL về “dịch vụ” là một phần lý do tại sao đây không phải là giấy phép tốt. SSPL cung cấp một định nghĩa, nhưng nó có thể có một phạm vi đáng ngạc nhiên. Dưới đây, trước tiên tôi tóm tắt một số cuộc thảo luận về định nghĩa này, sau đó thử áp dụng định nghĩa của SSPL cho các tình huống của bạn Trong quá trình xem xét giấy phép OSI của SPPL, CTO lúc bấy giờ của MongoDB là Eliot Horowitz đã giải thích định nghĩa về “dịch vụ” như sau
Thay thế và bầu chọn là một phần của bản gốc. Lưu ý rằng SSPL kết hợp ba thử nghiệm này với “hoặc”, không phải “và” Trước đó, ông đã viết
Vì vậy, theo ý kiến của Horowitz, định nghĩa về “dịch vụ” này thiên về cung cấp dịch vụ cho bên thứ ba hơn là chạy phần mềm dưới dạng dịch vụ/microservice theo nghĩa kỹ thuật Một số người như Lawrence Rosen đã lập luận rằng định nghĩa “làm cho sẵn có” này là không rõ ràng. không thể tính được “giá trị” của một dịch vụ và những gì một chương trình “đạt được cho người dùng” là chủ quan và được thêm vào bởi hoạt động tiếp thị. “Bạn đã tạo ra, ít nhất là một phần, giấy phép FOSS không thể thực thi được với định nghĩa đẹp hơn AGPL về "chương trình dưới dạng dịch vụ" mà vẫn không giúp được gì nhiều. . -)” Chúng tôi có thể thử áp dụng các tiêu chí của SSPL cho các tình huống của bạn a) Ứng dụng web sử dụng cơ sở dữ liệu được bao phủ bởi SSPL không cung cấp chức năng của chương trình đó dưới dạng dịch vụ. Cửa hàng trực tuyến này không cho phép các bên thứ ba tương tác với cơ sở dữ liệu, không lấy giá trị chủ yếu từ cơ sở dữ liệu (nhưng từ việc trở thành một cửa hàng trực tuyến) và không cung cấp mục đích của chương trình được đề cập (cửa hàng trực tuyến không hoạt động như một cơ sở dữ liệu b) Việc thêm API không thay đổi điều này. API cho phép các bên thứ ba tương tác với webshop, không sử dụng API webshop làm cơ sở dữ liệu c) Cung cấp chương trình được SSPL bao phủ dưới dạng dịch vụ dưới một tên khác sẽ đáp ứng định nghĩa của SSPL về dịch vụ. Bạn sẽ cho phép các bên thứ ba tương tác với chức năng của chương trình được bảo hiểm. Dịch vụ này sẽ lấy được giá trị của nó gần như hoàn toàn từ chương trình được bảo hiểm. Và dịch vụ hoàn thành mục đích chính của chương trình được bảo hiểm, là cơ sở dữ liệu Tuy nhiên, nếu dịch vụ được cung cấp thực sự là một phần mềm hoàn toàn không liên quan, chỉ cung cấp API giống như cơ sở dữ liệu được bao phủ bởi SSPL cho mục đích tương tác, thì điều đó có thể hoàn toàn ổn. Ví dụ: AWS DocumentDB là một cơ sở dữ liệu có thể tương tác như vậy. Cơ sở dữ liệu này chỉ có thể thuộc SSPL nếu nó là sản phẩm phái sinh của mã SSPL. Nhiều khu vực pháp lý coi trọng khả năng tương tác và cung cấp các biện pháp bảo vệ pháp lý rõ ràng hoặc án lệ hỗ trợ, e. g. Oracle v Google ở Mỹ d) Một API được thêm vào để cho phép tính bền vững của các đối tượng, tính bền bỉ này được hỗ trợ bởi cơ sở dữ liệu được bao phủ bởi SSPL. Đây là một kịch bản mà tôi thấy SSPL khá khó. Truyền thông công khai của MongoDB chỉ ra rằng họ sẽ không nghĩ rằng điều này nằm trong khái niệm dịch vụ của SSPL. Tuy nhiên, tôi thấy điều đó khó phù hợp với văn bản giấy phép thực tế, điều này có thể được hiểu một cách hợp lý để coi đó là việc cung cấp dịch vụ. Đặc biệt, API lưu giữ lâu dài cho phép tương tác hiệu quả với cơ sở dữ liệu được phủ SSPL thông qua một lớp dịch mỏng và đạt được các mục đích chính của cơ sở dữ liệu. Mặc dù API cụ thể này có thể không lấy giá trị của nó chủ yếu từ cơ sở dữ liệu, nhưng đó không phải là yếu tố duy nhất MongoDB SSPL là gì?Giấy phép Công cộng Phía Máy chủ (SSPL) là giấy phép phần mềm nguồn có sẵn do MongoDB Inc giới thiệu. vào năm 2018 .
SSPL so với AGPL là gì?Sự khác biệt chính liên quan đến phần 13 được thêm vào, trong đó việc sử dụng và phân phối tác phẩm được đề cập dưới bất kỳ hình thức nào đều phải tuân theo. Ở đâu AGPL-3. 0 sử dụng thuật ngữ chung 'tương tác mạng từ xa', SSPL nhắm thẳng vào các dịch vụ SaaS (Phần mềm dưới dạng Dịch vụ), với tiêu đề 'Cung cấp Chương trình dưới dạng dịch vụ' .
Tôi có thể sử dụng giấy phép SSPL không?SSPL duy trì tất cả các quyền tự do mà cộng đồng luôn có với MongoDB theo AGPL - người dùng được tự do sử dụng, xem xét, sửa đổi, phân phối phần mềm hoặc phân phối lại các sửa đổi đối với phần mềm. Khách hàng và đối tác OEM sử dụng MongoDB theo giấy phép thương mại sẽ không bị ảnh hưởng bởi thay đổi này .
Giấy phép công khai phía máy chủ có phải là nguồn mở không?Hãy làm rõ. Loại giấy phép phần mềm độc quyền mới này cung cấp nhiều quyền tự do hơn so với giấy phép độc quyền thông thường của nhiều thập kỷ trước. Nhưng nó không phải là mã nguồn mở . |
