Pourquoi les services web devraient être distribués comme des logiciels libres

Cet article a été publié il y a 13 ans 3 mois 22 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Ce billet m’est inspiré par un article paru sur le site O’Reilly Radar.

Dans le monde du logiciel traditionnel, j’entends par là ceux que nous utilisons sur nos ordinateurs, les logiciels propriétaires ou privateurs existent, car leur créateur souhaite se créer une rente de situation en restreignant la possibilité pour d’éventuels concurrents de copier son logiciel, de l’améliorer et enfin de lui voler « ces clients ».

Une logique que le logiciel libre combat depuis de nombreuses années.

Voici venir le cloud computing et plus précisément l’avènement du web des services en ligne. Leur apparition date d’ailleurs d’avant « l’invention » du cloud computing. Ils ont juste été réintégrés dans cette nouvelle famille d’application informatique portée par internet.

Les services web ont fourni une nouvelle façon de contourner les règles imposées par les licences des logiciels libres. Il est en effet possible de proposer un service web basé sur un logiciel libre que l’on a modifié sans pour autant en publier les sources. Un extrait d’un article sur la réutilisation du code placé sous une licence open source :

1. Ce sont des services web pas des logiciels distribués à des utilisateurs comme ceux que l’on peut installer sur son poste. L’obligation de redistribution des codes sources n’existe pas en général, d’où la création de l’AGPL pour essayer de combler cette faille.
2. Des licences comme Apache (la licence pas le serveur) permettent de placer sous la même licence ou sous les termes d’une autre licence une version modifiée du logiciel, donc éventuellement une licence non libre. Un exemple, le serveur Web Apache est utilisé (sous forme modifiée) par IBM dans son serveur d’applications propriétaire WAS (WebSphere Application Server).

Les éditeurs de service web sont de fait à nouveau en mesure de protéger le code d’un concurrent potentiellement plus malin.

Les exemples ne manquent pas. Facebook, Twitter et bien sûr le plus gros d’entre eux : Google. Tous contribuent à des briques de logiciels libres ou open source qu’ils assemblent pour leurs services en ligne.

Peut-on les convaincre de ne pas craindre l’ouverture du code de leur service ?

Il faut donc leur apprendre à dépasser la traditionnelle crainte des éditeurs de logiciel privateur : je libère mon code, on le copie, l’améliore et on me prend mes clients. Si un service rend disponible son code sous une licence AGPL par exemple, qui que ce soit qui l’améliore et l’utilise sur un autre site web doit légalement rendre publique les améliorations. Cette licence lève cette crainte, car le code reste toujours disponible même s’il est amélioré.

Andy Oram, propose des arguments selon lesquels les services web gagnent des visiteurs grâce à des caractéristiques qui ne sont pas forcément liées au code :

• La disponibilité du service ( cela parait évident, mais ce n’est pas toujours le cas),
• Les effets de réseau qui font que les gens invitent leurs amis à venir sur le site web où ils sont donnant ainsi un avantage à celui qui met le premier le service en ligne,
• L’apparence du site, les guides visuels à la navigation ce qui inclus des aspects qui peuvent être déposés sous forme de marque,
• Une API bien conçue qui facilite la connexion avec d’autres services web.

En fin de compte, le code ne serait pas si important pour un service web. Imaginons que Google ouvre le code de son moteur de recherche. Qu’un malin tente de mettre en ligne un Google libre de publicité. Premièrement il n’aura pas les peta-octets de données accumulées par Google ni l’infrastructure pour délivrer un service équivalent. Mais il pourrait y avoir des mini-Google sur des thématiques particulières sans que cela fasse probablement de l’ombre à Google.

Mais le moteur de recherche de Google est peut-être un mauvais exemple, car dans ce cas-là si l’algorithme de classement devenait public il serait peut-être plus facile de le manipuler. On constate cependant que certains y arrivent très bien malgré le secret qui l’entoure.

Un scénario a peu prêt identique pourrait être avancé pour les services Gmail, GReader, etc… Je pense que Google pourrait libérer tout son code que cela ne changerait plus grand-chose pour lui dans l’immédiat. Il a l’avance que lui procure son infrastructure informatique que l’on a tendance à souvent oublier derrière la simplicité et les performances affichées.

Mais pour l’instant Google se contente de libérer les services web qui ont échoué à l’image de Google Wave qui a été repris par le projet Apache.

Pour finir on me souffle dans mon oreillette StatusNet de ne pas oublier de mentionner le TIO Libre qui définit les caractéristiques d’un service libre. Une définition que j’ai utilisé notamment pour évaluer des offres de services web de type Saas (Software as a Service) à destination des entreprises comme TioLive ou encore Odoo.

Crédit image Certains droits réservés par c__