agpl giải thích: nghĩa vụ khi triển khai nội bộ

Bạn phát hiện mã AGPL có vẻ hữu ích, nhưng chưa chắc rõ điều đó nghĩa là gì khi chạy trong công ty. Mối băn khoăn thực dụng: liệu bạn có bị buộc phải công bố mã riêng tư, phơi bày hệ thống nội bộ, hay mở ra rủi ro pháp lý nếu sửa phần mềm và dùng nó sau tường lửa? Hướng dẫn này loại bỏ ngôn ngữ pháp lý phức tạp và trình bày, ở mức kỹ thuật, AGPL (GNU Affero General Public License) thực sự buộc một công ty triển khai mã như thế nào khi chạy nội bộ.

Tổng quan nhanh: AGPL là gì và khác GPL thế nào

AGPL là GPL của GNU có thêm điều khoản mạng. GPLv3 điều chỉnh việc phân phối nhị phân: nếu bạn phân phối chương trình đã sửa, bạn phải cung cấp mã nguồn tương ứng. AGPLv3 thêm mục 13: nếu bạn chạy một chương trình AGPL đã sửa và để người khác tương tác với nó qua mạng, những người dùng từ xa đó cũng phải được truy cập mã nguồn cho phiên bản đã sửa đó. Tóm lại: việc sử dụng qua mạng kích hoạt nghĩa vụ cung cấp mã tương tự như khi phân phối theo GPL.

Khi nào AGPL áp dụng trong công ty

Câu hỏi then chốt là ai được tính là "user" theo AGPL. Giấy phép không phân biệt khách hàng công cộng với nhân viên: bất kỳ ai tương tác với chương trình thuộc AGPL qua mạng đều là user được hưởng quyền truy cập mã. Vậy có ba kịch bản nội bộ điển hình cần phân biệt:

• Triển khai chỉ nội bộ, chỉ truy cập bởi nhân viên phía sau tường lửa công ty: nghĩa vụ AGPL áp dụng cho các nhân viên-user đó — bạn phải cung cấp cho họ mã nguồn tương ứng với phiên bản đang chạy và bất kỳ sửa đổi nào.
• Triển khai theo kiểu SaaS hoặc dịch vụ hướng tới khách hàng: nếu khách hàng bên ngoài tương tác với dịch vụ của bạn, bạn phải làm mã nguồn có sẵn cho những khách hàng đó (đăng công khai thường là cách đáp ứng).
• Sử dụng hoàn toàn ngoại tuyến (không có giao diện mạng): nếu chương trình chỉ chạy cục bộ trên máy không có tương tác mạng, điều khoản mạng của AGPL không bị kích hoạt ngoài các kích hoạt phân phối theo GPL bình thường.

Điều quan trọng: "sử dụng nội bộ" không tự động có nghĩa là "không có nghĩa vụ." Nếu nhân viên hoặc nhà thầu sử dụng dịch vụ, họ là user theo AGPL và được hưởng mã nguồn. Ngược lại, nghĩa vụ AGPL bắt buộc công bố lên Internet chỉ phát sinh nếu những user đó là bên ngoài (khách hàng, bên thứ ba) hoặc bạn chọn thỏa mãn yêu cầu bằng cách làm mã nguồn có thể truy cập công khai.

Bạn thực sự phải cung cấp gì cho người dùng

Khi AGPL bị kích hoạt, các nghĩa vụ thực tế là cụ thể. Bạn phải cung cấp "Complete Corresponding Source" cho chính xác phiên bản chương trình bạn đang chạy. Thông thường điều này bao gồm:

• Cây mã nguồn đầy đủ cho chương trình, bao gồm mọi sửa đổi bạn đã thực hiện.
• Script build, file cấu hình, script đóng gói, và mọi hướng dẫn cài đặt/triển khai cần thiết để tái tạo nhị phân đang chạy.
• Mọi script hoặc mã nguồn cần thiết để tạo hoặc lấy các thành phần không phải mã nguồn nhưng nằm trong hệ thống triển khai (ví dụ: mã dùng trong quá trình build container).
• Bảo toàn thông báo bản quyền, header license, và các file AUTHORS/NOTICE giống như trong dự án nguồn.

