L’âge de faire est un mensuel indépendant, sans publicité et à petit prix (1,50 €) qui cherche à sensibiliser un large public aux questions d’écologie, de citoyenneté, de solidarité.

Tiré à 25 000 exemplaires, il utilise un mode de distribution un peu particulier : plutôt qu’une diffusion en kiosque classique (mais coûteuse), ce journal s’appuie sur un réseau d’abonnés, de coopérateurs (invités à revendre leurs exemplaires), et de points relais volontaires.

Pourquoi donc en parler sur le Framablog ?

Parce qu’il existe des ponts naturels entre le logiciel libre et le « développement durable » (pris au sens noble et non marketing du terme).

Il nous arrive du reste d’en parler comme en témoigne notre tag « Écologie » regroupant divers billets autour du sujet^[1].

Ponts naturels que l’on pourrait assez paresseusement synthétiser par le diagramme ci-dessous :

Nous constatons par ailleurs que les rencontres et synergies se multiplient.

Ainsi le Festival du Développement Durable 2009 de Genève a accueilli plusieurs associations locales. C’est d’ailleurs à cette occasion et sous leur impulsion qu’est né le fort intéressant site Logiciels libres et développement durable d’où est issue l’illustration ci-dessus (pour l’anecdote on remarquera également cette très jolie Framakey durable en bois).

De même le Salon Primevère de Lyon accorde chaque année une place plus importante au logiciel libre (cette année le thème sera « Le prix de la gratuité » et de nombreuses associations du libre, dont Framasoft, y feront des conférences).

L’autre raison, c’est que le numéro actuel de L’âge de Faire (n°39 – février 2010) propose un excellent petit dossier d’une double page intitulée fort à propos : Et si on passait au libre ?

Suite à notre demande, l’auteur Didier Bieuvelet a tout de suite accepté d’en placer les articles sous licence Creative Commons By-Sa (articles dont les titres sont les suivants : Des logiciels citoyens, Témoignage d’un converti, Informatique libre et solidaire, Quels logiciels libres ?, Simple comme Ubuntu et De la vente liée à la vente forcée)

Vous trouverez donc :

• Les textes du dossier : au format ODT et au format PDF.
• Les pages originales du dossier au format PDF telles que vous pouvez les voir sur la copie d’écran : page 12 et page 13 (certaines photos n’étant pas sous licence libre, si un gentil volontaire souhaite refaire un PDF avec d’autres images libres pour diffusion/impression, nous nous ferons un plaisir de l’ajouter ici).

Quant au reste du journal, nous vous encourageons à vous rendre sur leur site pour vous le procurer.

La forge logicielle SourceForge n’est plus à présenter. C’est le plus grand dépôt d’applications libres au monde, qui se comptent en centaine de milliers.

Or petit scandale et réelle polémique, SourceForge vient tout récemment et sans préavis d’en barrer l’entrée aux ressortissants de l’Iran, la Corée du Nord, Cuba, du Soudan et de la Syrie, pour se mettre en conformité avec une loi américaine sur la sécurité nationale^[1].

Tant pis pour les développeurs et utilisateurs de ces cinq pays et tant pis aussi pour les principes non discriminants qui régissent le logiciel libre.

Pour évoquer ce problème nous avons choisi de traduire la news du Register, mais nous aurions tout aussi bien pu choisir cet article de ComputerWorld dont la conclusion interpelle : « La seule manière d’empêcher réellement les pays sur liste noire d’avoir accès aux dépôts de logiciels libres hébergés aux USA est d’interdire aux Américains de participer au mouvement open source ! »

SourceForge raye 5 nations de la carte open source

SourceForge bars 5 nations from open source downloads

Dan Goodin – 26 janvier 2010 – The Register
(Traduction Framalang : Olivier)

Certains pays sont plus égaux que d’autres

Le dépôt de logiciels open source, SourceForge.net, bloque désormais automatiquement les adresses Internet des utilisateurs de l’Iran, la Corée du Nord, Cuba, le Soudan et la Syrie au prétexte d’appliquer une loi empêchant les ressortissants de ces pays de télécharger des logiciels libres.

