www-de-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [web-translators-de] java-trap


From: Andreas K. Foerster
Subject: Re: [web-translators-de] java-trap
Date: Sun, 30 Jul 2006 19:59:05 +0200
User-agent: Mutt/1.5.9i

Am Sunday, dem 30. Jul 2006 schrieb Richard Steuer:

> > ist das jetzt die richtige Adresse, an die man sich wenden muss, wenn
> > man Übersetzungen beitragen will?
> 
> Für www.gnu.org ja, da bist du richtig. :-)

Endlich! :-)

> > Ich hab mal den Text javatrap.html übersetzt. Den hab ich schon
> > mehrfach eingesandt, aber nie auch nur eine Rückmeldung
> > bekommen. :-(((
> 
> Wenn javatrap.html eine Unterseite von gnu.org ist (ich kann sie nicht
> finden), dann schick sie einfach an die Liste hier. (An diese Mail
> hier ist im Moment nichts angehängt.)

Okay, ich hab es jetzt nochmal kurz überarbeitet.
Den XHTML-Code hab ich weitestgehend übernommen, obwohl der nich ganz
richtig ist (ul kann eigentlich nicht innerhalb von h4 auftauchen)
Eventuell müssen die Formalia nochmal überarbeitet werden...

Die Datei sollte sich jetzt im Anhang befinden.

-- 
AKFoerster

Übersetzungen dieser Seite

Frei, aber gefesselt - Die Java-Falle

 [image of a Philosophical Gnu]

von Richard Stallman
12. April, 2004

Translations of this page


Wenn Ihr Programm freie Software ist, ist das grundsÀtzlich ethisch in Ordnung -- aber es gibt eine Falle auf die Sie aufpassen mÌssen. Ihr Programm, obwohl es selber frei ist, kann durch unfreie Software, von der es abhÀngt, eingeschrÀnkt sein. Da dieses Problem heutzutage vor allem bei Java-Programmen bekannt ist, nennen wir es die Java-Falle.

Ein Programm ist freie Software, wenn seine Benutzer bestimmte entscheidende Freiheiten haben. Diese sind grob gesagt: Die Freiheit das Programm laufen zu lassen, die Freiheit die Quellen zu studieren und Änderungen vorzunehmen, die Freiheit Quell- und BinÀr-Dateien zu vertreiben, und die Freiheit verbesserte Versionen zu veröffentlichen. (siehe http://www.gnu.org/philosophy/free-sw.de.html.) Ob ein bestimmtes Programm Freie Software ist, hÀngt ausschließlich von der Bedeutung seiner Lizenz ab.

Ob das Programm aber in der Freien Welt verwendet werden kann, ob es vor Leuten verwendet werden kann, die bewusst in Freiheit leben, ist schon eine komplexere Frage. Das hÀngt nicht von der Lizenz des Programmes selber ab, denn kein Programm lÀuft in Isolation. Jedes Programm hÀngt von anderen Programmen ab. Zum Beispiel muss ein Programm kompiliert oder interpretiert werden, somit ist es abhÀngig von einem Compiler oder Interpreter. Wenn es in Byte-Code kompiliert wird, hÀngt es von einem Byte-Code-Interpreter ab. Außerdem benötigt es Bibliotheken damit es laufen kann, und es könnte andere Programme aufrufen, die in anderen, separaten Prozessen ablaufen. All diese Programme sind AbhÀngigkeiten. AbhÀngigkeiten, die notwendig sein könnten, damit das Programm ÃŒberhaupt lÀuft, oder sie könnten nur fÃŒr bestimmte Eigenschaften notwendig sein. So oder so, das ganze oder ein Teil des Programmes funktioniert nicht ohne diese AbhÀngigkeiten.

Wenn einige der AbhÀngigkeiten des Programmes unfrei sind, bedeutet das, dass das ganze oder ein Teil des Programmes nicht auf einem vollkommen freien System laufen kann -- es ist in der Freien Welt unbrauchbar. NatÌrlich, wir könnten das Programm zwar vertreiben und Kopien auf unseren Maschinen haben, aber das nÌtzt wenig, wenn es da nicht lÀuft. Dieses Programm ist zwar Freie Software, aber es ist praktisch in Fesseln gelegt durch seine unfreien AbhÀngigkeiten.

Dieses Problem kann in jeder Art von Software auftauchen, in jeder [Programmier-]Sprache. Zum Beispiel ein freies Programm, das nur unter Microsoft Windows lÀuft, ist eindeutig unbrauchbar in der Freien Welt. Aber Software, die unter GNU/Linux lÀuft, kann ebenfalls unbrauchbar sein, wenn sie von anderer unfreier Software abhÀngt. In der Vergangenheit waren Motif (bevor wir LessTif hatten) und Qt (bevor seine Entwickler es zu Freier Software machten) die großen Auslöser dieses Problemes. Die meisten 3D-Video-Karten funktionieren nur vollstÀndig mit unfreien Treibern, was dieses Problem ebenfalls hervorruft. Aber die Hauptquelle dieses Problemes ist heutzutage Java, denn Leute, die Freie Software schreiben, finden Java oft sexy. Verblendet von der Anziehungskraft, die diese Sprache auf sie ausÃŒbt, ÃŒbersehen sie das Problem der AbhÀngigkeiten und sie fallen in die Java-Falle.

Suns Implementation von Java ist unfrei. Blackdown ist ebenfalls unfrei; es ist eine Adaption von Suns proprietÀren Code. Die Standard-Java-Bibliotheken sind gleichfalls unfrei. Wir haben zwar freie Implementationen von Java, wie zum Beispiel der GNU Compiler fÌr Java (GCJ) und GNU Classpath, aber die unterstÌtzen noch nicht alle Eigenschaften. Wir sind noch bei der Aufholjagt.

Wenn Sie ein Java-Programm unter Suns Java-Plattform entwickeln, sind Sie selber dafÌr verantwortlich, wenn Sie Sun-eigene Eigenschaften verwenden, ohne dass es Ihnen Ìbehaupt auffÀllt. Zu der Zeit, wenn Sie dieses herausfinden, könnten Sie diese schon monatelang verwendet haben, und das Ganze umzuschreiben könnte wiederum Monate dauern. Sie könnten dann sagen: »Es wÀre zu viel Arbeit, nochmal neu anzufangen.« Dann wird Ihr Programm in die Java-Falle gefallen sein; es wird in der Freien Welt unbrauchbar sein.

Der zuverlÀssige Weg die Java-Falle zu vermeiden, ist, nur eine freie Implementation von Java auf dem System zu haben. Wenn Sie dann eine Java-Eigenschaft oder -Bibliothek verwenden, die Freie Software noch nicht unterstÌtzt, werden Sie das unmittelbar herausfinden, und Sie können den Code sofort umschreiben.

Sun fÀhrt damit fort zusÀtzliche »Standard«-Java-Bibliotheken zu entwickeln, und die sind fast alle unfrei; in vielen FÀllen sind sogar die Spezifikationen der Bibliothek ein GeschÀftsgeheimnis [trade secret], und Suns jÌngste Lizenz fÌr solche Spezifikationen verbietet die Veröffentlichung von allem, das weniger als eine vollstÀndige Implemetation der Spezifikation darstellt. (siehe http://jcp.org/aboutJava/communityprocess/JSPA2.pdf und http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html als Beispiele).

Zum GlÌck erlaubt diese Spezifikations-Lizenz die Veröffentlichung als Freie Software; andere, die diese Bibliothek erhalten, können bevollmÀchtigt werden, sie zu verÀndern und sind nicht verpflichtet an der Spezifikation zu kleben. [?] Aber diese Bedingung hat den Effekt, dass sie die Verwendung eines gemeinschaftlichen Entwicklungs-Modells zur Erstellung einer freien Implementierung verbietet. Die Verwendung dieses Modelles wÌrde die Veröffentlichung von unvollstÀndigen Versionen mit sich bringen, was denen, die die Spezifikationen gelesen haben, nicht erlaubt wird.

In der FrÌhzeit der Freie-Software-Bewegung war es unmöglich zu vermeiden, dass man von unfreien Programmen abhÀngig war. Bevor wir den GNU C-Compiler hatten, hing jedes C-Programm (frei oder nicht) von einem unfreien C-Compiler ab. Bevor wir die GNU C-Bibliothek hatten, hing jedes Programm von einer unfreien C-Bibliothek ab. Bevor wir Linux hatten, den ersten freien Kernel, hing jedes Programm von einem unfreien Kernel ab. Bevor wir Bash hatten, musste jedes Shell-Skript von einer unfreien Shell interpretiert werden. Es war unvermeidbar, dass unsere ersten Programme zunÀchst durch diese AbhÀngigkeiten behindert wÌrden. Aber wir akzeptierten das, weil unser Plan auch beinhaltete, diese nach und nach zu befreien. Unser Gesamt-Ziel, ein selbstverwaltetes GNU-Betriessystem, beinhaltete freien Ersatz fÌr all diese AbhÀngigkeiten; sobald wir das Ziel erreicht hÀtten, wÀren all unsere Programme befreit gewesen. Und so geschah es denn auch: mit dem GNU/Linux System können wir nun diese Programme auf freien Plattformen laufen lassen.

Heute ist die Situation eine andere. Wir haben nun leistungsfÀhige freie Betriebssysteme und viele freie Programmier-Werkzeuge. Welche Arbeit Sie auch immer erledigen wollen, Sie können es auf einer freien Plattform tun; es gibt keinen Grund mehr, eine unfreie AbhÀngigkeit auch nur zeitweilig zu akzeptieren. Der Haupt-Grund, warum heutzutage Leute in die Falle tappen, ist, weil sie nicht darÌber nachdenken. Die einfachste Lösung fÌr das Problem der Java-Falle ist es, den Leuten beizubringen, wie sie da nicht hinein fallen.

Um Ihren Java-Code vor der Java-Falle abzusichern, installieren Sie eine freie Java-Entwicklungs-Umgebung und benutzen Sie diese. Allgemeiner formuliert, was Sie auch immer fÌr eine Sprache benutzen, halten Sie die Auge offen, und prÌfen Sie den freien Status der Programme von denen Ihr Code abhÀngt. Die einfachste Art um zu ÌberprÌfen, ob das Programm frei ist, ist die, danach im Freie-Software-Verzeichnis zu suchen ( http://www.fsf.org/directory). Wenn ein Programm nicht in dem Verzeichnis ist, können Sie seine Lizenz(en) mit der Liste der Freien Software Lizenzen vergleichen ( http://www.gnu.org/licenses/license-list.html).

Wir versuchen die Java Programme aus der Falle zu befreien. Also, wenn Sie die Sprache Java mögen, laden wir Sie ein, bei der Entwicklung von GNU Classpath zu helfen. Wenn Sie Ihre Programme mit dem GCJ Compiler und GNU Classpath ausprobieren, und ÃŒber alle Probleme auf die Sie mit den Klassen, die bereits implementiert wurden, stoßen, berichten, ist das ebenfalls hilfreich. Wie auch immer, GNU Classpath zu vollenden wird Zeit beanspruchen; wenn weiterhin mehr unfreie Bibliotheken hinzugefÃŒgt werden, werden wir möglicherweise niemals alle von den Neusten haben. Also bitte, legen Sie Ihrer Freien Software keine Fesseln an. Wenn Sie heute eine Applikation schreiben, schreiben Sie sie von Anfang an so, dass sie in freien Umgebungen lÀuft.



Translations of this page:
[ English | Français | Español | Polski ]


reply via email to

[Prev in Thread] Current Thread [Next in Thread]