052.1 Bài 1

Phần mềm mã nguồn mở và tự do đã xuất hiện từ khá lâu và các thuật ngữ này thường đi đôi với nhau. Tuy nhiên, có một số khác biệt giữa cái mà một số cá nhân tuyên bố là “phần mềm tự do” và ý nghĩa chính thức của phần mềm tự do cũng như phần mềm mã nguồn mở. Cảnh báo tiết lộ nội dung: “Mã nguồn mở” không chỉ có nghĩa là bất kỳ ai cũng có thể xem mã nguồn — định nghĩa này sẽ là của phần mềm “mã nguồn có sẵn”. Phần mềm mã nguồn mở và tự do có thể làm được nhiều hơn thế.

Phần mềm mã nguồn mở và tự do trái ngược với các loại độc quyền hoặc mã nguồn đóng vì chúng không cung cấp tất cả các quyền tự do sẽ được thảo luận tới trong bài học này.

Có lẽ định nghĩa được trích dẫn nhiều nhất về phần mềm tự do là:

Chúng ta sẽ khám phá những điều thú vị trong tuyên bố trên ở các phần sau.

Một mặt, các nhà phát triển có thể đưa ra một quyết định đơn giản là bỏ qua những phần thưởng cũng như những khó khăn khi bán phần mềm của họ, và chỉ cho đi mà không cần đền bù. Trong tiếng Anh, phần mềm này là “tự do” theo nghĩa là không ai phải trả tiền cho nó mà sẽ tự do như ra vào một công viên công cộng*. Việc phân phối miễn phí này không liên quan gì đến các điều kiện cấp phép bổ sung và sẽ khiến người dùng luôn phải xem xét một cách kỹ lưỡng hơn (chẳng hạn như có thể họ đã không được cấp các quyền cần thiết để thay đổi hoặc tái phân phối phần mềm).

Mặt khác, các nhà phát triển cũng có thể lựa chọn biến phần mềm của họ thành “phần mềm tự do” theo định nghĩa của Stallman. Thuật ngữ này (được ông đặt ra vào những năm 1980) đề cập đến các quyền tự do thiết yếu của người dùng có thể được tóm tắt như sau:

“Phần mềm tự do” trong định nghĩa này được ủng hộ bởi Tổ chức Phần mềm Tự do (FSF) nơi đã đưa ra thuật ngữ copyleft (không có ý nghĩa pháp lý mà thiên về thể hiện sự cân nhắc mang tính triết lý) để mô tả các đặc điểm của giấy phép trên phần mềm tự dọ.

Bên cạnh phong trào phần mềm tự do, cộng đồng những người ủng hộ mã nguồn mở đã nổi lên vào cuối những năm 1990 như một cách làm cho phần mềm tự do trở nên dễ hiểu và phổ biến hơn đối với những người nằm ngoài phong trào. Một tổ chức phi lợi nhuận là Sáng kiến ​​Mã nguồn mở (OSI) đã được thành lập vào năm 1998 và Linus Torvalds - tác giả đầu tiên của hạt nhân Linux - đã ủng hộ khái niệm này. Sáng kiến ​​Mã nguồn mở đã chính thức hóa Định nghĩa Mã nguồn mở bao gồm các tiêu chí sau:

Tổ chức Phần mềm Tự do (FSF) đã không ủng hộ thuật ngữ "mã nguồn mở" và nhấn mạnh rằng nó đã lấp đi mục tiêu chính là tính tự do. Vì vậy, trong khi những người ủng hộ phần mềm tự do và phần mềm mã nguồn mở dường như đang theo đuổi và ủng hộ cùng một khái niệm thì các phong trào lại có những động cơ riêng biệt. Đơn giản mà nói, những người ủng hộ phần mềm tự do nhấn mạnh đến quyền của các nhà phát triển và người dùng, trong khi những người ủng hộ mã nguồn mở lại ưu tiên việc sử dụng rộng rãi cũng như thành công của phần mềm.

