hehe....och die aaaarmen KDE / Konqueror Entwickler.

Was haben die denn noch groß gemacht seit Apple das Ding weiterentwickelt?

Und bevor Apple sich des Codes angenommen hat konnte man KHTML eh in die Tonne kicken.

Schade, so haette Apple viele Punkte sammeln koennen, wenn sie sich etwas fuer OpenSource stark gemacht haetten.
Aber so
Ewige Eigenbroetlerei und Geldmache!

@RETRAX

So sehe ich das nicht, APPLE wird schon nicht ohne Grund den recht soliden CODE von KHTML genommen haben...
Soweit ich mich erinnern kann war damals ja auch die Gecko Engine von Mozilla (Firefox ...) angedacht, diese wurde aber wegen schlecht lesbarem Code und schlechter erweiterbarkeit wohl fallengelassen.

APPLE sollte ruhig als dank der Open Source gemeinde ein geschenk machen und den Code veröffentlichen!

Also ich versteh die Leute vom KDE-Projekt auch nocht so ganz. Apple gibt gemäß GPL die Änderungen bekannt. Dass diese nun an das eigene Betriebsystem und dessen QT-Clone angepasst werden, sollte wohl klar sein.

Sicherlich könnte man sich hier auch von Apple eine kooperative Vorgehensweise wünschen. Aber das primäre Interesse von Apple ist (legitimerweise) den Safari zu einem schnellen Mac-Browser zu machen. Und dass man da nicht immer auf die Kompatibilität zu KDE achtet dürfte wohl auch klar sein.

Nur leiden unter der momentanen Situation beide Seiten - Apple weil es als OS-unfreundlich dasteht, KDE weil sie rumjammern und Apple doch recht unfair angreifen.

Die meines Erachtens beste Lösung wäre, dass Apple den Safari/WebKit selbst zu OS macht. Dort würde Apple dann aktive in der Safari-Community mitarbeiten - ähnlich wie z.B. bei OpenDarwin oder Sun bei OpenOffice. Ein solches OpenWebKit würde sowohl dem Image von Apple als auch der Entwicklung des Safari/Mac OS helfen. Sekundär wäre es auch eine Hilfe für das GnuStep-Projekt, die dann auch auf das WebKit zurückgreifen könnten.

Sykane:
Sie veroeffentlichen den Code ja auch [weil sie es muessen]. Nur werfen sie eben immer Codebombem, mit riesigen Updates ab und das gefaellt den eigentlichen KHTML Codern natuerlich nicht, da sie sich so in extrem viel neue Sachen und Updates neueinlesen muessen, was zeitaufwendig und schwierig ist. Die HTML Coder schreiben ja schon seit langem das Apple lieber viele kleine Updates bringen soll, aber sie tun es nicht...

RETRAX

Lies doch das nächte Mal etwas nach bevor du solchen Unsinn postest.
Zum Beispiel hier:



Das Kotzen konnte ich mir gerade noch verkneifen (sick)

In Wahrheit tut Apple das absolute Minimum für die Zusammenarbeit mit den KHTML-Entwicklern, um nicht zu sagen Apple behindert die Weiterentwicklung der "freien" Version von KHTML (Gründe: siehe Link oben).

Die tolle Ankündigung damals, dass Apple freie Software supportet, hat sich mittlerweile weitgehend als reine PR-Aktion herausgestellt.

RETRAX
Wie bist du denn drauf??

"hehe....och die aaaarmen KDE / Konqueror Entwickler.

Was haben die denn noch groß gemacht seit Apple das Ding weiterentwickelt?"


RETRAX, Du Pappnase !


Bevor Apple KHTML benutzt hat, haben die KDE-Entwickler bereits ca. 5 Jahre Entwicklungsarbeit in KDE und KHTML gesteckt.

Wenn diese 5 Jahre Arbeit nichts wert gewesen wären, warum hat Apple dann nicht einfach etwas eigenes entwickelt ?

