052.2 Bài 1

Richard Stallman, khi đó là một nhà phát triển nổi tiếng tại MIT, đã thành lập Dự án GNU vào năm 1983 để phát triển thứ mà ông coi là một hệ điều hành “tự do”. Rất nhanh sau đó mọi người đều nhận ra rằng mã do dự án phát triển phải được bảo vệ về mặt pháp lý để nó không thể bị các nhà cung cấp thương mại chiếm lấy và từ đó trở thành “không tự do”.

Do đó, Stallman đã thành lập tổ chức phi lợi nhuận Tổ chức Phần mềm Tự do (FSF) vào năm 1985. Tổ chức này tóm tắt sứ mệnh của mình trên trang web của họ như sau: “Tổ chức Phần mềm Tự do đang làm việc để đảm bảo quyền tự do cho người dùng máy tính bằng cách thúc đẩy sự phát triển và sử dụng phần mềm và tài liệu tự do…​”

Công cụ trọng yếu đối với sứ mệnh này là một giấy phép một mặt tôn trọng các điều luật hiện hành (đặc biệt là luật bản quyền) và mặt khác thực hiện các ý tưởng tự do của chính nó một cách trong sạch về mặt pháp lý. Kết quả chính là phiên bản đầu tiên của Giấy phép Công cộng Chung GNU (GPLv1) ra đời vào năm 1989. Giấy phép này và nhiều bài viết liên quan — chẳng hạn như “Phần mềm Tự do là gì?” do Stallman viết vào năm 1992 — đã làm rõ động cơ và giá trị của các nhà phát triển phần mềm tự do - những người mà giờ đây cũng tự coi mình là một “phong trào”.

Cốt lõi của lập trình vẫn được hình thành từ “bốn quyền tự do thiết yếu” do Stallman đưa ra trong bài viết nói trên và được đánh số bắt đầu từ 0:

Không giống như giấy phép dành cho các sản phẩm thương mại sẽ đặt ra các hạn chế về việc sử dụng ngay từ đầu, phần mềm tự do hướng tới sự tự do tối đa cho người dùng và các nhà phát triển.

Lời mở đầu của GNU GPLv1 tóm tắt điều này như sau:

Điều này có nghĩa là mọi người đều có quyền sử dụng, phân phối và sửa đổi phần mềm theo GPL mà không bị hạn chế (điều này có thể thực hiện được vì mã nguồn hoàn toàn công khai — hay nói cách khác là “mở”) và lần lượt phân phối các bảnsửa đổi. Thậm chí bạn có thể yêu cầu trả phí khi chuyển nhượng phần mềm:

Nhưng nếu các quyền tự do có phạm vi rộng như vậy thì phần mềm sẽ được bảo vệ theo giấy phép này ở mức độ nào (chẳng hạn như việc kết hợp vào các sản phẩm độc quyền)?

Đây là vai trò của nguyên tắc copyleft đã được đề cập trước đó mà GPL đã áp dụng trong phiên bản 1 ngay cả khi thuật ngữ này chưa được xác định một cách rõ ràng:

Điều này có nghĩa là tất cả các quyền tự do này được liên kết với điều kiện là người dùng phải bảo toàn các quyền tự do này trong mọi việc họ làm đối với phần mềm.

Do đó, Copyleft không chỉ đảm bảo các quyền tự do mà còn yêu cầu mọi người dùng phải cấp các quyền tự do này cho người khác. Điều này có thể đạt được bằng cách quy định rằng phần mềm phải tuân theo giấy phép copyleft (chẳng hạn như GPLv1 đời đầu), chỉ có thể được sửa đổi và tái phân phối nếu các sửa đổi đó được xuất bản dưới cùng các điều kiện - tức là theo cùng một giấy phép.

