Một số phân nhánh của phần mềm nguồn mở biến thành phần mềm nguồn đóng là gì?


16

Nếu một công ty có một ứng dụng nguồn mở được cấp phép cho phép và sau đó phát triển một ứng dụng nguồn đóng từ đó bằng cách làm lại các phần mở rộng của ứng dụng, thêm các tính năng mới và áp dụng sửa lỗi ...

Bỏ qua mọi yêu cầu cấp phép ...

  • Làm thế nào để chuyển đổi xảy ra và những gì có thể được thực hiện để ngăn chặn nó ngoài việc chọn một giấy phép khác biệt?
  • Các trách nhiệm (đạo đức hoặc xã hội) cho công ty là gì? (Ví dụ: Trả lại cho dự án nguồn mở sẽ là điều đạo đức phải làm)
  • Nếu cả phiên bản nguồn mở và phiên bản nguồn đóng đều có sẵn, thì sự cạnh tranh ảnh hưởng đến một trong hai sản phẩm như thế nào?

Có bất kỳ ví dụ về các công ty hoặc sản phẩm đã làm điều này (thành công hoặc không thành công) trong quá khứ? Thái độ cộng đồng đối với các dự án đó là gì?


2
Tôi nghĩ rằng phản xạ .NET có thể là một ví dụ khá hay về điều này.
l46kok

2
@ l46kok Tôi đã hủy bỏ upvote của tôi cho nhận xét của bạn vì Reflector không bao giờ là nguồn mở, chỉ miễn phí như trong bia.
Đánh dấu

Câu trả lời:


14

Điều quan trọng cần lưu ý là kịch bản này có thể xảy ra ở cả hai dạng hợp pháp và bất hợp pháp.

Điều này có thể xảy ra hợp pháp nếu công ty sở hữu hoặc có quyền truy cập vào bản quyền liên quan đến mã. Ví dụ, các nhóm phát triển độc lập, nhỏ hơn có thể muốn bán hoặc cấp phép bản quyền cho một công ty lớn hơn. Tương tự như vậy, nếu phần lớn bản quyền của mã có thể được mua, phần "không thể đạt được" có thể chỉ cần được ném ra và viết lại.

Ở phía bên kia của đồng tiền, mã có thể đơn giản được lấy bất hợp pháp. New Corp, Inc. có thể không quan tâm đến sự phân nhánh pháp lý là gì. Dự án có thể quá cũ hoặc bị bỏ rơi hoặc New Corp nghĩ rằng họ sẽ thắng trong một vụ kiện. Hoặc New Corp có thể được đăng ký trong một khu vực nơi loại "mua lại" này đơn giản không được định nghĩa là bất hợp pháp. Không phải tất cả các giấy phép OSS đều có thể được thi hành, đặc biệt không phải là các giấy phép được ghép lại bởi những người không phải là chuyên gia về luật. Không phải tất cả chủ sở hữu dự án có thể có khả năng thực thi khiếu nại bản quyền của mình và các tổ chức lớn hơn như FSF có thể không có quyền tài phán đối với khiếu nại đó. TL; DR - khu vực này có thể trở nên mơ hồ và xấu xí rất nhanh.

Chuyển đổi và phòng ngừa

Làm thế nào để chuyển đổi xảy ra và những gì có thể được thực hiện để ngăn chặn nó ngoài việc chọn một giấy phép khác biệt?

Quá trình chuyển đổi xảy ra khi New Corp, Inc. mua lại cơ sở mã và các địa điểm sao chép dưới sự kiểm soát của họ. Các nhà phát triển của New Corp sau đó bắt đầu làm việc trên của họ phiên bản của việc lập cơ sở mã bất cứ điều gì thay đổi các lãnh chúa của công ty đã ra lệnh cần thiết. Các cơ chế thực tế của ngã ba này sẽ thay đổi dựa trên kho lưu trữ. Và trong khi đó là một vấn đề lớn về mặt triết học, nó thực sự khá áp đảo trong thực tế. get alltừ OpenRepos và sau đó checkinđến PrivateRepos.

Những gì có thể được thực hiện để ngăn chặn nó không bao giờ phân phối nguồn? Không có gì. Lấy làm tiếc.

