Si vous avez le malheur de développer un projet « open source » au sein de votre entreprise alors vous courrez le risque de voir arriver une « communauté » qui peut à tout moment s’agréger autour du code source de votre logiciel et en menacer sa bonne gouvernance.

Heureusement le développeur Josh Berkus est là pour vous expliquer point par point comment faire pour être certain de ruiner et dissoudre toute velléité communautaire (au cours d’une intervention donnée il y a un mois à la Linux.Conf.au et relatée ici par Jonathan Corbet)^[1].

Un article évidemment ironique (qui détourne les howto), mais qui donne à réfléchir sur les relations subtiles et complexes qui peuvent exister entre les communautés et les entreprises qui œuvrent sur un même projet.

Pas toujours facile de se comprendre en effet quand les uns disent plutôt « logiciel libre » et les autres plutôt « open source » (voire même parfois carrément « fauxopen source »).

Et puis, c’est pratique, puisqu’on dispose ainsi de tout ce qu’il ne faut pas faire pour réussir un projet communautaire.

On notera que Josh Berkus avait la société Sun Microsystems en tête lorsqu’il a énoncé son propos (Sun soutient notamment MySQL et OpenOffice.org). Mais comme il le précise lui-même a posteriori sur son blog, cela peut s’appliquer à n’importe quelle « corporate open source » et de citer alors entre autres Red Hat, Microsoft, IBM, Cisco, SugarCRM, Novell, Compiere, Borland, Google, ou encore Apple. « Si vous avez à faire à une compagnie qui possède un projet open source, vous pouvez être sûr à 95% qu’elle suit au moins un des dix points mentionnés ci-dessous »

Et de conclure positivement sur la nécessité de cultiver l’un des mots clés les plus importants de la communauté : la confiance.

Comment détruire votre communauté : mode d’emploi

How to destroy your community

Jonathan Corbet – 18 janvier 2010 – LWN.net
(Traduction Framalang : Olivier, Daria et Don Rico)

Le réputation de Josh Berkus en tant que hacker de PostgreSQL n’est plus à faire, mais ce n’est pas sa seule compétence, puisqu’il a aussi acquis une précieuse expérience durant sa pige au « Laboratoire de Destruction des Communautés », plus connu sous le nom de Sun Microsystems. Il y a suivi « l’enseignement breveté en 10 étapes » pour apprendre à débarrasser un projet de toute ingérence de la communauté.

La présentation très dynamique qu’a donnée Josh à la Linux.Conf.au sur le sujet était la première discussion de la miniconf L’économie de l’open source ; l’audience lui a réservé un accueil chaleureux.

Si vous êtes développeur dans une grosse entreprise, vous vous rendrez rapidement compte que les communautés de développement des logiciels libres sont une plaie. Dites adieu à vos plans marketing, par exemple, car elle se chargera d’introduire le logiciel dans des pays où vous êtes absents et pour lesquels vous n’avez pas de plan. Ils flanqueront par terre vos prévisions produits en sortant des innovations non-prévues, en implémentant des fonctionnalités des années avant ce que vous aviez planifié, ou pire encore, des fonctionnalités qui devaient être réservées à la version propriétaire de votre logiciel. Les communautés de logiciels libres sont d’éternelles insatisfaites, elles n’ont de cesse de vouloir améliorer les choses. Elles ont tendance à redéfinir les relations avec vos partenaires et vos clients, et vos commerciaux ne savent plus à quel saint se vouer. Et sans arrêt elles vous dérangent : un e-mail par ci, une conférence à laquelle vous devriez assister par là, etc.

Mais heureusement, des solutions existent pour vous débarrasser de la menace que représente cette communauté. Il suffit d’appliquer une ou plusieurs des étapes suivantes.

1. Rendez le projet dépendant d’outils complexes

Il a remarqué qu’en général, les entreprises n’ont pas de problème avec cette technique puisqu’elles aiment s’appuyer sur leurs propres outils. Pour les projets où la communauté n’est pas la bienvenue, il faut par exemple employer des systèmes singuliers qu’on ne trouve nulle part ailleurs. Un système de contrôle de version propriétaire (NdT : version control system) est absolument obligatoire. Mieux encore, un outil de suivi des problèmes (NdT : issue tracking system) avec un nombre limité de licences, afin que tout le monde doive s’y connecter avec le même compte.

