Navigation – Plan du site
Marchés ou communs ? Critères d’arbitrage

Le contrôle des communs numériques à des fins commerciales : le cas des logiciels libres

Stéphane Couture

Résumés

Cet article aborde les formes de contrôle des biens communs par des entreprises commerciales en étudiant le cas des logiciels libres. Les logiciels libres sont des logiciels dont le code source est librement accessible, et peut être modifié et partagé. Cette éthique de partage a permis l’émergence d’un modèle collaboratif souvent présenté comme l’exemple type des « communs numériques ». Cependant, de plus en plus d’entreprises participent aujourd’hui au développement des logiciels libres. Si plusieurs analystes voient d’un bon œil cette contribution commerciale, d’autres font ressortir les formes de contrôle que ces entreprises mettent en place pour tirer profit des communs en logiciels libres. En recensant différentes études sur ces questions et en analysant plus précisément les cas de Symfony et de Redhat, deux logiciels libres fortement développés par des entreprises commerciales, le présent article s’attarde sur ces formes de contrôle des communs numériques et en fait ressortir les conséquences éthiques.

Haut de page

Texte intégral

Introduction : les logiciels libres comme forme de bien commun

1Les logiciels libres sont des logiciels dont la licence permet le partage, l’étude, la modification et l’amélioration de leur code source. Le terme de logiciel libre a été lancé dans les années 1980 par Richard Stallman, qui a établi les bases éthiques et normatives de la philosophie des logiciels libres. Ces idées ont suscité l’intérêt de nombreux informaticiens et programmeurs, et ont permis la création de plusieurs logiciels libres matures et performants, aujourd’hui largement adoptés. C’est le cas des nombreux dispositifs permettant la réalisation et le fonctionnement de sites web, ou encore du noyau Linux, utilisé dans la majorité des serveurs sur Internet, téléphones portables, routeurs ou microcontrôleurs de toute sorte. Vers la fin des années 1990, des entreprises ont cherché le moyen de tirer profit de ces nouvelles formes d’innovation. C’est à ce moment qu’en anglais le terme open source a été créé pour remplacer celui plus militant de « logiciels libres », et ainsi favoriser une rhétorique plus familière aux entreprises commerciales. Depuis, bon nombre d’entreprises telles qu’IBM, Google, RedHat, Oracle Google et plus récemment, Microsoft, ont orienté leur stratégie d’affaires pour appuyer et profiter des formes de collaboration à l’œuvre dans les communautés de logiciels libres.

2De nombreux articles scientifiques ont été réalisés sur la question des logiciels libres, par exemple sur les valeurs « hackers » des acteurs impliqués dans ces projets (Auray, 2000 ; Coleman, 2012 ; Broca, 2013), ainsi que sur les formes de régulation qui assurent leur cohésion (Demazière, Horn, et Zune, 2007). Dans une perspective plus économique, plusieurs auteurs se sont également interrogés sur ce qui amenait les développeurs de logiciels libres et les entreprises à contribuer – parfois gratuitement – aux logiciels libres (Lee, Moisa, et Weiss, 2003; Lerner et Triole, 2000). Von Hippel (2007), puis Cardon (2005) ont analysé les formes d’innovation par l’usage, ou « ascendante », sous-jacentes à ces projets. D’autres auteurs ont analysé, dans une perspective critique, l’articulation entre la production du logiciel libre et le capitalisme contemporain (Coris, 2006 ; Moullier-Boutang, 2007 ; Dafermos et Söderberg, 2009 ; Birkinbine, 2014).

3Les logiciels libres ont été explicitement abordés sous l’angle des biens communs par divers auteurs (Aigrain, 2005 ; Benkler, 2003 ; Boyle, 2008 ; Lessig, 2006 ; Schweik, 2007). Aigrain considère ainsi le mouvement du logiciel libre comme un moment phare de l’élaboration du paradigme de l’information comme bien commun, qu’il oppose à celui de l’information comme propriété (Aigrain, 2005). Benkler, dans son livre The Wealth of Networks (Benkler, 2006), analyse les formes collaboratives émergentes telles que Wikipédia et les logiciels libres, en les définissant comme des formes de production pairs à pairs, basées sur les biens communs (Commons-based peer production). Ces projets, écrit l’auteur, ne s’appuient pas sur l’usage exclusif, typique des rapports de propriété, mais plutôt sur des formes institutionnelles qui permettent à toutes et à tous d’accéder aux ressources communes et de partager les résultats du travail. Pour Benkler, ces pratiques des biens communs constituent un nouveau paradigme économique qui émerge au cœur de l’économie capitaliste.

4Elinor Ostrom, en collaboration avec Charlotte Hess, a également abordé les logiciels libres dans ses derniers travaux. Récipiendaire du prix Nobel d’économie, Ostrom s’est particulièrement fait connaître pour ses analyses empiriques et économiques des biens communs. Ses travaux font contre-pied à la vision notamment développée par Hardin sur la « tragédie des communs » (Hardin, 1968), selon laquelle les biens communs sont voués à la surexploitation à moins d’être nationalisés ou privatisés. À travers de nombreuses études empiriques, Ostrom rend compte au contraire de la capacité d’auto-organisation des communautés pour préserver et enrichir les biens communs, et ce, sans recourir à des modes d’organisation privatifs ou étatiques. Ostrom insiste ainsi sur le fait que les biens communs ne devraient pas être analysés simplement en tant que ressources, mais surtout dans leur relation avec les groupes sociaux qui prennent part à leur production ou leur maintien. Ce n’est donc pas tant le caractère intrinsèque d’une ressource qui la définirait comme un bien commun, mais plutôt sa forme de gouvernance « commune », distincte à la fois de la privatisation et de l’étatisation.

  • 1 Dans le cas des communs numériques, le déclin n’est pas tant lié à leur surutilisation qu’à leur ab (...)

