Xem thêm

Hướng dẫn cách chọn và sử dụng giấy phép cho dự án mã nguồn mở trên GitHub

CEO Hùng PV
Bạn đã từng tạo một kho lưu trữ trên GitHub, và bạn đã thấy cuộc hội thoại tạo kho lưu trữ này. Ở cuối cuộc hội thoại đó, bạn thấy dòng "Chọn giấy phép của...

Bạn đã từng tạo một kho lưu trữ trên GitHub, và bạn đã thấy cuộc hội thoại tạo kho lưu trữ này. Ở cuối cuộc hội thoại đó, bạn thấy dòng "Chọn giấy phép của bạn". Dường như việc này rất quan trọng, vì nó được đặt ngay trong cuộc hội thoại tạo kho lưu trữ. Nhưng giấy phép là gì và tại sao bạn cần phải chọn một giấy phép?

Giấy phép là một phần cơ bản của việc phát triển phần mềm mã nguồn mở (Open Source Software - OSS). Nếu không có giấy phép đính kèm, dự án phần mềm của bạn không có ý nghĩa, bởi vì không có giấy phép thì không ai có thể sử dụng nó thực sự - chúng ta sẽ tìm hiểu vì sao ở phần sau.

Chúng ta đã nghe rất nhiều về thuật ngữ Mở nguồn (Open Source) và nhiều người cũng đã gặp thuật ngữ Giấy phép Mở nguồn (Open Source License), nhưng điều này thực sự có nghĩa gì, cách chúng hoạt động và tại sao bạn, một nhà phát triển OSS, nên quan tâm đến điều này vẫn là một dấu hỏi đối với nhiều người. Bài viết này mong muốn giúp làm rõ vấn đề này một chút.

Trước khi chúng ta đi vào chi tiết về việc cấp phép OSS, tôi muốn lưu ý rằng tôi không phải là một luật sư mà chỉ là một nhà phát triển Phần mềm Mở nguồn với gần hai thập kỷ kinh nghiệm. Tất cả những gì tôi sẽ giải thích ở đây là hiểu biết của riêng tôi và không thành lập một lời khuyên pháp lý trong bất kỳ hình thức nào. Tôi cũng sẽ đơn giản hóa một số điều và không đi vào sự phân biệt giữa Phần mềm Miễn phí và Mở nguồn hoặc triết lý đằng sau Phong trào Phần mềm Miễn phí. Mục tiêu của bài viết này là đưa ra một giới thiệu ngắn gọn về giấy phép phần mềm mã nguồn mở và giúp xóa đi một số hiểu lầm phổ biến chung - không hơn, không kém. Phew! Với sự miễn trừ trên, chúng ta hãy bắt đầu.

Open Source là gì?

Nhiều người nghĩ rằng Mở nguồn đơn giản chỉ có nghĩa là mã nguồn của một dự án có sẵn, nhưng điều này chỉ nói một phần của câu chuyện.

Tổ chức Open Source Initiative (OSI) cung cấp một định nghĩa được chấp nhận chung về những gì cấu thành Mở nguồn. Tóm tắt lại, để được coi là Mở nguồn,

  • Công việc phải cho phép "phân phối miễn phí",
  • Mã nguồn phải được công khai,
  • Có thể tạo ra các công việc khác dựa trên nó,
  • Không giới hạn việc ai có thể sử dụng công việc đó hoặc vì mục đích gì (vì vậy điều kiện như "không sử dụng thương mại" hoặc "không sử dụng với mục đích quân sự" không được chấp nhận trong Mở nguồn),
  • Công việc không cần phải có một giấy phép bổ sung trên cơ sở của giấy phép ban đầu nó đi kèm,
  • Và cuối cùng, giấy phép không phụ thuộc vào định dạng phân phối cụ thể, công nghệ hoặc sự hiện diện của các công việc khác.

Vì vậy, bạn có thể thấy rằng nó vượt ra ngoài khái niệm "mã nguồn có sẵn", thực sự có nhiều yêu cầu khác nữa phải được đáp ứng để công việc được coi thực sự là Mở nguồn.

Tuy nhiên, lưu ý rằng nó không nói đến "phải miễn phí" ở bất kỳ đâu. Một sự hiểu lầm phổ biến là OSS không được phép có chi phí hoặc bạn không được phép kiếm tiền từ việc tạo ra nó. Điều đó là không đúng, và thuật ngữ Phần mềm Miễn phí thường được gặp cùng với Mở nguồn thường được chú trọng là "miễn phí như lời nói, không miễn phí như bia" để làm rõ sự khác biệt này rõ ràng. Dịch vụ thương mại xây dựng trên OSS là hoàn toàn hợp lệ, và việc bán OSS cũng vậy, miễn là giấy phép được tuân thủ và mã nguồn được cung cấp kèm theo.

