it-swarm.com.de

Mozilla Public License (MPL 2.0) gegen Lesser GNU General Public License (LGPL 3.0))

Ich möchte eine Softwarebibliothek veröffentlichen, die in einer klassenbasierten, objektorientierten Programmiersprache geschrieben ist (Java) auf einem webbasierten Quellcode-Hosting-Service , damit Gabeln des Projekts mit dem Hauptprojekt zusammengeführt werden können (GitHub über Pull-Anfragen). Ich habe im Internet recherchiert und viel darüber nachgedacht, wie ich die Software lizenzieren kann. Bin ich in den folgenden Annahmen richtig (aus einer IANAL Perspektive)?

  • Sowohl LGPL als auch MPL fördern das Teilen von Änderungen für die LGPL/MPL-lizenzierte Software, die in anderen Softwareprojekten verwendet wird. Anstatt von den Benutzern der geänderten Bibliothek zu verlangen, dass sie eine separate Abzweigung hosten der Bibliothek, kann ich zum Original beitragen Bibliothek fördern (z. B. über Pull-Anfragen) .

  • Der Hauptunterschied besteht darin, wie MPL/LGPL-Lizenzcode in das Projekt eingebunden werden muss. MPL-Quellcodedateien können direkt in ein (möglicherweise) proprietäres Softwareprojekt kopiert werden ( statische Verknüpfung), während LGPL-lizenzierter Code dynamisch verknüpft sein muss (lose verknüpft) an das möglicherweise proprietäre Softwareprojekt, damit Endbenutzer die lizenzierte Softwarebibliothek gegen eine andere Version der lizenzierten Softwarebibliothek austauschen können).

  • Dynamische Verknüpfung und damit LGPL stellt zusätzliche Hindernisse für das Verpacken das proprietäre Softwareprodukt dar, ohne mehr Beiträge zur Open-Source-Softwarebibliothek zu fördern als durch statische Verknüpfung (und damit MPL). Es gibt eine modifizierte LGPL , die eine statische Verknüpfung ermöglicht.

  • Es gibt keine anderen relevanten Unterschiede (aus einer IANAL Perspektive).

  • Die ältere Lizenzversionen entsprechen nicht meinen Anforderungen so gut wie die neuesten.

Wie Sie sehen, ist meine Hauptanforderung, dass Modifikationen der Softwarebibliothek, die sich für die breite Öffentlichkeit als nützlich erweisen könnte, Open Source bleibt, ohne die Verwendung der Softwarebibliothek in einem proprietären Produkt einzuschränken.
Es gibt keine Lizenz, die auch Erweiterungen der Softwarebibliothek erfordert, die für das Originalwerk relevant sind, um als Open Source veröffentlicht zu werden, als Umfang des Begriff relevant kann beliebig klein/groß sein und somit als GPL enden, die nicht in einem proprietären Produkt verwendet werden kann (ohne die gesamte Quelle freizugeben).

Ich bin versucht, die modifizierte LPGL zu verwenden, aber andererseits von der Unbeliebtheit entmutigt. Aufgrund der obigen Punkte bevorzuge ich MPL.
Frage : Sind meine obigen Aussagen korrekt? Welche Lizenz sollte ich unter Berücksichtigung meiner Anforderungen auswählen?


Lösung : Mit Hilfe der Diskussion in der akzeptierten Antwort bleibe ich wegen der Popularität, Freiheit beim Verknüpfen bei der MPL und weil es sich um eine offizielle, unveränderte Lizenz handelt.

25
mucaho

Ich glaube, Sie haben die Unterschiede zwischen der Mozilla Public License und der GNU Lesser General Public License genau angegeben, und beide können Ihren Anforderungen gut entsprechen, aber Sie überspringen der wichtigste Unterschied zwischen den beiden Lizenzen:

Wer kann neue Versionen machen?

Sowohl die MPL (Abschnitt 10) als auch die LGPL (Abschnitt 14) enthalten in ihrer Lizenz das Recht, die aktuelle Version durch eine letztere Version zu ersetzen, und es gibt keine tatsächlichen Einschränkungen hinsichtlich der Verwendung dieser Lizenzen. Während es höchst unwahrscheinlich ist, dass entweder die Mozilla Foundation oder die Free Software Foundation etwas so Verrücktes tun, wie beispielsweise eine Klausel einzuführen, die besagt, dass "alle Beiträge zu dieser Software unser Eigentum werden", ist es nicht jenseits des Bereichs der Möglichkeiten, dass einer der Organisationen veröffentlichen eine neue Lizenzversion, die Ihnen nicht gefällt.

Was einen weiteren Punkt zur Verwendung einer "modifizierten LGPL" aufwirft.


Eine geänderte Lizenz ist nicht dieselbe Lizenz!

