Tôi có thể xóa tất cả các chữ hoa và rút ngắn từ chối trách nhiệm trong Giấy phép của mình không?


13

Tôi đang sử dụng Giấy phép MIT cho một đoạn mã cụ thể. Bây giờ, giấy phép này có một sự từ chối lớn trong tất cả các mũ:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF...
...

Tôi đã thấy từ chối trách nhiệm được viết hoa thông thường trên giấy phép zlib (lưu ý rằng nó nằm trên văn bản giấy phép) và thậm chí phần mềm không có tuyên bố từ chối trách nhiệm nào cả (điều này có nghĩa là tôi có đảm bảo không?), Nhưng tôi 'Muốn một số lời khuyên có nguồn gốc từ một bên đáng tin cậy. Tôi không tìm thấy bất kỳ.

Thông báo cấp phép của GNU cho các tệp khác đi kèm với tuyên bố từ chối trách nhiệm này:

Tập tin này được cung cấp nguyên trạng, không có bất kỳ bảo hành.

Ngắn gọn và đơn giản.

Do đó, câu hỏi của tôi: Có bất kỳ nguồn đáng tin cậy nào chỉ ra rằng một từ ngắn chứ không phải dài và được đánh vần bình thường thay vì từ chối trách nhiệm viết hoa (hoặc thậm chí một hoặc khác) có thể sử dụng một cách an toàn trong tất cả các khu vực pháp lý mà tôi nên quan tâm không?

Đối với mục đích của câu hỏi này, phần mềm được phát hành tại Liên minh Châu Âu, nếu nó làm cho bất kỳ sự khác biệt.


1
Kiểm tra với luật sư, vì tôi chắc rằng những người đã viết GPL / BSD đã làm :)
Tim Post

1
@Tim Tôi hy vọng người khác đã làm điều đó và tôi đang tìm kiếm phán quyết của họ. Không bị hiểu lầm: Tôi không tìm kiếm ý kiến ​​của ai đó , nhưng bằng chứng đáng tin cậy.
Stefano Palazzo

1
Tôi đã tò mò đủ về mũ để hỏi. Xem câu trả lời của tôi.
Tim Post

Câu trả lời:


18

IANAL, nhưng một người làm việc với tôi. Vì vậy, tôi hỏi. Kết quả:

  • Các mũ cho phép bạn nói 'không có cách nào họ có thể bỏ qua từ chối trách nhiệm, nó hầu như không được in tốt!' Điều này rất quan trọng trong giấy phép hoặc EULA mà những người không phải là luật sư phải đọc và chấp nhận.

  • Có một sự khác biệt giữa 'express' và 'ngụ ý'. Một số khu vực có luật cho phép mọi người 'ngụ ý' bảo hành, mặc dù một khu vực không được cung cấp rõ ràng, trừ khi bạn thực hiện một số thông số kỹ thuật nhất định.

Ông đề nghị không thực hiện bất kỳ thay đổi nào đối với giấy phép hiện tại, vì điều đó về cơ bản tạo ra một giấy phép hoàn toàn mới (và có thể yếu hơn). Giấy phép phổ biến là một vấn đề. Phổ biến giấy phép xấu là một vấn đề lớn hơn.

Giấy phép được thiết kế để bảo vệ bạn , và đưa ra kỷ nguyên mới về sự kiện tụng vô tận, mũ lưỡi trai và chạy theo những câu mà rất ít người đọc để bắt đầu là một cái giá nhỏ phải trả :)

Đây là một trong những lý do lớn nhất khiến V2 / V3 của GPL (L | A) nói cụ thể rằng việc thay đổi giấy phép bị cấm.

Mọi người kiện, mỗi ngày .. vì những thiệt hại mà lẽ thường phải tránh. Ví dụ: "Làm sao tôi biết cà phê nóng? Tôi sẽ không làm đổ nó vào lòng nếu nó được dán nhãn như vậy .."

Bạn thực sự cần lưu ý không làm suy yếu 'lá chắn' ngăn những người đào vàng làm phiền bạn.


Lý do lớn nhất khác mà giấy phép GPL cấm thay đổi, đó là một số kẻ khác có thể lấy GPL, chèn một số hạn chế như "bạn không thể xóa liên kết đến trang web của tôi" (Flowplayer, tôi đang nhìn bạn!), Hãy gọi nó GPL và (1) làm cho chữ viết tắt "GPL" trở nên vô nghĩa và (2) đánh lừa người hâm mộ FSF trong việc kết hợp sản phẩm mà không đọc một bản sao khác của "GPL" (trong thực tế đặt ra các hạn chế đối với họ trên và trên GPL , nhưng họ sẽ không bao giờ nhận ra cho đến khi họ bị kiện).
cHao

