Đưa một dự án nguồn mở sang nguồn đóng


19

Làm thế nào có thể hợp pháp để đưa một dự án được phát hành ban đầu dưới dạng nguồn mở trở lại nguồn đóng? Đặc biệt là một bản quyền với GPL bất kỳ phiên bản nào.


5
Nếu bạn giữ bản quyền của dự án, bạn có thể tự do cấp phép lại cho bất kỳ cách nào bạn muốn. Làm như vậy không làm mất hiệu lực bất kỳ mối quan hệ giấy phép hiện có nào được thiết lập theo GPL.
Blrfl

Tại sao không chỉ lấy nó, làm cho nó một dự án mới và đi từ đó?
Rook

@Blrfl Điều đó mang đến một câu hỏi thú vị. Bất cứ ai sẽ sử dụng các bộ phận hoặc toàn bộ dự án GPL'ed sẽ vi phạm giấy phép nguồn đóng vì cơ sở mã sẽ giống hệt nhau.
Karlson

8
@Karlson: Không thực sự, họ chỉ không bao giờ đăng ký giấy phép nguồn đóng. Họ vẫn theo giấy phép GPL.
DeepSpace101

Câu trả lời:


10

Có hai điều ở đây:

  • thu hồi giấy phép nguồn mở đã được đưa ra. Nó có thể sẽ phụ thuộc vào văn bản của giấy phép. Nếu giấy phép không có điều khoản, tôi không chắc có thể nếu người được cấp phép không vi phạm. Và một số giấy phép như GPL phiên bản 3, rõ ràng ở chỗ:

Tất cả các quyền được cấp theo Giấy phép này được cấp cho thời hạn bản quyền trên Chương trình và không thể hủy ngang với điều kiện các điều kiện đã nêu được đáp ứng.

  • cấp phép lại theo các điều khoản khác. Có thể miễn là bạn có được sự đồng ý của tất cả các chủ sở hữu bản quyền. Nếu bạn có tầm nhìn xa để có được nó trước khi chấp nhận các đóng góp (một số dự án GNU như GCC yêu cầu bạn chỉ định bản quyền cho FSF chẳng hạn) thì thật dễ dàng. Nếu bạn không làm thế, điều đó sẽ khó khăn (một số dự án thực hiện điều đó một cách tự nguyện để việc thay đổi giấy phép là không thể thực hiện được, có được sự đồng ý của mọi người hoặc theo dõi và loại bỏ sự đóng góp của những người không thực tế).

(Đề cập bắt buộc: Tôi không phải là luật sư, hãy xem của bạn và một số khía cạnh có thể được bản địa hóa và phụ thuộc vào thẩm quyền của bạn).


4

Bạn không thể lấy quyền của một người dùng khi sử dụng phần mềm đã cho v1.5 sau khi anh ta nhận được giấy phép GPL / OSS.

NHƯNG.

Bạn có thể liên hệ với tác giả của phần mềm đã cho v1.5

  1. mua giấy phép thương mại với quyền sửa đổi và phân phối lại nguồn đóng
  2. mua quyền của anh ấy trên phần mềm từ anh ấy

    (điều này không áp dụng trong tất cả các khu vực pháp lý - ở nhiều quốc gia, một số quyền không thể thay đổi - điều này có nghĩa là tác giả luôn giữ những quyền đó và anh ta chỉ có thể cấp phép cho bạn)

    Ah, vì bạn đã ở đó, bạn cũng có thể quan tâm đến việc mua quyền đối với tên của sản phẩm.

Sau đó, bạn có thể phát hành các phiên bản tiếp theo (giả sử là phần mềm 2.0 ) theo giấy phép thương mại và chỉ để lại phiên bản trước miễn phí. (như trong bài phát biểu miễn phí)

Một số dự án OSS tiếp tục bán các phiên bản mới và phát hành phiên bản trước dưới dạng mã nguồn mở, tại mỗi phiên bản nâng cấp chính.

(Tôi đang nghĩ Ghostscript ở đây, nhưng Android cũng đã được biết là làm một cái gì đó tương tự, công cụ phát hành trước cho các đối tác quan tâm, với giá rất đắt)

