Mã nguồn mở, bản quyền và các lỗi nhỏ


10

Giả sử một nhà phát triển đã phát triển một thư viện cho ứng dụng thương mại đóng kín của họ. Vì họ muốn trả lại cho cộng đồng nguồn mở, họ đã xuất bản thư viện này theo GPL, nhưng tiếp tục sử dụng nó trong ứng dụng của riêng họ. Vì họ giữ bản quyền, điều đó tốt.

Bây giờ, một người dùng phiên bản GPL tìm thấy một lỗi, sửa nó và gửi một bản vá cho nhà phát triển ban đầu. Theo tôi hiểu, để sử dụng lỗi này trong ứng dụng nguồn đóng của họ, nhà phát triển cần phải có sự cho phép của người gửi. Nếu người gửi từ chối, nhà phát triển phải tìm cách khác để sửa lỗi trong phiên bản nguồn đóng.

Nhưng nếu bản thân bugfix thực sự tầm thường thì sao? Giống như khởi tạo đúng một biến hoặc kiểm tra một con trỏ null? Một cái gì đó mà bất kỳ lập trình viên nửa có thẩm quyền có thể tìm và sửa trong vài phút, đưa ra một mô tả lỗi? Là bản vá cho điều này vẫn được bảo vệ bởi bản quyền? Hoặc nhà phát triển ban đầu có thể thực hiện sửa lỗi giống hệt trong ứng dụng nguồn đóng của họ mà không cần sự đồng ý của người nộp không?

Lưu ý: Đây thực sự là một tình huống giả định, không phải là một trong những câu hỏi "bạn của tôi" có vấn đề này "



2
Bạn có nhận ra rằng bạn đang yêu cầu tư vấn pháp lý từ một nhóm (hầu hết) những người ẩn danh qua Internet, những người thậm chí không giả vờ là luật sư?
Dan Pichelman

9
Vâng tôi đồng ý. Và tôi chắc chắn sẽ nói với thẩm phán rằng "Internet đã nói như vậy".
Benjamin Kloster

3
Nhưng bạn có thể chi hàng ngàn đô la cho một chuyên gia để đưa ra ý kiến ​​sẽ được một chuyên gia khác tranh luận trước tòa vì một phán quyết mà cuối cùng không có ý nghĩa gì cho đến khi được các tập đoàn lớn có tài khoản ngân hàng chi trả cho 10 vòng kêu gọi thực sự đóng đinh vào quan tài. Cho đến khi đại hội thông qua một cuộc tấn công mạng khác mà ném mọi thứ vào câu hỏi. Đối với Hoa Kỳ. ... Vâng, chào mừng bạn đến với màu xám vĩnh cửu đó là luật IP.
Philip

2
Câu hỏi thường gặp @DanPichelman nói rằng bạn có thể đặt câu hỏi cấp phép phần mềm ở đây cho các lập trình viên.

Câu trả lời:


6

Hãy cẩn thận: Tôi không phải là một luật sư!

Cập nhật: Các lỗi nhỏ có thể không có bản quyền. Xem câu trả lời của Michael Shaw, mà tôi tin là chính xác hơn những gì tôi nói ban đầu, để biết thêm thông tin.

Tuy nhiên, ngay cả khi cho rằng, tình huống này ít hơn lý tưởng:

  • Điều này có thể khá rõ ràng đối với ví dụ giả định của bạn, điều này tạo ra một sự thay đổi không đáng kể, trái ngược với việc thêm chức năng quan trọng. Tuy nhiên, trong cuộc sống thực, nó sẽ là một lời kêu gọi phán xét khi đó là trường hợp. Bạn sẽ bị bỏ lại trong một khu vực màu xám bản quyền.
  • Lý tưởng nhất là bạn muốn kết hợp tập tin cập nhật vào chương trình của bạn; bạn không muốn thêm mã của riêng mình, ngay cả khi nó không quan trọng. Nó chỉ trùng lặp làm việc không cần thiết.
  • Bây giờ sẽ có hai phiên bản của tệp: của bạn và một nguồn mở. Điều này chỉ gây rối nếu bạn muốn phát hành các phiên bản mã đã cập nhật cho cộng đồng sau này.

Kết luận: Giấy phép công cộng Gnu đặc biệt hạn chế sử dụng mã trong các chương trình nguồn đóng. Do đó, việc phát hành mã của bạn theo số tiền GPL để cố tình tạo một nhánh của mã không thể được kết hợp lại vào chương trình gốc. Điều này không có nhiều ý nghĩa.

Bạn sẽ được phục vụ tốt hơn bằng cách phát hành mã của mình theo giấy phép dễ dãi hơn, chẳng hạn như một trong các giấy phép BSD hoặc Giấy phép nghệ thuật . Các giấy phép này cho phép mã được đưa vào phần mềm nguồn đóng mà không cần sự cho phép bổ sung. Thông thường, bất kỳ sự phát triển nào nữa của cộng đồng sẽ diễn ra theo cùng một giấy phép bạn đã sử dụng, do đó bạn sẽ có thể kết hợp mọi thay đổi được thực hiện (nhỏ hoặc quan trọng) vào phần mềm của mình.

Về mặt kỹ thuật, ai đó có thể quyết định cập nhật mã của bạn và sau đó phát hành mã theo GPL, nhưng họ sẽ phải chủ động đưa ra lựa chọn đó. Nó sẽ không phải là vị trí mặc định. Và khi làm như vậy, họ sẽ cắt bỏ bản phát hành của họ khỏi bất kỳ bản cập nhật nào bạn thực hiện, vì vậy có lẽ nó sẽ không có lợi cho họ (vì đó là phần mềm của bạn, bạn có thể sẽ phát triển nó nhiều hơn bất kỳ ai khác).


