Tout est libre dans le logiciel libre, sauf sa maison !

Classé dans : Logiciel Libre | 18

Pranav - CC byPar nature décentralisés et collaboratifs, les logiciels libres ont besoin d’être hébergés sur Internet dans des forges qui en assurent leur développement (en offrant de nombreux services comme la gestion des versions ou le suivi des bugs).

SourceForge est certainement la plus célèbre d’entre elles et abrite en son sein plusieurs centaines de milliers de logiciels libres. Google, encore lui, n’est pas en reste avec son Google Code qui accueille de plus en plus d’applications.

Or si ces forges sont bien gratuites et très pratiques (puisque l’on crée et gère son projet en quelques clics), la plupart ne sont paradoxalement pas libres ! Il n’est ainsi pas possible de récupérer le code qui les fait tourner pour installer sa propre forge sur son propre serveur.

On comprend aisément qu’un site comme Facebook garde jalousement son code puisque son objectif est de concentrer au même endroit un maximum d’utilisateurs et surtout pas de les voir partir pour y faire leur petit Facebook personnel dans leur coin. Mais on comprend moins que les développeurs de logiciels libres se retrouvent un peu dans la même situation en acceptant de placer leur code sur des plateformes propriétaires. C’est une question de principe mais aussi de l’avenir incertain d’un code qu’il est alors difficile de déplacer[1].

C’est tout l’objet de cette mise en garde de notre ami Benjamin Mako Hill dont c’est déjà la quatrième traduction.

Il faut des outils libres pour faire des logiciels libres

Free Software Needs Free Tools

Benjamin Mako Hill – 4 juin 2010 – Blog personnel
(Traduction Framalang : Misc, Cheval boiteux, Siltaar et Goofy)

Au cours des dix dernières années, les développeurs de logiciels libres ont été régulièrement tentés par des outils de développement qui offrent la capacité d’élaborer des logiciels libres de façon plus efficace et productive.

Le seul prix à payer, nous dit-on, est que ces outils eux-mêmes ne sont pas libres ou s’exécutent comme des services réseaux avec du code que nous ne pouvons pas voir, ou lancer nous-mêmes. Dans leurs décisions d’utiliser ces outils et services (tels que BitKeeper, SourceForge, Google Code et GitHub), les développeurs de logiciels libres ont décidé que « la fin justifie les moyens » et ont en quelque sorte vendu la liberté de leur communauté de développeurs et d’utilisateurs. Cette décision d’adopter des outils de développement non libres et privés a entamé notre crédibilité dans la promotion des libertés logicielles et a compromis notre liberté comme celle de nos utilisateurs d’une façon que nous devrions rejeter.

En 2002, Linus Torvalds a annoncé que le noyau Linux utiliserait le systéme de gestion de version distribué BitKeeper. Bien que la décision ait généré beaucoup de craintes et de débats, BitKeeper a permis aux codeurs du noyau de travailler de manière décentralisée avec une efficacité qu’il n’aurait pas été possible d’obtenir avec les outils libres de l’époque. Certains développeurs Linux ont décidé que les bénéfices obtenus justifiaient la perte de liberté des développeurs. Trois ans plus tard, les sceptiques prirent leur revanche quand le proprétaire de BitKeeper, Larry McVoy, a retiré la licence gratuite d’utilisation de plusieurs développeurs importants du noyau, car Andrew Tridgell avait commencé à écrire un remplaçant libre de BitKeeper. Les développeurs furent forcés d’écrire leur propre outil libre pour le remplacer, un projet connu maintenant sous le nom de Git.

Bien sûr, les relations entre logiciels libres et outils non libres vont au-delà du cas de BitKeeper. Le code source des logiciels du service SourceForge était jadis disponible pour ses utilisateurs, mais les auteurs sont revenus à un modèle totalement fermé. Bien que SourceForge soit construit sur des briques libres, les utilisateurs interagissent avec le logiciel uniquement via le Web sur l’unique site SourceForge. Comme les utilisateurs n’ont pas de copie du logiciel de Sourceforge, ils ne peuvent pas en demander le code source. Des projets similaires comme le service Tigris.org de CollabNet, Google Code et GitHub ont tous des buts similaires, et gardent leur code pour eux de la même façon. Les services sont souvent fournis gratuitement et promeuvent le développement de logiciel libre, mais leur dévouement ne s’étend pas aux logiciels qui font tourner leur plateforme de développement. Le code source de chacun de ces services reste privé et non modifiable par les développeurs utilisant ces services.

