Qu’il s’agisse de son code ou de son utilisation, la faiblesse de la documentation d’un logiciel libre est souvent montrée du doigt.

Voici, selon Andy Lester, 13 défauts ou lacunes communément rencontrés, qui sont autant d’écueils que l’on peut contourner avec un minimum d’efforts aujourd’hui pour gagner demain un temps précieux.

13 choses que les gens détestent sur vos documentations open source

13 Things People Hate about Your Open Source Docs

Andy Lester – 10 janvier 2013 – SmartBear Blog
(Traduction : Lamessen, calou, Shanx, sinma, Asta + anonymes)

La plupart des développeurs open source aiment penser à la qualité du logiciel qu’ils développent, mais la qualité de la documentation est souvent laissée de côté. Il est rare de voir vanter la documentation d’un projet, et pourtant elle a un impact direct sur sa réussite. Sans une bonne documentation, les utilisateurs n’utiliseront pas votre projet, ou ils n’y prendront pas de plaisir. Les utilisateurs comblés sont ceux qui diffusent des infos à propos de votre projet – ce qu’ils ne font qu’après avoir compris comment il fonctionne. Et ils apprennent cela à partir de la documentation du projet.

Malgré tout, de trop nombreux projets ont une documentation décevante. Et cela peut être décevant de plusieurs manières.

Les exemples que je donne ci-dessous sont purement arbitraires, je ne veux pas cibler un projet en particulier. Ce sont seulement ceux que j’ai utilisés récemment, cela ne veut pas dire qu’ils représentent les pires atrocités. Chaque projet a commis au moins quelques-uns de ces péchés. Que vous soyez utilisateur ou développeur, à vous d’évaluer à quel point votre logiciel préféré est ou non coupable, et comment vous pouvez aider à y remédier le cas échéant.

1. Le manque d’une bonne introduction ou d’un README/LISEZ-MOI

Le README/LISEZ-MOI est la première impression que les utilisateurs potentiels ont de votre projet. Si le projet est sur GitHub, le README/LISEZ-MOI est automatiquement affiché sur la page d’accueil du projet. Si vous l’avez mal rédigé, ils peuvent ne jamais revenir.

Vous voulez capter l’attention du lecteur et l’encourager à continuer la découverte de votre projet ? Le README/LISEZ-MOI devrait alors au moins expliquer :

• ce que le projet fait
• pour qui il est fait
• sur quel matériel ou plateforme il tourne
• toutes les dépendances majeures, comme « Requiert Python 2.6 et libxml »
• comment l’installer, ou un accompagnement de chaque étape à la suivante.

Tout cela doit pouvoir être compris par quelqu’un qui n’a jamais entendu parler de votre projet, et peut-être même jamais imaginé un projet pouvant s’en rapprocher. Si le projet possède un module calculant la distance de Levenshtein, ne partez pas du principe que n’importe qui lisant votre README/LISEZ-MOI sait ce que c’est. Expliquez que la distance de Levenshtein est utilisée pour comparer deux chaînes de caractères, et ajoutez quelques renvois vers des explications plus poussées pour celui qui aimerait approfondir le sujet.

Ne décrivez pas votre projet par rapport à un autre projet, comme « NumberDoodle est comme BongoCalc, mais meilleur ! » Ça n’est d’aucune aide pour quelqu’un qui n’a jamais entendu parlé de BongoCalc.

2. La documentation non disponible en ligne

Bien que je n’ai pas lu d’études à ce sujet, je serais prêt à parier que 90% des recherches de documentation sont faites avec Google et un navigateur sur Internet. La documentation de votre projet doit être en ligne, et disponible. Partant de là, il serait embarrassant que la documentation de mon propre projet, ack, ne soit pas disponible à l’endroit où la majorité des gens vont la chercher. Mon hypothèse est basée sur ma propre expérience, à savoir que si je veux connaître le fonctionnement d’un outil en ligne de commande, je vais vérifier sa page man.

Comment je m’en suis aperçu ? Les utilisateurs m’écrivaient pour me poser des questions dont les réponses se trouvaient dans la FAQ. Ce qui m’a ennuyé : ils ne lisaient pas ma FAQ. Il se trouve qu’ils avaient cherché sur le site internet, mais je n’avais pas mis la FAQ à cet endroit. C’est une erreur facile à faire. Je suis proche du projet et je n’ai jamais eu besoin d’utiliser moi-même la FAQ, je n’avais donc pas remarqué qu’elle n’était pas présente en ligne. Beaucoup de problèmes sont dus à ce piège : les auteurs ne se mettent pas à la place des utilisateurs.

3. La documentation disponible uniquement en ligne

Le revers de ce problème est d’avoir la documentation disponible uniquement en ligne. Certains projets ne distribuent pas la documentation avec les livrables du projet, ou incluent une version médiocre de la documentation.

Le moteur de recherche Solr, par exemple, a un excellent wiki qui sert à la documentation du projet. Malheureusement, la documentation liée au téléchargement comporte 2200 pages de Javadoc d’API auto-générées. Au final, la seule documentation pour l’utilisateur est une unique page de tutoriel.

Le langage PHP n’est distribué avec aucune documentation. Si vous voulez la documentation, vous devez aller sur une page séparée pour les obtenir. Pire, seule la documentation du cœur est disponible au téléchargement, sans les annotations utiles des utilisateurs (voir « Ne pas accepter les remarques des utilisateurs » plus bas), et ce n’est pas le même format facile à parcourir que celui qui est disponible en ligne.

