Repo công khai trên GitHub chưa chắc là mã nguồn mở

Mã nguồn mở là phần mềm có mã mở công khai đi kèm một giấy phép đạt chuẩn của tổ chức OSI. Giấy phép là văn bản do chủ bản quyền lập ra để nói rõ người nhận được làm gì và cần tuân thủ điều gì.

Nhiều bạn thấy chữ “open source” trong README trên GitHub là yên tâm tải về dùng luôn. Thật ra mở mã cho xem mới là công khai mã, tức chưa có giấy phép chuẩn hoặc bị giấy phép riêng giới hạn.

Ngay trang tuanisme.com bạn đang đọc cũng chạy trên nền WordPress theo giấy phép GPLv2 trở lên. Giao diện tuanisme của web là một theme con dựng trên giao diện Twenty Twenty-Five và cũng khai GPLv2 trở lên.

Nhờ tự làm giao diện web, Tuấn thấy đọc kỹ giấy phép từ đầu giúp mình đỡ lo phạm luật. Bài này sẽ gỡ từng quyền, điều kiện của bốn giấy phép và cách đọc giấy phép trong ba bước nhé.

Bạn nhìn qua ba nấc từ kho mã không giấy phép tới lúc đạt chuẩn nguồn mở ở cạnh đây nha.

1. Mã nguồn mở là gì? Không chỉ là được xem mã

Theo OSI (Open Source Initiative), mở được mã ra đọc chưa đủ để gọi là mã nguồn mở. OSI là tổ chức giữ chuẩn định nghĩa và xét duyệt danh sách giấy phép.

Muốn đạt chuẩn, điều khoản phân phối phải thỏa đủ mười điều trong OSD (Open Source Definition), tức bản định nghĩa gốc của OSI. Bạn nắm ba điều chạm sát việc dùng hằng ngày ở cạnh đây trước nhé.

Trước hết, điều 2 trong định nghĩa của tổ chức OSI yêu cầu chương trình phải kèm mã nguồn. Giấy phép cũng phải mở quyền phân phối cả bản mã nguồn lẫn bản biên dịch.

Tiếp theo, điều 3 yêu cầu giấy phép cho chỉnh mã, làm ra bản sửa và phân phối theo điều khoản bản gốc. Bản sửa là phần mềm được bạn chỉnh lại từ mã người khác.

Chỗ điều 3 này nhiều người hay đọc nhầm nè. Định nghĩa chỉ bắt giấy phép gốc mở quyền cho phép phân phối theo điều khoản cũ, không ép bản sửa mang cùng giấy phép.

Cuối cùng, điều 6 nêu rõ giấy phép không được cấm chạy phần mềm ở ngành nghề nào. Nhờ vậy, không giấy phép nguồn mở nào được cấm bạn đưa phần mềm vào kinh doanh.

1.1 Open source và phần mềm nguồn mở: hai cách gọi một thứ

Vậy chữ “open source” tiếng Anh, “phần mềm nguồn mở” và “mã nguồn mở” có khác nhau không? Cả ba chỉ là cách gọi cùng một khái niệm, nên Tuấn coi cả ba là một nhé.

1.2 Mã nguồn mở nằm ở đâu?

Trên nền tảng lưu kho mã của các dự án, những repo mở công khai thường là nơi lập trình viên đăng phần mềm nguồn mở.

Dù vậy, muốn kho mã thật sự là nguồn mở thì tác giả cần gắn giấy phép. Mở kho mã ra, bạn tìm giấy phép ở hai chỗ trong thư mục gốc nha.

Theo tài liệu GitHub, đa số tác giả lưu nội dung giấy phép vào file LICENSE.txt, LICENSE.md hoặc LICENSE.rst ngay tại thư mục gốc của kho mã. Lúc trợ lý AI của Tuấn kiểm thử kho paperclipai/paperclip, file này còn đặt tên gọn là LICENSE không có đuôi.

Ngoài ra, một vài dự án cũng viết phần giới thiệu giấy phép ngay bên trong file README. Mẹo của Tuấn là dù README có ghi chữ “open source”, mình vẫn mở thẳng file LICENSE ở gốc ra xem mới yên tâm.