Do đó, lý tưởng của phần mềm tự do, cụ thể là việc sử dụng chung và phát triển phần mềm xa hơn, được ưu tiên hơn các nhu cầu cá nhân liên quan đến phần mềm. Nguyên tắc có đi có lại rất quan trọng: Những người sử dụng các quyền tự do cũng phải trao đi những quyền tự do đó. Do đó, các giấy phép Copyleft thường được gọi là giấy phép tương hỗ.

Cách tiếp cận hoàn toàn mới này đối với giấy phép phần mềm đã được chứng minh là hợp lý về mặt pháp lý và có thể thực hiện được trong phiên bản 1 của GPL; do đó, GPL chỉ trải qua hai lần sửa đổi lớn trong gần 40 năm phát triển của thị trường CNTT hiện đại.

Với sự gia tăng về khả năng truy cập và tốc độ của Internet, ngày càng có nhiều dịch vụ xuất hiện mà trong đó, phần mềm chỉ được cài đặt trên máy chủ của nhà cung cấp — Nhà cung cấp dịch vụ ứng dụng (ASP) — và khách hàng của họ sẽ tương tác với dịch vụ thông qua internet. Xu hướng này được gọi là Phần mềm dưới dạng dịch vụ (SaaS).

Trong những trường hợp như vậy, GPLv2 đã không cung cấp được một sự rõ ràng về việc liệu mã nguồn (có thể đã được nhà cung cấp sửa đổi) có nên được cung cấp hay không và bằng cách nào. Phiên bản 3 của GPL sẽ lấp được lỗ hổng này — hay còn được gọi là lỗ hổng ASP — bằng cách đề cập rõ ràng đến một giấy phép khác do FSF cấp năm 2007 trong mục 13: Giấy phép Công cộng Chung GNU Affero phiên bản 3 (GNU AGPLv3). Tên này được đặt theo tên của công ty Affero - nơi đã phát triển và xuất bản hai phiên bản đầu tiên của giấy phép này.

AGPLv3 này về cơ bản là tương ứng với GPLv3 nhưng có quy định rõ ràng về vấn đề ASP trong phần “tương tác mạng từ xa”. Hơn nữa, cả hai giấy phép đều nêu rõ rằng chúng có thể được kết hợp với nhau mà không bị hạn chế.

Tóm lại, GNU AGPL là phần bổ sung bổ trợ cho GPL. AGPL mở rộng phạm vi của GPL bằng cách áp dụng copyleft cho phần mềm không còn được sử dụng trong cài đặt cục bộ mà chỉ ở dạng dịch vụ được truyền qua mạng.

Sự phát triển của phần mềm tự do được dựa trên sản phẩm của người khác — tức là tích hợp, sửa đổi và chia sẻ mã nguồn của những người khác. Nếu tất cả các phần của một phần mềm được sửa đổi hoặc mới được biên dịch đều có cùng một giấy phép copyleft (chẳng hạn như là GPLv3) thì điều này có thể thực hiện được mà không gặp bất kỳ vấn đề nào về pháp lý. Giấy phép chỉ đơn giản là yêu cầu kết quả được phân phối theo cùng một giấy phép.

Mọi thứ sẽ trở nên phức tạp hơn khi phần mềm có bao gồm các thành phần được cấp phép theo các giấy phép khác nhau. Chúng ta cần phải tính đến nhiều yếu tố trên phương diện này.

Đôi khi phần mềm tự do được tạo ra trong những điều kiện rất khác biệt. Các thay đổi có thể là từ sửa lỗi đơn giản đến các dự án phức tạp với hàng triệu dòng mã. Bất kể là ở phạm vi nào, chúng ta cũng đều sẽ có sự phân biệt cơ bản giữa hai loại sản phẩm khi nói đến vấn đề cấp phép: phái sinh và kết hợp.

