Chọn giấy phép cho các dự án nguồn mở


30

Tôi đã thực hiện một số dự án nguồn mở và tôi dự định sẽ làm nhiều hơn trong tương lai. Cho đến nay, tôi đã phát hành tất cả mã của mình theo GPL, nhưng tôi đã đọc một vài bài viết cho rằng GPL quá hạn chế đối với bất kỳ mã nào được sử dụng trong môi trường công ty. Điều này, được cho là, làm giảm đóng góp.

Đây là những gì tôi muốn thực hiện:

Đối với các ứng dụng đầy đủ :

  • không sử dụng cho mục đích thương mại ngoại trừ hỗ trợ bán cho ứng dụng (nghĩa là không thể bán ứng dụng, nhưng mọi thứ xung quanh đều có thể)

Đối với thư viện (thành phần, plugin, ...):

  • có thể được đưa vào các dự án thương mại mà không cần sửa đổi
  • mọi sửa đổi thư viện / thành phần phải được mở nguồn (đóng góp lại) - phần còn lại của dự án, thương mại hay không, không bị ảnh hưởng

Đối với các ứng dụng, GPL vẫn có vẻ là sự lựa chọn hợp lý. Đối với các thư viện, sự hiểu biết sơ khai về giấy phép của tôi khiến tôi nghĩ rằng LGPL là một kết hợp tốt, nhưng, tôi không chắc chắn. Tôi đã xem giấy phép MIT và điều đó dường như quá dễ dãi.

Hầu hết thời gian, tôi muốn mọi người sử dụng mã của mình ở bất cứ đâu họ muốn, miễn là mọi cải tiến đều được đóng góp lại.

Điều này đưa tôi đến (các) câu hỏi của tôi: LGPL có phải là lựa chọn hợp lý cho các thư viện, thành phần, plugin nguồn mở không? Có một lựa chọn tốt hơn? GPL là một lựa chọn tốt cho các ứng dụng của tôi hay có điều gì tốt hơn?

Cập nhật:

Đối với những người quan tâm đến quyết định cuối cùng của tôi, tôi đã quyết định phát hành thư viện của mình theo chương trình đa giấy phép, MPL, LGPL và GPL. Điều này cho phép hầu như tất cả mọi người sử dụng mã của tôi mà không có nghĩa vụ, trừ khi họ sửa đổi nó theo MPL, trong trường hợp đó nó sẽ phải được đóng góp lại.

Điều này có nghĩa là mã có thể được sử dụng bởi cả FSF và phần mềm độc quyền, nhưng việc khai thác thương mại "xấu" bị ngăn chặn (hoặc vì vậy tôi muốn nghĩ).


1
Bạn có nghĩa là không sử dụng thương mại hoặc không phân phối / bán lại thương mại ?
MIA

Có lẽ là phân phối / bán lại. Tôi sẽ không phiền nếu mọi người sử dụng công cụ của tôi một cách thương mại, nhưng tôi đoán điều đó sẽ phụ thuộc vào dự án. Mặc dù tôi không thấy cách sử dụng bất cứ thứ gì tôi đã viết cho đến nay cho mục đích thương mại ..
dr Hannibal Lecter

4
Điều quan trọng cần lưu ý là (trái với một số câu trả lời) Câu hỏi thường gặp về Creative Commons nêu rõ các giấy phép CC không nên được sử dụng cho phần mềm. (Sự cống hiến trong miền công cộng Muff được chấp thuận để sử dụng với phần mềm nhưng sẽ không phù hợp với các mục đích đã nêu trong câu hỏi ban đầu.) Thay vào đó, CC khuyên bạn nên chọn giấy phép được phê duyệt bởi Tổ chức phần mềm miễn phí hoặc Sáng kiến ​​nguồn mở.
Peter Briggs

1
Tôi đoán là, trừ khi bạn nghĩ ra thứ gì đó thực sự độc đáo và hữu ích, cơ hội "thương mại hóa xấu" là rất nhỏ đến mức không đáng để dành thời gian để cố gắng ngăn chặn nó.
Bryan Oakley

1
Trong trường hợp ai đó quan tâm, có một đề xuất cho một trang web Hỏi & Đáp về cấp phép nguồn mở tại khu vực51: area51.stackexchange.com/proposeals/58715/ Lỗi
Kurt Pattyn

Câu trả lời:


8

Nghe có vẻ như GPL và LGPL là những gì bạn muốn cho các dự án của bạn.


Vì vậy, bạn sẽ nói rằng LGPL là một lựa chọn tốt cho yêu cầu của tôi? Tôi không phải là luật sư nên tôi chỉ kiểm tra :)
dr Hannibal Lecter