Có khá nhiều phần mềm tự do đạt đủ điều kiện để được coi là mã nguồn mở; trong khi đó, có nhiều giấy phép cũng được coi là mã nguồn mở (được OSI phê duyệt) nhưng lại không tự do theo như FSF.

Bởi sự khác biệt giữa các mục tiêu và động cơ liên quan đến mã nguồn mở và tự do nhiều hơn là nội dung của các giấy phép, và vì cả hai thuật ngữ vẫn được sử dụng thường xuyên, nhiều người ủng hộ tham chiếu cả hai định nghĩa này bằng cách sử dụng các cụm từ là FOSS (Free and Open Source Software) hoặc FLOSS (Free/Libre and Open Source Software). Thuật ngữ “libre” được dùng để chỉ sự tự do trong nhóm ngôn ngữ Rôman.

Ngoài các danh mục rộng rãi về FOSS và phần mềm độc quyền, chúng ta còn có một loạt các chiến lược phân phối khác. Một trong số các chiến lược này là:

Điều đầu tiên và quan trọng nhất: Nếu không có sẵn thông tin giấy phép cho một tệp hoặc một dự án mã nguồn nhất định, chúng ta không thể mặc định rằng tệp hoặc dự án đó không được bảo vệ bản quyền. Thực tế thì ngược lại, ít nhất là vì hầu hết các quốc gia trên thế giới đều đã ký kết Công ước Berne kể từ năm 1887.

Trong công ước này, các quốc gia ký kết đã đồng ý rằng một tác phẩm văn học hoặc nghệ thuật sẽ lập tức được bảo vệ bản quyền ngay khi nó bắt đầu tồn tại (hay nói cách khác là ngay khi nó được "định hình" để trở thành một phương tiện). Điều đó có nghĩa là tác giả sẽ không phải đăng ký hoặc xin bản quyền. Họ vẫn có thể làm việc này ở một số quốc gia và việc đăng ký có thể sẽ trở nên cần thiết khi đối mặt với các hành vi vi phạm ở một số khu vực pháp lý bao gồm cả Hoa Kỳ.

Ngoài ra, các bên ký kết đều đồng ý tôn trọng bản quyền của bất kỳ tác giả nào thuộc về một quốc gia ký kết khác; tính đến tháng 11 năm 2022, số lượng các quốc gia này chiếm tới 181 trong tổng số 195 quốc gia trên thế giới.

Tuy nhiên, không phải bất cứ thứ gì được tạo ra cũng đều sẽ được bảo vệ bản quyền. Để đủ điều kiện để được coi là một tác phẩm được bảo vệ bản quyền, nó cần phải đáp ứng một số tiêu chí cơ bản. Ví dụ như các sự kiện và ý tưởng không thể được bảo vệ bản quyền, nhưng một văn bản lý giải một ý tưởng lại có thể được bảo vệ nếu nó đạt đến một mức độ nguyên bản nhất định. Mức độ nguyên bản ở từng nơi trên thế giới có thể sẽ khác nhau, nhưng rào cản bảo hộ sẽ rất thấp trong nhiều trường hợp. Nhiều khu vực pháp lý hiện đang xem xét mức độ mà trí tuệ nhân tạo có thể được sử dụng để tạo ra một tác phẩm xứng đáng với cái được gọi là tính nguyên bản và từ đó cũng xứng đáng được bảo vệ bản quyền.

Tùy thuộc vào khu vực pháp lý, các chương trình máy tính sẽ được bảo vệ quyền dưới dạng các tác phẩm văn học: tức là bản quyền không áp dụng cho ý tưởng hoặc thuật toán mà áp dụng cho việc triển khai của nó trong mã nguồn.

Bản quyền trao cho tác giả các quyền độc quyền (bên cạnh những quyền khác) để sao chép, sửa đổi, cấp phép lại, phân phối và phát hành tác phẩm. Việc tiếp nhận tác phẩm là miễn phí; vì vậy, người ta không cần giấy phép để đọc một cuốn sách hay nghe một bài hát trên radio, miễn là việc đó không yêu cầu phải tạo ra một bản sao vĩnh viễn.

