Lịch sử phần mềm mã nguồn mở và các giấy phép

Phần mềm mã nguồn mở là gì và bắt nguồn từ đâu

Lịch sử của phần mềm mã nguồn mở phần lớn là lịch sử của các giấy phép, vì giấy phép là yếu tố duy nhất quyết định bạn được phép làm gì với mã nguồn do người khác viết. Mọi người đã chia sẻ mã nguồn công khai từ rất lâu trước khi có ai ghi các giấy phép đó thành văn bản. Việc chia sẻ chấm dứt khi mã nguồn trở thành một sản phẩm, và các giấy phép được viết ra để bảo vệ quyền chia sẻ trước tòa án.

Đó là phiên bản ngắn gọn. Phiên bản đầy đủ quan trọng vì phần mềm bạn chạy trên server ngày nay vẫn mang dấu ấn của những quyết định đó. Một số quyết định được đưa ra vào năm 1983. Một số được đưa ra vào năm ngoái, và đó là lý do một vài ứng dụng trong các hướng dẫn self-hosting của chúng tôi hiện có hai phiên bản với tên khác nhau.

Phần mềm được chia sẻ trước khi được bán

Trong những năm 1950 và 1960, phần mềm đi kèm với máy tính. IBM phát hành mã nguồn cùng các hệ thống của mình, còn những nhóm người dùng như SHARE, được thành lập vào năm 1955, chuyền tay các chương trình trên băng từ. Có hai yếu tố đã chấm dứt điều đó. Năm 1969, IBM công bố sẽ định giá phần mềm riêng với phần cứng, qua đó hình thành một thị trường độc lập cho phần mềm. Sau đó, pháp luật cũng theo kịp. Computer Software Copyright Act of 1980 xác nhận rằng chương trình là tác phẩm có thể được bảo hộ bản quyền tại Hoa Kỳ. Sau năm 1980, mã nguồn bạn không tự viết mặc định bị đóng, vì vậy việc chia sẻ mã cần có sự cho phép bằng văn bản của tác giả.

Câu lạc bộ Máy tính Homebrew và Thư ngỏ gửi những người đam mê máy tính

Câu lạc bộ Máy tính Homebrew tổ chức cuộc họp đầu tiên vào tháng 3 năm 1975, trong một gara ở Menlo Park, California. Các thành viên mang theo phần cứng và băng giấy; việc sao chép là một phần của cuộc họp. Altair BASIC, do Bill Gates và Paul Allen viết, được chuyền quanh phòng trên những cuộn băng đã sao chép. Tháng 2 năm 1976, Gates trả lời trong bản tin của câu lạc bộ bằng bài “Thư ngỏ gửi những người đam mê máy tính”.

Như phần lớn những người đam mê máy tính hẳn đã biết, đa số các bạn đang ăn cắp phần mềm.

Ông viết rằng chưa đến 1 trong 10 chủ sở hữu Altair đã trả tiền cho BASIC, và thời gian máy tính dùng để viết phần mềm này có giá trị hơn 40,000 dollar. Toàn bộ lập luận hiện đại đã có trong bức thư đó. Sao chép phần mềm không tốn chi phí và giúp ích cho tất cả những người sao chép nó. Nhưng để viết phần mềm, vẫn có người phải bỏ ra 1 năm cuộc đời. Mỗi licence được mô tả dưới đây đều cố gắng giải quyết đồng thời cả hai thực tế đó.

GNU năm 1983 và GPL như một sáng chế pháp lý

Richard Stallman công bố GNU vào tháng 9 năm 1983 trên Usenet, mạng newsgroup được sử dụng trước khi web xuất hiện. GNU là viết tắt của “GNU's Not Unix”. Kế hoạch là xây dựng một hệ thống tương thích với Unix hoàn chỉnh để bất kỳ ai cũng có thể sao chép và thay đổi.

