GPL vs MIT vs Apache: Mỗi giấy phép yêu cầu gì?

GPL so với MIT và Apache: mỗi giấy phép yêu cầu bạn làm gì

GPL, MIT và Apache 2.0 trả lời cùng một câu hỏi theo những cách khác nhau: khi phân phối lại phần mềm, bạn có nghĩa vụ gì với người khác? MIT chỉ yêu cầu giữ thông báo bản quyền, không yêu cầu gì thêm. Apache 2.0 yêu cầu giữ thông báo đó, đồng thời thiết lập thỏa thuận về patent giữa mọi bên có sử dụng code. GPL yêu cầu bạn công bố source code của phần bạn xây dựng trên nền tảng đó, theo cùng giấy phép mà bạn đã nhận.

Điều này có vẻ là vấn đề dành cho luật sư, cho đến ngày một project bạn đang vận hành thay đổi giấy phép và bị tách thành hai. Khi đó, đây là vấn đề vận hành. Bạn phải chọn giữa hai package repository, còn các client library có thể không còn giao tiếp được với nhau. Hướng dẫn này tập trung vào các giấy phép và cơ chế của chúng, không bàn về phong trào đã tạo ra chúng. Vì vậy, mỗi section đều kết thúc ở điểm liên quan trực tiếp đến bạn: người phải thực hiện upgrade.

Vì sao GPL tồn tại: một máy in không ai được phép sửa

Khoảng năm 1980, Phòng thí nghiệm Trí tuệ nhân tạo MIT nhận được một máy in laser Xerox 9700. Phòng thí nghiệm đã sửa phần mềm cho một máy in đời trước để máy báo cho bạn biết khi lệnh in bị kẹt. Với máy mới, họ không có source code, và yêu cầu cung cấp source code bị từ chối vì một thỏa thuận không tiết lộ thông tin. Richard Stallman, khi đó là một lập trình viên tại phòng thí nghiệm, xem sự từ chối này là vấn đề mang tính hệ thống chứ không phải một sự cố đơn lẻ, rồi công bố dự án GNU vào ngày 27 tháng 9 năm 1983.

Copyleft được xây dựng dựa trên luật bản quyền, không chống lại luật đó. Theo mặc định, bạn hoàn toàn không có quyền sao chép code của người khác. GPL cấp quyền đó với một điều kiện: nếu bạn cung cấp chương trình cho người khác, bạn phải cung cấp source code cho họ theo cùng các điều khoản, để họ có thể làm điều mà phòng thí nghiệm trước đó không thể làm. Điều kiện này có thể được thực thi vì nếu không có license, ngay từ đầu bạn đã không được cấp phép.

Stallman viết license đầu tiên cho GNU Emacs, sau đó khái quát hóa thành GPL version 1 vào ngày 25 tháng 2 năm 1989. GPL version 2 ra mắt vào tháng 6 năm 1991 và vẫn là license của phần lớn system software bạn đang chạy. Lesser GPL ra đời dành cho các library, để một chương trình theo bất kỳ license nào cũng có thể link với một library copyleft mà không bị kéo vào GPL.

Một chi tiết quyết định cách GPL ảnh hưởng đến người tự host. Nghĩa vụ phát sinh khi phân phối, không phải khi sử dụng. Bạn có thể sửa một chương trình GPL, chạy chương trình đó trên server của mình và cung cấp dịch vụ cho công chúng mà không phải cung cấp gì cho ai, vì bạn chưa từng đưa bản sao chương trình cho người khác. Khoảng trống này là lý do AGPL tồn tại.

Truyền thống cấp phép permissive: BSD, rồi MIT

Berkeley chọn một hướng khác. Computer Systems Research Group phát hành phần mã Unix của họ theo một licence yêu cầu giữ lại thông báo bản quyền và tuyên bố từ chối mọi bảo đảm. Phiên bản ban đầu có 4 điều khoản. Điều khoản thứ 4, còn gọi là advertising clause, yêu cầu ghi nhận công lao của trường đại học trong mọi tài liệu quảng cáo có đề cập đến các tính năng của phần mềm. Cách này không thể mở rộng. Stallman đếm được 75 nội dung ghi nhận riêng biệt trong một phiên bản NetBSD năm 1997. UC Berkeley đã rút điều khoản này vào ngày 22 tháng 7 năm 1999, trong một lá thư của William Hoskins thuộc Office of Technology Licensing.