Sie haben zwar eine erstaunliche Fähigkeit, Ihre eigenen Lizenzbedingungen anzugeben, und könnten im Wesentlichen sagen "Sie können dies gemäß der GPL verteilen, aber Sie müssen meinen Namen in Ihre Credits eintragen und mich bezahlen 1% aller Einnahmen, die Sie generieren ", jedes Mal, wenn Sie dies tun, erstellen Sie eine neue Lizenz basierend auf der Arbeit eines anderen. Dies bedeutet, dass Sie NICHT die MPL oder die LGPL verwenden, sondern eine neue "Mucaho-Lizenz".

Das bedeutet, dass Sie wahrscheinlich keine Hilfe vom Autor Ihrer ursprünglichen Lizenz erhalten, wenn Sie Ihre Interpretation der Lizenz in einem Gerichtssaal verteidigen müssen, und es ist durchaus möglich, dass sie Klage erheben, um zu sagen, dass IHRE Version gelten sollte und nicht deins.


Natürlich sind beide kleine Punkte. Selbst "Lizenzpopularität" spielt keine Rolle, es sei denn, Sie erwarten, dass Ihr Code direkt in größere Projekte integriert wird.

Persönlich denke ich, dass die MPL eine bessere Wahl ist, wenn Sie proprietäre Kompatibilität mögen oder wenn die Wahl zwischen der tatsächlichen MPL und einer anderen Lizenz liegt, die Sie basierend auf der LGPL manuell bearbeiten müssen. Wenn Sie keinen Grund haben, die MPL nicht zu verwenden, sollten Sie sich für etwas entscheiden, das von einer Stiftung unterstützt wird, anstatt für eine, die Sie ohne jegliche Hilfe in einem Gerichtssaal zurücklassen könnte.

15
DougM

Die Antwort von DougM und VRE macht einen fairen Punkt. MPLv2 und LGPLv3 sind mit statischen Ausnahmen hinsichtlich der Ereignisse, die den Copyleft auslösen würden, identisch. Ich denke jedoch, dass uns ein weiterer sehr wichtiger Unterschied zwischen LGPL und MPL fehlt. Wenn der Copyleft ausgelöst wird, gilt der Copyleft für:

  • für MPL: auf genau die gleichen Dateien Ihrer Originalbibliothek
  • für LGPL: zur "Arbeit basierend auf der Bibliothek" im Gegensatz zu der "Arbeit, die die Bibliothek verwendet". So kann die LGPL sein Copyleft möglicherweise auf neue Dateien erweitern.

Randfall: Durch die Verwendung von MPL können Benutzer ihre Verbesserungen nicht teilen

MPL ist eine Copyleft-Lizenz auf Dateiebene. Dies bedeutet, dass jemand, der es in ein größeres Projekt einbettet (statisch oder dynamisch) und Änderungen an Ihrer Datei vornimmt, nur die an dieser bestimmten Datei vorgenommenen Änderungen freigeben muss.

Wenn Sie Bedenken haben, die Integrität Ihrer Codebasis offen zu halten, gibt es Edge-Fälle, in denen dieser Copyleft-Effekt von MPL möglicherweise nicht ausreicht.

Zum Beispiel könnte jemand eine der Hauptdateien Ihres Projekts nehmen, "my_private_new_file importieren" Hinzufügen und Ihre Hauptmethode ändern, indem Sie beispielsweise "my_private_new_file.newAwesomeFeature.run ( ) ".

Auf diese Weise konnte er Ihrem Projekt neue Funktionen hinzufügen, während nur die geänderte Hauptdatei freigegeben wurde und die tatsächliche Logik der neuen Funktion in "my_private_new_file" geschlossen blieb.

Wenn Sie die Hauptdatei wieder in der Community haben, erhalten Sie nur die Information "Hey, Sie haben eine neue Funktion hinzugefügt", aber Sie können diese neue Funktion nicht offen einbinden ... Es kann ärgerlich sein, wenn die neue Funktion genau verfügbar ist - Bezogen auf das Problem, das Ihre Bibliothek zu lösen versucht.

Dies ist natürlich ein Edge-Fall, und es ist ziemlich unwahrscheinlich, dass jemand dies tun möchte, aber es ist ein Risiko, das Sie bei der Verwendung von MPLv2 berücksichtigen müssen.

Die LGPL wurde geschrieben, um solche Verhaltensweisen zu verbieten. Sehen:

Ich zitiere die ursprüngliche LGPL-Lizenz:

Achten Sie genau auf den Unterschied zwischen einer "Arbeit, die auf der Bibliothek basiert" und einer "Arbeit, die die Bibliothek verwendet". Ersteres enthält Code, der aus der Bibliothek stammt, während letzteres mit der Bibliothek kombiniert werden muss, um ausgeführt zu werden.

Das Copyleft gilt nur für die "Arbeit basierend auf der Bibliothek". Was ist nun eine "Arbeit basierend auf der Bibliothek" in der Praxis? Es lässt Raum für Interpretationen. Das ist nicht nur eine nette Sache, da es bedeutet, dass die Einhaltung Ihrer Lizenz komplizierter und daher beängstigender wird. Es könnte dazu führen, dass einige Leute Ihre Bibliothek einfach nicht benutzen.

