Giấy phép Công cộng Mozilla (MPL 2.0) so với Giấy phép Công cộng GNU Ít hơn (LGPL 3.0)


23

Tôi muốn phát hành một thư viện phần mềm được viết bằng ngôn ngữ lập trình hướng đối tượng (Java) dựa trên lớp trên một dịch vụ lưu trữ mã nguồn dựa trên web , cho phép các nhánh của dự án được sáp nhập vào dự án chính (GitHub thông qua pull yêu cầu). Tôi đã nghiên cứu trên web và suy nghĩ rất nhiều về cách cấp phép cho phần mềm. Tôi có đúng trong các giả định sau ( theo quan điểm của IANAL ) không?

  • Cả LGPL và MPL ​​đều thúc đẩy chia sẻ các sửa đổi đối với phần mềm được cấp phép LGPL / MPL đang được sử dụng trong các dự án phần mềm khác. Thay vì yêu cầu người dùng của thư viện sửa đổi lưu trữ một ngã ba riêng biệt của thư viện, tôi có thể quảng bá đóng góp cho thư viện gốc (ví dụ: thông qua các yêu cầu kéo).

  • Sự khác biệt chính là cách mã được cấp phép MPL / LGPL phải được liên kết vào dự án. Các tệp mã nguồn MPL có thể được sao chép trực tiếp vào dự án phần mềm độc quyền (có thể) ( liên kết tĩnh ), trong khi mã được cấp phép LGPL phải được liên kết động (liên kết lỏng lẻo với dự án phần mềm độc quyền có thể để người dùng cuối có thể tắt phần mềm được cấp phép thư viện cho một phiên bản khác của thư viện phần mềm được cấp phép).

  • Liên kết động và do đó LGPL đặt ra những trở ngại thêm cho việc đóng gói sản phẩm phần mềm độc quyền, mà không thúc đẩy nhiều đóng góp cho thư viện phần mềm nguồn mở hơn là có liên kết tĩnh (và do đó là MPL). Có một LGPL được sửa đổi cho phép liên kết tĩnh.

  • Không có sự khác biệt có liên quan khác (từ góc độ IANAL ).

  • Các phiên bản giấy phép cũ không phù hợp với nhu cầu của tôi tốt như những phiên bản mới nhất.

Như bạn có thể thấy yêu cầu chính của tôi là sửa đổi thư viện phần mềm có thể chứng minh hữu ích cho công chúng ở dạng nguồn mở, mà không áp đặt các hạn chế trong việc sử dụng thư viện phần mềm trong một sản phẩm độc quyền.
Không có giấy phép nào yêu cầu các phần mở rộng của thư viện phần mềm có liên quan đến tác phẩm gốc được phát hành dưới dạng nguồn mở, vì phạm vi của thuật ngữ có liên quan có thể tùy ý nhỏ / lớn, do đó kết thúc là GPL không thể là được sử dụng trong một sản phẩm độc quyền (không phát hành toàn bộ nguồn).

Tôi muốn sử dụng LPGL đã được sửa đổi , nhưng mặt khác lại không được khuyến khích bởi sự phổ biến. Dựa trên những điểm trên tôi thích MPL.
Câu hỏi: Những tuyên bố trên của tôi có đúng không? Tôi nên chọn giấy phép nào khi xem xét các yêu cầu của tôi?


Giải pháp: Với sự giúp đỡ của cuộc thảo luận trong câu trả lời được chấp nhận, tôi chọn gắn bó với MPL vì sự phổ biến , tự do trong liên kết và vì đây là giấy phép chính thức, chưa được sửa đổi .



Một câu hỏi và trả lời bổ sung cho việc cấp phép phần mềm sẽ rất hữu ích theo quan điểm của tôi. Cảm ơn!
mucaho

1
Tôi không thực sự thấy một câu hỏi trong đó. Bạn có thể làm rõ câu hỏi thực tế của bạn là gì?
Bart van Ingen Schenau 14/12/13

Câu trả lời:


14

Tôi tin rằng bạn đã nêu chính xác sự khác biệt giữa Giấy phép Công cộng MozillaGiấy phép Công cộng GNU Ít hơn và có thể phù hợp với nhu cầu của bạn, nhưng bạn đang bỏ qua sự khác biệt quan trọng nhất giữa hai giấy phép:

Ai có thể tạo phiên bản mới?

