En même temps, la GPL n'oblige qu'à reverser le code pas à merger sur la branche principale. Et il ne faut se plaindre que des forks soient possibles, sinon il fallait pas migrer sous git mais sous SVN ;)
D'ailleurs, tu illustres toi-même que le monde de l'embarqué est à part car ils n'ont pas besoin d'un grande part du kernel.
C'est donc que visiblement il n'y a pas que Google que ca dérange.
La question serait peut-être de se demander s'il ne devrait pas y avoir une branche intermédiaire qui correspondrait à un sous-projet pour toutes les architectures embarquée. A partir de là chaque version pourrait diverger à sa guise (Maemo, Android, ...) et relivrer sur cette branche tandis que des synchros régulières avec la main peuvent être prises en charge en commun.
Chacun fait un pas vers l'autre.
Mais ca existe peut-être déjà ou c'est peut-être ce qui est proposé par Greg Kroah-Hartman.
[^] # Re: Appelons un fork, un fork
Posté par nomorepost . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à 3.
D'ailleurs, tu illustres toi-même que le monde de l'embarqué est à part car ils n'ont pas besoin d'un grande part du kernel.
C'est donc que visiblement il n'y a pas que Google que ca dérange.
La question serait peut-être de se demander s'il ne devrait pas y avoir une branche intermédiaire qui correspondrait à un sous-projet pour toutes les architectures embarquée. A partir de là chaque version pourrait diverger à sa guise (Maemo, Android, ...) et relivrer sur cette branche tandis que des synchros régulières avec la main peuvent être prises en charge en commun.
Chacun fait un pas vers l'autre.
Mais ca existe peut-être déjà ou c'est peut-être ce qui est proposé par Greg Kroah-Hartman.