CVSROOT: /web/www
Module name: www
Changes by: GNUN <gnun> 12/02/08 01:27:13
Modified files:
licenses : lgpl-java.de.html
licenses/po : lgpl-java.de-en.html
Log message:
Automatic update by GNUnited Nations.
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/lgpl-java.de.html?cvsroot=www&r1=1.3&r2=1.4
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/po/lgpl-java.de-en.html?cvsroot=www&r1=1.3&r2=1.4
Patches:
Index: lgpl-java.de.html
===================================================================
RCS file: /web/www/www/licenses/lgpl-java.de.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -b -r1.3 -r1.4
--- lgpl-java.de.html 2 Feb 2012 02:09:54 -0000 1.3
+++ lgpl-java.de.html 8 Feb 2012 01:26:32 -0000 1.4
@@ -25,38 +25,39 @@
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
-GPL lizenziert werden, ein Effekt, der als <em>erblich</em> 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. </p>
+als ganzes unter der GPL lizenziert werden, ein Effekt, der als
+<em>erblich</em> 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. </p>
<p>
-Im Juli 2003 veröffentlichte Slashdot eine Geschichte, ich hatte behauptet,
+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
licens...@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
-licens...@gnu.org als auch meiner persönlichen E-Mail-Adresse, erhalten. </p>
+licens...@gnu.org als auch über meine persönliche E-Mail-Adresse, erhalten.
</p>
<p>
-Die Position der FSF blieb unverändert: Die LGPL ist mit allen bekannten
-Programmiersprachen, einschlieÃlich Java, wie beabsichtigt
+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 Nachkonstruktion „Reverse
-Engineering“ zu erlauben, das Diagnostizieren „Debuggen“
-zu ermöglichen. </p>
-<p>
-Die typische Aufbau für Java ist, dass jede Bibliothek eine Anwendung als
-separate JAR-Datei (Java Archive) verteilt wird. Anwendungen verwenden Javas
-<em>Import</em>-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 die Verbreitung der Arbeit der Bibliothek
-genehmigen. Die LGPL gestattet diese Verbreitung. </p>
+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. </p>
+<p>
+Der 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 <em>Import</em>-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. </p>
<p>
Wenn Sie eine Java-Anwendung vertreiben, die LGPL lizenzierte Bibliotheken
importiert, ist es leicht, die LGPL einzuhalten. Die Lizenz Ihrer Anwendung
@@ -71,17 +72,16 @@
sind dafür verantwortlich, dass es funktioniert. </p>
<p>
Wenn Sie die Bibliothek mit der Anwendung (oder eigenständig) vertreiben,
-müssen Sie den Quelltext der Bibliothek einschlieÃen. Aber wenn die
-Anwendung stattdessen von Nutzern verlangt, die Bibliothek allein zu
-erhalten, müssen Sie den Quellcode der Bibliothek zur Verfügung stellen.
</p>
+müssen Sie 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. </p>
<p>
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 die gleiche Weise wie
-herkömmliche Verknüpfung und die LGPL gestattet diese Art der davon
-abgeleiteten Werks auf die gleiche Weise, wie es gewöhnliche
-Funktionsaufrufe zulassen. </p>
+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.
</p>
<div style="font-size: small;">
@@ -132,7 +132,7 @@
<!-- timestamp start -->
Aktualisierung:
-$Date: 2012/02/02 02:09:54 $
+$Date: 2012/02/08 01:26:32 $
<!-- timestamp end -->
</p>
Index: po/lgpl-java.de-en.html
===================================================================
RCS file: /web/www/www/licenses/po/lgpl-java.de-en.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -b -r1.3 -r1.4
--- po/lgpl-java.de-en.html 2 Feb 2012 02:10:32 -0000 1.3
+++ po/lgpl-java.de-en.html 8 Feb 2012 01:26:46 -0000 1.4
@@ -107,7 +107,7 @@
<p>
Updated:
<!-- timestamp start -->
-$Date: 2012/02/02 02:10:32 $
+$Date: 2012/02/08 01:26:46 $
<!-- timestamp end -->
</p>
</div>