Cả MPL (phần 10) và LGPL (phần 14) bao gồm trong giấy phép của họ cấp quyền thay thế phiên bản hiện tại bằng phiên bản sau và không có giới hạn thực tế nào về những giấy phép đó. Mặc dù rất khó có khả năng Mozilla Foundation hoặc Free Software Foundation sẽ làm điều gì đó điên rồ như, giả sử, đưa ra một điều khoản "tất cả các đóng góp cho phần mềm này trở thành tài sản của chúng tôi", nó không nằm ngoài khả năng là một trong những khả năng các tổ chức sẽ phát hành phiên bản giấy phép mới mà bạn không thích.

Điều này dẫn đến một điểm khác về việc sử dụng "LGPL đã sửa đổi".


Giấy phép sửa đổi không phải là giấy phép tương tự!

Mặc dù bạn có khả năng khá tuyệt vời để chỉ định các điều khoản cấp phép của riêng mình và về bản chất có thể nói rằng "bạn có thể phân phối điều này theo GPL, nhưng bạn cần ghi tên tôi vào tín dụng của bạn và trả cho tôi 1% cho bất kỳ doanh thu nào bạn tạo ra" , bất cứ khi nào bạn làm như vậy bạn sẽ tạo một giấy phép mới dựa trên công việc của người khác. Điều này có nghĩa là bạn KHÔNG sử dụng MPL hoặc LGPL, bạn đang sử dụng "giấy phép mucaho" mới.

Điều đó có nghĩa là bạn có thể sẽ không nhận được bất kỳ trợ giúp nào từ tác giả của giấy phép ban đầu nếu bạn cần bảo vệ việc giải thích giấy phép bên trong phòng xử án và hoàn toàn có thể họ có thể nộp đơn kiện để nói rằng phiên bản THEIR nên áp dụng và không phải của bạn.


Tất nhiên, cả hai đều là những điểm nhỏ. Ngay cả "mức độ phổ biến của giấy phép" cũng không thành vấn đề trừ khi bạn mong đợi mã của mình được tích hợp trực tiếp vào các dự án lớn hơn.

Cá nhân, tôi nghĩ rằng MPL là lựa chọn tốt hơn nếu bạn thích khả năng tương thích độc quyền hoặc nếu lựa chọn nằm giữa MPL thực tế và giấy phép khác mà bạn phải chỉnh sửa thủ công dựa trên LGPL. Trừ khi bạn có lý do để không sử dụng MPL, hãy sử dụng một cái gì đó được hỗ trợ bởi một nền tảng thay vì một thứ có thể khiến bạn phải ở trong phòng xử án mà không cần bất kỳ sự trợ giúp nào.


Theo như tạo ra các phiên bản mới, trường hợp của FSF tạo ra một điều khoản cho phép Wikipedia cung cấp lại nội dung như CC-SA là đáng lưu ý.
Christian

Cảm ơn! Chỉ để làm rõ: @DougM đã nói "Cả MPL (phần 10) và LGPL (phần 14) bao gồm trong giấy phép của họ cấp quyền thay thế phiên bản hiện tại bằng phiên bản sau" . Tôi vẫn có thể chọn nếu phần mềm của tôi vẫn được cấp phép theo phiên bản cũ hoặc nếu tôi muốn thay đổi sang phiên bản giấy phép mới hơn, phải không (xem phần MPL2.0 10.2)? Vì vậy, nếu tôi thay đổi quan điểm về các phiên bản mới một cách chính xác, chỉ những người dùng thư viện LPGL / MPL của tôi gặp bất lợi nếu tôi chọn chuyển sang phiên bản mới hơn và phiên bản mới hơn không phù hợp với họ?
mucaho

2
Cả LGPL và MPL ​​đều không có cơ chế thu hồi giấy phép. Khi ai đó có mã, đó là của họ theo các điều khoản của giấy phép đó mãi mãi . Và họ có thể chọn xem có tuân theo giấy phép còn tồn tại hay bất kỳ giấy phép kế nhiệm nào hay không. (Bạn có thể chuyển các bản phân phối mới lên phiên bản mới, nhưng bất cứ ai muốn đến ngã ba cna thực hiện như vậy ngay cả khi họ "ngã ba" không làm thay đổi một phần khác duy nhất của chương trình của bạn..)
DougM

