MIT so với BSD so với Giấy phép kép


87

Hiểu biết của tôi là:

  • Các dự án được cấp phép của MIT có thể được sử dụng / phân phối lại trong các dự án được cấp phép BSD .
  • Các dự án được cấp phép BSD có thể được sử dụng / phân phối lại trong các dự án được MIT cấp phép.
  • Các giấy phép điều khoản 2 của MIT và BSD về cơ bản là giống hệt nhau .
  • BSD 3-mệnh đề = BSD 2 mệnh đề + mệnh đề "không chứng thực"
  • Cấp giấy phép kép cho phép người dùng chọn trong số các giấy phép đó, không bị ràng buộc với cả hai.

Nếu tất cả những điều trên là chính xác, thì điểm quan trọng của việc sử dụng giấy phép MIT / BSD kép là gì? Ngay cả khi BSD đề cập đến phiên bản 3 điều khoản, thì người dùng có thể chọn hợp pháp chỉ tuân theo giấy phép MIT không?

Có vẻ như nếu bạn thực sự muốn áp dụng điều khoản "không chứng thực" thì bạn phải cấp phép cho nó chỉ là BSD (không phải kép). Nếu bạn không quan tâm đến điều khoản "không có chứng thực", thì chỉ riêng MIT là đủ và MIT / BSD là dư thừa.

Tương tự như vậy, kể từ khi giấy phép MIT và BSD đều " GPL tương thích " và có thể được phân phối lại trong GPL -licensed dự án, sau đó hai cấp giấy phép MIT / GPL cũng dường như không cần thiết.


1
Bạn có thể cung cấp một ví dụ giấy phép MIT + BSD không? Nó thường dự phòng giấy phép kép theo hai giấy phép cho phép tương tự nhau, nhưng tôi đã thấy việc cấp phép kép bị lạm dụng như một cách để tuyên bố rõ ràng rằng mã có thể được phân phối lại theo từng giấy phép.
yannis

@Yannis Yea Tôi tự hỏi nếu mọi người cấp phép kép cho họ chỉ rõ ràng hơn cho những người không biết. Nhưng tôi nghĩ rằng nó chỉ làm cho nó thêm khó hiểu cho họ.
ryanve



1
Theo kinh nghiệm của tôi, mọi người chủ yếu sử dụng giấy phép kép cho các giấy phép không tương thích. ví dụ: MPL + (L) GPL hoặc giấy phép phải trả tiền không có bản sao cùng với (A) GPL.
CodeInChaos

Câu trả lời:


60