Ces outils de développement proprietaires posent un dilemme à de nombreux développeurs de logiciels libres. Le but de chacun de ces services est de permettre le succès des logiciels libres et l’obtention de plus de libertés grâce à l’utilisation d’outils plus efficaces. CollabNet, Google et GitHub annoncent chacun qu’ils veulent que le logiciel libre progresse et qu’ils veulent l’aider à avancer. Pour certaines raisons, ces entreprises ont choisi de soutenir les libertés logicielles par des moyens moins en phase avec les éthiques du mouvement que celle qu’ils cherchent à créer. Le résultat est que les développeurs sont dépossédés. La liberté du code logiciel que produisent ces hackers est dépendante d’une restriction inacceptable.

Tout d’abord, l’utilisation d’outils non libres envoie un message irrecevable pour les utilisateurs du logiciel libre produit. « La liberté des logiciels est importante pour vous », semblent dire les développeurs, « mais pas pour nous ». Un tel comportement sape l’efficacité basique du fort engagement éthique au cœur du mouvement du logiciel libre. À tous ceux qui ont déja fait le choix du logiciel libre, nous devons montrer que nous pouvons réussir – et prospérer – en utilisant des logiciels libres. Nous devons soutenir les alternatives libres face aux systèmes propriétaires, comme Savane qui peut remplacer SourceForge ou Google Code, et qui est à la base de GNU Savannah, ou encore Gitorious, pour remplacer GitHub, en les utilisant et en les améliorant dans les domaines où ils peuvent être améliorés.

Deuxièmement, nous devrions comprendre en nous projetant plus en avant que le logiciel que nous produisons n’est libre qu’en fonction des logiciels dont il dépend pour son usage, sa distribution et son évolution.

La licence GNU GPL et le code source ne signifient pas grand-chose pour un utilisateur qui veut modifier un programme sans avoir un accés libre au logiciel requis pour permettre cette modification. Il ne s’agit pas que de mettre les libertés des développeurs dans la balance, mais aussi finalement celles des utilisateurs et de tous les développeurs qui prendront le relais. Ceux qui choisissent d’utiliser des logiciels non libres placent tout le monde à la merci des groupes et des individus qui produisent les logiciels dont ils dépendent.

Tandis que les outils de développement propriétaires peuvent aider les développeurs de logiciels libres à produire de meilleurs logiciels à court terme, le prix à payer est inacceptable. Dans le débat controversé des logiciels privés et des services réseaux, les développeurs de logiciels libres devraient se placer du côté de « l’excès » de liberté. Compromettre nos principes afin d’obtenir plus de liberté est auto-destructeur, instable et au final injuste envers nos utilisateurs et la communauté des développeurs de logiciels libres dans son ensemble.

Tout comme les premiers mainteneurs du projet GNU se sont d’abord concentrés sur la création d’outils libres pour la création de logiciel libre, nous devons nous assurer que nous pouvons produire des logiciels sans entrave et utiliser des outils incontestablement ouverts. Si nous échouons, les logiciels seront indirectement moins libres. Nous devons refuser l’utilisation de logiciels qui ne nous garantissent pas les libertés que nous tentons de donner à nos utilisateurs par le développement de logiciels, et nous devons faire pression en ce sens sur les producteurs de nos outils de développement. Le logiciel libre n’a pas réussi en compromettant nos principes. Nous ne serons pas bien servis d’un point de vue technique, pragmatique ou éthique en compromettant la liberté des outils que nous utilisons pour constuire un monde libre.

Benjamin Mako Hill
Creative Commons By-Sa

Notes

[1] Crédit photo : Pranav (Creative Commons By)