2. Ai đặt ra chữ “open source”, ai giữ định nghĩa?

Nhiều bạn tưởng cụm từ này tự nhiên có sẵn từ ngày đầu của ngành máy tính. Thật ra tên gọi, tổ chức giữ chuẩn và bản định nghĩa đều ra đời qua bốn mốc thời gian rõ ràng.

Theo trang lịch sử của tổ chức OSI, chữ “open source” ra đời ngày 03/02/1998 tại buổi họp chiến lược ở Palo Alto, California. Người đề xuất cụm từ này là bà Christine Peterson.

Cuối tháng 02/1998, hai ông Eric Raymond và Bruce Perens đã bắt tay thành lập tổ chức OSI. Đến tháng 10/1999, tổ chức này tung ra bảng danh sách giấy phép đạt chuẩn đầu tiên, rồi năm 2004 thì đưa thêm điều 10 vào OSD.

Nội dung OSD được phát triển từ Bộ nguyên tắc phần mềm tự do của dự án Debian, viết tắt là DFSG. Bản hiện tại là OSD 1.9, được sửa lần cuối vào ngày 22/03/2007.

Tuấn dặn nhỏ một chi tiết kẻo bạn vào trang web của họ rồi nhầm nha. Dòng ngày 16/02/2024 ở đầu trang chỉ là ngày sửa trang web thôi, không phải ngày sửa bản định nghĩa đâu.

3. Giấy phép nguồn mở cho bạn những quyền gì?

Một tờ giấy phép nguồn mở đạt chuẩn OSD sẽ trao quyền để bạn tự do xài, chỉnh sửa và chia sẻ lại chương trình. Tuấn thấy nắm chắc ba quyền này giúp bạn dùng công cụ nào cũng biết rõ mình được làm gì.

Ba nhóm quyền chính bạn nhận được từ một giấy phép đạt chuẩn OSI nằm gọn trong hình bên cạnh.

3.1 Dùng cho mọi việc, cả kinh doanh

Có được đem phần mềm nguồn mở vào việc kinh doanh không? Câu trả lời là hoàn toàn được nha.

Như điều 6 của OSD đã chốt, tờ giấy phép không được chặn việc đem chương trình vào hoạt động thương mại. Trên trang choosealicense, cả bốn cái tên MIT, Apache-2.0, GPL-3.0 lẫn AGPL-3.0 đều bật quyền thương mại “Commercial use”, đi cùng quyền sửa, phân phối và dùng riêng.

Trang tuanisme.com của Tuấn cũng đang dùng phần mềm mang giấy phép GPLv2 trở lên là WordPress. Tuấn cứ thế cài lên máy chủ để vận hành web mỗi ngày mà không cần xin phép ai cả.

3.2 Xem được toàn bộ mã nguồn

Được xem mã thì bạn cầm được gì trong tay? Điều 2 của OSD bắt buộc chương trình phải đi kèm mã và mở quyền phân phối cả bản mã lẫn bản biên dịch.

Nhờ vậy, bạn luôn mở ra xem được phần ruột của chương trình. Sự khác nhau giữa phần mã để sửa với bản đã đóng gói hiện ra rất rõ ở hình cạnh đây.

Tại mục 1 của văn bản GPL-3.0, mã nguồn được hiểu là dạng thuận tiện nhất để người ta vào chỉnh sửa chương trình. Còn mã đối tượng là mọi dạng khác không phải mã nguồn, như bản đã biên dịch xong.

Hôm 20/10/2026, nhóm DeepSeek đã tung bộ mã DeepInfer dưới giấy phép Apache 2.0 như Tuấn từng điểm lại trong bài tin DeepSeek mở mã DeepInfer. Chính Tuấn đã mở mã DeepInfer ra đọc và thấy rất thích vì nhìn thẳng được vào cách tổ chức bên trong.

3.3 Sửa thành bản của riêng bạn, rồi chia sẻ lại

Bạn có được sửa mã thành bản riêng rồi chia sẻ, thậm chí bán lấy tiền không? Điều 3 của OSD yêu cầu tờ giấy phép phải mở quyền chỉnh sửa, làm ra bản sửa rồi đem phân phối theo điều khoản của bản gốc.