Hãy sử dụng GPL (giấy phép công cộng GNU) làm ví dụ. GPL yêu cầu nguồn phải có sẵn cho bất kỳ ai nhận được bản sao hợp pháp của dự án. Không quy định nào cho phép chủ sở hữu nguồn từ chối giao nguồn cho chủ sở hữu hợp pháp một bản sao của ứng dụng GPL. Nó đi ngược lại với phần mềm miễn phí và đó là lý do tại sao bản sao GPL được đưa ra.

Có khả năng, bạn có các khóa hành động pháp lý thực tế để theo đuổi. Nhưng đó là tất cả sau khi nguồn đã thoát và bị rẽ nhánh, không phải trước đó. Và trong một số khu vực pháp lý, bạn sẽ không có bất kỳ khiếu nại pháp lý nào. Và tất cả những điều này giả định rằng bạn thậm chí còn biết rằng ngã ba đã xảy ra. Bạn có thể không bao giờ tìm ra.

Đạo đức

Các trách nhiệm (đạo đức hoặc xã hội) cho công ty là gì? (Ví dụ: Trả lại cho dự án nguồn mở sẽ là điều đạo đức phải làm)

Đạo đức là địa phương của văn hóa. Vì vậy, tiết phần này với hạt muối. Một cuộc thảo luận đầy đủ về việc xem xét văn hóa về đạo đức nằm ngoài phạm vi của câu trả lời này và ngoài chủ đề cho các lập trình viên.

Tôi đã nhận thấy rằng cộng đồng lập trình có xu hướng phản ứng tiêu cực với một ngã ba thù địch. Heck, trong một số trường hợp, cùng một cộng đồng vẫn phản ứng tiêu cực với một ngã ba thân thiện và hợp pháp. Đó là một cộng đồng khá phức tạp.

Từ góc độ FOSS, có một kỳ vọng rằng New Corp sẽ "trả ơn" cho cộng đồng về sự đóng góp của nó. Các điều khoản, điều kiện và thời gian trả nợ đó cũng đa dạng như số lượng dự án OSS đang tồn tại. Một số người trong cộng đồng (nghĩ Richard Stallman) sẽ không bao giờ bằng lòng với một dự án mở sẽ bị đóng cửa. Những người khác sẽ tìm kiếm lợi ích cung cấp cho cộng đồng nói chung và sẽ đánh giá dựa trên điều đó. Và những người khác chỉ đơn giản là không quan tâm bởi vì họ không bao giờ biết hoặc quan tâm đến dự án nguồn gốc.

Nguồn sẵn có

Nếu cả phiên bản nguồn mở và phiên bản nguồn đóng đều có sẵn, thì sự cạnh tranh ảnh hưởng đến một trong hai sản phẩm như thế nào?

Nó thực sự phụ thuộc vào mức độ so sánh giữa hai cơ sở mã liên quan đến chức năng, hiệu suất và tính ổn định.

Nếu các cơ sở mã vẫn tương tự và New Corp thân thiện với cộng đồng OSS, họ có thể đóng góp các cập nhật của họ trở lại dự án cơ sở. Trong trường hợp này, mọi người đều có lợi. Đây không phải là một "cuộc cạnh tranh" trong trường hợp này, mà là sự hợp tác cùng có lợi.

Nếu mã dựa trên cơ sở phân kỳ mạnh mẽ và New Corp không thân thiện với cộng đồng OSS, thì vẫn không có sự cạnh tranh. Các sản phẩm giàu tính năng hơn tồn tại và sản phẩm ít phong phú hơn có xu hướng chết đi. Lưu ý rằng điều này có thể đi theo bất kỳ cách nào - phiên bản đóng có thể chết nếu phiên bản nguồn mở tiếp tục đổi mới hoặc đáp ứng tốt hơn nhu cầu của cộng đồng.

Thực tế sẽ ở đâu đó giữa hai đầu của quang phổ.

Thí dụ

Red Hat có hai bản phân phối chính - Enterprise Linux và Fedora. EL là phiên bản được cấp phép "đóng" của họ và Fedora là phiên bản cộng đồng của họ. Do GPL, phần lớn, nếu không phải tất cả, phiên bản EL được phát hành ở dạng nguồn. Một dự án khác không liên kết với Red Hat có tên là CentOS chọn ra các thay đổi cho EL và phân phối dự án đó sau một số thương hiệu nhỏ.

Có một số càu nhàu khi Red Hat chia thành hai phiên bản riêng biệt, nhưng nhìn chung, đó là một thỏa thuận khá khả thi. Cộng đồng Fedora muốn các tính năng được đưa vào phân phối nhanh hơn những gì khách hàng doanh nghiệp của Red Hat cảm thấy thoải mái. Cải tiến cho các cơ sở mã chảy theo cả hai hướng.