5Ostrom et Charlotte Hess ont analysé plus particulièrement les communs de la connaissance, comme les articles scientifiques, les œuvres culturelles (musique, théâtre) et les œuvres numériques comme Wikipédia ou les logiciels libres (Hess et Ostrom, 2007). Ces « nouveaux communs » se distinguent des biens communs naturels ou matériels – étudiés précédemment par Ostrom – par le fait qu’ils ne sont pas rivaux, c’est-à-dire que leur utilisation par les uns ne diminue pas la valeur des biens ou n’entrave pas leur utilisation par les autres (au contraire d’un potager, par exemple, où une cueillette par les uns réduit le nombre de légumes disponibles pour les autres). Par leur gestion communautaire, les « biens communs numériques » continuent toutefois de se distinguer à la fois des biens publics et des biens privés, comme c’est le cas des biens communs matériels1.

6Les biens de la connaissance ou numériques sont particulièrement vulnérables aux « enclosures ». Issu de l’anglais, le terme « enclosure » désigne des dynamiques de privatisation et d’appropriation de ce qui était auparavant une ressource commune. Dans le cas des biens de la connaissance ou numériques, les enclosures se traduisent surtout par l’imposition d’un droit de propriété intellectuelle exclusif défendu par différents mécanismes légaux, notamment par l’augmentation des amendes et des peines en cas de violation, ou technologiques, par l’intermédiaire de la gestion numérique des droits (Digital Rights Management – DRM) qui limite la diffusion du contenu ou encore par les murs payants empêchant d’accéder à certains contenus en ligne. Ces enclosures tentent de créer une exclusivité artificielle sur une ressource dont la non-rivalité se prête davantage au partage. À l’inverse, selon Hess et Ostrom, les initiatives comme les logiciels libres contribuent à l’accessibilité et la robustesse des biens communs de la connaissance. Toutefois, connaissant l’intérêt des entreprises commerciales pour les logiciels libres, existe-t-il d’autres dynamiques de contrôle voire d’enclosure des biens communs qui ne se feraient pas sur le mode du renforcement des droits exclusifs de propriété ?

7L’argument principal de ce texte est que des formes de contrôle, que l’on pourrait associer à de nouvelles formes d’enclosures, se mettent en place aujourd’hui autour des logiciels libres. Ces formes de contrôle, tout en respectant le principe du libre accès au code source, s’apparentent davantage à des modes de gouvernance plus typiques de l’entreprise privée qu’à ceux de l’économie des biens communs. Dans les prochaines sections, j’analyserai ces formes de contrôle pour deux cas spécifiques de logiciels libres : Red Hat et Symfony. Je poursuivrai et aborderai ensuite certains enjeux éthiques liés au rôle des entreprises privées dans le monde du logiciel libre, en particulier en ce qui a trait à la canalisation du travail gratuit.

Contrôle et gouvernance privative des logiciels libres

8Différentes analyses se sont attardées, dans une perspective critique, au rôle des entreprises privées dans le monde du logiciel libre. Plusieurs articles ont par exemple analysé la manière dont les entreprises réussissent à canaliser le travail gratuit des bénévoles pour soutirer du profit (Dafermos et Söderberg, 2009; Broca 2013), un aspect sur lequel je reviendrai plus loin. Pour Moulier-Boutang, les logiciels libres et open source seraient représentatifs d’un capitalisme cognitif et post-industriel où l’entrepreneuriat consisterait « à convertir la richesse déjà là dans l’espace virtuel du numérique en valeur économique » (Moulier-Boutang, 2007 : 167, cité par Broca, 2013 : 244). Analysant ces engagements des entreprises dans le monde du logiciel libre, Coris (2006) y voit pour sa part un exemple d’« absorption par la sphère marchande ». Elle s’attarde plus spécifiquement sur le cas, dans le contexte français, des Sociétés de services en logiciels libres (SS2L), créées au début des années 2000. Les SS2L se voulaient en opposition aux Sociétés de services en ingénierie informatique (SSII), qui à ce moment n’incluaient pas les logiciels libres dans leur offre. Coris note cependant que la plupart des projets de SS2L se sont avérés des échecs, certains ayant mis la clé sous la porte, d’autres ayant été rachetés par les SSII traditionnelles, et le reste ayant reformulé radicalement leurs modèles d’affaires. En parallèle, certains logiciels libres ont été davantage intégrés dans l’offre des SSII en raison de leurs bénéfices, tels que leurs coûts réduits et leur flexibilité. Ainsi, l’émergence d’un contexte industriel favorable aux logiciels libres a contribué à condamner l’approche communautaire des débuts plutôt qu’à la pérenniser. De plus, les logiciels libres intégrés dans les entreprises « traditionnelles » se sont limités la plupart du temps à ceux dont la maturité et la reconnaissance étaient comparables aux logiciels propriétaires similaires. En gros, Coris constate que les logiciels libres sont parvenus à s’imposer au prix d’une certaine industrialisation qui a remis en cause leur modèle « communautaire » :

« Né d’une opposition au système capitaliste – exemplifié par le modèle “propriétaire” de protection de la propriété intellectuelle –, le logiciel libre semble pourtant parvenir à s’imposer : les SSII finissent par être obligées d’intégrer les logiciels libres dans leur offre. En même temps, les SS2L sont, quant à elles, contraintes de s’industrialiser » (p. 21).

9Cependant, les différents essais et analyses participant à la promotion de la théorie des biens communs ont tendance à placer les logiciels libres comme un cas paradigmatique des biens communs numériques, mais à négliger la problématique de l’engagement important des entreprises privées commerciales dans le développement des logiciels libres. Comme je l’ai mentionné, Hess et Ostrom (2007), dans leur ouvrage sur les communs de la connaissance, notent que les initiatives comme les logiciels libres contribuent à promouvoir l’accessibilité des biens communs de la connaissance. Dans un chapitre du même ouvrage portant sur les logiciels libres, Schweik (2011) note bien la participation des entreprises privées dans la production de logiciels libres, mais cette analyse s’avère exclusivement positive plutôt que critique. Plus important, en résumant la composition des communautés de logiciels libres comme étant le fait d’individus – développeurs ou usagers – passionnés ou alors payés par des entreprises (p. 301), l’auteur néglige de considérer la dimension proprement institutionnelle de la participation des entreprises, de même que les mécanismes que celles-ci peuvent potentiellement mettre en place pour contrôler cette production. Mentionnons également ce court billet d’un blogue du Monde diplomatique, où Hervé Le Crosnier (2012) présente le mouvement du libre comme la troisième incarnation de la théorie des communs, sans toutefois mentionner le rôle important des entreprises privées. Dans un autre texte, Le Crosnier (2015) note cependant que les grandes entreprises parmi les plus dominatrices, comme IBM et Google, s’appuient sur les logiciels libres, mais cela est surtout un signe pour l’auteur que « l’écosystème informatique ne [peut] fonctionner sans une innovation répartie, et donc des capacités d’accès et de création à partir des bases communes » (p. 81).

