Các Loại Giấy Phép Phần Mềm Mã Nguồn Mở và Lưu Ý Khi Sử Dụng Cho Mục Đích Thương Mại

Ngày 15/02/2025

Tôi viết này giúp phân tích các loại giấy phép phổ biến và đưa ra những lưu ý quan trọng để tránh rủi ro pháp lý.

1. Phân Loại Giấy Phép Mã Nguồn Mở

Các giấy phép OSS chủ yếu thuộc hai nhóm: Copyleft (bảo hộ) và Permissive (tự do), mỗi loại mang lại quyền lợi và nghĩa vụ khác nhau .

Bảng so sánh nhanh các loại open source licenses

a. Giấy Phép Permissive

• MIT License:
  • Cho phép sử dụng, chỉnh sửa, phân phối mã nguồn mà không hạn chế, kể cả trong phần mềm độc quyền.
  • Yêu cầu duy nhất: Ghi nhận bản quyền gốc và thông báo giấy phép trong sản phẩm .
  • Phải mở:
• Không cần mở mã nguồn của bạn (kể cả khi sửa đổi thư viện MIT).
• Chỉ cần giữ nguyên bản quyền và thông báo giấy phép MIT trong mã nguồn hoặc tài liệu sản phẩm.
• Có thể đóng:
• Toàn bộ mã nguồn mới do bạn viết.
• Ví dụ:
  • Bạn dùng thư viện React (MIT) để xây dựng ứng dụng thương mại → Ứng dụng của bạn có thể đóng hoàn toàn, chỉ cần ghi chú "Sử dụng React, © Facebook" trong file LICENSE.
• Opensource: jQuery, React.
• Apache License 2.0:
  • Tương tự MIT nhưng yêu cầu thêm việc duy trì tệp NOTICE để ghi công tác giả và thông báo thay đổi .
  • Cho phép sử dụng bằng sáng chế và tương thích với các license khác .
  • Phải mở:
• Giữ nguyên file NOTICE của dự án gốc (ghi công tác giả và thay đổi).
• Không cần mở mã nguồn của bạn.
• Có thể đóng:
  • Mọi phần code mới bạn thêm vào, trừ khi bạn sửa đổi trực tiếp code Apache.
• Ví dụ:
  • Bạn tích hợp Apache Kafka vào hệ thống → Hệ thống của bạn có thể đóng, nhưng phải đính kèm file NOTICE của Kafka.
• BSD License:
  • Có hai phiên bản: 2-Clause (đơn giản) và 3-Clause (cấm sử dụng tên tác giả để quảng cáo sản phẩm phái sinh) .

b. Giấy Phép Copyleft

• GNU GPL (General Public License):
  • Yêu cầu mã nguồn phải được công khai khi phân phối sản phẩm phái sinh và áp dụng cùng license gốc .
  • Phiên bản AGPL mở rộng yêu cầu này cho cả phần mềm chạy trên mạng.
  • Phải mở:
• Toàn bộ mã nguồn nếu phần mềm của bạn kết hợp/chạy chung với code GPL (dù là static linking, dynamic linking, hay tích hợp module).
• Không thể tách closed-source: Bạn không được phép giấu mã nguồn phần dùng GPL.
• Ngoại lệ:
  • Nếu phần mềm của bạn giao tiếp qua API hoặc CLI (không chia sẻ chung codebase) → Có thể đóng mã nguồn.
• Ví dụ:
  • Bạn dùng thư viện GPL trong ứng dụng → Toàn bộ ứng dụng phải mở theo GPL.
• Bạn viết plugin cho WordPress (GPL) → Plugin phải mở theo GPL.
• Opensource: Linux, GIMP.
• Mozilla Public License (MPL):
  • Ít nghiêm ngặt hơn GPL, chỉ yêu cầu công khai mã nguồn của các tệp được sửa đổi .
  • Phải mở:
    • Chỉ các file mã nguồn được sửa đổi trực tiếp từ code MPL.
  • Có thể đóng:
    • Các file mã nguồn mới không dựa trên code MPL.
  • Ví dụ:
    • Bạn dùng thư viện MPL trong dự án → Chỉ file MPL đã sửa phải mở, phần còn lại có thể đóng.
• LGPL (Lesser GPL)
  • Phải mở:
• Chỉ phần code LGPL (nếu bạn sửa đổi nó).
• Có thể đóng:
• Phần mã nguồn của bạn, nếu chỉ liên kết động (dynamic linking) với thư viện LGPL.
• Ví dụ:
  • Bạn dùng thư viện LGPL (ví dụ: FFmpeg) trong ứng dụng → Ứng dụng của bạn có thể đóng, nhưng phải cho phép người dùng thay thế thư viện LGPL bằng phiên bản sửa đổi.
• AGPL (Affero GPL)
  • Phải mở:
    • Toàn bộ mã nguồn nếu bạn chạy phần mềm dưới dạng dịch vụ mạng (SaaS), kể cả không phân phối mã.
  • Ví dụ:
    • Bạn xây dựng SaaS dùng MongoDB (AGPL) → Phải công khai mã nguồn toàn bộ hệ thống.
