Các giao diện và chữ ký phương thức có được bảo vệ bản quyền không?

Ví dụ: đó có phải là vi phạm bản quyền nếu tôi viết một lớp có tên Ngẫu nhiên với cùng chữ ký phương thức và mục đích chính xác như lớp .Net System.Random của Microsoft không? Liệu nó có làm nên sự khác biệt của ngôn ngữ mà nó viết bằng ngôn ngữ nào không? Trong trường hợp này, tôi muốn viết một lớp Ngẫu nhiên để sử dụng trong ActionScript, lớp này thiếu lớp PRNG được tích hợp sẵn.

Nếu bất cứ ai có liên kết tốt hoặc đề xuất tham khảo để hiểu những khía cạnh nào của phần mềm được bảo vệ thì điều đó cũng thật tuyệt vời. Và vâng tôi biết đây không phải là nơi cho lời khuyên pháp lý "thực sự". Nếu bất cứ ai ra tòa chỉ vào một bảng tin công khai là ưu tiên - xấu hổ về họ.

Tôi tin rằng nhìn vào mối quan hệ giữa Mono và Dotnet trả lời câu hỏi này. Nhóm Mono có thể sử dụng các định nghĩa phương thức hoặc giao diện chung nhưng họ phải thực hiện lại các phần bên trong. Tuy nhiên, trường hợp Android v Oracle mang đến một vài điểm khác khiến cho sự khác biệt rõ ràng này trở nên mờ nhạt hơn một chút. Trong trường hợp AvO, hầu hết các điểm được đưa ra tòa đều là bằng sáng chế liên quan đến VM, các giao diện thư viện không phải là điểm gây tranh cãi. Mã duy nhất đã được làm nổi bật là các ví dụ trong đó có vẻ như một số phần mở rộng mà phần bên trong đã được sao chép.

Có một câu hỏi tương tự về các lược đồ cơ sở dữ liệu: Sao chép lược đồ cơ sở dữ liệu của đối thủ cạnh tranh? Tôi đã trả lời rằng việc sao chép toàn bộ lược đồ có thể là vi phạm bản quyền, tùy thuộc vào quy mô của việc sao chép, được đánh giá bởi một thẩm phán.

Ngay cả khi câu hỏi của bạn tương tự, tôi sẽ trả lời hoàn toàn ngược lại: bạn có thể sao chép chữ ký phương thức. Tại sao?

Trong thực tế, chữ ký phương pháp xuất phát từ lẽ thường.

• Thứ nhất, nếu chúng ta lấy một ví dụ cực đoan, Microsoft không thể giữ bản quyền tênRandom và kiện mọi người sẽ sử dụng từ này Randomtrong bất kỳ ứng dụng nào.

• Thứ hai, bạn đang cố gắng làm gì chính xác? Tái hiện .NET Framework? Tại sao? Không cần phải phát minh lại bánh xe . Nếu bạn biết cách làm cho nó tốt hơn, trực quan hơn, v.v., rất có thể bạn sẽ đi kèm với tên của các lớp và phương thức tốt hơn, một tổ chức tốt hơn, v.v. Nếu bạn cố gắng sao chép cấu trúc của .NET Framework để chuyển nó sang một cấu trúc khác ngôn ngữ , sau đó bạn không phải là đối thủ cạnh tranh trực tiếp của Microsoft, vì vậy họ không có lý do nghiêm trọng nào để kiện bạn (điều này được nói, họ sẽ kiện bạn nếu bạn sao chép chính mã nguồn). Trên thực tế, họ thậm chí sẽ có lợi từ bạn: sao chép cấu trúc như vậy sang các khung khác sẽ không chỉ cho thấy sự thành công của .NET Framework mà còn giúp các nhà phát triển .NET làm việc với các ngôn ngữ khác và các nhà phát triển từ các ngôn ngữ khác dễ dàng hơn để học .MẠNG LƯỚI.

• Thứ ba, họ có nhiều việc phải làm nghiêm trọng hơn là kiện mọi người sẽ sao chép tên của các phương thức và các lớp của .NET Framework.

Bây giờ, nếu ý định của bạn là sao chép toàn bộ .NET Framework và tạo ra một sản phẩm sẽ được nhiều nhà phát triển sử dụng, hãy tham khảo ý kiến ​​luật sư trước khi chấp nhận rủi ro.

Một ví dụ:

Tôi hoàn toàn không hài lòng với giới hạn 259 ký tự xấu hổ trong đường dẫn tệp trong .NET Framework và không thể sử dụng các giao dịch mã ở cấp độ tệp. Vì vậy, tôi đã triển khai Filelớp của riêng mình với các phương thức sẽ hoạt động như mong đợi cho bất kỳ đường dẫn nào, không chỉ các đường ngắn nhỏ và thực hiện các giao dịch. Trong phiên bản đầu tiên, tôi quyết định sao chép tên của các phương thức trong Filevà Directorycác lớp . Microsoft sẽ kiện tôi vì điều đó? Tôi nghi ngờ điều đó.

Trong mọi trường hợp, trong phiên bản thứ hai tôi đi kèm với một cú pháp mới new File(string fileName), mà tôi thấy trực quan hơn nhiều đối với tôi . Nhân bản tên của các phương thức đôi khi hữu ích, nhưng bạn phải có lý do chính đáng để làm điều đó.

Bảo vệ bản quyền bảo vệ "biểu hiện nghệ thuật" của tác phẩm, chứ không phải hình thức kỹ thuật (để trích dẫn wikipedia ).

Bảo vệ bản quyền không bảo vệ sự thật .

Vì vậy, câu hỏi trở thành, một API hoặc giao diện là "sự thật" hay một biểu hiện nghệ thuật? Đối với các API đơn giản chỉ là một danh sách các cách để có được các số ngẫu nhiên và các loại số ngẫu nhiên khác nhau, API có thể giống như một sự thật. Nhưng, tôi có thể thấy có một giao diện rất tinh vi (bạn biết đấy, những cái bạn nhìn chằm chằm trong một phút, rồi nói "Ahh! Thật ấn tượng.") Có thể được coi là một "biểu hiện nghệ thuật" đáng được bảo vệ.

Đây là một bài viết gần đây về Oracle và Google đấu tranh về bản quyền API về vấn đề này đang được tranh luận tại tòa án (Hoa Kỳ).

Tôi không phải là một luật sư và bài viết này không nên được hiểu là tư vấn pháp lý. Tôi thậm chí không thể viết từ chối trách nhiệm rất tốt.

Bạn có thể có các khía cạnh chức năng thuần túy, nhưng bạn không thể có các khía cạnh biểu cảm. Tên lớp, tên phương thức và chữ ký hoàn toàn là chức năng. Bạn cần chúng để hoạt động. Tên tham số và macro tiêu đề có thể được coi là biểu cảm. Ví dụ, trong trường hợp chống độc quyền Windows, Microsoft lập luận rằng không có gì ngăn cản đối thủ cạnh tranh sao chép API Windows và tạo nền tảng riêng của họ mà ứng dụng Windows sẽ chạy.