Die LGPL und Java

von David Turner

---

Es ist immer die Position der FSF gewesen, dass dynamisch verknßpfte Anwendungen zu Bibliotheken ein einziges Werk aus abgeleiteten Bibliotheks- und Anwendungscode erstellt. Die GPL verlangt, dass alle abgeleiteten Werke als Ganzes unter der GPL lizenziert werden, ein Effekt, der als erblich beschrieben werden kann. Wenn also eine Anwendung auf eine GPL lizenzierte Bibliothek verweist, muss die Anwendung auch unter der GPL lizenziert werden. Im Gegensatz dazu kÜnnen unter der GNU Lesser General Public License (LGPL) lizenzierte Bibliotheken mit proprietären Anwendungen verknßpft werden.

Im Juli 2003 veröffentlichte Slashdot eine Geschichte, ich hätte behauptet, dass die LGPL für Java nicht bestimmungsgemäß funktionierten würde. Diese Geschichte basierte auf einem Missverständnis einer Antwort auf eine an licensing@gnu.org gesendete Frage, und viele Versuche, die Angelegenheit in der Slashdot-Geschichte zu klären, konnten nicht vermittelt werden. Ich habe seitdem zahlreiche Fragen zu dieser Geschichte, sowohl über licensing@gnu.org als auch über meine persönliche E-Mail-Adresse, erhalten.

Die Position der FSF blieb durchweg unverändert: Die LGPL ist mit allen bekannten Programmiersprachen, einschließlich Java, wie beabsichtigt anwendbar. Anwendungen, die auf LGPL-Bibliotheken verweisen, mĂźssen nicht unter der LGPL freigegeben werden. Anwendungen mĂźssen nur den Anforderungen in Abschnitt 6 der LGPL folgen: erlauben, neue Versionen der Bibliothek mit der Anwendung verbinden zu kĂśnnen; und Nachkonstruktionen ‚Reverse Engineering‘ erlauben, um dies diagnostizieren ‚debuggen‘ zu kĂśnnen.

Der typische Aufbau von Java ist, dass jede Bibliothek, welche von einer Anwendung benutzt wird, als separate JAR-Datei (Java Archive) verteilt wird. Anwendungen verwenden Javas Import-Funktionalität, um auf Klassen aus diesen Bibliotheken zuzugreifen. Wenn die Anwendung kompiliert wird, werden Funktionssignaturen gegen die Bibliothek ßberprßft und stellen eine Verknßpfung her. Die Anwendung ist dann im Allgemeinen ein abgeleitetes Werk der Bibliothek. So muss der Copyright-Inhaber der Bibliothek die Verbreitung des Werkes genehmigen. Die LGPL gestattet diese Verbreitung.

Wenn Sie eine Java-Anwendung vertreiben, die LGPL lizenzierte Bibliotheken importiert, ist es leicht, die LGPL einzuhalten. Die Lizenz Ihrer Anwendung muss Nutzern erlauben, die Bibliothek zu modifizieren und den Quellcode nachzuentwickeln ‚Reverse Engineering‘, um diese Änderungen zu diagnostizieren ‚debuggen‘. Das bedeutet nicht, dass Sie den Quellcode bereitstellen oder irgendwelche Details Ăźber die Interna Ihrer Anwendung bereitstellen mĂźssen. NatĂźrlich kĂśnnen durch ein paar Änderungen von Nutzern an der Bibliothek die Schnittstelle unterbrochen werden, wodurch sie nicht mehr mit Ihrer Anwendung zusammenarbeitet. Sie brauchen sich keine Sorgen zu machen ‑ Menschen, die die Bibliothek modifizieren sind dafĂźr verantwortlich, dass es funktioniert.

Wird die Bibliothek mit Ihrer Anwendung (oder eigenständig) vertrieben, muss das den Quelltext der Bibliothek umfassen. Doch verlangt Ihre Anwendung stattdessen von Nutzern, sich die Bibliothek allein zu besorgen, müssen Sie den Quellcode der Bibliothek nicht zur Verfügung stellen.

Aus Sicht der LGPL ist der einzige Unterschied zwischen Java und C, dass Java eine objektorientierte Sprache ist, die Vererbung unterstßtzt. Die LGPL enthält keine besonderen Bestimmungen fßr die Vererbung, da keine benÜtigt werden. Vererbung erstellt abgeleitete Werke auf die gleiche Weise wie die herkÜmmliche Verknßpfung und die LGPL gestattet diese Art eines abgeleiteten Werkes auf die gleiche Weise, wie es gewÜhnliche Funktionsaufrufe zulässt.