giấy phép công cộng chung

Giấy phép Công cộng GNU (GPL) là gì?

Giấy phép Công cộng GNU (thường được gọi là "GPL") là một giấy phép phần mềm mã nguồn mở nổi bật. Giấy phép này yêu cầu rằng bất cứ khi nào mã nguồn được sử dụng, chỉnh sửa hoặc phân phối, mã nguồn đó phải luôn mở và được chia sẻ theo cùng điều khoản giấy phép. GPL là một trong những giấy phép có ảnh hưởng lớn nhất trong hệ sinh thái mã nguồn mở.

Giấy phép mã nguồn mở xác định rõ các điều kiện mà tác giả cho phép người khác sử dụng và chỉnh sửa mã nguồn—tương tự như việc chia sẻ một công thức và cho phép người khác cải tiến. GPL quy định rằng bất kỳ phiên bản cải tiến nào của “công thức” cũng phải được công khai và chia sẻ theo các quy tắc giống hệt nhau. Yêu cầu đối ứng này đảm bảo cộng đồng luôn được hưởng lợi từ các cải tiến liên tục.

Các nguyên tắc cốt lõi của GPL là gì?

Về bản chất, GPL hiện thực hóa khái niệm “copyleft”, được hiểu là “bản quyền đối ứng”: khi bạn sử dụng hoặc chỉnh sửa mã nguồn mở do người khác công khai, bất kỳ việc phân phối thay đổi nào cũng phải được mở và giữ nguyên thông báo bản quyền cùng văn bản giấy phép gốc.

Các nguyên tắc chính bao gồm:

• Công khai mã nguồn: Khi phân phối tệp thực thi, bạn cũng phải cung cấp quyền truy cập mã nguồn tương ứng.
• Duy trì giấy phép: Các sản phẩm phái sinh phải tiếp tục sử dụng GPL.
• Giữ nguyên thông báo: Các tuyên bố bản quyền và giấy phép gốc phải được giữ nguyên vẹn.
• Không bảo hành: Phần mềm được cung cấp “nguyên trạng”, không có bất kỳ đảm bảo nào từ tác giả.
• Điều khoản bằng sáng chế (v3): Phiên bản 3 của GPL bổ sung các biện pháp bảo vệ bằng sáng chế rõ ràng hơn.

Nhân Linux đã lâu sử dụng GPL-2.0 (tính đến năm 2025), trở thành ví dụ điển hình nhất về việc áp dụng GPL.

GPL ảnh hưởng như thế nào đến phát triển Web3?

GPL quyết định liệu bạn có thể phân phối phần mềm sử dụng mã nguồn mở dưới dạng đóng nguồn hay không, hoặc bạn có bắt buộc phải công khai mã nguồn khi phân phối dự án của mình không. Trong lĩnh vực Web3, các nghĩa vụ của GPL có thể áp dụng đối với client node, ví, giao diện frontend và hợp đồng thông minh.

Ví dụ, nếu frontend dApp của bạn tích hợp một thành phần được cấp phép GPL và bạn phân phối bản thực thi cho người dùng, bạn có thể phải công khai mã nguồn frontend và giữ nguyên mọi thông báo gốc. Điều này thúc đẩy sự minh bạch trong hợp tác nhưng có thể hạn chế các mô hình kinh doanh đóng nguồn.

Trên chuỗi, thực hành mã nguồn mở giúp tăng cường khả năng kiểm toán và bảo mật. Nhiều nhóm lựa chọn công khai mã nguồn quan trọng để xây dựng niềm tin, đồng thời cân nhắc kỹ tính tương thích giấy phép với chiến lược sản phẩm.

GPL áp dụng cho hợp đồng thông minh như thế nào?

Hợp đồng thông minh thường được viết bằng Solidity, với giấy phép chỉ định ở đầu tệp thông qua SPDX-License-Identifier (ví dụ: "SPDX-License-Identifier: GPL-3.0-or-later"). Các yêu cầu cấp phép đối ứng của GPL đặt ra một số lưu ý đối với hợp đồng thông minh:

Thứ nhất, Phân phối: Việc biên dịch và triển khai hợp đồng lên chuỗi thường được coi là phân phối công khai. Nếu hợp đồng của bạn bao gồm hoặc chỉnh sửa mã GPL, việc triển khai công khai có thể yêu cầu bạn phải công khai mã nguồn các chỉnh sửa đó. Việc xác định đây có phải là phân phối hay không phụ thuộc vào ngữ cảnh—cần đánh giá trong giai đoạn thiết kế.

Thứ hai, Liên kết và phái sinh: Kế thừa hợp đồng hoặc gọi thư viện thường được xem là tạo ra sản phẩm phái sinh. Nếu bạn kế thừa từ hợp đồng được cấp phép GPL, hợp đồng phân phối của bạn cũng phải tuân thủ cùng giấy phép.

Thứ ba, Thực tiễn phổ biến: Nhiều nhóm chọn giấy phép mở hơn như MIT hoặc Apache cho các hợp đồng cốt lõi nhằm giảm nghĩa vụ về sau. Nếu sử dụng GPL, hãy cung cấp đầy đủ mã nguồn, thông báo bản quyền và hướng dẫn build trong repository để thuận tiện kiểm toán và tái sử dụng.

GPL khác gì so với giấy phép MIT và Apache?

Điểm khác biệt chính giữa GPL, MIT và Apache là mức độ mạnh mẽ của yêu cầu đối ứng.

• MIT: Tương tự như chia sẻ một công thức kèm ghi nhận—rất thoáng, không bắt buộc sản phẩm phái sinh phải dùng cùng giấy phép. Phù hợp cho sản phẩm đóng nguồn hoặc cấp phép kép.
• Apache-2.0: Giống MIT nhưng bổ sung các điều khoản về bằng sáng chế và từ chối trách nhiệm—phù hợp nhu cầu doanh nghiệp.
• GPL: Bắt buộc cấp phép đối ứng, lý tưởng cho dự án muốn cộng đồng liên tục chia sẻ cải tiến; hạn chế hơn với phân phối đóng nguồn.

Tóm lại: Chọn GPL nếu muốn tối đa hợp tác mở và chia sẻ bắt buộc các cải tiến; chọn MIT hoặc Apache để linh hoạt hơn giữa thương mại hóa mở và đóng nguồn.

Tuân thủ GPL trong dự án của bạn như thế nào?

Bước 1: Đặt tệp LICENSE (toàn văn GPL) tại thư mục gốc repository và ghi rõ thông tin giấy phép trong README.

Bước 2: Thêm dòng SPDX-License-Identifier (ví dụ: "SPDX-License-Identifier: GPL-3.0-or-later") ở đầu mỗi tệp mã nguồn để toolchain nhận diện giấy phép.

Bước 3: Giữ nguyên các thông báo bản quyền và giấy phép của tác giả gốc; đánh dấu rõ thay đổi của bạn với ngày, tác giả và tóm tắt.

Bước 4: Cung cấp cách lấy mã nguồn cho mọi tệp thực thi được phân phối—ví dụ, công khai mã nguồn, script build và tài liệu phụ thuộc để đảm bảo khả năng tái tạo.

Bước 5: Kiểm tra tính tương thích giấy phép của các phụ thuộc bên thứ ba; nếu cần, sử dụng LGPL (phù hợp hơn cho thư viện).

Bước 6: Thực hiện rà soát tuân thủ trước khi phát hành; nếu có yếu tố thương mại, hãy tham vấn pháp lý để giảm thiểu rủi ro.

Sự khác biệt giữa các phiên bản GPL là gì?

Các phiên bản chính là v2 và v3:

• v2 (ví dụ: nhân Linux): Phiên bản lâu đời và phổ biến nhất; chưa giải quyết các vấn đề bằng sáng chế hiện đại hoặc khóa thiết bị.
• v3: Tăng cường điều khoản bằng sáng chế, bổ sung chống Tivoization (ngăn thiết bị khóa phiên bản đã chỉnh sửa) và các điều khoản liên quan DRM—phù hợp hơn với kịch bản phân phối hiện đại.

"Or later" so với "Only": Chọn "GPL-3.0-or-later" cho phép bạn áp dụng các phiên bản tương lai để linh hoạt hơn; "only" cố định phiên bản nhằm quản lý tương thích tốt hơn.

Bên cạnh đó, LGPL dành cho thư viện (cho phép liên kết dưới điều kiện mở hơn), còn AGPL mở rộng nghĩa vụ mã nguồn mở cho phần mềm cung cấp qua mạng—dịch vụ backend Web3 và tương tác frontend cần chú ý các kích hoạt AGPL.

Có thể sử dụng GPL cho mục đích thương mại không?

Có—GPL cho phép sử dụng thương mại. Tuy nhiên, khi bạn phân phối sản phẩm phái sinh chứa mã GPL, bạn phải công khai mã nguồn và giữ nguyên mọi thông báo. Các chiến lược doanh nghiệp phổ biến gồm:

• Cấp phép kép: Mã nguồn cốt lõi mở theo GPL đồng thời cung cấp phiên bản thương mại cho khách hàng doanh nghiệp.
• Mô hình dịch vụ: Kiếm doanh thu qua hosting, hỗ trợ, kiểm toán hoặc tích hợp, đồng thời giữ mã nguồn tuân thủ yêu cầu mở (lưu ý nghĩa vụ riêng của AGPL với phần mềm qua mạng).
• Tách biệt thành phần: Cách ly các thành phần buộc phải chia sẻ khỏi logic kinh doanh độc quyền; sử dụng LGPL hoặc giải pháp độc quyền cho thư viện để giảm nghĩa vụ đối ứng.

Những rủi ro và hiểu lầm phổ biến về GPL là gì?

Các hiểu lầm thường gặp bao gồm:

• "GPL không thể dùng cho thương mại"—Sai. Cho phép sử dụng thương mại nhưng phân phối sản phẩm phái sinh sẽ kích hoạt nghĩa vụ mã nguồn mở.
• "Không cần tuân thủ nếu không phân phối"—Chưa đầy đủ. Việc triển khai có được coi là phân phối hay không phụ thuộc vào ngữ cảnh; triển khai on-chain hoặc qua mạng có thể tính là phát hành công khai.
• "GPL có thể tự do trộn với MIT/Apache"—Cần cẩn trọng. Quan hệ phái sinh có thể buộc toàn bộ dự án phải áp dụng GPL; tránh trộn giấy phép không tương thích.
• "Sử dụng nhỏ lẻ sẽ không bị ràng buộc"—Cách tích hợp mã (kế thừa, liên kết tĩnh/động) vẫn có thể tạo sản phẩm phái sinh; cần rà soát tuân thủ.

Rủi ro bao gồm vi phạm bản quyền và tranh chấp tuân thủ, có thể ảnh hưởng đến gọi vốn, niêm yết hoặc hợp tác. Dự án xử lý tài sản hoặc bảo mật hợp đồng nên hoàn thiện thiết kế giấy phép và kiểm toán mã nguồn từ sớm.

Khuyến nghị và tổng kết khi lựa chọn GPL