1
Tôi cũng không phải là luật sư, nhưng tôi nghĩ rằng LGPL chính xác là những gì bạn muốn cho một thư viện và GPL cho các ứng dụng đầy đủ.
thay thế

Bán ứng dụng GPL là hợp pháp. Bạn (về cơ bản) chỉ cần bao gồm mã nguồn và cung cấp cho khách hàng của bạn các quyền GPL giống như bạn có.
bdsl 17/03/2015

8
  • không sử dụng cho mục đích thương mại ngoại trừ hỗ trợ bán cho ứng dụng (nghĩa là không thể bán ứng dụng, nhưng mọi thứ xung quanh đều có thể)

Xin lưu ý rằng GPL không cấm bán ứng dụng và việc cấm này thực sự sẽ khiến giấy phép của bạn không miễn phí, như quan sát của Huperniketes. Điều duy nhất GPL đảm bảo là công ty bán phần mềm cũng sẽ phải cung cấp cơ sở mã miễn phí. Nhưng họ không phải cung cấp gói phần mềm miễn phí. Đó là một sự khác biệt khá lớn, vì mã nguồn của phần mềm không phải là một sản phẩm có thể sử dụng được.


Tôi thực sự ổn với điều đó, vì mã nguồn sẽ trôi nổi ở đâu đó và ai đó sẽ được hưởng lợi từ nó. ;)
dr Hannibal Lecter

Tôi thực sự không có được nó. Ý tôi là, nếu tôi có thể lấy các nguồn, tôi có thể biên dịch, và không có gì cấm tôi sử dụng nó, phải không?
Camilo Martin

@Camilo: những gì bạn không nhận được?
Konrad Rudolph

Phần 4 và 6b của GPL phiên bản 3 bao gồm những gì bạn đang nói @KonradRudolph
Rudolf Olah

Họ không phải cung cấp mã nguồn miễn phí nếu họ đưa nó vào gói khi họ bán ứng dụng.
bdsl 17/03/2015

5

Nếu bạn muốn ngăn chặn việc sử dụng phần mềm thương mại của mình, GPL sẽ không cắt phần mềm đó. GPL có xu hướng tránh được các doanh nghiệp thương mại trong các sản phẩm họ bán vì yêu cầu phân phối lại nguồn đã sửa đổi, nhưng họ có thể sử dụng phần mềm GPL trong nội bộ. Điều đó không có nghĩa là các doanh nghiệp không thiết lập để bán phần mềm GPL hoặc xây dựng phần cứng xung quanh phần mềm GPL (ví dụ LinkSys), nhưng hầu hết các doanh nghiệp không muốn chia sẻ sản phẩm của họ với các đối thủ cạnh tranh.

Tôi không biết giấy phép Creative Commons Ghi công phi thương mại không phải là giấy phép bạn muốn (hạn chế duy nhất bạn đề cập là sử dụng thương mại ), nhưng nếu không, bạn có thể cần phải có giấy phép chuẩn bị cho bạn bởi một luật sư có chứa các quyền cấp ngôn ngữ mà bạn muốn chủ sở hữu giấy phép phải có.

Ngoài ra, một khi bạn bắt đầu bao gồm các hạn chế như sử dụng phi thương mạikhông sửa đổi , bạn có thể không còn đáp ứng các tiêu chí cho giấy phép nguồn mở như được định nghĩa bởi Sáng kiến ​​nguồn mở . Trang web của họ cũng liệt kê các giấy phép OSS được phê duyệt khác . Có lẽ đã có một cái phù hợp với mục tiêu của bạn.

xác định đầy đủ mục tiêu của bạn sẽ là chìa khóa trước khi chọn các quyền và giới hạn bạn đặt cho người dùng phần mềm của mình. Sự phổ biến có quan trọng hơn khả năng sửa đổi hoặc phân phối hoặc sử dụng hay không? Hãy nghĩ về các mục tiêu của bạn trong việc phát hành mã để bắt đầu và theo tinh thần bạn làm điều đó hoặc các điều khoản mà bạn cấp quyền truy cập có thể có tác dụng ngược lại.


Doanh nghiệp sử dụng phần mềm GPL trong nội bộ không phải là sử dụng phần mềm thương mại ...
thay thế vào

3
@mathepic, các từ "kinh doanh" và "sử dụng" không tấn công bạn có giống với "sử dụng thương mại" không? định
nghĩa.uslegal.com / c / commIAL

@Huperniketes Không, họ không. Một doanh nghiệp sử dụng phần mềm (ví dụ: trình duyệt cơ sở dữ liệu) hoàn toàn giống với một người sử dụng phần mềm đó. Không có sự khác biệt, miễn là dự án không được tích hợp vào sản phẩm cuối cùng của doanh nghiệp.
thay thế