4

Tuyên bố từ chối trách nhiệm toàn bộ trong giấy phép MIT ít nhiều là một bản sao dán từ ngôn ngữ pháp lý được tìm thấy trong giấy phép thu hẹp thương mại, trong đó việc đánh vần là "không bảo đảm" là bắt buộc phải chính xác hơn về mặt pháp lý cho phần mềm miễn phí. Vì các giấy phép nguồn mở tồn tại mà không có thông báo pháp lý này, tôi cho rằng hình thức ngắn có lẽ là ổn.

Như với tất cả những điều hợp pháp, nếu bạn thực sự lo lắng về nó, bạn nên tham khảo ý kiến ​​một luật sư chuyên về luật cấp phép phần mềm.


2

Từ chối trách nhiệm là có để bảo vệ bạn là tác giả ban đầu. Nếu không, có thể có những bảo đảm ngụ ý theo luật bạn sẽ cần phải thực hiện khi chuyển giao công việc phần mềm.

Như bạn có thể tưởng tượng trong các hệ thống kỹ thuật, điều này có thể phức tạp và đó là lý do tại sao bạn thực sự muốn loại trừ bảo hành. Đây cũng là những gì cấp độ đầu vào hoặc tài liệu nâng cao hơn về chủ đề này cho thấy.

Khi xã hội ngày càng phụ thuộc vào phần mềm để thực hiện các chức năng quan trọng trong mọi thứ, từ sản xuất đến các hệ thống hỗ trợ sự sống, nguy cơ lỗi trong chương trình phần mềm sẽ dẫn đến thiệt hại kinh tế, thiệt hại tài sản hoặc thương tích cá nhân tăng lên. Các nhà phát triển phần mềm thận trọng sẽ nhận thức được những rủi ro này và sẽ thực hiện các bước để giảm thiểu tiếp xúc với loại trách nhiệm pháp lý này. Việc xác định nhà phát triển phần mềm nên đi bao xa trong nỗ lực này đòi hỏi phải cân bằng mức độ tiếp xúc với trách nhiệm pháp lý của sản phẩm phần mềm trước tác động bất lợi, nếu có, trong các bước cần thiết để hạn chế sự tiếp xúc này đối với khả năng tiếp thị và bán phần mềm của nhà cung cấp phần mềm.

( từ: IV. Kết luận - Trách nhiệm sản phẩm phần mềm: Hiểu và giảm thiểu rủi ro (Tác giả Lawrence B. Levy và Suzanne Y. Bell) )

Vì có lẽ bạn đang cho phần mềm của mình đi theo các điều khoản phần mềm miễn phí rất tự do, bạn nên tham khảo ý kiến ​​luật sư trước khi thay đổi văn bản giấy phép được thiết lập và chấp nhận rộng rãi (vâng, điều đó có thể làm thay đổi và nếu tôi đọc phản hồi của @Tim Post Lawyer , thì đây cũng là Luật sư của ông có ý gì. Bạn cũng có thể thấy điều đó trong các bình luận / ấn phẩm của các luật sư khác, đặc biệt là về giấy phép phần mềm miễn phí).

Tuy nhiên, từ chối trách nhiệm này là không có carte-blush cho tất cả mọi thứ. Ví dụ, ở Đức, bạn không thể giảm trách nhiệm pháp lý bằng cách từ chối bảo hành một cách dễ dàng bằng cách chỉ cần thêm nó dưới các điều khoản.

Bởi vì bảo hành đầy đủ cho một phần mềm theo yêu cầu của pháp luật sẽ đặt quá nhiều trách nhiệm pháp lý cho tác giả gốc - những người thực sự thường không kiếm được một xu - điều này đã được làm rõ hơn đối với Phần mềm Tự do vì hiện tại có một số câu trong luật Đức làm cho điều này rõ ràng hơn (và để cho phép từ chối bảo hành ở một mức độ nhất định). Điều này đã không đặt thế giới như chúng ta đã biết trước khi từ trên xuống, nhưng chỉ nói rằng mọi thứ không dễ dàng như vẻ ngoài của chúng và trong một khu vực quan trọng, có lẽ tốt hơn là ở lại với một lượng lớn người dùng quan trọng của điều khoản tương tự để chống lại hiệu quả trong trường hợp cần thiết.