Văn bản GPL-3.0 ghi rõ người đưa bản phần mềm đi phân phối được lấy bất kỳ giá nào hoặc không lấy tiền. Người đó cũng được bán riêng dịch vụ hướng dẫn hay bảo hành.

Cách giấy phép GPL đi từ phần mềm lõi sang theme mẫu rồi tới theme riêng của web Tuấn nối theo ba nấc này.

Trên trang tuanisme.com, giao diện tuanisme mà Tuấn dùng là một theme con dựng trên nền giao diện Twenty Twenty-Five của nhóm WordPress. Cả WordPress, theme Twenty Twenty-Five lẫn theme con tuanisme của Tuấn đều khai giấy phép GPLv2 trở lên.

Với Tuấn, việc được dựa trên giao diện chuẩn có sẵn rồi chỉnh lại theo ý mình chính là điểm hay nhất của đồ nguồn mở.

3.4 Đổi lại bạn phải làm gì: MIT, Apache khác GPL, AGPL ở đâu

Khi xài hay sửa mã theo MIT và Apache, tờ giấy phép đòi hỏi nghĩa vụ gì ở mình? Trước tiên, chữ phát hành được hiểu là việc trao bản phần mềm sang tay người khác qua hình thức bán, tặng hay cho tải về.

Trên choosealicense, cả bốn loại đều đòi người nhận giữ lại dòng thông báo bản quyền cùng giấy phép lúc sao chép hay phân phối bản sao. Còn việc tự chạy riêng một mình thì tài liệu không kết luận thêm.

Bạn nhìn bốn hàng ở hình cạnh đây sẽ thấy mức độ điều kiện tăng dần nha.

Ở MIT, yêu cầu duy nhất là giữ dòng bản quyền cùng giấy phép trong mọi bản sao hay phần đáng kể của chương trình. Bản sửa và phần mềm lớn hơn được phát hành theo điều khoản khác không kèm mã.

Với Apache-2.0 mục 4, khi chép và phân phối bản sao dù có sửa hay không, giấy phép bắt đưa bản giấy phép và giữ thông báo bản quyền. Bạn cũng cần ghi rõ ở file đã sửa.

Người đóng góp trao rõ quyền sáng chế, còn bản sửa được phát hành theo điều khoản khác không kèm mã. Người mới lướt qua bảng mã và trang tóm tắt giấy phép MIT kế tiếp.

Nhìn bảng, hai loại đầu thoáng, hai loại cuối thêm điều kiện kèm mã.

3.5 GPL và AGPL: khi nào phải kèm mã

Trong GPL-3.0, “phát hành” hay “convey” chỉ mọi cách giúp người khác tạo hoặc nhận bản sao. Khi phát hành, giấy phép bắt đưa trọn mã nguồn của chương trình lẫn bản sửa cho người nhận, gồm phần mềm lớn hơn dùng nó, dưới cùng giấy phép và ghi đã sửa kèm ngày.

Bạn so hai cột cạnh đây là thấy lúc nào kèm mã nha.

Theo mục 0 và 2 của GPL-3.0, bạn được tạo và tự chạy các bản không đem phát hành mà không vướng điều kiện mở mã. Điều này áp dụng miễn là giấy phép của bạn còn hiệu lực.

Việc chỉ mở tương tác qua mạng máy tính mà không trao bản sao thì không tính là phát hành.

AGPL-3.0 mục 13 siết thêm chỗ qua mạng đó. Khi bạn có sửa mã chương trình, bản sửa bắt buộc tạo cơ hội cho người ở xa tương tác qua mạng lấy được mã nguồn của bản sửa dù không phát hành.

Quay lại WordPress, phần mềm này mang GPLv2 trở lên chứ không phải AGPL. Trên trang giấy phép của WordPress, họ thừa nhận vùng xám pháp lý, nhưng theo ý kiến của họ thì theme và plugin thuộc nhóm bản sửa nên mang GPL.

Kinh nghiệm của Tuấn là định sửa kho mã mở dịch vụ web thì luôn kiểm chữ AGPL trước.

4. Đọc giấy phép một repo trong 3 bước trước khi dùng cho việc kinh doanh

