Tue 07 Feb 2012 11:00:33 AM UTC, original submission:
Hi,
inline is a correction of the german translation from the website
http://www.gnu.org/licenses/lgpl-java.html.
Most of the translation is copied from the already existing translation.
My English is not very good, but some passages in the text were
definetely wrong. And there were also a few serious issues like the
missing "not" (German: nicht) in the part with the non existent
requirement for distributing the source of the library, if the
application requires the user to obtain the library on his/her own.
Greetings
Amir
GNU LGPL und Java
von David Turner
Dieser Artikel wurde im November 2004 geschrieben, als die LGPLv2.1 die
aktuelle Version der Lizenz war. Seitdem wurde LGPLv3 veröffentlicht.
Die wichtigsten Punkte dieses Artikels bleiben sich bezüglich LGPLv3
treu, aber einige Details, wie Abschnittsnummern, haben sich geändert.
Es ist immer die Position der FSF gewesen, dass dynamisches Verknüpfen
von Anwendungen mit Bibliotheken ein einziges Werk aus abgeleitetem
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, in der behauptet
wurde, ich hätte behauptet, dass die LGPL im Falle Java nicht
bestimmungsgemäß funktionieren würde. Diese Geschichte basierte auf
einem Missverständnis einer Antwort auf eine an -unavailable-
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
-unavailable- 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: sie müssen es erlauben,
neue Versionen der Bibliothek mit der Anwendung verbinden zu können; und
sie müssen das Reverse Engineering erlauben um dies "debuggen" zu können.
Die typische Aufbau für 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“. Dies 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.
Wenn Sie die Bibliothek mit der Anwendung (oder eigenständig)
vertreiben, müssen Sie auch den Quelltext der Bibliothek ausliefern.
Aber wenn die Anwendung stattdessen von Nutzern verlangt, 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 in der gleichen
Weise wie die herkömmliche Verknüpfung und die LGPL gestattet diese Art
eines abgeleiteten Werks auf die gleiche Weise, wie sie auch gewöhnliche
Funktionsaufrufe zulässt.
|