• LGPL (Lesser GPL)
  • Phải mở:
    • Chỉ phần code LGPL (nếu bạn sửa đổi nó).
  • Có thể đóng:
    • Phần mã nguồn của bạn, nếu chỉ liên kết động (dynamic linking) với thư viện LGPL.
  • Ví dụ:
    • Bạn dùng thư viện LGPL (ví dụ: FFmpeg) trong ứng dụng → Ứng dụng của bạn có thể đóng, nhưng phải cho phép người dùng thay thế thư viện LGPL bằng phiên bản sửa đổi.

2. Lưu Ý Khi Sử Dụng OSS Cho Mục Đích Thương Mại

a. Tuân Thủ Điều Khoản Giấy Phép

• Kiểm Tra Tính Tương Thích:
  • Nếu sử dụng mã nguồn GPL, toàn bộ sản phẩm phái sinh phải tuân theo GPL. Trong khi đó, MIT hay Apache cho phép kết hợp với mã độc quyền .
  • Ví dụ: Dùng thư viện GPL trong phần mềm độc quyền sẽ vi phạm license .
• Tránh Sử Dụng Mã Không Có Giấy Phép:
  • Mã không có license mặc định thuộc bản quyền tác giả, việc sử dụng có thể dẫn đến kiện tụng .

b. Quản Lý Rủi Ro Pháp Lý

• Kiểm Tra Các Thư Viện Phụ Thuộc:
  • Công cụ như Snyk giúp quét và báo cáo license của các thành phần phụ thuộc .
• Thận Trọng Với Bằng Sáng Chế:
  • Một số license như Apache 2.0 hoặc GPLv3 có điều khoản cấp quyền sử dụng bằng sáng chế, nhưng cũng có thể thu hồi nếu người dùng kiện tụng .

c. Lựa Chọn Mô Hình Kinh Doanh Phù Hợp

• Dual Licensing:
  • Phát hành sản phẩm dưới hai license: Một phiên bản mã nguồn mở và một phiên bản thương mại.
  • Ví dụ: MySQL của Oracle .
• Open Core:
  • Cung cấp phiên bản cơ bản miễn phí và bán các tính năng cao cấp.
• SaaS (Software as a Service):
  • Kiếm tiền từ dịch vụ lưu trữ đám mây, như MongoDB Atlas .

Cách Tách Phần Mềm Để Tối Ưu Open/Close Source

Kiến Trúc Microservices hoặc Modular

• Tách biệt các thành phần dùng license khác nhau:
  • Ví dụ:
    • Module A (dùng GPL) → Phải mở toàn bộ Module A.
    • Module B (dùng MIT) → Có thể đóng.
    • Module C (tự viết, không dùng OSS) → Đóng hoàn toàn.
• Sử dụng API Gateway
  • Tương tác qua API/REST:
    • Dịch vụ dùng AGPL chạy độc lập → Các dịch vụ khác gọi API có thể đóng nguồn.

4. Lưu Ý Quan Trọng

1. Copyleft "lây nhiễm" toàn bộ nếu code được tích hợp trực tiếp (ví dụ: GPL trong cùng repo code).
2. Tách biệt vật lý (khác repo, giao tiếp qua network) giúp tránh lây nhiễm.
3. Luôn kiểm tra license của tất cả dependencies (kể cả nested dependencies) bằng tools như:
   • FOSSA
   • Black Duck

5. Một Số Dự Án Thực Tế

• React của Facebook: Ban đầu dùng BSD-3 + điều khoản bằng sáng chế, sau chuyển sang MIT để tăng tính mở .
• Red Hat: Thành công với mô hình hỗ trợ kỹ thuật cho hệ điều hành mã nguồn mở .
• Spotify: Dùng Apache Kafka (Apache 2.0) → Đóng mã nguồn hệ thống, chỉ giữ file NOTICE.
• Tesla: Sử dụng Linux (GPL) → Mở toàn bộ mã kernel modifications, nhưng đóng mã phần mềm xe.

Kết Luận

Việc lựa chọn giấy phép phù hợp và hiểu rõ nghĩa vụ pháp lý là chìa khóa để tận dụng OSS trong thương mại. Doanh nghiệp cần:

1. Đọc kỹ điều khoản license trước khi tích hợp mã nguồn.
2. Sử dụng công cụ quản lý để đảm bảo tuân thủ.
3. Lựa chọn mô hình kinh doanh linh hoạt như SaaS hoặc Dual Licensing.

"Mã nguồn mở không chỉ là công cụ miễn phí—nó là nền tảng cho sự đổi mới nếu được áp dụng đúng cách."

Tài Liệu Tham Khảo:

• Viblo - Các điểm lưu ý về OSS
• Snyk - So sánh giấy phép
• GitHub Guide - Hướng dẫn cấp phép