Bạn cũng có thể tìm thấy những hàm ý này trong các điều khoản của GPL 3, một giấy phép hiện đại có ý nghĩa sử dụng quốc tế:

Phần 15. là Tuyên bố miễn trừ trách nhiệm bảo hành và 16. là Giới hạn trách nhiệm :

17. Giải thích mục 15 và 16.

Nếu từ chối trách nhiệm bảo hành và giới hạn trách nhiệm được cung cấp ở trên không thể có hiệu lực pháp lý địa phương theo các điều khoản của họ, tòa án xem xét sẽ áp dụng luật địa phương gần như miễn trừ tuyệt đối mọi trách nhiệm dân sự liên quan đến Chương trình, trừ khi bảo hành hoặc giả định trách nhiệm kèm theo một bản sao của Chương trình để đổi lấy một khoản phí.

( từ: Giấy phép Công cộng GNU - Phiên bản 3, ngày 29 tháng 6 năm 2007 )

Điều này chỉ có thể nếu bạn tuân thủ các thông lệ được chấp nhận bao gồm không thay đổi các văn bản giấy phép Phần mềm Tự do được chấp nhận bao gồm các khuyến cáo bảo hành bên dưới chúng vì lý do cá nhân (ít nhiều).


Tuy nhiên, văn bản giấy phép MIT mà bạn liên quan đến trong câu hỏi của bạn không có yêu cầu giữ lại từ chối trách nhiệm bảo hành.

Điều này có thể có ý nghĩa bởi vì trong một số trường hợp ký hợp đồng cấp phép phần mềm hoặc công việc dựa trên nó có thể yêu cầu bạn loại bỏ tuyên bố từ chối trách nhiệm thực sự rộng rãi này và đàm phán các điều khoản chính xác hơn ở đây.

Tuy nhiên, có lẽ không nên loại bỏ nó vì điều đó, Câu hỏi thường gặp về OSI cũng có chủ đề bảo hành khác nhau (không cụ thể, xem bên dưới) và từ ngữ gợi ý một bảo hành được bán riêng có lẽ thực sự có ý nghĩa hơn nhiều:

Một số công ty có thể bán cho bạn một bảo hành riêng, với một khoản phí, nhưng đó không phải là một phần của giấy phép nguồn mở, đó chỉ là hợp đồng riêng của bạn với công ty đó.

( từ: Tôi có thể hạn chế cách mọi người sử dụng chương trình được cấp phép Nguồn mở không? - Câu hỏi thường gặp về OSI )

Vì vậy, thay đổi và xóa nó dường như không được phép và có vẻ như bạn sẽ không mất bất kỳ quyền sử dụng lại nào, tuy nhiên những gì bạn thực sự làm ở đây là phá hủy văn bản và cung cấp bảo hành cho quá nhiều người dùng như bạn thực sự sẵn sàng quan tâm về.

Phân tích văn bản thêm bởi những người khác có thể không dễ dàng xác định giấy phép ban đầu mà họ có được từ việc thêm một bước / điểm để theo dõi trong khi làm rõ giấy phép của tác phẩm (đối với bên thứ ba sử dụng tác phẩm đó). Sau đó, những người dùng khác có thể bối rối và những gì không. Vì vậy, giữ minh bạch này là gợi ý tốt nhất tôi có thể đưa ra.

Và làm điều đó vì một lý do. Chỉ định dạng mục đích vì nó không làm hài lòng khẩu vị của bạn? Chà, đó là một thế giới tự do để bạn có thể làm bất cứ điều gì bạn muốn, nhưng điều này cũng là để tặng một cái gì đó cho người khác vì vậy hãy nhớ rằng điều này có thể khiến người khác sống phức tạp hơn một chút. Chỉ cần quyết định điều gì là quan trọng đối với bạn và những rủi ro mà bạn sẵn sàng chấp nhận.

Và nếu bạn có câu hỏi pháp lý, tốt hơn, hãy hỏi ai đó có thể trả lời những câu hỏi đó cho bạn một cách ràng buộc về mặt pháp lý (không nói rằng luật sư sẽ luôn luôn làm, nhưng khả năng cao hơn là bạn sẽ được giáo dục nhiều hơn sau đó từ quan điểm pháp lý: )). Nhưng tôi đoán bạn biết thỏa thuận.

IANA / YLJASD

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.