Theo trang tài liệu GitHub về giấy phép repo, thiếu giấy phép thì chịu luật bản quyền mặc định. Khi đó chủ mã giữ trọn quyền, không ai được chép, phân phối hay tạo bản sửa.

Ở kho không có giấy phép, Điều khoản GitHub chỉ cho xem và fork, tức tạo bản sao về tài khoản GitHub của bạn. Có giấy phép nguồn mở thì dùng theo đó, xem ba bước cạnh đây.

4.1 Bước 1: xem tên giấy phép ở trang repo

Lúc vừa mở một kho mã lên, bạn ngó ngay nhãn tên giấy phép nằm ở đầu trang repo.

Tài liệu GitHub giải thích rằng hệ thống dùng thư viện Licensee để đối chiếu file LICENSE với một danh sách ngắn những giấy phép quen thuộc. Sau khi khớp xong, trang web sẽ báo tên giấy phép ở đầu trang repo.

Nếu giấy phép có mặt trên choosealicense nhưng chẳng hiện rõ ở đầu trang repo, kho mã đó có thể đang gộp nhiều giấy phép hoặc trình bày phức tạp. Lúc đó bạn đừng đoán mò mà chuyển sang bước 2 nhé.

4.2 Bước 2: mở file LICENSE, đọc vài dòng đầu

Ở bước hai, bạn bấm mở file giấy phép ở thư mục gốc ngay trên trình duyệt mà không cần tải gì về máy. File này thường đặt tên là LICENSE.txt, LICENSE.md, LICENSE.rst hoặc chữ LICENSE không đuôi.

Chỉ cần đọc vài dòng đầu như kết quả trợ lý AI của Tuấn mở trên ba repo thật ở cạnh đây là biết ngay tên giấy phép.

Lúc trợ lý AI do Tuấn giao việc bấm đọc dòng đầu file LICENSE ở ba kho mã, kho paperclipai/paperclip hiện ngay chữ “MIT License”. Dòng kế dưới ghi rõ bản quyền “Copyright (c) 2025 Paperclip AI”.

Kho heygen-com/hyperframes ghi “Apache License / Version 2.0, January 2004”, còn debpalash/VoiceStudio ghi “GNU AFFERO GENERAL PUBLIC LICENSE / Version 3, 19 November 2007”.

Trong bảng xếp hạng kho mã nổi bật của tháng trên GitHub hôm 21/10/2026 mà trợ lý AI giúp Tuấn quét qua API, VoiceStudio giữ vị trí số 1 với AGPL-3.0. Ngay vị trí số 2 là kho paperclip nhưng lại mang giấy phép MIT.

Hai kho đứng đầu bảng mà giấy phép khác xa nhau, nên Tuấn luôn nhắc bạn tự mở file ra xem.

4.3 Bước 3: tra tên trong danh sách OSI

Khi đã cầm cái tên giấy phép trong tay, làm thế nào để biết chắc nó đạt chuẩn nguồn mở? Bạn đem tên đó dò trên danh sách giấy phép OSI đã duyệt, vì mọi giấy phép ở đó đều đã qua quy trình xét duyệt của OSI.

Tra xong chỉ có hai ngả: có tên trong danh sách là giấy phép nguồn mở, vắng tên hoặc gặp chữ Other thì dừng lại đọc kỹ.

Hôm 27/10/2026, trợ lý AI của Tuấn tự đếm đường dẫn trên trang OSI thì có 126 giấy phép. Gặp tên lạ là Tuấn mở ra tra chứ không đoán, còn người mới chỉ kiểm bằng mắt thì bỏ qua bảng và lệnh API ở cuối mục.

Ai muốn kiểm bằng lệnh thì gọi REST API GitHub lấy nội dung giấy phép:

curl -s https://api.github.com/repos/CHU/REPO/license

Bạn thay CHU, REPO rồi đọc trường license.spdx_id trong kết quả.

4.4 Gặp chữ “Other” thì đọc kỹ giấy phép

Lúc trợ lý AI giúp Tuấn tra API hai kho n8n-io/n8n và open-webui/open-webui, kết quả đều báo NOASSERTION kèm nhãn “Other”, tức GitHub chưa nhận ra tên.

