Tương Lai Của Nguồn Mở Vào Năm 2026: Cuộc Chiến "Fork" Đang Trở Nên Khốc Liệt

Có gì đó đang bị gãy vỡ trong thế giới nguồn mở (open source). Đó không phải là những dòng code, mà là những hợp đồng xã hội bất thành văn.

Thế giới mã nguồn mở không sụp đổ vì thiếu tiền hay tình trạng kiệt sức của người đóng góp (dù cả hai vấn đề này đều có thật). Nó đang bị chia rẽ bởi chính những tổ chức đã xây dựng đế chế trên phần mềm của cộng đồng, khi họ quyết định rằng thỏa thuận ban đầu không còn phục vụ lợi ích của họ nữa. Các bản fork (nhánh phát triển) đang nhân lên. Giấy phép bị đột biến. Và các luật sư đang sẵn sàng can thiệp.

Những người bảo trì tình nguyện, những người thực sự viết ra phần lớn mã nguồn này? Họ đang mắc kẹt giữa làn đạn.

Vụ Thanh Lọc LibreOffice

The Document Foundation (TDF), tổ chức phi lợi nhuận đứng sau LibreOffice, đã loại bỏ toàn bộ nhân sự của Collabora khỏi quy trình quản trị và phát triển. Hơn 30 nhà phát triển, nhiều người trong số họ đã cống hiến kể từ khi dự án tách từ OpenOffice vào năm 2010, giờ đây đã ra đi.

TDF cho rằng việc này là cần thiết do xung đột lợi ích. Collabora, với tư cách là một công ty thương mại xây dựng sản phẩm dựa trên LibreOffice (đặc biệt là Collabora Online), đã tích lũy một ảnh hưởng quá lớn trong nội bộ tổ chức. Lập luận của TDF là các ưu tiên thương mại của Collabora đang lái dự án đi xa khỏi những gì cộng đồng thực sự cần.

Đó là một mối quan ngại quản trị chính đáng. Tuy nhiên, cách thực hiện lại quá thô bạo, giống như dùng cưa máy thay vì dao mổ phẫu thuật.

Hơn 30 nhà phát triển không chỉ đại diện cho số lượng commit. Họ mang theo những kiến thức thể chế và kinh nghiệm phản biện mất nhiều năm mới tích lũy được. LibreOffice vốn dĩ đã đang mất dần người đóng góp. Việc loại bỏ một lượng lớn nhà phát triển dày dạn kinh nghiệm của một công ty không sửa được vấn đề quản trị; nó tạo ra một khoảng trống phát triển.

Collabora vẫn tiếp tục phát hành Collabora Online. Mã nguồn của họ vẫn dưới giấy phép MPL, vì vậy họ có thể xây dựng bất cứ thứ gì họ muốn. Nhưng mối quan hệ cộng sinh từng khiến cả hai dự án trở nên mạnh mẽ hơn? Đã kết thúc. Và LibreOffice trở nên yếu thế hơn vì điều đó.

Nạn nhân thực sự trong vụ này không phải là một trong hai tổ chức. Đó là những tình nguyện viên độc lập, những người giờ đây có ít người phản biện dày dạn kinh nghiệm hơn cho các bản vá của họ và phải làm việc trong một dự án mà sự liên kết chính trị quan trọng hơn chất lượng mã nguồn.

Euro-Office: Khi Chủ Quyền Số Gặp Luật Giấy Phép

Trong khi LibreOffice tự "ăn mòn" nội bộ, một cuộc chiến khác đang nhen nhóm trong lĩnh vực bộ văn phòng.

Nextcloud và IONOS (nhà cung cấp đám mây và lưu trữ lớn nhất Đức) đã công bố Euro-Office, một bản fork của OnlyOffice nhằm đáp ứng các yêu cầu về chủ quyền số của EU. Lời đề xuất rất rõ ràng: một bộ văn phòng do châu Âu kiểm soát hoàn toàn mà các cơ quan công cộng có thể triển khai mà không cần lưu thông qua hạ tầng của Mỹ hay Trung Quốc.

Chính phủ các nước EU đã thúc đẩy mạnh mẽ chủ quyền số, và các cơ quan công khắp châu Âu muốn tìm giải pháp văn phòng không phụ thuộc vào Microsoft 365 hay Google Workspace. OnlyOffice, với tính năng cộng tác thời gian thực vững chắc, là một nền tảng lý tưởng.

Tuy nhiên, OnlyOffice đã phản ứng gay gắt. Đội ngũ OnlyOffice phản công, cáo buộc Euro-Office vi phạm các điều khoản giấy phép AGPL của họ. Tranh chấp cốt lõi xoay quanh một câu hỏi mà AGPL luôn tạo ra: copyleft (quyền tác giả ngược) yêu cầu chính xác điều gì khi ai đó fork một dự án và bọc một sản phẩm thương mại xung quanh nó? OnlyOffice nói Euro-Office không đáp ứng các nghĩa vụ của họ. Euro-Office khẳng định họ hoàn toàn tuân thủ.

