Mã GitHub trong sản phẩm thương mại: giấy phép và những điều cần kiểm tra

Bạn đang xây dựng một sản phẩm và tìm thấy một phần có sẵn trên GitHub: một thư viện, một mẫu, hay cả một dự án làm đúng điều bạn cần. Claude gợi ý đưa nó vào dự án của bạn. Rồi bạn chợt dừng lại: mã có vẻ được công khai, nhưng bạn có thực sự được phép dùng nó, chưa nói đến bán một sản phẩm có chứa mã đó không? Liệu sau này tác giả có thể kiện bạn không?

Tôi sẽ lần lượt giải thích vì sao mã nguồn mở trên GitHub tự nó không đồng nghĩa với việc được cấp phép, giấy phép nào cho phép bạn sử dụng mã và bán sản phẩm, điều kiện copyleft nào có thể đòi mã nguồn tương ứng cho tác phẩm được bao phủ, và cách kiểm tra giấy phép trong một phút trước khi dùng mã. Không có câu trả lời kiểu “còn tùy tình huống”.

Thông tin thực tế về cách làm việc với Ailoot có trong tài liệu hướng dẫn.

Có đúng là nếu mã nằm trên GitHub thì bạn được dùng miễn phí không?#

Cái bẫy chính ở đây là từ “mở”. Bạn có thể xem mã nguồn, nên có vẻ như vì mã không bị che giấu thì bạn được phép sử dụng. Lập luận đó sai. “Mở để đọc” và “được cấp phép sử dụng” là hai chuyện khác nhau.

Theo mặc định, mọi tác phẩm sáng tạo, kể cả mã, đều được bảo vệ bởi bản quyền ngay từ khi được tạo ra. Trừ khi tác giả cấp quyền rõ ràng, bạn không được sử dụng tác phẩm đó. GitHub mô tả điều này trên trang tham khảo về giấy phép của họ.

Lớp thứ hai là chính GitHub. Mọi người nghĩ rằng vì họ đã đồng ý với quy định của GitHub khi đăng mã nên họ cũng có thể dùng mã của người khác ở đó. Quy định nói ngược lại. Khi công khai một kho lưu trữ, tác giả chỉ cho phép người khác xem và fork kho đó — tức là tạo một bản sao ngay trong GitHub. Điều đó không cho phép bạn sử dụng mã trong công việc của mình.

Những từ then chốt nằm ở câu cuối: “trong phạm vi các tính năng của GitHub” và “quyền bổ sung đến từ giấy phép”. Một bản fork vẫn nằm trong GitHub. Ngay khi muốn dùng mã trong sản phẩm của mình, chưa nói đến việc bán sản phẩm đó, bạn cần có giấy phép riêng từ tác giả. Không có giấy phép thì không có quyền — kể cả khi mã nằm ngay trước mắt bạn.

Điều gì quyết định bạn có thể dùng mã của người khác hay không?#

Mọi thứ phụ thuộc vào một tệp. Một kho lưu trữ được duy trì đúng cách có tệp giấy phép — thường là LICENSE, đôi khi là LICENSE.md, hoặc được nhắc trực tiếp trong README. Đây là quyền tác giả cấp, nêu các điều khoản bạn phải tuân theo khi dùng mã. GitHub thường hiển thị tên giấy phép trong thanh bên của trang kho lưu trữ, trước cả khi bạn mở tệp đó.

Để tránh lạc lối trong ngôn ngữ pháp lý, bạn nên đọc giấy phép thông qua ba câu hỏi liên quan đến tình huống của mình:

1. Bạn có thể dùng mã này trong sản phẩm thương mại mà mọi người phải trả tiền để sử dụng không?
2. Bạn có thể sửa đổi mã cho phù hợp với nhu cầu của mình không?
3. Sau đó bạn có phải công khai mã nguồn của sản phẩm không, hay có thể giữ mã ở trạng thái đóng?

Hầu hết khác biệt giữa các giấy phép nằm ở những câu trả lời khác nhau cho câu hỏi thứ ba. Với hai câu đầu, các giấy phép mở phổ biến thường trả lời “có”: dùng, sửa đổi, bán. Nhưng việc giấy phép có buộc bạn công khai mã của mình hay không là chỗ nhiều người vấp phải. Tiếp theo, chúng ta sẽ xem các loại chính dựa trên ba câu hỏi này.

Giấy phép nào cho phép bạn dùng mã và bán sản phẩm?#

Hãy bắt đầu với tin tốt. Với người đang xây dựng sản phẩm để bán, lựa chọn tốt nhất là nhóm giấy phép được gọi là giấy phép dễ dãi. Có một số loại, nhưng ba loại phổ biến nhất là MIT, Apache 2.0 và BSD. Cả ba đều trả lời “có” cho hai câu hỏi đầu và cho phép bạn giữ mã nguồn của mình ở trạng thái đóng.

Loại phổ biến và đơn giản nhất là MIT. Nội dung của nó chỉ gói gọn trong một đoạn văn.

