Paint.NET^[1] est un très bon logiciel libre de retouches d’images pour Windows. De l’avis de beaucoup, bien plus « sexy » et accessible au grand public que Gimp par exemple.

Sauf qu’il possède deux défauts, un petit et un bien plus grand, éliminatoire même. Il nécessite, comme son nom l’indique, l’implémentation préalable du framework .NET de Microsoft, mais surtout il a très vite été un logiciel libre contesté qui n’avait en fait de logiciel libre que le nom, ou plutôt « que » la licence (en l’occurrence la licence MIT).

Contrôle du code, communauté inexistante et absence des dernières version des sources à télécharger, faisaient en effet de ce logiciel un exemple emblématique de « fauxpen source ». De l’aveu même de Rick Brewster, son unique développeur : « le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non sollicitées ». Il appelle d’ailleurs cela un logiciel « released sources ».

Aujourd’hui les choses sont clarifiées. Rick Brewster a décidé il y a un mois de changer la licence pour en faire un vrai logiciel propriétaire gratuit (ou freeware). « You may not modify, adapt, rent, lease, loan, sell, or create derivative works based upon the Software or any part thereof », peut-on lire sur l’article de son blog qui annonce la nouvelle.

Cette nouvelle n’est pas forcément bonne (un logiciel qui quitte la lumière pour rejoindre le côté obscur de la force) mais elle est logique et cohérente vue l’évolution de l’application. Il nous a cependant semblé intéressant de traduire cet article, d’abord pour mieux comprendre les motivations de cette migration à contre-courant, mais aussi parce que les arguments avancés sont autant de justifications plus ou moins convaincantes qui vous feront peut-être réagir dans les commentaires.

Une nouvelle licence pour Paint.NET 3.5

A new license for Paint.NET v3.5

Rick Brewster – 9 novembre 2009 – Blog personnel
(Traduction Framalang : Jimbo)

Au fil des années, j’ai été obligé de me battre avec un certain nombre de personnes, et de sociétés, qui tentaient de plagier Paint.NET en recompilant le programme sous une dénomination commerciale différente et en insérant leur propre nom dans les crédits. Parfois, ils se faisaient payer pour ce service. J’ai même créé mon propre terme pour désigner cela : un « backspaceware » (NdT : en français cela donnerait quelque-chose comme « effaciciel », le backspace étant la touche « retour en arrière », qui permet d’effacer le dernier caractère tapé). En outre, de temps en temps, on trouve Paint.NET en vente sur eBay.

Et, comme beaucoup d’entre vous le savent, Paint.NET était open source. Ou plutôt, il était « released sources » (NdT : C’est-à-dire « sources publiées ») : le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non-sollicitées. J’aimais publier le code source, parce qu’il me semblait bon de permettre à d’autres de l’étudier. Il y a environ un an, fatigué de voir ces versions plagiées de Paint.NET et j’ai décidé de retirer le code source du site Web. Cependant le code source était toujours dans la nature en différents endroits d’Internet (ce qui n’est guère illégal). Même sans le code source, une personne maline et douée pouvait probablement encore décompiler, modifier puis recompiler le programme, afin de lui faire dire ou faire ce qu’elle voulait.

Le plus gros problème était que, même si ces actions déplorables manquaient clairement d’éthique, le licence MIT autorisait tout cela. Ou, du moins, dans certains cas particuliers, ce qu’elle interdisait n’était pas clair. Donc, d’un point de vue juridique, ce qui pouvait précisément être entrepris à ce sujet n’était pas clair. Je ne suis pas juriste et je ne voulais pas dépenser des milliers de dollars pour avoir une explication de tout cela. Quelques personnes ont affirmé que j’avais choisi la mauvaise licence et, avec le recul, c’est sans aucun doute exact.

En outre, tout ceci va plus loin que le plagiat ou ma propre tension artérielle. La publication de copie dérivées de Paint.NET est source de confusion et perturbe la plupart des utilisateurs. J’ai reçu des e-mail de personnes troublées parce qu’elles pensaient que Paint.NET avait été renommé et que des fonctions manquaient dans « la nouvelle version ». Ces copies dérivées provoquent du désordre puisque souvent elles désinstallent le vrai Paint.NET (avec la même interface graphique que pour l’installation Windows) tout en conservant le système de mise à jour d’origine. Ce qui signifie que lorsque vous installez une telle copie dérivée, elle supprime Paint.NET, et puis lorsque Paint.NET est mis à jour, il désinstalle la version dérivée et la remplace par Paint.NET, etc… Ou la version modifiée plante, et le rapport de bugs indique à l’utilisateur de l’envoyer à mon adresse mail. Il y a aussi a risque réel de trojans et de virus.

Tout est désormais fini.

Pour la version finale de Paint.NET 3.5, qui ne devrait plus tarder, j’ai modifié la licence. Pour la plupart des utilisateurs, cela n’aura aucun impact. C’est toujours un freeware. Il n’y a toujours aucune prétention sur les fichiers créés, ouverts ou sauvés avec Paint.NET. Vous pouvez toujours établir un miroir du fichier zippé à télécharger sur votre site web (par exemple Betanews, Download.com, etc.) sans en demander la permission. Vous pouvez toujours vendre des trucs que vous créez avec Paint.NET (pour autant que vous ayez le droit de le faire bien sûr). Vous pouvez continuer à utiliser dans un contexte commercial, et à l’installer sur autant de machines que vous le désirez.

Cependant, la licence spécifie que vous ne pouvez plus modifier Paint.NET lui-même, ou créer une œuvre dérivée basée sur le logiciel Paint.NET (c’est-à-dire un logiciel dérivé). Vous ne pouvez pas non plus le vendre. Je ne pense pas que cela aura un impact sur quiconque d’autre que ceux qui désirent plagier ou détrousser Paint.NET. Je ne vais implémenter aucune restriction quant au reverse engineering ou la décompilation, par exemple à l’aide de Reflector. Je pense que ce serait bête, et je crois encore de tout mon cœur qu’il est bon qu’on soit capable d’étudier le code de Paint.NET, quand bien même il ne s’agit que du démontage approximatif fourni par Reflector. Toutefois, vous n’êtes pas autorisé à modifier et recompiler une nouvelle version de Paint.NET à partir de ce démontage.

Cette décision créera à n’en pas douter de la confusion. Par exemple, « Est-ce que les plugins sont autorisés ? ». Oui, absolument: le programme est conçu pour accepter ces dernier et ils ne constituent pas une modification de Paint.NET lui-même. Je devrai certainement mettre la FAQ à jour sur cette question, comme sur d’autres.

Je m’attends à ce qu’il y ait une minorité bien en voix qui condamne ce changement de licence. Avant de vous exprimer, veuillez vous poser cette question : cela vous touche-t-il réellement ? Comptiez vous vraiment faire quelque chose que cette nouvelle licence interdit ? Je parie que la réponse est « non », mais, je vous en prie, postez un commentaire si la réponse est un véritable oui. Beaucoup de personnes ont condamné ma décision de supprimer le code source mais après enquête, il s’est avéré que c’était une pure question de principe : elles n’avaient jamais téléchargé le code source, jamais rencontré quelqu’un qui l’avait téléchargé, et jamais prévu de faire quoi que ce soit qui tirerait profit ou dépendrait de l’accès au code source. Je comparerai cela à être contrarié par le fait que votre passeport vous interdit de voyager en Antarctique : comptiez-vous vraiment vous rendre là-bas un jour ?^[2]

L’autre décision que je compte prendre est de publier le code source de portions de Paint.NET 3.5, probablement sous une licence de type MIT ou BSD. Les développeurs de plugins gagneraient en effet beaucoup à disposer du code source des effets graphiques et de certaines commandes relatives à l’interface WinForms. La meilleure façon de résumer les choses est de dire que la nouvelle licence (NdT : Voir les termes de la nouvelle licence sur l’article d’origine) couvre les « binaires », c’est-à-dire « ce que vous venez de télécharger et d’installer ». Je peux toujours créer des paquets à télécharger qui sont couverts par d’autres termes de licence. D’un point de vue de la philosophie, c’est peut-être déroutant, mais je suis prêt à en payer le prix.

