A chaque fois qu'Apple modifie les clauses de l'accord de licence de l'App Store, l'affaire fait beaucoup parler d'elle. Deux clauses en particulier, la 3.3.1 et la 3.3.9, ont été l'objet de bien des attentions à mesure de leurs évolutions.
La première a fait figure d'exocet envoyé dans le jardin d'Adobe : publiée quatre jours avant la mise sur le marché de Flash CS5, elle interdisait la compilation d'applications à l'aide d'autres outils que ceux fournis par Apple, ainsi que l'inclusion de code interprété.
En d'autres termes, une clause taillée sur mesure pour interdire la création d'applications pour iOS à l'aide de Flash (lire Flash sur iPhone : comment ça marche). Le tout a entrainé une acerbe passe d'armes entre les deux sociétés (lire Evangéliste Adobe : « Apple, va te faire… » et Steve Jobs s'exprime sur Flash). Adobe a même lancé une procédure à l'encontre d'Apple (lire Anti-concurrence : Adobe a bien déposé plainte contre Apple).
La seconde clause en question visait le recueil des données personnelles des utilisateurs. Si on a pu croire qu'elle avait pour objectif d'empêcher le travail d'AdMob sur iOS (lire Clause 3.3.9 : les régies pub indépendantes enchantées), désormais sous la tutelle de Google après une tentative de rachat manquée de la part d'Apple, elle répondait en fait à une indiscrétion de Flurry Analytics. En effet, la société, qui fournit des outils statistiques aux développeurs qui insèrent son code de surveillance dans leurs applications, avait pu par ce biais repérer et dévoiler un certain prototype de tablette sur le campus d'Apple (lire La tablette capable de faire fonctionner des applis iPhone ?), s'attirant par là même la colère d'Apple.
AdMob retrouve sa patente sur l'App Store
Steve Jobs n'en avait pas fait grand mystère lors de son entretien public avec Walt Mossberg durant la conférence D8. Le patron d'Apple s'est défendu de vouloir empêcher le travail des concurrents d'iAds. Selon lui, les développeurs se doivent de demander l'autorisation des utilisateurs sur la collecte de leurs données personnelles, et celles-ci ne doivent servir qu'à des fins publicitaires et à rien d'autre.
Le développeur à l'origine de la question a fait remarquer à Steve Jobs qu'il y avait pourtant un besoin légitime de connaître le contexte d'utilisation de leurs applications afin de les améliorer. L'argument fait mouche, mais Jobs concède qu'Apple est pour l'heure trop échaudée, et qu'il sera toujours temps de discuter à nouveau avec Flurry Analytics une fois la colère retombée. Flurry a pris acte des nouvelles directives en jurant qu'on ne l'y reprendrait plus (lire Flurry répond à la pique de Steve Jobs).
Malgré les dénégations de Steve Jobs, la clause 3.3.9 a bel et bien empêché AdMob de travailler sur iOS (lire Accord de licence iOS : la valse des clauses).
Google n'a d'ailleurs pas tardé à réagir à l'annonce d'Apple pour faire part de son satisfécit :
Quoi qu'il en soit, il semble donc que l'ire d'Apple à l'encontre de Flurry soit apaisée, puisqu'elle révise la clause 3.3.9 en ces termes :
Il est donc à nouveau possible de procéder à une collecte de données, sur l'autorisation expresse de l'utilisateur, et il est interdit de fournir des éléments concernant l'appareil à un tiers. Flurry n'aura donc plus la primeur des prochains appareils d'Apple, tout rentre dans l'ordre.
Tout ça pour ça ?
Mais après l'escalade entre Apple et Adobe, c'est bien la révision de la clause 3.3.1 qui est la plus sensationnelle. Ce retour en arrière est assez inattendu dans la mesure où Apple avait fait montre d'une détermination indéfectible, et osons le dire, d'un certain sadisme à l'encontre de son amie de 26 ans (lire Apple/Adobe : petits massacres entre amis).
Apple avait justifié ce durcissement en déclarant que les logiciels multiplateformes diluaient la cohérence de son interface et manquaient nécessairement d'optimisation, sans omettre les risques de se voir à la merci d'un partenaire trop lent à implémenter les modifications apportées par Apple (lire SDK iPhone : pourquoi Apple a-t-elle changé la donne ?). Il s'agissait donc officiellement de motivations techniques, ce qui en soit était légitime… mais on se demande bien aujourd'hui ce qu'il en est advenu.
La clause 3.3.1 avait fait des victimes collatérales : nombre d'environnements de développement alternatifs se sont vus pris dans la tourmente (lire iPhone OS 4.0 : Vent de panique pour les SDK alternatifs). Si certains ont baissé les bras pour se recentrer sur d'autres axes (lire Clause 3.3.1 : RunRev se concentrera sur Android), d'autres ont persisté et Apple ne leur a guère fait de difficultés, confirmant par là même que seul Flash était directement visé, à défaut de nommément… une mise à jour de la clause 3.3.1 a d'ailleurs introduit la notion d'autorisation écrite de la part d'Apple pour utiliser du code interprété.
Mauvaise foi, quand tu nous tiens…
Car la clause 3.3.1, pour toute vertueuse qu'Apple l'ait voulue, posait un problème majeur, notamment concernant les moteurs de jeux : si ceux-ci sont bel et bien codés en C++ et compilés avec Xcode comme il se doit, les jeux qui les exploitent font un usage intensif de scripts interprétés en divers langages (LUA, Python, etc…) pour les personnaliser à leurs couleurs.
En somme, la clause 3.3.1 aurait tout simplement empêché le portage de moteurs renommés comme l'Unreal Engine 3, qui a fait les belles heures du dernier special event (lire Testez gratuitement l'Unreal Engine), ou encore l'Id Tech 5 au cœur de Rage (lire Carmack fait une démo de Rage sur iPhone).
Apple finit donc par faire machine arrière et autoriser tout langage et outil de compilation que les développeurs jugeront souhaitable d'utiliser, ouvrant ainsi les portes de l'App Store aux applications réalisées avec Flash CS5. La seule exigence qu'Apple conserve est d'interdire le téléchargement de code, compilé ou interprété, ce qui se comprend facilement : à quoi bon valider une application si son comportement peut être totalement changé après publication en modifiant un code externe qui serait intégré dynamiquement ? Apple permet toutefois de télécharger du code externe pour peu que son chargement et son exécution s'effectuent au sein de Webkit.
De la "magnanimité" d'Apple
Comment expliquer ce revirement de situation ? Certains ont voulu voir l'ombre d'Android dans ce fléchissement de la pomme : le support de Flash 10.1 dans la dernière mise à jour du système d'exploitation mobile de Google aurait été un tel revirement de situation qu'Apple n'aurait pu que s'avouer vaincue et s'en remettre aux bons soins d'Adobe. Il n'en est rien : n'oublions pas qu'il ne s'agit pas ici de permettre l'intégration de Flash dans Safari Mobile, mais bien de permettre la validation d'applications réalisées avec Flash CS5 en vue de leur distribution sur l'App Store. Il ne s'agit là pour Adobe que d'un pis aller, à défaut de prendre place dans le navigateur mobile d'Apple, pour conserver un semblant d'universalisme à Flash (lire Quand Adobe et Apple se disputent le Web).
Il faut donc chercher la cause ailleurs, et peut-être du côté de l'enquête diligentée à l'encontre d'Apple par la Commission Fédérale du Commerce sur la demande d'Adobe. Étant donné qu'Apple n'est pas en situation de monopole, elle peut certes faire ce que bon lui semble sur son App Store (lire Anti-concurrence : Apple doit-elle s'inquiéter ?).
Cependant, la validation d'applications qui étaient manifestement en violation de la clause 3.3.1, et le système de dérogations écrites instituées par Apple ressemble fort à une discrimination à la tête du client, et là était peut-être pour Adobe un moyen de faire sanctionner Apple. Plutôt que de risquer de se faire forcer la main dans une humiliation publique cuisante, la firme de Cupertino aura préféré revenir sur la clause litigieuse. Peut-être aussi qu'Apple a tout bêtement réalisé le déficit d'image que son intransigeance avait suscité, entraînant une levée de boucliers notamment du côté des développeurs qui s'étaient investis sur les SDK alternatifs.
La réaction de Wall Street ne se sera pas fait attendre : l'action d'Adobe a bondi de 12 %, quoi que John Nack veuille voir dans cet enthousiasme un intérêt de la bourse pour l'annonce de Flash Media Server 4.0… à chacun de juger quelle théorie semble la plus probable.
Adobe a par ailleurs réagi officiellement sur son compte Twitter :
Voilà l'épilogue d'une bataille rangée qui aura fait couler beaucoup d'encre. Reste à voir si les fruits de ce revirement seront à la hauteur des attentes de l'une… ou des réticences de l'autre. Espérons que les deux sociétés sauront mettre de côté leurs rancœurs pour collaborer plus sereinement à l'avenir: de gré ou de force, elles sont condamnées à travailler ensemble.
La première a fait figure d'exocet envoyé dans le jardin d'Adobe : publiée quatre jours avant la mise sur le marché de Flash CS5, elle interdisait la compilation d'applications à l'aide d'autres outils que ceux fournis par Apple, ainsi que l'inclusion de code interprété.
En d'autres termes, une clause taillée sur mesure pour interdire la création d'applications pour iOS à l'aide de Flash (lire Flash sur iPhone : comment ça marche). Le tout a entrainé une acerbe passe d'armes entre les deux sociétés (lire Evangéliste Adobe : « Apple, va te faire… » et Steve Jobs s'exprime sur Flash). Adobe a même lancé une procédure à l'encontre d'Apple (lire Anti-concurrence : Adobe a bien déposé plainte contre Apple).
La seconde clause en question visait le recueil des données personnelles des utilisateurs. Si on a pu croire qu'elle avait pour objectif d'empêcher le travail d'AdMob sur iOS (lire Clause 3.3.9 : les régies pub indépendantes enchantées), désormais sous la tutelle de Google après une tentative de rachat manquée de la part d'Apple, elle répondait en fait à une indiscrétion de Flurry Analytics. En effet, la société, qui fournit des outils statistiques aux développeurs qui insèrent son code de surveillance dans leurs applications, avait pu par ce biais repérer et dévoiler un certain prototype de tablette sur le campus d'Apple (lire La tablette capable de faire fonctionner des applis iPhone ?), s'attirant par là même la colère d'Apple.
AdMob retrouve sa patente sur l'App Store
Steve Jobs n'en avait pas fait grand mystère lors de son entretien public avec Walt Mossberg durant la conférence D8. Le patron d'Apple s'est défendu de vouloir empêcher le travail des concurrents d'iAds. Selon lui, les développeurs se doivent de demander l'autorisation des utilisateurs sur la collecte de leurs données personnelles, et celles-ci ne doivent servir qu'à des fins publicitaires et à rien d'autre.
Le développeur à l'origine de la question a fait remarquer à Steve Jobs qu'il y avait pourtant un besoin légitime de connaître le contexte d'utilisation de leurs applications afin de les améliorer. L'argument fait mouche, mais Jobs concède qu'Apple est pour l'heure trop échaudée, et qu'il sera toujours temps de discuter à nouveau avec Flurry Analytics une fois la colère retombée. Flurry a pris acte des nouvelles directives en jurant qu'on ne l'y reprendrait plus (lire Flurry répond à la pique de Steve Jobs).
Malgré les dénégations de Steve Jobs, la clause 3.3.9 a bel et bien empêché AdMob de travailler sur iOS (lire Accord de licence iOS : la valse des clauses).
Google n'a d'ailleurs pas tardé à réagir à l'annonce d'Apple pour faire part de son satisfécit :
C'est une grande nouvelle pour toute la communauté mobile, car nous pensons qu'un environnement concurrentiel est le meilleur moyen de pousser l'innovation et la croissance dans la publicité mobile. La publicité mobile a déjà concouru à financer des dizaines de milliers d'applications à travers de nombreux appareils et plateformes différents, et continuera de le faire pour bien des années encore.
Quoi qu'il en soit, il semble donc que l'ire d'Apple à l'encontre de Flurry soit apaisée, puisqu'elle révise la clause 3.3.9 en ces termes :
Vous ou vos applications ne pouvez collecter les données des utilisateurs ni de leurs appareils sans leur consentement préalable, et ce faisant à seule fin de fournir un service ou une fonction qui soient directement pertinents pour l'utilisation de l'application, ou pour distribuer des publicités. Vous ne pouvez pas utiliser de fonctions analytiques dans votre application pour collecter et envoyer des données concernant l'appareil à une tierce partie
Il est donc à nouveau possible de procéder à une collecte de données, sur l'autorisation expresse de l'utilisateur, et il est interdit de fournir des éléments concernant l'appareil à un tiers. Flurry n'aura donc plus la primeur des prochains appareils d'Apple, tout rentre dans l'ordre.
Tout ça pour ça ?
Mais après l'escalade entre Apple et Adobe, c'est bien la révision de la clause 3.3.1 qui est la plus sensationnelle. Ce retour en arrière est assez inattendu dans la mesure où Apple avait fait montre d'une détermination indéfectible, et osons le dire, d'un certain sadisme à l'encontre de son amie de 26 ans (lire Apple/Adobe : petits massacres entre amis).
Apple avait justifié ce durcissement en déclarant que les logiciels multiplateformes diluaient la cohérence de son interface et manquaient nécessairement d'optimisation, sans omettre les risques de se voir à la merci d'un partenaire trop lent à implémenter les modifications apportées par Apple (lire SDK iPhone : pourquoi Apple a-t-elle changé la donne ?). Il s'agissait donc officiellement de motivations techniques, ce qui en soit était légitime… mais on se demande bien aujourd'hui ce qu'il en est advenu.
La clause 3.3.1 avait fait des victimes collatérales : nombre d'environnements de développement alternatifs se sont vus pris dans la tourmente (lire iPhone OS 4.0 : Vent de panique pour les SDK alternatifs). Si certains ont baissé les bras pour se recentrer sur d'autres axes (lire Clause 3.3.1 : RunRev se concentrera sur Android), d'autres ont persisté et Apple ne leur a guère fait de difficultés, confirmant par là même que seul Flash était directement visé, à défaut de nommément… une mise à jour de la clause 3.3.1 a d'ailleurs introduit la notion d'autorisation écrite de la part d'Apple pour utiliser du code interprété.
Mauvaise foi, quand tu nous tiens…
Car la clause 3.3.1, pour toute vertueuse qu'Apple l'ait voulue, posait un problème majeur, notamment concernant les moteurs de jeux : si ceux-ci sont bel et bien codés en C++ et compilés avec Xcode comme il se doit, les jeux qui les exploitent font un usage intensif de scripts interprétés en divers langages (LUA, Python, etc…) pour les personnaliser à leurs couleurs.
En somme, la clause 3.3.1 aurait tout simplement empêché le portage de moteurs renommés comme l'Unreal Engine 3, qui a fait les belles heures du dernier special event (lire Testez gratuitement l'Unreal Engine), ou encore l'Id Tech 5 au cœur de Rage (lire Carmack fait une démo de Rage sur iPhone).
Apple finit donc par faire machine arrière et autoriser tout langage et outil de compilation que les développeurs jugeront souhaitable d'utiliser, ouvrant ainsi les portes de l'App Store aux applications réalisées avec Flash CS5. La seule exigence qu'Apple conserve est d'interdire le téléchargement de code, compilé ou interprété, ce qui se comprend facilement : à quoi bon valider une application si son comportement peut être totalement changé après publication en modifiant un code externe qui serait intégré dynamiquement ? Apple permet toutefois de télécharger du code externe pour peu que son chargement et son exécution s'effectuent au sein de Webkit.
De la "magnanimité" d'Apple
Comment expliquer ce revirement de situation ? Certains ont voulu voir l'ombre d'Android dans ce fléchissement de la pomme : le support de Flash 10.1 dans la dernière mise à jour du système d'exploitation mobile de Google aurait été un tel revirement de situation qu'Apple n'aurait pu que s'avouer vaincue et s'en remettre aux bons soins d'Adobe. Il n'en est rien : n'oublions pas qu'il ne s'agit pas ici de permettre l'intégration de Flash dans Safari Mobile, mais bien de permettre la validation d'applications réalisées avec Flash CS5 en vue de leur distribution sur l'App Store. Il ne s'agit là pour Adobe que d'un pis aller, à défaut de prendre place dans le navigateur mobile d'Apple, pour conserver un semblant d'universalisme à Flash (lire Quand Adobe et Apple se disputent le Web).
Il faut donc chercher la cause ailleurs, et peut-être du côté de l'enquête diligentée à l'encontre d'Apple par la Commission Fédérale du Commerce sur la demande d'Adobe. Étant donné qu'Apple n'est pas en situation de monopole, elle peut certes faire ce que bon lui semble sur son App Store (lire Anti-concurrence : Apple doit-elle s'inquiéter ?).
Cependant, la validation d'applications qui étaient manifestement en violation de la clause 3.3.1, et le système de dérogations écrites instituées par Apple ressemble fort à une discrimination à la tête du client, et là était peut-être pour Adobe un moyen de faire sanctionner Apple. Plutôt que de risquer de se faire forcer la main dans une humiliation publique cuisante, la firme de Cupertino aura préféré revenir sur la clause litigieuse. Peut-être aussi qu'Apple a tout bêtement réalisé le déficit d'image que son intransigeance avait suscité, entraînant une levée de boucliers notamment du côté des développeurs qui s'étaient investis sur les SDK alternatifs.
La réaction de Wall Street ne se sera pas fait attendre : l'action d'Adobe a bondi de 12 %, quoi que John Nack veuille voir dans cet enthousiasme un intérêt de la bourse pour l'annonce de Flash Media Server 4.0… à chacun de juger quelle théorie semble la plus probable.
Adobe a par ailleurs réagi officiellement sur son compte Twitter :
Nous sommes rassurés de voir Apple lever les restrictions sur les termes de sa licence, offrant aux développeurs la liberté de choisir les outils qu'ils utilisent.
Voilà l'épilogue d'une bataille rangée qui aura fait couler beaucoup d'encre. Reste à voir si les fruits de ce revirement seront à la hauteur des attentes de l'une… ou des réticences de l'autre. Espérons que les deux sociétés sauront mettre de côté leurs rancœurs pour collaborer plus sereinement à l'avenir: de gré ou de force, elles sont condamnées à travailler ensemble.