Trên trang giấy phép của n8n, tới 17/03/2022 họ gắn Apache 2.0 kèm Commons Clause, còn nay dùng Sustainable Use License.

Họ ghi bạn chỉ được xài hoặc sửa cho việc nội bộ doanh nghiệp của mình, hoặc mục đích cá nhân, phi thương mại, và chỉ phân phối lại miễn phí cho việc phi thương mại.

Nói gọn, n8n chỉ cho dùng nội bộ hoặc phi thương mại, còn chữ “nguồn mở” thì chính n8n không nhận.

Đội ngũ n8n cũng ghi rõ rằng chuẩn OSI không cho phép giấy phép nguồn mở đặt rào cản lên mục đích sử dụng.

Bởi vậy, n8n không tự gọi mình là mã nguồn mở và có bán giấy phép riêng cho khách doanh nghiệp. Tuấn thấy ai không mở LICENSE.md ra đọc rất dễ tưởng nhầm.

Trang hướng dẫn của GitHub cũng nhắc rằng họ không phải là luật sư và vẫn có lúc nhầm lẫn. Lời khuyên chung là bạn nên tham khảo ý kiến người làm chuyên môn pháp lý trước lúc đem một kho mã đi kinh doanh sản phẩm hay dịch vụ.

5. Mã nguồn mở có miễn phí không?

Chiếu theo điều 1 của OSD, khi chương trình được bán hay tặng trong gói gộp nhiều phần mềm, tờ giấy phép không được phép thu phí bản quyền hay khoản phí nào khác cho lần bán đó.

Quy định này chỉ ràng buộc tờ giấy phép chứ không hề bắt buộc phần mềm phải cho không.

Văn bản GPL-3.0 cũng nói chữ “free” là tự do chứ không phải giá, người phát hành vẫn được lấy giá bất kỳ hoặc bán dịch vụ bảo hành. Vậy khi dùng thật, tiền có thể nằm ở chỗ nào ngoài tờ giấy phép?

Từ đó suy ra, giấy phép không thu tiền bản quyền chẳng đồng nghĩa với việc lúc vận hành bạn không tốn chi phí.

Tự chạy thì cần máy hoặc chỗ đặt web, công cụ gọi dịch vụ hay mô hình thu phí thì trả cho bên đó, hoặc có nơi bán giấy phép riêng cho doanh nghiệp giống n8n.

Ngay như trang tuanisme.com dùng WordPress không mất phí bản quyền, nhưng Tuấn vẫn trả tiền gói reseller hosting của Hawk Host để web chạy mỗi ngày.

6. Mã nguồn mở khác “công khai mã” và phần mềm đóng thế nào?

Để tách rõ một kho mã mở cho xem với phần mềm nguồn mở thật sự, bạn đặt ba nhóm này lên bảng so sánh nhé. Bảng kế tiếp gom quyền bạn được làm và ví dụ từng loại.

Từ bảng trên, bạn thấy nhóm “công khai mã” là chỗ dễ nhầm nhất, như skill docx của Anthropic nè.

Dù kho anthropics/skills mở công khai trên GitHub, file LICENSE.txt của skill docx lại ghi dòng giữ mọi quyền “© 2025 Anthropic, PBC. All rights reserved.”.

Văn bản này quy định việc dùng phải theo thỏa thuận với Anthropic và cấm tạo bản sửa từ tài liệu đó. Bởi vậy, Tuấn luôn dặn bạn cần mở tờ LICENSE ra xem trước khi chép về sửa.

7. Ai nên chọn phần mềm nguồn mở, ai nên cân nhắc?

Vậy khi nào bạn nên chọn phần mềm nguồn mở và khi nào nên cân nhắc? Bạn nên chọn khi muốn tự chạy trên máy mình, muốn xem mã theo điều 2 của OSD hoặc dùng vào kinh doanh nhờ điều 6 không cấm thương mại.

Hai cột tóm tắt ở hình cạnh đây giúp bạn đặt nhanh nhu cầu lên bàn cân trước khi chọn.