C’est bientôt la Noël et ses rituels spirituels et consuméristes. Et comme chaque année, la question existentielle suivante : Mais que vais-je donc bien pouvoir offrir à Tata Jeanine ?

Et que se passe-t-il si vous êtes à court d’idées, de temps et d’imagination ? Vous allez immanquablement penser à… un agenda (il ne reste plus que cette option puisque Tata Jeanine n’aime pas le chocolat).

Or cela tombe bien puisque c’est exactement le cadeau que nous allons nous aussi vous suggérer ! Sauf que cet agenda-là possède selon nous un petit supplément d’âme puisqu’il est proposé par Wikimédia France en partenariat avec l’éditeur InLibroVeritas (sous double licence libre Creative Commons By-Sa et Art Libre).

Donc, chère Tata, tu auras l’impression qu’une fois de plus je ne me suis pas foulé, mais détrompe-toi car tu tiendras entre les mains bien plus qu’un simple calendrier illustré et légendé, aussi beau soit-il (ce qui est d’ailleurs le cas). Tu tiendras entre les mains une infime mais lumineuse parcelle de ce libre accès à la connaissance souhaité et rendu possible par les projets Wikimedia (l’occasion du reste de nous rendre compte ensemble que Wikimedia ne se résume pas à l’encyclopédie Wikipédia).

L’agenda 2010 Wikimédia se présente au format A4 sous un format hebdomadaire (une page par semaine avec notation de rendez-vous sur la page de droite, une photo dûment sélectionnée sur la page de gauche). Vous pouvez le consulter en ligne et bien entendu l’acheter chez InLibroVeritas au prix de 25€.

Vous trouverez ci-dessous copie de la préface rédigée par Adrienne Alix, la présidente de l’association Wikimédia France qui, dernier argument, touchera l’intégralité des bénéfices de la vente.

PS : On peut voir l’intégralité des photos de l’agenda (et même un peu plus) sur cette page de l’espace personnel d’Adrienne sur Wikimedia Commons^[1].

Préface

« Wikipédia » : pour vous ce mot évoque internet, culture, diffusion du savoir. Saviez-vous qu’à côté de Wikipédia se développent des projets liés, complémentaires et dynamiques ?

Ce que Wikipédia est à la connaissance encyclopédique, Wikimedia Commons l’est aux contenus multimédias, Wikisource aux textes anciens, Wikiquote aux citations : des projets de diffusion libre et massive de connaissances.

Tous ces projets, et d’autres encore, font partie du mouvement Wikimédia. Ils sont hébergés par la Wikimedia Foundation, une association à but non lucratif. Ils fonctionnent, comme Wikipédia, sur un mode collaboratif : chaque internaute est invité à apporter selon ses capacités sa pierre à la diffusion du savoir.

Aujourd’hui, l’association Wikimédia France, association pour le libre partage de la connaissance, a voulu mettre en valeur le fabuleux contenu de ces projets. Et comment mieux valoriser ces projets qu’en montrant leurs contenus ? C’est la raison d’être de cet agenda.

Nous voulons vous montrer, grâce à un bel objet qui vous accompagnera toute l’année, la richesse culturelle des projets Wikimédia.

En illustrant cet agenda avec des photos tirées de Wikimedia Commons, vous découvrirez que cette médiathèque libre, contenant plus de 5 millions de fichiers rassemble des photos de monuments, d’animaux, de splendeurs de la nature ; mais aussi des cartes, des gravures, des tableaux. Sans compter les documents diffusés sous licences libres par de grandes institutions : NASA, Archives fédérales allemandes, qui ont choisi de libérer leurs contenus.

Les photos que nous avons choisies pour cet agenda ont pour objectif de montrer la richesse de Wikimedia Commons et de vous inciter à la fois à vous servir de cette base incroyablement riche pour vos besoins personnels ou professionnels (exposés, présentations, livres, journalisme etc.) ; mais aussi à contribuer à son enrichissement : vous aussi, vous pouvez choisir de placer vos photos sous licence libre et de les offrir à la diffusion sur Wikimedia Commons.

Pour accompagner ces belles photos, nous avons choisi quelques mots. Parfois un extrait d’article de Wikipédia, qui vous incitera à aller en savoir plus sur l’encyclopédie ; ou un extrait de texte tiré d’un livre de Wikisource, la bibliothèque numérique de textes libres de droits ; voire une citation extraite de Wikiquote, projet dédié à la collecte de citations.

Par l’achat de cet agenda, vous soutiendrez concrêtement et financièrement ces projets pour qu’ils continuent à vivre et à nourrir notre vie culturelle. Les projets Wikimédia ne vivent que par les dons de ceux qui les soutiennent. Merci de tout cœur.

Nous vous souhaitons de passer une belle année 2010 avec les projets Wikimédia. Notre ambition est de vous faire découvrir leurs richesses, et pourquoi pas de vous inciter à y participer.

Adrienne Charmet-Alix
Présidente de Wikimédia France – association pour le libre partage de la connaissance

Vous trouverez à la fin de l’agenda une présentation plus complète des projets ainsi que les adresses internet des sites et des contenus utilisés pour la réalisation de cet agenda.

Commander l’agenda 2010 Wikimédia

Voici un article de Bastien Sibille susceptible de ne pas laisser notre lectorat indifférent.

Voir en effet le logiciel libre comme « un rempart contre la tentation hégémonique du capitalisme », et qui devrait donc par là-même s’allier à l’économie sociale afin de ne pas perdre « son potentiel émancipateur » et participer de concert à « la reconquête des biens communs », est un point de vue dont l’adhésion est certaine mais pas forcément totale.

L’occasion d’en débattre donc ensemble après lecture^[1].

Bastien Sibille est coordonateur de l’Association Internationale du Logiciel Libre (Ai2L) pour l’Économie Sociale. Un article qui fait écho à Sébastien Broca : Du logiciel libre aux théories de l’intelligence collective et qui revisite une nouvelle fois la différence d’approche entre « logiciel libre » et « open source ».

Économie Sociale – Logiciels Libres, le temps de l’alliance

URL d’origine du document

Bastien Sibille – novembre 2009 – version 2.0
Licence Creative Commons By-Nd

Deux mondes co-existent qui dressent des remparts contre la tentation hégémonique du capitalisme : l’un est ancien et puise ses racines dans le XIXe siècle industriel – le monde de l’économie sociale (coopératives, mutuelles, associations…) ; l’autre est plus jeune et tisse ses réseaux dans le XXIe siècle informatique – le monde du logiciel libre. Si les communautés du libre et les entreprises d’économie sociale se connaissent et se côtoient depuis plus d’une décennie, elles ne voient pas souvent combien leurs luttes sont proches. Le temps est venu de dire la proximité de ces luttes et l’urgence de leur alliance.

Raisons de l’alliance

Depuis une vingtaine d’années des communautés d’informaticiens, puis des entreprises informatiques, ont développé ce qu’on appelle des « logiciels libres ». Les logiciels libres sont des logiciels que l’on peut librement exécuter, étudier, modifier et diffuser autour de soi. Ils s’opposent aux logiciels propriétaires dans la mesure où leur code est « ouvert » alors que celui des logiciels propriétaire est « fermé ». L’ouverture est à la fois technique et juridique. Sur le plan technique, le code source des logiciels libres est « lisible » par des êtres humains alors que celui des logiciels propriétaires est distribué en langage machine, ce qui le rend illisible même par les informaticiens. Sur le plan juridique, les logiciels libres sont protégés par des « licences libres » qui assurent qu’ils ne pourront jamais être privatisés et resteront un bien commun.

Les principes qui encadrent la production, la distribution et l’usage des logiciels libres présentent d’importantes synergies avec les principes de l’économie sociale. Il faut tout d’abord relever une synergie dans le rapport à l’accumulation du capital entre les entreprises d’économie sociale et les communautés du libre. Un logiciel, parce qu’il est l’accumulation du travail des femmes et des hommes qui l’ont modelé, est un capital – un capital immatériel. Les licences propriétaires organisent la rémunération de ce capital immatériel: chaque fois qu’il est dupliqué et vendu, il génère un gain sans qu’un travail supplémentaire n’ait été fourni. Dans le cas des logiciels libres, point de rémunération du capital : seul le travail paie. Voilà un premier trait qui place les logiciels libres tout proche des luttes historiques de l’économie sociale.