Les projets open source ne peuvent pas supposer que les utilisateurs ont accès à Internet quand ils ont besoin de la documentation. Le mode avion existe toujours. De toute façon, vous ne souhaitez pas que l’utilisateur dépende uniquement du fait que votre site web est disponible ou non. Au moins à deux reprises durant les derniers mois, le wiki de Solr était indisponible au beau milieu de ma journée de travail alors que je recherchais des informations sur un problème de configuration épineux.

Un projet qui fait les choses bien est Perl et son dépôt de module CPAN. La documentation pour chaque module est disponible soit à search.cpan.org ou metacpan.org dans un format hypertexte facile à lire. Pour la consultation hors-ligne, la documentation de chaque module est intégrée dans le code lui-même, et quand le module est installé sur le système d’un utilisateur, la documentation locale est créée sous forme de pages man. Les utilisateurs peuvent aussi utiliser « perldoc Module::Name » pour obtenir la documentation depuis le shell. En ligne ou hors-ligne : c’est votre choix.

4. La documentation non installée avec le paquet

Ce problème est généralement une erreur des paquageurs, pas des auteurs du projet. Par exemple, sur Ubuntu Linux, la documentation du langage Perl est séparée, ce sont des paquets optionnels pour le langage lui-même. L’utilisateur doit savoir qu’il doit explicitement installer la documentation de la même façon que le langage principal ou il n’y aura pas accès quand il en aura besoin. Ce compromis de quelques mégabites d’espace disque au détriment de la documentation à portée de main de l’utilisateur dessert tout le monde.

5. Le manque de captures d’écran

Il n’y a pas de meilleur moyen d’obtenir l’attention potentielle d’un utilisateur, ou d’illustrer un usage correct, qu’avec des captures d’écran judicieuses. Une image vaut mieux qu’un long discours, c’est encore plus important sur Internet parce que vous ne pouvez obtenir d’un lecteur de lire plus de quelques centaines de mots en tout.

Les captures d’écran accompagnant le texte sont inestimables pour guider l’utilisateur voulant faire les choses au mieux. Une capture d’écran lui permet de comparer visuellement ses résultats à ceux de la documentation et va le rassurer d’avoir exécutée la tâche correctement ou l’aidera à trouver facilement ce qui ne va pas.

Il est de plus en plus commun de trouver des vidéos sur le site internet d’un projet pour en donner un aperçu, et c’est génial. Tout autant que le fait d’avoir une vidéo pour chaque étape d’un processus complexe. Le projet Plone, par exemple, a un site entier dédié aux tutoriels vidéos. Cependant, les vidéos ne peuvent pas remplacer les captures d’écran. Un utilisateur veut voir rapidement l’allure des captures d’écran sans s’arrêter devant une vidéo. Les vidéos n’apparaissent également pas dans une recherche Google Image, à l’inverse des captures d’écran.

6. Le manque d’exemples réalistes

Pour les projets basés sur du code, l’analogue des captures d’écran sont de bons et solides exemples du code en action. Ces exemples ne devraient pas être abstraits, mais directement issus du monde réel. Ne créez pas d’exemples bateaux plein de « nom de la démo ici » et lorem ipsum. Prenez le temps de créer des exemples signifiants avec une histoire d’utilisateur qui représente la façon dont votre logiciel résout un problème.

Il y a de bonnes raisons de vous embêter avec des problèmes de maths en classe. Ils permettent d’appliquer ce que vous avez appris.

Disons que j’ai écrit un module d’un robot Web, et que j’explique la méthode follow_link. Je pourrais montrer la définition de la méthode ainsi :

$mech->follow_link( text_regex => $regex_object, n => $link_index );

Mais admirez à quel point cela devient évident en ajoutant de la réalité dans l’exemple.

# Suit le 2e lien où la chaîne de caractères « download » apparait
$mech->follow_link( text_regex => qr/download/, n => 2 );

Les noms des variables $regex_object et $link_index sont maintenant compréhensibles par le lecteur.

Bien entendu, vos exemples ne doivent pas être aussi brefs. Comme Rich Bowen du projet Apache le souligne, « Un exemple correct, fonctionnel, testé et commenté l’emporte sur une page de prose, à chaque fois. »

Montrez autant que possible. L’espace n’est pas cher. Créez une section dédiée aux exemples dans la documentation, ou même un livre de cuisine. Demandez aux utilisateurs d’envoyer du code qui fonctionne, et publiez leurs meilleurs exemples.

7. Liens et références inadéquats

Vous avez les hyperliens. Utilisez-les.

Ne pensez pas, parce que quelque chose est expliquée dans une certaine partie de la documentation, que le lecteur a déjà lu cette partie, ou bien qu’il sait où elle se trouve. Ne vous contentez pas de signaler que cette partie du code manipule des objets frobbitz. Expliquez brièvement lors du premier usage de ce terme ce qu’est un objet frobbitz, ou donnez le lien vers la section du manuel l’expliquant. Encore mieux, faites les deux !

8. Oublier les nouveaux utilisateurs

Il arrive trop souvent que l’écriture de la documentation soit rédigée à partir du point de vue de son auteur, alors que es nouveaux utilisateurs ont besoin de documentation d’introduction pour les aider.

L’introduction devrait être une page séparée de la documentation, idéalement avec des exemples qui permettent à l’utilisateur de réussir quelques manipulations avec le logiciel. Pensez à l’excitation que vous ressentez quand vous commencez à jouer avec un nouveau logiciel et qu’il vous permet de faire quelque chose de cool. Faites que ça arrive aux nouveaux utilisateurs également.