Hiểu biết của tôi là:

  1. Các dự án được MIT cấp phép có thể được sử dụng / phân phối lại trong các dự án được cấp phép BSD.
    TRUE (nhưng trừ khi có sửa đổi, người dùng cũng có thể lấy nó từ các nguồn ban đầu.

  2. Các dự án được cấp phép BSD có thể được sử dụng / phân phối lại trong các dự án được MIT cấp phép. Giấy phép
    FALSE MIT cho phép phân phối mà không cần tín dụng đóng góp; BSD không.

  3. Các giấy phép điều khoản 2 của MIT và BSD về cơ bản là giống hệt nhau.
    SAI Xem ở trên.

  4. BSD 3-mệnh đề = BSD 2 mệnh đề + mệnh đề "không chứng thực"
    TRUE

  5. Cấp giấy phép kép cho phép người dùng chọn trong số các giấy phép đó mà không bị ràng buộc với cả hai.
    ĐÚNG (tôi nghĩ vậy!)

Tương tự, vì giấy phép MIT và BSD đều "tương thích GPL" và có thể được phân phối lại trong các dự án được cấp phép GPL, nên cấp phép kép MIT / GPL cũng có vẻ dư thừa.

NO . Đây là một sự khác biệt lớn. Giấy phép MIT và Giấy phép Apache chỉ yêu cầu bạn cung cấp tín dụng cho chủ sở hữu bản quyền gốc. Nếu bạn chọn, bạn có thể phân phối lại nguồn; nhưng nếu bạn chọn bạn có thể giữ sản phẩm mới có nguồn gốc mà không cần mở mã. Do đó, có thể sử dụng mã được phát triển theo MIT và Apache - theo giấy phép thương mại.

Nếu bạn đã từng sử dụng mã với giấy phép dựa trên GPL và tình cờ sửa đổi nó, bạn phải phân phối mã sửa đổi của mình theo GPL. Nói cách khác, một khi bất kỳ cơ sở mã GPL nào được sử dụng trong một dự án và nếu bạn muốn xuất bản dưới dạng sản phẩm, nó phải được xuất bản cùng với mã nguồn và nó phải được xuất bản theo GPL. Nó không bao giờ có thể là giấy phép thương mại hoặc nguồn đóng và nó không thể là bất kỳ giấy phép nào khác ít nghiêm ngặt hơn GPL.

Ví dụ, có thể lấy mã giấy phép MIT, Apache hoặc BSD, được sửa đổi và phân phối theo GPL. Khi một cơ sở mã được phân phối dưới dạng GPL, các phiên bản dẫn xuất tiếp theo của nó không thể được phân phối theo giấy phép MIT, Apache hoặc BSD mà chỉ phải là GPL.

Chỉnh sửa:
Ví dụ trường hợp giấy phép kép: Giả sử Nice Office được phát hành theo giấy phép kép - MIT và GPL. Nó có hai khả năng. Một số người có thể tạo NicePro Office, có thể thương mại và bán. Trong khi đó một số cộng đồng nguồn mở khác tạo ra một văn phòng NiceOpen ngã ba. Trong trường hợp này, nó có thể thực thi theo phân phối GPL (của phiên bản Nice Office ban đầu cũng như NiceOpen Office) do đó nếu bạn bắt đầu với NiceOpen Office, bạn phải tuân thủ chỉ GPL và không phải giấy phép MIT.

Vấn đề là trong trường hợp giấy phép kép, người đầu tiên nhận được giấy phép có một sự lựa chọn. Anh ta có thể chọn một trong hai cách - tuy nhiên, người thứ hai cần tuân thủ sự lựa chọn của người đầu tiên. Anh ấy / cô ấy không thể ghi đè các quyền ban đầu của một trong hai thế hệ và dù sao cũng không thể làm giảm nghĩa vụ của giấy phép áp dụng.

EDIT 2 Thêm một bài đọc thú vị - Giấy phép GPL và MPL ​​có mâu thuẫn nghiêm trọng. Đọc này. http://www.tomhull.com/ocston/docs/mozgpl.html


4
@Dipan Nếu một dự án được cấp phép kép theo MIT / GPL, thì nó có thể được sử dụng trong dự án độc quyền b / c, người dùng có thể chọn chỉ theo dõi MIT. Nếu một dự án chỉ giữ giấy phép MIT, thì nó có thể được phân phối lại theo các giấy phép khác bao gồm GPL. Đó là những gì tôi có nghĩa là dư thừa.
ryanve

11
@DipanMehta Bạn có ý nghĩa gì khi "tín dụng đóng góp" trong # 2? Có vẻ như bạn đang đề cập đến giấy phép 4 điều khoản BSD, điều này không được xác minh bởi FSF như điều khoản 3 và điều khoản 2. Tôi đang nói về các mệnh đề 3 và 2 mệnh đề, trong trường hợp đó tôi khá chắc chắn rằng tất cả năm câu đều đúng .
ryanve

4
Bạn có thể sử dụng mã được cấp phép BSD kết hợp với mã được cấp phép của MIT; bạn chỉ cần đề cập đến trong các tài liệu của dự án rằng "BazApp sử dụng libfoobar, được phân phối theo giấy phép BSD" hoặc đại loại như thế. Các giấy phép BSD và MIT được áp dụng trên mỗi tệp, thay vì theo từng dự án ,.
mipadi

10
@Dipan_Mehta Như ryanve đã nói với bạn, bạn đang nói về giấy phép BSD 4 điều khoản ban đầu, trong khi OP đang nói về giấy phép BSD 3 và 2 điều khoản đã sửa đổi. Giấy phép BSD 2 điều khoản thực sự tương đương với giấy phép MIT. Ngay cả trang OSI cũng nói như vậy.

17
Điểm # 2 (mã BSD không thể được bao gồm trong mã MIT) chạy ngược lại với mọi thông tin tôi từng đọc về BSD 3 mệnh đề và 2 mệnh đề. Điểm # 2 sẽ đúng về BSD 4 mệnh đề (hiện tại và bị lãng quên), nhưng OP đã nói rõ câu hỏi này không phải là về BSD 4 mệnh đề. Có vẻ khá có hại khi có một thông tin cực kỳ sai lệch như vậy trong một câu trả lời rất tốt và đáng tin cậy.
apsillers

4

Năm điểm của bạn đều đúng .

Câu trả lời khác dường như giả sử bạn đang bao gồm giấy phép BSD 4 điều khoản cũ, hiếm khi được sử dụng .

Nếu bạn diễn giải "giấy phép BSD" khi đề cập đến các biến thể 3 mệnh đề hoặc 2 mệnh đề được sử dụng phổ biến hơn của giấy phép BSD, thì tất cả năm khiếu nại trong câu hỏi đều đúng.

Nếu tất cả những điều trên là chính xác, thì điểm quan trọng của việc sử dụng giấy phép MIT / BSD kép là gì?

Về mặt kỹ thuật nên không cần nó. Hoặc có thể được sử dụng trong các tình huống tương tự.

Ngay cả khi BSD đề cập đến phiên bản 3 điều khoản, thì người dùng có thể chọn hợp pháp chỉ tuân theo giấy phép MIT không?

Nghe có vẻ đúng.

Có vẻ như nếu bạn thực sự muốn áp dụng điều khoản "không chứng thực" thì bạn phải cấp phép cho nó chỉ là BSD (không phải kép). Nếu bạn không quan tâm đến điều khoản "không có chứng thực", thì chỉ riêng MIT là đủ và MIT / BSD là dư thừa.

Đúng rồi. Nếu bạn quan tâm đến điều khoản cụ thể đó, sẽ không có ý nghĩa gì khi cấp phép cho cùng một công việc theo giấy phép mà không có điều khoản đó.

Tương tự, vì giấy phép MIT và BSD đều "tương thích GPL" và có thể được phân phối lại trong các dự án được cấp phép GPL, nên cấp phép kép MIT / GPL cũng có vẻ dư thừa.

Đúng.

Mặc dù, đôi khi một sản phẩm phần mềm sẽ tuyên bố là được cấp phép kép là MIT và GPL (hoặc một số giấy phép cho phép và GPL), nhưng thực tế họ đang đề cập đến hai phiên bản phần mềm khác nhau.

Ví dụ, một số phần mềm có thể được biên dịch và phân phối với giấy phép cho phép như BSD hoặc MIT, nhưng nếu bạn bỏ qua một số thư viện và do đó một số chức năng, nó có thể được phân phối dưới dạng GPL. Các thư viện bị bỏ qua thường sẽ là các thư viện bên thứ ba không tương thích GPL nhưng vẫn có thể được phân phối.

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.