10Si cela est sans doute vrai, il me semble toutefois important d’analyser plus précisément comment les entreprises commerciales réussissent à contrôler le développement et l’usage de ces bases communes. Dans un article sur le site d’actualités sur les nouvelles technologies Ars Technica, Ron Amadeo (2013) critique par exemple le contrôle de Google sur la plateforme Android pour tablettes et téléphones intelligents. Alors que Google avait au départ intégré plusieurs applications en logiciels libres au lancement de sa plateforme Android, elle a depuis cessé de contribuer au développement de la plupart de ces applications pour plutôt développer ses propres versions propriétaires. Ce faisant, l’entreprise rend plus difficile la création d’un système alternatif (basé sur des logiciels libres) qui pourrait reprendre ces applications, ce qui lui permet donc de créer davantage de dépendance vis-à-vis de ses propres services. Google exerce également un contrôle indirect en interdisant aux fabricants d’utiliser ses applications phares (et propriétaires) sur des plateformes Android, dont Aliyum, la version chinoise d’Android, ou encore le Kindle OS d’Amazon, une version non reconnue d’Android. En effet, écrit Amadeo, l’intégration de ces logiciels dans un produit requiert la licence Google Apps. Or, cette licence est plus facilement obtenue en adhérant à l’Open Handset Alliance, qui interdit à ses membres de développer une application sur d’autres plateformes que celles de Google. En d’autres termes, si Google s’appuie sur les logiciels libres pour développer sa plateforme et apporte également une certaine contribution, elle canalise par d’autres moyens les efforts des autres acteurs pour faire de ses technologies une plateforme quasi monopolistique. L’adhésion aux logiciels libres se fait donc par la mise en place de formes de contrôle et d’« enclosure » indirectes qui, tout en respectant le libre accès au code source, en diminue la portée.

  • 2 Les analyses développées dans ce texte ont également été nourries par les discussions sur la liste (...)

11Au-delà du cas spectaculaire de Google, plusieurs entreprises développent des relations se situant entre réciprocité et contrôle des logiciels libres. Dans la suite de ce texte, je vais explorer ces nouvelles formes de contrôle des biens communs, en analysant plus profondément deux cas de logiciels libres (ou open source) principalement développés par des entreprises privées : l’entreprise RedHat et son projet communautaire Fedora, ainsi que le framework web Symfony, utilisé pour construire des sites web et commandité par l’agence parisienne SensioLabs. L’étude du premier cas est basée sur l’analyse que fait Benjamin Birkinbine (2014) dans sa thèse de doctorat. M’inspirant de ces analyses, mon attention pour le second cas se porte sur le projet Symfony, que j’ai étudié dans ma propre recherche doctorale (terminée en 2012). Ces deux cas rendent compte de dynamiques dans lesquelles les entreprises ne sont pas nécessairement clairement prédatrices (comme dans le cas de Google), mais contribuent au contraire significativement au développement des logiciels libres, tout en établissant des moyens de contrôler ce développement2.

12Avant de poursuivre, j’aimerais mentionner que je ne prétends pas à une exhaustivité empirique en ce qui concerne les interactions entre les acteurs de chacun des cas ou même de l’ensemble des logiciels libres. Mes analyses se limitent ici à l’analyse des procédures formelles de gouvernance décrites par les acteurs ou rapportées dans les textes auxquels je fais référence. Comme plusieurs auteurs l’ont mentionné, l’étude de cas en sciences sociales ne permet pas de conclure à des généralisations empiriques ou statistiques (Lincoln et Guba, 2000 ; Latzko-Toth, 2009), mais vise plutôt à être un observatoire permettant de cerner et d’explorer un objet d’étude (Hamel, 1998 : 126-128). Par ailleurs, mon objectif n’est pas non plus de décrier tout engagement des entreprises privées dans la production du logiciel libre. Ma démarche est analytique et consiste à faire ressortir des situations dans lesquelles des formes de gouvernance s’apparentent davantage aux formes « privatives » de régulation des ressources qu’aux formes « communes » décrites par Ostrom. À l’instar de Birkinbine (2014), mon argument est que ces formes de contrôle peuvent être considérées comme de nouvelles « enclosures » respectant néanmoins le principe de libre accès au code source.

Le cas de Redhat et son projet communautaire Fedora

  • 3 Pour la version 4.3 de Linux, publiée en novembre 2015, RedHat était responsable de 18 % des modifi (...)

13Fondée en 1993, l’entreprise Red Hat a établi son siège social à Raleigh, en Caroline du Nord, et compte environ 7 500 employés à travers le monde. Elle est présente en bourse depuis août 1999 et son chiffre d’affaires s’élève à près de 1,4 milliard de dollars américains par année. Red Hat est largement associée au système d’exploitation Red Hat Enterprise Linux, mais l’entreprise a acquis d’autres compagnies opérant dans le domaine de l’open source ainsi que plusieurs autres entreprises de logiciels propriétaires qu’elle a convertis en logiciels libres. RedHat est également aujourd’hui considérée comme l’un des principaux contributeurs du noyau Linux3. Il s’agit donc d’une entreprise phare, reconnue dans le monde des logiciels libres, autant pour ses contributions que pour sa réussite financière. Le modèle d’affaires principal de RedHat consiste à proposer des packages solides de Linux – des distributions – et d’agir comme répondant légal en cas de difficulté avec ces systèmes. En effet, l’un des problèmes soulevés au sujet de l’adoption des logiciels libres par les entreprises et autres organisations, est que celles-ci ne savent pas comment entrer en relation avec une « communauté » de développeurs. RedHat agit ainsi comme intermédiaire en tant qu’entreprise ayant pignon sur rue, mais faisant le pont avec les communautés de logiciels libres.