1
-1 Các khái niệm không thể có bản quyền. Bản quyền áp dụng cho các biểu thức, không phải ý tưởng. Sửa lỗi đề xuất sử dụng giấy phép dễ dãi hơn cũng là sai; vấn đề là chúng tôi muốn sử dụng một lỗi mà không có sự cho phép của tác giả, việc phát hành nó theo một giấy phép khác không làm thay đổi bất cứ điều gì.
Michael Shaw

Bạn đúng về sửa chữa giấy phép cho phép; Tôi đã đọc sai câu hỏi và nghĩ rằng tác giả sửa lỗi giả định đã từ chối cấp phép sử dụng nó trong phiên bản nguồn mở thay vì phiên bản đóng. Bạn vẫn sai về các ý tưởng có bản quyền (trừ khi bạn đang nói về quyền tài phán không thuộc Hoa Kỳ). Luật Bản quyền Hoa Kỳ: "Trong mọi trường hợp, việc bảo vệ bản quyền đối với tác phẩm gốc của tác giả mở rộng cho mọi ý tưởng, thủ tục, quy trình, hệ thống, phương thức hoạt động, khái niệm, nguyên tắc hoặc khám phá ..."
Michael Shaw

@MichaelShaw, tôi đã cập nhật câu trả lời để xóa thông tin không chính xác. Cảm ơn vì đầu vào của bạn.

6

Nếu lỗi này thực sự không quan trọng, thì có khả năng nó không có bản quyền, đặc biệt là nếu thực sự không có cách nào khác để viết mã. Có hàng trăm triệu cách viết một bài thơ tình yêu hoặc một trò chơi video, thực sự không có nhiều hơn một hoặc hai cách để viết if (*p == NULL). Bản quyền là biểu hiện của một ý tưởng, vì vậy nếu thực sự không có bất kỳ lựa chọn nào về cách thể hiện ý tưởng, thì không thể có bản quyền.

Tuy nhiên, nếu lỗi vẫn còn khá nhỏ, có thể có vài chục cách thể hiện nó, vì vậy nó có thể có bản quyền. Và có thể không dễ để biết liệu một cái gì đó khá tầm thường hầu như không có bản quyền hoặc hầu như không thể phát hiện được.

Cũng có thể nó có thể có bản quyền, nhưng sử dụng nó sẽ được sử dụng hợp lý. Sử dụng hợp lý là một chút phức tạp, vì nó phụ thuộc vào việc cân nhắc một số yếu tố và nó có thể không hữu ích, vì việc áp dụng hợp pháp sẽ được quyết định bởi một tòa án - lý tưởng nhất là bạn không muốn có một phiên tòa nào cả , tuy nhiên trường hợp của bạn có thể mạnh mẽ. Một trong những yếu tố của việc sử dụng hợp lý là một phần của công việc đã được sử dụng (điều này chống lại bạn, vì bạn đã lấy toàn bộ) và một yếu tố khác là tiềm năng thương mại của công việc (điều này là cho bạn, vì giá trị thương mại của bản thân một lỗi không quan trọng là bằng 0), do đó, việc đoán theo cách mà tòa án có thể phán quyết là dễ bị lỗi.

Có lẽ cách tốt nhất để giải quyết vấn đề này là đưa một mô tả chính xác về lỗi và vị trí chính xác của nó cho một nhà phát triển chưa nhìn thấy bản vá. Sau đó, họ có thể sửa lỗi một cách độc lập (sẽ mất rất ít thời gian, vì lỗi này là không đáng kể) và tất cả các vấn đề bản quyền tiềm ẩn đều biến mất, vì nếu nó có bản quyền, bạn sở hữu bản quyền. Nhà phát triển của bạn có thể kết thúc với gần như chính xác mã giống như bản vá vì về cơ bản chỉ có một cách để viết nó, nhưng trong trường hợp này nó không có bản quyền.


-2

Ý kiến ​​thiếu kinh nghiệm của tôi, sau khi đọc http://www.ifosslr.org/ifosslr/article/view/30/64 , là đây:

Tác phẩm gốc có quyền tác giả duy nhất và người đó sở hữu bản quyền và có thể chọn cấp phép cho tác phẩm theo cách họ muốn và thực sự có.

Bây giờ một nhà phát triển tìm thấy một lỗi và đóng góp một bản sửa lỗi. Điều này có thể được coi là không có bản quyền (đóng góp quá nhỏ) nhưng nói rằng đó là một đóng góp đáng kể. Tác giả ban đầu chấp nhận sự đóng góp do đó làm cho tác phẩm trở thành một tác phẩm tập thể, vì cả hai cá nhân đã đồng ý sáp nhập.

Trong một tác phẩm tập thể, mỗi tác giả sở hữu các phần tương ứng của mình nhưng mỗi tác giả cũng sở hữu một lợi ích không thể phân chia trong toàn bộ tác phẩm và do đó mỗi tác giả có thể giải phóng toàn bộ tác phẩm theo bất kỳ điều khoản nào họ muốn.

Nếu đây là một cách giải thích hợp lý thì tranh cãi không phải là liệu tác giả gốc có thể sử dụng bản sửa lỗi trong bản phát hành thương mại của họ hay không, mà IMO họ có thể. Xung đột tiềm tàng là liệu người sửa lỗi có tin rằng họ có quyền sở hữu riêng không bị chia rẽ trong toàn bộ công việc hay không. Trong trường hợp đó, tác giả ban đầu có thể nhận được một bản phát hành từ trình sửa lỗi cho biết rõ ràng họ chấp nhận không có quyền sở hữu trong tác phẩm.

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.