N’oubliez pas de mettre en place un site Web qui respecte la parité : 50% du temps planté, 50% du temps opérationnel. Ne pas mettre de site à disposition ne suffira pas : dans de telles situations, la communauté a la fâcheuse habitude de créer le sien. Avec un site bancal, en revanche, vous vous en prémunirez et vous assurerez que l’information restera bien cachée.

2. Attirez les participants nocifs et optimisez les dégâts qu’ils peuvent engendrer

Ce cas particulier nécessite quelques étapes :

1. Prenez sur vous et engagez-vous dans de longs débats avec ces personnes et dénoncez-les sur les listes du projet.
2. Au bout d’un certain temps, bannissez-les par décret ; évitez à tout prix tout processus communautaire.
3. Les gens bannis déverseront leur bile ailleurs. Vous devez les suivre et poursuivre votre débat sur ces sites externes.
4. Enfin, la communauté se plaindra de ce comportement. Votre réponse sera simple : réintégrez les enquiquineurs à la communauté. Reprenez à la première étape et recommencez.

D’après Josh, un casse-pieds bien pris en main peut annihiler une communauté de plusieurs centaines de membres.

3. Ne fournissez pas de documentation

Aucune information utile ne devrait être disponible, ni pour le code, ni sur les méthodes de compilation, rien sur le processus de soumission de correctif, ni sur le processus de sortie, rien de rien. Puis, quand on demandera de l’aide, répondez « Lis la notice, bordel ! » (NdT : RTFM pour Read the fucking manual)

4. Prenez les décisions relatives au projet en petit comité

Pour bien commencer, vous pouvez organiser vos réunions en ligne en ne prévenant les participants que très peu de temps à l’avance. Pour que cette technique soit vraiment efficace, prévoyez ces réunions à des heures incompatibles avec le fuseau horaire commun à la plupart des membres de la communauté.

Le mieux est encore de tout faire en visioconférence : vous exclurez de fait environ un tiers de la planète pour qui elle se déroule de nuit, de plus, les gens ont un boulot, tant pis pour eux aussi. Mais le must reste encore d’organiser les réunions en personne au siège de la société.

5. Sortez la grosse artillerie juridique

S’impliquer dans le projet devrait rimer avec accords de participation alambiqués, contrats de licence protégeant le contenu du site Web, accords de confidentialité, marques déposées, etc. Pour ne pas faire les choses à moitié, tous ces documents devraient être modifiés en catimini à peu près tous les deux mois.

6. Choisissez avec soin l’agent de liaison avec la communauté

Votre meilleur candidat : quelqu’un de solitaire, quelqu’un qui n’a pas d’amis et qui n’apprécie pas vraiment les autres. Si vous n’en avez pas sous la main, prenez le membre de votre équipe qui a le plus de travail, quelqu’un avec des responsabilités en développement et en gestion, et qui travaille déjà au minimum 70 heures par semaine. Dans ce cas, il est primordial de ne pas le décharger de la moindre de ses responsabilités.

Quelqu’un qui ne maîtrise pas la technologie fera aussi l’affaire. Prenez un spécialiste de Java pour assurer la liaison dans un projet en Perl. Ou, si vraiment ces solutions ne sont pas possibles, laissez simplement la place vacante pendant des mois.

7. Rendez opaques les prises de décision

Les entreprises réfractaires aux communautés devraient, d’après Josh, s’inspirer des Nations Unies et créer des processus longs et complexes. Personne ne doit savoir qui prend réellement les décisions, c’est très bon pour transformer les contributeurs en éléments nocifs. Il va de soi que les règles devraient être immuables ou presque.

8. Faites n’importe quoi avec les licences

Les membres de la communauté étant souvent à cheval sur la question des licences, modifiez la licence et vous avez de bonnes chances de les faire fuir. Évoquer des changements de licence sans jamais vraiment rien modifier peut se révéler encore plus efficace : vous faites fuir les contributeurs actuels qui apprécient la licence choisie sans pour autant en attirer d’autres, adeptes eux de la future licence supposée.

9. N’accordez jamais, au grand jamais, l’accès au commit à quelqu’un d’extérieur à l’entreprise