Phần còn lại là BSD licence 3 điều khoản. Licence này bổ sung lệnh cấm sử dụng tên của những người đóng góp để chứng thực sản phẩm của bạn. Phiên bản 2 điều khoản bỏ luôn yêu cầu đó. Nội dung MIT licence xuất phát từ MIT vào thập niên 1980, khi licence này được dùng cho X Window System. Trên thực tế, nó thực hiện cùng chức năng như BSD 2 điều khoản.

Động cơ của hai bên khác nhau. Một trường đại học được tài trợ bằng tiền công muốn công trình của mình được sử dụng ở mọi nơi, kể cả bởi các công ty. GNU project muốn xây dựng một commons không thể bị đóng lại. Cả hai lập trường đều hợp lý, và cả hai đều có điểm thất bại. Code permissive có thể bị đưa vào sản phẩm độc quyền mà không có gì được đóng góp trở lại. Code copyleft bị các công ty từ chối vì luật sư của họ không chấp nhận điều kiện này.

Berkeley còn để lại một bài học thứ hai, và đây là điều bài viết này liên tục quay lại. AT&T's Unix System Laboratories đã kiện Berkeley Software Design vào năm 1992 về code BSD. Vụ kiện được dàn xếp vào đầu năm 1994. Trong 2 năm, không ai có thể chắc chắn rằng BSD an toàn để xây dựng dựa trên đó. Việc áp dụng BSD đình trệ trong khi Linux phát triển. Sự không chắc chắn về pháp lý làm chậm việc áp dụng nhanh hơn cả một tính năng còn thiếu.

Vì sao Apache 2.0 bổ sung điều khoản cấp phép bằng sáng chế

Giấy phép đầu tiên của Apache Group là một biến thể của BSD 4-clause và vẫn có vấn đề về điều khoản quảng cáo tương tự. Version 1.1, phát hành năm 2000, đã loại bỏ điều khoản đó. Version 2.0, phát hành vào tháng 1 năm 2004, là một bản viết lại thay vì chỉ vá lỗi.

Bổ sung quan trọng nhất là bằng sáng chế. MIT và BSD hoàn toàn không đề cập đến bằng sáng chế. Một contributor có thể cấp cho bạn quyền sử dụng mã theo copyright mà không có hạn chế, nhưng vẫn nắm giữ một bằng sáng chế áp dụng cho chức năng của mã đó, rồi kiện những người sử dụng mã. Apache 2.0 khắc phục lỗ hổng này: mỗi contributor cấp một patent licence bao phủ phần đóng góp của mình, và bất kỳ ai kiện với cáo buộc rằng tác phẩm vi phạm bằng sáng chế của họ sẽ mất patent licence của chính họ đối với tác phẩm đó. Mối đe dọa có tính đối ứng, nên trên thực tế không ai khởi kiện.

Phần còn lại của 2.0 mang tính hành chính, và đó là lý do các công ty ưa dùng nó. Có quy định rõ về file NOTICE, nên thông tin ghi nhận tác giả được tập trung tại một nơi thay vì rải rác trong source tree. Có thể áp dụng licence bằng cách dẫn chiếu thay vì dán vào mọi source file. Các đóng góp được điều chỉnh bởi các điều khoản rõ ràng. Trademarks bị loại trừ. Khi legal review một dependency dùng Apache 2.0, mọi câu hỏi cần đặt ra đều đã có câu trả lời trong văn bản licence, nên việc phê duyệt trở thành quy trình thường lệ. Đây chính là phần lớn ý nghĩa của cụm từ "corporate default".

GPLv3 đã thay đổi gì và vì sao Linux vẫn dùng GPLv2

TiVo phát hành một đầu ghi video chạy Linux và công bố mã nguồn kernel, đúng theo yêu cầu của GPLv2. Sau đó, phần cứng kiểm tra chữ ký mật mã khi boot và từ chối chạy kernel mà nó không nhận diện. Bạn có thể đọc mã nguồn, sửa đổi và biên dịch mã nguồn đó. Nhưng bạn không thể chạy nó trên chính thiết bị đã cung cấp mã nguồn. Điều khoản của giấy phép được đáp ứng, nhưng mục đích của giấy phép bị vô hiệu hóa. Cách làm này sau đó được gọi là tivoisation.