Bởi quyền của tác giả ra đời mà không cần phải đăng ký nên bất kỳ ai muốn sao chép, sửa đổi, cấp phép lại, phân phối hoặc phát hành tác phẩm của tác giả khác đều phải xin phép trước. Đây là nơi các giấy phép phát huy tác dụng như những hợp đồng giữa tác giả của tác phẩm và những người muốn thực hiện một số quyền độc quyền của tác giả.

Giấy phép FOSS có thể được cung cấp cho bất kỳ ai mà không cần trả phí. Bất cứ ai cũng có thể tạo giấy phép của riêng mình và đăng ký để được OSI hoặc FSF phê duyệt. Tuy nhiên, việc sử dụng giấy phép FOSS sẵn có rất được khuyến khích vì nó đã được đại chúng chấp nhận; hơn thế nữa, nội dung của giấy phép và các nghĩa vụ của nó cũng đã trở nên quen thuộc đối với những người sử dụng phần mềm được trang bị đầy đủ kiến thức. Trên thực tế, chỉ một số ít trong số vô vàn các giấy phép được FSF hoặc OSI phê duyệt là được sử dụng phổ biến.

Ngược lại với bản quyền (không bảo vệ các ý tưởng), bằng sáng chế sẽ bảo vệ các phát minh (ý tưởng) mà không (hoặc chưa) cần ý tưởng của chúng phải được "định hình" thông qua máy móc hay các quy trình. Một điểm khác biệt nữa là các nhà phát minh sẽ phải nộp đơn xin cấp bằng sáng chế một cách rõ ràng và đăng ký chúng với cơ quan cấp bằng sáng chế của quốc gia nơi yêu cầu bảo hộ.

Để tránh đi quá sâu vào luật sáng chế và các yêu cầu của nó, chúng ta sẽ chỉ tập trung vào một vấn đề trọng tâm: việc bảo vệ bằng sáng chế yêu cầu (bên cạnh các tiêu chí khác) một ý tưởng có một khía cạnh kỹ thuật nhất định. Từ trước tới nay, những ý tưởng về một công thức nấu ăn mới hoặc một trò chơi cờ bàn (board game) mới không đủ điều kiện để được bảo hộ bằng sáng chế; trong khi đó, các ý tưởng về một chiếc máy nấu ăn mới hoặc một máy chơi trò chơi mới lại có thể có đủ điều kiện để được bảo hộ.

Trong bối cảnh của lập trình máy tính, câu hỏi đặt ra là liệu phần mềm có được bảo hộ bởi bằng sáng chế hay không. Điều này phụ thuộc vào cả vùng pháp lý và các ứng dụng cụ thể. Ví dụ, ở Đức, các chương trình máy tính như vậy thường không được bảo hộ bởi bằng sáng chế. Tuy nhiên, nếu các chương trình được kết hợp với một đối tượng vật lý — ví dụ như khi phần mềm điều khiển hệ thống phanh tự động trong ô tô — thì nó có thể yêu cầu bảo hộ bằng sáng chế cho ứng dụng bao gồm thành phần vật lý của phanh chứ không phải phần mềm và nhờ vậy có thể đạt đủ điều kiện để được bảo hộ.

Ở các khu vực pháp lý khác (chẳng hạn như Hoa Kỳ), bằng sáng chế có thể được cấp cho các chương trình máy tính như vậy, tùy thuộc vào sự phát triển của án lệ.

Khái niệm về bảo hộ với bằng sáng chế cần được ghi nhớ khi thực hiện cấp phép FOSS. Một số giấy phép (chẳng hạn như GPLv3) cho phép cấp bằng sáng chế về phần mềm FOSS bằng cách cấp quyền rõ ràng cho việc sử dụng phần mềm. Ngược lại, một số giấy phép thậm chí còn không đề cập đến các bằng sáng chế (chẳng hạn như giấy phép Điều khoản BSD-3) và các giấy phép khác lại loại trừ chúng một cách rõ ràng (chẳng hạn như các giấy phép Tài sản Sáng tạo Công cộng - Creative Commons). Tuy nhiên, trong một số trường hợp nhất định, việc cấp bằng sáng chế có thể được ám chỉ trong giấy phép hoặc có thể được ghi vào giấy phép.