Ensuite, les modes de production du libre respectent au moins trois autres piliers fondamentaux des entreprises d’économie sociale.

• La liberté d’entrée et de sortie : un homme entre librement dans une association, et en sort tout aussi librement. Cette liberté est très présente dans la philosophie et la pratique des logiciels libres : tout utilisateur qui le souhaite peut entrer dans le code, l’utiliser, et en sortir librement.
• Le principe démocratique : un homme = une voix. Cette liberté fondamentale du fonctionnement des associations est à l’œuvre dans les logiciels libres : tout utilisateur du code peut prendre part à la création ou à la modification du code. Les communautés d’usagers des logiciels libres prennent ainsi part à leur amélioration en indiquant aux développeurs les bugs qu’ils ont repérés. Nous sommes ici à l’opposé des modes de production des logiciels propriétaires, dans lesquels quelques informaticiens décident pour tous du fonctionnement du logiciel.
• L’impartageabilité des réserves pour finir. Lorsqu’un ensemble de femmes et d’hommes créent une richesse logicielle, lorsqu’ils écrivent ensemble le code informatique puis décident de le protéger par une licence libre, ils s’assurent que la richesse produite ne pourra être privatisée : le code restera ouvert à tous. Personne ne pourra se l’approprier. La richesse immatérielle placée sous licence libre ne peut que rester commune.

Urgence de l’alliance

L’alliance des entreprises d’économie sociale et des communautés du libre est une nécessité stratégique. L’intensification de l’usage, depuis les années 1980, de la micro-informatique – traitements de textes, tableurs, agendas – et, depuis le milieu des années 1990, des réseaux informatiques – courriels, sites internet, intranet, prestation de services et paiements en ligne – ont conduit les entreprises d’économie sociale à dépendre de plus en plus fortement des logiciels informatiques. Aujourd’hui, ces logiciels sont majoritairement produits par des entreprises capitalistes. Ces entreprises organisent la rémunération de leurs investissements en « fermant » le code des logiciels, de manière à ce que (1) ceux qui veulent s’en servir soient obligés de les acheter, et (2) ceux qui veulent lire les fichiers créés par ces logiciels soient obligés d’acquérir les logiciels.

Les logiciels propriétaires sont des chevaux de Troie de l’économie capitaliste placés au cœur des entreprises d’économie sociale. Leur utilisation par les entreprises d’économie sociale est extrêmement préoccupante. D’abord parce qu’elle signifie que les structures d’économie sociale reposent, pour une très large partie de leurs activités, sur des outils informatiques qui, de par leur mode de production et leur architecture, ne correspondent pas à leur valeurs. Ensuite parce qu’il rend les structures d’économie sociale dépendantes d’entreprises capitalistes. Au-delà de l’incohérence de valeurs, cette dépendance est inquiétante. Elle signifie, par exemple, que toute la mémoire informatique (l’ensemble des fichiers textes, des images, des tableurs) des entreprises d’économie sociale dépend, pour son utilisation future, de la survie ou du bon vouloir des entreprises capitalistes qui produisent les logiciels.

Aujourd’hui, l’indépendance des structures d’économie sociale vis-à-vis des éditeurs capitalistes du code informatique est possible. Les logiciels libres offrent aux structures d’économie sociale une alternative puissante.

• Elle est puissante d’abord parce que le code libre est un code pérenne: il pourra toujours être repris, retravaillé, remodelé pour coller au mieux aux besoins des structures qui le déploient.
• Elle est puissante aussi parce que le code libre est un code solide: dans la mesure où il est ouvert, tous les acteurs compétents de la communauté du libre participent à son amélioration. C’est l’assurance que ses faiblesses sont vite repérées et corrigées.
• Elle est puissante ensuite parce que le code libre est un code solidaire : les logiciels développés par certaines structures d’économie sociale pourront bénéficier à d’autres. En ayant la possibilité de librement distribuer les logiciels qu’elle utilise, une structure d’économie sociale facilite ses communications électroniques avec des structures partenaires et notamment avec des partenaires qui n’auraient pas eu les moyens d’acheter les logiciels.
• Elle est puissante enfin parce qu’elle permet aux structures d’économie sociale d’utiliser, dans leurs actions quotidiennes, des outils informatiques qui sont cohérents avec les valeurs pour lesquelles elles se battent. De la même façon que les entreprises d’économie sociale se sont dotées d’instruments financiers et juridiques spécifiques, il est urgent qu’elles se dotent d’instruments informatiques qui respectent leurs principes.

Une alliance est nécessairement un mouvement à au moins deux sens. Les raisons qui encouragent les communautés du libre à s’allier à l’économie sociale ne sont pas moins fortes que celles qui poussent les structures d’économie sociale à adopter les logiciels libres.

Équiper les entreprises d’économie sociale en logiciels libres, c’est équiper des entreprises dont les modes de fonctionnement et de travail sont proches des modes de production des logiciels libres : la coopération, le travail en réseau, le bénévolat sont des éléments particulièrement présents dans le quotidiens des structures d’économie sociale. Les logiciels libres y sont donc soumis à un usage intensif par des utilisateurs plus promptes que d’autres à signaler les bugs aux communautés et à leur faire bénéficier des amélioration des logiciels. Il y a fort à parier que la qualité des logiciels libres augmentera substantiellement s’ils sont largement utilisés par les structures d’économie sociale. D’autre part, la force de frappe informatique des entreprises d’économie sociale est considérable. De nombreuses entreprises d’économie sociale mobilisent des services informatiques importants tant par le nombre d’informaticiens qui y travaillent que par les développements qu’ils ont produits. En s’alliant à l’économie sociale, les communautés du libre pourront compter sur la puissance de feu informatique de celle-ci.

Les logiciels libres et l’économie sociale sont des mouvements d’émancipation. En s’alliant à l’économie sociale, le mouvement du libre rejoint une force de progrès et de justice susceptible de le porter vers de nouveaux horizons ; il rejoint une lutte historique ancienne, profondément enracinée dans nos sociétés, capable de mobiliser des réseaux étendus et variés. Autrement dit, en s’alliant à l’économie sociale, le mouvement du libre intègre un mouvement plus vaste que lui sur lequel il pourra s’appuyer pour continuer à construire sa légitimité.

Ce n’est pas tout. Les communautés du libre sont aujourd’hui à un tournant : la qualité de leur production logicielle les conduit à être de plus en plus au cœur des stratégies de très grandes entreprises informatiques. Le libre d’hier n’est plus le libre d’aujourd’hui, et l’esprit de ses pionniers pourrait bientôt n’y plus rayonner que marginalement. Les enjeux capitalistes commencent à imprimer sensiblement leur marque sur les projets de logiciels libres : le risque est que la réussite du libre ne dissolve son potentiel émancipateur. Ici, l’alliance des communautés du libre avec les structures d’économie sociale prend toute sa dimension – elle assure que le succès du libre ne se fera pas au détriment de son sens politique profond.

Enjeux de l’alliance

Il faut enfin dire qu’une prise de position forte en faveur des licences libres marque, pour les alliés, un engagement dans un débat beaucoup plus large. Dans un monde où les modes de productions sont de plus en plus tournés vers les biens immatériels, les enjeux socio-politiques liés à la propriété intellectuelle deviennent cruciaux et ne s’arrêtent pas aux seuls logiciels. Le brevetage des génomes des plantes et des animaux, des molécules actives des médicaments ou l’augmentation de la durée du droit d’auteur applicable aux œuvres d’art sont des exemples de la violence des mécanismes actuels de privatisation de l’immatériel. La propriété intellectuelle est ainsi au cœur des luttes présentes et futures dans des champs aussi variés que l’agriculture, la santé ou l’art.

