Ontwikkelaars KHTML ontevreden over houding Apple

Het rommelt tussen Apple en de ontwikkelaars van KHTML, de fundering waar de nog steeds populairder wordende browser Safari op gebouwd is. De samenwerking tussen het bedrijf en het open source-team, die een paar jaar geleden nog beloofde om vruchtbaar en positief voor beide te worden, dreigt nu door gebrek aan communicatie uit te lopen op een fiasco. KHTML is een zogenaamde render engine, een component dat platte HTML-tekst vertaalt naar de grafische weergave waar het gros van de internetters zo graag naar kijkt. Een complex en essentieel onderdeel voor een browser dus. In eerste instantie waren de ontwikkelaars blij met de keuze van Apple, omdat zij in ruil voor hun hulp en ondersteuning konden profiteren van de verbeteringen die het bedrijf aanbracht in de code. Nu Apple echter steeds meer overstapt op zijn eigen aftakking, WebCore genaamd, voelen zij zich gebruikt. Het bedrijf zou al langere tijd veel meer verbeteringen aanbrengen in zijn eigen aftakking van de code dan in het originele project, en overweegt volgens een bron van News.com zelfs helemaal te op te houden met de kruisbestuiving van WebCore terug naar KHTML.

Omdat de broncode onder de GPL-licentie is uitgebracht kan niemand de KHTML-ontwikkelaars tegenhouden om de verbeteringen van WebCore op eigen houtje over te nemen, maar er zijn verschillende redenen waarom dat makkelijker gezegd dan gedaan is. Ten eerste kost het veel tijd en zou de hulp van Apples ontwikkelaars hierbij dus meer dan welkom zijn. Verder is de architectuur van WebCore aangepast ten opzichte van KHTML om beter aan de specifieke eisen van Safari en Mac OS X te voldoen, waardoor lang niet alle nieuwe code (rechtstreeks) gekopiëerd kan worden van het ene naar het andere project. KHTML is immers meer gericht op de desktopomgeving KDE en de daarbij horende browser Konqueror. Een laatste obstakel is dat manier waarop Apple bugs oplost en features toevoegt niet door alle open source-ontwikkelaars even hoog wordt gewaardeerd. De commerciële instelling van het bedrijf levert nu eenmaal niet altijd de meest elegante code op.

Zack Rusin van het KHTML-project heeft zijn problemen met het gedrag van Apple kenbaar gemaakt in open brief aan het bedrijf. Daarin vraagt hij vooral om betere samenwerking, onder andere door toegang te krijgen tot de bugdatabase, betrokken te worden bij discussies over wijzigingen aan de architectuur en meer inzet voor het originele project. Apple zelf heeft op dit moment nog geen commentaar gegeven, maar uit een bericht van een Safari-ontwikkelaar aan News.com blijkt dat het bedrijf hele andere richtingen op zit te denken. Zo wordt een verse start voor het KHTML-project gesuggereerd op basis van de WebCore-code, en sluit men zelfs de rechtstreekse integratie van WebCore in KDE niet uit. Gezien het kwaad bloed dat Apple in de KHTML-ontwikkelgemeenschap heeft gezaaid lijkt dat echter niet bepaald een waarschijnlijk scenario. De combinatie tussen idealistische en commerciële belangen lijkt in dit geval dus niet goed uit te pakken voor de eerste groep. In de woorden van Rusin:

"As long as they needed us, they used us, but when they gained enough knowledge they had no reason to keep sending us reviews and patches. [...] At a certain point they decided it was a waste of time for them, and at that point the communication just stopped...We had hopes that they would pour resources into KHTML. But that never happened."

Reacties (46)

[Countess]

legaal gezien doet apple niks fout natuurlijk (GPL mag je gewoon gebruiken), maar moreel gezien is het op zijn zachst gezegt niet netjes.
zwak van apple eigenlijk.

[rtgo]