Đây là vấn đề mà không ai ở Brussels muốn nghe: chủ quyền số và cấp phép nguồn mở thường xuyên xung đột nhiều hơn những gì các nhà hoạch định chính sách châu Âu thừa nhận. Fork một dự án để thoát khỏi một sự phụ thuộc có thể tạo ra các ràng buộc pháp lý khó khăn không kém.

EU không thể xây dựng chủ quyền số trên nền tảng của các vụ kiện tụng giấy phép. Đó không phải là chủ quyền. Đó là sự phụ thuộc kèm theo những luật sư.

HashiCorp vs. OpenTofu: Cỗ Máy Pháp Của IBM Can Thiệp

Cuộc chiến giấy phép kéo dài nhất trong chu kỳ này thuộc về Terraform của HashiCorp và bản fork cộng đồng OpenTofu.

Tóm tắt nhanh cho những ai chưa theo dõi: Vào tháng 8 năm 2023, HashiCorp đã chuyển Terraform từ Mozilla Public License 2.0 sang Business Source License 1.1. BSL không phải là giấy phép nguồn mở theo bất kỳ định nghĩa nào. Nó hạn chế sử dụng thương mại bởi các đối thủ cạnh tranh. Cộng đồng đã phản ứng ngay lập tức. Trong vài tuần, OpenTofu được ra mắt dưới sự bảo trợ của Linux Foundation, fork phiên bản cuối cùng của Terraform được cấp phép MPL.

Điều đó xảy ra gần ba năm trước. Áp lực pháp lý chưa hề giảm đi. Nó còn tồi tệ hơn.

HashiCorp (nay thuộc sở hữu của IBM sau thương vụ mua lại trị giá 6,4 tỷ USD) đã tiếp tục theo đuổi các yêu cầu pháp lý đối với người đóng góp OpenTofu, alleging rằng các commit sau fork đã kết hợp mã độc quyền của HashiCorp. OpenTofu phủ nhận điều này hoàn toàn, chỉ ra các quy trình phát triển sạch (clean-room) của họ.

Việc IBM mua lại HashiCorp được kỳ vọng sẽ làm dịu tình hình. Nhưng điều ngược lại đã xảy ra. Một startup có thể dọa kiện tụng. IBM thì không dọa. IBM có một bộ phận pháp lý to bằng một công ty luật tầm trung và lịch sử chiến tranh bằng sáng chế kéo dài hàng thập kỷ.

Tác động làm lạnh là có thể đo lường được. Một số công ty đã âm thầm ngừng đóng góp cho OpenTofu, không phải vì họ nghĩ IBM đúng, mà vì họ không đủ tiền để ra tòa. Đó là mục đích. Bạn không cần thắng một vụ kiện để giết chết một bản fork. Bạn chỉ cần làm cho việc đóng góp trở nên rủi ro.

Trong khi đó, hệ sinh thái Terraform đang bị rạn nứt. Ngày nay cú pháp vẫn giống hệt nhau, nhưng OpenTofu đã bắt đầu thêm các tính năng mà Terraform không có (như mã hóa trạng thái phía client), và Terraform đã thêm các tính năng mà OpenTofu không thể chạm đến mà không gặp rủi ro pháp lý. Các tác giả nhà cung cấp giờ phải duy trì ma trận tương thích. Hai năm sau, đây không còn là một bản fork. Đây là sự ly giáo.

Redis: Ba Lần Thay Đổi Giấy Phép Và Đếm Tiếp

Redis Labs (hiện chỉ là "Redis") đã thực hiện bước đi tương tự vào tháng 3 năm 2024, chuyển từ BSD sang giấy phép kép dưới Redis Source Available License và Server Side Public License. Cái nào cũng không đủ điều kiện là nguồn mở theo định nghĩa của OSI. Thông điệp trùng khớp với HashiCorp: các nhà cung cấp đám mây (như AWS) đang bán dịch vụ Redis được quản lý mà không đóng góp lại, và công ty Redis đã chấm dứt việc trợ cấp cho điều đó.

Đáp lại diễn biến này, Valkey đã được ra mắt như một bản fork dưới Linux Foundation, được sự hỗ trợ bởi AWS, Google Cloud, Oracle và Ericsson.

Điều xảy ra tiếp theo với Redis mới là điểm thú vị. Sau khi lần thay đổi giấy phép ban đầu làm sợ quá nhiều người dùng, Redis đã xoay trục một lần nữa, thêm AGPLv3 như một tùy chọn song song với các giấy phép độc quyền của họ. Elastic cũng đã làm điều tương tự với Elasticsearch sau vụ fork drama tạo ra OpenSearch.