3
@mathepic, bạn không đúng. Một doanh nghiệp là một mối quan tâm thương mại - tồn tại vì lợi nhuận. Bất kỳ hoạt động nào nó tham gia là thương mại. Và thiết lập một máy chủ web chạy Apache để lưu trữ hướng dẫn sử dụng là sử dụng thương mại của Apache. Từ hoạt động, theo nghĩa pháp lý, là sử dụng , không phân phối , không bán hoặc bán lại .
Huperniketes

2
@dr, đó không phải là vi phạm vì giấy phép Apache không cấm sử dụng thương mại. apache.org/foundation/licence-FAQ.html#WhatDoesItMESE "Nó cho phép bạn: tự do tải xuống và sử dụng phần mềm Apache, toàn bộ hoặc một phần, cho mục đích cá nhân, nội bộ hoặc thương mại;"
Huperniketes

4

Nếu điều bạn quan tâm là đảm bảo mã của bạn được miễn phí, lấy lại các cải tiến và chắc chắn rằng bất kỳ ai cũng có thể sử dụng nó, thì MPL là giấy phép phù hợp với bạn. Nó được sử dụng miễn phí trong bất kỳ sản phẩm nào, kể cả phần mềm thương mại, không có các hạn chế liên kết phức tạp, kỳ quặc như LGPL áp đặt. Nó yêu cầu bất kỳ ai sử dụng mã của bạn và sửa đổi nó sẽ giải phóng các thay đổi theo MPL, nhưng nó không chạm hoặc hạn chế bất kỳ phần còn lại nào của mã trong dự án.


Tôi hoàn toàn không quen thuộc với MPL, nhưng nghe có vẻ rất thú vị. Cho đến nay, tôi chỉ phát hành mã PHP nên các hạn chế liên kết không phải là vấn đề, nhưng tôi cũng có kế hoạch phát hành một số mã Mono, MPL có thể rất hữu ích.
dr Hannibal Lecter

4

Nếu bạn đã viết tất cả mã của mình (nghĩa là, nếu bạn sở hữu mã của mình), bạn cũng có thể cấp phép kép : xuất bản mã của mình trong ví dụ GPLv3 và đề nghị bán nó (với một giấy phép khác) cho những người muốn sử dụng nó ít hạn chế hơn.

(điều này đặc biệt phù hợp với thư viện, vì thư viện GPL-ed chỉ có thể được sử dụng trên phần mềm GPL).

Hãy cẩn thận về các đóng góp bên ngoài hoặc các bản vá mà bạn kết hợp vào mã của mình (vì bạn không sở hữu chúng).


1

Việc bạn thực sự có thể nộp đơn xin MPL hay chỉ GPL tùy thuộc vào một sự khác biệt quan trọng:

"Quyền dưới đây" bao gồm quyền được cấp cho người nhận để liên kết MPL "Mã được bảo hiểm" với mã không phải MPL riêng để tạo thành "Công việc lớn hơn" (MPL 3.7 Công việc lớn hơn). GPL không cung cấp cho người nhận bất kỳ quyền như vậy. Do đó, người nhận không thể thay đổi các điều khoản cấp phép để áp dụng GPL thay vì MPL.

Xem này .

Điều này có ý nghĩa gì với bạn là nếu bạn đang sử dụng bất kỳ thành phần nào mà chính nó là GPL'ed, bạn (có thể) không thể phát hành mã (đang sử dụng mã này) theo MPL; MPL sẽ cố gắng sai khi cho phép phân phối lại mã GPL theo MPL không đúng. Điều này là tốt, nếu sự phụ thuộc của bạn theo thứ tự giấy phép MIT hoặc Apache.

Nói chung, nếu bạn là không làm tốt hơn bằng cách chọn MPL thay vì GPL trừ khi bạn đang sử dụng công cụ MPL. GPL cũng sẽ đảm bảo rằng các đóng góp cũng sẽ được công bố trở lại.

Chỉ có thay đổi quan trọng mà MPL ​​cung cấp là sự bảo vệ chống lại các vi phạm bằng sáng chế vô tình gây ra. Như giấy phép đặt nó:

Sẽ không ổn nếu ai đó tạo ra Sửa đổi mà người đó có bằng sáng chế, làm cho Sửa đổi có sẵn miễn phí theo yêu cầu trong Giấy phép, sau đó quay lại và cố gắng tính phí cho mọi người về quyền sáng chế.

MPL và GPL không tương thích hoàn toàn.

Bạn có thể xem ở đây: MIT so với BSD so với Giấy phép kép để thảo luận về hàm ý của giấy phép kép.


Không tương thích GPL đã được giải quyết với MPL v2.0. (Tôi đoán bài này đã được thực hiện trước khi v2.0 được phát hành). Xem tuyên bố của GNU trên MPLv2.0
mucaho

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.