Les réactions des puristes du mouvement des logiciels libres et open source ne se sont pas fait attendre. Ils militent pour que chacun ait accès au code, à la seule condition qu’il respecte les termes de la licence. À l’instar du dépôt open source de Google, les termes d’utilisation de Sourceforge interdisent depuis longtemps à quiconque résidant dans un des pays placés sur la liste de sanction de l’US Office of Foreign Assets Control d’envoyer ou de télécharger du code.

Depuis la semaine dernière, SourceForge a commencé à bannir certaines adresses IP pour faire respecter cette interdiction. Dans un article paru lundi, Sourceforge n’annonce pas la raison de ce changement, mais il affirme néanmoins que cette décision ne cadre pas avec la philosophie de l’entreprise :

« Cependant, notre participation à la communauté open source ne peut pas nous faire oublier que nous vivons dans le monde réel et que nous sommes tenus aux lois qui régissent le pays d’où nous exerçons », peut-on lire dans l’article. « Notre obligation est de suivre ces lois et nos vœux, aussi humanistes soient-ils, ne peuvent pas s’y soustraire. »

Les critiques de cette restriction ne se firent pas attendre. Dans les commentaires, sur le blog de SourceForge, une personne note que cette restriction entre en conflit avec la Section 5 de la définition de l’Open Source qui stipule que les licences ne doivent pas établir une discrimination « entre des personnes ou des groupes de personnes ». Les critiques soutiennent également que ces restrictions ne sont pas compatibles avec le discours que tenait la semaine précédente Hillary Clinton, la Secrétaire d’État américaine, encourageant un Internet libre.

En janvier 2008, Bruce Byfield écrivait, dans un article que nous avions traduit ici-même (Ce qui caractérise les utilisateurs de logiciels libres) : « La communauté du Libre peut se targuer d’être une méritocratie où le statut est le résultat d’accomplissements et de contributions ».

Deux ans plus tard, le même nous propose de sonder plus avant la véracité d’une telle assertion, qui ne va finalement peut-être pas de soi et relève parfois plus du mythe savamment auto-entretenu.

Et de poser en guise de conclusion quelques pertinentes questions qui si elles trouvaient réponse participeraient effectivement à combler l’écart constaté entre la théorie et la pratique.

Nos propres discours n’en auraient alors que plus de consistance et de maturité^[1].

Les projets open source et le mythe de la méritocratie

Open Source Projects and the Meritocracy Myth

Bruce Byfield – 2 décembre 2009 – Datamation
(Traduction Framalang : Olivier et Cheval boiteux)

« Ce n’est pas une démocratie, c’est une méritocratie. »

On trouve cette déclaration sur la page de gouvernance d’Ubuntu, mais les notes de version de Fedora présentent quelque chose de similaire, tout comme la page Why Debian for developers et partout où l’essence des projets libres et open source (NdT : FOSS) est débattue.

La méritocratie est un mythe, une de ces histoires que la communauté des logiciels libres et open source aime se conter. Par mythe je n’entends pas mensonge, mais cette méritocratie est une histoire que les développeurs se racontent à eux-mêmes pour les aider à se forger une identité commune.

En d’autres termes, l’idée que les logiciels libres et open source sont une méritocratie est aussi vraie que de dire que les États-Unis sont une terre d’opportunité, ou que les scientifiques sont objectifs. Pour les membres de la communauté des logiciels libres et open source cette idée est primordiale dans leur perception du système et leur perception d’eux-même, car ils ont foi en cette idée que le travail est récompensé par la reconnaissance de leurs pairs et l’attribution de plus de responsabilités

Afin de perdurer, il faut que le mythe renferme une part de vérité, et ainsi personne ne le remet en question. Des exceptions peuvent survenir, mais elles seront justifiées, voire niées.

Cependant, si les mythes de la communauté ne sont pas des mensonges, ils ne révèlent pas toute la vérité non plus. Ils sont souvent des versions simplifiées de situations bien plus complexes.