En prenant une position claire en faveur des logiciels libres, des licences libres et des modes de production et de diffusion des produits de l’esprit qu’elles organisent, les communautés du libre et les entreprises d’économie sociale s’engagent dans un combat plus vaste que le seul domaine informatique : celui de la reconquête des biens communs. Ce combat est crucial pour l’avenir nos sociétés.

En programmation, les commentaires sont des portions du code source ignorées par le compilateur ou l’interpréteur, car ils ne sont pas nécessaires à l’exécution du programme, nous dit Wikipédia.

De fait ils sont le plus souvent utilisés pour expliquer le code, et contrairement à ce dernier qui nécessite un langage de programmation, les commentaires se font dans une langue humaine, généralement en anglais.

C’est une opération indispensable et une partie intégrante du travail du développeur, afin qu’un autre puisse comprendre et éventuellement modifier le code initial (quitte à ce que cet autre soit l’auteur même des commentaires, reprenant son code quelques temps plus tard).

De par le fait que sa nature en autorise l’accès et le ré-appropriation, on comprendra que ces commentaires soient encore plus importants dans le cas d’un logiciel libre.

Il se trouve cependant que, par paresse, manque de temps ou mépris pour ce qui ne serait pas de la programmation stricto sensu, ils sont parfois quelque peu négligés par les développeurs.

Or l’hypothèse défendue ici est qu’il y aurait une corrélation directe en la qualité des commentaires et la qualité du code.

Affirmer ainsi péremptoirement que l’un n’irait pas sans l’autre est somme toute assez osé. Mais cela a le mérite d’évoquer cette « face cachée » de la programmation qui fait aussi partie des compétences attendues d’un bon développeur^[1].

Si les commentaires sont moches, le code est moche

If the comments are ugly, the code is ugly

Esther Schindler – 15 novembre 2009 – IT World
(Traduction Framalang : Goofy)

C’est un peu dur, je sais, mais finalement je crois que c’est vrai.

Le développeur de Plone Martin Aspeli m’a signalé un billet assez judicieux dans lequel un programmeur en C faisait part de trois règles apprises à ses dépens. Celle qui a particulièrement attiré l’attention de Martin (et la mienne) est la suivante :

Les bons programmes ne comportent aucune faute d’orthographe ni de faute de grammaire. Je pense que cela vient probablement d’une attention soutenue aux moindres détails ; dans les programmes excellents tout est correct à tous les niveaux, jusqu’aux points qui terminent les phrases de commentaires.

« Allez, tu charries ou quoi ? ». Vous pourriez croire que pinailler à ce point est indigne de vous, « Et bien je m’en vais commencer à vous signaler les erreurs dans votre code lui-même ». J’ai été bien embarrassé les deux ou trois fois où ça m’est arrivé.

La programmation, que vous la pratiquiez en enthousiaste de l’open source ou parce que vous êtes au service du patron, est un exercice qui exige de l’attention aux détails. Quiconque écrit un logiciel doit être pointilleux, sinon le code ne fonctionnera pas. Je suis sûre que je n’ai pas besoin de vous citer la série des célèbres bogues de programmation dont s’est rendu coupable un programmeur qui a utilisé une virgule et non un point, ou des plantages aléatoires provoqués par deux lignes de code placées au mauvais endroit ?

Il est possible que mon jugement soit faussé par mes fonctions d’écrivain et d’éditrice, mais je crois fermement que si vous ne pouvez pas trouver le temps d’apprendre les règles de syntaxe de la langue (y compris la différence entre « c’est » et « ces », ou encore « m’a » et « ma »), je ne crois pas que vous puissiez être beaucoup plus consciencieux pour écrire du code en respectant les bonnes pratiques. Si vos commentaires sont négligés, je m’attends à trouver du code négligé.

Mon postulat vient de ce que m’a enseigné un éditeur très brillant, il y a dix ans (Laton McCartney, si tu lis ça : merci !). Si tu peux écrire le chapeau, disait-il, tu peux écrire l’article très facilement. Si tu ne peux pas écrire le chapeau, c’est que tu ne comprends pas encore ce que tu veux dire, et tu ne devrais pas commencer à écrire (le « chapeau » est le petit paragraphe d’accroche qui suit le grand titre, qui dit en un mot de quoi il est question et invite gentiment le lecteur à en savoir plus). De filandreuses « explications » du code dans les commentaires de l’application (c’est-à dire, ceux qui se lisent comme de bonnes excuses) indiquent que le développeur ne savait probablement pas ce qu’il faisait au juste. Ce qui signifie que son code est éligible au titre de nid à bugs.

Se plaindre de la mauvaise documentation interne est un vieux refrain, mais il existe une raison pour laquelle il est important de la faire bien. Vos commentaires sont la seule façon dont vous disposez pour communiquer avec la prochaine personne qui regardera votre logiciel (il se peut même que ce soit vous) en profondeur, et pas juste une ligne ou deux. À quoi pensiez-vous en écrivant ce code ? D’accord, du code « auto-documenté » c’est l’idéal, mais c’est un peu arrogant de prétendre que vous l’avez atteint, et ça l’est tout autant de ma part si je prétends que mes phrases n’ont pas besoin d’être révisées (elles en ont besoin, je suis bien contente d’avoir un correcteur).

Un autre problème habituel dans la médiocrité des commentaires apparaît lorsque les développeurs mettent à jour le code sans mettre à jour les commentaires ; comme l’a expliqué un consultant, les commentaires ne sont pas testés. Mais est-ce qu’il ne s’agit pas là encore d’un manque d’attention aux détails ? À chaque fois que vous n’êtes pas totalement attentif, vous êtes prédisposé à laisser tomber un petit bout de logique.

Vous voulez quelques exemples ?

En voici un tiré d’une explication à propos d’un choix de conception. (« oui, je devine que c’était probablement intentionnel », a écrit le programmeur qui m’a montré cet exemple. « mais c’est bien là le problème : il faut que je devine ».)

 «... des questions prévues pour injustifier un débat...» 

Voici maintenant une authentique ligne de code avec un commentaire. Notez que le commentaire met l’accent sur la faute d’orthographe. Sans compter que le commentaire vous indique que le programmeur n’avait pas la moindre idée de ce qu’il faisait au départ. Particulièrement parce qu’il n’aurait pas dû écrire « finished » (NdT : fini) dans ce bout de code, mais qu’il aurait dû essayer « complete » (NdT : terminé).

 if item.getState() == 'finsihed': #est-ce correct? 

Bon, je vous accorde quelques exceptions. Si l’anglais n’est pas votre langue maternelle, il est possible que les commentaires que vous laissez dans votre code montrent que vous n’êtes pas à l’aise pour écrire en anglais. Cependant, en ce qui me concerne je n’ai pas trouvé que c’était le cas. Comme beaucoup d’Américains s’en sont rendu compte, les capacités en anglais des « étrangers » sont généralement bien meilleures que les nôtres. Parmi les développeurs que je connais, ceux qui ont des lacunes dans leur maîtrise de la langue anglaise en sont conscients et font tout leur possible pour qu’un anglophone passe en revue leur documentation.

Je ne me lancerai pas dans des considérations sur l’indentation du code et des commentaires, c’est une guerre de religions. Mais j’ai rencontré des développeurs qui réagissaient aussi violemment devant un formatage de code « moche » que moi devant une grammaire moche.

Les environnements de développement modernes procurent la discutable possibilité aux développeurs d’être négligents sans effets pervers ; une interface glisser-déposer vous permet de créer une application vite fait bien fait (ou plutôt mal fait, j’en ai peur) avec bien moins d’horribles dommages collatéraux qu’à l’époque où les logiciels étaient généralement écrits en assembleur. Pourtant, d’une certaine façon, j’ai du mal à considérer le « je peux être négligent » comme un avantage réel.

La règle du commentaire « moche » vaut autant pour les applications propriétaires que pour les logiciels open source. Mais les développeurs de FOSS (NdT : Free and Open Source Software, les logiciels libres et open source) doivent faire beaucoup plus attention encore pour deux raisons. La première, c’est qu’au bureau, vous avez de grandes chances de croiser le développeur du code mal fichu et de pouvoir lui poser des questions (ou de lui en coller une, si c’était vraiment horrible). De plus, dans la communauté open source, davantage de gens regardent dans le code et ont besoin de le comprendre.