Ví dụ: giả sử dự án phần mềm A bị thiếu một chức năng nhất định. Thay vì tự phát triển chức năng này từ đầu, sẽ hợp lý hơn khi người ta kết hợp mã từ một dự án B khác cung cấp chính xác chức năng này vào với A. Phần mềm từ B thậm chí không cần phải thay đổi cho việc này mà có thể chỉ cần được thêm vào A. Vì lý do này mà nó được gọi là một sản phẩm kết hợp. Nếu cả A và B đều có cùng giấy phép copyleft thì không có vấn đề gì đối với sản phẩm kết hợp này.

Nếu A và B có các giấy phép copyleft khác nhau, chúng ta sẽ cần phải thận trọng: Sự kết hợp giữa A và B đã là một sản phẩm riêng biệt chưa? Và nếu vậy thì nó có thể hoặc phải được cấp phép theo giấy phép nào? Hoặc có thể tránh được xung đột bằng cách đảm bảo rằng cả hai phần A và B vẫn tách biệt với các giấy phép tương ứng của chúng và không cấu thành một sản phẩm mới hay không?

Điều này sẽ càng trở nên khó khăn hơn với các sản phẩm phái sinh — tức là khi dự án A chỉ có thể sử dụng chức năng của B bằng cách đưa trực tiếp mã từ B vào mã của A. Việc tích hợp này sẽ tạo ra một sản phẩm phái sinh mới mà các thành phần của nó không thể tách rời được nữa.

Copyleft sẽ phát huy tác dụng đối với một sản phẩm phái sinh. Ví dụ: nếu A tuân theo giấy phép copyleft như GPLv3 thì sản phẩm phái sinh mới cũng sẽ phải tuân theo giấy phép GPLv3 theo nguyên tắc tương hỗ có qua có lại. Nhưng nếu B có giấy phép khác thì sao? Đây có phải là giấy phép copyleft và nó có tương thích với GPLv3 không? Hoặc, nếu đó là một loại giấy phép khác, B cũng có thể được phát hành theo một giấy phép khác — tức là được cấp lại — hay không? Hay thậm chí giấy phép của A và B liệu có loại trừ lẫn nhau trên phương diện phân loại hay không?

Mục đích của bài học này không phải là để liệt kê các sự kết hợp có thể xảy ra và các giải pháp khả thi. Điều quan trọng ở đây là phải minh họa được mức độ phức tạp của vấn đề xuất phát từ sự kết hợp của nhiều vấn đề rất khác nhau.

Về mặt kỹ thuật, điều đầu tiên chúng ta cần phải làm rõ là cách các thành phần khác nhau của phần mềm (trong ví dụ A và B) hoạt động cùng nhau như thế nào: Chúng có thể tách rời nhau hay có những quy trình mà việc thực thi của chúng không còn có thể được phân công rõ ràng cho phần này hoặc phần kia nữa?

Từ góc độ pháp lý, có nhiều câu hỏi được đặt ra về mối quan hệ giữa giấy phép của A và B. Chúng có tương thích với nhau không hay chỉ tương thích một phần/ một chiều? Có thể chọn cấp lại giấy phép hay không?

Ở đây chúng ta chỉ có thể hiểu sơ qua về mức độ phức tạp của những câu hỏi này chứ không thể giải quyết chúng. Những quyết định như vậy đòi hỏi phải có một nền tàng kiến ​​thức pháp lý vững chắc. Do đó, các quyết định cấp phép cho các sản phẩm mới — đặc biệt là các sản phẩm kết hợp và phái sinh — phải được đưa ra sớm, cẩn thận và luôn luôn là sau khi được tư vấn pháp lý một cách chi tiết.

Copyleft đã được chứng minh là cực kỳ mạnh mẽ trong nhiều thập kỷ qua, đặc biệt là ở dạng GPL trong phiên bản 2 và 3. Tuy nhiên, các yêu cầu kỹ thuật đặc biệt đã thúc đẩy FSF phản ứng bằng cách điều chỉnh các giấy phép của họ. Giấy phép Công cộng Chung GNU Affero là một ví dụ như vậy. Chúng ta sẽ thảo luận về các ví dụ khác trong các phần phụ sau.