GPL version 3, được phát hành vào ngày 29 June 2007, giải quyết trực tiếp vấn đề này. Khi phân phối binary bên trong một thiết bị tiêu dùng, bạn cũng phải cung cấp “Installation Information”: các key hoặc hướng dẫn cần thiết để cài đặt phiên bản đã sửa đổi và chạy phiên bản đó. Version 3 cũng bổ sung điều khoản cấp quyền sử dụng patent rõ ràng, các điều khoản được soạn để đáp lại thỏa thuận patent giữa Microsoft và Novell vào November 2006, cùng khả năng tương thích một chiều với Apache 2.0.

Linux không đi theo hướng đó. Kernel chỉ dùng GPL version 2, không có điều khoản ngoại lệ “or any later version”, và file COPYING của kernel nêu rõ điều này. Linus Torvalds công khai phản đối các điều khoản chống tivoisation đối với phần cứng dùng chữ ký. Rào cản thực tế còn lớn hơn bất đồng này: kernel có hàng nghìn chủ sở hữu bản quyền, nên không ai có thể thu thập đủ chấp thuận cần thiết để đổi giấy phép, ngay cả khi tất cả đều muốn làm vậy. Đây là một trong những biện pháp bảo vệ mạnh nhất mà một dự án có thể có. Bạn nên nhớ điều đó khi xem xét một dự án do một công ty duy nhất sở hữu.

Giấy phép còn lại được phát hành trong 2007 có ảnh hưởng trực tiếp hơn đến bạn. GNU Affero GPL version 3, được phát hành vào November cùng năm, mở rộng nghĩa vụ cung cấp mã nguồn cho những người tương tác với chương trình qua network. Nếu chạy một service AGPL đã sửa đổi cho công chúng, bạn phải cung cấp mã nguồn cho những người dùng đó. Vì vậy, nhiều phần mềm web tự host dùng AGPL. Nextcloud là một ví dụ. Nếu bạn đang so sánh các lựa chọn tự host thay thế cho Nextcloud, dòng giấy phép trong repository của từng ứng viên cho bạn biết nhiều hơn về 5 năm tiếp theo của dự án so với danh sách tính năng.

Bạn thực sự có thể kết hợp những giấy phép nào?

Tính tương thích chỉ đi theo một chiều, từ giấy phép permissive sang giấy phép copyleft.

• Mã nguồn MIT và BSD có thể được đưa vào bất kỳ sản phẩm nào, kể cả sản phẩm đóng.
• Mã nguồn Apache 2.0 có thể được đưa vào dự án GPLv3; tác phẩm kết hợp sẽ dùng GPLv3.
• Không thể đưa mã nguồn Apache 2.0 vào dự án chỉ dùng GPLv2. Các điều khoản về chấm dứt quyền sáng chế và bồi thường của Apache 2.0 là điều kiện bổ sung mà GPLv2 không cho phép thêm. FSF và ASF đều công bố kết luận này.
• Bạn không thể tự chuyển mã nguồn GPL sang một giấy phép permissive. Chỉ chủ sở hữu bản quyền mới có thể làm việc đó, và như vậy bạn lại phải xác định họ là ai.

Kỷ nguyên đổi giấy phép: SSPL, BUSL và những điều chúng không phải là

Động lực ban đầu là lợi ích thương mại. Một công ty sở hữu bản quyền của một sản phẩm, một cloud provider bán sản phẩm đó dưới dạng managed service ở quy mô lớn nhưng đóng góp lại rất ít, nên công ty thay đổi licence để ngăn việc này. Redis Labs là bên đầu tiên có động thái rõ ràng vào tháng 8 năm 2018 khi thêm Commons Clause lên trên Apache 2.0 cho một số module. MongoDB làm theo vào ngày 16 tháng 10 năm 2018 bằng cách chuyển từ AGPLv3 sang Server Side Public License.

SSPL là AGPL với một section được viết lại. Nếu cung cấp program cho bên thứ ba dưới dạng service, bạn phải công bố source code của mọi thứ được dùng để cung cấp service đó, bao gồm cả phần mềm quản lý và orchestration đi kèm. Nghĩa vụ này không có ranh giới rõ ràng và chưa có tòa án nào kiểm định. OSI chưa từng phê duyệt licence này, còn MongoDB đã rút đơn đăng ký vào tháng 3 năm 2019. Debian trước đó đã tuyên bố vào tháng 12 năm 2018 rằng phần mềm SSPL không thuộc archive của họ, và Fedora kết luận vào tháng 1 năm 2019 rằng licence này không phải là free software. Sau đó, Red Hat loại MongoDB khỏi Fedora và Red Hat Enterprise Linux. Đây là kết quả trực tiếp của việc đổi licence: distribution ngừng đóng gói phần mềm, nên các bản nâng cấp của bạn giờ đến từ vendor repository theo lịch của vendor.