Toutefois, lorsque j’ai suggéré à des développeurs que « si les commentaires sont moches, le code est moche », beaucoup n’étaient pas d’accord. Et vous non plus peut-être. J’aimerais savoir pourquoi, et je vous invite donc à laisser un… commentaire.

Voici une traduction intéressante à plus d’un titre.

D’abord parce qu’elle donne la parole à un développeur de logiciel libre (dont nous n’oublions pas ce que nous leur devons, c’est-à-dire tout). En l’occurrence il s’agit de Zed Shaw, bien connu dans la communauté Python et RoR (Ruby on Rails).

Ensuite parce qu’elle évoque la classique opposition à l’intérieur même des licences libres entre celles de type GPL et celle de type BSD. C’est toute la question du copyleft et de la viralité de la licence. Le copyleft est une apparente restriction, puisqu’il impose de diffuser le code modifié sous la même licence. Mais peut-être que cette contrainte est paradoxalement une garantie supplémentaire de liberté pour l’utilisateur ?

Enfin parce qu’elle aborde de nombreuses problématiques liées à l’open source et au monde de l’entreprise. Le fait de cacher à ses clients que l’on a utilisé du logiciel libre dans les solutions que l’on propose est une attitude malheureusement très fréquente (permettant de faire croire à moindre frais que l’on est hyper-compétent et que l’on a travaillé dur sur le projet). Il y a aussi toute la logique des startups, dont on attend un retour sur investissement presque immédiat, et qui du coup font de la rétention de code pourtant libre au départ.

Et puis il y a la question morale de la reconnaissance et celle très concrète du gagne-pain du développeur, frustré d’être ainsi ignoré et constatant non sans une certaine irritation que d’autres en profitent à sa place.

Voilà donc, entres autres arguments, pourquoi l’article ci-dessous mérite attention. Fatigué qu’une énième personne vienne lui demander pourquoi son code n’est pas sous licence BSD, Zed Shaw a décidé de réagir avec ce plaidoyer pugnace pour la licence GPL.

« Je veux que les gens apprécient le travail que j’ai fait et la valeur de ce que j’ai réalisé. Pas qu’ils passent en criant « pigeon » au volant de leurs voitures de luxe. »

Remarque : L’auteur concentre dans son titre les trois licences de la famille : la GNU/GPL, la LGPL et l’AGPL^[1].

Pourquoi je (A/L)GPLise

Why I (A/L)GPL

Copyright Zed A. Shaw – 13 juillet 2009 – Blog personnel
Avec l’aimable autorisation de l’auteur
(Traduction Framalang : Poupoul2 et Cheval boiteux – Remerciements à Léviathan)

Dans le monde de Python, la GPL est fréquemment critiquée, la plupart préférant utiliser une licence plus permissive telle que BSD, MIT ou Python. Il est donc compréhensible que des gens soient en colère parce que j’ai placé Lamson (NdT : Serveur SMTP développé en Python) sous licence GPL. Nombreux sont ceux qui détestent cette licence, pensant qu’elle contrevient à l’esprit de Python.

J’aimerais cependant expliquer pourquoi moi j’utilise la GPL, après des décennies d’écriture de logiciels open source et quelques projets reconnus. Ce sont mes raisons de l’utiliser, elles ne s’appliquent qu’à moi et à ce que je souhaite faire de mon logiciel dorénavant. Vous êtes libres de vos opinions et choix, et j’espère que vous respecterez les miens.

C’est le droit de l’auteur

Je crois que ce qu’un auteur souhaite faire avec son travail est son droit le plus strict. Il l’a écrit, alors que tout le monde lui expliquait que ça ne fonctionnerait pas. Il s’est enchaîné à ce travail plutôt que de sortir avec des amis. Il en a corrigé les bogues, écrit sa documentation de façon à ce que tout le monde puisse l’utiliser. Il a peut-être même passé du temps à en assurer la promotion et à aider les gens. Tout cela gratuitement, et pour des raisons qui lui appartiennent.

Lorsque vous dénigrez un projet ou une personne pour son choix de licence, vous êtes un gigantesque abruti. L’auteur a travaillé sur ce projet, pas vous. Au minimum, vous insultez les croyances de cette personne dans le logiciel libre et open source, mais aussi son sentiment que le logiciel libre et open source fait progresser notre culture.

Au pire, vous êtes un gros et ingrat malotru, parce que quelqu’un vous donne un logiciel, alors que vous insultez son travail non pas sur des critères techniques, mais sur une licence que vous désapprouvez.

Je me fiche totalement de la licence que les autres utilisent pour leurs logiciels, c’est leur logiciel et râler à cause de la licence qu’ils ont choisi est injurieux. Ils l’ont écrit, y ont sué sang et eau, et vous devriez être reconnaissant d’avoir le privilège de simplement y avoir accès.

Voici la première raison pour laquelle j’utilise la GPL :

Parce que c’est mon choix, et si vous n’êtes pas d’accord avec ça, n’utilisez pas mon logiciel. C’est aussi simple que ça.

Je ne veux plus être ignoré

J’ai écrit Mongrel (NdT : Serveur et librairie HTTP pour Ruby on Rails) et puis je l’ai donné, avec l’espoir que ça en aiderait d’autres et que le donner me rapporterait d’une manière ou d’une autre. Peut-être un boulot, ou un peu de respect, ou encore ma propre entreprise créant d’autres logiciels tels que celui-ci.

Mongrel a eu un grand succès, et de très nombreuses entreprises gagnent beaucoup d’argent avec. Non seulement permet-il à Rails de fonctionner, mais également à quasiment tous les frameworks Web Ruby, tel que les serveurs web Ruby, et a même été porté dans d’autres langages. Mongrel est et a été un super projet et j’en suis réellement fier.

Laissez moi vous expliquer à quel point Mongrel est avancé. Vous rappelez vous de la nouvelle attaque récemment publiée sur Apache appelée Slowloris (NdT : attaques par Déni de Service via des requêtes HTTP partielles) ? J’avais en fait prévu cette attaque, et écrit Mongrel de manière à ce qu’il y soit résistant (autant que Ruby me l’ait permis). Je l’avais appelé la « trickle attack » (NdT : attaque par écoulement), et j’en avais même fait la démonstration. C’était en 2004. Il y a cinq ans. Je l’avais même ajouté comme attaque à RFuzz en 2005.

Malheureusement, le succès de Mongrel ne m’est pas revenu. Bien que tout le monde utilise mon logiciel, la grande majorité des entreprises utilisatrices étaient des startups, et la dernière chose que les startups admettent c’est qu’elles ne possèdent pas leur propriété intellectuelle. Elles souhaitent que tout le monde, et particulièrement les sociétés de capital risque et les investisseurs, croit qu’elles sont des génies qui ont « innové » dans tout ce qu’elles font fonctionner.

Lorsque je regardais autour de moi, les entreprises n’avaient aucun problème à admettre qu’elles utilisaient Ruby on Rails, mais elles n’en disaient pas plus, ce qui signifiait que lorsque j’essayais de trouver du travail, il m’était impossible d’expliquer l’ampleur de l’impact de Mongrel. Pour elles, il ne s’agissait que d’un simple serveur Web que leur administrateur système devait utiliser, Ruby on Rails était le véritable pourvoyeur d’argent.

Voici la seconde raison pour laquelle j’utilise la GPL :

À cause de l’expérience Mongrel, j’ai presque besoin que les entreprises soient obligées d’admettre qu’elles utilisent mon logiciel. Je préfèrerais à la limite que personne n’utilise mon logiciel, plutôt que de me trouver dans une situation où tout le monde l’utilise et personne ne l’admet.

Pire, tout le monde l’utilise, et en même temps me dit que je ne sais pas développer.

Le capital risque a changé l’industrie