Ce devrait être une règle (tacite évidemment) : seuls les employés peuvent avoir les droits de commit (NdT : avoir ces droits revient à avoir accès et contrôle sur le code source du dépôt officiel du logiciel). Vos réponses doivent être évasives, « problèmes légaux, on y travaille » est une bonne carte à jouer. Afin que cette mesure prenne tout son effet, choisissez un employé qui n’écrit pas de code et confiez lui l’accès au commit sur le projet.

10. Réfugiez-vous dans le silence

Laissez les questions sans réponse, ne dites rien. Maîtriser cette technique peut rendre, à elle seule, toutes les autres inutiles. C’est le meilleur moyen de détruire une communauté qui existe.

En conclusion, Josh ajoute que grâce à Sun, il peut témoigner de l’efficacité de toutes ces techniques. Mais Sun est loin d’être la seule entreprise dans cette situation. Un ancien du X Consortium a avoué à Josh qu’eux aussi avaient un jour recouru à chacune de ces méthodes. Ces compétences de destruction de communauté sont monnaie courante dans l’industrie du logiciel.

Mais que faire si votre entreprise veut au contraire se bâtir une communauté ?

Il paraît évident qu’elle devrait alors s’employer à appliquer à l’inverse les méthodes énumérées ci-dessus. Mais d’après Josh, la clé de voûte du système reste la confiance. À l’instar du mariage, développer une communauté peut prendre des années, mais une seule infidélité détruira la confiance qui en constitue le socle. Ainsi, une entreprise peut perdre la moitié de sa communauté en un week-end. Pour ne pas connaître ce triste sort, il faut avoir confiance en la communauté et agir de sorte que cette confiance soit réciproque.

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.

La Quadrature va-t-elle jetter l’éponge ? C’est le cri qu’a poussé Benjamin Bayart hier sur son blog.

Rien de tel que de se remémorer alors son intervention, en juillet dernier aux Rencontres Mondiales du Logiciel Libre de Nantes, où il explique pourquoi La Quadrature a besoin de notre soutien.

Et de laisser ensuite la parole à un Jérémie Zimmermann éloquent quant au sens donné à leur action : « S’appuyer sur notre expertise pour écrire la doc et les pages man de l’outil que l’on a bâti et que l’on veut préserver : Internet ».

PS : Et comme on ne peut plus s’en passer, il y a également une vidéo bonus de Stallman en fin d’article 😉

—> La vidéo au format webm

Transcript

Jérémie Zimmermann : Je pense que les sociologues, ethnologues et autres bidulogues se pencheront sur la question, s’ils ne le font pas déjà. De voir que c’est nous, la bande de geeks, qui allons retourner les parlements.

Alors nous la bande de geeks, on est ceux qui connaissons le mieux Internet, ceux qui l’utilisons tous les jours depuis plus longtemps que tout le monde, et ceux qui en quelque sorte l’avons fabriqué. Et donc on peut dire sans se vanter qu’on a une expertise en la matière, un expertise en matière d’Internet et des technologies numériques.

Et c’est intéressant de voir que l’on utilise spécifiquement notre expertise dans quelque chose que l’on a bâti. Pour le préserver tel qu’on le connaît aujourd’hui et tel qu’on aime à l’utiliser aujourd’hui.

Et j’aimerais me livrer ici a un parallèle peut-être un petit peu hasardeux. Je sais que pas grand monde aime la politique, ou en tout cas la politique telle qu’elle existe aujourd’hui, à base de spectacle et de petites phrases, de connards bronzés qui ne connaissent pas leurs dossiers et qui raisonnent à coups de sondages, etc.

Mais la politique, la vraie, c’est pas ça. C’est s’intéresser à la vie de la cité. Et pour s’intéresser à la vie de la cité, pour participer, il faut précisément transmettre son expertise, transmettre sa connaissance.

Et donc notre rôle, ce que l’on fait tous les jours dans ces campagnes, on transmet l’expertise que l’on a de l’outil que l’on veut préserver.

Mais transmettre de l’expertise, c’est un petit peu de la communication, et c’est un petit peu un truc que les geeks ne savent pas bien faire en général.

Et le parallèle hasardeux que je vais faire, c’est dire qu’en gros ce que l’on est en train de faire. c’est faire la doc et faire les pages man qui vont avec l’outil qu’on a développé.

Et que nous les geeks, on sait qu’on n’aime pas faire les pages man, et qu’on n’aime pas rédiger la doc. Et le problème c’est que si on ne les fait pas, le projet ne va pas décoller et il n’ira pas très loin. Et donc voilà, à vos éditeurs de texte quoi !

