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

GPL, MIT và Apache: mỗi licence 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 cho người khác, bạn có nghĩa vụ gì? MIT chỉ yêu cầu giữ lại thông báo bản quyền. Apache 2.0 yêu cầu giữ thông báo đó, đồng thời đưa ra thỏa thuận về patent với mọi người đóng góp cho code. GPL yêu cầu bạn công bố source code của phần bạn xây dựng dựa trên phần mềm, theo cùng licence 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 đổi licence và tách thành hai project. Khi đó, đây là vấn đề vận hành. Bạn phải chọn giữa hai package repository, đồng thời các client library có thể không còn giao tiếp được với nhau. Guide này tập trung vào các licence và cơ chế hoạt động của chúng, không tập trung vào 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, sau đó là MIT

Berkeley chọn một hướng khác. Computer Systems Research Group phát hành phần Unix của mình theo một licence yêu cầu giữ lại thông báo bản quyền và từ chối mọi bảo hành. Phiên bản ban đầu có 4 điều khoản. Điều khoản thứ 3, còn gọi là điều khoản quảng cáo, yêu cầu phải ghi nhận University trong mọi tài liệu quảng cáo có nhắc đế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 July 1999, trong một lá thư của William Hoskins thuộc Office of Technology Licensing.

Phần còn lại là 3-clause BSD licence. Licence này vẫn cấm dùng tên của các contributor để chứng thực cho sản phẩm của bạn. Phiên bản 2-clause loại bỏ cả điều khoản đó. Nội dung MIT licence xuất hiện tại MIT trong thập niên 1980, khi nó được dùng cho X Window System. Trên thực tế, licence này có cùng mục đích với 2-clause BSD.

Độ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 tạo ra một commons không thể bị đóng lại. Cả hai lập trường đều hợp lý, nhưng cả hai đều có điểm thất bại. Code permissive có thể bị đưa vào phần mềm độc quyền, và bạn không nhận lại được gì. 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. Đây cũng là điểm 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 liên quan đến code BSD. Vụ việc được dàn xếp vào đầu năm 1994. Trong 2 năm, không ai chắc 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 việc áp dụng dừng lại nhanh hơn cả việc thiếu một tính năng.

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 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 trở lại rất ít, nên công ty thay đổi license để ngăn việc đó. Redis Labs là bên đầu tiên có động thái rõ ràng vào tháng 8 năm 2018 khi bổ sung Commons Clause lên trên Apache 2.0 cho một số module của mình. MongoDB tiếp bước 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 xung quanh nó. 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 nghiệm. OSI chưa từng phê duyệt license này, còn MongoDB đã rút đơn đăng ký vào tháng 3 năm 2019. Debian đã tuyên bố từ tháng 12 năm 2018 rằng phần mềm dùng 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 license này không tự do. Sau đó, Red Hat loại MongoDB khỏi Fedora và Red Hat Enterprise Linux. Đây là hệ quả trực tiếp của việc đổi license: distribution ngừng đóng gói phần mềm, nên các bản upgrade 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. License này xuất phát từ những người sáng lập MariaDB, và version 1.1 có từ năm 2017. Nó không phải copyleft và cũng không phải open source. Source code được công khai và việc sử dụng ngoài production là miễn phí. Việc sử dụng trong production chỉ được phép trong phạm vi Additional Use Grant của vendor, và grant này thường cấm chạy một hosted service cạnh tranh. Mỗi release tự động chuyển sang một open source license thực sự vào một change date không quá 4 năm sau release đó. License được chuyển sang phải là GPL version 2.0 hoặc version mới hơn, hoặc một license tương thích với một trong các version đó. 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 license này. Điều này đáng lưu ý nếu bạn đang chọn trong các lựa chọn thay thế Notion tự host: chạy nó cho team của bạn là được phép, còn xây dựng một service trên đó thì không.

Không license nào trong hai license này là không trung thực. Cả hai đều nói rõ rằng chúng là source available. Theo định nghĩa của OSI, không license nào là open source. Sự khác biệt cuối cùng ảnh hưởng đến bạn, chứ không phải cloud provider mà các license này nhắm đến.

OpenSearch: cái giá của việc tách fork do thay đổi giấy phép

Elastic thông báo 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 Apache 2.0 cuối cùng. 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á như thế nào. Tên package và repository thay đổi. Mọi tham chiếu đến Kibana trong runbook đều phải đổi thành OpenSearch Dashboards. Tên plugin cũng thay đổi. Sau đó, sự tách fork chạm đến application code: từ version 7.13 của các thư viện client chính thức của Elastic, client sẽ kiểm tra sản phẩm mà nó kết nối đến và từ chối tiếp tục nếu đó không phải Elasticsearch, đồng thời báo rằng server là một sản phẩm không xác định. Một quyết định về giấy phép 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ị fail bên trong application của chính bạn.

Câu chuyện sau đó lại thay đổi thêm 2 lần. Elastic thông báo vào ngày 29 August 2024 rằng họ sẽ thêm AGPLv3 làm lựa chọn giấy phép thứ 3. FAQ về giấy phép của Elastic ghi nhận việc bổ sung này vào September 2024, nên Elasticsearch hiện tại lại là open source được OSI phê duyệt. Vào ngày 16 September 2024, AWS chuyển OpenSearch cho OpenSearch Software Foundation, do Linux Foundation hỗ trợ, tạo cho fork này một nơi 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ả 2 dự án đều là open source, đều đang được duy trì, và OpenSearch đang ở series 3.x tính đến October 2026.

Kết cục chính là bài học. Giấy phép đã quay lại, nhưng fork vẫn tồn tại. Khi một ecosystem đã có 2 phiên bản của mọi thứ, việc hủy thay đổi giấy tờ không thể hợp nhất chúng trở lại.

Con số quyết định mức độ đau đớn của một lần đổi giấy phép là khoảng thời gian từ lúc thông báo đến khi 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, dùng 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à rebuild mà không có fork trước đó để sao chép. 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ư on-disk format. Điểm đáng chú ý là hướng phát triển: hiện nay một fork đáng tin cậy có thể xuất hiện trong vài tuần, với một foundation và các maintainer được trả phí 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.