L’industrie du logiciel a changé depuis l’an 2000. Je mettrais en fait le curseur à l’entrée en bourse de Google, mais je ne peux pas dire exactement à quel moment. Ce que je peux dire, c’est que les méthodes actuelles de progression des entreprises technologiques induisent l’exploitation du code source plutôt que la contribution.

Je ne peux pas réellement en vouloir à ces startups, elles sont conçues ainsi. Une entreprise adossée à un capital-risqueur aura presque toujours un objectif de gain à court terme, dans l’espoir d’apporter plus tard un joli retour sur investissement. Pour un capital-risqueur, un retour sur 20 ans n’est pas acceptable, particulièrement si vous prévoyez de faire cela sans offre et des stocks options disponibles pour tout le monde.

Pour une entreprise financée par un capital-risqueur, il ne s’agit toujours que d’augmenter des revenus pour donner l’illusion de la croissance, afin que les actionnaires investissent et mènent le prix de l’action aussi haut que possible. Il n’est pas dans leur intérêt de ne pas faire d’offre. Ils veulent de l’argent maintenant, autant que possible, et ne sont pas intéressés par l’investissement technologique ou humain.

Ce qu’elles veulent, ce sont des tonnes de technologie gratuite qu’elles peuvent cacher aux investisseurs. Elles sont ravis que cette technologie soit maintenue par des gens qui ne l’ont pas écrite, pour que les employés ne puissent pas réclamer leur dû plus tard.

Cette gestion à courte vue, combinée au financement limité de départ, signifie que ces entreprises exploitent l’open source. Elles l’utiliseront, gagneront leur argent, et partiront lorsque ceci sera fait. Ce qui, en fait, est parfaitement logique, parce que ainsi vont les choses, et honnêtement, si vous êtes une entreprise qui cherche à gagner de l’argent de cette manière, c’est ce que je vous suggèrerais de faire.

Pourtant, le contrat tacite entre les entreprises et les développeurs open source est désormais révolu. Je n’ai aucune raison de leur offrir un usage sans restriction de mon logiciel, puisqu’ils ne sont intéressés que par la transformation de mon logiciel en offre alléchante de mise sur le marché à court terme, à deux ou cinq ans.

Voici la troisième raison pour laquelle j’utilise la GPL :

Les entreprises du secteur technologique sont désormais conçues pour être créées et détruites rapidement au bénéfice de gros capital-risqueur, tout en maintenant des coûts très bas. Cela signifie qu’elles n’ont aucune prime économique à donner, aussi n’ai-je aucune prime sociale à leur « donner » mon logiciel.

Les développeurs sont des plagiaires

Ne nous voilons pas la face, tout le monde a besoin de manger et de payer son loyer. Pour beaucoup de gens, leurs besoins en argent sont modestes, et si vous travaillez sur quelque chose, vous espérez en retirer quelque chose qui vous aidera à satisfaire ces besoins. Il se peut que ce ne soit pas de l’argent. Peut-être est ce que ce sera du respect, ou des honneurs, mais vous espérez réellement quelque chose de votre travail.

Nous sommes d’accord. Aussi je trouve étrange un message twitter tel que celui-ci :

ericholscher @zedshaw Ce serait chouette si l’interface/code était sous licence BSD. Très utile au travail. L’interface REST marche aussi très bien.

Éric est un garçon très sympathique, aussi je ne vais pas m’acharner sur lui, mais si je traduis le message, ça pourrait donner ça : « Hey ! Ton logiciel est fantastique ! Je peux l’avoir gratuitement, pour pouvoir l’utiliser au boulot, plaire à mon patron et me faire de l’argent ? »

Honnêtement, combien d’administrateurs disent à leur patron que ce qu’ils utilisent provient du logiciel libre ? Combien d’entre vous disent aux investisseurs que toute votre infrastructure logicielle est basée sur un truc qu’un autre gars a écrit en plusieurs mois ? Combien d’entre vous vont voir leur dirigeants en disant : « Vous savez, il y a ce gars, Zed, qui a écrit le logiciel que nous utilisons, pourquoi ne pas l’embaucher comme consultant ? »

Vous ne le faites pas. Aucun d’entre vous. Vous prenez le logiciel, et vous l’utilisez tel Excalibur terrassant le dragon, et vous en ramassez ensuite tous les lauriers. Vous ne rendez rien, et en fait, j’ai croisé une grande majorité d’entre vous qui assènent constamment que je ne sais pas développer, histoire de plus encore protéger son cul.

Il n’est désormais plus pardonnable et acceptable que vous tous plagiez le travail que vous utilisez. Comme vos employeurs ont besoin de l’illusion de « l’innovation », vous avez besoin de l’illusion d’être intelligent. Ce qui vous amène à mentir, et à voler tout ce qui vous tombe sous la main, comme si cela vous appartenait.

Ok, mais cela signifie que vous avez cassé le contrat tacite avec les développeurs et défenseurs de logiciels libres et open source. Aussi longtemps que vous me rendez ma paternité et que vous assurez la promotion de mon travail, je vous donnerai mon logiciel. Puisqu’aucun d’entre vous ne le fait, je n’ai aucune motivation à vous donner mon logiciel, de la même manière que je n’ai pas besoin de me conformer au contrat passé avec l’entreprise nourrie au capital-risque.

Voici la quatrième raison pour laquelle j’utilise la GPL :

J’utilise la GPL pour que vous restiez honnête. Vous devez désormais dire à vos patrons que vous utilisez mon boulot. Et ils s’en pisseront dessus de trouille. Parfait. Parce que j’ai aussi une solution pour ça.

Si c’est bien, payez pour l’avoir

J’aime travailler sur Lamson, parce que faire des application de messagerie est tellement plus drôle que des applications Web. Lorsque je m’assois pour construire une application de courriel, ça ne nécessite qu’un ensemble de technologies et c’est terminé. Si j’ai besoin de faire une application Web, cela implique du design, des templates, du javascript, des bases de données, et plein d’autres machins.

L’autre raison pour laquelle j’aime écrire des logiciels de courriels est que personne d’autre ne le fait. Vous tous êtes de grosses buses, parce que même avec un projet tel que Lamson, vous êtes encore tous effrayés par le gros monstre SMTP. Le jour où j’ai dit que je pourrais faire du Mail over REST, vous avez presque fait dans votre slip. Oui, parce que ça aurait été tellement plus simple.

Et j’aime donner Lamson, parce que c’est une partie de moi-même. C’est ce parfait mélange de camelote, bidouillages techniques, marketing et écriture que j’aime, et dans lequel j’excelle. Même si j’en arrive à faire des montagnes d’argent en construisant des choses avec Lamson, Lamson restera libre pour que je puisse rester honnête.

Mais j’écris aussi mes propres logiciels et projets avec Lamson. Je l’utiliserai pour créer autant d’incroyables services de courriel que je pourrais. Certains gratuits, certains payés par la pub, certains payants, mais tous utiliseront Lamson pour botter des culs avec du courriel.

Maintenant, compte tenu du fait qu’il n’y a aucune motivation pour une entreprise à admettre qu’elle utilise mon travail, et qu’il n’y a aucune motivation pour un développeur à me rendre mon travail, posez vous cette simple question :

Pourquoi diable est ce que je ne facturerais pas des gens qui ne sont pas capables d’utiliser correctement la GPL ?

Je sais, je sais, les conservateurs du logiciel libre pensent que cela fait de moi un traître, mais réfléchissez-y. Vous avez le logiciel, sous licence GPL, et aussi longtemps que vous êtes un projet open source taillé dans la pierre qui publie son code, vous êtes libre de l’utiliser et d’en faire ce que vous voulez.

J’aime l’open source, mais qu’en est-il des entreprises qui l’utilisent ? Les entreprises vont devoir payer à présent. C’est ainsi que fonctionne l’économie. Si c’est assez bon pour que vous l’utilisiez, alors c’est assez bon pour que vous le payiez.

Voici la cinquième raison pour laquelle j’utilise la GPL :

Je serai toujours un développeur open source, mais très franchement, nous crevons parce que des entreprises qui utilisent nos logiciels ne rendent rien. L’ironie de la situation est que pour pouvoir accroître ma motivation à faire de l’open source, j’ai besoin de me faire payer.