Nói đơn giản, MIT cho phép bạn làm gần như mọi thứ với mã, kể cả bán sản phẩm và giữ mã nguồn của mình ở trạng thái đóng. Nghĩa vụ duy nhất là đưa nội dung giấy phép và dòng ghi nhận tác giả vào sản phẩm. Chẳng hạn, Babel, .NET và Rails được phát hành theo MIT, nên gần như chắc chắn bạn đã dùng mã theo giấy phép này.

Apache 2.0 hoạt động tương tự nhưng bổ sung hai điểm quan trọng. Thứ nhất, giấy phép bảo vệ rõ ràng trước các khiếu nại về bằng sáng chế: tác giả mã cam kết không kiện bạn về bằng sáng chế liên quan đến mã này. Thứ hai, có thêm một số yêu cầu chính thức khi sử dụng.

BSD (phiên bản 2 điều khoản và 3 điều khoản) về cơ bản tương tự MIT: sử dụng, sửa đổi, bán và giữ lại thông báo bản quyền. Tôi đã đưa cả ba vào một bảng để bạn có thể nhìn thấy khác biệt ngay.

Cách áp dụng vào trường hợp của bạn: nếu thấy MIT, Apache 2.0 hoặc BSD trong mã của người khác, bạn có thể yên tâm — bạn được phép dùng mã đó trong sản phẩm thương mại, sửa đổi và giữ mã nguồn của mình ở trạng thái đóng. Chỉ cần đừng xóa tệp giấy phép và thông tin ghi nhận tác giả khỏi phần mã bạn đã lấy.

Nghĩa vụ mã nguồn GPL và AGPL áp dụng thế nào?#

GPL và AGPL cho phép dùng thương mại. Nghĩa vụ nguồn GPL phát sinh khi chuyển giao tác phẩm được bao phủ; chỉ chạy server không chuyển bản sao không phải điều kiện đó. AGPLv3 thêm yêu cầu chào cung cấp nguồn cho người dùng tương tác từ xa với bản đã sửa. Phải xác định tác phẩm kết hợp nào được bao phủ; thành phần riêng, độc lập không tự thành một phần của nó.

Copyleft giữ tác phẩm được bao phủ và bản phái sinh dưới cùng giấy phép khi điều kiện tương ứng áp dụng. Với GPLv3, phân phối bản nguồn hoặc object-code của tác phẩm được bao phủ hay phái sinh kết hợp phải đáp ứng giấy phép và nghĩa vụ mã nguồn tương ứng. Không tự áp cho mọi chương trình độc lập cùng sản phẩm hoặc server.

Ví dụ web service: host thư viện GPL trên server riêng mà không cấp bản sao cho người dùng tự nó không buộc công khai toàn dịch vụ. Phân phối app kết hợp được bao phủ tới khách có thể kích hoạt GPL; kiểm cách tích hợp và giấy phép trước xác định nguồn phải đi kèm. Client trình duyệt giao người dùng là câu hỏi phân phối riêng.

AGPLv3 thêm điều kiện mạng: nếu sửa chương trình và người dùng tương tác từ xa với bản đó, phải chào cung cấp nổi bật mã nguồn tương ứng cho họ. Điều này chính xác hơn nói chỉ host thành phần AGPL là mở mọi phần độc lập của dịch vụ.

Với sản phẩm độc quyền, xem tác phẩm được bao phủ, cách kết hợp, việc phân phối bản sao và tương tác mạng AGPL có áp dụng không. Chọn bản permissive tương thích hoặc xin quyền riêng nếu không đáp ứng được nghĩa vụ. Dùng thương mại tự nó được phép; vấn đề là tuân giấy phép và tích hợp thực.

Bạn nên làm gì nếu kho lưu trữ hoàn toàn không có tệp giấy phép?#

Một sai lầm phổ biến là cho rằng nếu không có giấy phép thì cũng không có hạn chế và bạn được tự do sử dụng mã. Thực tế ngược lại. Không có giấy phép không đồng nghĩa với được phép; theo mặc định, điều đó có nghĩa là không được phép. Mã không có giấy phép vẫn thuộc toàn bộ quyền tác giả của người viết và bạn không được đụng đến.

Quy tắc chúng ta đã bắt đầu cũng áp dụng ở đây: theo mặc định, mã được bảo vệ bởi bản quyền, và nếu không có sự cho phép rõ ràng, bạn không được sao chép, sửa đổi hoặc phân phối mã. Khả năng xem và fork mã trong GitHub không phá vỡ rào cản đó — nó không cấp cho bạn quyền dùng mã trong sản phẩm của mình.

Trong thực tế, nếu mã không có giấy phép nhưng bạn thật sự cần nó, hãy làm như sau:

1. Viết cho tác giả. Liên hệ trực tiếp trong phần thảo luận của kho lưu trữ hoặc qua email, hỏi xem bạn có thể dùng mã không và theo những điều khoản nào. Đôi khi tác giả chỉ quên thêm giấy phép và sẽ bổ sung nếu được đề nghị.
2. Tìm mã thay thế. Với gần như mọi công việc, đều có kho lưu trữ tương tự thứ hai, thứ ba và thứ mười — trong số đó bạn sẽ tìm được một kho có giấy phép MIT hoặc Apache phù hợp.
3. Đừng sử dụng mã đó. Nếu bạn không có quyền và cũng không có mã thay thế, mã đó không thuộc về bạn và bạn không thể đưa nó vào sản phẩm định bán. Ý nghĩ “ai mà biết được?” thường kết thúc tệ đúng lúc sản phẩm bắt đầu sinh lời và thu hút sự chú ý.

Nếu chính Claude thêm mã của người khác vào dự án thì sao?#

Còn có một lớp thứ hai ở đây, và rất dễ nhầm với trường hợp đầu. Một chuyện là bạn vào kho lưu trữ rồi sao chép một tệp từ đó: khi ấy mọi điều ở trên về giấy phép là nghĩa vụ trực tiếp của bạn. Chuyện khác là Claude viết mã cho bạn để đáp ứng một yêu cầu.

Trong những trường hợp thông thường, AI tạo ra văn bản của riêng mình cho nhiệm vụ của bạn thay vì sao chép tệp của người khác. Khi ấy câu hỏi chuyển sang lĩnh vực khác: ai sở hữu mã được tạo ra và bạn có thể bán nó không? Đây là chủ đề lớn riêng biệt, và tôi đã đề cập trong bài viết về ai sở hữu mã do AI viết.

Nhưng có một ngoại lệ cần lưu ý. Đôi khi AI tạo ra một phần mã của người khác dễ nhận ra, gần như từng chữ một — chẳng hạn như toàn bộ một hàm từ thư viện nổi tiếng. Trong trường hợp đó, giấy phép của thư viện vẫn áp dụng, bất kể ai là người thực sự gõ phím. Vì vậy, các khối mã dựng sẵn lớn mà Claude đưa vào nguyên vẹn cần được kiểm tra như thể chính bạn sao chép chúng.

Cách kiểm tra giấy phép trước khi dùng mã: các bước cần làm#

Hãy chuyển tất cả nội dung thành một danh sách kiểm tra ngắn để áp dụng với mọi mã của bên thứ ba trước khi đưa vào dự án. Thực hiện từ trên xuống.

1. Tìm tên giấy phép trên trang kho lưu trữ

   Mở kho lưu trữ trên GitHub. Tên giấy phép thường hiện ở cột bên phải hoặc bên dưới danh sách tệp — chẳng hạn “MIT License”, “Apache-2.0” hoặc “GPL-3.0”. Nếu phần này để trống và không có tệp giấy phép, đó đã là dấu hiệu đáng ngại; hãy quay lại kiểm tra ở bước cuối.

2. Mở chính tệp giấy phép

   Tìm LICENSE, LICENSE.md hoặc COPYING trong danh sách tệp rồi mở. Đảm bảo tên khớp với nội dung hiển thị trong thanh bên và giấy phép áp dụng cho mã bạn đang dùng, chứ không chỉ cho một phần riêng biệt của kho lưu trữ.

3. Xác định loại: dễ dãi hay copyleft

   MIT, Apache 2.0 và BSD là giấy phép dễ dãi; bạn có thể dùng mã trong sản phẩm thương mại đóng. GPL và AGPL là copyleft; kiểm tác phẩm được bao phủ, phân phối và điều kiện mạng AGPL trước xác định nghĩa vụ nguồn. Tên riêng chưa xác lập thành phần độc lập nào bị bao phủ.

4. Đối chiếu với tình huống của bạn

   Trả lời ba câu hỏi: bạn có bán sản phẩm không, bạn có sửa đổi mã không, và bạn có muốn giữ mã nguồn ở trạng thái đóng không? MIT, Apache và BSD phù hợp với sản phẩm đóng để bán. Với GPL/AGPL, xác định tác phẩm được bao phủ hoặc kết hợp cần nguồn tương ứng nào và khi nào nghĩa vụ kích hoạt; đánh giá khả năng đáp ứng.

5. Không có giấy phép thì đừng dùng

   Nếu không có tệp giấy phép và README không nói gì về việc cấp quyền, bạn không được sử dụng mã. Hãy viết cho tác giả để xin phép hoặc tìm mã tương đương có giấy phép phù hợp. “Mã được công khai” không phải là sự cho phép.

Việc kiểm tra này có vẻ phiền phức cho đến lần đầu sản phẩm của bạn phát triển, bắt đầu kiếm tiền và có người hỏi về mã của bên thứ ba bên trong. Dành hai phút lúc đầu sẽ tốn ít hơn xử lý tranh chấp sau này. Tôi đề cập riêng đến việc nên làm gì với sản phẩm sau đó để sản phẩm không bị đình trệ sau khi ra mắt trong bài viết: Tôi đã xây dựng sản phẩm bằng AI; tiếp theo là gì.

Truy cập Ailoot.