EULA
Thỏa thuận người dùng cuối hay end-user license agreement (EULA) là hợp đồng pháp lý được ký kết giữa nhà phát triển phần mềm hoặc nhà cung cấp và người dùng phần mềm, thường là nơi người dùng đã mua phần mềm từ một trung gian như nhà bán lẻ. EULA chỉ định chi tiết các quyền và hạn chế áp dụng cho việc sử dụng phần mềm.[1]
Nhiều biểu mẫu hợp đồng chỉ được lưu ở dạng kỹ thuật số và chỉ được trình bày cho người dùng dưới dạng click-through mà người dùng phải "chấp nhận". Vì người dùng có thể không thấy thỏa thuận cho đến khi họ đã mua phần mềm, các tài liệu này có thể là hợp đồng đồng thuận.
Các công ty phần mềm thường đưa ra các thỏa thuận đặc biệt với các doanh nghiệp lớn và các tổ chức chính phủ bao gồm các hợp đồng hỗ trợ và các bảo hành được soạn thảo đặc biệt.
Một số thỏa thuận cấp phép người dùng cuối đính kèm với phần mềm được trình bày cho người dùng đôi khi trên giấy hoặc thường là điện tử, trong quá trình cài đặt. Người dùng có quyền lựa chọn chấp nhận hoặc từ chối thỏa thuận. Việc cài đặt phần mềm là có điều kiện cho người dùng nhấp vào nút có nhãn "chấp nhận".
Nhiều EULA khẳng định giới hạn trách nhiệm rộng rãi. Thông thường nhất, EULA sẽ cố gắng vô hại đối với người cấp phép phần mềm trong trường hợp phần mềm gây ra thiệt hại cho máy tính hoặc dữ liệu của người dùng, nhưng một số phần mềm cũng đề xuất các giới hạn về việc người cấp phép có thể chịu trách nhiệm cho thiệt hại phát sinh do sử dụng không đúng cách phần mềm (ví dụ, sử dụng phần mềm khai thuế không chính xác và kết quả là sẽ bị phạt). Một trường hợp duy trì những hạn chế như vậy đối với các thiệt hại do hậu quả là M.A. Mortenson Co. v. Timberline Software Corp., Một số EULAs cũng yêu cầu hạn chế về địa điểm và luật áp dụng trong trường hợp xảy ra tranh chấp pháp lý.
Một số chủ sở hữu bản quyền sử dụng EULAs trong nỗ lực phá vỡ các giới hạn của luật bản quyền hiện hành đối với bản quyền của họ (chẳng hạn như các hạn chế trong phần 107, 122 của United States Copyright Act), hoặc để mở rộng phạm vi kiểm soát đối với làm việc trong các lĩnh vực mà luật pháp bảo vệ bản quyền bị từ chối (chẳng hạn như cố gắng tính phí, điều chỉnh hoặc ngăn chặn các buổi biểu diễn riêng tư của một tác phẩm vượt quá một số buổi biểu diễn nhất định hoặc vượt quá một khoảng thời gian nhất định). Các EULA như vậy, về bản chất, là những nỗ lực để giành quyền kiểm soát, theo hợp đồng, đối với các vấn đề mà luật bản quyền ngăn cấm kiểm soát. [2] Loại EULAs này đồng tình với DRM và cả hai có thể được sử dụng làm phương pháp thay thế để mở rộng quyền kiểm soát phần mềm.
Trong các tranh chấp về tính chất này ở Hoa Kỳ, các vụ kiện thường được kháng cáo và các tòa án phúc thẩm khác nhau đôi khi không đồng ý về các điều khoản này. Điều này tạo cơ hội cho Tòa án Tối cao Mỹ can thiệp, điều mà nó thường được thực hiện theo cách giới hạn phạm vi và thận trọng, cung cấp rất ít theo án lệ trước đó hoặc giải quyết.
EULA thường dài và được viết bằng ngôn ngữ pháp lý đặc biệt cao, khiến người dùng bình thường gặp khó khăn trong việc đưa ra sự đồng ý.[3] Nếu công ty thiết kế thỏa thuận cấp phép người dùng cuối theo cách cố tình không khuyến khích người dùng đọc chúng và sử dụng ngôn ngữ khó hiểu, nhiều người dùng có thể không đồng ý.
So sánh với giấy phép phần mềm tự do
[sửa | sửa mã nguồn]Một giấy phép phần mềm tự do cấp cho người dùng phần mềm đó quyền sử dụng cho bất kỳ mục đích nào, bao gồm sửa đổi và phân phối lại các tác phẩm và phần mềm sáng tạo, cả hai đều bị cấm bởi mặc định bản quyền và thường không được cấp cho phần mềm độc quyền. Các giấy phép này thường bao gồm từ chối bảo hành, nhưng tính năng này không phải là duy nhất đối với phần mềm tự do. [4] Giấy phép Copyleft cũng bao gồm một điều khoản bổ sung quan trọng phải được tuân theo để sao chép hoặc sửa đổi phần mềm, yêu cầu người dùng cung cấp mã nguồn cho công việc và phân phối các sửa đổi của họ theo cùng một giấy phép (hoặc đôi khi là tương thích); do đó bảo vệ hiệu quả các tác phẩm phái sinh khỏi mất quyền ban đầu và được sử dụng trong các chương trình độc quyền.
Không giống như EULA, giấy phép phần mềm tự do không hoạt động như các phần mở rộng theo hợp đồng đối với luật hiện hành. Không có thỏa thuận nào giữa các bên được tổ chức, bởi vì giấy phép bản quyền chỉ đơn giản là một tuyên bố về quyền đối với một thứ mà nếu không sẽ không được phép theo mặc định theo luật bản quyền.[2]
Cấp phép Shrink-wrap và click-wrap
[sửa | sửa mã nguồn]Thuật ngữ giấy phép shrink-wrap đề cập phổ thông đến bất kỳ thỏa thuận cấp phép phần mềm nào được đính kèm trong gói phần mềm và không thể truy cập được cho khách hàng cho đến sau khi mua. Thông thường, thỏa thuận cấp phép được in trên giấy có trong họp đóng gói phần mềm. Nó cũng có thể được trình bày cho người dùng trên màn hình trong khi cài đặt, trong trường hợp đó, giấy phép đôi khi được gọi là giấy phép click-wrap. Việc khách hàng không thể xem xét thỏa thuận cấp phép trước khi mua phần mềm đã khiến các giấy phép đó gặp phải những thách thức pháp lý trong một số trường hợp.
Cho dù giấy phép shrink-wrap có ràng buộc về mặt pháp lý khác nhau giữa các khu vực pháp lý hay không, mặc dù phần lớn các khu vực pháp lý giữ các giấy phép đó có thể được thi hành. Vấn đề đặc biệt là sự khác biệt về quan điểm giữa hai tòa án Mỹ trong Klocek v. Gateway và Brower v. Gateway. Cả hai trường hợp liên quan đến một tài liệu giấy phép shrink-wrapped được cung cấp bởi nhà cung cấp trực tuyến của một hệ thống máy tính. Các điều khoản của giấy phép shrink-wrapped không được cung cấp tại thời điểm mua, nhưng được bao gồm trong sản phẩm được vận chuyển như một tài liệu in. Giấy phép yêu cầu khách hàng trả lại sản phẩm trong khung thời gian giới hạn nếu giấy phép không được đồng ý. Trong vụ Brower, tòa phúc thẩm tiểu bang New York phán quyết rằng các điều khoản của tài liệu giấy phép shrink-wrapped có thể được thi hành vì sự đồng ý của khách hàng rõ ràng là do không trả lại hàng hóa trong vòng 30 ngày theo quy định của tài liệu. Tòa án quận Kansas của Hoa Kỳ trong vụ Klocek phán quyết rằng hợp đồng mua bán đã hoàn tất tại thời điểm giao dịch và các điều khoản vận chuyển bổ sung có trong một tài liệu tương tự như trong vụ Brower không cấu thành hợp đồng, bởi vì khách hàng không bao giờ đồng ý với họ khi hợp đồng mua bán hoàn thành.
Hơn nữa, trong ProCD v. Zeidenberg, giấy phép đã được phán quyết có thể thi hành được vì khách hàng cần phải đồng ý với các điều khoản của thỏa thuận bằng cách nhấp vào nút "Tôi đồng ý" để cài đặt phần mềm. Tuy nhiên, trong vụ việc Specht v. Netscape Communications Corp., người được cấp phép có thể tải xuống và cài đặt phần mềm mà không cần phải xem xét trước và đồng ý tích cực với các điều khoản của thỏa thuận, và vì vậy giấy phép được giữ là không thể thực thi được.
Các thỏa thuận cấp phép Click-wrap đề cập đến việc hình thành hợp đồng dựa trên trang web (xem iLan Systems, Inc. v. Netscout Service Level Corp.). Một ví dụ phổ biến về điều này xảy ra khi người dùng phải xác nhận chắc chắn các điều khoản cấp phép của trang web, bằng cách click vào nút "yes" trên cửa sổ bật lên, để truy cập các tính năng của trang web. Do đó, điều này tương tự với giấy phép shrink-wrap, trong đó người mua ngụ ý đồng ý với các điều khoản cấp phép bằng cách gỡ bỏ shrink-wrap của gói phần mềm và sau đó sử dụng chính phần mềm. Trong cả hai loại phân tích, trọng tâm là hành động của người dùng cuối và hỏi liệu có chấp nhận rõ ràng hay ngầm định các điều khoản cấp phép bổ sung hay không.
Trách nhiệm sản phẩm
[sửa | sửa mã nguồn]Hầu hết các giấy phép cho phần mềm được bán lẻ đều từ chối mọi bảo đảm về hiệu suất của phần mềm và giới hạn trách nhiệm đối với mọi thiệt hại đối với giá mua của phần mềm. Một trường hợp nổi tiếng duy trì sự từ chối như vậy là Mortenson v. Timberline.
Bằng sáng chế
[sửa | sửa mã nguồn]Ngoài ngụ ý học thuyết cạn kiệt, nhà phân phối có thể bao gồm giấy phép bằng sáng chế cùng với phần mềm.
Kỹ thuật đảo ngược
[sửa | sửa mã nguồn]Các hình thức thường cấm người dùng kỹ thuật đảo ngược. Điều này cũng có thể gây khó khăn cho việc phát triển phần mềm của bên thứ ba tương tác với phần mềm được cấp phép, do đó làm tăng giá trị của các giải pháp của nhà phát hành thông qua việc giảm sự lựa chọn của khách hàng. Tại Hoa Kỳ, các điều khoản của EULA có thể ưu tiên các quyền kỹ thuật đảo ngược được sử dụng hợp lý, Bowers v. Baystate Technologies.
Một số giấy phép[5] để cấm quyền của người dùng phát hành dữ liệu về hiệu suất của phần mềm, nhưng điều này vẫn chưa được thử thách tại tòa án.
Xem thêm
[sửa | sửa mã nguồn]Chú thích
[sửa | sửa mã nguồn]- ^ Linux Foundation, EULA Definition, published ngày 28 tháng 2 năm 2006, accessed ngày 10 tháng 8 năm 2019
- ^ a b Eben Moglen (ngày 10 tháng 9 năm 2001). “Enforcing the GNU GPL”. gnu.org. Free Software Foundation, Inc. Bản gốc lưu trữ ngày 26 tháng 4 năm 2013. Truy cập ngày 20 tháng 5 năm 2013.
- ^ Bashir, M., Hayes, C., Lambert, A. D., & Kesan, J. P. (2015). Online privacy and informed consent: The dilemma of information asymmetry. Proceedings of the Association for Information Science and Technology, 52(1), 1-10. doi:10.1002/pra2.2015.145052010043
- ^ Con Zymaris (ngày 5 tháng 5 năm 2003). “A Comparison of the GPL and the Microsoft EULA” (PDF): 3, 12–16. Bản gốc (PDF) lưu trữ ngày 6 tháng 10 năm 2008. Truy cập ngày 19 tháng 7 năm 2013. Chú thích journal cần
|journal=(trợ giúp) - ^ Examples include Microsoft.NET Framework redistributable EULA