Die KDE-Entwickler haben hervorragende Arbeit geleistet, deswegen hat Apple sich für KHTML entschieden.

Ich sehe das so: (Und das sage ich als ehemaliger teilzeit KDE-Programmierer)

Wenn man Software unter der GPL erstellt, dann weiß man, was man macht: Man möchte die Welt verbessern. Man möchte Software eben nur deshalb schreiben, damit _alle_ in den Genuss guten Codes kommen und aber auch darauf aufbauen können.

Daher sollte man nicht verbittert sein, wenn Apple KHTML forkt.

ABER: Ich glaube worüber man sich bei den KDE-Developern wirklich ärgert ist nicht, dass Apple KHTML Code weiter entwickelt. Das ist ja ein Kompliment!
Nein, man ärgert sich darüber, dass Apple dadurch, dass sie KHTML gewählt haben (Zitat Steve Jobs: We love Open Source) einen PR-Coup gelandet haben. Man hat sozusagen all das positive Karma gezapft, dass einem durch die Öffentlichkeit so zufliegt, weil man ein OSS Projekt unterstützt (und damit auch die oben beschriebene Idee), und auf der anderen Seite tatsächlich das Projekt _nicht_ unterstützt, sondern nach dem Motto friss oder stirb gehandelt.

Kurz: Apple hat durch die Übernahme von KHTML, den Entwicklern ein Kompliment gemacht. Mehr nicht. Aber man hätte auch nicht so tun dürfen, als wollte man den Entiwcklern dafür auch etwas zurück geben. (Was diese auch nicht erwarten, wenn man dies nicht ausdrücklich erklärt. s.o.)

kai!

Von behinderung kann keine Rede sein. Wenn Sie mehr haben wollen, dann müssen die das in der Lizenz zum Ausdruck bringen.

Und prinzipiell ist mir das ehh alles egal. Konqui ist ein guter Browser, nur für eine andere Plattform. Ob das Dingen mehr oder weniger als Safari kann juckt mich nicht.

Nun will CNET eine eMail eines leitenden Apple-Entwicklers in die Hände bekommen haben, in dem vorgeschlagen wird, dass Apple KTHML aufgibt und den eigenen WebCore den Bedürfnissen anpasst, also wahrscheinlich einen eigenen Zweig des KHTML-Projektes erstellt.

Herrje, kann denn hier niemand Englisch? Noch falscher kann man den Sachverhalt wohl nicht wiedergeben.

Wie soll Apple denn bitte "KHTML aufgeben" und stattdessen "den eigenen WebCore" verwenden, wenn eben dieser WebCore auf KHTML basiert??? Wie kann man denn etwas so Kenntnis-Entlastetes schreiben?

Apple schlägt etwas vollkommen anderes vor. WebCore ist eine Abstraktionsschicht, die um die KHTML-Engine gelegt ist. Safari greift über diese Abstraktionsschicht auf KHTML zu, KDE aber direkt. Dadurch unterscheiden sich die Bedürfnisse der beiden Entwicklergruppen erheblich, und es kommt zu den beklagten (aber keinesfalls gewollten!) Verzweigungen der Entwicklung. Apple schlägt nun vor, dass in Zukunft auch KDE, wie Safari, auf WebCore aufsetzt, so dass die Zweige wieder konvergieren und die Entwicklerarbeit wieder unter einen Hut zu bringen ist.

starpeak

Die meines Erachtens beste Lösung wäre, dass Apple den Safari/WebKit selbst zu OS macht.

Das ist - bezüglich WebCore - exakt Apples Vorschlag ... Apple wörtlich (auf der Quell-Website): "We'd be open to making our tree multi-platform."

<Seufz>

WebCore Source

Und erste Projekte:

Wow!

Uli Zappe

Danke für die Infos!

macguardians schreiben

kai!