Morele argumenten zijn niet erg sterk om dat ze subjectief zijn. Vaak zijn ze ook niet efficient.
Het is naief om te denken dat open source niet misbruikt gaat worden voor commerciele doeleinden. Dat weet je als je je code toevoegt. Als je niet wilt dat je code misbruikt wordt (of als je het in ieder geval moeilijk wilt maken), dan moet je closed source software maken zoals ze dat bij veel commerciele bedrijven doen.

Het is hetzelfde in de wetenschap: je maakt je resultaten openbaar en dan gaat er een bedrijf mee aan de haal om er geld mee te verdienen. De oplossing is natuurlijk simpel: patenten. Maar dat zal wel vloeken in de kerk zijn hier

[Countess]

dat is niet helemaal waar
als bedrijven GPL willen gebruiken moeten ze de gebruikte code ook weer onder GPL uitbrengen.
je code is onder GPL dus in principe (wettenlijk gezien) veilig voor uitbuiting

khtml is dus blijkbaar niet GPL maar LGPL lees ik hierboven.

[TheOneLLama]

KHTML is gewoon GPL. Het is inderdaad een "library", en niet zozeer een volledig programma. Maar dus niet LGPL. (QT, de widget toolkit van oa KDE is bv ook GPL en niet LGPL, als je een library maakt betekend dat echt niet dat je er direct LGPL voor zou moeten gebruiken)

Apple heeft de KHTML code gepakt, en deze ge"forked" en daar een product van gemaakt genaamd "Webcore". In het begin zorgde ze ervoor dat wijzingen in "Webcore" (wat specifiek voor OSX is) ook terug gegeven of in ieder geval doorgeven werden aan het KHTML project. Daar is men nu mee gekapt.

Men is dus nog wel steeds verplicht alle source van "Webcore" onder de GPL uit te brengen. Dat doet Apple ook. Er is echter een verschil tussen je source online zetten en een werkbaar open source project. Alles wat verder met development van Webcore te maken heeft (bug tracker, test rapporten, source managment, etc), zit achter gesloten deuren bij Apple.

Safari maakt gebruik van Webcore, maar het zijn technisch gezien 2 verschillende programmas. Dus Safari valt niet onder de GPL.

Wat het KHTML-team graag wil is dat Apple ipv van Webcore los ontwikkelen de wijzigingen van Webcore in KHTML integreerd, zodat wijzigingen die Apple in de toekomst maakt direct in KHTML komen, waardoor Apple kan profiteren van de wijzigingen die het KHTML team maakt.

Apple stelt (mogelijk) ook zoiets voor, maar dan dat zei verder gaan waar ze gebleven zijn (webcore dus) en dat KHTML meer toegang tot de development van Webcore krijgt.

Uiteindelijk willen beide partijen wel samenwerken lijkt me, maar beide (met name Apple) willen de ultime controle over het project bij zichzelf hebben.

[Verwijderd]

"khtml is dus blijkbaar niet GPL maar LGPL lees ik hierboven."

Dat is omdat KHTML een bibliotheek is. Daarvoor is die LGPL immers speciaal gemaakt. Er zijn wel nog steeds strenge voorwaarden aan verbonden, maar nie zo streng als bij GPL. Tis juist dat die voor die miserie zorgt, maar daar zorg je als ontwikkelaar zelf voor.
Er zijn ten slotte meer licencies dan enkel GPL als open-source, het is dus zeker niet zo dat open-source == open zetten voor uitbuiting!

[Verwijderd]

@TheOneLLama:

KHTML is gewoon GPL. Het is inderdaad een "library", en niet zozeer een volledig programma. Maar dus niet LGPL. (QT, de widget toolkit van oa KDE is bv ook GPL en niet LGPL, als je een library maakt betekend dat echt niet dat je er direct LGPL voor zou moeten gebruiken)

Zoals je in de code zelf kan zien is KHTML toch echt LGPL en geen GPL (!!!).

Voorbeeld:
http://webcvs.kde.org/kdelibs/khtml/design.h?rev=1.9&view=markup

Je hebt gelijk dat je een library niet perse onder de LGPL hoeft te dumpen, maar in dit geval hebben de ontwikkelaars van KHTML daar wel voor gekozen.