Je ne demanderai évidemment jamais rien à un projet open source puisqu’ils honorent le contrat tacite : si je donne, vous donnez.

Mais les jours des entreprises-minutes et des développeurs ingrats qui gagnent de l’argent sur mon dos avec mon logiciel sont terminés. Ma nouvelle devise est :

L’open source à l’open source, le business au business.

Si vous faites de l’open source, vous êtes mon héros et je vous soutiens. Mais si vous êtes une entreprise, alors parlons affaires.

Finalement, la valeur

Au final, je voudrais également donner une petite raison pour laquelle j’utilise la GPL : La valeur perçue. Lorsque les gens peuvent obtenir quelque chose gratuitement sans même avoir besoin d’y penser, ils lui donnent même moins de valeur que quelque chose pour lequel ils paient même pour une somme dérisoire. C’est juste la manière d’être des gens, et il n’y a pas grand chose à faire contre ça.

Ma dernière raison d’utiliser la GPL est que je crois que mes projets ont de la valeur, et je veux que les gens qui les utilisent perçoivent cette valeur. Ils ont même tellement de valeur que je veux les associer à un document légal complexe et totalement non testé comme preuve de leur utilité. Si je voulais faire simple, je les placerais simplement sous licence BSD et tout le monde les utiliseraient.

Je veux que les gens apprécient le travail que j’ai fait et la valeur de ce que j’ai réalisé.

Pas qu’ils passent en criant « pigeon » au volant de leurs voitures de luxe.

Et si le plus grand danger qui guettait désormais le logiciel libre n’était pas exogène mais endogène ?

Si, comme le pensent certains, ce n’était plus le logiciel propriétaire qui menace, mais une dilution des valeurs et de la culture du logiciel libre dans une soupe open source de… confusion et d’opacité, au grand dam de l’utilisateur qui ne serait plus alors acteur potentiel d’une communauté ?

On aurait même inventé une expression pour caractériser ces logiciels aux processus de développement privés et fermés qui, et je caricature à dessein^[1], finissent par n’avoir d’open source que la licence : les « fauxpen source ».

Personnellement j’aime beaucoup ce néologisme. Il a été inventé par Phil Marsosudiro le 2 mai 2009 au cours d’une soirée (arrosée ?) quelque part en Caroline du Nord. Comment le sais-je ? Parce que je me suis rendu sur le site, ou plutôt la page, fauxpensource.org pardi !

Et il est repris ici par Matt Asay^[2] dont je ne partage pas forcément l’optimisme (et les contradictions) mais qui évoque une problématique dont nous n’avons pas fini d’entendre parler.

Quand l’open source ne l’est pas assez (open)

When open source isn’t (open enough)

Matt Asay – 10 novembre 2009 – CNET News (The Open Road)
(Traduction Framalang : Yonnel et Cheval boiteux)

Certains logiciels open source ne sont peut-être pas assez ouverts. Alors que « open source » fait référence à la licence sous-jacente au logiciel et à son adhésion à la définition de l’open source, on trouve de nombreux exemples de projets open source qui offrent une licence ouverte mais un processus de développement relativement fermé.

On a appelé cela « fauxpen source », ou pire encore, mais nous devons peut-être nous y habituer. Cela semble être la nouvelle norme du développement open source. Seules les fondations open source comme Eclipse, Apache Software Foundation et Mozilla semblent en mesure d’y échapper totalement.

Java est souvent cité comme exemple emblématique de « fauxpen source ». Lundi, le directeur technique de SAP, Vishal Sikka, a appelé de ses vœux un processus plus ouvert pour le développement de Java, mettant en avant que Sun exerce un contrôle trop strict sur le développement de Java. C’est un reproche qui mine la communauté Java depuis des années.

Et Java n’est pas le seul. Si Google s’attire les compliments pour ses investissements dans l’open source, certains n’hésitent pas à prétendre que Google garde une communauté Android fermée. Le même genre de plaintes a vu le jour à propos de la gestion de Chrome et de Chrome OS.

Même Red Hat, la quintessence des entreprises open source, est d’abord connue pour ce qu’elle distribue, pas pour ce qu’elle développe. Red Hat, bien sûr, travaille aux côtés d’IBM et d’autres développeurs salariés ou indépendants à l’écriture du noyau Linux, et publie scrupuleusement ses logciels sous licences open source. Mais lorsqu’il s’agit du développement de sa distribution Red Hat Enterprise Linux, de son middleware JBoss ou d’autres technologies (par ex. KVM), bonne chance si vous voulez trouver des contributions externes significatives.

MySQL ? C’est grosso modo la même chose. L’entreprise (maintenant Sun Microsystems) fait virtuellement tous ses développements en interne, ce qui est vrai pour chaque entreprise privée open source qui me vient en tête. C’est une des raisons pour lesquelles Richard Stallman n’a pas à rougir de s’inquiéter de l’avenir de MySQL, même si c’est sa licence GPL préférée qui est utilisée.

La source est peut-être open, mais le processus pas nécessairement.

Il y a de très bonnes raisons pour que Google, Red Hat, MySQL et d’autres agissent de la sorte sur leurs efforts de développement open source. Ils sont responsables, fiscalement et légalement, devant leurs clients, et doivent être en capacité de garantir qualité et sécurité. On peut comprendre qu’ils exercent un certain contrôle pour s’assurer que les produits qu’ils distribuent protègent l’intégrité de leur marque.

Toutefois ceci témoigne d’un réel fossé entre « l’open source » en tant que licence et « l’open source » en tant que mode de développement et de distribution de logiciels complètement transparent. Le premier modèle est simple à mettre en place, le second beaucoup moins et demande une réelle volonté de la part de l’éditeur.

Les entreprises qui semblent mieux réussir sont celles qui ne comptent pas sur un retour sur investissement direct avec les logiciels libres. En d’autres termes, si vous ne vendez pas de l’open source, il est plus facile d’être ouvert. Doc Searls exprime cela de manière tout à fait pertinente quand il dit que « vous gagnez de l’argent grâce à (l’open source), pas de l’open source ».

Les exemples ne manquent pas. IBM en est un, Google également, bien que je sois d’accord avec ceux qui le critiquent car il peut assurément mieux faire. On peut également citer Facebook, Oracle et quelques autres.

À l’avenir, je pense que nous allons voir cette « fauxpen source » décliner, les entreprises séparant clairement leurs efforts dans l’open source et leurs modèles de ventes. L’open source peut offrir une plate-forme directe de gains, mais ce n’est pas le meilleur moyen pour véritablement générer de l’argent. Pas pour la plupart des entreprises en tout cas.

Un peu de storytelling aujourd’hui sur le Framablog, avec cette histoire de fourmis qui n’avaient pas d’images dans Wikipédia.

Nous le savons, l’encyclopédie libre est très certainement l’une des plus belles aventures humaines jamais imaginées.

Mais son influence est telle qu’elle a aujourd’hui également la capacité d’influencer directement ou indirectement la politique de licences des contenus produits par les organismes publics, universités en tête^[1].

AntWeb passe sous licence Creative Commons BY-SA

AntWeb goes CC-BY-SA

Waldir Pimenta – 6 novembre 2009 – All The Modern Things
(Traduction Framalang : Poupoul2)

Saviez vous que l’insecte le plus venimeux au monde est une fourmi ? En effet, une piqûre de la fourmi Maricopa Harvester équivaut à douze piqures d’abeilles, ce qu’il faut pour tuer un rat de plus de deux kilos.

J’ai découvert cela il y a plus d’un an dans le livre des insectes de l’Université de Floride. Je me suis immédiatement tourné vers Wikipedia pour savoir ce qu’on en disait, mais à ma grande surprise, aucun article n’existait. J’en ai donc commencé un à partir d’un page blanche, en utilisant des informations glanées sur plusieurs sites consacrés aux fourmis. Finalement, les gens ont commencé à enrichir l’article, jusqu’à ce qu’il contienne une somme d’informations de bonne qualité à propos de cette espèce fascinante. Mais il y manquait toujours quelque chose, qui à lui seul pouvait rendre l’article dix fois meilleur : Une image.

