bugGNU German Translation Team for gnu.org - Bugs: bug #35464, licenses/lgpl-java.html

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #35464: licenses/lgpl-java.html

Submitted by:  None
Submitted on:  Tue 07 Feb 2012 11:00:33 AM UTC  
 
Category: ÜbersetzungSeverity: 3 - normal
Item Group: VorschlagStatus: behoben
Privacy: öffentlichAssigned to: Joerg Kohne <joeko>
Open/Closed: Closed

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.

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by joeko (Updated the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 07 Feb 2012 09:41:22 PM UTCjoekoStatusNone=>behoben
      Assigned toNone=>joeko
      Open/ClosedOpen=>Closed
      Discussion LockUnlocked=>Locked

    Back to the top


    Powered by Savane 3.1-cleanup1