Ah, cảm ơn đã làm rõ! Bạn có muốn giải thích "họ có quyền thay thế phiên bản hiện tại bằng phiên bản sau" không? Điều đó có nghĩa là (trong trường hợp không thể xảy ra), FSF có thể đưa ra một điều khoản có nội dung "tất cả các đóng góp cho phần mềm này trở thành tài sản của chúng tôi" vào LGPLv3.0 đã tồn tại ?
mucaho

1
Họ có thể thử , nhưng làm như vậy có lẽ sẽ không thành công. Tuy nhiên, họ có thể nói rằng "bạn có thể đánh cắp tên của bất kỳ dự án nào bạn chuyển sang LGPL4" hoặc một số phiên bản bất ngờ khác. (Họ có thể sẽ không làm điều đó, nhưng cả họ và Mozilla về mặt kỹ thuật COULD, mặc dù các tòa án có thể không cho phép họ thi hành một điều khoản như vậy.)
DougM

3

Câu trả lời của DougM và AER làm cho một điểm công bằng. MPLv2 và LGPLv3 với ngoại lệ tĩnh giống nhau về các sự kiện sẽ kích hoạt copyleft. Tuy nhiên, tôi nghĩ chúng ta đang thiếu một sự khác biệt rất quan trọng khác giữa LGPL và MPL. Khi copyleft được kích hoạt, copyleft áp dụng cho:

  • cho MPL: với các tệp rất chính xác của thư viện gốc của bạn
  • đối với LGPL: đối với "công việc dựa trên thư viện" trái ngược với "công việc sử dụng thư viện". Vì vậy, LGPL có khả năng có thể mở rộng copyleft của mình sang các tệp mới.

Case-case: Sử dụng MPL cho phép người dùng không chia sẻ các cải tiến của họ

MPL là một giấy phép copyleft cấp tập tin. Điều đó có nghĩa là nếu ai đó nhúng nó vào một dự án lớn hơn (tĩnh hoặc động) và thực hiện thay đổi cho tệp của bạn, anh ta chỉ phải phát hành thay đổi được thực hiện cho tệp cụ thể này.

Nếu bạn lo lắng về việc giữ tính toàn vẹn của cơ sở mã của mình mở, có những trường hợp cạnh trong đó hiệu ứng sao chép này của MPL có thể không đủ.

Ví dụ: ai đó có thể lấy một trong các tệp chính của dự án của bạn, thêm "nhập my_private_new_file" và sửa đổi phương thức chính của bạn chẳng hạn bằng cách thêm "my_private_new_file.newAw đũaFeature.run ()" .

Và bằng cách này, anh ta có thể thêm các tính năng mới vào dự án của bạn trong khi chỉ phát hành tệp chính đã sửa đổi và giữ logic thực tế của tính năng mới đóng trong "my_private_new_file" .

Việc đưa tệp chính trở lại cộng đồng chỉ cung cấp cho bạn thông tin rằng "hey bạn đã thêm một tính năng mới" nhưng nó không cho phép bạn kết hợp tính năng mới này trong mở ... Thật khó chịu nếu tính năng mới bị chặt chẽ liên quan đến vấn đề mà thư viện của bạn đang cố gắng giải quyết.

Rõ ràng, đó là một trường hợp cạnh và rất khó có ai đó muốn làm điều đó, nhưng đó là một rủi ro mà bạn phải nhận thức được khi sử dụng MPLv2.

LGPL được viết để cấm các hành vi đó. Xem:

Tôi trích dẫn giấy phép LGPL gốc:

Hãy chú ý đến sự khác biệt giữa "công việc dựa trên thư viện" và "công việc sử dụng thư viện". Cái trước chứa mã có nguồn gốc từ thư viện, trong khi cái sau phải được kết hợp với thư viện để chạy.

Copyleft chỉ áp dụng cho "công việc dựa trên thư viện". Bây giờ "công việc dựa trên thư viện" trong thực tế là gì? Nó để lại không gian để giải thích. Đó không chỉ là một điều tốt đẹp vì nó có nghĩa là việc tuân thủ giấy phép của bạn trở nên phức tạp hơn và do đó đáng sợ. Nó có thể dẫn một số người chỉ đơn giản là không sử dụng thư viện của bạn.

Theo nghĩa này, LGPL hạn chế hơn MPL, nhưng cũng bảo vệ tính toàn vẹn của dự án nhiều hơn.

MPL giúp người dùng từ thế giới độc quyền dễ dàng sửa thư viện của bạn và sử dụng nó, trong khi vẫn phải chia sẻ bản sửa lỗi