Lời đề nghị có thể được đưa trực tiếp tới những user tương tác với chương trình. Trên thực tế các tổ chức thường đáp ứng bằng cách đặt một liên kết rõ ràng trong giao diện ứng dụng hoặc trang About dẫn tới một tarball hoặc snapshot repository git và một README đọc được bằng người giải thích các bước build và deploy. AGPL không quy định một định dạng URL hay nhà cung cấp hosting duy nhất, nhưng nguồn phải có thể truy cập được bởi những user có quyền theo một dạng hữu dụng.

"Cung cấp mã" không có nghĩa là gì (và những hiểu lầm thường gặp)

Một số việc AGPL không tự động bắt bạn phải làm:

• Nó không yêu cầu bạn công bố các dịch vụ độc quyền hoặc cấu hình không liên quan tới chương trình AGPL. Chỉ chương trình và mã nguồn tương ứng của nó mới bắt buộc.
• Nó không đòi hỏi phải công bố liên tục lịch sử phát triển; điều quan trọng là cung cấp mã nguồn chính xác được dùng để chạy dịch vụ (mặc dù nhiều đội công bố tag VCS hoặc hash commit để rõ ràng).
• Nó không tự động buộc phải công bố thông tin xác thực, khóa riêng tư, hoặc bí mật. Những thứ đó không phải là "mã nguồn" và bạn nên loại bỏ hoặc không bao gồm bí mật trong bất kỳ kho lưu trữ công bố nào. (Nếu bí mật cần thiết để build một bản phân phối có thể hoạt động, hãy ghi tài liệu các placeholder và nguồn bí mật dự kiến thay vì nhúng bí mật.)

Cách tuân thủ — danh sách kiểm tra thực tế cho đội kỹ thuật

Khi bạn triển khai mã AGPL (đã sửa hoặc chưa sửa), hãy làm theo các bước sau để duy trì tuân thủ và tránh bất ngờ:

• Kiểm kê: ghi lại nơi sử dụng các thành phần AGPL, có bị sửa hay không, và ai sử dụng từng dịch vụ (nhân viên, nhà thầu, khách hàng).
• Phiên bản và hash commit: gắn tag commit chính xác hoặc ID build bạn đang chạy. Hiển thị định danh đó trong UI (ví dụ, trang About) để mã nguồn bạn công bố có thể khớp với instance đang chạy.
• Công bố mã nguồn tương ứng: cung cấp một kho lưu trữ có thể tải xuống hoặc snapshot git chỉ đọc bao gồm script build, Dockerfile, và manifest triển khai cần thiết để tái tạo chương trình đang chạy.
• Đảm bảo người có quyền có thể truy cập mã nguồn: với dịch vụ hướng tới khách hàng, dùng URL công khai liên kết từ giao diện. Với dịch vụ nội bộ, git nội bộ hoặc kho artifact truy cập được bởi nhân viên thường là đủ.
• Bảo toàn thông báo: giữ nguyên header bản quyền và license từ upstream và thêm ghi chú đóng góp của bạn cho các sửa đổi.
• Tránh nhúng bí mật: làm sạch khóa riêng, token, mật khẩu, và địa chỉ mạng nội bộ khỏi mọi kho lưu trữ công bố.
• Đào tạo đội hỗ trợ và pháp chế: đảm bảo kỹ sư hỗ trợ biết cách phản hồi yêu cầu mã nguồn và có URL sẵn; thông báo cho đội pháp chế nơi các thành phần AGPL được sử dụng.

Ví dụ: một liên kết "Source" tối thiểu hiển thị ở chân trang ứng dụng
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (full source)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions to reproduce container)

Kết hợp mã AGPL với module độc quyền — rủi ro hay gặp

Một trong những câu hỏi thực tế khó nhất là khi nào mã độc quyền của bạn giao tiếp với phần mềm AGPL thì bị ràng buộc bởi AGPL. Giấy phép áp dụng cho chương trình và các tác phẩm phái sinh. Không có quy tắc rõ ràng trong giấy phép nói rằng "liên kết theo cách X là an toàn." Các nguyên tắc kỹ thuật được chấp nhận là:

• Các tiến trình tách biệt giao tiếp qua các giao thức mạng chuẩn, định nghĩa rõ (HTTP, gRPC, SMTP, v.v.) ít có khả năng bị coi là một chương trình hợp nhất. Nếu thành phần độc quyền của bạn là một dịch vụ tách biệt dùng thành phần AGPL qua REST API, nhiều người hành nghề coi đó là tách biệt an toàn — nhưng điều này không đảm bảo và phụ thuộc vào mức độ phụ thuộc chặt chẽ và thiết kế của hai phần.
• Liên kết thư viện trực tiếp vào nhị phân, sử dụng API trong tiến trình, hoặc phát hành một phân phối đơn khối là rủi ro: tổ hợp đó có khả năng cao bị cho là tác phẩm phái sinh và kích hoạt nghĩa vụ cung cấp mã.
• Plugin hoặc module được tải vào tiến trình AGPL là nguy hiểm nếu chúng không tách biệt rõ ràng; một số dự án dùng ranh giới IPC ổn định, được kiểm toán để giảm rủi ro.

Đây là các câu hỏi pháp lý có nhiều sắc thái thực tế. Khi nghi ngờ, tham khảo ý kiến pháp lý và cân nhắc các biện pháp kỹ thuật như tách thành dịch vụ, dùng lựa chọn có giấy phép cho phép hơn, hoặc thương lượng giấy phép thương mại từ upstream.

Tùy chọn kinh doanh: cấp phép thương mại, cấp phép kép, và lựa chọn vận hành

Các dự án mã nguồn mở dùng AGPL thường cung cấp giấy phép thương mại hoặc mô hình cấp phép kép: bạn có thể tuân thủ nghĩa vụ AGPL hoặc mua giấy phép độc quyền để loại bỏ yêu cầu cung cấp mã qua mạng. Mô hình này phổ biến cho các dự án muốn bảo vệ giá trị phía server trong khi vẫn cho phép sử dụng miễn phí theo AGPL.

Về mặt vận hành, bạn có ba con đường thực tế khi gặp phụ thuộc AGPL:

• Tuân thủ: công bố mã nguồn cho những user có quyền theo danh sách kiểm tra ở trên. Thường là con đường rẻ nhất cho công cụ nội bộ và triển khai nhỏ.
• Thương lượng giấy phép thương mại: trả upstream để có giấy phép độc quyền nếu bạn cần giữ sửa đổi kín hoặc tránh nghĩa vụ AGPL.
• Thay thế thành phần: dùng lựa chọn có giấy phép cho phép hơn hoặc phần mềm độc quyền nếu thay đổi giấy phép không khả thi.

Nếu sản phẩm của bạn là dịch vụ truy cập từ xa hoặc desktop từ xa, hãy cân nhắc xem thành phần AGPL chỉ ảnh hưởng tới client hay cả mã server/relay của bạn. Với nhiều triển khai, sử dụng dịch vụ relay được quản lý giảm gánh nặng vận hành và tuân thủ; Tenvo là relay được quản lý do chúng tôi vận hành (máy chủ ở Đức) và là khuyến nghị mặc định của chúng tôi cho các nhóm muốn một relay được quản lý đơn giản, không có gánh nặng tự lưu trữ. Nếu tuân thủ bắt buộc phải có hạ tầng tại chỗ (ví dụ có yêu cầu bằng văn bản cấm hạ tầng bên thứ ba), thì tự lưu trữ là lựa chọn đúng — hãy cân nhắc tự lưu trữ RustDesk, nhưng tính cả chi phí duy trì liên tục, gia hạn chứng chỉ và kế hoạch chuyển đổi dự phòng trước khi chọn phương án đó.

Chỉ nội bộ so với công bố công cộng — phân biệt quan trọng

Hai điểm cuối cùng thường gây nhầm lẫn:

• Công bố chỉ nội bộ cho nhân viên đáp ứng AGPL cho những user đó. Nếu bạn giữ mã nguồn có sẵn trong mạng nội bộ công ty để nhân viên dùng dịch vụ có thể lấy nó, bạn đã đáp ứng nghĩa vụ cốt lõi cho user nội bộ. AGPL không tự động yêu cầu bạn công bố sửa đổi lên Internet công cộng trừ khi user có quyền bao gồm khách hàng bên ngoài và bạn chọn thỏa mãn yêu cầu của họ bằng cách đăng công khai.
• Công bố mã nguồn công khai thường là con đường tuân thủ đơn giản nhất cho dịch vụ hướng tới khách hàng vì tránh công việc phân phối theo từng khách hàng và thể hiện thiện chí. Nó cũng phù hợp với kỳ vọng của nhiều dự án upstream, nhưng đồng thời nghĩa là sửa đổi của bạn có thể bị đối thủ nhìn thấy.