Par exemple, un package graphique pourrait présenter une série de captures d’écran qui montrent comment ajouter des données dans un fichier, comment faire intervenir le grapheur, et ensuite montrer les graphes obtenus. Une bibliothèque de codes pourrait montrer quelques exemples d’appels à la bibliothèque, et montrer le résultat obtenu. Pensez simplicité. Offrez une victoire facile. Le texte devrait introduire les termes aux endroits appropriés, avec des liens vers une documentation plus détaillée sur le long terme.

Un document de démarrage séparé donne à l’utilisateur une compréhension rapide du logiciel. Il garde aussi les explications d’introduction en dehors de la partie principale de votre documentation.

9. Ne pas écouter les utilisateurs

Les développeurs doivent écouter les utilisateurs de la documentation. La chose évidente est d’écouter les suggestions et requêtes des personne qui utilisent activement votre logiciel. Quand un utilisateur prend le temps d’écrire un mail ou de poster quelque chose comme « ça aurait pu m’aider à mieux installer le programme s’il y avait eu une explication ou des liens au sujet des pilotes de la base de données », prenez ce message au sérieux. Pour chaque utilisateur vous envoyant un mail pour un problème, vous devez vous attendre à ce que dix utilisateurs silencieux aient le même problème.

Il est important d’écouter les problèmes des utilisateurs et d’en chercher les causes. S’ils ont souvent des problèmes pour effectuer des mises à jour groupées de bases de données, la première chose à faire est d’ajouter une question à la FAQ (vous avez bien une FAQ, n’est-ce pas ?) qui traite de ces questions-là. Cependant, la question peut aussi indiquer que la section traitant des mises à jour de base de données n’est pas assez claire. Ou peut-être qu’il n’y a pas de référence à cette section depuis la vue d’ensemble introductive du document, avec pour conséquence que vos utilisateurs ne pensent jamais à lire le reste du manuel.

En plus d’aider plus de gens à découvrir à quel point votre projet est utile, ça diminuera aussi la frustration de la communauté déjà existante. Si votre liste de diffusion, forum ou canal IRC est remplie de personnes qui posent toutes les mêmes questions idiotes (ou pas si idiotes) au point que tout le monde devient lassé d’y répondre, sachez reconnaître que ce sont des questions récurrents pour la FAQ, et mettre les réponses à un endroit facile à trouver aidera tout le monde à se concentrer sur des choses plus amusantes.

Gardez aussi un œil sur les questions des forums externes. Consultez les sites comme StackOverflow régulièrement, et placez une Google Alert sur votre nom de projet pour être maintenu au courant des discussions concernant votre projet sur Internet.

10. Ne pas accepter les entrées des utilisateurs

Si votre projet a une base d’utilisateur assez grande, il peut être judicieux d’incorporer les commentaires des utilisateurs directement dans la documentation. Le meilleur exemple que j’ai pu voir est celui donné par PHP. Chaque page de la documentation permet aux utilisateurs authentifiés d’ajouter des commentaires sur la page, aidant ainsi à clarifier certains points ou ajoutant des exemples qui ne sont pas dans la documentation principale. L’équipe PHP laisse aussi le choix au lecteur de lire la doc avec ou sans les commentaires des autres utilisateurs.

Aussi pratique cela soit-il, cela nécessite de la maintenance. Les commentaires doivent être éliminés de temps en temps pour éviter la prolifération. Par exemple, la page de la documentation PHP sur comment lancer PHP depuis la ligne de commande inclut 43 commentaires d’utilisateurs qui remontent à 2001. Les commentaires écrasent la documentation principale. Les commentaires devraient être archivés ou supprimés, tout en incluant les points les plus importants dans la documentation principale.

Un wiki est également une bonne approche. Cependant, si votre wiki ne permet pas à l’utilisateur de télécharger toutes les pages en une seule grosse archive (cs. point n°3 ci-dessus), alors vos utilisateurs sont à la merci de votre connexion internet et du serveur hébergeant le projet.

11. Impossibilité de voir ce que fait le logiciel sans l’installer

Au minimum, chaque projet de logiciel nécessite une liste de fonctionnalités et une page de captures d’écran pour permettre au potentiel utilisateur intéressé de savoir pourquoi il devrait l’essayer. Aidez l’utilisateur, comparant les différents paquets à utiliser, à voir pourquoi cela vaut la peine de prendre le temps de le télécharger et de l’installer.

Les images sont un bon moyen de faire cela. Votre projet devrait avoir une page « Captures d’écran » qui montre des exemples de l’outil en action (cf. point n°5 ci-dessus). Si votre projet se résume uniquement à du code, comme une librairie, alors il devrait y avoir une page d’exemples montrant ce code utilisant le projet.

12. S’appuyer sur la technologie pour votre rédaction

Trop souvent, les auteurs de logiciels utilisent des systèmes de documentation automatisés pour faire leur travail. Ce système automatisé rend les choses plus facile à maintenir, mais il ne supprime pas la nécessité d’un travail d’écriture humain.

Le pire des cas concerne le changelog, qui n’est rien de plus qu’un dump des messages de commit du système de gestion de version, mais sans un résumé qui l’explique. Un changelog devrait lister les nouvelles fonctionnalités, les problèmes résolus et les incompatibilités potentielles. Sa cible est l’utilisateur final. Un log de commit est pratique et simple à générer pour les personnes travaillant sur le projet, mais ce n’est pas ce dont l’utilisateur a besoin.