Benjamin Bayart : On ne peut pas laisser les parlementaires écrire tout seul le manuel d’Internet, ça ça va pas être bon, va falloir qu’on s’en mêle…

Soutien de Richard Stallman à La Quadrature du Net

—> La vidéo au format webm

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.

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.

Migration et complémentarité obligent, la collaboration entre Ubuntu-fr et Framasoft ne date pas d’hier. Elle a débuté par des ponts constants entre nos deux forums et des stands communs sur le terrain, s’est poursuivie avec le projet du framabook Simple comme Ubuntu, pour atteindre un premier point d’orgue l’été dernier avec la sortie de la Framakey Ubuntu-fr Remix (ou FUR).

La sortie de cette clé précédant de quelques jours les Rencontres Mondiales du Logiciel Libre de Nantes, nous avons alors décidé de prendre le risque de quitter l’immatériel pour proposer sur nos stands une vraie, et ma foi fort jolie, Framakey à nos deux couleurs. Opération réussie, le défi ludique étant de savoir qui du stand Framasoft ou Ubuntu-fr en vendrait le plus (il me semble que c’est Framasoft qui a gagné, mais d’une courte tête !).

Nous avons réitéré l’expérience aux récentes Ubuntu Party de Paris et de Toulouse, avec le même succès (là c’est Ubuntu-fr qui a largement gagné, mais c’est normal « on jouait à l’extérieur » !).

Tout ça pour dire que nous avions mis un pied dans le processus de vente d’objets physiques. Et comme les deux associations proposaient également, depuis un certain temps déjà, des tee-shirts et autres goodies (mais là encore uniquement lors des évènements), nous nous sommes dits : et pourquoi pas ouvrir une petite boutique commune sur Internet ?

Question d’autant plus opportune que tout le monde ne peut pas forcément se rendre à ces manifestations et que nous recevions de nombreux mails nous demandant justement si il était possible d’acheter en ligne une clé ou un tee-shirt.

Ce souhait se concrétise aujourd’hui avec l’ouverture du site EnVenteLibre.org (ou EVL pour les intimes).

Graphiquergonomiquement parlant, on peut certainement améliorer la chose (on dira que c’est la version 0.1 ou 1.0 du site), mais c’est déjà bien en place, fonctionnel, et testé confidentiellement avec succès par une première vague d’acheteurs que l’on remercie au passage.

Vous remarquerez que ne l’avons pas appelé « FramaTruc » comme nous en avons pris la mauvaise habitude (ici ça aurait pu être « FramaShop » par exemple), mais un nom indépendant de nos deux associations. Vous remarquerez également que chaque association à son onglet sur le site, il est donc potentiellement possible d’accueillir d’autres structures, mais nous n’en sommes pas là…

Cette boutique existe donc d’abord pour répondre à la demande de ceux qui n’ont pas l’occasion de nous rencontrer in the real life. Ceux qui souhaitent se lever le matin un tee-shirt Ubuntu ou Framasoft sur le dos et se réveiller en douceur avec un bon café (ou thé) fumant dans un magnifique mug Ubuntu. Si c’est trop chaud vous pourrez alors poser votre tasse sur la non moins magnifique soucoupe constituée par le CD d’Ubuntu ou le FramaDVD (mais on me souffle dans l’oreillette que ces soucoupes peuvent également servir à autre chose). Et de partir alors au turbin, le sourire aux lèvres et la clé en bandoulière…

Mais redevenons plus sérieux. Cette boutique nous permet aussi et surtout de continuer à diffuser le logiciel libre au plus large public. En effet, avant la boutique, il fallait être capable de télécharger patiemment l’image d’un CD ou DVD et de le graver. Pour la FUR c’était encore plus compliqué : acheter une clé vierge de bonne qualité (nous insistons sur ce point), télécharger le pack, l’installer et rendre la clé bootable sous Ubuntu. Avec la boutique, on peut donc recevoir ces objets optimisés et directement prêts à l’emploi, et nul doute que cela élargira le spectre des personnes souhaitant découvrir et utiliser des logiciels libres (d’autant que nous sommes capables de livrer partout dans le monde).

