Par contre Apple ne respecte pas l'esprit GPL/LGPL en faisant tres peu d'effort pour intégrer leurs modifications dans le projet originel, bref un fork comme tu dis.
Sans vouloir trouver des excuses à Apple, il se trouve qu'il est généralement difficile de faire collaborer des équipes de devs qui travaillent sur leur temps libre (et n'ont pas d'obligation de résultat) et des gens qui bossent dessus à temps plein et doivent sortir du produit au bout.
J'en veux pour preuve la quantité de patchs non appliqués par manque de temps dans le projet MPlayer: les contributions extérieures ne sont pas toujours dans la droite ligne du projet, et ne plaisent pas toujours à l'équipe de dévelloppement, tels qu'elles sont implémentées.
Par exemple, le projet Unichrome, qui ajoute le support des puces graphiques VIA existe depuis pas mal de temps, et a été plusieurs fois rejetté parceque le patch touchait à beaucoup de choses à la fois, certaines de ces modifications étant par ailleurs inutiles.
Si on regarde du côté de GCC, Apple a aussi sa version de GCC qui fonctionne diablement mieux pour générer du code Altivec que le GCC "normal". Or, toutes ces modifications ne se sont pas non plus retrouvées dans le "vrai" GCC pour les même raisons exposées plus haut.
Bref, Apple ne respecte pas tellement l'idéologie, mais on ne peut pas dire non plus que ça soit évident de contenter tout le monde
La je pense qu'Apple sous-estime le besoin de coopérer sainement avec des developpeurs du libres
J'aurais été curieux de voir ce qu'aurait donné une collaboration "à la Red Hat": ie: embaucher les gens du projet pour le faire avancer suivant sa volonté.
Ca marche avec RedHat, mais c'est une entreprise d'inspiration libre depuis le début.
Apple, c'est différent, ils ont toujours été très secret sur leur façon de fonctionner... bah, peut-être qu'il faut leur laisser un peu de temps... Un virage à 180°, ça se négocie par trop vite, sinon on se casse la gueule...
[^] # Re: Licences
Posté par Guillaume POIRIER . En réponse à la dépêche KDE doit-il abandonner KHTML pour Webcore ?. Évalué à 10.
Sans vouloir trouver des excuses à Apple, il se trouve qu'il est généralement difficile de faire collaborer des équipes de devs qui travaillent sur leur temps libre (et n'ont pas d'obligation de résultat) et des gens qui bossent dessus à temps plein et doivent sortir du produit au bout.
J'en veux pour preuve la quantité de patchs non appliqués par manque de temps dans le projet MPlayer: les contributions extérieures ne sont pas toujours dans la droite ligne du projet, et ne plaisent pas toujours à l'équipe de dévelloppement, tels qu'elles sont implémentées.
Par exemple, le projet Unichrome, qui ajoute le support des puces graphiques VIA existe depuis pas mal de temps, et a été plusieurs fois rejetté parceque le patch touchait à beaucoup de choses à la fois, certaines de ces modifications étant par ailleurs inutiles.
Si on regarde du côté de GCC, Apple a aussi sa version de GCC qui fonctionne diablement mieux pour générer du code Altivec que le GCC "normal". Or, toutes ces modifications ne se sont pas non plus retrouvées dans le "vrai" GCC pour les même raisons exposées plus haut.
Bref, Apple ne respecte pas tellement l'idéologie, mais on ne peut pas dire non plus que ça soit évident de contenter tout le monde
J'aurais été curieux de voir ce qu'aurait donné une collaboration "à la Red Hat": ie: embaucher les gens du projet pour le faire avancer suivant sa volonté.
Ca marche avec RedHat, mais c'est une entreprise d'inspiration libre depuis le début.
Apple, c'est différent, ils ont toujours été très secret sur leur façon de fonctionner... bah, peut-être qu'il faut leur laisser un peu de temps... Un virage à 180°, ça se négocie par trop vite, sinon on se casse la gueule...