Jetez un œil à cette page de la documentation de Solarium, une interface PHP pour le moteur de recherche Solr. Tout d’abord, l’avertisemment prend la moitié supérieure de l’écran, ne donnant aucune information au lecteur. Ensuite, il n’y a vraiment rien de véritablement descriptif sur la page que la liste des noms de fonctions. Il n’y a aucune explication sur les différentes méthodes, ni de liens indiquant où trouver l’explication. Les pages générées automatiquement sont jolies, et elles pourraient ressembler à de la documentation, mais elles n’en sont pas.

13. Arrogance et hostilité vis-à-vis de l’utilisateur

L’attitude du type RTFM (Read The Freaking Manual) est mauvaise pour votre projet et votre documentation.

C’est le summum de l’arrogance que de croire que tous les problèmes qui ont trait au fait que quelqu’un ne sache pas utiliser votre logiciel sont de la faute de l’utilisateur.

Même s’il est probablement vrai que les utilisateurs peuvent trouver leurs réponses dans votre documentation mais ne le font pas, il est stupide de penser que c’est la faute de l’utilisateur. Peut-être votre documentation est-elle mal écrite, ou difficile à lire, ou présente mal à l’écran. Peut-être avez-vous besoin d’améliorer la section « Mise en route » (lien #8 ci-dessus) qui explique ce que le logiciel a pour but de faire. Peut-être que certaines parties d’information nécessitent d’être répétées à de multiples endroits de la documentation.

N’oubliez pas que les nouveaux utilisateurs de votre logiciel peuvent arriver sur votre projet sans rien n’en savoir. Votre documentation doit faire de son mieux pour s’assurer que cette ignorance soit facilement résolue.

Synthèse

Je suis sûr que vous avez déjà eu affaire à quelques-uns de ces problèmes listés ci-dessous, et peut-être que pour d’autres vous n’y avez pas pensé. Faites-nous connaître les problèmes que vous avez rencontrés dans les commentaires ci-dessous, sachant qu’il ne s’agit pas de pointer du doigt certains projets en particulier.

Surtout, j’espère que si vous reconnaissez un problème dans la documentation de vos projets, vous prendrez la peine d’améliorer la situation. Heureusement, améliorer la documentation est une manière idéale de faire participer les nouveaux arrivants dans votre projet. On me demande souvent : « Comment puis-je commencer dans l’open source », et je recommande des améliorations dans la documentation comme une bonne manière de commencer.

Faites-en sorte que ce soit aussi facile que possible, pour les novices comme les plus anciens, de savoir où il est nécessaire de travailler la documentation. Créez une liste des tâches, par exemple dans votre système de suivi des bogues, qui explique ce qui a besoin d’être amélioré. Soyez précis dans ce que sont vos besoins. Ne vous contentez pas de dire que vous avez besoin d’exemples, sans plus de précision. Créez des tâches spécifiques, comme « ajoutez un code d’exemple sur le fonctionnement de la tâche X », « ajouter une capture d’écran du générateur de rapports » ou « ajouter des informations de dépendances au fichier README/LISEZ-MOI ». Les contributeurs souhaitent aider mais trop souvent ils ne savent pas par où commencer.

La documentation n’est pas la partie la plus glamour d’un projet open source, et pour la plupart d’entre nous ce n’est pas amusant. Mais sans une bonne documentation, les utilisateurs ne sont pas servis comme ils pourraient l’être, et votre projet en souffrira sur le long terme.

Crédit photo : Rosalux Stiftung (Creative Commons By)

À l’heure où les USA sont empêtrés dans une sombre histoire d’espionnage généralisé à grande échelle, il nous a paru intéressant de déterrer et traduire un article de Richard Stallman rédigé en 2001 juste après le 11 septembre.

Force est de reconnaître qu’une fois de plus il avait pressenti les conséquences néfastes que nous subissons aujourd’hui.

Des milliers de morts, des millions privés de libertés civiles ?

Thousands dead, millions deprived of civil liberties?

Richard Stallman – 2001 – Site personnel
(Traduction : Lamessen, Slystone, Sky, Amine Brikci-N, Asta)

Dans de nombreux cas, les dommages les plus sévères que cause une lésion nerveuse sont secondaires ; ils se produisent dans les heures qui suivent le traumatisme initial, car la réaction du corps à ces dommages tue davantage de cellules nerveuses. Les chercheurs commencent à découvrir des façons de prévenir ces lésions secondaires et réduire les dommages ultimes.

Si nous ne faisons pas attention, les attaques meurtrières sur New York et Washington vont conduire à des effets secondaires bien pire encore, si le congrès étasunien adopte des « mesures préventives » qui écartent la liberté que l’Amérique représente.

Je ne parle pas de fouilles dans les aéroports ici. Les fouilles de personnes ou de bagages, tant qu’ils ne cherchent pas autre chose que des armes et ne gardent pas de traces de ces fouilles, est juste un désagrément : elles ne mettent pas en danger vos libertés civiles. C’est la surveillance massive de tous les aspects de nos vies qui m’inquiète : de nos appels téléphoniques, nos courriels et nos déplacements physiques.

Ces mesures sont susceptibles d’être recommandées indépendamment du fait qu’elles seraient efficaces pour leur objectif déclaré. Un dirigeant d’une entreprise développant un logiciel de reconnaissance faciale est dit avoir annoncé à des journalistes que le déploiement massif de caméras embarquant un système de reconnaissance faciale aurait empêché les attaques. Le New York Times du 15 septembre cite un congressiste prônant cette « solution ». Étant donné que la reconnaissance humaine du visage effectuée par les agents d’accueil n’a pas permis de stopper les pirates, il n’y a pas de raison de penser que les caméras à reconnaissance faciale informatisée aurait été d’une quelconque aide. Mais cela n’arrête pas les agences qui ont toujours voulu mettre en place plus de surveillance de pousser ce plan aujourd’hui, ainsi que beaucoup d’autres plans similaires. Il faudra l’opposition du public pour les stopper.

Encore plus inquiétant, une proposition visant à exiger des portes dérobées gouvernementales dans les logiciels de chiffrement a déjà fait son apparition.

Pendant ce temps, le Congrès s’est empressé de voter une résolution donnant à Bush les pleins pouvoirs d’utilisation de la force militaire en représailles des attaques. Les représailles peuvent être justifiées, si les auteurs des attaques peuvent être identifiés et ciblés avec soin, mais le Congrès a le devoir d’examiner les mesures spécifiques lorsqu’elles sont proposées. Donner carte blanche au président dans un moment de colère est exactement l’erreur qui a conduit les États-Unis dans la guerre du Vietnam.

S’il vous plait, laissez vos représentants élus et votre président non élu savoir que vous ne voulez pas que vos libertés civiles deviennent les prochaines victimes du terrorisme. N’attendez pas, Les lois sont déjà en cours d’écriture.

Crédit photo : Sigg3net (Creative Commons By)

Lorsque la distribution GNU/Linux Ubuntu est sortie en 2004, son père fondateur Mark Shuttleworth a signalé lui-même le premier « bug » : Microsoft détient la majorité du marché (Microsoft has a majority market share).

Il s’agissait symboliquement, et avec humour, de montrer le cap à suivre en désignant le principal concurrent.

Aujourd’hui la donne a changé et Shuttleworth a décidé hier de marquer ce bug comme résolu (fix released), quand bien même cela ne signifie pas, loin de là, qu’Ubuntu ait gagné comme il s’en explique ci-dessous.

Remarque : Nous en profitons pour signaler que Framasoft sera présent en masse à l’Ubuntu Party de Paris, avec stand et 3 mini-conférences le samedi 1er juin.

Bug #1 : Microsoft détient la majorité du marché

Bug #1 (liberation) : Microsoft has a majority market share

Mark Shuttleworth – 30 mai 2013 – Launchpad Ubuntu
(Traduction : Penguin, Mowee, Cryptie, quack1, @zessx, Asta, misc, MFolschette, Samusz + anonymes)

Aujourd’hui, l’utilisation de l’informatique dans la vie de tous les jours est beaucoup plus importante qu’elle ne l’était en 2004 : les téléphones, tablettes et autres appareils nomades sont devenus une part non négligeable de notre vie numérique. D’un point de vue compétitif, cet édifiant marché est une bénédiction pour la concurrence. Avec notamment iOS et Android, qui tous deux représentent une part significative du marché (Voir Windows en dessous de iOS et Android réunis avec ce graphique.

Android n’est peut-être pas mon premier choix de (noyau) Linux, ni le vôtre, mais c’est sans aucun doute une plateforme open source qui offre des avantages pratiques et économiques aux utilisateurs, comme à l’industrie. Ainsi, nous avons d’un côté de la concurrence et de l’autre une bonne représentation de l‘open source dans l’informatique personnelle.

Même si nous n’avons joué qu’un petit rôle dans ce changement, je pense qu’il est important pour nous de reconnaître qu’il a eu lieu. Du point de vue d’Ubuntu, le bug est maintenant clos.

Évidemment, ce bug a aussi un aspect social. Pour beaucoup, il a fait office de déclaration d’intention. Mais il est préférable pour nous de nous concentrer sur l’excellence de notre propre travail, plutôt que considérer notre impact sur le produit des autres. Depuis les (nombreuses) années que ce bug est référencé, nous avons trouvé comment être excellents dans le cloud, et j’espère que nous trouverons aussi bientôt comment l’être sur les postes de travail des développeurs, et peut-être même sur toute la quantité d’appareils que les utilisateurs réguliers peuvent utiliser. Je préférerais désormais que nous trouvions un cri de ralliement qui célébrerait ces idées et leur management.

Il est important de remarquer que de nos jours, si vous êtes dans le domaine de l’informatique dématérialisée (NdT : cloud computing), l’équipe de service d’infrastructure (NdT : IaaS) de Microsoft est très compétente et travaille dur pour que Linux soit parfaitement supporté par Azure, ce qui rend le travail avec eux très plaisant. Si l’évolution du marché a peut-être joué un rôle dans tout ça, les circonstances ont changé et les institutions se sont adaptées. Nous nous devons donc de le faire aussi.

Cela dit, il est bon de prendre du recul et de visualiser combien tout cela a changé depuis 2004, et à quelle vitesse ! Avec Ubuntu, notre but est de proposer à tous une expérience utilisateur formidable, que ce soit pour les développeurs, pour la production en entreprise ou tout simplement l’utilisateur final. Et tout cela avec un large support de matériel. Nous évoluons dans un environnement dynamique qui ne cesse de changer d’année en année. C’est donc pour cela que nous devons sans arrêt nous remettre en question, que ce soit au niveau de notre façon de faire, nos pratiques, les outils que nous utilisons ainsi que les relations que nous entretenons en interne et en externe. Corriger ce problème n’en est qu’un tout petit exemple.

En 2008, nous présentions ici-même quelques statistiques mensuelles des cinq premiers sites du réseau Framasoft en terme de trafic. Nous avons réitéré en 2010. Les voici réactualisées en janvier/février 2013 (la même période qu’en 2010).

On constate tout d’abord l’apparition dans le top five de deux de nos services libres : Framapad et Framadate (en lieu et place de Framabook et Framagora).

Si on compare à 2010, du côté des OS, Windows baisse un peu, GNU/Linux stagne et Mac progresse. Tandis que chez les navigateurs, Firefox baisse et Internet Explorer plonge (Safari lui passe même parfois devant) au détriment de Chrome qui gagne en moyenne près de 20%.

Pour ce qui concerne le trafic global, les sites historiques Framasoft et Framakey baissent (plusieurs hypothèses, une interne : la faible mise à jour, et une externe : changement d’usages et d’intérêt), le Framablog progresse et nos services libres font d’emblée une belle percée. N’oublions pas également que le réseau Framasoft compte aujourd’hui une vingtaine de projets, ce qui était loin d’être le cas en 2010.

Statistiques Framasoft entre le 11 janvier et le 10 février 2013

• Framasoft
  • visiteurs/mois : 208 000
  • visites/mois : 256 000
  • pages vues/mois : 636 000
  • Les 3 premiers OS : Windows 77%, Linux 11%, Mac 10%
  • Les 3 premiers navigateurs : Firefox 48%, Chrome 26%, IE 16%
• Framablog
  • visiteurs/mois : 63 000
  • visites/mois : 85 000
  • pages vues/mois : 120 000
  • Les 3 premiers OS : Windows 54%, Linux 23%, Mac 13%
  • Les 3 premiers navigateurs : Firefox 49%, Chrome 27%, Safari 9%
• Framakey
  • visiteurs/mois : 33 000
  • visites/mois : 65 000
  • pages vues/mois : 210 000
  • Les 3 premiers OS : Windows 93%, Linux 4%, Mac 2%
  • Les 3 premiers navigateurs : Firefox 69%, Chrome 12%, IE 10%
• Framadate
  • visiteurs/mois : 32 000
  • visites/mois : 66 000
  • pages vues/mois : 180 000
  • Les 3 premiers OS : Windows 64%, Mac 16%, Linux 13%
  • Les 3 premiers navigateurs : Firefox 48%, Chrome 18%, IE 17%
• Framapad
  • visiteurs/mois : 28 000
  • visites/mois : 62 000
  • pages vues/mois : 159 000
  • Les 3 premiers OS : Windows 65%, Mac 16%, Linux 15%
  • Les 3 premiers navigateurs : Firefox 51%, Chrome 27%, Safari 11%

L’actualité du cinéma remet périodiquement en lumière des œuvres littéraires qui peuvent ainsi trouver un nouveau lectorat. À condition toutefois de pouvoir y accéder librement sans attendre que plusieurs générations d’éditeurs et d’ayants droits aient tiré un substantiel profit des droits qu’ils confisquent pour un temps toujours plus indéterminé.

Tel est le cas dans cet article pour le roman Gatsby le magnifique, qui aurait dû être élevé depuis quelques années dans le domaine public aux États-Unis, mais qui demeure pour longtemps encore sous copyright. Ce qui n’apportera ni profit intellectuel ni profit économique.

Rappelons que le terme de copyright est conservé dans cette traduction en raison du contexte américain, mais que cette notion n’a pas de fondement juridique en droit français, qui ne connaît que les dispositions du Code de la propriété intellectuelle.

Pourquoi Gatsby le magnifique n’est-il pas encore dans le domaine public ?

Article original de Parker Higgins sur le site de l’Electronic Frontier Foundation : Why Isn’t Gatsby in the Public Domain?

Traduction Framalang : , Michael, Garburst, Shanx, Slystone, Asta, goofy

Quand le film Gatsby le magnifique débarque dans les cinémas de tout le pays, il porte à l’écran l’histoire connue par des millions de lecteurs de ce classique de la littérature, souvent appelé proverbialement « le grand roman américain ». Voici un fait que peu de gens connaissent : même si le livre a été publié il y a maintenant presque 90 ans et fait partie de longue date de notre patrimoine culturel, il n’est pas encore entré dans le domaine public.

Oui, alors même que F. Scott Fitzgerald est mort il y a 73 ans (et donc est peu susceptible d’être sollicité pour créer davantage de chefs-d’œuvres), Gatsby le magnifique est toujours limité par le copyright.

En fait, il ne sera pas totalement libre pour le public américain avant le 1er janvier 2021 ; et encore, seulement si les durées de copyright ne sont pas encore une fois prolongées. Grâce à la loi Sonny Bono de 1998 sur l’extension du copyright, aucune œuvre publiée aux États-Unis n’entrera dans le domaine public avant 2019. Certains pays ont des lois légèrement plus saines sur le copyright, mais le représentant américain au commerce travaille ardemment à tirer profit des accords internationaux comme le TPP pour élargir le champ du copyright partout dans le monde.

Pire encore, une décision dramatique de la Cour suprême en 2012 a décidé que même une fois dans le domaine public, des œuvres peuvent en être retirées sur décision du Congrès. Entre les extensions excessives des durées de copyright et l’incertitude sur le statut du domaine public, créer de nouvelles œuvres fondées sur le domaine public est devenu difficile et risqué.

Nous ressentons concrètement les effets pernicieux des extensions du copyright tous les jours. Par exemple, une étude datant de l’année dernière sur les livres d’Amazon a révélé que les livres publiés après la date limite critique de 1923 sont bien moins disponibles que d’autres livres même plus âgés d’un siècle. Le résultat c’est que la littérature du XX^e siècle a disparu de l’histoire des livres.

Et le problème ne s’arrête pas aux livres. Une autre étude par un professeur d’économie au MIT s’est penchée sur une archive de magazines sur le baseball, qui incluait des numéros dans le domaine public, et d’autres qui sont encore assujettis au régime du copyright. Par opposition, les images des numéros dans le domaine public peuvent être numérisées et redistribuées, si bien que leur disponibilité a énormément amélioré la qualité (et donc accru la lecture et l’investissement dans l’édition) des articles de Wikipédia sur les joueurs de baseball de cette époque.

Vous pouvez vous soucier ou non de certains joueurs de baseball des années 60, mais cette situation se répète encore et encore dans différents secteurs. Au nom de la préservation des profits pour une poignée d’ayants droit, notre histoire culturelle part en miettes dans un flou artistique légal qui nous est imposé.

Un domaine public réduit à la portion congrue ne nous vole pas seulement les œuvres passées, mais aussi nos œuvres futures qui pourraient se baser sur un domaine public élargi. Les ayants droit ont le pouvoir de bloquer des œuvres dérivées simplement en refusant d’accorder la licence pour ces œuvres. Et si on ne peut pas retrouver la trace ou confirmer l’identité des ayants droit, ce qui est tout à fait possible quand on discute d’œuvres qui ont presque un siècle, la difficulté d’obtenir une licence peut stopper tout simplement la production.

Ironiquement, cela cause du tort aussi à ces mêmes studios qui ont initialement fait du lobbying en faveur de la loi pour l’extension du copyright. Adapter des œuvres célèbres est un moyen puissant d’atteindre un public déjà familiarisé avec les personnages et l’histoire ; un vaste public est le terreau fertile pour de nouvelles œuvres. Par exemple, les premiers films de Disney exploitaient librement le domaine public pour proposer des versions des contes de fées classiques, mais son lobbying pour toujours plus de restrictions sur le droit d’auteur a privé les autres (et le public) des mêmes possibilités.

Le réalisateur de Gatsby, Baz Luhrmann, a lui-même tiré avantage du domaine public avec son film « Roméo+Juliette » en 1996. Le film était, bien sûr, une version très modernisée et adaptée de la pièce classique de Shakespeare, exactement le genre de chose qu’un ayant droit pourrait interdire en raison d’une « intégrité artistique », s’il existait une entreprise commerciale « Shakespeare » aussi douée pour le lobbying que Disney ou la MPAA.

Mais le film a aussi été un succès populaire et critique, rapportant presque 150 millions de dollars de recettes au box office, et le monde du cinéma se serait appauvri sans lui. Il devrait être évident pour Hollywood que le domaine public joue un rôle important en faveur d’une culture prospère, aussi bien sur le plan artistique que sur le plan économique. Augmenter la portée du copyright peut avoir paru un bon moyen de garantir les profits annuels, mais finalement le prix à payer est fort élevé aussi bien pour Hollywood que pour l’intérêt général.

Crédit photo : Bill Mc Intyre – licence CC BY-NC-SA 2.0

Source : Journée internationale contre les DRM – édition 2013 (April)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Traduction : Framalang d’après une première traduction effectuée par Liu qihao (aka Eastwind) qui remercie François van der Mensbrugghe, Catherine Philippe et Ciarán O’Riordan.

Quelques considérations sur le rôle du juriste dans le domaine du logiciel libre et open source

Till Jaeger

Le docteur Till Jaeger est collaborateur du cabinet d’avocats JBB Rechtsanwaelte depuis 2001. Avocat diplômé et spécialisé dans le domaine du droit d’auteur et du droit des médias, il conseille autant les grandes et moyennes entreprises du secteur des technologies de l’information que les institutions gouvernementales et les développeurs de logiciels sur des sujets impliquant contrats, licences et usage en ligne. Son travail est orienté vers les contentieux relatifs aux logiciels libres et open source. Il est co-fondateur de l’institut pour l’étude juridique du logiciel libre et open source (ifrOSS). En outre, il aide développeurs et éditeurs de logiciels dans le processus de mise en compatibilité et en conformité de leurs licences libres. Till a représenté le projet gpl-violations.org dans plusieurs procès (NdT : devant les juridictions allemandes) dont l’objet portait sur le respect de la GPL. Il a également publié divers articles et livres à propos de questions juridiques sur les logiciels libres et open source. Il a été membre du comité C lors de l’élaboration de la GPLv3.

Pour commencer, clarifions une chose : je ne suis pas un geek. Je ne l’ai jamais été, et je n’ai aucune intention de le devenir. En revanche, je suis juriste. La plupart des lecteurs de ce livre auront probablement tendance à éprouver une plus grande sympathie à l’égard des geeks qu’envers les juristes. Cependant, je ne souhaite pas éluder ce fait : la communauté du logiciel libre et open source n’est pas nécessairement passionnée par les juristes, elle est trop occupée à développer du code. Cela, je le savais déjà au début de l’année 1999, lorsque nos chemins se sont croisés pour la première fois. Néanmoins, d’autres éléments m’étaient, à ce moment-là, encore inconnus. En 1999, tandis que je terminais ma thèse de doctorat portant sur le droit d’auteur classique, j’évaluais l’étendue des droits moraux. Dans ce contexte, j’ai passé un certain temps à réfléchir à la question suivante : comment les droits moraux des développeurs sont-ils protégés par la licence GPL, étant donné que celle-ci confère aux utilisateurs un droit de modification sur leurs logiciels ? C’est ainsi que je suis entré pour la première fois en contact avec le logiciel libre et open source.

À cette époque, les qualificatifs « libre » et « ouvert » avaient évidemment des significations différentes. Mais dans le monde dans lequel je vivais, cette distinction ne méritait pas d’être débattue. Cependant, vu que j’étais libre d’étudier ce qui m’intéressait et ouvert à l’exploration de nouvelles questions sur le droit d’auteur, j’ai rapidement découvert que les deux termes ont quelque chose en commun : bien qu’ils soient effectivement différents, ils sont bien mieux utilisés lorsqu’ils sont ensemble…

Voici trois choses que j’aurais souhaité savoir à l’époque :

Tout d’abord, que mes connaissances techniques, en particulier dans le domaine du logiciel, étaient insuffisantes. Ensuite, que je ne comprenais pas véritablement la communauté et que j’ignorais ce qui importait aux yeux de ses membres. Et cerise sur le gâteau, que je ne connaissais pas grand-chose aux juridictions étrangères, à l’époque. Ces notions m’auraient été précieuses si j’avais pu les aborder dès le départ.

Depuis, j’ai appris suffisamment et, à l’instar de la communauté qui se réjouit de partager ses réalisations, je suis heureux de partager mes leçons (1).

Connaissances techniques

Comment est formée une architecture logicielle ? À quoi ressemble la structure technique d’un logiciel ? Quelles sont les licences compatibles ou incompatibles entre elles ? Comment et pourquoi ? Quelle est la structure du noyau Linux ? Pour citer un exemple, la question essentielle des éléments constitutifs d’une « œuvre dérivée » selon la GPL détermine la manière dont le logiciel pourra être licencié. Tout élément rentrant dans le champ d’une œuvre dérivée d’un logiciel originaire sous licence GPL doit être redistribué selon les termes de cette dernière. Pour évaluer si un programme constitue une « œuvre dérivée » ou pas, il est nécessaire d’avoir au préalable une compréhension technique approfondie. Ainsi, l’interaction des modules de programmes, des liaisons, des IPC (Communications inter-processus), des greffons, des infrastructures technologiques, des fichiers d’en-tête, etc. détermine au niveau formel (parmi d’autres critères) le degré de connexité d’un logiciel par rapport à un autre, ce qui aide à le qualifier ou non d’œuvre dérivée.

Connaissance de l’industrie et de la communauté

Au-delà de ces questions fonctionnelles, l’étendue de mes connaissances des principes régissant le libre était limitée, tant au regard de la motivation des développeurs que des entreprises utilisant du logiciel libre. En outre, je ne connaissais pas son arrière-plan philosophique, et n’étais pas plus familier avec les modalités pratiques d’interactions sociologiques de la communauté. Ainsi, les questions : « Qui est mainteneur ? » ou « Quel est le fonctionnement d’un système de contrôle de version ? » ne trouvaient pas d’écho à mes oreilles. Or, pour servir du mieux possible vos clients, ces questions sont toutes aussi importantes que la maitrise des aspects d’ordre purement technique. Par exemple, nos clients nous demandent de nous occuper du côté juridique des modèles économiques construits sur une double licence de type « open core ». Ceci inclut la gestion des contrats de supports, de services, de développements ainsi que les conventions applicables aux codes sources venant des contributions. Ce faisant, nous guidons entreprises et institutions dans la grande réserve du logiciel libre lors de la mise en place de ces modèles.

D’autre part, nous conseillons aussi les développeurs sur la manière de régler les litiges nés des violations de leur droit d’auteur, notamment via l’élaboration et la négociation de contrats en leur nom et pour leur compte. Ceci étant, pour répondre à tous ces besoins de manière complète, il est fondamental de s’être familiarisé avec cette multiplicité de points de vue.

Connaissances en droit comparé

La troisième chose dont un juriste libriste a besoin, c’est de connaissances à propos des juridictions étrangères, au moins quelques-unes et, plus il en acquiert, mieux il se porte. Pour pouvoir interpréter les différentes licences correctement, il est essentiel de comprendre l’état d’esprit dans lequel s’inscrivaient les personnes qui les ont écrites.

Dans la plupart des cas, le système juridique américain est d’une importance capitale. Par exemple, lors de l’élaboration de la GPL, celle-ci a été écrite avec, à l’esprit, des notions issues de la common law étasunienne. Aux États-Unis le terme « distribution » inclut la distribution en ligne. Or, le système de droit d’auteur allemand établit un distinguo entre la distribution en ligne et hors-ligne. Dès lors,  les licences qui ont été rédigées par des juristes de la common law étasunienne peuvent être interprétées comme incluant la
distribution en ligne. Au cours d’un procès, cet argument peut devenir particulièrement pertinent (2).

Un apprentissage permanent

Au final, toutes ces connaissances sont d’une grande utilité. Aussi, j’espère qu’à l’image du processus d’évolution d’un logiciel, qui apporte son lot de solutions aux besoins de tous les jours, mon esprit continuera à répondre aux défis que la vibrante communauté du logiciel libre et open source pose constamment à l’attention d’un juriste.

(1) L‘Institut für Rechtsfragen der Freien und Open Source Software (institut des questions de droit sur les logiciels libres et open source) propose, entre autres, une collection d’ouvrages et de jurisprudences en lien avec les logiciels libres et open source ; pour plus de détails, voir sur le site http://www.ifross.org/.

(2) Voir : http://www.ifross.org/Fremdartikel/LGMuenchenUrteil.pdf, Cf. Welte v.Skype, 2007