Khi nào cần tự lưu trữ hoặc các sắp xếp đặc biệt khác

Tự lưu trữ phù hợp khi có yêu cầu bằng văn bản cấm phụ thuộc vào cơ sở hạ tầng bên thứ ba (quy định về nơi lưu trữ dữ liệu, mạng được phân loại, hoặc nghĩa vụ hợp đồng). Nếu không, tùy chọn managed relay / cơ sở hạ tầng được quản lý thường tốn ít hơn về mặt thực tế khi bạn cộng chi phí on-call, vá lỗi, giữ chứng chỉ TLS, và dự phòng vận hành. Chúng tôi bàn sâu hơn về các đánh đổi này trong Self hosting hidden costs và trong bài lớn hơn của chúng tôi về Open source business model: why AGPL works for SaaS.

Ví dụ thực tế và phần FAQ ngắn

• Q: Nếu tôi sửa mã AGPL và chỉ đội ops của tôi dùng, tôi có phải công bố không? A: Có — đội ops của bạn là user. Làm mã nguồn có sẵn nội bộ.
• Q: Nếu tôi cung cấp dịch vụ có backend AGPL cho khách hàng, tôi có phải công bố công khai không? A: Bạn phải cung cấp mã nguồn tương ứng cho những khách hàng đó. Đăng công khai là phương pháp chuẩn để đáp ứng yêu cầu đó.
• Q: Tôi có thể giữ cấu hình và bí mật ở dạng đóng không? A: Bí mật không phải là "mã nguồn" theo giấy phép. Loại bỏ bí mật khỏi kho lưu trữ công bố và ghi tài liệu các đầu vào bí mật mong đợi thay vào đó.
• Q: Có đủ để chỉ trỏ tới upstream nếu tôi đã sửa cục bộ không? A: Không. Bạn phải cung cấp mã nguồn cho phiên bản cụ thể bạn chạy, bao gồm các thay đổi của bạn.

Nếu bạn muốn một ví dụ thực tế về tự lưu trữ một ngăn xếp remote desktop mã nguồn mở và các bước build chính xác để duy trì tuân thủ, xem hướng dẫn Self-hosted remote desktop của chúng tôi và tutorial Docker cho RustDesk trong RustDesk self-hosted setup để tham khảo cơ chế có thể tái sử dụng.

Tuân thủ AGPL là cơ học: xác định user, đóng băng revision đang chạy, tập hợp complete corresponding source và hướng dẫn build, và làm cho nó có thể truy cập bởi những user đó. Phần khó là quản trị và kiến trúc: quyết định có tách các thành phần, thương lượng giấy phép, hay chấp nhận việc sửa đổi bị công khai.

Nếu bạn đang triển khai hạ tầng truy cập từ xa và muốn tránh tự chạy và công bố một relay riêng, relay được quản lý của Tenvo là mặc định thực dụng: ứng dụng khách gốc cho Windows, macOS và Linux, ứng dụng khách trên trình duyệt ở bản beta công khai, relay được quản lý với máy chủ ở Đức và các gói từ Free $0 đến Lite $2.99/tháng và Pro $7.99/tháng. Tự lưu trữ chỉ nên dùng khi có yêu cầu bằng văn bản bắt buộc: nếu không, tùy chọn managed thường rẻ hơn khi tính cả on-call, vá lỗi, lưu trữ khóa và yêu cầu dự phòng.

Các câu hỏi cần độ chắc chắn pháp lý — biên giới của tác phẩm phái sinh, giải thích kiến trúc plugin cụ thể, hoặc thương lượng hợp đồng — là vấn đề pháp lý. Bài viết này nhằm làm rõ bức tranh kỹ thuật để bạn có thể ra quyết định thông minh và có cuộc trao đổi hợp lý với counsel.

Khi bạn sẵn sàng thử managed relay và giữ chi phí vận hành ở mức thấp, tải Tenvo và trải nghiệm mô hình triển khai cùng UI: Tải Tenvo.