Enfin il s’agit également de voir si à terme cela peut constituer une éventuelle source de financement pour nos deux associations. Fidèles à une certaine approche des choses, nous avons choisi de ne pas marger outre mesure sur des prix volontairement tirés vers le bas pour les rendre les plus attractifs possibles (sachant que comme nous produisons en petite quantité nous ne pouvons pas obtenir des tarifs de gros préférentiels). Mais, originalité, nous invitons à compléter les achats par un don de votre choix à l’une et/ou l’autre^[1] association si vous souhaitez soutenir et encourager leur action.

Sans vouloir être grandiloquents, proposer de « soutenir librement » en même temps que l’on « consomme » nous semble être un modèle intéressant à explorer participant, qui sait, à dessiner les contours d’une future et salutaire société de la contribution. Et lorsque nous ferons les premiers bilans, nous aimerions beaucoup pouvoir témoigner du fait que l’un est souvent allé avec l’autre (pour la bonne santé des caisses de nos associations, mais aussi pour l’exemple à valeur de symbole).

Ces premiers bilans seront l’occasion d’envisager l’avenir (ou non) de ce projet. Et en attendant c’est avec modestie mais enthousiasme que nous vous proposons déjà une petite sélection de produits qui s’étofferont avec le temps si le succès est au rendez-vous.

Quant à la Framakey Ubuntu-fr Remix, si vous en voulez une sous votre sapin (ou celui de vos proches), dépêchez-vous de vous rendre chez EnVenteLibre.org ! Sur les 280 proposées, il n’en reste en effet déjà plus que 160…

PS : Tout le monde a mis la main à la pâte, mais ce projet n’aurait jamais pu voir le jour sans le travail acharné de notre salarié Pierre-Yves Gosset (si vous le croisez, parlez-lui un peu des obstacles légaux, fiscaux, techniques et logistiques qu’il aura fallu surmonter, réaction assurée !). Qu’il en soit ici chaleureusement remercié, et avec lui tous les donateurs qui nous permettent de maintenir ce salarié.

L’actuelle campagne de soutien des Creative Commons (CC) bat son plein. Elle vise à récolter un demi-million de dollars avant le 31 décembre. Inutile de vous dire que nous vous encourageons vivement à participer, si vous pensez, comme nous, que ces licences font partie de ce qui est arrivé de mieux à l’Internet au cours de la présente décennie.

À cette occasion, il a été demandé à des personnalités utilisant les CC de témoigner en rédigeant une Commoner Letter. C’est la première de ces lettres que nous avons traduit ici, faisant directement écho à un billet de janvier dernier où nous évoquions l’inauguration par Al Jazeera d’un dépôt d’archives vidéos sous licence Creative Commons^[1].

Rendez-vous l’an prochain pour la lettre de TF1 ?

Commoner Letter #1 : Mohamed Nanabhay de la chaîne Al Jazeera

Commoner Letter #1: Mohamed Nanabhay of Al Jazeera

7 octobre 2009 – Blog Creative Commons
(Traduction Framalang : Olivier Rosseler et Yostral)

Introduction de Allison Domicone (Creative Commons)

J’ai le plaisir de vous annoncer le lancement de notre série Commoner Letter annuelle, une série de lettres rédigées par des membres importants de la communauté des CC pour appuyer notre campagne de soutien pour les CC. Mais cette campagne ne vise pas qu’à lever des fonds, nous voulons que cela soit bien clair. Nous cherchons avant tout à faire connaître plus largement les CC et à militer pour le partage en ligne et la culture collaborative.

Je suis donc fier de vous annoncer la parution de la première Commoner Letter, de Mohamed Nanabhay, directeur du développement en ligne pour Al Jazeera English. Mohamed et Al Jazeera ont offert une visibilité à l’international aux CC grâce au travail incroyable qu’ils ont founi cette année. Comme vous le savez peut-être déjà, Al Jazeera a lancé plus tôt dans l’année un dépôt Creative Commons qui héberge des rushes vidéo que tout le monde peut partager, réutiliser et remixer. Avoir un tel allié chez Al Jazeera est un honneur et j’espère que vous apprécierez le témoignage personnel que nous livre Mohamed sur son attachement aux Creative Commons.

Lettre de Mohamed Nanabhay (Al Jazeera)

Cher Creative Commoner,