Nếu mục tiêu của bạn là thúc đẩy hợp tác cộng đồng, đảm bảo các cải tiến được đóng góp lại và duy trì khả năng kiểm toán, GPL là lựa chọn vững chắc. Nếu bạn cần tự do hơn cho mô hình đóng nguồn hoặc cấp phép kép, MIT hoặc Apache sẽ linh hoạt hơn. Đảm bảo nhất quán và truy vết giấy phép cho hợp đồng thông minh và frontend—bao gồm tệp LICENSE và tiêu đề SPDX trong repository, chuẩn hóa đường dẫn phân phối mã nguồn. Lưu ý khác biệt phiên bản, tính tương thích phụ thuộc và liệu tình huống của bạn có phải là phân phối hay phái sinh. Luôn kiểm tra tuân thủ và tham vấn pháp lý trước khi thương mại hóa. Với chiến lược cấp phép rõ ràng, bạn có thể đạt được hợp tác tin cậy và tuân thủ quy định trong hệ sinh thái Web3.

FAQ

Tôi có thể sử dụng trực tiếp mã nguồn GPL trong dự án thương mại không?

Có—nhưng bạn cũng phải công khai mã nguồn sản phẩm phái sinh. Thiết kế “lây lan” của GPL có nghĩa là nếu bạn phát triển sản phẩm dựa trên mã GPL và bán nó, bạn bắt buộc phải công khai mã nguồn theo cùng điều khoản giấy phép. Yêu cầu cốt lõi này khiến GPL không phù hợp với mô hình kinh doanh đóng nguồn. Nếu doanh nghiệp của bạn cần giữ mã riêng tư, hãy cân nhắc sử dụng thư viện cấp phép Apache hoặc MIT.

Rủi ro pháp lý nào nếu tôi tham chiếu hợp đồng thông minh GPL trong dự án Web3?

Rủi ro chính là khả năng bị tác giả gốc kiện vi phạm bản quyền. Dù luật hợp đồng thông minh còn đang phát triển, tòa án ở nhiều quốc gia đã công nhận hiệu lực nghĩa vụ GPL—vi phạm có thể dẫn đến bồi thường. Ngoài ra, nếu bạn muốn gọi vốn hoặc bán lại, nhà đầu tư có thể e ngại rủi ro GPL. Nên tham vấn luật sư từ sớm hoặc chọn giấy phép ít ràng buộc hơn để giảm thiểu rủi ro.

Tại sao nói GPL “lây nhiễm” dự án của tôi?

Đây là cách phổ biến để mô tả hiệu ứng “lây lan” của GPL. Khi bạn đưa mã GPL vào dự án—dù gián tiếp—toàn bộ dự án có thể phải tuân thủ điều khoản GPL (trong một số trường hợp). Với nhà phát triển muốn giữ mã độc quyền, “bị ép mở” này giống như dự án bị “lây nhiễm”. Đây không phải là lỗi mà là chủ ý thiết kế—nhằm bảo vệ nguyên tắc phần mềm tự do.

Nếu dự án của tôi chỉ gọi API của thư viện GPL, có cần mở mã nguồn không?

Tùy vào cách bạn tương tác với thư viện và phiên bản GPL áp dụng. Nếu chỉ gọi API động (ví dụ: gọi dịch vụ ngoài), thường không cần mở mã nguồn dự án. Tuy nhiên, nếu liên kết tĩnh hoặc chỉnh sửa rồi sử dụng mã GPL thì phải công khai mã nguồn dự án theo GPL. Hãy tham vấn luật sư mã nguồn mở để làm rõ thế nào là “sản phẩm phái sinh” và tránh mơ hồ pháp lý.

Điều gì xảy ra nếu tôi sử dụng cả mã GPL và MIT trong một dự án?

Bạn phải tuân thủ cả hai giấy phép—có thể rất phức tạp. GPL bắt buộc mở toàn bộ sản phẩm phái sinh; MIT cho phép đóng nguồn—hai điều này xung đột. Trên thực tế, dự án của bạn phải theo giấy phép “nghiêm ngặt hơn” (GPL) để đảm bảo tương thích. Tránh trộn giấy phép khi có thể hoặc tách rõ module theo loại giấy phép để giảm thách thức tuân thủ.