Business Source License là một cơ chế khác. Licence này do những người sáng lập MariaDB tạo ra, và version 1.1 có từ năm 2017. Đây không phải copyleft và cũng không phải open source. Source code được công khai, việc sử dụng là miễn phí trừ trường hợp mà vendor loại trừ, thường là chạy một hosted service cạnh tranh, và mỗi release sẽ tự động chuyển sang một licence open source thực sự vào một change date không muộn hơn 4 năm sau release đó. Licence đích phải tương thích với GPLv2. HashiCorp chuyển Terraform và các sản phẩm khác sang BUSL 1.1 vào ngày 10 tháng 8 năm 2023. Outline cũng dùng licence này. Điều đó đáng lưu ý nếu bạn đang chọn trong nhóm các lựa chọn thay thế Notion tự host: chạy nó cho team của bạn thì được phép, còn xây dựng một service trên đó thì không.

Không licence nào trong hai licence này là không trung thực. Cả hai đều nói rõ rằng chúng chỉ cung cấp source code. Theo định nghĩa của OSI, cả hai đều không phải open source, và sự khác biệt này tác động đến bạn chứ không phải cloud provider mà chúng nhắm đến.

OpenSearch: cái giá của việc tách fork giấy phép đối với người vận hành

Elastic công bố vào ngày 14 January 2021 rằng Elasticsearch và Kibana sẽ rời Apache 2.0 để chuyển sang một trong hai lựa chọn là SSPL hoặc Elastic License, bắt đầu từ release 7.11. Version 7.10.2 là release cuối cùng dùng Apache 2.0. Khoảng một tuần sau, AWS cho biết họ sẽ tạo và duy trì một fork Apache 2.0 của cả hai sản phẩm. Fork này được đặt tên là OpenSearch vào ngày 12 April 2021, còn Kibana được đổi tên thành OpenSearch Dashboards. OpenSearch 1.0 được phát hành chính thức vào ngày 12 July 2021, xây dựng từ Elasticsearch 7.10.2 và Kibana 7.10.2.

Hãy xem việc đó khiến những người vận hành cluster phải trả giá thế nào. Tên package và repository thay đổi. Mọi chỗ tham chiếu đến Kibana trong runbook đều phải đổi thành OpenSearch Dashboards. Tên plugin cũng thay đổi. Sau đó, việc tách fork ảnh hưởng đến cả application code: từ version 7.13 của các client library chính thức của Elastic, client sẽ kiểm tra hệ thống mà nó đã kết nối và từ chối tiếp tục nếu hệ thống đó không phải Elasticsearch, đồng thời báo rằng server là sản phẩm không xác định. Một quyết định về licence tại một công ty mà bạn không làm việc cho đã biến thành một call bị lỗi bên trong application của chính bạn.

Câu chuyện sau đó lại thay đổi thêm hai lần. Elastic bổ sung AGPLv3 làm lựa chọn licence thứ ba vào ngày 29 August 2024, nên Elasticsearch hiện tại lại là open source được OSI phê duyệt. Ngày 16 September 2024, AWS chuyển OpenSearch cho OpenSearch Software Foundation, do Linux Foundation lưu trữ. Điều này giúp fork có một tổ chức quản trị không thuộc về một công ty duy nhất. Năm năm sau khi tách fork, cả hai project đều là open source và vẫn được duy trì. Tính đến August 2026, OpenSearch đang ở series 3.x.

Đây là bài học cuối cùng. Licence đã quay lại, nhưng fork vẫn tồn tại. Khi một ecosystem đã có hai phiên bản của mọi thành phần, việc hủy thay đổi giấy phép không thể tự động hợp nhất chúng lại.

Con số quyết định mức độ đau đớn của việc đổi licence là khoảng cách giữa thời điểm công bố và thời điểm có một fork ổn định mà bạn thực sự có thể deploy.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Mỗi khoảng thời gian được tính từ thông báo công khai của vendor đến release ổn định đầu tiên của fork, theo các ngày được liệt kê bên dưới. OpenSearch 1.0 mất 179 ngày, vì fork phải được đổi tên và xây dựng lại mà không có fork trước đó để tham khảo. OpenTofu mất 153 ngày. Valkey mất 27 ngày, vì nó fork từ Redis 7.2.4 và giữ nguyên protocol cũng như định dạng trên disk. Điểm đáng chú ý là xu hướng này: hiện nay một fork đáng tin cậy có thể xuất hiện trong vài tuần, cùng một foundation và các maintainer được trả công ngay từ ngày đầu tiên.