Điều gì có thể đi sai

  1. Cuộc thi. Một ngã ba OSS lớn + đổi tên có thể chỉ đơn giản là giết chết sản phẩm thương mại mới, (đó là một thị trường tự do)

  2. Người bảo trì có thể không có tất cả các quyền anh ta cần để cấp phép lại cho phần mềm đã cho 1.5

    • Tác giả ban đầu không thể có sẵn: người duy trì hiện tại có thể là người duy trì thứ hai, hoặc thứ ba hoặc thứ tư sau người duy trì ban đầu.
    • Dự án có thể đã nhận được quá nhiều sửa lỗi bên ngoài, hoặc bổ sung tính năng và người bảo trì không bao giờ bận tâm đến việc xin miễn, vì vậy phần mềm này thực sự thuộc sở hữu của người bảo trì và mọi người đã từng đóng góp bất kỳ mã nào . Theo các điều khoản không xác định .

      Một mớ hỗn độn không thể diễn giải thực sự chỉ chờ đợi một luật sư có thời gian để đốt cháy và một công ty đáng để vắt tiền. (trên thực tế, ngay cả dự án GNU luôn yêu cầu các miễn trừ khắc phục tất cả bản quyền đối với nền tảng GNU)

    • Miễn trừ có thể đã được ký, nhưng các điều khoản về chúng có thể nêu chính xác giấy phép về mã không bao giờ có thể thay đổi .

Trong hai tình huống cuối cùng, cách duy nhất để thoát khỏi OSS là một bản viết lại khó khăn, to lớn, đẫm máu và buồn bã của tất cả các mã đóng góp. Và ngay cả khi được thực hiện đúng và tốt, nó vẫn có thể bị thách thức, (bởi luật sư đó , vâng) vì vậy ... nó thực sự không đáng.

Tuyên bố miễn trừ trách nhiệm: IANAL.


Và vâng, đây là lý do tại sao nó khó có thể đóng góp cho cơ sở mã Android chính. Họ chỉ không thể chấp nhận các bản sửa lỗi và vẫy cờ OSS chỉ cho giá trị từ thông dụng của nó . (vâng, nó thật tệ)
ZJR

2
IANAL. Những người đóng góp Android phải ký một "Thỏa thuận cấp phép cộng tác viên doanh nghiệp", điều này mang lại hiệu quả cho "lãnh đạo dự án" một giấy phép bản quyền để thực hiện bất kỳ điều gì họ muốn với mã của bạn.
Jaydee

3

IANAL nhưng:

Tôi nghĩ rằng nếu bạn sở hữu tất cả bản quyền đối với cơ sở mã, tức là tất cả những người đóng góp đã trao cho bạn (hoặc công ty của bạn nhiều khả năng) bản quyền cho tất cả các đóng góp của họ, thì bạn có thể phát hành lại cơ sở mã đó theo một giấy phép khác (có thể là một nguồn đóng) nếu bạn chọn. Một số dự án ( như jQuery ) phát hành mã của họ theo hai giấy phép khác nhau cùng một lúc (một trong số đó là GPL).

Điều này không thay đổi giấy phép của bất kỳ phiên bản mã hiện có nào và khi làm như vậy, bạn có thể thấy những người đóng góp của mình cảm thấy khá khó chịu, từ bỏ dự án và tiếp tục phát triển nó dưới một tên khác. Đừng trích dẫn tôi về điều này nhưng tôi nghĩ đó là loại điều đã dẫn đến Libre Office so với Open Office.


0

Nếu bạn là người giữ quyền của dự án, bạn có quyền đặt giấy phép (duy nhất) cho mỗi bên mà bạn phân phối nguồn của mình.

Bây giờ được cho rằng bạn đã cung cấp cho ai đó một mã với GPL, những gì anh ấy / cô ấy sở hữu không thể bị thu hồi trừ khi mã được phân phối theo một số điều kiện.

Ví dụ, Open Office là nguồn mở (và vẫn là). Nhưng kể từ khi Oracle mua lại Sun, mọi người cảm thấy rằng OO có thể quá chặt chẽ nên họ có thể bắt đầu sửa đổi mã đó một cách độc lập dưới tên của Libre Office và Oracle không thể thu hồi quyền đó.

Tuy nhiên, có hai điều bạn luôn có thể làm:

  1. Đính kèm giấy phép theo một số điều kiện. Ví dụ: bạn có thể có giấy phép thương mại khác với Nguồn mở, điều này chỉ khi bạn là một dự án nguồn mở (hoặc NGO / Academia).

  2. Đối với tất cả các phiên bản mới, bạn vẫn có thể ngừng giấy phép cũ và cung cấp một giấy phép mới. Ví dụ, REDHAT 7 (hoặc 8) là tất cả nguồn mở. Sau đó, họ đã tạo ra RHEL được cấp phép thương mại. Đây là cách Fedora được sinh ra.

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.