Giấy phép là gì và tại sao tôi cần một giấy phép?

Bất kỳ công việc mà bạn tạo ra khi mặc định làm cho bạn trở thành chủ sở hữu bản quyền của nó. Điều đó có nghĩa là chỉ có riêng bạn được phép phân phối những gì bạn đã tạo ra. Nếu bạn muốn chuyển quyền này cho những người khác, bạn có thể làm điều đó thông qua một giấy phép gọi là "giấy phép". Hãy hiểu giấy phép như một tập hợp các quy tắc xác định cách người khác có thể sử dụng, phân phối, sửa đổi và tương tác với công việc bạn đã tạo ra, và theo những điều kiện nào.

Hãy tưởng tượng rằng bạn đã viết một công cụ phần mềm và bạn muốn lưu trữ mã nguồn của nó trên GitHub. Nếu không có giấy phép đính kèm, mọi người có thể xem nó và fork nó (vì cả hai điều đó được cho phép thông qua Điều khoản Dịch vụ của GitHub), nhưng họ không thể sử dụng nó trong các dự án của riêng họ, sửa đổi nó hoặc làm bất kỳ việc khác nào khác với nó. Bạn là người duy nhất sở hữu bản quyền độc quyền.

Tuy nhiên, bằng cách thêm một giấy phép vào đó, bạn có thể mở rộng những gì có thể làm với mã của bạn và - nếu bạn muốn - với một số nghĩa vụ cụ thể. Ví dụ, bạn có thể thêm một giấy phép người dùng có thể sửa đổi hoặc xây dựng công cụ của bạn miễn là họ chia sẻ phiên bản tương quan của họ với mã nguồn cũng như. Hoặc bạn có thể thêm một giấy phép cho phép mọi người tự do sử dụng, phân phối và sửa đổi mã của bạn, nhưng chỉ nếu họ giữ tên của bạn. Và quan trọng nhất có lẽ là bạn có thể (và nên) thêm một giấy phép chỉ cho phép sử dụng mã của bạn nếu những người sử dụng mã của bạn công nhận rằng không có sự đảm bảo về tính chính xác hoặc chức năng kèm theo nó, không có bảo hành và không có trách nhiệm, điều đó có nghĩa là bạn không thể bị kiện tụng về thiệt hại nếu có điều gì đó trong mã của bạn gây ra hậu quả cho ai đó.

Vì vậy, để tóm lại, một giấy phép cho phép bạn định nghĩa các quyền và nghĩa vụ bổ sung liên quan đến công việc của bạn vượt ra ngoài bản quyền độc quyền mà bạn sở hữu và nó có thể bảo vệ bạn.

Có những lựa chọn giấy phép nào?

Rất may, bạn không cần phải viết giấy phép của riêng bạn (và thực sự, bạn không nên làm điều đó, vì sẽ có rủi ro). Có nhiều giấy phép đã có sẵn cho bạn để lựa chọn, và tôi sẽ giới thiệu cho bạn một số giấy phép phổ biến nhất.

Vui lòng lưu ý rằng tôi sẽ tập trung vào giấy phép phần mềm mã nguồn mở ở đây, vì những giấy phép đáp ứng Định nghĩa Mở nguồn của OSI, vì đó cũng là những gì tôi khuyên bạn hạn chế chính mình khi chọn một giấy phép cho dự án OSS mới. Tuy nhiên, tôi sẽ cũng tóm tắt ngắn gọn về giấy phép Creative Commons, vì chúng thường được gặp trong các dự án phần cứng, và một số giấy phép Public Domain, vì chúng thường được gặp trong thực tế.

Giấy phép "Copyleft": GPL, AGPL, LGPL

Nhớ lại khi tôi nói rằng bạn có thể yêu cầu bất kỳ ai sửa đổi công việc của bạn chia sẻ mã nguồn của nó cũng? Việc tuân thủ các điều kiện tương tự thường được đề cập đến là "được lây nhiễm" và thành viên phổ biến nhất của gia đình giấy phép mã nguồn mở lây nhiễm này là giấy phép copyleft GPL, AGPL và LGPL.

GPL, hoặc GNU Public License, là lây nhiễm (vì vậy các công việc phái sinh phải được phân phối theo các điều kiện tương thích), loại bỏ bất kỳ yêu sách bảo hành nào (vì vậy bạn không thể bị kiện), và nêu rõ rằng bất kỳ hình thức xác nhận nào ("viết bởi J. Random Hacker") phải được giữ nguyên. Giấy phép này và những người anh em của nó được OSI chấp thuận và do đó việc sử dụng thương mại không phải là vấn đề.

AGPL, hoặc Affero GNU Public License, mở rộng về điều khoản lây nhiễm sao cho ngay cả khi phái sinh chỉ được truy cập thông qua một kết nối mạng, mã nguồn của chúng phải được cung cấp dựa trên các điều kiện tương thích.