Qt is, zoals je zelf al aangeeft, inderdaad GPL is en alles wat daarmee gelinkt wordt moet de regels daarvan volgen (zoals aangegeven in de termen van de GPL).

KHTML bovenop Qt kan worden gezien als GPL, maar KHTML op zich (zonder gebruik te maken van Qt of andere code die onder de GPL valt) is gewoon LGPL.

Als KHTML GPL was geweest had Apple het niet eens kunnen gebruiken voor Safari omdat ze de rest van Safari dan ook openbaar hadden moeten maken (onder de GPL), wat hier duidelijk niet zo is.

btw. Voor de zoveelste keer (ik denk niet dat de mensen hier het ooit zullen leren ); QT == QuickTime, Qt == die API van Trolltech

[Verwijderd]

Patenten zijn in dit geval onzin; patenten beschermen ideen, en het is niet het idee waar Apple mee aan de haal zijn gegaan, maar de code. Code wordt normalitair beschermd door copyright. Deze geef je deels op met GPL.

Verder wil ik niet voor meneer "normen en waarden" spelen hier, maar de constatering dat morele argumenten moeilijk te verdedigen zijn betekent nog niet dat deze er niet toe doen.

Het uitbrengen van software onder de GPL(nog sterker met BSD) licentie getuigt van een zeker vertrouwen, vertrouwen dat mensen de vrijheid die je ze geeft om te doen met jouw code op een manier gebruiken die zowel de auteur en de gebruiker ten goede komt.

Je kan de programmeurs nu wel "naief" noemen, maar dit vertrouwen is wel wat de open source wereld zo groot heeft gemaakt.

Nu gaat het een keer mis, maar dat is een uitzondering op de vele keren dat de samenwerking tussen een bedrijf en een open source project wel goed gaat. Ik heb hier persoonlijk juist hele goede ervaringen mee, maar ben blij tegen Apple gewaarschuwd te zijn

[niqck]

Apple toont mooi aan waar de fout in GPL zit. Persoonlijk vind ik het best grappig. De GPL-zealots zitten continu te schreeuwen dat GPL het beste is sinds de uitvinding van het wiel, beter dan warm water. Apple volgt mooi de richtlijnen van de GPL en het is nog niet goed.

GPL zegt dat de source-code beschikbaar gesteld moet worden; doet Apple mooi. Nergens staat in welke vorm die beschikbaar moet zijn. Misschien worden ze bij de FSF nu eindelijk eens wakker en landen ze terug met beide voeten op de grond.

Ik heb niets tegen open-source, GPL of wat dan ook, ik juich het zelfs toe. Maar ik heb grote problemen met mensen die met oogkleppen door het leven gaan en van oordeel zijn dat zij als enigen het bij het rechte eind hebben en de rest van de wereld dom en fout is.

[Verwijderd]

Het gaat hier om de LGPL, er is een belangrijk verschil tussen die twee licenties.

De LGPL heeft een toevoeging die het mogelijk maakt afgeleide werken onder een andere licentie uit te brengen, de GPL heeft dat niet. (Had KDE dus voor de GPL gekozen dan was er geen probleem geweest.)

[TheOneLLama]

Het gaat hier helemaal niet om de LGPL. KHTML heeft (zoals vrijwel alle KDE projecten) een GPL licentie, geen LGPL licentie.

[Verwijderd]