La méritocratie dans les logiciels libres et open source n’échappe, à mon avis, pas à ce constat. Selon le contexte, si vous contribuez dans un bon projet et faites les choses biens, l’aspect méritocratique des logiciels libres et open source s’ouvrira à vous, c’est souvent le cas.

Mais de là à dire que les communautés ne fonctionnent qu’au mérite, il y a un pas que je ne franchirai pas. Le mérite n’est qu’un facteur à prendre, parmi tant d’autres, le mérite seul ne vous accordera ni reconnaissance, ni responsabilités. Bien d’autres considérations, souvent ignorées, entrent en jeu.

Hypothèses contestables

En invoquant l’argument du mérite on tourne rapidement en rond, c’est l’un des problèmes d’une méritocratie. Une hiérarchie est déjà établie, oui, mais comment ? Au mérite. S’ils n’avaient pas de mérite, ils n’auraient pas leur place.

Pas besoin de chercher bien loin pour voir que seul le mérite ne compte pas dans la hiérarchie des logiciels libres et open source. Les fondateurs du projet, en particulier, ont tendance à conserver leur influence, peu importe l’importance de leurs dernières contributions… si tant est qu’ils contribuent toujours au développement.

Par exemple, lorsque Ian Murdock fonda Progeny Linux Systems (entreprise pour laquelle j’ai travaillé) en 2000, il n’avait pas participé au projet Debian depuis quelques années. Et malgré cela, lorsque l’entreprise s’intéressa à Debian, son statut n’avait pas bougé. Tout portait à croire qu’il n’allait pas s’impliquer personnellement dans le projet et pourtant, s’il n’avait pas refusé la proposition, on lui aurait malgré tout attribué le titre de Debian Maintainer sans passer par le processus habituel.

Plus récemment, Mark Shuttleworth est devenu dictateur bienveillant à vie pour Ubuntu et Canonical, non pas à cause de ses contributions aux logiciels libres, mais parce qu’il disposait de l’énergie et de l’argent pour se propulser à ce rang. Sa position au sein d’Ubuntu ou de Canonical n’est pas remise en cause, mais toujours est-il qu’elle ne doit rien au mérite (au sens où l’entend la communauté), mais plutôt à son influence.

Et les leaders ne sont pas les seuls à gagner de l’influence pour des raisons autres que leur mérite. Dans les projets où certains contributeurs sont rémunérés et d’autres bénévoles, les contributeurs rémunérés ont presque toujours plus d’influence que les bénévoles. Dans certains cas, comme sur le projet OpenOffice.org, les contributeurs salariés peuvent presque entièrement éclipser les bénévoles.

D’autres projets, comme Fedora, repartissent l’influence plus équitablement, mais les contributeurs payés occupent souvent des postes à responsabilité. Par exemple, des dix membres du comité d’administration de Fedora, sept sont des salariés de Red Hat. Idem pour openSUSE où trois des cinq membres du comité sont des employés de Novell, le principal sponsor du projet, et un autre est consultant spécialisé dans les produits Novell. Et la situation est similaire dans bon nombre d’autres projets.

Alors oui, vous allez me dire que les membres payés ont plus de temps à accorder à ces responsabilités. C’est juste, mais ce n’est pas le sujet. Le fait est que les membres payés occupent statistiquement plus de postes à responsabilité que les bénévoles. Et c’est toute le postulat de départ qui est remis en cause, on constate alors que votre statut dans le projet n’est pas directement déterminé par votre mérite.

D’autres moyens de se faire remarquer

La méritocratie semble être le système parfait en théorie. Mais le fait est que la théorie est rarement mise en pratique. Avant de le reconnaître, encore faut-il déjà définir ce qu’est le mérite, la communauté des logiciels libres et open source ne fait pas exception.