Đặc biệt là khi xử lý phần mềm nhúng (như phần mềm trong thiết bị âm thanh), chúng ta cần đặc biệt chú ý đến các bằng sáng chế liên quan đến phần mềm (ví dụ như tiến hành kiểm tra bằng sáng chế của tác giả phần mềm).

Như đã đề cập từ trước, giấy phép là hợp đồng giữa tác giả của tác phẩm và người muốn thực hiện một số quyền độc quyền của tác giả. Một số giấy phép FOSS mở rộng hơn (chẳng hạn như Giấy phép Công cộng GNU phiên bản 2 và phiên bản 3) sẽ bao gồm cả các điều khoản về việc chấm dứt hợp đồng. Các giấy phép FOSS luôn bao gồm các khoản cấp quyền liên quan đến các quyền tự do trung tâm. Thông thường, các quyền sau đây sẽ được nêu rõ hoặc có thể được ngầm hiểu trong văn bản giấy phép:

Người quản lý giấy phép là những cá nhân — hoặc trong nhiều trường hợp là các tổ chức (như FSF) — quản lý các phiên bản của giấy phép. Ví dụ: mục 9 của GPLv2 tuyên bố FSF là người quản lý giấy phép:

Một số người quản lý giấy phép cũng sẽ phát hành các câu hỏi thường gặp (FAQs) để giúp trả lời các câu hỏi liên quan đến giấy phép. Những câu hỏi này có thể sẽ rất hữu ích trong việc trao đổi giữa người được cấp phép và người cấp phép.

Khi một nhóm nhà phát triển kết hợp mã từ dự án của người khác vào dự án của riêng họ, kết quả của nó có thể là một sản phẩm dẫn xuất hoặc phái sinh. Các chi tiết khác nhau sẽ tùy theo từng dự án và từ giấy phép này sang giấy phép khác, và bởi vì các chi tiết này đòi hỏi tính tinh vi ở một mức nhất đinh với các kỹ thuật phát triển phần mềm, có thể nói là các nhà phát triển bắt buộc phải đảm bảo rằng phương thức kết hợp mã mà họ sử dụng tuân thủ theo đúng giấy phép.

Vấn đề quan trọng nhất liên quan đến sản phẩm phái sinh là đối với một số giấy phép (như GPL), sản phẩm phái sinh phải được phát hành theo cùng một giấy phép. Những giấy phép như vậy được gọi là giấy phép tương hỗ (reciprocal).

Ý nghĩa thực tế trước mắt của một yêu cầu tương hỗ là ở chỗ, nếu chúng ta sử dụng mã GPL trong dự án của riêng mình theo cách làm cho mã của mình trở thành một nguồn phái sinh, chúng ta sẽ phải tiết lộ mã nguồn của mình và để người khác xây dựng sản phẩm từ đó. Yêu cầu cấp phép này được một số nhà phát triển rất yêu thích bởi họ muốn khuyến khích nhiều người sử dụng giấy phép miễn phí hơn. Tuy nhiên, giấy phép sẽ làm giảm đi sự hấp dẫn của GPL đối với một số nhà phát triển muốn sử dụng mã tự do.

Nhiều giấy phép mã nguồn mở và tự do khác không áp đặt yêu cầu đó. Chúng có xu hướng được gọi là giấy phép linh hoạt (permissive).

Nếu tại thời điểm phân phối các điều kiện cấp phép không được đáp ứng (ví dụ: nếu phần mềm được cấp phép GPLv3 được phân phối dưới dạng nhị phân không kèm theo một mã nguồn), hợp đồng cấp phép sẽ bị vi phạm. Hậu quả của việc vi phạm giấy phép sẽ phụ thuộc vào giấy phép. Ví dụ: vi phạm giấy phép GPLv3 có thể dẫn đến việc chấm dứt giấy phép. Bất kỳ hành động nào khác đều sẽ cần có sự cho phép của tác giả (ví dụ như nếu phân phối phần mềm thì sẽ cấu thành hành vi vi phạm bản quyền).