Het gaat wel om de LGPL, want alle bibliotheken van KDE vallen onder de LGPL (kijk maar in de code: http://websvn.kde.org/trunk/KDE/kdelibs/khtml/ - alles LGPL).

De toepassingen vallen inderdaad voor het grootste gedeelte onder de GPL.

[Verwijderd]

hoe dan ook, het blijft niet netjes van Apple. en in mijn ogen is dit slechte promotie voor Apple. in ieder geval voor mij. mijn oude iMac zal ik zeker niet vervangen... Steve Jobs en dit soort praktijken... brrrr.

[Verwijderd]

Dave Hyatt (hoofd developer van het Safari team, daarvoor een van de ontwikkelaars van -onder meer- Mozilla) heeft de KHTML-ers uitgenodigd met hun grieven te komen.

What do you think Apple could be doing better here? Comment or trackback. I'll read it all.

(30 April 2005)

http://weblogs.mozillazine.org/hyatt/

Overigens klagen de meeste KHTML ontwikkelaars meer over ongeduldige gebruikers dan over Apple, in de trant van: "Ben ik weken bezig om iets te programmeren wat Safari op OS-nivo heeft opgelost, klagen de gebruikers alweer dat het zolang duurt en dat het in Safari allemaal allang draait."

Meer over Hyatt:

http://en.wikipedia.org/wiki/Dave_Hyatt

[Verwijderd]

welkom in de wereld van de bedrijven....

[sparkle]

Apple heeft toch ook de unix kern over genomen en verderd uitgebreid. En dan ook niet publiek gemaakt?

Zie ik dit goed?

[TheOneLLama]

Voor de kernel en Unix omgeving heeft men zich (voornamelijk) op BSD gebaseerd. Bij de BSD licentie hoef je wijzigingen in de source niet openbaar te maken (bv de TCP/IP stack van Windows is nog steeds op die van BSD gebaseerd).

Echter, Apple heeft dat wel gedaan:
http://www.opensource.apple.com/darwinsource/

Met name in de kernel ("Mach") is veel veranderd.

[KroeT]

Apple levert de code gewoon, alleen doet dat in te grote brokken die niet hapklaar genoeg zijn voor de Open Source gemeenschap. Dit is inderdaad niet zo netjes, en ik zie niet in waarom ze het niet anders doen, maar het breekt geen regels. Zolang de veranderingen in de code aangeleverd worden is er naar mijn mening niets aan de hand behalve flink wat werkverschaffing voor de niet-apple ontwikkelaars.

[Verwijderd]

't is heel simpel: wat Apple doet mag. Of het _slim_ is wat ze doen is een heel ander verhaal: Apple's patches worden niet/nauwelijks in KHTML opgenomen en dus zullen de codebases steeds verder uit elkaar gaan lopen. Op zich niks mis mee, maar Apple kan nu op zijn beurt niet meer profiteren van het werk wat in KHTML gebeurd.

Dit gedrag is erg typerend voor bedrijven die OSS code gaan gebruiken. Initieel veel werk overnemen, en op het moment dat ze die code zelf kunnen uitbrengen het project forken zodat ze op eigen kracht een "voorsprong" kunnen behalen. Niets mis mee opzich, MAAR:

Wat ze niet in lijken te zien is dat ze zichzelf met deze houding afgesloten hebben van een hele boel gratis mankracht, van programeerwerk tot Q/A.

Ach ja, ze komen daar over een jaartje ook wel achter. Gebeurd elke keer; niet druk om maken.

[MacWolf]

Zoals al aangegeven doet Apple niets illegaals. Toegegeven: ik ben er niet blij mee. Ik zou liever zien dat Apple op dit punt meer met de open-source gemeenschap samenwerkt.

Toch heb ik begrepen dat forken op zichzelf niets vreemds is in de open-source wereld. Er wordt van veel open-source software forks gemaakt die lastig te integreren is met de originele software. Dit alles begreep ik uit de thread bij Slashdot over dit onderwerp.

Dit alles neemt niet weg dat Apple op andere punten veel opener is qua broncode. Neem bijv. Bonjour (technologie die kortgeleden nog bekend stond onder de noemer Rendezvous en ook bekend is onder de naam zeroconf). Apple heeft Rendezvous in eerste instantie ontwikkeld en er een open-source project van gemaakt. In de Linux wereld zijn steeds meer applicaties te vinden die gebruik maken van de technologie).