Valkey và OpenTofu: cùng mô hình, nhanh hơn

Redis Ltd chuyển Redis từ giấy phép BSD 3-clause sang lựa chọn RSALv2 hoặc SSPLv1 vào ngày 20 March 2024. Tám ngày sau, Linux Foundation công bố Valkey, được fork từ Redis 7.2.4 và tiếp tục sử dụng BSD 3-clause. Valkey 7.2.5 được phát hành vào ngày 16 April 2024 với cùng protocol và cùng các data file, nên với phần lớn operator, quá trình migration chỉ là đổi tên package. Sau đó, vào May 2025, Redis bổ sung AGPLv3 thành lựa chọn thứ ba trong Redis 8. Điều này khiến Redis trở lại là open source theo định nghĩa của OSI, trong khi Valkey tiếp tục hoạt động theo cơ chế governance riêng. Mô hình này rất giống Elasticsearch.

Terraform cũng đi theo lộ trình tương tự, nhưng có thêm một chương. OpenTofu fork từ bản phát hành cuối cùng sử dụng Mozilla Public License 2.0, gia nhập Linux Foundation vào September 2023 và phát hành 1.6.0 vào ngày 10 January 2024. Ngày 3 April 2024, luật sư của HashiCorp gửi cho dự án một cease and desist letter, cáo buộc rằng fork đã sao chép code từ một bản phát hành Terraform được cấp phép BUSL. OpenTofu công bố phản hồi chi tiết vào ngày 11 April 2024, phủ nhận cáo buộc này và truy nguyên phần code bị tranh chấp về lịch sử được cấp phép theo MPL mà cả hai dự án cùng kế thừa. Sau đó không có diễn biến công khai nào khác. Rủi ro thực sự trong sự việc này là điều cần ghi nhớ: chỉ một cáo buộc cũng có thể khiến việc adoption bị đình trệ trong một quarter. Hiệu ứng này giống vụ kiện Berkeley xảy ra ba mươi năm trước.

Không phải fork nào cũng bắt đầu từ vấn đề giấy phép. Forgejo fork từ Gitea vào năm 2022 sau khi việc phát triển Gitea chuyển sang một công ty. Đây là tranh chấp về governance, không phải tranh chấp về licensing. Forgejo vẫn dùng MIT trong series version 8, sau đó chuyển sang GPLv3 hoặc bản mới hơn từ version 9.0 vào năm 2024, để code của dự án không thể bị đưa ngược vào một product do commercial entity kiểm soát. Nếu bạn đang cân nhắc các lựa chọn Git server tự host, cặp dự án này là ví dụ thực tế rõ nhất về một codebase và hai cách tiếp cận.

Bài kiểm tra cần chạy trước khi chọn dùng bất kỳ thứ gì

Bốn câu hỏi cần trả lời trước lần cài đặt đầu tiên, không phải sau đó.

1. Ai nắm bản quyền? Việc cấp lại giấy phép cần có sự cho phép của mọi chủ sở hữu bản quyền. Vì vậy, một project có hàng trăm contributor độc lập nhưng không có thỏa thuận chuyển nhượng bản quyền thì trên thực tế không thể cấp lại giấy phép. Một project do một công ty sở hữu toàn bộ có thể được cấp lại giấy phép tại một cuộc họp hội đồng quản trị.
2. Có CLA không, và CLA cấp những quyền gì? Contributor licence agreement cho phép công ty cấp lại giấy phép cho phần đóng góp của bạn theo bất kỳ điều khoản nào công ty muốn là cơ chế chính xác đứng sau mọi trường hợp cấp lại giấy phép ở trên. DCO (developer certificate of origin), tức dòng sign-off mà Linux kernel áp dụng từ 2004, không chuyển giao bất kỳ quyền nào. CLA do một foundation nắm giữ an toàn hơn CLA do một công ty nắm giữ, vì công ty có thể bị bán.
3. Ai sở hữu trademark? Elastic vẫn giữ tên Elasticsearch, nên fork phải đổi tên. Mọi runbook có nhắc đến Kibana cũng phải viết lại.
4. Cụ thể việc cấp lại giấy phép sẽ khiến bạn tốn những gì? Hãy tính đến data format, client library, phần cấu hình bạn phải viết lại và việc đã có fork tương thích hay chưa.