LGPL, hoặc Lesser GNU Public License, ngược lại một chút về mức độ lây nhiễm, nêu rõ rằng phái sinh chỉ đính kèm với công việc không cần chia sẻ theo cùng các điều kiện giấy phép. Điều này là một chủ đề gây tranh cãi khá nhiều, nhưng nói chung ý tưởng ở đây là miễn là công việc của bạn chỉ được sử dụng như một thư viện và không được xây dựng trực tiếp, điều khoản lây nhiễm sẽ không được kích hoạt.

Giấy phép cho phép: MIT, BSD, Apache, ...

Nếu triết lý lây nhiễm không phù hợp với bạn vì bất kỳ lý do nào, có một nhóm giấy phép mã nguồn mở khá tự do mà không lây nhiễm nhưng vẫn cung cấp sự xác nhận và bảo vệ khỏi trách nhiệm.

MIT, BSD và giấy phép Apache khá giống nhau. Tất cả đều yêu cầu phải giữ nguyên thông tin xác nhận, bảo hành và trách nhiệm hoàn toàn bị loại bỏ và - vì được chấp thuận bởi OSI - việc sử dụng thương mại hoàn toàn không phải là vấn đề. Sự khác biệt giữa các thành viên trong gia đình này nằm ở việc cho phép yêu sách về sở hữu công nghệ và việc sử dụng nhãn hàng. Ác quỷ ở đây thực sự nằm trong chi tiết, vì vậy hãy chú ý kỹ khi chọn giữa các giấy phép tự do khác nhau. Để so sánh nhanh chóng, tôi gợi ý xem các giấy phép trên tldrlegal.com.

Creative Commons

Nếu bạn quan tâm đến phát triển phần cứng, bạn có thể gặp các giấy phép Creative Commons. Creative Commons tương tự như một miễn chọn phiên của giấy phép - bạn có một giấy phép cơ bản loại bỏ yêu sách bảo hành, và các module khác nhau mà bạn cũng có thể đính kèm nếu bạn muốn:

  • BY: yêu cầu người tác giả được nêu rõ.
  • SA: bất kỳ phái sinh nào phải "chia sẻ tương tự", nghĩa là theo các điều kiện giấy phép tương tự - đây là module lây nhiễm.
  • NC: sử dụng thương mại bị cấm - nếu module này được đính kèm, giấy phép không còn được coi là Mở nguồn theo định nghĩa của OSI.
  • ND: phái sinh bị cấm - nếu module này được đính kèm, giấy phép cũng không còn được coi là Mở nguồn theo định nghĩa của OSI.

Như bạn có thể thấy, Creative Commons có thể gây rắc rối khi nó liên quan đến khả năng tương thích Mở nguồn. Miễn là bạn tránh các module "NC" và "ND", công việc của bạn vẫn nên được coi là Mở nguồn theo định nghĩa, nhưng vì giấy phép không được chính OSI chấp thuận, bạn có thể gặp vấn đề tương thích với bất kỳ thứ gì bạn phụ thuộc vào, hoặc làm công việc của bạn trở nên khó khăn để tiếp tục xây dựng.

Public Domain, CC0, Unlicense, ...

Có thể xảy ra rằng bạn cũng gặp phần mềm đã được công bố vào [Public Domain]](/images/blog/admin/2024/02/16/search-code-repositories-users-issues-pull-requests-1708088569.webp), nghĩa là tất cả các yêu sách bản quyền đã bị từ bỏ. Khái niệm này dường như rất hấp dẫn với những người thực sự chỉ muốn tự do cho mã của họ và không quan tâm tới việc diễn ra gì với nó.

Nên lưu ý rằng mặc dù điều này có vẻ là một khái niệm khá quyến rũ ban đầu, nhưng lại có một điểm bất lợi rất lớn: không miễn trách nhiệm bảo hành. Bạn thực sự không muốn tự làm mình trở nên dễ tổn thương đối với những đe dọa pháp lý chỉ vì đã viết một số mã nguồn gây ra vấn đề cho ai đó do một lỗi, vì vậy nếu bạn muốn theo đuổi con đường này, đề xuất của tôi ít nhất là xem xét một số thứ như [Unlicense]](/images/blog/admin/2024/02/16/search-code-repositories-users-issues-pull-requests-1708088569.webp) bởi nó ít nhất chứa sự cho phép không bảo hành và bảo vệ bạn khỏi trách nhiệm.

Vậy làm thế nào để cấp phép cho dự án mã nguồn mở của tôi?

Tùy thuộc vào việc dự án của bạn là độc lập hay xây dựng dựa trên công việc của người khác, có những điều cần xem xét khác nhau.