Apple tut das absolute Minimum, was die KDE-Entwickler in ihrer eigenen Lizenz definieren . Somit haben diese kein Recht, sich zu beschweren. Des Weiteren sind sie nicht verpflichtet, die Änderungen von Apple zu übernehmen. Von einer Behinderung des KHTML-Projekts kann man also überhaupt nicht reden! Apple kann damit machen was es will und braucht sich einen Dreck um das scheren, was die ursprünglichen Entwickler denken, da die Lizenz, die sich die ursprünglichen Entwickler ausgesucht haben, exakt das Verhalten von Apple billigt. Apple muss einzig und alleine den Quellcode der vom Originalcode abgeleiteten Bilbiotheken zur Verfügung stellen und die durchgeführten Änderungen hervorheben.

Was hierbei zu Problemen führt:

- Apple stellt offenbar nicht die KHTML-Änderungen zur Verfügung, sondern das gesamte WebCore. Laut Lizenz nicht nur zulässig, sondern so vorgesehen. Das passt den KHTML-Entwicklern nicht, da diese den Code rausfummeln müssen. Ihr Pech. Hätten sie halt die Lizenz restriktiver formuliert.

- Apple "bereichert" sich in den Augen der KHTML-Entwickler an den Open Source-Projekten, ohne wesentliches zurückzugeben. Ihr Pech. Sollten sie halt die Lizenzen restriktiver halten.

- Apples Marketing erzählt von der wunderbaren Zusammenarbeit der einzelnen Teams. Willkommen in der Wirklichkeit, liebe KHTML-Entwickler!

Insgesamt ist die Situation natürlich bedauerlich, aber ich finde es lächerlich, dass sich eine von zwei Parteien darüber aufregt, dass die andere ihre Lizenzpflichten *erfüllt*.

oliver kurlvink

es mag sicher stimmen, dass sich apple genau an die lizenzvorschriften hält.
aber jetzt mal abgesehen davon, dass es ums knallharten it-business geht und mit der idealistischen optik eines OSS-coders:

ich finde es eine schweinerei, wenn man mit leuten
- die (meistens) unbezahlt solide software projekte auf die beine stellen
- die einem die grösste arbeit an einer eigenen html-rendering engine abnehmen
- die einem die grösste arbeit an einem modernen betriebssystem und dessen hauptkomponenten abnehmen

so umspringt. seid doch mal ehrlich, ohne OSS software, kann man die mac plattform vergessen! ich hätte mir nie einen schweineteuren power mac g5 gekauft und von linux auf mac os x gewechselt, wenn apple nicht ein auf unix basierendes os (mit viel oss) eingeführt hätte. wir wissen alle, dass die liste lang ist: der ganze unix unterbau, die gnu/bsd tools, apache, xfree, khtml, ....

wenn man sich schon ein os aus oss zusammenhämmert und sich so die haut rettet, könnte man, ein bisschen gewissen und edelmut vorausgesetzt, mehr machen als nur die lizenzen erfüllen. aber wie gesagt, marx ist tot und der himmel ist nicht immer blau

viel wind um nichts.

Wenn Apple einen Fork von KHTML macht muss er doch automatisch wieder unter GPL stehen, oder?

Ja. Macht ja nix. WebCore steht auch jetzt schon unter LGPL.

Mal eine interessante Meinung zum Thema - vom Mozilla-Firefox Projektleiter


....Not everyone wants to change the world, but Apple does - and although they may have done the least required of them in accordance with the licenses of the original source code, it was within their rights to do what they did, and no one should begrudge them for it. Safari's renderer is vastly superior to the KHTML used by Konqueror. Should I have to wait months or years for every patch that makes Safari more compatible to be done perfectly? No. Well, maybe as a software engineer I should. But does anyone that isn't a software engineer care? Probably not. Case closed.
-----

ziemlich prakmatisch gesehen

Vielleicht sollten sich die KHTML Leute mal ein Beispiel daran nehmen bzw. das nehmen was für ihren Browser einfach besser macht (also WebCore)
Das Apple wenig zurückgibt ist trotzdem nicht gerade nobel. - irgendwie peinlich