Một lợi thế cho MPL là nếu người dùng tìm thấy lỗi trong thư viện của bạn, anh ta có thể sửa nó trực tiếp trong tệp mà không phải đưa ra tất cả mã của mình mà chỉ cung cấp bản sửa lỗi. Thực tế mà nói, khi phân phối công việc của mình cho khách hàng, anh ta chỉ có thể cung cấp một liên kết đến một ngã ba của dự án của bạn có chứa bản sửa lỗi, và anh ta rất tốt.

Bằng cách sử dụng LGPL, mọi thứ phức tạp hơn. Nếu ai đó giả mạo dự án của bạn, sửa lỗi và nhúng nó vào phần mềm độc quyền của anh ta, anh ta phải phân phối cho người dùng của mình "công việc dựa trên thư viện" theo LGPL. Đó là một khái niệm khá mơ hồ, đặc biệt là khi thư viện được nhúng tĩnh ... Về vấn đề này, tôi nghĩ đó là lý do ban đầu tại sao không có ngoại lệ "tĩnh" trong LGPL gốc. Nó làm cho việc xác định "công việc dựa trên thư viện" trở nên tầm thường: đó là thư viện động mà bạn gọi trong phần mềm độc quyền của mình.

Do đó, MPL giúp các nhà cung cấp độc quyền dễ dàng sử dụng VÀ gửi bản sửa lỗi đến thư viện của bạn hơn LGPL.

Đồng thời, hầu hết các nhà cung cấp độc quyền không có tài nguyên cũng không có thời gian để đi sâu vào thư viện phức tạp của bạn và rất có thể họ sẽ không tự sửa nó. Họ thà mở một vấn đề trên repo GitHub của bạn, hoặc gửi e-mail trong danh sách gửi thư và chờ sửa chữa của bạn.

Về vấn đề này, LGPL thi hành nhiều loại hành vi này. Nhưng thực thi có thực sự cần thiết?

Phần kết luận

Lựa chọn giữa LGPL và MPL ​​là một câu hỏi khó và như thường lệ với giấy phép phần mềm, tùy thuộc vào mục tiêu của bạn. Cả hai giấy phép đều rất giống nhau nhưng đồng thời vô cùng khác nhau. Chúng được thiết kế cho các mục tiêu và triết lý rất khác nhau.

LGPL được Quỹ Phần mềm Tự do tạo ra để cho phép sử dụng rộng rãi các thư viện Phần mềm Tự do trong thế giới độc quyền nhưng luôn có ý tưởng thúc đẩy Phần mềm Tự do và chống lại phần mềm độc quyền. Tất cả là một phần của chiến lược hướng tới ý thức hệ của họ. Xem: https://www.gnu.org/licenses/why-not-lgpl.html

MPL là một giấy phép thực tế được Mozilla thiết kế để thực thi một số loại chia sẻ tương tự với thư viện ban đầu, trong khi vẫn khuyến khích mọi người tạo ra các phần mềm và tiện ích bổ sung độc quyền (kể cả chính Mozilla), đây là một hoạt động mà FSF ủy quyền LGPL nhưng vẫn coi có hại.

Về bản chất, MPLv2 được nhiều người coi là giấy phép cho phép, trong khi LGPLv3 bao gồm ngoại lệ tĩnh hiếm khi được gọi theo cách này.

CHỈNH SỬA

Tôi quên đề cập đến một cái gì đó quan trọng. LGPLv3 (có hoặc không có ngoại lệ tĩnh) cấm tivoization . Bạn có thể nghĩ rằng đó là một "chi tiết" nhưng thực tế không phải vậy, tùy thuộc vào mục tiêu của bạn. Bạn có quan tâm đến người dùng Tự do không? Sau đó, nó không phải là một chi tiết. Bạn có quan tâm rằng thư viện của bạn có thể được sử dụng trên thiết bị của Apple không? VLC quan tâm nhiều hơn đến việc sử dụng, vì vậy họ đã quyết định sử dụng LGPLv2 không có hạn chế đó. Tương tự, đó là một trong những lý do tại sao Linux tiếp tục sử dụng GPLv2 . MPLv2 cũng không có bất kỳ hạn chế tiviozation nào, rõ ràng vì đây là giấy phép được tạo ra với triết lý Nguồn mở "thực tế" hơn, không phải là ý thức hệ của FSF.

Có thể có những thứ "nhỏ" khác như thế này mà tôi đã bỏ lỡ.

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.