18 Réponses

  1. Il y a aussi le problème de licence. Celle de SourceForge implique de donner à SourceForge tous les droits sur le code qu’on leur confie, ce qui n’est pas forcément compatible avec la volonté de l’auteur.

  2. @elessar
    "Donner à SourceForge tous les droits sur le code" ? Tu galèges ? Tu crois vraiment que les gros projets hébergés par sourceforge ont cédé leurs droits ? Tu devrais t’informer plus sérieusement.

  3. Salut a tous!

    Je n’ai pas encore lu tout l’article et je dois aller au boulot. Je tenais juste a preciser qu’il existe des alternatives parfaitement libres a ces forges, comme GNU Savannah ou gitorious (cites dans le texte) mais aussi GNA! et alioth.

    On peut en trouver une jolie liste ici:
    http://en.wikipedia.org/wiki/Compar

    Donc si vous demarrez un projet libre, reflechissez avant de vous precipiter sur sourforge ou google code!

  4. CodingTeam ! http://codingteam.net/index
    The forge libre qu’elle est bien, avec des morceaux de french touch dedans.
    Les gens ne vont sur SourceForge et Google Code que parce que ce sont celles qui ont le plus de visibilité. Pour contrer cela, il ne faut pas louper une telle occasion de parler des alternatives libres ;-)

  5. Problème ancien déjà résolu
    http://gna.org/ ou http://www.tuxfamily.org/

    Après, il faut surement faire de la pub

  6. Il y a aussi Launchpad qui est libre maintenant.
    Il a l’avantage d’être très complet et d’être assez facile d’accès (du moins je trouve).

  7. Bakounine

    Depuis janvier 2010, pour être en accord avec la loi américaine (pays d’hébergement) Source force n’est plus accessible depuis certain pays

    http://sourceforge.net/blog/clarify

    Je ne suis vraiment libre que lorsque tous les êtres humains qui m’entourent, hommes ou femmes, sont également libres. […] Ma liberté personnelle, ainsi confirmée par la liberté de tous, s’étend à l’infini.

    Bakounine, Dieu et l’État.

  8. Oui, launchpad est enfin libre. Pour la petit histoire, Benjamin Mako Hill était un des premiers employées de Canonical, et donc je trouve assez ironique qu’il parle de la libération des forges aprés avoir bossé chez Canonical, dont la forge a fait couler beaucoup d’encre. Par exemple, je trouve que Benjamin aurait pu dire que si les forges sont proprios, c’est parce que le business model des boites derriéres est de vendre une version privée du logiciel. Par exemple, une société qui veut heberger son code fermé sur github peut payer pour avoir une version à installer sur son lan ( http://fi.github.com/pricing.html ). De même, à l’époque ou Launchpad était encore un logiciel proprio, une offre de Canonical était l’hebergement de projet pour payer les salariés ( https://bugs.launchpad.net/launchpa… ).

    Ceci dit, Launchpad a beau être libre, personne n’a pris le service pour en faire un fork tellement la mise en place semble complexe. Il faut déjà avoir une version supporté d’Ubuntu, lancer un script bien spécifique qui va toucher à la config réseau ( en rajoutant en dur les ips et les vhosts sur 127.0.0.1, qui va rajouter des sources et des paquets , des scripts dans /usr/local/ ). Tout ça ne parait déja pas trés propre.

    Ensuite, je vais pas accuser Canonical , ils ont fait leur boulot, et pour avoir fait suffisament d’admin, je sais à quel point on finit toujours par avoir ce genre de choses. Et pour moi, c’est pas non plusle role de Canonical que de s’assurer que leur code marche partout, c’est plus à la communauté de faire en sorte de rendre le logiciel suffisament portable et facile à installer. Mais j’ai le sentiment qu’en effet, les gens ne se préoccuppent pas des sites webs de la même façon qu’ils s’occupent du code sur leur ordinateur.

  9. Sebseb01

    Personnellement, j’utilise http://codingteam.net/ Elle propose tous les outils dont j’ai besoin, tout les ouitls son simple et efficace. En plus le développeur est français, et on peut lui souffler des idées.

  10. Pour tous ceux que le sujet des forges intéresse, une session sur le sujet est prévue dans le cadre de l’Open World Forum 2010 à Paris, le 1er octobre.
    Voir http://www.openworldforum.org/atten
    Le thème de cette journée est justement l’interopérabilité entre forges et la liberté des données projet hébergées sur ces forges.
    J’ajoute que si les forges citées dans l’article, en particulier Sourceforge, posent bien les problèmes exposés, il y a d’autres implementations de forge qui sont libres, et qui seront représentées lors de cette journée.

  11. @BlueTak : Au temps pour moi, c’est pour les « contenus associés » qu’on concède une licence intégrale à SourceForge. Ces contenus, c’est tout sauf le code : textes, sons, images, vidéos…

  12. Je dois dire que je ne suis pas particulièrement scandalisé par la présence de forges telles que Google Code.
    Basée entièrement sous des outils libres, les seuls éléments réellement propriétaires sont de petits utilitaires tels que la tree view des révisions Mercurial en HTML.
    Oui, c’est vrai, le code serveur n’est pas publié, mais est-ce réellement dramatique? Après tout, très peu de sites, même parmi les sites de L.L., publient le code source PHP/Perl/Python/ASP.NET(?) de leur site…

    On pourra arguer qui si Google Code ferme demain, ou décide de faire passer ses services à 400$/mois, personne ne pourra le "forker". Mais après tout, l’intérêt de Google Code ou autre forges ne vient pas tant des outils qu’il propose (installer Mercurial/SVN + Bugzilla + un wiki + un éventuel gestionnaire de mailing list sur un serveur privé ne pose aucun problème), mais bien de la gratuité, fiabilité et rapidité de son réseau administré (bon d’accord, on va dire que l’argument ne s’applique pas à SourceForge…).
    Et ça, libre ou non, ça dépend du bon vouloir de Google.

    Donc oui, ce serait _mieux_, mais est-ce _nécessaire_, au sens où la communauté du libre se contredit elle-même en utilisant ces services? Ça je ne le pense pas.

    Après, il faut également faire attention aux termes de la licence d’utilisation, mais c’est une autre histoire.

  13. Mako Hill est de la FSF. Donc il adopte la même position "dure" que Stallman. Et donc ça le dérange que les outils ne soient pas libres.

    Je trouve ça très bien que des gars comme lui viennent nous mettre en garde et tendent vers une sorte d’idéal que serait le "tout libre".

    Mais le "tout libre" est plus un chemin ou une disposition mentale qu’une réalité. Dans la pratique, on ne peut que cohabiter avec le non libre. Le tout est de le faire avec vigilance. Ainsi mettre son code sur SourceForge ou Google offre quand même des garanties puisque l’intérêt de ces sociétés est de rendre service aux communautés et certainement pas de faire du fric avec les données collectées comme d’autres.

    Il faut aussi savoir faire confiance au propriétaire de temps en temps quand le terrain est bien balisé comme cela semble bien être le cas ici.

  14. Dans la liste des outils non libres il y a JIRA (suivi de bugs) qui est vraiment très utilisé par les logiciels libres (apache etc…) puisque gratuit pour eux.

  15. @xav sauf que Google fait du fric avec les données collectés, faut pas l’oublier, d’une part.

    et que d’autre part, il existe des alternatives libres. Quand aux garanties, on peut se souvenir des affaires Oracle vs Google ( ou les joies d’avoir un changement radical de direction aprés un rachat ), ou simplement les soucis de Twitter ( qui n’a rien à faire de l’ouverture au final ). Et l’illustration même de l’affaire Bitkeeper montre les dégats de la cohabitation.

  16. Christophe-Marie

    Je me permet d’intervenir sur cet article malgré son ancienneté, pour poser une ou deux réflexions.

    Oui, certes, on pourra reprocher à google (par exemple) de ne pas ouvrir le code de son googlecode. Pourtant, j’ai plutôt envie de les remercier que de les fustiger. En donnant l’accès à une plateforme de cette qualité aux développeurs, google contribue bien plus au développement du logiciel libre qu’il n’y nuit.

    Pour le développeur, mettre en place un dépot public pour un projet est pénible. Il faut s’occuper du gestionnaire de version, de la page d’accueil, de la rubrique téléchargement, d’un wiki pour la documentation… Quand on voit que tout cela est livré clef en main chez google, il est compréhensible qu’on saute sur l’occasion. Le code est libre, le site ne l’est pas. À la bonne heure, on s’en remettra. Plutôt que de râler, je préfère remercier. Mes projets n’auraient peut-être pas vu le jour aussi vite si on n’avait pas eu cela sous la main.

    Maintenant, je n’irai pas défendre l’indéfendable: ça serait mieux si c’était libre. Mais bon, pour moi, loin de mettre en danger le libre, cela y contribue.

  17. Jérôme

    Dans ma boite on a migré sur GitlabHQ. Mais les projets open-source sont sur GitHub. Pourquoi ? Simplement parce qu’on veut donner de la visibilité à ce qu’on fait et qu’un « réseau social de développeurs » est une bonne solution.

    http://gitlabhq.com/