Nếu bạn đang tạo một dự án độc lập, bạn có thể tự do quyết định về giấy phép. Nhìn vào các dự án khác trong cộng đồng phát triển của bạn, hoặc các dự án tương tự, và xem họ đã chọn giấy phép nào. Hãy đảm bảo bạn hiểu rõ giấy phép bạn dự định sử dụng và bạn cảm thấy "thoải mái" về nó. Nếu bạn ghê tởm ý nghĩ rằng có ai đó có thể lấy mã của bạn, xây dựng một cái gì đó mới trên nó và không chia sẻ mã nguồn của cái đó, một giấy phép tự do có thể không phải là lựa chọn tốt nhất và một giấy phép copyleft lây nhiễm như GPL có thể phù hợp hơn với bạn. Nếu ngược lại bạn chỉ muốn mọi người có thể làm bất cứ điều gì với mã của bạn, miễn là tên của bạn vẫn ở đó và bạn không bị kiện vì nó, bạn có thể muốn xem xét một giấy phép như MIT. Hãy xem tại choosealicense.com nếu bạn cần một bàn tay trợ giúp.

Nếu bạn đang xây dựng dự án dựa trên công việc của người khác, thì điều này trở nên phức tạp hơn một chút. Bạn cần kiểm tra và hiểu rõ giấy phép của họ, và cũng hiểu rằng bạn sẽ bị hạn chế vào một cái gì đó tương thích trong sự lựa chọn của riêng mình. Nếu bạn xây dựng dự án dựa trên một công việc được cấp phép theo GPL, hãy ghi nhớ về tính lây nhiễm. Nếu bạn xây dựng dự án dựa trên một công việc được cấp phép theo giấy phép Creative Commons, hãy cực kỳ cẩn thận, bạn có thể không thậm chí được phép xây dựng trên nó, tùy thuộc vào phiên bản. Đối với GPL cụ thể, có một danh sách tương thích hữu ích mà bạn có thể tham khảo.

Bất kể dự án của bạn là độc lập hay bạn đang xây dựng dựa trên công việc của người khác, tôi không thể nhấn mặt đủ về tầm quan trọng hiểu rõ và cảm thấy thoải mái với giấy phép bạn chọn cho mã của mình. Nếu đến một lúc bạn nhận ra rằng bạn hối tiếc vì quyết định của mình, bạn sẽ thấy rằng việc thay đổi giấy phép của các phiên bản tương lai của công việc của bạn có những thách thức riêng (và đơn giản là không thể với các phiên bản đã phát hành). Bất kỳ ai đó đóng góp vào dự án của bạn làm như vậy dưới giấy phép bạn đã nêu ra. Họ cung cấp cho bạn quyền truy cập vào các công việc bản quyền của riêng họ dựa trên các điều kiện của giấy phép của dự án của bạn - ngay cả khi chỉ là sửa một lỗi chính tả. Bạn không thể thay đổi giấy phép của toàn bộ mã nguồn nếu bạn không phải là người duy nhất sở hữu bản quyền, bạn cần xin ý kiến từ tất cả mọi người đã đóng góp. Tùy thuộc vào lịch sử và quy mô của dự án của bạn, điều đó có thể khó khăn đối với việc không thể thực hiện. Do đó, tôi mạnh mẽ khuyến nghị hiểu rõ giấy phép và đảm bảo bạn cảm thấy thoải mái với nó.

Khi bạn đã chọn giấy phép mong muốn của mình, sao chép nó vào tệp LICENSE.txt trong thư mục gốc của dự án (GitHub thông thường cũng phát hiện điều này và hiển thị một tóm tắt giấy phép nhỏ trên kho lưu trữ của bạn - rất đẹp!). Hãy ghi chú nó trong tệp README của dự án của bạn. Bạn cũng có thể muốn thêm một tiêu đề giấy phép vào các tệp nguồn của dự án của bạn. Tóm lại, hãy tạo điều kiện cho ai đó có bản sao mã của bạn có thể hiểu giấy phép dễ dàng.

Bạn đã hoàn thành tất cả những điều đó chưa? Xin chúc mừng, bạn đã cấp phép cho dự án của mình!

Kết luận

Nếu bạn không đặt giấy phép cho mã nguồn của mình, quyền bản quyền độc quyền của bạn sẽ áp dụng và không ai thực sự có thể sử dụng mã của bạn. Có một số lượng lớn các giấy phép có sẵn để lựa chọn, và trước khi quyết định một, bạn nên đảm bảo bạn hiểu nó, thoải mái với nó và cũng không gặp phải bất kỳ vấn đề tương thích nào với những thứ bạn phụ thuộc vào. Tốt nhất nên tuân thủ các giấy phép đã được chứng minh, nổi tiếng và đã được chứng minh thay vì những giấy phép tối nghĩa hơn, và đừng bao giờ thử viết giấy phép riêng của bạn.

Chúc bạn viết mã vui vẻ!

Đọc thêm

1