Naast Rendezvous heeft Apple ook van launchd een open-source project gemaakt. Apple wil met launchd verschillende software vervangen, waaronder cron en applicatie launchers. Meer over launchd is te vinden op Slashdot. Launchd is een nette vervanger voor de vele verschillende launchers e.d. die in de Linux wereld te vinden zijn. Het geheel is bijv. te configureren met XML bestanden.

Daarnaast is natuurlijk de "achterkant" van OS X open-source, onder de noemer Darwin.

Een ieder die een erg negatief beeld heeft van dit nieuwsitem moet ook nog even deze pagina lezen (van een khtml ontwikkelaar bij KDE). De KDE ontwikkelaars zijn blijkbaar vooral ontevreden met kritiek uit de open-source wereld. Hun werk wordt vaak gezien als simpele kopiën van de broncode, terwijl het vaak allemaal ingewikkelder is.

EDIT: Een ieder die meer wilt weten van lauchd, lees dit artikel op Ars Technica en bekijk de man page bij Apple.

Het Safari weblog is trouwens geschreven door David Hyatt. David Hyatt was 1 van de orginele Mozilla ontwikkelaars en is dus niet onbekend met de open-source wereld. Zie dit nieuwsbericht uit 2002.

[Johnny]

Niet erg netjes van Apple, maar het is wel naief om geen glasharde afspraken te maken met een groot commercieel bedrijf, want dan vraag je er gewoon om dat er vroeg of laat zoiets gebeurt.

GPL zegt ook niet zoveel over het samenwerken aan projecten, alleen dat wijzigingen in de code moeten worden vrijgegeven, maar als die wijziginen je niet aanstaan heb je pech.

[bartvb]

Wat voor een afspraken zou je dan moeten maken? "Jullie maken geen gebruik van OS X specifieke function calls want anders ...". Ja, wat anders? De KHTML ontwikkelaars kunnen in deze situatie niets uitrichten. Hun engine valt onder GPL en dus kan iedereen KHTML pakken, in stukjes hakken en er aan veranderen wat ze willen. Ook zonder toestemming van de ontwikkelaars. Het is natuurlijk erg prettig als men _wel_ het fatsoen opbrengt om mee te blijven helpen met de ontwikkeling maar dat is, zoals je nu ziet, niet verplicht. IMO niet bepaald netjes van Apple. Wel soort van begrijpelijk aangezien zij verder moeten en niet altijd kunnen wachten op een aantal vrijwilligers die in hun vrije tijd aan KHTML werken en die vrijwel altijd een nette oplossing willen ipv 'een oplossing'. Ben benieuwd hoe dit verder uit gaat pakken. Overigens is er wel een soort van reactie geweest van de Apple kant:

http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054

Of ja, vooral een melding dat de kritiek ontvangen is en dat er naar geluisterd wordt (iig door Hyatt).

[Verwijderd]

Die toestemming hebben ze wel, de ontwikkelaars geven hun copyright immers weg onder de voorwaarden van de GPL!

[Verwijderd]

Je geeft je copyright niet weg! Copyright hou je. Echter, je brengt de software onder een licentie uit waarmee andere mensen het mogen aanpassen. Ook dan blijft het copyright echter van jou!

[paella]

de nog steeds populairder wordende browser Safari

ik vind dit een wat ongefundeerde uitspraak. Safari is op dit moment eigenlijk de browser bij de Mac. Ik ken geen getallen, maar het marktaandeel onder Mac zal heel hoog zijn. Ik zou eerder zeggen dat door Firefox, Camino enzo, het juist minder populair wordt.

Tenzij bedoeld wordt dat de Mac zelf steeds populairder wordt en dus ook Safari.

[Metal Baron]

Waarschijnlijk wordt Safari steeds populairder omdat:

a) Steeds meer OS9 gebruikers naar OSX overgaan
b) IE niet meer geleverd wordt met 10.4 en al niet meer standaard in 10.3
c) Het aandeel van MacOS langzaamaan toeneemt.

Camino, Omniweb, Opera waren er al lang voor Safari. Firefox doet het goed op het mac platform maar is duidelijk niet speciaal voor de mac gemaakt: het gevoel mist er nogal bij. Vandaar dat veel mensen FF naast Safari gebruiken, met name voor de extensies.