Nếu một công ty đưa phần mềm được cấp phép GPLv3 vào một sản phẩm và vi phạm giấy phép thì khiếu nại có thể được đưa ra để yêu cầu công ty thu hồi sản phẩm của họ. Việc cố ý vi phạm bản quyền thậm chí có thể dẫn đến các cáo buộc hình sự.

Một số giấy phép sẽ có các điều khoản cụ thể cho phép người được cấp phép khắc phục vi phạm trong vòng 30 ngày kể từ ngày thông báo. Nếu người phân phối phần mềm tuân thủ theo giấy phép trong khoảng thời gian này thì giấy phép sẽ được khôi phục.

Các dự án phần mềm lớn thường bao gồm các phần mềm tuân theo các giấy phép khác nhau, mỗi giấy phép sẽ chỉ rõ các yêu cầu riêng của nó. Những dự án như vậy có thể gặp phải trở ngại khi sử dụng các phần mềm yêu cầu giấy phép của nó được sử dụng trên các sản phẩm phái sinh. Điều này là do các điều khoản cấp phép của các giấy phép copyleft đó có thể sẽ khác nhau dẫn đến việc không tương thích. Việc phát hành hoặc phân phối một dự án phần mềm tích hợp các thành phần theo các giấy phép copyleft khác nhau có thể sẽ không thể thực hiện mà không vi phạm một trong các giấy phép.

Một số giấy phép copyleft sẽ liệt kê rõ ràng các giấy phép tương thích để giúp dễ dàng sử dụng thành phần được cấp phép copyleft theo một giấy phép copyleft khác.

Hầu hết các giấy phép linh hoạt đều sẽ tương thích với các giấy phép khác. Ví dụ: các thành phần được MIT cấp phép có thể được sử dụng trong dự án được cấp phép GPLv3 mà không gặp phải rủi ro vi phạm cấp phép. Tuy nhiên, trong mọi trường hợp, một thành phần được cấp phép GPLv3 sẽ không thể được sử dụng trong dự án được MIT cấp phép mà không vi phạm các điều khoản của GPLv3. Do đó, khả năng tương thích không phải lúc nào cũng sẽ hoạt động theo cả hai chiều.

Trước khi một dự án phần mềm được đưa ra thị trường, các nhà phát triển và cố vấn pháp lý của họ nên tiến hành kiểm tra kỹ lưỡng khả năng tương thích của giấy phép để tránh vi phạm giấy phép. Việc quản lý tuân thủ mã nguồn mở nên được tích hợp vào các giai đoạn đầu của quy trình phát triển phần mềm để tránh sự chậm trễ trong việc phân phối phần mềm (ví dụ như do các vấn đề không tương thích với giấy phép). Hãy nghiên cứu kỹ mã nguồn để tìm các giấy phép hiện hành (ví dụ như bằng cách sử dụng các công cụ quét phần mềm) và kiểm tra xem liệu tất cả các điều kiện cấp phép có được đáp ứng hay không.

Một số phần mềm sẽ có thể có sẵn theo nhiều giấy phép. Ví dụ: người cấp phép có thể chọn cấp phép kép cho dự án của họ theo cả giấy phép copyleft như GPLv3 và một giấy phép độc quyền. Ví dụ: giấy phép độc quyền có thể được yêu cầu nếu người được cấp phép tiềm năng kết hợp mã vào sản phẩm độc quyền của riêng họ. Mỗi nhà phát triển sẽ xác định xem họ có thể tuân thủ các điều kiện GPLv3 hay không hay sẽ phải có giấy phép độc quyền và rất có thể là phải trả phí cấp phép.

Như đã chỉ ra trước đó, một số phần mềm có thể bao gồm các thành phần tuân theo nhiều giấy phép khác nhau với các điều kiện cấp phép khác nhau. Mặc dù hầu hết các giấy phép thường không gây ra tình trạng không tương thích nhưng các giấy phép khác nhau có thể có các yêu cầu khác nhau đối với các phần khác nhau của phần mềm.