↶
Changer les données, dévier la norme.
Des entreprises du Web ont adopté la fonction « Ne pas me pister » que Mozilla a proposée.
The do-not-track button also wouldn’t block companies such as Facebook Inc. from tracking their members through « Like » buttons and other functions.
Et les données seront quand même collectées, mais les entreprises s’engagent à ne pas les utiliser à des fins publicitaires ni à les utiliser pour l’emploi, les assurances, etc.
Heureusement, on peut quand même se prémunir (et c’est efficace).
Cette année, une petite nouvelle est arrivée dans le monde des licences de logiciel libre : la seconde version de la licence publique Mozilla (MPL 2.0). Elle n’est pas totalement nouvelle, car elle garde l’esprit général de la première version puisqu’il s’agit d’une licence de faible copyleft. C’est-à-dire que cette licence permet dans une certaine mesure — assez large — de combiner du code régi par la MPL avec du code sous une autre licence (y compris propriétaire). Pour autant, des modifications apportées aux fichiers du code MPL doivent être régies par les mêmes obligations : mise à disposition du code source, notifications des droits des utilisateurs (droits d’utiliser, de partager, d’étudier le fonctionnement et de publier des modifications — la définition d’un logiciel libre).
Ainsi, la MPL est un bon compromis, entre d’un côté les licences « académiques » (BSD, MIT) et de l’autre, les licences copyleft¹ fortes comme la licence publique générale GNU. Mais comme tout compromis, la MPL souffre des inconvénients incombant à chacun des deux modèles de licence.
Il y a cependant des qualités indéniables à la MPL 2.0, que j’ai voulues résumer ici :
C’est la principale qualité du copyleft à la sauce Mozilla : la portée de celui-ci se limite aux « Modifications » telles que définies par la MPL 2.0, c’est-à-dire tout fichier originellement sous MPL qui a été modifié, et tout nouveau fichier qui contient du code originellement sous MPL. Pour faire simple : tant qu’on ne touche pas à un fichier du code sous MPL, on est en dehors du cadre d’application de son copyleft.
Cette façon de procéder contraste largement avec le fonctionnement des licences GNU dont la portée du copyleft s’apprécie juridiquement, car celui-ci s’applique aux œuvres dérivées (derivative works en copyright). Or pour déterminer s’il s’agit d’une œuvre dérivée ou non, il faut à la fois solliciter des approches juridiques et techniques. Ça ne veut pas dire pour autant que cette solution est plus compliquée, ni moins sûre (il y a consensus) mais il reste des zones à clarifier (on peut voir un essai de catégorisation de plusieurs cas de figure où le copyleft s’applique ou ne s’appliquerait pas).
La MPL 2.0 a adopté une meilleure solution, qui déclare explicitement la compatibilité avec les licences GNU². On peut donc incorporer du code MPL 2.0 à du code GPL 3.0 par exemple, et distribuer le tout sous licence GPL 3.0 — tout en donnant la possibilité à celui qui reçoit l’ensemble de continuer à bénéficier de la portion du code MPL 2.0 sous cette licence.
Du côté des projets et des distributeurs de logiciels en aval, cette compatibilité simplifie grandement l’analyse du jeu de licences et leur travail de documentation, etc.
À l’heure où la guerre nucléaire sur les brevets est déclarée, on sait l’importance de ces clauses anti-brevets dans les licences de logiciels libres qui se sont développées depuis la version 1.1 de la MPL (1998). On peut dire en quelque sorte que ces clauses sont à la guerre des brevets, ce que les traités SALT sont aux armes nucléaires : des accords mutuels de non-agression.
Le licencié d’un logiciel sous MPL bénéficie de droits accordés par ses contributeurs. Si celui-ci engage des poursuites contre quiconque pour violation de brevets par le logiciel sous MPL, alors il perd tous les droits (droits d’auteur et droits sur les brevets des contributeurs) dont il avait bénéficié jusqu’alors grâce à la MPL.
Cette clause de défense contre les attaques pour violation de brevets (attaques souvent abusives, sur des brevets parfois invalides ou fantasques) est une avancée majeure par rapport à la version 1.1 de la MPL — laquelle avait une clause à la fois bien trop large puisqu’elle se déclenchait pour toutes poursuites de violation de brevets, y compris les brevets qui n’avaient rien à voir avec le logiciel sous MPL ; et à la fois bien trop restreinte puisqu’elle ne concernait que la poursuite d’ayant-droits du logiciel sous MPL, laissant les autres sans protections.
Dans l’ensemble, il faut saluer le travail de Mozilla qui a conduit la rédaction de cette version de la MPL. Il s’agit sensiblement d’une amélioration, qui a su garder les qualités inhérentes à la MPL tout en corrigeant les problèmes pratiques et en s’adaptant aux problématiques d’aujourd’hui notamment dans cette lutte contre les brevets qui, chaque jour, menacent les développeurs de logiciel.
En anglais : Articles de Luis Villa, qui a mené ce travail de rédaction de la MPL 2.0 ; Un article de Richard Fontana (RedHat) ; Communiqué de la FSF ; et enfin, le texte de la licence.
Hier, de nouvelles ambitions pour la vidéo sur le Web ont vu le jour. C’est officiel, Google publie un nouveau standard ouvert pour la vidéo. WebM est un conteneur pour le web, qui utilise le codec video VP8 et le codec audio Vorbis. Le conteneur est basé sur Matroska, un autre standard ouvert pour le multimédia.
Tout d’abord, voyons ce que cela change pour le Web et pour HTML5. Bien que techniquement, WebM ait encore des progrès à faire, il s’agit indéniablement d’un grand pas en avant. VP8 est un codec relativement nouveau et prometteur. Il est opérationnel : WebM est d’ores et déjà implémenté par Mozilla Firefox, Google Chromium et Opera du côté navigateurs; supporté par l’industrie pour l’accélération matérielle.
Avec des acteurs d’un tel poids, inutile de préciser : c’est un gros pavé dans la marre. Évidemment, H.264 et Theora vont en souffrir et avec YouTube, Google dispose presque d’une arme de destruction massive pour imposer de facto son standard — de la même manière que YouTube a massivement contribué à l’hégémonie de Flash pour la vidéo sur Internet ces dernières années.
Donc là où WebM change la donne par rapport à Theora, c’est d’une part sur la performance technique et d’autre part grâce au soutien immédiat et large dont il bénéficie. La bataille avec H.264 s’annonce rude. Mais je suis vraiment optimiste.
Qu’est-ce qui a changé dans le rapport de force ? Jusqu’ici, s’opposaient:
Alors, qu’est-ce qui a pu pousser Google à libérer VP8 ? Pour saisir toute l’importance de la question, rappelons que pour cela Google a fait l’acquisition de On2 Technologies, pour la somme de 106,5 millions de dollars. Qu’est-ce qui peut justifier un tel geste ? Après tout, il existe déjà H.264. Google aurait pu se permettre d’en rester là.
Apple et Microsoft s’en sont contentés, bien qu’ils clament ne pas avoir de réel intérêt économique à être licencié du MPEG-LA qui collectent les redevances de H.264.
Mais Google ne vient pas du même monde que Apple et Microsoft, leurs stratégies sont assez différentes. Il ne faut jamais oublier que Google vient avant tout du monde du Web et qu’une partie importante de son modèle économique est alimentée par le Web comme plateforme. D’ailleurs si on voit les autres annonces faites pendant le Google I/O, on remarquera qu’avec leurs nouvelles APIs et Wave, Google tente de devenir la plateforme centrale du Web.
C’est là, la différence majeure avec Apple et Microsoft. La plateforme de Microsoft, c’est Windows, et celles de Apple, iTunes et Apple Store.
Qu’est-ce que WebM a à voir là-dedans ? Principalement, un standard fermé comme H.264 est trop restrictif pour permettre le développement d’une plateforme Web. C’est d’ailleurs une des raisons motivant le passage à HTML5. Google veut que tous puissent se connecter à leur plateforme, quelque soit leur logiciel, quelque soit leur outil. Google veut être omniprésent sur le Web et surtout ne pas avoir à dépendre d’un intermédiaire, c’est une des raisons motivant le développement de Android pour les mobiles et de Chrome OS pour les netbooks : étendre encore les points d’entrée vers sa plateforme Web. Car c’est là le cœur de son activité et de ses revenus, notamment avec AdSense.
À l’opposé de ce modèle économique Web, Apple et Microsoft sont davantage dans une logique industrielle. Ils font du logiciel propriétaire, c’est-à-dire qu’ils veulent contrôler la plateforme (contrairement à Android, iPhone OS n’est pas libre) et contrôler le canal de distribution (c’est le succès de iTunes et de Apple Store). Or, pour contrôler le canal de distribution efficacement, il est plus facile de contrôler le format notamment de manière à éviter une concurrence trop multiple. C’est la grosse différence entre H.264 et les standards ouverts comme Theora et WebM. L’un est dans une logique d’industriels: on joue seulement entre géants; l’autre est dans une logique Web. La différence substantielle est que dans le premier cas, on a créé une exclusivité aux dépens des autres.
Or les répercussions sont importantes en matière de liberté d’expression. Dans le premier modèle, on voit bien que seuls sont amenés à s’exprimer ceux qui se soumettent aux conditions posées par Apple par exemple — avec toutes les conséquences en matière de censure que cela contient. D’autre part dans le premier modèle, le logiciel libre est exclu ou désavantagé.
Reste la question : que vont faire les licenciés du MPEG-LA, supporteurs de H.264 pour riposter ? La question des brevets est épineuse. Ce sera pour une prochaine fois, à suivre.