14L’entreprise visait à l’origine une clientèle large, mais s’est concentrée depuis sur le produit RedHat Enterprise Linux, destiné aux entreprises. Au même moment, elle mettait sur pied un projet « communautaire », Fedora, qui bénéficie des contributions de la communauté. La stratégie d’affaires de RedHat consiste en quelque sorte à reprendre les contributions faites sur le projet communautaire Fedora pour les intégrer dans son produit RedHat Enterprise Linux, qu’elle bonifie pour son public cible. L’un des enjeux pour l’entreprise est donc de s’assurer que le développement et les contributions sur Fedora s’inscrivent effectivement dans l’intérêt commercial de RedHat. Birkinbine (2014) fait ressortir – de trois façons – comment l’entreprise RedHat exerce un certain contrôle sur Fedora, et met ainsi à profit le bien commun dans un but commercial : sur le plan de la gouvernance, sur le plan des contrats de licence des contributeurs, et à travers les marques de commerce.

15Au niveau de la gouvernance, Birkinbine note que RedHat réussit à contrôler efficacement le développement de Fedora en agissant sur la gouvernance du projet. L’orientation de Fedora est en effet contrôlée par le Fedora Project Board, une sorte de conseil d’administration du projet. Au moment de l’analyse, ce conseil comptait neuf membres dont cinq étaient élus par la communauté et quatre étaient nommés par le Fedora Project Leader, un employé de RedHat. Le Project Leader préside également le Fedora Project Board et a un droit de veto sur l’ensemble des décisions du projet. On voit que RedHat peut ainsi conserver une main ferme sur le développement du projet. Birkinbine écrit que la structure de gouvernance du projet Fedora permet à RedHat de diriger le développement du projet communautaire, et de réutiliser, voire de s’approprier, le travail réalisé par la communauté (Birkinbine, 2014 : 93).

16Une deuxième façon de contrôler le développement du projet, selon Birkinbine, est l’utilisation de « contrats de licence des contributeurs » (Contributor License Agreements). Ces contrats ne sont pas des contrats de droits d’auteurs qui obligeraient les contributeurs à délaisser leurs droits, mais établissent certaines balises que les contributeurs conviennent de respecter en participant au projet. Les contributeurs conservent leurs droits sur leurs contributions, mais doivent s’engager à ce que celles-ci ne violent pas les droits d’auteurs, et soient placées sous la licence d’utilisation Fedora ou une autre licence libre jugée acceptable (dont la liste est accessible sur le site web du projet). Cette façon de procéder permet à l’entreprise RedHat de s’assurer que personne ne revendiquera des droits de propriété sur le code inclus dans le projet communautaire, ce qui permet à RedHat d’intégrer ce code dans son offre commerciale.

17Bien que l’entreprise n’utilise pas le droit d’auteur pour conserver le contrôle du code source, elle protège néanmoins sa propriété intellectuelle à travers ses marques de commerce (Trademarks). C’est la troisième façon de contrôler le projet, selon Birkinbine. Les marques de commerce de RedHat comprennent, par exemple, les logos, ainsi que le nom de la compagnie et de ses produits. Les autorisations sur la marque de commerce interdisent également l’utilisation de noms similaires, comme Green Hat, Red Cap, etc. Une reproduction des produits RedHat impliquerait donc un travail important pour supprimer toute référence à ces logos ou produits. Pour Birkinbine, le recours de l’entreprise aux lois sur la marque de commerce lui permet de protéger sa position sur le marché. D’ailleurs, en 2014, RedHat a acquis les marques de commerce de la distribution CentOS, un dérivé de RedHat, en devenant le commanditaire principal du projet, ce que Birkinbine compare à une forme d’intégration horizontale visant à réduire la concurrence.

18Birkinbine note que RedHat peut être vue de deux façons différentes. D’une part, elle peut être vue comme agissant d’une façon pragmatique, comme interface entre les formes de production basées sur le bien commun, et les modalités d’affaires exigées par nos sociétés capitalistes. Il s’agirait donc d’une relation de réciprocité entre l’entreprise et les communautés de logiciels libres, les uns profitant réciproquement du travail des autres. C’est sans doute cette perspective qui fait que la compagnie a bonne réputation dans le monde des logiciels libres. Toutefois, RedHat peut aussi être analysée comme une compagnie comme une autre, qui centralise la production dans une structure corporative, sépare la propriété (ownership) de la paternité (authorship) et utilise à profit la propriété intellectuelle pour protéger ses marques de commerce. La différence principale entre RedHat et les autres entreprises, écrit Birkinbine, est que Redhat n’emploie pas directement sa force de travail, et doit par conséquent s’appuyer sur le maintien de bonnes relations avec la communauté. Je reviendrai plus loin sur cet aspect.

Le cas de Symfony