[egeltje]

Tja, met Safari gaat het op de Mac als Internet Explorer op de PC. Je krijgt het er bij, het werkt goed, dus waarom op zoek naar alternatieven?
Ik heb Firefox, IE voor de Mac en Camino geinstalleerd op mijn iBookje, maar heb (nog) geen zwaarwegende redenen gevonden om af te stappen van Safari.

[Verwijderd]

Wat een onzin weer hier.

Dat je zelf geen camino of firefox gebruikt op de mac wil nog niet zeggen dat je dat dan ook maar op alle andere mac-users moet projecteren.

Ben zelf zeer tevreden camino-user.

[Verwijderd]

ik vind dit een wat ongefundeerde uitspraak

fundament:
Marktaandeel Safari in april 2005 (1.21%) gestegen t.o.v. november 2004 (0.91%):
http://www.onestat.com/html/aboutus_pressbox37.html
http://www.tweakers.net/nieuws/35160/

[Verwijderd]

Nou nou.. Safari is grappig maar lang niet een goede browser. Ik wil de layout zien welke de webdesigner heeft gemaakt, niet wat safari er van bakt...

Neen, Firefox is de #1 op MacOs, en het verre neefje Konqueror draai ik ook wel eens.

[Verwijderd]

Safari geeft als enige de layout die de webdesigner gemaakt heeft. Wat je ziet zijn de miskleunen die de webdesigner moest maken om de pagina zichtbaar te maken op IE en Firefox.

Overigens is naar mijn mening Safari veel te streng door protocollen een hogere prioriteit te geven dan inhoud. Als ik een pagina bezoek wil ik die zien, ongeacht of Safari vind dat het een waardeloos geschreven pagina is.

[SuperDre]

Maar is het niet zo dat als je de code gebruikt en daar wijzigingen op maakt die moet delen met de open source community? Zo zijn toch de meeste Opensource licenties..
Tja, dit zul je in de toekomst anders wel veel vaker gaan zien, gewoon code pakken en daar aan verbeteren en dat dan commercieel uitbrengen..

[ILUsion]

Het is zeker niet altijd een vereiste om wijzigingen te delen bij open-source. Kijk naar de BSD/MIT-licentie, dan merk je dat gewoon een melding van je bron genoeg is (zo bevat ook Windows stukjes code die onder de BSD-licentie vallen). Met GPL is het een ander verhaal: je moet alle wijzigingen ook vrijgeven onder dezelfde voorwaarden die je zelf opgelegd gekregen hebt (onder de GPL dus).

Wat bij dit project het geval is geweest (zo maak ik uit op het artikel, zelf gebruik ik Konqueror amper en een Mac heb ik niet staan) is dat de ontwikkelaars van KHTML een samenwerking zijn aangegeaan met die van Apple die een render engine wilden in voor Safari. Bij Apple hebben ze een open-source prject opgezet dat WebCore noemt en de renderengine omvat, die echter gewoon geforkt (afgetakt: dus alle bruikbare source gekopiëerd) is van KHTML en dan hebben ze hun medewerking aan KHTML zowat stopgezet (niet helemaal, natuurlijk; maar ze deden natuurlijk liever bewerkingen aan hun eigen fork dan aan KHTML zelf), maar eigenlijk was de belofte dat ze samen zouden werken aan KHTML, wat nu dus wat verkeerd uitdraait.

Eigenlijk heeft Apple gewoon KHTML gebruikt als basis en geeft verbeteringen door als het hen uitkomt terwijl ze misschien evengoed zouden kunnen proberen KHTML ingebouwd te houden en daarin dan exclusief voor Mac bedoelde features conditioneel in te bouwen ofzo.