Bâtie sur le code, la communauté des logiciels libres et open source valorise principalement la capacité à coder, bien que les plus gros projets soient beaucoup plus variés : tests, rédaction de la documentation, traduction, graphisme et support technique. De nombreux projets, comme Fedora et Drupal, évoluent et tentent de gommer cet a priori, mais cela demeure vrai pour la plupart des projets. Ainsi, les noms connus dans les projets ou les personnes qui font des présentations lors des conférences sont majoritairement des développeurs.

Cet a priori est cependant justifié. Après tout, sans le code, le projet de logiciel libre ou open source n’existerait pas. Et pourtant, le succès du projet dépend autant des autres contributions que du code lui-même.

Et comme le fait remarquer Kirrily Robert, blogueur chez Skud, même si certaines contributions sont moins estimées que d’autres, ça n’est pas une raison de les occulter complètement.

Par exemple, la personne la mieux placée pour écrire la documentation pourrait bien être le chef du projet, mais peut-être alors a-t-il mieux à faire que de rédiger la documentation. Il vaut peut-être mieux qu’une autre personne, même moins douée, rédige la documentation. Dans ce cas, celui qui écrit la documentation devrait être remercié, non seulement pour son travail, mais aussi parce qu’il libère l’emploi du temps du chef du projet. Et pourtant ceci est rarement reconnu dans les projets de logiciels libres ou open source.

L’idée que le mérite soit remarqué, reconnu et recompensé est rassurante dans notre culture industrielle moderne. J’aurai même tendance à penser que c’est encore plus rassurant dans le cercle des logiciels libres et open source, dont de nombreux membres admettent être introvertis, voire même se diagnostiquent eux-mêmes comme étant victime du syndrome d’Asperger.

Mais le mérite est-il toujours reconnu dans les logiciels libres et open source ? Voici ce que Noirin Shirley écrit à propos des obstacles à franchir par les femmes pour participer à cet univers :

Souvent, les valeurs reconnues dans une méritocratie deviennent rapidement le couple mérite/confiance en soi et obstination, dans le meilleur des cas. « Le travail bien fait ne vous apporte pas d’influence. Non, pour gagner de l’influence il faut faire du bon travail et bien s’en vanter, ou au minimum le rappeler à tout le monde régulièrement. » Les femmes échouent à cette étape là.

Shirley suggère ici qu’il faut non seulement être bon et régulier, mais il faut aussi savoir se rendre visible sur les forums, chats et listes de discussion, ainsi qu’aux conférences. Puisque les femmes sont apparemment conditionnées culturellement pour ne pas se mettre en avant, elles sont nombreuses à ne pas être à leur avantage dans un projet de logiciel libre ou open source (idem pour les hommes manquant de confiance en eux). Si elles ne peuvent ou ne souhaitent pas s’auto-promouvoir un minimum, leurs idées peuvent passer inaperçues, être sous-estimées ou carrément écartées.

À l’inverse, selon la même logique, certains gagnent en autorité plus parce qu’ils sont sociables ou opiniâtres que pour ce qu’ils réalisent concrètement (j’ai quelques exemples en tête, mais je ne veux pas faire d’attaque personnelle).

Tout comme la démagogie peut pervertir la démocratie, l’auto-promotion peut pervertir la méritocratie. Si un projet n’y prend pas garde, il se retrouvera bien vite à accepter des contributions, non pas sur la base de leur qualité, mais à cause de la visibilité et de l’insistance de celui qui les propose.

L’attraction sociale et comment s’y soustraire

Dans Le mythe de la méritocratie, Stephen J. McNamee et Robert K. Miller, Jr. avancent que la méritocratie aux États-Unis est influencée par ce qu’ils nomment l’attraction sociale. Ce sont des facteurs comme l’origine sociale ou l’éducation qui peuvent modifier positivement ou négativement la perception qu’ont les autres de nos contributions.

D’après moi, l’attraction sociale touche aussi la communauté des logiciels libres et open source, pas simplement parce qu’elle fait partie de notre société industrielle moderne, mais pour des facteurs qui lui sont propres. Reconnaître son existence n’est pas forcément facile, mais ça n’est pas pour autant une remise en cause de la méritocratie dans les logiciels libres et open source. L’importance du travail réalisé par les contributeurs n’en est pas non plus amoindrie.