Unix tự do! Bắt đầu từ Lễ Tạ ơn năm nay, tôi sẽ viết một hệ thống phần mềm tương thích hoàn toàn với Unix có tên GNU (viết tắt của Gnu's Not Unix), và cung cấp miễn phí cho tất cả những ai có thể sử dụng nó.

Free Software Foundation (FSF) được thành lập sau đó vào năm 1985. Free Software Definition của tổ chức này liệt kê 4 quyền tự do, được đánh số bắt đầu từ 0: chạy chương trình cho bất kỳ mục đích nào, nghiên cứu và thay đổi chương trình, phân phối lại các bản sao, và phân phối các phiên bản đã thay đổi. Quyền tự do 1 yêu cầu mã nguồn, vì trên thực tế không ai có thể nghiên cứu một binary theo cách khả thi. “Free” ở đây có nghĩa là tự do, không phải miễn phí. Cụm từ của FSF là free như trong free speech, không phải free như trong free beer.

Tuyên ngôn không phải là sáng chế. Licence mới là sáng chế. GNU General Public License (GPL) dùng luật bản quyền để yêu cầu chia sẻ thay vì ngăn cản việc chia sẻ. Bạn nhận được 4 quyền tự do với một điều kiện: bất kỳ ai được bạn chuyển phần mềm cho cũng phải nhận được các quyền đó, kèm mã nguồn. Stallman gọi cơ chế này là copyleft. Cơ chế này lần đầu được phát hành cùng GNU Emacs vào năm 1985, trở thành GPL version 1 vào năm 1989, và version 2 vào tháng 6 năm 1991.

GPL hoạt động vì nó dựa trên luật bản quyền, chứ không chống lại luật đó. Nếu không có licence, bạn hoàn toàn không có quyền phân phối code của người khác. GPL cấp quyền đó và gắn các điều kiện vào quyền này. Vì vậy, một vendor phát hành code GPL đã sửa đổi bên trong router nhưng từ chối cung cấp mã nguồn không phải là đang vi phạm một lời hứa. Vendor đó đang xâm phạm bản quyền, và chủ sở hữu bản quyền có thể đưa vụ việc ra tòa. Đây là lý do việc thực thi GPL có thể thực hiện được, từ các vụ việc của Harald Welte và gpl-violations.org trong những năm 2000 cho đến vụ kiện của Software Freedom Conservancy chống lại Vizio, được đệ đơn vào năm 2021, trong đó lập luận rằng người đã mua chiếc television cũng có thể yêu cầu cung cấp mã nguồn.

Linux hoàn thiện hệ thống

Đến năm 1991, dự án GNU đã có compiler, C library, shell và hầu hết công cụ. Dự án vẫn chưa có kernel hoạt động, vì kernel riêng của GNU là Hurd mất nhiều thời gian hơn dự kiến. Vào tháng 8 năm 1991, một sinh viên ở Helsinki đăng bài lên newsgroup comp.os.minix:

Tôi đang làm một hệ điều hành (miễn phí, chỉ là dự án cá nhân, sẽ không lớn và chuyên nghiệp như gnu) cho các máy clone AT 386(486).

Linux 0.01 ra mắt vào tháng 9 năm 1991 theo một license do Linus Torvalds tự viết, trong đó cấm bán phần mềm. Đầu năm 1992, ông thay license này bằng GPLv2 và sau đó nói rằng đây là một trong những quyết định đúng đắn nhất của mình. License này khiến các công ty có thể đóng góp an toàn: một công ty có thể phân công kỹ sư làm việc trên kernel mà không lo đối thủ biến các cải tiến đó thành phần mềm độc quyền.

Một Unix miễn phí đã tồn tại tại Berkeley. Lý do Linux chứ không phải BSD (Berkeley Software Distribution) trở thành Unix miễn phí mặc định một phần là do một vụ kiện. Unix System Laboratories kiện Berkeley Software Design vào năm 1992, và vụ kiện kéo dài đến đầu năm 1994. Trong 2 năm đó, các hệ thống BSD có rủi ro pháp lý còn Linux thì không, và đó là thời điểm người dùng bắt đầu chuyển sang Linux. FSF đề nghị gọi hệ thống kết hợp này là GNU/Linux, vì Linux là kernel còn phần lớn công cụ xung quanh là của GNU. Hầu hết mọi người gọi là Linux. Cả 2 tên đều chỉ cùng một tập hợp phần mềm.

1998: thương hiệu open source và sự chia rẽ chưa bao giờ được hàn gắn

Tháng 1 năm 1998, Netscape thông báo sẽ công bố source code của trình duyệt. Đây là công ty lớn nhất từ trước đến lúc đó thực hiện việc này, và quyết định đó làm lộ ra một vấn đề thực tế. Trong tiếng Anh, cụm từ "free software" được hiểu là "phần mềm không tốn tiền", và các lãnh đạo công ty đã hiểu đúng theo nghĩa đó. Tháng 2 năm 1998, một nhóm họp tại Palo Alto để tìm thuật ngữ phù hợp hơn, và Christine Peterson đề xuất "open source". Trong vài tuần sau đó, Eric Raymond và Bruce Perens thành lập Open Source Initiative (OSI). Tổ chức này thông qua Open Source Definition, được điều chỉnh từ Debian Free Software Guidelines do Perens viết vào năm 1997.

Open Source Definition có mười tiêu chí. Hai tiêu chí quyết định phần lớn các tranh luận hiện đại: source phải được cung cấp, và licence không được hạn chế ai có thể sử dụng chương trình hoặc họ có thể sử dụng chương trình vào mục đích gì. Một licence ghi rằng "bạn không được cung cấp phần mềm này dưới dạng một dịch vụ thương mại" sẽ không đạt tiêu chí, bất kể licence đó cho phép những gì khác. Hãy nhớ câu này. Đây là ranh giới mà các licence source-available ngày nay vượt qua.

Sự chia rẽ bắt đầu từ năm 1998 liên quan đến lý do, không phải việc licence nào được chấp nhận. Lập luận của FSF mang tính đạo đức: người dùng không thể thay đổi chương trình thì không kiểm soát được máy tính của chính mình. Lập luận của OSI, được Raymond trình bày với giới kinh doanh trong bài viết "The Cathedral and the Bazaar", mang tính thực tiễn: phát triển mở tạo ra phần mềm tốt hơn, và doanh nghiệp có thể dựa vào đó để hành động. Bài phản hồi của Stallman, "Why Open Source Misses the Point of Free Software", vẫn được đăng trên gnu.org, và ông chưa bao giờ chấp nhận thuật ngữ mới này. Perens, người góp phần tạo ra thuật ngữ đó, đã từ chức khỏi ban quản trị OSI vào năm 1999 vì cho rằng phong trào đã rời xa free software.

Cần phân biệt chính xác rằng khoảng cách thực tế giữa hai bên rất nhỏ. Danh sách free licence của FSF và danh sách licence được OSI phê duyệt gần như trùng khớp hoàn toàn, trong đó có GPL, MIT, Apache 2.0 và BSD. Những người viết cần diễn đạt đồng thời cả hai nghĩa thường dùng FOSS (free and open source software) hoặc FLOSS (free/libre and open source software).

Cách các công ty học được cách phát hành mã nguồn

Việc Red Hat niêm yết trên thị trường chứng khoán năm 1999 cho thấy tiền nằm ở dịch vụ hỗ trợ và đóng gói, không phải ở việc bán các bản sao phần mềm. IBM cam kết đầu tư một tỷ đô la vào Linux cho năm 2001. Giám đốc điều hành Microsoft gọi Linux là “một căn bệnh ung thư” vào năm 2001. Đến năm 2016, chính công ty đó lại tham gia Linux Foundation với tư cách thành viên platinum, rồi mua GitHub vào năm 2018 với giá 7.5 tỷ đô la bằng cổ phiếu. IBM mua Red Hat vào năm 2019 với giá 34 tỷ đô la. Không điều nào trong số đó là sự thay đổi quan điểm về giấy phép. Đó là sự thay đổi về nơi tạo ra doanh thu. Khi một hệ điều hành là chi phí dùng chung, tự duy trì hệ điều hành riêng sẽ rất tốn kém, và mọi vendor đều muốn cạnh tranh ở lớp phía trên.

Quyền sở hữu của doanh nghiệp cũng có thể dẫn đến kết quả ngược lại. Khi Oracle mua Sun vào năm 2010, công ty này tiếp quản MySQL và OpenOffice.org, rồi cả hai cộng đồng đều rời đi. MariaDB phát triển từ MySQL, còn LibreOffice được fork từ OpenOffice.org vào tháng 9 năm 2010. Fork là quyền biểu quyết thực sự duy nhất của một cộng đồng người dùng, và giấy phép là thứ khiến quyền biểu quyết đó trở nên khả thi.

Vì sao một số ứng dụng bạn tự host hiện đã có fork

Từ năm 2018 trở đi, một nhóm công ty đã thay đổi điều khoản của phần mềm mà họ đã phát hành trước đó. Tình huống này lần nào cũng tương tự. Một công ty thuê gần như toàn bộ developer, một cloud provider lớn hơn nhiều bán chính phần mềm đó dưới dạng managed service, và công ty nhỏ hơn cho rằng license là lý do khiến họ không thể cạnh tranh.

• MongoDB chuyển sang Server Side Public License (SSPL) vào tháng 10 năm 2018. SSPL quy định rằng nếu bạn cung cấp phần mềm cho người khác dưới dạng service, bạn phải công khai source code của mọi thứ được dùng để cung cấp service đó. OSI không chấp nhận license này là open source, và MongoDB đã rút nó khỏi quá trình thẩm định vào năm 2019.
• Redis bổ sung các hạn chế sử dụng cho một số module trong năm 2018 và 2019, sau đó chuyển server chính sang các điều khoản source-available kép ở version 7.4 vào tháng 3 năm 2024. Một fork của bản phát hành cuối cùng còn dùng BSD license xuất hiện vài ngày sau đó với tên Valkey, dưới sự bảo trợ của Linux Foundation và được Amazon, Google, Oracle cùng nhiều công ty khác hỗ trợ. Vào tháng 5 năm 2025, Redis bổ sung Affero General Public License version 3 (AGPLv3), một license được OSI phê duyệt, làm lựa chọn thứ ba cho Redis 8.
• Elastic chuyển Elasticsearch và Kibana khỏi Apache 2.0 vào tháng 1 năm 2021, sang các điều khoản kép gồm SSPL và Elastic License. Amazon fork OpenSearch. Elastic bổ sung AGPLv3 làm lựa chọn thứ ba vào tháng 8 năm 2024, và OpenSearch được chuyển giao cho Linux Foundation vào tháng 9 năm 2024 dưới tên OpenSearch Software Foundation.
• HashiCorp chuyển Terraform và các tool khác sang Business Source License (BUSL) vào tháng 8 năm 2023. BUSL không phải là open source license trong thời gian còn hiệu lực, vì nó cấm sử dụng trong production để cạnh tranh. Mỗi release sẽ chuyển sang một open license vào một ngày cố định, với Terraform là sau 4 năm. OpenTofu được fork trong vòng vài tuần và hiện cũng thuộc Linux Foundation.

Cả hai phía đều có lý do chính đáng, và không bên nào hành động thiếu thiện chí. Một công ty phải trả lương cho 50 người trong khi một công ty lớn hơn rất nhiều bán lại sản phẩm của mình sẽ gặp vấn đề mà thiện chí không thể giải quyết. Người dùng xây dựng hệ thống dựa trên các điều khoản của Apache 2.0 rồi thức dậy dưới các điều khoản mới cũng gặp vấn đề, và không ai hỏi ý kiến họ trước. Hãy để ý điều xảy ra tiếp theo trong 2 trường hợp đó. Sau khi các fork được sử dụng rộng rãi, Elastic và Redis đều bổ sung copyleft mạnh trở lại. Copyleft giải quyết khiếu nại ban đầu, vì AGPLv3 yêu cầu nhà cung cấp service công khai các thay đổi mà họ chạy. Tính đến tháng 8 năm 2026, cả 2 project và cả 2 fork vẫn đang hoạt động. Đây là kết quả mà các license được thiết kế để cho phép.

Ai được phép thay đổi giấy phép

Một dự án chỉ có thể đổi giấy phép nếu một bên kiểm soát bản quyền của toàn bộ dự án. Các công ty đạt được quyền kiểm soát đó theo một trong hai cách. Việc chuyển nhượng bản quyền chuyển quyền sở hữu từng phần đóng góp cho công ty. Thỏa thuận cấp phép cho contributor (CLA) vẫn để bạn là chủ sở hữu, nhưng cấp cho công ty các quyền đủ rộng để đổi giấy phép đối với phần việc của bạn. Thông thường, bạn ký một trong hai loại thỏa thuận này bằng cách nhấp vào liên kết mà bot đăng trong pull request đầu tiên của bạn.

Linux không có CLA. Các đóng góp được cung cấp theo GPLv2 kèm Developer Certificate of Origin, và bản quyền được phân tán cho hàng nghìn cá nhân và công ty. Không ai có thể đổi giấy phép của Linux, vì không ai có thể thu thập đầy đủ chữ ký của tất cả các bên đó. Cơ chế bảo vệ tương tự cũng áp dụng cho mọi dự án có nhiều chủ sở hữu bản quyền độc lập. Đây là cơ chế bảo vệ mạnh hơn một lời hứa, vì nó dựa trên thực tế về quyền sở hữu của từng phần.

Vì vậy, câu hỏi cần đặt ra về phần mềm mà bạn dự định phụ thuộc vào không phải là hiện nay phần mềm đó có phải open source hay không. Câu hỏi là ai có thể thay đổi giấy phép của phần mềm đó, và họ có thể tự mình thực hiện việc đó hay không.

Nền tảng thực sự mang lại gì

Một foundation nắm giữ tài sản và xác định quy tắc ra quyết định. Apache Software Foundation, Linux Foundation, Cloud Native Computing Foundation trực thuộc Linux Foundation và Software Freedom Conservancy đều thực hiện công việc này theo những cách khác nhau. Foundation không tự nhiên trở nên trung lập. Các thành viên trả phí để có ghế, và phần lớn người làm toàn thời gian cho một dự án lớn thuộc foundation đều do các công ty thành viên trả lương. Điều bạn nhận được hẹp hơn nhưng vẫn rất có giá trị: trademark và quy trình release không thuộc về một vendor duy nhất, nên không công ty nào có thể đưa dự án thành private.

Trademark là phần nhiều người bỏ qua. Code được cấp phép. Tên là trademark, và trademark không nằm trong phạm vi của code licence. Bạn luôn có thể fork code. Nhưng thông thường bạn không thể giữ tên cũ. Đó là lý do các fork trong câu chuyện này có tên là Valkey, OpenSearch, OpenTofu và Forgejo.

Vấn đề maintainer

Hạ tầng hiện đại phụ thuộc vào những project chỉ có một hoặc hai maintainer không được trả công. Các sự cố khiến thực tế này lộ rõ. Lỗ hổng Heartbleed trong OpenSSL năm 2014 ảnh hưởng đến một library xử lý phần lớn lưu lượng web được mã hóa, nhưng chỉ có một nhóm nhỏ người duy trì với gần như không có kinh phí. Log4Shell vào tháng 12 năm 2021 khiến hoạt động ứng phó sự cố trên toàn thế giới phải dựa vào một nhóm tình nguyện viên nhỏ của project Apache Log4j.

Backdoor XZ Utils được phát hiện vào tháng 3 năm 2024 là ví dụ rõ nhất, vì cuộc tấn công nhắm vào maintainer thay vì code. Một account đã dành khoảng hai năm để đóng góp những thay đổi thực sự hữu ích cho một compression library được dùng trong nhiều Linux distribution. Những account khác gây áp lực buộc maintainer duy nhất, vốn đã kiệt sức, phải nhận thêm người hỗ trợ. Co-maintainer mới sau đó cài backdoor vào các release archive, nhắm đến những system có SSH (secure shell) daemon link với liblzma. Một developer phát hiện ra backdoor khi điều tra lý do login mất thêm khoảng nửa giây so với dự kiến. Đó là may mắn, và tất cả những người liên quan đều đã công khai thừa nhận như vậy.

Kinh phí đã bắt đầu được rót vào: GitHub Sponsors từ năm 2019, Open Collective, Sovereign Tech Fund của Đức từ năm 2022 và project Alpha-Omega của OpenSSF. Kinh phí được phân bổ không đồng đều và thường tìm đến những project vốn đã nổi tiếng. Quy định cũng đang được ban hành. Cyber Resilience Act của Liên minh châu Âu có hiệu lực vào tháng 12 năm 2024, trong đó phần lớn nghĩa vụ sẽ áp dụng từ tháng 12 năm 2027. Các bản dự thảo ban đầu có thể khiến tình nguyện viên không được trả công phải chịu trách nhiệm pháp lý như nhà sản xuất. Vì vậy, văn bản cuối cùng tạo ra một nhóm nhẹ hơn có tên là "open source software steward", sau thời gian dài các foundation và distribution vận động.

Lịch sử open source có ý nghĩa gì đối với phần mềm trên VPS của bạn

Mọi ứng dụng trong các hướng dẫn self-hosting của chúng tôi đều kế thừa từ những quyết định này. Nextcloud tồn tại nhờ một fork: năm 2016, người sáng lập ownCloud và phần lớn đội ngũ đã rời đi, rồi khởi động lại dự án theo AGPLv3. Hai sản phẩm này hoạt động song song từ đó đến nay. Lịch sử đó là bối cảnh của các lựa chọn thay thế Nextcloud đáng cân nhắc và các lựa chọn thay thế Dropbox tự host cạnh tranh với cả hai sản phẩm.

Mô hình tương tự cũng xuất hiện trong lĩnh vực Git hosting. Chính Gitea bắt đầu vào năm 2016 dưới dạng fork của Gogs. Cuối năm 2022, trademark và các domain của dự án được chuyển cho một công ty. Codeberg fork Forgejo vào tháng 12 cùng năm, và Forgejo chuyển từ MIT sang GPLv3 ở version 9 vào năm 2024. Cả hai đều được đề cập trong các lựa chọn máy chủ Git tự host, và khác biệt về license là một phần lớn lý do khiến chúng tiếp tục tách hướng phát triển. Trong khi đó, phần lớn free software được phát triển trên GitHub, một nền tảng đóng thuộc sở hữu của Microsoft. Đây là một tranh luận đã có từ lâu, với những lập luận hợp lý ở cả hai phía: xem GitHub thực sự là gì.

Trước khi giao một server cho một dự án, bạn nên dành mười phút để kiểm tra bốn điểm.

• Đọc file LICENSE trong repository, không chỉ đọc trang marketing. Các trang này vẫn tiếp tục nói "open source" rất lâu sau khi file LICENSE không còn xác nhận điều đó.
• Tìm CLA hoặc việc chuyển nhượng copyright. Nếu có, một chủ sở hữu duy nhất có thể thay đổi điều khoản của các bản release sau này.
• Xác định ai nắm copyright: một công ty, nhiều contributor hay một foundation.
• Đếm số maintainer đang hoạt động. Một dự án chỉ có một maintainer là rủi ro đối với chính người đó cũng như đối với bạn.

Không điều nào trong số này có nghĩa là bạn phải tránh phần mềm của một vendor duy nhất. Phần lớn loại phần mềm này rất tốt, và việc có nguồn tài chính thường là lý do duy nhất giúp dự án tiếp tục được duy trì. Các kiểm tra trên cho biết bạn đang phụ thuộc vào điều gì. Khi quyết định điều gì đáng để tự host, hãy đặt license cạnh yêu cầu bộ nhớ trong bảng so sánh.

Bạn có thể đọc một phần lịch sử này ngay trên máy trước mặt mình. Mỗi package trên hệ thống Debian hoặc Ubuntu đều có các điều khoản riêng:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Con số đầu tiên cho biết có bao nhiêu package đã cài có file copyright, thường là vài trăm trên một VPS nhỏ. Lệnh thứ hai in phần đầu file của bash, trong đó nêu GNU General Public License version 3. File bị thiếu nghĩa là package không được build theo policy của Debian. Trường hợp này hiếm gặp và đáng để kiểm tra kỹ lần nữa trước khi bạn tin cậy package đó.

FAQ

Sự khác nhau giữa free software và open source là gì?

Hai khái niệm này bao quát gần như cùng một nhóm licence, nhưng khác nhau về lý do các licence đó quan trọng. “Free software” là thuật ngữ có trước, do Free Software Foundation đưa ra vào năm 1985, với lập luận mang tính đạo đức: người dùng không thể thay đổi chương trình thì không kiểm soát được máy tính. “Open source” được đặt ra vào tháng 02 năm 1998 để giải thích cùng các licence đó dễ hơn cho doanh nghiệp, với lập luận mang tính thực tiễn. Các licence GPL, MIT, BSD và Apache 2.0 đều có trong cả hai danh sách chính thức. Người viết muốn nói đến cả hai khái niệm cùng lúc thường dùng FOSS hoặc FLOSS.

Software có source khả dụng có giống open source không?

Không. Source-available nghĩa là bạn có thể đọc mã nguồn. Theo Open Source Definition, open source còn có nghĩa là licence không được hạn chế đối tượng sử dụng software hoặc mục đích sử dụng. Cả SSPL và Business Source License đều hạn chế việc sử dụng thương mại để cạnh tranh, nên theo định nghĩa này, cả hai đều không phải open source dù đều công khai mã nguồn. Nếu bạn chỉ tự host để dùng riêng, hạn chế đó có thể không ảnh hưởng đến bạn. Nếu muốn xây dựng sản phẩm trên nền tảng đó, trước hết hãy đọc kỹ nội dung licence.

Một công ty có thể thu hồi open source licence đã cấp không?

Không thể thu hồi đối với mã nguồn đã phát hành. Phiên bản đó vẫn chịu licence đi kèm khi được release. Đây chính là lý do các fork như Valkey và OpenTofu có thể bắt đầu từ commit cuối cùng còn được cấp licence permissive. Công ty có thể áp dụng điều khoản mới cho các phiên bản tương lai, nhưng chỉ khi công ty kiểm soát bản quyền của toàn bộ project thông qua việc chuyển nhượng bản quyền hoặc contributor licence agreement. Các project có nhiều chủ sở hữu bản quyền độc lập, trong đó có Linux, không thể bị bất kỳ ai relicence.

Tôi nên tìm licence nào trong software self-hosted?

Đối với software bạn tự chạy và không bán lại, bất kỳ licence nào được OSI phê duyệt như GPL, AGPL, MIT hoặc Apache 2.0 đều cung cấp đầy đủ quyền bạn cần. Kiểm tra hữu ích hơn là xác định ai nắm bản quyền, vì điều đó quyết định các điều khoản sau này có thể bị thay đổi theo hướng bất lợi cho bạn hay không. Một project thuộc về foundation hoặc nhiều contributor độc lập không thể bị relicence trái với quyền lợi của người dùng. Một project do một vendor duy nhất kiểm soát và có contributor licence agreement thì có thể bị relicence. Cả hai đều có thể là software tốt. Chỉ một bên có thể tự thay đổi quy tắc.