In diesem Sinne ist LGPL restriktiver als MPL, schützt aber auch die Integrität des Projekts.

MPL erleichtert Benutzern aus der proprietären Welt das Reparieren und Verwenden Ihrer Bibliothek, während das Fix weiterhin freigegeben werden muss

Ein Vorteil für MPL ist, dass ein Benutzer, wenn er einen Fehler in Ihrer Bibliothek findet, diesen direkt in der Datei beheben kann, ohne seinen gesamten Code preisgeben zu müssen, sondern nur den Fix bereitstellen muss. Wenn er seine Arbeit an einen Kunden verteilt, kann er praktisch nur einen Link zu einem Zweig Ihres Projekts bereitstellen, der den Fix enthält, und er ist gut.

Durch die Verwendung von LGPL werden die Dinge komplizierter. Wenn jemand Ihr Projekt teilt, einen Fehler behebt und es statisch in seine proprietäre Software einbettet, muss er die "Arbeit basierend auf der Bibliothek" unter der LGPL an seine Benutzer verteilen. Das ist ein ziemlich dunkler Begriff, besonders wenn die Bibliothek statisch eingebettet ist ... In dieser Hinsicht war es meiner Meinung nach der ursprüngliche Grund, warum es in der ursprünglichen LGPL keine "statische" Ausnahme gibt. Es macht die Identifizierung der "Arbeit basierend auf der Bibliothek" trivial: Es ist die dynamische Bibliothek, die Sie in Ihrer proprietären Software aufrufen.

Infolgedessen macht es MPL proprietären Anbietern interessanterweise einfacher, Fix zu verwenden UND an Ihre Bibliothek zu senden als LGPL.

Gleichzeitig verfügen proprietäre Anbieter in den meisten Fällen weder über die Ressourcen noch über die Zeit, um in Ihre komplizierte Bibliothek einzutauchen, und würden dies höchstwahrscheinlich nicht selbst beheben. Sie möchten lieber ein Problem in Ihrem GitHub-Repo öffnen oder eine E-Mail in der Mailingliste senden und auf Ihre Korrektur warten.

In dieser Hinsicht erzwingt LGPL mehr diese Art von Verhalten. Aber ist die Durchsetzung wirklich notwendig?

Fazit

Die Wahl zwischen LGPL und MPL ist eine schwierige Frage und hängt, wie bei Softwarelizenzen üblich, von Ihrem Ziel ab. Beide Lizenzen sind sehr ähnlich, aber gleichzeitig sehr unterschiedlich. Sie wurden für sehr unterschiedliche Ziele und Philosophien entwickelt.

LGPL wurde von der Free Software Foundation entwickelt, um die weit verbreitete Verwendung von Bibliotheken für freie Software in der proprietären Welt zu ermöglichen, wobei jedoch stets die Idee berücksichtigt wurde, freie Software zu fördern und gegen proprietäre Software zu kämpfen. Es ist alles Teil einer Strategie in Richtung ihrer Ideologie. Siehe: https://www.gnu.org/licenses/why-not-lgpl.html

MPL ist eine praktische Lizenz, die von Mozilla entwickelt wurde, um eine Art von Share-Alike für die ursprüngliche Bibliothek zu erzwingen und gleichzeitig die Benutzer zu ermutigen, proprietäre Software und Add-Ons (einschließlich Mozilla selbst) zu erstellen. Dies ist eine Praxis, die die FSF über die LGPL genehmigt, aber dennoch als schädlich erachtet.

Im Wesentlichen wird MPLv2 von vielen als zulässige Lizenz angesehen, während LGPLv3 einschließlich mit statischen Ausnahmen selten so genannt wird.

BEARBEITEN

Ich habe vergessen, etwas Wichtiges zu erwähnen. LGPLv3 (mit oder ohne statische Ausnahme) verbietet die Tivoisierung . Sie mögen denken, es sei ein "Detail", aber es ist tatsächlich nicht so, abhängig von Ihrem Ziel. Interessieren Sie sich für die Freiheit der Benutzer? Dann ist es kein Detail. Interessiert es Sie, dass Ihre Bibliothek auf Apples Gerät verwendet werden kann? VLC kümmert sich mehr um die Verwendung, also sie entschieden sich für LGPLv2 , das keine solche Einschränkung enthält. Ebenso ist dies einer der Gründe, warum Linux verwendet weiterhin GPLv2 . MPLv2 unterliegt auch keiner Einschränkung der Tiviozierung, da es sich offensichtlich um eine Lizenz handelt, die mit Blick auf die "praktischere" Open Source-Philosophie erstellt wurde, nicht auf die FSF-Ideologie.

Es könnte andere "kleinere" Dinge wie diese geben, die ich verpasst habe.

6
N. Gimenez