Ainsi, en cherchant des images afin d’illustrer cet article, j’ai découvert les fantastiques images d’AntWeb, un projet de l’Académie des Sciences de Californie, qui a pour objectif d’illustrer l’énorme diversité des fourmis dans le monde. J’étais particulièrement heureux qu’ils utilisent une licence Creative Commons, mais j’ai rapidement déchanté en constatant que celle qu’ils utilisaient (la licence Creative Commons BY-NC) n’était pas appropriée pour Wikipédia, ou plus généralement pour ce que les Creative Commons appellent elles-mêmes les « œuvres culturelles libres » (Ndt : voir à ce sujet ce billet du Framablog).

Je leur ai donc envoyé un courriel, suggérant de changer la licence. Lorsqu’ils m’ont répondu, j’ai découvert qu’en fait, des discussions internes à propos de la licence étaient déjà en cours. Je suis resté en contact avec eux, et me suis assuré de leur parler des avantages de voir leurs travaux placés dans des vitrines telles que Wikipédia, Commons ou Wikispecies.

J’aime à penser que ma modeste intervention a participé à leur prise de décision, quelque temps plus tard, non seulement de changer de licence pour une Creative Commons BY-SA, mais également de téléverser leurs images dans Commons eux-mêmes. Il s’agissait d’une partie de leur mission globale : « L’accès universel aux informations sur les fourmis ». Auparavant, le projet AntWeb, se concentrait sur la numérisation de contenus et le développement d’un portail web : ils ont désormais décidé d’exporter le contenu d’AntWeb pour en améliorer l’accès. Mettre les images et les méta-données associées dans Commons fut un exemple en matière d’organisation.

Cette initiative a été saluée par la communauté, et il y a eu de nombreuses contributions à ce massif téléversement, afin de rendre les images plus faciles à trouver et à utiliser pour illustrer des articles, et autres pages pertinentes. Le processus a pris plusieurs jours, mais au final ce sont pas moins de 30 000 images qui auront été téléversées, intégralement associées à leurs données EXIF, mais également aux informations taxonomiques et géographiques, chaque fois qu’elles étaient disponibles.

Tout ceci n’est pourtant quelque part qu’une première pierre. Puisque, comme d’habitude dans le monde des wikis, vous pouvez contribuer. Il existe des articles à illustrer dans toutes les langues de Wikipedia (l’outil de recherche d’images libres FIST de Magnus arrive à point nommé pour cela). Il y a des pages à illustrer sur Wikispecies. Il y a des catégories à créer dans Commons, afin de faciliter la navigation dans l’arbre des catégories des fourmis et d’y rendre chaque image de fourmi accessible. Et plus important, il y a cette nouvelle fantastique à diffuser, afin de faire savoir à tous ceux qui sont intéressés par les fourmis qu’ils peuvent désormais compter sur ce qui est sans doute la plus importante ressource en ligne d’images de fourmis, toutes de grandes qualité.

Un grand merci à Brian Fisher, chef de projet AntWeb, qui a coordonné le processus de changement de licence, Dave Thau, ingénieur logiciel AntWeb, qui a écrit le script de téléversement et réalisé cette opération, et à toute l’équipe d’AntWeb pour leur formidable travail.

Le 26 août dernier la Free Software Foundation (FSF) lançait la campagne Windows7sins en vue d’alerter l’opinion sur le fait que Windows avait beau avoir changé, (le symbole du logiciel propriétaire qu’est) Microsoft demeurait toujours le même.

Grâce aux efforts communs et conjoints de Framasoft (traduction Framalang) et de l’April (relecture et mise en ligne^[1]), le site de la campagne est désormais traduit en français.

Cette campagne joue sur le numéro du dernier système d’exploitation pour se décliner en sept « péchés », malheureusement « capitaux » à freiner le développement et la diffusion du logiciel libre :

1. Empoisonnement de l’éducation
2. Invasion de la vie privée
3. Comportement monopolistique
4. Verrouillage
5. Blocage abusif des standards
6. Soutien des DRM
7. Menaces sur la sécurité de l’usager

Vous en trouverez quelques extraits ci-dessous mais nous vous invitons surtout à parcourir le site.

Remarque : Cette campagne a été diversement reçue par les internautes anglophones. Encore une critique de Microsoft, occupez-vous plutôt de mettre en avant les qualités du logiciel libre, envoyer une lettre aux 500 plus grandes sociétés américaines ne sert à rien^[2], a-t-on ainsi pu entendre ça et là. À vous ne nous dire (avec écoute et courtoisie) dans les commentaires si nous avons néanmoins bien fait de traduire le site.

Les 7 « péchés » de Windows 7

Péché 1 : Empoisonnement de l’éducation

À ce jour, on apprend à la plupart des enfants, dont l’éducation implique des ordinateurs, à utiliser le produit d’une seule entreprise : Microsoft. Cette firme dépense de fortes sommes pour que les groupes de pression et les commerciaux corrompent les services d’éducation. Une éducation qui mise sur la puissance des ordinateurs devrait ouvrir la voie de la liberté et de l’autonomie, et non ouvrir un boulevard au monopole insidieux d’une entreprise.
Pour en savoir plus..

Péché 2 : Invasion de la vie privée

Microsoft utilise des logiciels avec des noms fallacieux comme Windows Genuine Advantage pour inspecter le contenu des disques durs de ses utilisateurs. Les termes de la licence utilisateur que l’on est obligé d’accepter avant de pouvoir utiliser Windows préviennent bien que Microsoft se réserve le droit de faire ça sans avertissement.
Pour en savoir plus..

Péché 3 : Comportement monopolistique

Pratiquement tous les ordinateurs achètés sont vendus avec Windows pré-installé, et non par un libre choix. Microsoft impose ses dictats aux revendeurs de matériel informatique, pour qu’ils ne proposent pas de PC sans Windows pré-installé, bien que de très nombreux clients le leur demandent. Même les ordinateurs disponibles avec d’autres systèmes d’exploitations pré-installés tel que GNU/Linux incluaient souvent Windows au départ.
Pour en savoir plus..

Péché 4 : Verrouillage

Microsoft essaie régulièrement de contraindre ses utilisateurs à faire des mises à jour, en supprimant le support des versions précédentes de Windows et d’Office, et en augmentant le niveau du matériel requis. Pour beaucoup de gens, cela signifie qu’ils doivent mettre leur ordinateur au rebut juste parce qu’il n’est pas à la hauteur des exigences techniques requises par les nouvelles versions de Windows.
Pour en savoir plus..

Péché 5 : Blocage abusif des standards

Microsoft a essayé de bloquer le passage au standard libre pour les formats de documents, parce que des standards comme OpenDocument Format menaceraient le contrôle exercé pour le moment sur l’utilisateur avec les formats propriétaires de Word. Elle s’est lancée dans des manoeuvres en sous-main, qui peuvent aller jusqu’à la corruption de fonctionnaires, pour essayer de stopper de telles initiatives.
Pour en savoir plus..

Péché 6 : Soutien des DRM (Digital Restrictions Management)

Avec Windows Media Player, Microsoft collabore avec les grandes firmes des médias pour imposer des restrictions sur la copie de médias avec leur système d’exploitation. Par exemple, à la demande de NBC, Microsoft est capable d’empêcher les utilisateurs de Windows d’enregistrer des émissions télévisées qu’ils ont pourtant le droit d’enregistrer légalement.
Pour en savoir plus..

Péché 7 : Menaces sur la sécurité de l’usager

Windows a une longue histoire de failles de sécurité, ouvrant la porte à la diffusion des virus et permettant à des utilisateurs distants de prendre le contrôle des ordinateurs d’autres usagers et de les transformer en robots spammeurs. Puisque le logiciel est secret, tous les utilisateurs dépendent de Microsoft pour régler ces problèmes – mais Microsoft tient à ses propres intérêts en matière de sécurité, pas à ceux de ses usagers.
Pour en savoir plus..

Extraits du site Windows7Sins en version française.