Apache hat ja einige Projekte die auf Java aufbauen, da wäre ein freies Java, dass unter der gleichen Lizenz wie Apache selbst steht sicherlich nicht schlecht.
Für Distros, die ausschließlich auf freie Software setzen wäre das natürlich auch sehr gut.
Außerdem war bis 1.4 die Linuxversion von Sun unter jeder Kritik. Wenn man wirklich Java einsetzten wollte, brauchte man die von Blackdown oder IBM.
Da die Solaris und Window Versionen aber nicht schlecht waren, lag die Vermutung nahe, daß Sun da absichtlich gebremst hat.
Abgesehen davon kann ich mir vage erinnern, mal etwas über Probleme mit der Redistribution gelesen zu haben, also daß man das Paket nur direkt von Sun runterladen und ein Distributor nicht ein konformes Paket bereitstellen kann.
MacOS X wird auch unterstützt, aber das wars dann wohl. Vorwiegend aber unfreie Plattformen. Freie Plattformen wie die Opensource-BSDs gucken in die Röhre oder müssen sich mit Linuxemulation behelfen. Sehr unschön.
Mit entsprechenden inoffiziellen Patches. Ja. Aber das ist äusserst mühsam, ich zumindest hatte recht lange bis das Ding kompiliert war (und erst noch kein Java 1.5).
Das ist jetzt nicht als Kritik an den Portierern zu verstehen wohlgemerkt, sondern als Kritik an Sun...
> ...und natürlich wie im Artikel erwähnt > ist es auch ein Problem, "dass Java > gegenwärtig nur Solaris, Linux und Windows > unterstütze."
Das ist auch mal wieder nichts weiter als eine Falschinformation im Artikel. Java für Mac OS X bekommt man bei Apple, Java für HP-UX, Tru64 und OpenVMS bekommt man bei HP, Java für IBM-Plattformen bekommt man bei IBM. Diese Firmen haben Suns geistiges Eigentum ordnungsgemäß lizensiert und leisten dafür auch Support. Leider ist das gewissen "Ich-versuche-mal-mit-Falschbehauptungen-durchzukommen"-Leuten nicht beizubringen.
Nochmal zum Mitschreiben: Wer nichtkommerzielle Plattformen nutzen will, der muss sich damit abfinden, dass es keinen Hersteller gibt, der mit Lizenzgebühren ausreichend Geld verdient und von diesem Geld Technologien für seine Kunden lizensieren kann. Deswegen gibt es für nichtkommerzielle Plattformen kaum kommerzielle Software. Das hat man gefälligst vorher zu wissen, bevor man so eine Plattform wählt. -> _You_Get_What_You_Pay_For!_
Davon abgesehen war es sowieso eigentlich so gedacht, dass jeder Hersteller einer Plattform Java lizensiert und dann selbst portiert und anbietet. Für Windows hat Sun eine Ausnahme gemacht, weil Microsoft versucht hat, die Technologie zu zerstören und für Linux hat Sun eine Ausnahme gemacht, weil weil es sonst keiner machen kann, die Distributoren sind nämlich nicht bereit, dafür zu investieren.
Tja, die freie Lizenz ist halt gerade das Wesen von Free Software.
Aber um die Punkte zusammenzubringen:
1. Wie schon gesagt kann die Lizenz einseitig durch Sun einfach auch zum schlechteren geändert werden - ohne Fork-Möglichkeit eine klare Bedrohung
2. Sie schränkt die Lizenzen der erstellten Programme ein (ich kann kein Java-Programm unter z.B. GPL stellen). Geht mit vielen anderen Free Software Lizenzen auch nicht, die werden aber nicht für die Programmiersprache selbst verwendet, sondern üblicherweise nur für Programme.
3. Was wenn Sun die Lust an Java verliert? Wer entwickelt dann Java weiter? Wo ist die Garantie dass man dann Java immer noch sinnvoll einsetzen kann?
4. Plattformen wie schon erwähnt.
Ich finde das reicht zwar nicht für den Ausdruck "unzumutbar" aber es reicht definitiv für ständiges warnen und meckern.
ich bin mir relativ sicher dass man selbst erstellte JavaProgramme auch jetzt unter die GPL stellen kann, aber man braucht halt ne proprietäre JVM um sie auszuführen...
Dein zweiter Punkt ist definitiv falsch. Die Lizenz der Virtual Machine oder des Compilers hat nicht im Geringsten mit der Lizenz des Programmes zu tun. Man darf ja auch mit dem GCC Closed-Source-Software kompilieren.
> ich kann kein Java-Programm unter z.B. GPL stellen
doch, das geht. kannst es auf der fsf seite nachlesen. das eigentlich java problem ist, dass java selbst nicht frei ist. dein freies programm hätte also eine unfreie abhängigkeit. das problem ist dabei nicht die lizenz, sondern dass du es deinen usern nicht zumuten sollst, unfreie software einzusetzen. es gibt tatsächlich leute, welche *nur* freie software auf dem system laufen haben.
Ja, die Bedingungen sind für manche Zwecke unzumutbar. Versuche nur mal spasseshalber unter einem BSD einen Mozilla mit Java-Plugin ans Laufen zu bekommen, dann siehst wie unzumutbar das ist, was SUN den Javanutzern aufzwingen will. Bei einem echten Opensource-Java wäre ein Port auf FreeBSD, BeOS usw. usw. kein Thema.
Daher finde ich es gut dass ein OS-Java in der Mache ist.
> Versuche nur mal spasseshalber unter > einem BSD einen Mozilla mit Java-Plugin > ans Laufen zu bekommen, dann siehst wie > unzumutbar das ist, was SUN den > Javanutzern aufzwingen will.
You Get What You Pay For. Es ist definitiv nicht unzumutbar, sich vor der Wahl einer Plattform mal zu entscheiden, welche Software es dafür gibt. Für nichtkommerzielle Plattformen gibt es nun mal kaum kommerzielle Software. Wer sich in der Situation befindet, auf einer nichtkommerziellen BSD-Plattform eine kommerzielle Software nicht zum Laufen bringen zu können, der hat das seiner eigenen Nachlässigkeit zuzuschreiben. Unzumutbar ist es, von einem wirtschaftlich arbeitenden Unternehmen zu verlangen, dass es auf jede Randgruppenplattform Rücksicht nimmt.
Du wiederholst dich. Ich glaube die wenigsten wollen Sun "zwingen" ihr Java Open Source zu machen.
Aber es ist doch absolut legitim einen freien Clone von Java zu schaffen. Und ich hoffe das dies auch gelingen wird. Es würde Java jedenfalls gut tun. Mit Sun hat das ersteinmal garnichts zu tun, die können mit ihrem Java tun und lassen was sie wollen. Insbesondere dann, wenn es eine freie JAva Implementierung gibt.
Der Zaurus kommt/kam ja von Sharp inklusive Personal Java. Und ich finde Java auf dem Teil auch recht nützlich. Nun ist ja mittlerweile Opie die eher bessere Alternative auf dem Zaurus. Aber Java zusammen mit Opie zu verwenden ist wenn überhaupt möglich, recht kompliziert und rechtlich bedenklich. Hier würde eine freie Java Implementation zumindest helfen, auch wenn dann nach wie vor solche Sachen wie eine AWT Anbindung an Qt Embedded fehlen würde.
Ich verstehe diese Angst vor Forks nicht. Die Wahrscheinlichkeit, daß es zu einem Fork kommt ist umgekehrt proportional zur Größe des Projekts. Und der Maintrainer muß schon eine Menge falsch machen, um einen Fork zu provozieren. Klar, kleine Programme werden alle Naselang geforkt, aber bei umfangreichen Programmen mit viel Code und langer Existenz ist das sehr selten, da der Aufwand imens ist. Meist ist es dann einfacher ein ähnliches Programm selbst neu an zu fangen.
Denke mal an XFree86, die sind doch so gut wie in der Versenkung verschwunden, nachdem Xorg einen Fork durchgezogen hat. Und alles nur, weil jemand bei XFree86 es für eine gute Idee hielt ein wenig an der Lizenz zu schrauben. Hätte er geahnt, was dannach passiert, hätten sie die Lizenz vermutlich nie angefasst.
Die Lizenzänderung war nur der Auslöser, die Unzufriedenheitüber die Arbeitsweise des Projekts war ja vorher schon Thema. Ich könnte mir vorstellen, dass sie die Lizenzänderung eben aus Angst vor einem Fork gemacht haben.
So gesehen erreicht man mit dem Schutz vor dem Fork eine noch schlechtere Ausgangsbasis, weil jede alternative Implementierung von vorne anfangen muß und dann später erst recht wenig Möglichkeit besteht, die Implementierungen zusammenzuführen.
Ein Fork hat dem gegenüber den Vorteil, daß man nicht alles doppelt machen muß und man zu einem späteren Zeitpunkt sogar wieder eins werden kann.
Aber ich denke diese Fork-Geschichte ist nur eine vorgeschobene Sache, denn wie du ja schon festgestellt hast ist ein Fork bei einem so großen Projekt nicht sehr wahrscheinlich, wenn das aktuelle Entwicklerteam halbwegs kooperativ ist.
Womöglich hat Sun einfach nicht vor, kooperativ zu sein.
Scheint so. Und SableVM auch (ich selber mag SableVM lieber als Kaffe, weil es unter der LGPL steht und nicht unter der GPL).
Bin mir auch noch nichts so ganz sicher, was das Ziel von Harmony ist. Ursprünglich dachte ich, daß GNU Classpath zusätzlich unter die APL gestellt wird oder - wenn das nicht möglich ist - soetwas ähnliches wie mit Mozilla Missing geschieht. Doch dem scheint nicht so zu sein. Klar ist nur, daß die Apachen mit den GNUs in Kontakt stehen. Wenn es notwendig sein sollte, wird die GNU Classpath Lizenz geändert (immerhin hat die FSF die Rechte dadran). Ansonsten soll jedoch die Lizenz so gelassen werden wie sie ist und ein Classpath unter der APL wird es wohl nicht geben. Das Harmony Wiki scheint auch nicht gerade sehr ergibig zu sein. Mehr steht hingegen schon im MaililnList-Archiv.
Insofern scheint Harmony in meinen Augen bloß eine weitere VM zu werden die Classpath verwendet. Möglich ist auch, daß Apache für ihr J2EE namens Geronimo auch ein eigenes J2SE haben wollen.
Der Vorteil ist jedoch, daß bisher Sun und Apache gute Beziehungen zueinander hatten. Und somit der Einfluß von Apache auf Sun größer ein wird als der von Kaffe auf Sun.
Ein weiterer Vorteil von Apache ist, daß sie hinterher Suns JavaCompatiblityKit lizensieren wollen und vorhaben hinterher Harmony offiziell Java nennen zu dürfen.
Ansonsten scheint aber Harmony nichts besonderes zu sein. Aber so genau weiß ich es auch nicht, da ich auch nicht in das Projekt involviert bin.
Ein weiterer Vorteil von Apache ist, daß sie hinterher Suns JavaCompatiblityKit lizensieren wollen und vorhaben hinterher Harmony offiziell Java nennen zu dürfen.
Das ist der Hauptgrund, weshalb Harmony ins Leben gerufen wurde.
naja, ich weis ehrlich gesagt auch ned wieso die das machen. ich mein sun ist bisher immer sehr linux freundlich gewesen. und auch wenn sich das ändern sollte. ich kann doch nicht von jeden programm, das es für linux gibt, ne open source alternative machen. was sagt das den entwicklern? wir intressieren uns sowieso ned für ihre produkte.
die sollten sich lieber dranmachen eine schnellere open source flash 7 implementierung, inklusive flash erstellungs proggie zu machen, anstatt java "mal wieder" neu zu erfinden. ich hoffe,die vermurksen es ned und im endeffekt kommt dann ein java raus, das spwieso zu allen anderen inkompatibel ist. usw.
> ich hoffe,die vermurksen es ned und im endeffekt kommt dann ein java raus, das spwieso zu allen anderen inkompatibel ist. usw. Da habe ich keine Bedenken, da ja gerade die Zertifizierung durch Sun das Hauptziel ist.
> die sollten sich lieber dranmachen eine schnellere open source flash 7 implementierung, inklusive flash > erstellungs proggie zu machen, anstatt java "mal wieder" neu zu erfinden Wer die? Die freien Entwickler sind doch keine Dienstleister, die mal aus Spass irgendwas vor sich hin entwickeln, was ein anderer braucht.
Die Entwickler um Geir Magnussen wollen eine Java VM mit allem drum und dran schreiben. Wenn du mit Sun's Java auf x86/amd64 vollends zufrieden bist, dann ist das ok.
Vielleicht hat dich dieser Status Quo aber noch nie überlegen lassen, was an Java alles so faul ist ...
Wir wär's denn, wenn die Apache-Leute erstmal ihre Hausaufgaben machen würden, statt jetzt so ein Riesen-Projekt anzufangen. Die XML-Tools Xerces, Xalan und FOP scheinen ja nicht sehr aktiv gepflegt zu werden. Bevor ich so ein riesiges Produkt wie Java neu erfinde, muss ich schon eine ganze Menge guter Gründe haben. Und "was wäre wenn" zählt für mich nicht dazu.
Und, ohne jemanden ärgern zu wollen, muss ich bei einem Nischen-System wie Free-BSD nicht auch gewisse Einschränkungen akzeptieren? Ich habe damals die OS/2-Lektion gelernt.
Gosling versteht es nicht, das macht aber nichts. Danese Cooper (ehemals Sun, jetzt Intel) und Simon Phipps (Sun) finden Harmony gut und werden es unterstützen (Quelle: Harmony Entwickler Liste).
Ich hätte auch Angst, wenn eine so renommierte freie Softwareschmiede wie die Apache Software Foundation daher kommt und mein proprietäres Produkt reimplementiert.
Btw: ~750.000 Zeilen Quellcode sind dem Projekt schon mal sicher - in Form von GNU Classpath. Eine VM wird es aller vorraussicht nach von einem bestehenden Projekt erben: JikesRVM, JCVM, JamVM sind im Gespräch. Alle diese VMs können heute schon Software wie Tomcat 5 und Eclipse uvm. laufen lassen.
Auch Ersatz für die JDK Tools javadoc, rmic, rmiregistry usw. gibt es schon.
Der Artikel von vunet sagt, dass Harmony Jahre an Entwicklungsarbeit vor sich hat: Ich finde das ist FUD.
> Gosling versteht es nicht, das macht aber nichts. Danese Cooper (ehemals Sun, jetzt Intel) und Simon > Phipps (Sun) finden Harmony gut und werden es unterstützen (Quelle: Harmony Entwickler Liste).
Ack. Ich verstehe nicht wieso Gosling jetzt das Maul aufreissen muss um aller Welt mitzuteilen dass er etwas nicht versteht.
Ich meine das ist ja nicht wirklich sein Problem. Wird es noch werden, hoffe ich, aber vorerst ist es noch weit davon entfernt.
Sun ist ja von einer Technoligieentwicklungs Firma zu einer Techologiemarketing Firma geworden und muß daher jede sich bietende Gelegenheit nutzen, sich im Gespräch zu halten.
> Ich verstehe nicht wieso Gosling jetzt > das Maul aufreissen muss um aller Welt > mitzuteilen dass er etwas nicht versteht.
Die Weltmeister im Maulaufreißen sind immer noch GNU und FSF, die nichts, aber auch wirklich gar nichts davon verstanden haben, wie das in der kommerziellen Softwarewelt läuft. Zum Glück hat die Apache Foundation mit denen nichts am Hut.
>Btw: ~750.000 Zeilen Quellcode sind dem Projekt schon mal sicher - in Form von GNU Classpath.
ist es entschieden, dass GNU Classpath die Lizenz hin zur Apache Lizenz ändert? Ich kann mir nicht vorstellen, dass die FSF jeden Schutz der Freiheit bei einem GNU Projekt so ohne weiteres aufgibt.
> ist es entschieden, dass GNU Classpath die Lizenz hin zur Apache Lizenz ändert? Nein ist es nicht. Aber warum sollte das nötig sein? Die GPL+Linking Exception von Classpath ist prinzipiell ASL kompatibel. Momentan wird der genaue Wortlaut geprüft und verbessert, damit es keine rechtlichen Unsicherheiten gibt.
Die Schnittstellen von Classpath zur VM kommen aller Vorraussicht unter eine andere Lizenz, damit Harmony ihre Schnittstellen-Implementation problemlos in ihren SVN-Repositories halten kann.
> Ich kann mir nicht vorstellen, dass die FSF jeden Schutz der Freiheit bei einem GNU Projekt so ohne > weiteres aufgibt. Ich kann mir aber auch nicht vorstellen, das die ASF eine bereits 7 Jahre dauernde Klassenbibliotheksentwicklung nicht nutzen will. Und das, wo GNU Classpath sogar mit unfreier Software dh. VM verbunden werden darf: JamaicaVM
>Nein ist es nicht. Aber warum sollte das nötig sein?
Also das letzt was ich dazu gehört habe war, dass man die beiden Projekte gerne "vereinen" will (was auch immer das heißt) und dazu müsse sich GNU Classpath an die Apache Lizenz anpassen. Aber kann auch sein, dass ich da was falsches im Kopf habe.
>Die GPL+Linking Exception von Classpath ist prinzipiell ASL kompatibel.
Also das letzte was ich gelesen habe ist, dass die Apache Lizenz zur GPL nicht kompatibel ist wegen der "Patent-Klausel". Das wird sich doch frühestens mit GPLv3 ändern, wenn man da eine ähnliche/gleiche Klausel einführen sollte.
>Die Schnittstellen von Classpath zur VM kommen aller Vorraussicht unter eine andere Lizenz
OK, dass verstehe ich schon eher, dann wird man als Schnittstellen Lizenz wohl eine wählen die zu beiden Lizenzen kompatibel ist, dass könnte natürlich funktionieren.
PS: Will man in Harmony überhaupt eine eigene VM entwickeln? Ich dachte es geht da eher um Bibliotheken um zu J2SE kompatibel zu sein? VMs und Compiler hat man ja bereits genug.
> Also das letzt was ich dazu gehört habe war, dass man die beiden Projekte gerne "vereinen" will (was > auch immer das heißt) und dazu müsse sich GNU Classpath an die Apache Lizenz anpassen. Ich halt mal die Ohren auf. :)
> Also das letzte was ich gelesen habe ist, dass die Apache Lizenz zur GPL nicht kompatibel ist wegen > der "Patent-Klausel". Das ist richtig. Aber die Lizenz von GNU Classpath ist so liberal, dass man es sogar mit Bitkeeper verlinken dürfte ;) Wie gesagt JamaicaVM ist durch und durch unfrei und ist trotzdem zu gut wie nichts verpflichtet. Nur Änderungen an Classpath selbst sollen zurückfliessen.
> PS: Will man in Harmony überhaupt eine eigene VM entwickeln? Ich dachte es geht da eher um > Bibliotheken um zu J2SE kompatibel zu sein? VMs und Compiler hat man ja bereits genug. Jupp, genau darum geht es.
Die meisten freien VMs sind aber eben "nur" die VM selbst. Ein richtiges J2SE hat ja einen Compiler, eine VM, die Klassenbibo, ein paar Tools, Doku + Beispiele. All das will Harmony auch haben. Zugegebenermaßen schneidet sich das mit den Vorhaben von Kaffe, GCJ und der neuen auf SableVM-basierenden JDK-Ersatz Distribution.
Diese Vielfalt mag bei einigen Besorgnis auslösen (so wie manche zuviele GNU/Linuxe oder BSDse befürchten), ich sehe das aber als Vorteil. Auf diese Weise bekommen unsere Anwender mehr Möglichkeiten und jeder kann sich die Software seiner Wahl nach Lizenz oder sonstwas aussuchen.
Auf der Ebene der Klassenbibliothek geht ja sowieso alles auf GNU Classpath zurück und da bin ich froh, dass wir auch die Apaches im Boot haben. :)
Geir und die meisten um ihn herum haben IMHO kein Problem mit der schwachen Form von Copyleft von Classpath. In der Tat ist es so, das Gespräche zwischen Mark (Maintainer von CP) und Geir das Ganze überhaupt ins Rollen gebracht haben.
>dass die SUN-Lizensierung von Java einen Fork wirksam verhindert.
in welcher Welt leben die SUN Leute? Was ist Kaffe, SableVM, gcj, harmony,... Die Sun Lizenzierung fördert parallel Entwicklungen um nicht zu sagen erzwingt diese, dass ist die Realität und nicht umgekehrt. Man könnte sogar sagen, dass die Lizenz von SUN .Net und Mono erst wirklich Rückenwind gegeben hat. Wer hätte daran interesse gehabt, wenn es ein freies Java mit einem offenen Standard gegeben hätte?
> Dass die Reihen offenbar doch nicht ganz so geschlossen sind, zeigen einige eingereichte Beiträge in > den diversen Panels auf dem LinuxTag: Wie meinst du das?
Von Anonymous Coward am Di, 24. Mai 2005 um 23:43 #
...es tut mir in der Seele weh, immer von Implementation lesen zu muessen. Es muss Implementierung heissen. Das stoert mich fast genauso sehr, wie die gaengige Uebersetzung von "physical" nach "physikalisch". Wie gesagt, kein Gemecker, aber anmerken darf man sowas sicherlich. Ansonsten guter Beitrag!
Sind die Bedingungen von JAVA so unzumutbar?
Für Distros, die ausschließlich auf freie Software setzen wäre das natürlich auch sehr gut.
Da die Solaris und Window Versionen aber nicht schlecht waren, lag die Vermutung nahe, daß Sun da absichtlich gebremst hat.
Abgesehen davon kann ich mir vage erinnern, mal etwas über Probleme mit der Redistribution gelesen zu haben, also daß man das Paket nur direkt von Sun runterladen und ein Distributor nicht ein konformes Paket bereitstellen kann.
> aber nicht schlecht waren, lag die
> Vermutung nahe, daß Sun da absichtlich
> gebremst hat.
Das ist Paranoia.
MacOS X wird auch unterstützt, aber das wars dann wohl.
Vorwiegend aber unfreie Plattformen. Freie Plattformen wie die Opensource-BSDs gucken in die Röhre oder müssen sich mit Linuxemulation behelfen.
Sehr unschön.
Bye
Das ist jetzt nicht als Kritik an den Portierern zu verstehen wohlgemerkt, sondern als Kritik an Sun...
MfG Peschmä
ist auch schon wieder Schluß. :-(
Gib' mir noch nen "kaffe"
> ist es auch ein Problem, "dass Java
> gegenwärtig nur Solaris, Linux und Windows
> unterstütze."
Das ist auch mal wieder nichts weiter als eine Falschinformation im Artikel. Java für Mac OS X bekommt man bei Apple, Java für HP-UX, Tru64 und OpenVMS bekommt man bei HP, Java für IBM-Plattformen bekommt man bei IBM. Diese Firmen haben Suns geistiges Eigentum ordnungsgemäß lizensiert und leisten dafür auch Support. Leider ist das gewissen "Ich-versuche-mal-mit-Falschbehauptungen-durchzukommen"-Leuten nicht beizubringen.
Nochmal zum Mitschreiben: Wer nichtkommerzielle Plattformen nutzen will, der muss sich damit abfinden, dass es keinen Hersteller gibt, der mit Lizenzgebühren ausreichend Geld verdient und von diesem Geld Technologien für seine Kunden lizensieren kann. Deswegen gibt es für nichtkommerzielle Plattformen kaum kommerzielle Software. Das hat man gefälligst vorher zu wissen, bevor man so eine Plattform wählt. -> _You_Get_What_You_Pay_For!_
Davon abgesehen war es sowieso eigentlich so gedacht, dass jeder Hersteller einer Plattform Java lizensiert und dann selbst portiert und anbietet. Für Windows hat Sun eine Ausnahme gemacht, weil Microsoft versucht hat, die Technologie zu zerstören und für Linux hat Sun eine Ausnahme gemacht, weil weil es sonst keiner machen kann, die Distributoren sind nämlich nicht bereit, dafür zu investieren.
Aber um die Punkte zusammenzubringen:
1. Wie schon gesagt kann die Lizenz einseitig durch Sun einfach auch zum schlechteren geändert werden - ohne Fork-Möglichkeit eine klare Bedrohung
2. Sie schränkt die Lizenzen der erstellten Programme ein (ich kann kein Java-Programm unter z.B. GPL stellen). Geht mit vielen anderen Free Software Lizenzen auch nicht, die werden aber nicht für die Programmiersprache selbst verwendet, sondern üblicherweise nur für Programme.
3. Was wenn Sun die Lust an Java verliert? Wer entwickelt dann Java weiter? Wo ist die Garantie dass man dann Java immer noch sinnvoll einsetzen kann?
4. Plattformen wie schon erwähnt.
Ich finde das reicht zwar nicht für den Ausdruck "unzumutbar" aber es reicht definitiv für ständiges warnen und meckern.
Philipp
fabian
doch, das geht. kannst es auf der fsf seite nachlesen. das eigentlich java problem ist, dass java selbst nicht frei ist. dein freies programm hätte also eine unfreie abhängigkeit. das problem ist dabei nicht die lizenz, sondern dass du es deinen usern nicht zumuten sollst, unfreie software einzusetzen. es gibt tatsächlich leute, welche *nur* freie software auf dem system laufen haben.
Ja, die Bedingungen sind für manche Zwecke unzumutbar.
Versuche nur mal spasseshalber unter einem BSD einen Mozilla mit Java-Plugin ans Laufen zu bekommen, dann siehst wie unzumutbar das ist, was SUN den Javanutzern aufzwingen will.
Bei einem echten Opensource-Java wäre ein Port auf FreeBSD, BeOS usw. usw. kein Thema.
Daher finde ich es gut dass ein OS-Java in der Mache ist.
Bye
> einem BSD einen Mozilla mit Java-Plugin
> ans Laufen zu bekommen, dann siehst wie
> unzumutbar das ist, was SUN den
> Javanutzern aufzwingen will.
You Get What You Pay For. Es ist definitiv nicht unzumutbar, sich vor der Wahl einer Plattform mal zu entscheiden, welche Software es dafür gibt. Für nichtkommerzielle Plattformen gibt es nun mal kaum kommerzielle Software. Wer sich in der Situation befindet, auf einer nichtkommerziellen BSD-Plattform eine kommerzielle Software nicht zum Laufen bringen zu können, der hat das seiner eigenen Nachlässigkeit zuzuschreiben. Unzumutbar ist es, von einem wirtschaftlich arbeitenden Unternehmen zu verlangen, dass es auf jede Randgruppenplattform Rücksicht nimmt.
Aber es ist doch absolut legitim einen freien Clone von Java zu schaffen. Und ich hoffe das dies auch gelingen wird. Es würde Java jedenfalls gut tun. Mit Sun hat das ersteinmal garnichts zu tun, die können mit ihrem Java tun und lassen was sie wollen. Insbesondere dann, wenn es eine freie JAva Implementierung gibt.
Momentan scheinen sie durchaus zumutbar.
Aber mal ein kleines Beispiel:
Der Zaurus kommt/kam ja von Sharp inklusive Personal Java. Und ich finde Java auf dem Teil auch recht nützlich. Nun ist ja mittlerweile Opie die eher bessere Alternative auf dem Zaurus. Aber Java zusammen mit Opie zu verwenden ist wenn überhaupt möglich, recht kompliziert und rechtlich bedenklich. Hier würde eine freie Java Implementation zumindest helfen, auch wenn dann nach wie vor solche Sachen wie eine AWT Anbindung an Qt Embedded fehlen würde.
Klar, kleine Programme werden alle Naselang geforkt, aber bei umfangreichen Programmen mit viel Code und langer Existenz ist das sehr selten, da der Aufwand imens ist. Meist ist es dann einfacher ein ähnliches Programm selbst neu an zu fangen.
Ich könnte mir vorstellen, dass sie die Lizenzänderung eben aus Angst vor einem Fork gemacht haben.
Ein Fork hat dem gegenüber den Vorteil, daß man nicht alles doppelt machen muß und man zu einem späteren Zeitpunkt sogar wieder eins werden kann.
Aber ich denke diese Fork-Geschichte ist nur eine vorgeschobene Sache, denn wie du ja schon festgestellt hast ist ein Fork bei einem so großen Projekt nicht sehr wahrscheinlich, wenn das aktuelle Entwicklerteam halbwegs kooperativ ist.
Womöglich hat Sun einfach nicht vor, kooperativ zu sein.
Bin mir auch noch nichts so ganz sicher, was das Ziel von Harmony ist. Ursprünglich dachte ich, daß GNU Classpath zusätzlich unter die APL gestellt wird oder - wenn das nicht möglich ist - soetwas ähnliches wie mit Mozilla Missing geschieht.
Doch dem scheint nicht so zu sein. Klar ist nur, daß die Apachen mit den GNUs in Kontakt stehen. Wenn es notwendig sein sollte, wird die GNU Classpath Lizenz geändert (immerhin hat die FSF die Rechte dadran). Ansonsten soll jedoch die Lizenz so gelassen werden wie sie ist und ein Classpath unter der APL wird es wohl nicht geben.
Das Harmony Wiki scheint auch nicht gerade sehr ergibig zu sein. Mehr steht hingegen schon im MaililnList-Archiv.
Insofern scheint Harmony in meinen Augen bloß eine weitere VM zu werden die Classpath verwendet.
Möglich ist auch, daß Apache für ihr J2EE namens Geronimo auch ein eigenes J2SE haben wollen.
Der Vorteil ist jedoch, daß bisher Sun und Apache gute Beziehungen zueinander hatten. Und somit der Einfluß von Apache auf Sun größer ein wird als der von Kaffe auf Sun.
Ein weiterer Vorteil von Apache ist, daß sie hinterher Suns JavaCompatiblityKit lizensieren wollen und vorhaben hinterher Harmony offiziell Java nennen zu dürfen.
Ansonsten scheint aber Harmony nichts besonderes zu sein. Aber so genau weiß ich es auch nicht, da ich auch nicht in das Projekt involviert bin.
Das ist der Hauptgrund, weshalb Harmony ins Leben gerufen wurde.
und auch wenn sich das ändern sollte. ich kann doch nicht von jeden programm, das es für linux gibt, ne open source alternative machen. was sagt das den entwicklern? wir intressieren uns sowieso ned für ihre produkte.
die sollten sich lieber dranmachen eine schnellere open source flash 7 implementierung, inklusive flash erstellungs proggie zu machen, anstatt java "mal wieder" neu zu erfinden. ich hoffe,die vermurksen es ned und im endeffekt kommt dann ein java raus, das spwieso zu allen anderen inkompatibel ist. usw.
Da habe ich keine Bedenken, da ja gerade die Zertifizierung durch Sun das Hauptziel ist.
> erstellungs proggie zu machen, anstatt java "mal wieder" neu zu erfinden
Wer die? Die freien Entwickler sind doch keine Dienstleister, die mal aus Spass irgendwas vor sich hin entwickeln, was ein anderer braucht.
Die Entwickler um Geir Magnussen wollen eine Java VM mit allem drum und dran schreiben. Wenn du mit Sun's Java auf x86/amd64 vollends zufrieden bist, dann ist das ok.
Vielleicht hat dich dieser Status Quo aber noch nie überlegen lassen, was an Java alles so faul ist ...
Und, ohne jemanden ärgern zu wollen, muss ich bei einem Nischen-System wie Free-BSD nicht auch gewisse Einschränkungen akzeptieren? Ich habe damals die OS/2-Lektion gelernt.
> ich bei einem Nischen-System wie Free-BSD
> nicht auch gewisse Einschränkungen akzeptieren?
Ja, absolut! Und das hat man gefälligst vor der Entscheidung für eine Plattform zu wissen!
Ich hätte auch Angst, wenn eine so renommierte freie Softwareschmiede wie die Apache Software Foundation daher kommt und mein proprietäres Produkt reimplementiert.
Btw: ~750.000 Zeilen Quellcode sind dem Projekt schon mal sicher - in Form von GNU Classpath. Eine VM wird es aller vorraussicht nach von einem bestehenden Projekt erben: JikesRVM, JCVM, JamVM sind im Gespräch. Alle diese VMs können heute schon Software wie Tomcat 5 und Eclipse uvm. laufen lassen.
Auch Ersatz für die JDK Tools javadoc, rmic, rmiregistry usw. gibt es schon.
Der Artikel von vunet sagt, dass Harmony Jahre an Entwicklungsarbeit vor sich hat: Ich finde das ist FUD.
> Phipps (Sun) finden Harmony gut und werden es unterstützen (Quelle: Harmony Entwickler Liste).
Ack. Ich verstehe nicht wieso Gosling jetzt das Maul aufreissen muss um aller Welt mitzuteilen dass er etwas nicht versteht.
Ich meine das ist ja nicht wirklich sein Problem. Wird es noch werden, hoffe ich, aber vorerst ist es noch weit davon entfernt.
MfG Peschmä
Sun ist ja von einer Technoligieentwicklungs Firma zu einer Techologiemarketing Firma geworden und muß daher jede sich bietende Gelegenheit nutzen, sich im Gespräch zu halten.
> das Maul aufreissen muss um aller Welt
> mitzuteilen dass er etwas nicht versteht.
Die Weltmeister im Maulaufreißen sind immer noch GNU und FSF, die nichts, aber auch wirklich gar nichts davon verstanden haben, wie das in der kommerziellen Softwarewelt läuft. Zum Glück hat die Apache Foundation mit denen nichts am Hut.
ist es entschieden, dass GNU Classpath die Lizenz hin zur Apache Lizenz ändert? Ich kann mir nicht vorstellen, dass die FSF jeden Schutz der Freiheit bei einem GNU Projekt so ohne weiteres aufgibt.
Nein ist es nicht. Aber warum sollte das nötig sein? Die GPL+Linking Exception von Classpath ist prinzipiell ASL kompatibel. Momentan wird der genaue Wortlaut geprüft und verbessert, damit es keine rechtlichen Unsicherheiten gibt.
Die Schnittstellen von Classpath zur VM kommen aller Vorraussicht unter eine andere Lizenz, damit Harmony ihre Schnittstellen-Implementation problemlos in ihren SVN-Repositories halten kann.
> Ich kann mir nicht vorstellen, dass die FSF jeden Schutz der Freiheit bei einem GNU Projekt so ohne
> weiteres aufgibt.
Ich kann mir aber auch nicht vorstellen, das die ASF eine bereits 7 Jahre dauernde Klassenbibliotheksentwicklung nicht nutzen will. Und das, wo GNU Classpath sogar mit unfreier Software dh. VM verbunden werden darf: JamaicaVM
Also das letzt was ich dazu gehört habe war, dass man die beiden Projekte gerne "vereinen" will (was auch immer das heißt) und dazu müsse sich GNU Classpath an die Apache Lizenz anpassen.
Aber kann auch sein, dass ich da was falsches im Kopf habe.
>Die GPL+Linking Exception von Classpath ist prinzipiell ASL kompatibel.
Also das letzte was ich gelesen habe ist, dass die Apache Lizenz zur GPL nicht kompatibel ist wegen der "Patent-Klausel". Das wird sich doch frühestens mit GPLv3 ändern, wenn man da eine ähnliche/gleiche Klausel einführen sollte.
>Die Schnittstellen von Classpath zur VM kommen aller Vorraussicht unter eine andere Lizenz
OK, dass verstehe ich schon eher, dann wird man als Schnittstellen Lizenz wohl eine wählen die zu beiden Lizenzen kompatibel ist, dass könnte natürlich funktionieren.
PS: Will man in Harmony überhaupt eine eigene VM entwickeln? Ich dachte es geht da eher um Bibliotheken um zu J2SE kompatibel zu sein? VMs und Compiler hat man ja bereits genug.
> auch immer das heißt) und dazu müsse sich GNU Classpath an die Apache Lizenz anpassen.
Ich halt mal die Ohren auf. :)
> Also das letzte was ich gelesen habe ist, dass die Apache Lizenz zur GPL nicht kompatibel ist wegen
> der "Patent-Klausel".
Das ist richtig. Aber die Lizenz von GNU Classpath ist so liberal, dass man es sogar mit Bitkeeper verlinken dürfte ;)
Wie gesagt JamaicaVM ist durch und durch unfrei und ist trotzdem zu gut wie nichts verpflichtet. Nur Änderungen an Classpath selbst sollen zurückfliessen.
> PS: Will man in Harmony überhaupt eine eigene VM entwickeln? Ich dachte es geht da eher um
> Bibliotheken um zu J2SE kompatibel zu sein? VMs und Compiler hat man ja bereits genug.
Jupp, genau darum geht es.
Die meisten freien VMs sind aber eben "nur" die VM selbst. Ein richtiges J2SE hat ja einen Compiler, eine VM, die Klassenbibo, ein paar Tools, Doku + Beispiele. All das will Harmony auch haben. Zugegebenermaßen schneidet sich das mit den Vorhaben von Kaffe, GCJ und der neuen auf SableVM-basierenden JDK-Ersatz Distribution.
Diese Vielfalt mag bei einigen Besorgnis auslösen (so wie manche zuviele GNU/Linuxe oder BSDse befürchten), ich sehe das aber als Vorteil. Auf diese Weise bekommen unsere Anwender mehr Möglichkeiten und jeder kann sich die Software seiner Wahl nach Lizenz oder sonstwas aussuchen.
Auf der Ebene der Klassenbibliothek geht ja sowieso alles auf GNU Classpath zurück und da bin ich froh, dass wir auch die Apaches im Boot haben. :)
Geir und die meisten um ihn herum haben IMHO kein Problem mit der schwachen Form von Copyleft von Classpath. In der Tat ist es so, das Gespräche zwischen Mark (Maintainer von CP) und Geir das Ganze überhaupt ins Rollen gebracht haben.
ich würde auch niemehr redhat nutzen, aber andere machen es, und?
in welcher Welt leben die SUN Leute? Was ist Kaffe, SableVM, gcj, harmony,...
Die Sun Lizenzierung fördert parallel Entwicklungen um nicht zu sagen erzwingt diese, dass ist die Realität und nicht umgekehrt. Man könnte sogar sagen, dass die Lizenz von SUN .Net und Mono erst wirklich Rückenwind gegeben hat. Wer hätte daran interesse gehabt, wenn es ein freies Java mit einem offenen Standard gegeben hätte?
http://www.linuxtag.org/vcc/details.pl?id=335
http://www.linuxtag.org/vcc/details.pl?id=162
http://www.linuxtag.org/vcc/details.pl?id=166
http://www.linuxtag.org/vcc/details.pl?id=164
> den diversen Panels auf dem LinuxTag:
Wie meinst du das?
Wie würdest du denn "physikalisch" ins Englische übersetzen?