Hai lệnh có thể trả lời một phần các câu hỏi này trong vài giây.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Mọi package Debian và Ubuntu đều có file tại /usr/share/doc/<package>/copyright. File này ghi giấy phép của version bạn đã cài, không phải giấy phép mà project đang dùng hiện nay. Với bash trên Ubuntu 24.04, file đó ghi GNU General Public License version 3. Chạy lệnh thứ hai bên trong source checkout để xem lịch sử của chính file giấy phép. Nếu có commit trong hai năm gần đây, bạn nên đọc commit đó trước khi xây dựng bất kỳ thứ gì dựa trên project. Nếu lệnh không in ra gì, repository đặt tên file giấy phép theo cách khác; hãy liệt kê thư mục root để tìm.

Không có giấy phép nào bảo vệ bạn khỏi mọi kết quả, và chọn theo ý thức hệ là lý do khiến nhiều người bất ngờ về sau. Hãy ưu tiên các project có bản quyền được phân tán cho nhiều bên hoặc do một foundation nắm giữ, đồng thời lưu dữ liệu ở format mà bạn có thể export. Sau đó xác định fork nào bạn sẽ chuyển sang và ghi lại tên fork trước khi cần dùng. Kiểm tra từng ứng viên theo cách này mất chưa đến một giờ. Khi bạn quyết định nên tự host gì trong 2026, đây là yếu tố phân biệt một lần upgrade với một lần migration.

FAQ

MIT licence có giống BSD licence không?

Về thực chất, MIT tương đương với BSD 2-clause: giữ thông báo bản quyền và tuyên bố miễn trừ bảo hành, sau đó bạn có thể tùy ý sử dụng, kể cả xây dựng một sản phẩm proprietary. BSD 3-clause bổ sung một điều khoản: không được dùng tên của contributor để xác nhận hoặc quảng bá sản phẩm của bạn nếu chưa được cho phép. Phiên bản BSD 4-clause cũ hơn còn yêu cầu ghi nhận trong tài liệu quảng cáo. UC Berkeley đã rút điều khoản đó vào 22 July 1999, nên hầu như không còn bản phát hành hiện tại nào vẫn có điều khoản này.

Tôi có thể đưa code Apache 2.0 vào một project GPLv2 không?

Không. Apache 2.0 bổ sung các điều kiện mà GPLv2 không cho phép thêm vào, chủ yếu là điều khoản chấm dứt quyền sử dụng patent. Vì vậy, một tác phẩm kết hợp không thể đồng thời đáp ứng cả hai licence. FSF và ASF đều công bố kết luận này. Chiều ngược lại thì được: code Apache 2.0 có thể được đưa vào project GPLv3, và kết quả sẽ là GPLv3. Đây cũng là lý do code Apache 2.0 không thể được merge vào Linux kernel, vì kernel chỉ dùng GPL version 2.

SSPL có phải là một open source licence không?

Không, và câu trả lời này có hậu quả thực tế. OSI chưa bao giờ phê duyệt licence này, còn MongoDB đã rút đơn đăng ký vào March 2019. Debian tuyên bố vào December 2018 rằng phần mềm SSPL không thuộc về archive của mình. Fedora kết luận vào January 2019 rằng licence này không phải licence tự do. Sau đó, Red Hat đã loại MongoDB khỏi Fedora và Red Hat Enterprise Linux. Với bạn, điều đó có nghĩa là một package mà distribution từng maintain giờ đến từ vendor repository và tuân theo lịch hỗ trợ của vendor. Business Source License cũng là source available thay vì open source, dù mỗi release sẽ chuyển đổi sang một open source licence trong vòng four years.

Thay đổi licence có áp dụng cho version tôi đang chạy không?

Không. Licence được cấp cùng một release không thể bị thu hồi khỏi các bản sao đã được phát hành, và đây chính là lý do fork có thể tồn tại. OpenSearch được xây dựng từ Elasticsearch 7.10.2, release cuối cùng mà Elastic phát hành theo Apache 2.0. Điều bạn mất là tương lai, vì bản security fix tiếp theo sẽ được phát hành theo các điều khoản mới. Pin version cuối cùng còn có licence permissive chỉ giúp trì hoãn vài tháng, và đó không phải là một kế hoạch.