Het project KHTML kan dus wel aan alle source van WebCore (dat moet ook kunnen, volgens de GPL!) maar ze kunnen er niet zo veel mee omdat die code enkel voor Mac ontworpen is. Als ze er iets aan zouden willen hebben, moeten ze dus gewoon veel tijd zetten op het analyseren van die code, uitzoeken wat gaat werken en wat niet, wat problemen gaat geven, code verder uittesten terwijl ze evengoed gewoon aan KHTML zouden kunnen verderwerken op hun eigen houtje. Ze vragen dus aan Apple om opnieuw meer energie in KHTML te steken en te helpen om de verbeteringen die aan WebCore gebeuren ook bij KHTML door te voeren.

Het is natuurlijk vrij naïef om te denken dat Apple helemaal resources gaat steken in KHTML terwijl ze zelf een werkend WebCore hebben. Maar op zich wel een smerige streek vanaf dat forken.

[mOrPhie]

Maar is het niet zo dat als je de code gebruikt en daar wijzigingen op maakt die moet delen met de open source community?

Dat doet apple ook, alleen dan middels hun eigen WebCore en niet via KHtml, waardoor die verbeteringen ook in KHtml komen. De afsplitsing naar webcore is dus om het mogelijk te maken eigen belangen voor de community te zetten. Dat mag apple natuurlijk wel doen, maar is hoogst onbeschoft tegenover de mensen die al sinds 1996 aan KHtml werken en nu hun code gebruikt zien worden zonder dat ze er zelf baat bij hebben. Dat is gewoon net erg netjes.

[Brent]

Kinderen, onthoud: bedrijven zijn altijd evil.

[Gwaihir]

Ook op het moment dat ze ons loon overmaken?

Onze maatschappij staat of valt bij een gezond bedrijfsleven. Enige nuancering van die uitspraak lijkt me dus wel nodig.

[Superstoned]

niet helemaal.

je moet niet vergeten dat een bedrijf geleid word door mensen. die hebben ook doelen en idealen. Aandeelhouders zijn belangrijk, maar het is uiteindelijk maar 1 groep waarmee je rekening dient te houden. een belangrijke, absoluut. Maar werknemers zijn belangrijk (en het beeld wat zij van het bedrijf hebben). klanten zijn belangrijk (microsoft schiet zichzelf in de voet door haar klanten slecht te behandelen, maar dat merken ze wel). en, het imago van een bedrijf waar je topman geweest bent kan je maken of breken. als dat imago slecht is ben je er geweest. dus denk niet dat bedrijven niet gevoelig zijn voor dit soort media aandacht!

[Verwijderd]

FYI: een bedrijf kan geen kennis bezitten, een bedrijf bezit medewerkers die kennis bezitten...

[i-chat]

wellicht, een idee voor volgende, generatie projecten,

BOUW je eigen OS-Licentie, waarin je bijv een clausule kunt zetten die "commercieel" gebruik slechts toestaat onder het
"support the orriginal" beding...

[Verwijderd]

Dat is nou precies het idee achter de LGPL licentie. Indien je veranderingen aanbrengt moet je deze in de vorm van code beschikbaar stellen aan de originele auteur. Alleen heeft iedereen die jou project gebruikt wel volledige vrijheid in hoe en wat hij aan je code veranderd. Het hele free software idee is op deze vrijheid immers gebaseerd.
Het zou een restrictieve license zijn als ze voorwaarden gingen stellen "je mag doen met onze code wat je wil, ZOLANG je alles binnen onze architectuur doet, niets zonder onze toestemming toevoegt, ons op de hoogte stelt van elke verandering met een uitvoerig verslag.. ". Dan is het gelijk niet meer aantrekkelijk.

Aan de andere kant is dit niet "lief" van Apple. Waarom lopen de KHTML'ers uit "wraak" niet over naar Mozilla? Waarom zijn er uberhaupt twee open source html rendering engines? Het lijkt mij dat je veel verder komt als je je krachten bundelt.

[Verwijderd]

Dat is niet zo mooi van Opperhoofd Steve. Wel uit ongenoegen gebruik ik 24 uur lang enkel Camino als browser.

[Verwijderd]

hou er dan maar rekening mee dat je niet meer terug gaat... ik ben helemaal in love met camino .84!!!