L’année a été riche pour Al Jazeera et sa relation avec les Creative Commons. En janvier nous avons inauguré le premier dépôt mondial de vidéos professionnelles placées sous licence Creative Commons 3.0 Attribution (CC BY). Nous avions alors libéré une sélection de séquences filmées par Al Jazeera, des rushes sur la guerre à Gaza, permettant ainsi à tout le monde de les télécharger, de les partager, de le re-mixer, de les sous-titrer et finalement de les rediffuser, que l’on soit un particulier ou une chaîne de télévision, à la seule condition que nous soyons crédités pour la vidéo.

Embrasser la culture libre, c’est avant tout accepter que l’on renonce au contrôle en échange de quelque chose de plus grand : son appropriation par la communauté créative. Vous ne savez donc jamais vraiment où tout cela va vous mener. À l’origine, quand nous avons inauguré notre dépôt, nous pensions mettre là à disposition des ressources pertinentes pour quelqu’un désirant produire du contenu sur la guerre et qu’elles seraient principalement utilisées par d’autres chaînes d’informations et des réalisateurs de documentaires.

Le résultat fut à la fois surprenant et enthousiasmant. À peine nos vidéos furent-elles en ligne que déjà des contributeurs de Wikipédia en extrayaient des images pour compléter les articles sur le guerre de Gaza. Et rapidement, enseignants, créateurs de films, développeurs de jeux vidéos, organisations humanitaires et producteurs de clips musicaux s’inspirèrent de nos images. Cet accueil chaleureux de la communauté de la culture libre nous conforta dans notre choix.

Joichi Ito, président de Creative Commons dit au lancement : « Les séquences d’informations filmées sont l’un des pilliers du journalisme moderne. Rendre ainsi disponibles sous licence Creative Commons ces images, pour des usages amateurs et commerciaux, est une contribution fantastique au dialogue mondial autour d’évènements importants. Al Jazeera montre l’exemple et sera, nous l’espérons, imitée par beaucoup d’autres. »

Lancer un projet ne suffit pourtant pas à générer une communauté, un engagement à long terme et des valeurs communes sont nécessaires. Notre association avec Creative Commons remonte à 2007, lorsque Lawrence Lessig, fondateur des Creative Commons, a donné son discours d’introduction lors du 3ème Al Jazeera Forum à Doha, au Qatar. Dans ce discours il nous mettait au défi de libérer nos contenus afin de renforcer la liberté d’expression. Ce défi, nous l’avons relevé, en plus de notre dépôt Creative Commons, nous rendons également disponible nombre de nos reportages sur notre chaîne dédiée sur Youtube.

Après le lancement de notre dépôt, nous avons co-animé un atelier avec Creative Commons ayant pour titre « Créer des projets médias dans des réseaux ouverts », dont l’animation était assurée par le directeur de Creative Commons, Joichi Ito. Cet atelier fut diffusé en direct dans tout le Moyen-Orient dans le cadre de notre 4ème Al Jazeera Forum, qui s’est tenu en mars 2009. Cet évènement mondial a rassemblé près de deux cents journalistes, analystes, universitaires et intellectuels.

Grâce aux licences Creative Commons nous touchons un public plus large, mais la portée de notre projet est mieux résumé par ce commentaire de Lawrence Lessig : « Al Jazeera nous donne une leçon importante de promotion et de défense de la liberté d’expression. En offrant une ressource libre et gratuite au monde, le réseau encourage l’extension du débat et sa plus grande compréhension. »

La collaboration avec Creative Commons a été très enrichissante. Nous sommes reconnaissants envers Lawrence Lessig, Joi Ito et toute l’équipe qui œuvrent à la diffusion de la liberté d’expression pour leur aide, leurs conseils et leur soutien.

La collaboration involontaire qui s’est développée après que nous ayons ouvert notre dépôt de vidéos, ainsi que le bon accueil que ce dernier a reçu dans le monde entier, n’auraient pas été possible sans l’aide des licences Creative Commons. Nous apportons notre soutien à leur campagne car nous avons été témoin, et nous le sommes toujours, des bienfaits de l’enrichissement et du renforcement des communs numériques. J’espère que vous aussi, selon vos possibilités, vous apporterez votre soutien aux CC en renforçant ainsi les biens communs. Je vous conseille vivement de vous lancer et d’utiliser vous aussi les licences Creative Commons.

Sincèrement,

Mohamed Nanabhay
Directeur du développement en ligne, Al Jazeera English

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.