Au contraire, reconnaître l’existence de l’attraction sociale peut être un premier pas pour améliorer la méritocratie dans le monde des logiciels libres et open source.

Kirrily Robert émet une idée intéressante. À l’instar des auditions anonymes où les musiciennes sont plus facilement choisies lorsque le sexe de la personne qui postule n’est pas connu, Robert propose que les soumissions soient également anonymes afin que leur évaluation ne soit pas biaisée. Si l’augmentation des contributions féminines lui tient à cœur, ces soumissions anonymes pourraient aussi garantir que seul le mérite entre en ligne de compte pour chaque contribution.

Mais ce n’est là qu’une proposition. Si vous voulez que la communauté des logiciels libres et open source devienne véritablement méritocratique, alors elle doit avoir le courage se poser quelques bonnes questions.

Pour commencer, par quel autre moyen peut-on réduire l’importance de l’auto-promotion ? Comment peut-on s’assurer que les employés et les bénévoles soient réellement au même niveau ? Peut-on redéfinir le mérite pour qu’il ne reflète pas uniquement ce qui est lié au code, mais au succès global du projet ?

Répondre à ces questions n’affaiblira pas le principe du mérite. Au contraire, ce principe de base de la communauté devrait en ressortir renforcé, et mieux utilisé. Et c’est, sans aucun doute, ce que souhaite tout supporter des logiciels libres et open source.

Lu sur le site de l’AFUL : Éric Magnien, qui a gagné deux fois en justice contre le constructeur ASUS (lire le commentaire détaillé de la décision de justice par Me Frédéric Cuif), s’exprime dans le journal télévisé 19-20 de France 3 Bretagne le 21 décembre 2009 : Un Morbihannais en lutte contre Windows, par Géraldine Lassalle.

—> La vidéo au format webm

Transcript

Voix off : C’est un combat semblable à celui de David contre Goliath. Dans le rôle de David, Éric Magnien, régiseur de théâtre lorientais, dans le rôle de Goliath, le fabricant d’ordinateur Asus. Tout commence en mai 2008 quand Eric décide de s’acheter un ordinateur.

Éric Magnien : Je voulais acheter un ordinateur, mais je ne voulais pas des logiciels qui étaient installés avec, parce que j’utilisais déjà avec un autre ordinateur des logiciels libres, donc sous Linux.

Voix off : Pourtant Éric n’a pas le choix. il doit acheter l’ordinateur avec avec le système d’exploitation de Microsoft déjà installé. Il décide alors de demander au constructeur le remboursement des logiciels Windows dont il n’a pas besoin.

Éric Magnien : Il me demandait à ce que je renvois l’ordinateur à mes frais, à leur service après-vente à Paris, pour effacer totalement le disque dur et enlever l’étiquette de Windows. Donc c’était totalement inacceptable, pour un remboursement de 40 euros alors que dans le commerce ces mêmes logiciels coutaient 205 euros.

Voix off : S’engage alors une bataille juridique qui va durer plus d’un an. Avec l’aide de l’Association Francophone des Utilisateurs de Logiciels Libres (AFUL), Éric rassemble tous les elements demontrant l’abus dont il est victime. Face à lui une armée d’avocats experts, un combat inégal mais Éric sait qu’il est légitime. En août 2009 la justice condamne le constructeur.

Éric Magnien : C’est une procédure longue, difficile mais nécessaire, et qui vaut le coup parce que c’est notre droit. On a le droit d’obtenir réparation de ce genre de choses, on a le droit d’obtenir le remboursement de ces licences. Et donc c’est aussi pour une certaine idée du droit, de la justice, que j’ai été jusqu’au bout de la démarche.

Voix off : La décision de justice rendu par le tribunal de Lorient pourrait bien décider d’autres consommateurs à faire valoir leurs droits. Le 2 décembre dernier, la société Acer a été condamnée pour la cinquième fois pour des faits similaires.

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.

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.