19Le logiciel Symfony est décrit comme un cadre d’application – un framework en anglais – pour le développement d’applications web. Le logiciel est par exemple utilisé dans le fonctionnement de sites web tels que Daily Motion ou Yahoo Bookmarks, ou encore dans le développement d’autres logiciels, comme Drupal, servant eux-mêmes à la construction de sites web. Symfony a été fondée et est encore aujourd’hui principalement commanditée (sponsored) par l’entreprise française SensioLabs. Basée à Paris, l’entreprise compte quelque 150 employés dans trois bureaux, en France, au Royaume-Uni et aux États-Unis. Au moment de l’analyse (en 2010), environ 500 personnes contribuaient au développement de Symfony.

  • 4 Dans la culture du logiciel libre, le terme anglais de Benevolent Dictator for Life (dictateur bien (...)

20Comme dans le cas de Redhat, l’entreprise (SensioLabs) a établi plusieurs règles pour assurer le contrôle du projet Symfony. Tout d’abord, au niveau de la gouvernance, le projet est fortement contrôlé par l’entreprise. En effet, le développeur principal de Symfony est également cofondateur et président actuel de SensioLabs. Autour de lui, le projet est soutenu par un noyau – la core team – d’une douzaine de personnes. Aucune règle générale de gouvernance en ce qui concerne les prises de décision n’était mentionnée sur le site web au moment de la rédaction de cet article. On précise toutefois qu’aucun nouveau membre de la core team n’était accepté, et que les membres pouvaient être exclus pour absentéisme, mauvaise conduite ou encore sur décision du chef de projet (Upon decision of the Project Leader). En d’autres termes, l’équipe qui mène le développement du projet est cooptée par le dirigeant de l’entreprise commanditaire, qui peut également exclure qui que ce soit à sa guise. On peut évidemment supposer qu’il s’agit là d’une « dictature bienveillante » – pour reprendre un terme courant dans la culture du logiciel libre4 – et que les décisions sont en pratique prises de façon commune. Toutefois, force est de constater que ces règles décrites – et que l’on peut donc supposer ultimes – semblent relever davantage d’une gouvernance « privative » que de modalités d’autogouvernance communautaires décrites par Ostrom.

21Comme pour RedHat, un certain contrôle sur le projet s’opère également au moyen des licences. Sur ce point, la situation dans Symfony est en fait plus restrictive. Il n’y a pas, comme dans RedHat, un « contrat de licence des contributeurs » donnant l’option aux contributeurs d’utiliser la licence qu’ils souhaitent parmi plusieurs jugées acceptables. Dans Symfony, une seule licence est permise, ce qui s’explique possiblement par le fait que les contributions s’inscrivent dans un ensemble de code source, plutôt qu’un système de paquets, nécessitant donc une cohérence plus grande. Plus précisément, c’est la licence MIT qui est utilisée, une licence dite « permissive » qui permet d’intégrer le code source dans une application propriétaire. Le projet se situe donc en rupture avec l’approche préconisée par la licence publique générale GNU (GPL) qui interdit d’intégrer du code source libre dans une application propriétaire ou à code source fermé.

22L’hébergement des plugins sur le site officiel du projet requiert également l’utilisation de la licence MIT ou d’autres licences permissives comme la LGPL ou la BSD. Un plugin est une extension d’un logiciel qui bonifie ou modifie sa fonctionnalité. Dans le cas de Symfony, des centaines de plugins ont été créés par des individus ou des entreprises qui cherchent à adapter le logiciel à leurs propres besoins. Bien que les auteurs des plugins de Symfony aient toute la liberté de faire ce qu’ils souhaitent de leur code, l’hébergement sur le site officiel du projet leur donne évidemment beaucoup plus de visibilité. C’est donc en contrôlant l’hébergement officiel que le fondateur (et l’entreprise commanditaire) continue de garder une influence sur les choix de licence des projets.

23Finalement, un certain contrôle est aussi exercé par l’entreprise sur ses marques de commerce. La page « Trademark and Logo Policy » stipule que la marque Symfony est la propriété du créateur et leader actuel du projet, également fondateur et président de SensioLabs. La page mentionne également que la politique de marques de commerce est de favoriser la diffusion de Symfony, tout en « contrôlant cet usage » de façon à éviter des utilisations inappropriées pouvant semer la confusion dans le public5. Le document précise que la politique inclut toutes les marques de commerce commençant par les lettres « Symfony », « Symf » et « sf », qu’elles soient sous forme de textes ou de logos. La politique interdit également toute forme d’utilisation commerciale de cette marque.

  • 6 Un aspect intéressant à noter ici est que c’est le préfixe sf qui est à l’origine du nom Symfony, e (...)

24Fait intéressant, dans les premières versions de Symfony, la marque de commerce s’inscrivait jusqu’au cœur du code source, par l’entremise des conventions de nommage. En programmation informatique, les conventions de nommage sont des règles qui concernent la manière de nommer des identifiants du code source, par exemple le nom des fichiers, le nom des variables ou des fonctions dans le code. Dans Symfony, l’une des conventions de nommage importantes consistait à préfixer le nom des « classes » (une composante du code) et des fichiers par les lettres sf, ce qui signifie symfony, mais également Sensio Framework, du nom de SensioLabs, l’entreprise commanditaire du projet6, comme le montre la figure 1.

Figure 1. Nom de fichiers dans Symfony (version 1.4)

Figure 1. Nom de fichiers dans Symfony (version 1.4)

25Les implications légales de ces conventions restent ambiguës. Aurait-il été possible de reprendre le code source tel quel et de le redistribuer sous un autre nom, comme le permettent en théorie les licences de logiciels libres, ou bien aurait-il été nécessaire de modifier substantiellement le code source pour ce faire ? Il semble que dans les versions subséquentes du code source, le préfixe sf n’ait pas été retenu. On retrouve toutefois plusieurs mentions du logiciel Symfony au cœur même du code source (Figure 2).

26Symfony, comme RedHat, met donc en œuvre différentes mesures pour assurer le contrôle du développement de projets basés sur les biens communs. Bien que ces mesures ne soient pas des formes d’« enclosure » au sens traditionnel, elles restent néanmoins des manières de canaliser le travail parfois gratuit de nombreux contributeurs qui agissent souvent pour le bien commun. Que reste-t-il alors du fondement éthique qui était à l’origine des logiciels libres ? C’est ce que je vais aborder dans la prochaine section.

Logiciels libres : de l’éthique à la business ?

27Quels sont les enjeux éthiques de ces appropriations commerciales des logiciels libres ? L’un des principaux enjeux, identifié depuis longtemps, est sans doute celui de l’évacuation de l’éthique du discours sur les logiciels libres. Rappelons en effet que le logiciel libre a d’abord été créé sous l’injonction d’un impératif éthique, soit celui de permettre le partage du code source des logiciels. L’intérêt commercial pour les logiciels libres a toutefois tendance à détourner l’attention vers des éléments « vendeurs », tels que leur faible coût, leur plus grande flexibilité ou leur supériorité technique. Comme cela a été mentionné plus tôt, c’est dans cette perspective que le terme open source a été créé pour supprimer la confusion, en anglais, du terme free de free software, qui veut autant dire « libre » que « gratuit ». Cette nouvelle appellation est d’ailleurs très régulièrement décriée par Richard Stallman, qui rappelle que la création du terme open source provenait aussi d’un désir d’évacuer la dimension de « liberté » présente dans la rhétorique des logiciels libres, pour replacer l’attention sur la question de la supériorité technique du modèle open source. Stallman écrivait ainsi que la « discussion de l’open source ne s’intéresse pas au bien et au mal, seulement à la popularité et au succès8 » (2009). Dans un certain sens, écrivait Stallman, les partisans de la rhétorique du logiciel libre et de celle de l’open source forment deux camps au sein d’une même communauté.

28Un deuxième enjeu, quoique plus politique qu’éthique, qui ressort clairement des études de cas est celui de la gouvernance. Contrairement à la vision originale des communautés des logiciels libres comme eldorado démocratique, voire anarchiste, où tout le monde pourrait contribuer au code (Lessig, 1998 ; Moglen, 1999), il est maintenant amplement documenté que dans de nombreux cas, la gouvernance des communautés, qui se veut supposément « méritocratique », repose en fait sur la main mise de son ou de ses fondateurs, ainsi que de quelques collaborateurs de confiance. Dans le cas de Symfony, par exemple, la direction du projet est le fait de son créateur, également fondateur et président de l’entreprise, qui est le principal commanditaire du projet. Dans le cas de Fedora, la gouvernance est plus balancée, car elle repose sur un conseil dont la moitié des membres sont élus. Le pouvoir reste tout de même essentiellement entre les mains de l’entreprise RedHat. Ces modes de gouvernance des projets étudiés correspondent-ils vraiment à l’idéal des biens communs porté par Ostrom et le mouvement des communs actuel ? Rappelons que pour Elinor Ostrom, la gouvernance démocratique est l’un des aspects importants des biens communs. En effet, l’un des principes mis de l’avant par Ostrom pour caractériser un bien commun est que les « individus affectés par les règles entourant le bien commun peuvent généralement participer à la modification de ces règles » (Hess et Ostrom, 2007 : 7). Est-ce bien le cas dans les deux projets étudiés ?

29Finalement, et bien que cela ne ressorte pas explicitement dans les études de cas présentées plus tôt, l’enjeu du travail gratuit mérite d’être mentionné. Cette problématique – aussi abordée par le concept de Digital Labor – a déjà été analysée par plusieurs auteurs (Terranova, 2000 ; Dafermos et Söderberg, 2009 ; Scholz, 2013 ; Broca, 2014 : 123-127 ; Cardon et Casili, 2015). Tiziana Terranova remarquait déjà en 2000 la présence active des Venture Capitalists dans les conférences open source. Elle notait qu’il ne s’agissait pas là d’un intérêt altruiste, mais plutôt d’une manière de profiter d’une quantité toujours plus importante de code source disponible gratuitement sur Internet, ainsi que du travail gratuit d’une masse de programmeurs enthousiastes qui pouvaient résoudre des bogues de façon quasi instantanée. L’auteure soulignait toutefois qu’il ne s’agissait pas là d’une simple dynamique de prédation capitaliste des logiciels libres, mais qu’il y avait au contraire une relation très étroite entre l’enthousiasme des militants open source et les élans aventuriers des compagnies open source. Utilisant une analyse marxiste, Dafermos et Söderberg (2009) considèrent pour leur part que les entreprises open source, comme Red Hat, réussissent à mobiliser le travail gratuit, ce qui leur permet de multiplier la plus-value des salariés qu’elles emploient. Les auteurs soutiennent également que ce travail gratuit a un effet à la baisse sur la rémunération et les conditions de travail de l’ensemble des travailleurs. En définitive, écrivent Dafermos et Söderberg, parmi les travailleurs, c’est peut-être bien le développeur professionnel de logiciels libres qui est dans la position la plus privilégiée.

30Ces inquiétudes par rapport au travail gratuit sont persistantes. Ashe Dryden, une développeuse indépendante du langage de programmation Ruby, critique par exemple l’importance du travail gratuit dans le monde des logiciels libres en en déplorant les conséquences sociales, en particulier pour les femmes (Dryden, 2013). L’auteure remarque ainsi que plusieurs emplois dans les entreprises open source requièrent aujourd’hui, comme condition d’embauche, d’avoir fourni des contributions publiques à des logiciels libres, ce qui implique nécessairement d’avoir accompli un travail gratuit avant d’être embauché. De plus, les candidats ayant déjà contribué aux logiciels libres poursuivront probablement leur implication dans ces projets durant leur temps libre, par passion et par loyauté pour les projets commencés. « This is akin to not paying someone for overtime », écrit donc l’auteure. Par ailleurs, Dryden souligne que cette contrainte « d’avoir déjà contribué à des logiciels libres » pour être embauché tend à marginaliser davantage les personnes qui n’ont pas eu le loisir de consacrer du temps aux logiciels libres. Pour Dryden, une conséquence indirecte de ce travail non payé est donc l’absence de diversité – et en particulier l’absence de femmes et de personnes généralement marginalisées – au sein des communautés et des entreprises de logiciels libres. L’auteure note finalement que ce sont souvent les personnes déjà en place qui bénéficient le plus de ce travail gratuit, de même que les chefs d’entreprises et leurs actionnaires.

Conclusion : entre réciprocité et marchandisation des biens communs

  • 9 C’est le cas de LibreOffice, créé à partir d’OpenOffice, à la suite du départ de plusieurs de ses d (...)

31L’engagement des entreprises commerciales dans le monde des logiciels libres continue de susciter un intérêt ambivalent de la part des acteurs et des analystes. Plusieurs considèrent que les acteurs commerciaux jouent un rôle essentiel pour faire sortir les logiciels libres de la marginalité. D’autres acteurs et analystes expriment cependant des inquiétudes en ce qui concerne notamment le contrôle des orientations de développement ou la captation du travail gratuit. Le présent article s’est particulièrement attardé à la question de la gouvernance des projets de logiciels libres. Si l’on suit Ostrom – à savoir qu’un bien commun renvoie surtout à l’action collective –, pourrait-on encore considérer comme des biens communs des projets de logiciels libres où la balance du pouvoir concernant les orientations soit le fait d’une entreprise privée et d’une seule ? Cela ne relèverait-il pas davantage d’une forme de gouvernance plus typique d’un « bien privé » ? On pourrait certes soutenir que, si le code source est libre, il est alors possible de recréer un autre projet à partir du code source précédemment contrôlé par une entreprise privée. C’est ce que l’on appelle un fork dans le langage des logiciels libres (une fourche en français)9. Toutefois, créer un fork d’un projet peut être source de conflits et requiert un travail important, deux aspects qui favorisent le statu quo. Ce « fork » devient alors un nouveau projet, et on peut se demander si un logiciel qui a changé de nom et de mode d’organisation demeure le même « bien ».

32Une question ouverte reste donc de savoir si le contrôle qu’exercent certaines entreprises privées sur des logiciels libres pourrait mettre en péril le statut de bien commun de l’ensemble de l’écosystème des logiciels libres. On peut en effet avancer que le libre accès au code source permet des dynamiques de contre-pouvoir « inter-communautés » qui s’expriment par exemple par ces dynamiques de fourches entre projets. D’ailleurs, Dafermos et Söderberg (2009), tout en critiquant le rôle des entreprises dans la production du logiciel libre, considèrent prématuré de conclure à un contrôle corporatif de l’écosystème du logiciel libre. Toutefois, l’intérêt d’entreprises très puissantes comme Google pour les logiciels libres ainsi que les inquiétudes persistantes concernant le travail gratuit, justifient à mon sens de garder ces questionnements à l’avant-plan.

33Dans la mesure où les modes de production collaboratifs basés sur les biens communs prennent de plus en plus d’importance, il devient crucial d’analyser des dynamiques qui peuvent apparaître comme de nouvelles formes de contrôle et d’enclosure, même si elles respectent certains principes de libre accès aux ressources communes. Par exemple, dans le cas des logiciels libres, le libre accès au code source est-il suffisant pour caractériser un projet comme un bien commun ? Dans le cadre de cet article, j’ai tenté de montrer que de nouvelles formes de contrôle, s’apparentant à de nouvelles « enclosures », se mettent en place, tout en prenant appui sur le libre accès au code source. J’ai également insisté sur l’importance de conserver un regard critique sur ces nouvelles formes de contrôle, et d’éviter de poser le libre accès au code source comme le seul critère qualifiant un logiciel libre comme un bien commun.

Haut de page

Bibliographie

Aigrain, Philippe (2005), Cause commune : l’information entre bien commun et propriété, Paris, Fayard. En ligne à http://www.causecommune.org/download, consulté le 9 novembre 2007.

Amadeo, Ron (2013), « Google’s iron grip on Android: Controlling open source by any means necessary », Ars Technica (21 octobre). En ligne à http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary, consulté le 3 août 2015.

Auray, Nicolas (2000), « Le savoir en réseaux et l’empreinte inventive », revue Alice, vol. 3, hiver, p. 78‑97.

Benkler, Yochai (2003), « Freedom in the Commons: Towards a political economy of information », Duke Law Journal, vol. 52, p. 1245-1276.

Benkler, Yochai (2006), The Wealth of Networks: How Social Production Transforms Markets And Freedom, New Haven, Yale University Press.

Birkinbine, Benjamin (2014), « Incorporating the Commons: A Political Economic Analysis of Corporate Involvement in Free and Open Source Software », Thèse de doctorat, University of Oregon. En ligne à https://scholarsbank.uoregon.edu/xmlui/handle/1794/18513, consulté le 27 août 2015.

Boyle, James (2008), The Public Domain: Enclosing the commons of the mind, New Haven, Yale University Press.

Broca, Sébastien (2013), Utopie du logiciel libre : du bricolage informatique à la réinvention sociale, Paris, Le passager clandestin. En ligne à http://lepassagerclandestin.fr/catalogue/essais/utopie-du-logiciel-libre.html, consulté le 8 janvier 2016.

Cardon, Dominique (2005), « Innovation par l’usage », dans Alain Ambrosi, Valérie Peugeot et Daniel Pimienta (dir.), Enjeux de mots : regards multiculturels sur les sociétés de l’information. Caen, C & F Éditions. En ligne à http://vecam.org/article588.html, consulté le 14 décembre 2011.

Cardon, Dominique et Antonio Casilli (2015), Qu’est-ce que le Digital Labor ?, Bry-sur-Marne, INA.

Coleman, Gabriella (2012), Coding Freedom: The Ethics and Aesthetics of Hacking, Princeton, Princeton University Press.

Coris, Marie (2006), « Chronique d’une absorption par la sphère marchande : les Sociétés de Services en Logiciels Libres », Gérer & Comprendre, no 84, p. 12‑24.

Dafermos, George et Johan Söderberg (2009), « The hacker movement as a continuation of labour struggle », Capital & Class, n97, p. 53-73.

Demazière, Didier, François Horn et Marc Zune (2007), « Des relations de travail sans règles ? », Sociétés contemporaines, vol. 66, no 2, p. 101-125.

Dryden, Ashe (2013), « The Ethics of Unpaid Labor and the OSS Community », Blogue de Ashe Dryden (13 novembre). En ligne à http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community, consulté le 3 septembre 2015.

Hamel, Jacques (1998), « Défense et illustration de la méthode des études de cas en sociologie et en anthropologie. Quelques notes et rappels », Cahiers internationaux de sociologie, vol. 104, p. 121-138.

Hardin, Garrett (1968), « The Tragedy of the Commons », Science, vol. 162, no 3859 (13 décembre), p. 1243‑1248. En ligne à http://www.sciencemag.org/content/162/3859/1243, consulté le 26 août 2015.

Hess, Charlotte et Elinor Ostrom (2007), Understanding Knowledge as a Commons: From theory to practice, Cambridge, MIT Press.

Hippel, Eric von (2007), « Horizontal Innovation Networks–By and for Users », Industrial and Corporate Change, vol. 16, no 2, p. 293-315.

Latzko-Toth, Guillaume (2009), « L’étude de cas en sociologie des sciences et des techniques », Note de recherche 2009-03, Montréal, Centre interuniversitaire de la recherche sur la science et la technologie (CIRST). En ligne à http://www.cirst.uqam.ca/Portals/0/docs/note_rech/2009-03.pdf, consulté le 8 janvier 2016.

Le Crosnier, Hervé (2012). « Elinor Ostrom ou la réinvention des biens communs », Les blogs du Diplo (15 juin). En ligne à http://blog.mondediplo.net/2012-06-15-Elinor-Ostrom-ou-la-reinvention-des-biens-communs, consulté le 8 janvier 2016.

Le Crosnier, Hervé (2015). En communs. Une introduction aux communs de la connaissance. Caen, C & F Éditions.

Lee, Samuel, Nina Moisa et Marco Weiss (2003), Open Source as a Signalling Device – An economic analysis, Working Paper Series: Finance & Accounting, Johann Wolfgang Goethe-Universität Frankfurt a. M. En ligne à http://www.econstor.eu/handle/10419/76971, consulté le 30 juillet 2015.

Lerner, Josh et Jean Tirole (2000), « The Simple Economics of Open Source », Journal of Industrial Economics, no 52 (mars), p. 197-234. En ligne à http://www.nber.org/papers/w7600, consulté le 30 juillet 2015.

Lessig, Lawrence (1998), « Open Code and Open Societies: Values of Internet Governance », Chicago-Kent Law Review, vol. 74, p. 101-116.

Lessig, Lawrence (2006), Code: Version 2.0, New York, Basic Books.

Lincoln, Yvonna S. et Egon G. Guba (2000 [1979]), « The Only Generalization Is: There Is No Generalization », dans Roger Gomm, Martyn Hammersley et Peter Foster (dir.), Case Study Method. Key Isssues, Key Texts, p. 27-44. London, Sage Publications.

Moglen, Eben (1999), « Anarchism Triumphant: Free Software and the Death of Copyright », First Monday, vol. 4, no 8.

Moulier-Boutang, Yan (2007). Le capitalisme cognitif : La Nouvelle Grande Transformation. Paris, éditions Amsterdam.

Scholz, Trebor (2013), Digital Labor. The Internet as Playground and Factory, New York, Routledge, 2013.

Schweik, Charles M. (2007), « Free/Open-Source Software as a Framework for Establishing Commons in Science », dans Charlotte Hess et Elinor Ostrom (dir.,), Understanding Knowledge as a Commons: From theory to practice, p. 277-309. Cambridge, MIT Press.

Stallman, Richard (2009), « Viewpoint: Why “Open Source” Misses the Point of Free Software », Communications of the ACM, vol. 52, no 6 (juin), p. 31-33. En ligne à http://doi.acm.org/10.1145/1516046.1516058, consulté le 1er septembre 2015.

Terranova, Tiziana (2000), « Free Labor: Producing culture for the digital economy », Social Text, vol. 18, no 2, p. 33-58. En ligne à http://muse.jhu.edu/journals/soc/summary/v018/18.2terranova.htm, consulté le 4 août 2015.

Haut de page

Notes

1 Dans le cas des communs numériques, le déclin n’est pas tant lié à leur surutilisation qu’à leur abandon par manque d’intérêt ou en raison des difficultés à gérer adéquatement leur production et leur maintenance.

2 Les analyses développées dans ce texte ont également été nourries par les discussions sur la liste « échanges » du réseau francophone des biens communs.

3 Pour la version 4.3 de Linux, publiée en novembre 2015, RedHat était responsable de 18 % des modifications des lignes de code de Linux – tout juste derrière Intel : http://www.remword.com/kps_result/P.

4 Dans la culture du logiciel libre, le terme anglais de Benevolent Dictator for Life (dictateur bienveillant à vie) désigne une personne qui définit les orientations générales du projet, mais à laquelle les autres personnes font confiance pour ne pas abuser de ses pouvoirs https://fr.wikipedia.org/wiki/Benevolent_Dictator_for_Life.

5 http://symfony.com/trademark.

6 Un aspect intéressant à noter ici est que c’est le préfixe sf qui est à l’origine du nom Symfony, et non l’inverse. En effet, l’entreprise qui commandite le projet – Sensio – avait initialement développé un cadre d’application interne nommé Sensio Framework, dont le préfixe de plusieurs identifiants du code source était « SF ». L’entreprise a ensuite décidé de rendre public son logiciel, ce qui impliquait de trouver un autre nom moins lié à l’entreprise. Plutôt que de réécrire le code source, l’entreprise a décidé de choisir un nom qui reflétait les préfixes utilisés dans le code source, soit symfony.

7 https://github.com/symfony/symfony/blob/2.8/src/Symfony/Bundle/FrameworkBundle/Controller/Controller.phphttps://github.com/symfony/symfony/blob/2.8/src/Symfony/Bundle/FrameworkBundle/Controller/Controller.php.

8 La traduction de ce texte se trouve ici : http://www.gnu.org/philosophy/open-source-misses-the-point.fr.html, consulté le 3 septembre 2015.

9 C’est le cas de LibreOffice, créé à partir d’OpenOffice, à la suite du départ de plusieurs de ses développeurs, insatisfaits de certains changements aux modes de gouvernance.

Haut de page

Table des illustrations

Titre Figure 1. Nom de fichiers dans Symfony (version 1.4)
URL http://ethiquepublique.revues.org/docannexe/image/2275/img-1.png
Fichier image/png, 14k
Titre Figure 2. Code source de Symfony7
URL http://ethiquepublique.revues.org/docannexe/image/2275/img-2.png
Fichier image/png, 17k
Haut de page

Pour citer cet article

Référence électronique

Stéphane Couture , « Le contrôle des communs numériques à des fins commerciales : le cas des logiciels libres », Éthique publique [En ligne], vol. 17, n° 2 | 2015, mis en ligne le 06 mai 2016, consulté le 26 juillet 2017. URL : http://ethiquepublique.revues.org/2275 ; DOI : 10.4000/ethiquepublique.2275

Haut de page

Auteur

Stéphane Couture

Stéphane Couture est chercheur postdoctoral en communication à l’université McGill et enseignant en informatique à l’Université du Québec à Montréal. Ses recherches portent sur les aspects sociaux et politiques des logiciels libres et de la collaboration numérique. Il est également engagé au sein de plusieurs initiatives sociales et citoyennes en lien avec ces sujets.

Haut de page

Droits d’auteur

Tous droits réservés

Haut de page
  • Revues.org