Chiêu bài "quay lại AGPL" này rất đáng chú ý. Các công ty này nhận ra rằng việc chuyển sang hoàn toàn độc quyền đã thiêu rụi quá nhiều thiện chí. AGPL mang lại cho họ nhãn nguồn mở trong khi vẫn khiến cuộc sống của các nhà cung cấp đám mây trở nên khó khăn nếu họ không muốn mở nguồn lớp quản lý của mình. Đó là một sự thỏa hiệp. Nó cũng là một lời thừa nhận rằng lần thay đổi giấy phép ban đầu đã đi quá xa.

Trong khi đó, Valkey tiếp tục phát triển. AWS đã tích hợp nó vào ElastiCache. Nó không còn là một bản fork phản đối nữa. Nó là hạ tầng sản xuất mà các công ty lớn đặt cược vào lớp caching của mình.

Kiểm Tra Rủi Ro Trong Dự Án Của Bạn

Đây là câu hỏi thực tế mà mọi đội ngũ nên đặt ra: những dependency nào của bạn đã thay đổi giấy phép, và cái nào có thể sẽ thay đổi?

Hầu hết các nhà phát triển không kiểm tra. Họ chạy npm install hoặc go get và tiếp tục việc của mình. Nhưng giờ đây đó là một rủi ro.

Đối với các dự án Node.js, bạn có thể kiểm tra mọi giấy phép trong cây dependency bằng một lệnh:

# Cài đặt license-checker toàn cục
npm install -g license-checker

# Chạy kiểm tra dự án
license-checker --summary

# Muốn gắn cờ các giấy phép rủi ro cụ thể? Lọc chúng:
license-checker --failOn "SSPL;BSL-1.1;Elastic-2.0;RSALv2"

# Xuất ra CSV để gửi cho đội pháp lý:
license-checker --csv --out licenses.csv

Đối với các dự án Go:

# Cài đặt go-licenses từ Google
go install github.com/google/go-licenses@latest

# Kiểm tra tất cả các dependency
go-licenses report ./... 2>/dev/null | sort

# Tìm bất cứ thứ gì không phải MIT/BSD/Apache:
go-licenses report ./... 2>/dev/null | grep -v -E "MIT|BSD|Apache"

Các nhà phát triển Python có thể sử dụng pip-licenses:

pip install pip-licenses
pip-licenses --format=table --with-urls

Hãy chạy các lệnh này trong CI (Tích hợp liên tục). Nghiêm túc đấy. Một dependency hôm nay là BSD có thể không còn là BSD vào tháng sau. Những thay đổi giấy phép trong các dependency gián tiếp là thứ sẽ cắn bạn sáu tháng sau này khi bộ phận pháp lý thực hiện cuộc kiểm tra trước khi bán công ty.

Mẹo chuyên nghiệp: Hãy cố định phiên bản dependency (pin versions) VÀ periodically kiểm tra sự khác biệt (diff) của các tệp giấy phép trong tệp khóa (lock file) của bạn. Một lần nâng cấp phiên bản thay đổi chuỗi giấy phép là một dấu hiệu đỏ đáng để điều tra trước khi phát hành.

Kịch Bản Không Ai Muốn Thừa Nhận

Đây là điều kết nối tất cả những câu chuyện này. Các công ty đã xây dựng doanh nghiệp lớn nhất trên nguồn mở đang có hệ thống "kéo thang" lên sau lưng họ.

Mô hình thường thấy:

1. Phát hành dưới giấy phép cho phép (MIT, BSD, Apache, MPL).
2. Xây dựng cộng đồng. Thu hút người đóng góp. Để hệ sinh thái phát triển.
3. Chờ đợi cho đến khi các nhà cung cấp đám mây bắt đầu cung cấp phần mềm của bạn dưới dạng dịch vụ.
4. Thay đổi giấy phép sang cái gì đó hạn chế.
5. Tuyên bố bạn đang "bảo vệ cộng đồng" trong khi thực tế là bảo vệ doanh thu.

Bước 5 là phần thiếu trung thực. Những thay đổi giấy phép này không bảo vệ người đóng góp cộng đồng. Chúng bảo vệ mô hình kinh doanh của công ty. Những người viết mã dưới giấy phép ban đầu không đăng ký để công việc của họ trở thành độc quyền.

Và bước quay lại AGPL sau đó? Đó chỉ là bước 5 với quan hệ công chúng tốt hơn. AGPL là một giấy phép nguồn mở thật, đúng vậy. Nhưng việc chuyển sang nó một cách ngược lại đã thay đổi hợp đồng xã hội đối với mọi người đã đóng góp dưới giấy phép cho phép. Những người đóng góp đó đã chọn BSD hoặc MIT vì một lý do. AGPL là một thỏa thuận hoàn toàn khác.