Ở chiều cân nhắc, cả tờ giấy phép MIT lẫn mục 15 của GPL-3.0 đều ghi phần mềm được trao nguyên trạng “AS IS”, không bảo hành. Cả bốn giấy phép trên choosealicense cũng đều giới hạn trách nhiệm của tác giả.

Nếu cần bảo hành, bạn chỉ có cách tìm nơi bán gói dịch vụ hay bảo hành riêng theo mục 4 của GPL-3.0.

Bạn cũng cần cân nhắc nếu định sửa mã GPL-3.0 rồi phát hành, hoặc sửa mã AGPL-3.0 rồi mở qua mạng mà ngại kèm mã nguồn của bản sửa.

Theo Tuấn, nếu muốn giữ kín phần mã tự sửa thì bạn đừng chọn nhóm bắt mở mã từ đầu.

8. Câu hỏi thường gặp về mã nguồn mở

Phần cuối bài, Tuấn đáp ngắn gọn bốn câu hỏi mà các bạn mới tìm hiểu mã nguồn mở rất hay hỏi thêm.

8.1 Mã nguồn mở có bản quyền không?

Có, tác giả vẫn giữ bản quyền mặc định với mã của họ chứ không hề bỏ bản quyền. Họ dùng bản quyền đó để cấp quyền cho bạn qua tờ giấy phép, như ba bước nối nhau ở hình cạnh đây.

Ví dụ lúc trợ lý AI giúp Tuấn mở đọc file LICENSE ở kho paperclipai/paperclip, ngay dưới dòng “MIT License” là dòng bản quyền “Copyright (c) 2025 Paperclip AI”.

Tuấn thấy nhờ dòng bản quyền đó mà cả người viết mã lẫn người mang về dùng đều có căn cứ pháp lý rõ ràng.

8.2 GPL là gì?

GPL là giấy phép nguồn mở cho dùng, sửa, chia sẻ nhưng bắt đưa đủ mã nguồn của chương trình lẫn bản sửa cho người nhận theo cùng giấy phép khi phát hành. Lúc nào là phát hành, lúc nào chạy riêng không kèm mã thì bạn xem lại ở mục 3.5 nhé.

8.3 AI mã nguồn mở là gì?

Theo trang định nghĩa của OSI cho AI bản 1.0 năm 2024, một hệ thống AI nguồn mở cần trao đủ bốn quyền. Bốn quyền đó gồm tự do dùng cho mọi việc không cần xin phép, nghiên cứu cách hệ thống chạy, sửa và chia sẻ.

Để người nhận làm được việc sửa đó, bản định nghĩa đòi hỏi hệ thống phải kèm đủ ba thứ ở hình cạnh đây.

Cụ thể, dạng ưu tiên để sửa của hệ thống AI, tính cả “mô hình mở” hay “trọng số mở”, bắt buộc đi kèm đủ ba phần. Đó là thông tin dữ liệu huấn luyện, mã tạo ra tham số cùng chính bộ tham số đó.

Nhờ chuẩn này, mỗi khi thấy một mô hình quảng cáo mở trọng số, Tuấn đều nhìn xem họ có kèm thông tin về dữ liệu huấn luyện, mã và tham số hay không.

8.4 Mã nguồn mở có an toàn không?

Về phía giấy phép, các văn bản như MIT hay GPL-3.0 chỉ ghi phần mềm được trao nguyên trạng “AS IS”, không kèm bảo hành.

Còn chuyện phần mềm nguồn mở nói chung có độ an toàn cao hơn hay thấp hơn phần mềm đóng thì hiện vẫn chưa có nguồn kiểm chứng để kết luận.

Vì tờ giấy phép không cam kết thay cho độ an toàn kỹ thuật, Tuấn khuyên bạn vẫn nên tự kiểm tra kỹ kho mã trước khi cài lên máy nha.

Tóm lại, lần tới thấy chữ “open source” trong README, bạn nhớ kiểm giấy phép theo ba bước trước khi đem vào kinh doanh hay tải bộ cài của dự án về máy nhé.

Bạn đang nhắm thử repo nào trên GitHub mà nhìn tờ giấy phép vẫn còn lăn tăn chưa biết dùng được không? Cứ để lại bình luận cho Tuấn biết nha.