1
@GlenH7 Câu trả lời hay bao gồm những lời xin lỗi về kỹ thuật và pháp lý :)
hagubear

1
đừng quên rằng người ta có thể tiếp quản một cơ sở mã và không nhận thức được liên kết đến một thư viện nguồn mở ẩn sâu bên trong hàng triệu dòng mã, hàng trăm poms, tệp ant, tệp tạo tệp, v.v. đặc biệt là nếu đó là một liên kết gián tiếp. Chúng tôi đã có điều đó xảy ra, và đã có một thời gian để cắt mã bị ảnh hưởng và thay thế nó bằng thứ gì đó chúng tôi có thể phân phối.
jwenting

4

Giả sử rằng mọi thứ đều hợp pháp và trên bảng, và chúng ta đang nói về một sản phẩm có giấy phép nguồn mở kosher trước khi quá trình bắt đầu:

Quá trình chuyển đổi diễn ra như thế nào ...

Về cơ bản, công ty thực hiện một bản phát hành mới của phần mềm với giấy phép nguồn mở.

và những gì có thể được thực hiện để ngăn chặn nó ngoài việc chọn một giấy phép khác biệt?

Nói chung không có gì. Trường hợp duy nhất có thể được ngăn chặn (hoặc trì hoãn) là nếu có nhiều chủ sở hữu bản quyền và một số người trong số họ phản đối việc cấp phép lại. Nhưng nếu công ty nghiêm túc, họ có thể quyết định giải quyết vấn đề đó bằng cách viết lại các phần có liên quan của cơ sở mã, vân vân.

Cố gắng áp dụng "áp lực đạo đức" trước thực tế có lẽ khó có thể làm việc. Công ty có khả năng làm điều này mà không có bất kỳ thông báo trước.

Phải nói rằng, có những ví dụ về những nỗ lực "quay trở lại" nguồn mở đã phản tác dụng đối với công ty thực hiện nó. Hãy xem xét các trường hợp của OpenOffice, Hudson và MySQL, trong đó các hành động của Oracle đã dẫn đến một ngã ba, một cuộc di cư hàng loạt của cộng đồng nhà phát triển và (đối với OO và MySQL) ngày càng bán phá giá sản phẩm ban đầu có lợi cho ngã ba (LibreOffice và MariaDB ).

Các trách nhiệm (đạo đức hoặc xã hội) cho công ty là gì?

Thẳng thắn (và hơi cay độc), nó không liên quan đến những gì bạn và tôi nghĩ rằng trách nhiệm đạo đức và xã hội của một công ty nên là.

Từ góc độ pháp lý, trách nhiệm duy nhất của giám đốc công ty và giám đốc điều hành là 1) để tối đa hóa giá trị cho các cổ đông / chủ sở hữu và 2) đảm bảo rằng luật pháp được tuân thủ. Bạn có thể lập luận rằng với tư cách cá nhân, những người này có trách nhiệm xã hội và đạo đức, nhưng ... thật không may ... nhiều người trong số họ sẽ không đồng ý.

Nhưng dù bằng cách nào, trách nhiệm đạo đức và xã hội chỉ có liên quan trong một ý nghĩa thực tế nếu công ty và các nhân viên của công ty đưa họ lên tàu và thực hiện chúng một cách nghiêm túc.

Nếu cả phiên bản nguồn mở và phiên bản nguồn đóng đều có sẵn, thì sự cạnh tranh ảnh hưởng đến một trong hai sản phẩm như thế nào?

Tôi không nghĩ rằng có một câu trả lời cho điều này. Nó phụ thuộc vào hoàn cảnh.


Có bất kỳ ví dụ về các công ty hoặc sản phẩm đã làm điều này (thành công hoặc không thành công) trong quá khứ? Thái độ cộng đồng đối với các dự án đó là gì?

Vâng, có những ví dụ. Chỉ cần Google cho cụm từ "đi nguồn đóng" và áp dụng bộ lọc không có thật. Đọc qua các bản hit (không có thật) sẽ cho bạn cảm giác về thái độ cộng đồng và nếu bạn nghiên cứu sâu hơn về các sản phẩm / công ty, bạn có thể quyết định xem họ có thành công hay không. (Tôi sẽ không làm điều này cho bạn vì "thành công" là một đánh giá giá trị.)

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.