Số Phận Của Những Tình Nguyện Viên

Những người nhận giao dịch tồi tệ nhất không phải là các công ty. Họ là những cá nhân đóng góp (individual contributors) người bảo trì các gói, xem xét PR, sửa lỗi và viết tài liệu miễn phí.

Khi một dự án bị fork, các maintainer tình nguyện buộc phải chọn phe. Terraform hay OpenTofu? Redis hay Valkey? LibreOffice dưới sự quản trị mới của TDF, hay bất cứ nơi nào các nhà phát triển Collabora đổ bộ tiếp theo?

Mỗi lựa chọn đều mang theo sức nặng nghề nghiệp và mối quan hệ cộng đồng — và đôi khi là rủi ro pháp lý thực sự. Hầu hết các tình nguyện viên không đăng ký cho chính trị. Họ đăng ký để viết phần mềm tốt. Nhưng viết phần mềm tốt trong thế giới nguồn mở năm 2026 có nghĩa là phải né tránh các thay đổi giấy phép, các bản fork của tập đoàn, các cuộc đảo chính quản trị và các đe dọa pháp lý.

Vấn đề kiệt sức (burnout) mà thế giới nguồn mở đã lo lắng trong suốt một thập kỷ qua? Các cuộc chiến giấy phép đã tăng tốc nó. Không gì giết chết động lực của một maintainer nhanh hơn việc nhìn thấy đóng góp của họ trở thành đạn dược trong một tranh chấp pháp lý của công ty mà họ không hề có liên quan.

Tương Lai Của Nguồn Mở

Nếu bạn là người lạc quan, hệ sinh thái fork hoạt động tốt. Khi một công ty "rút thảm" (rug-pull) giấy phép, cộng đồng fork, tìm quản trị mới dưới Linux Foundation hoặc Apache Foundation, và tiếp tục xây dựng. OpenTofu tồn tại. Valkey tồn tại. Mã nguồn sống sót sau sự phản bội của công ty.

Nhưng mỗi lần fork cũng làm phân mảnh hệ sinh thái. Hai phiên bản của Terraform có nghĩa là gánh nặng tài liệu tăng gấp đôi, gánh nặng bảo trì nhà cung cấp tăng gấp đôi, và sự nhầm lẫn tăng gấp đôi cho bất kỳ ai mới bắt đầu với hạ tầng dưới dạng mã (infrastructure-as-code). Và các tranh chấp pháp lý khiến những người đóng góp tiềm năng phải suy nghĩ kỹ hai lần trước khi tham gia.

Thực tế nằm ở giữa hai cực này. Nguồn mở không chết. Nhưng kỷ nguyên mà giấy phép cho phép đồng nghĩa với hợp đồng xã hội vĩnh viễn? Đã hết. Đã chôn vùi dưới một đống chuyển đổi BSL và các bước ngoặt AGPL.

Các công ty chạy nguồn mở trong môi trường sản xuất cần coi rủi ro giấy phép giống như rủi ro nhà cung cấp. Điều gì sẽ xảy ra nếu giấy phép thay đổi vào ngày mai? Fork ở đâu? Ai đứng sau nó? Di chuyển nhanh như thế nào? Những không còn là câu hỏi giả định nữa. Chúng là mối quan tâm vận hành với các mốc thời gian thực.

Và đối với bất kỳ ai bắt đầu một dự án nguồn mở mới vào năm 2026, quyết định về giấy phép mang trọng lượng hơn bao giờ hết. Giấy phép cho phép thu hút người đóng góp nhưng cho phép các vụ "rút thảm". Giấy phép copyleft cung cấp sự bảo vệ nhưng làm sợ các công ty muốn áp dụng. Không có lựa chọn an toàn. Chỉ có những sự đánh đổi với các chế độ thất bại khác nhau.

Kết Luận

Nguồn mở năm 2026 không bị hỏng. Nhưng nó không còn là phong trào thống nhất mà nó đã giả vờ trong hai thập kỷ qua. Còn lại là một tập hợp các lợi ích cạnh tranh được giữ cùng nhau bởi các giấy phép hóa ra lại mơ hồ hơn — và có thể bị vũ khí hóa nhiều hơn — so với những gì bất kỳ ai viết ra chúng từng mong đợi.

Sẽ có nhiều fork hơn. Nhiều thay đổi giấy phép hơn. Và các vụ kiện tụng sẽ không dừng lại.

Nguồn mở sẽ sống sót qua điều này. Nó luôn như vậy. Câu hỏi thực sự là liệu những người thực sự viết mã có sẽ ở lại đủ lâu để bảo trì nó trong khi các tập đoàn tranh giành xem ai được hưởng lợi từ công việc của họ hay không.

Không ai giải quyết phần đó. Và dựa trên những gì đã diễn ra trong năm 2026 đến nay, không ai đang cố gắng cả.