La licence AGPL résout-elle tous les problèmes de l’open source et du cloud computing ?

Suite à mon article sur le cloud computing et à la menace potentielle qu’il peut représenter pour l’open source,  je continu sur ma lancée et je profite de ce billet pour rebondir sur la question de Nico.P :

Je croyais que le but de la licence GNU AGPL était justement de résoudre le problème potentiel ?!

Déjà, commençons par rappeler ce qu’est la licence AGPL ou GNU Affero General Public License :

C’est une licence libre dérivée de la Licence publique générale GNU avec une partie supplémentaire couvrant les logiciels utilisés sur le réseau.

Elle a été écrite par Affero pour autoriser les droits garantis par la GPL à couvrir les interactions avec des produits propriétaires à travers un réseau comme Internet, ce que la GPL ne fait pas.

Affero Inc. est une société fondée en 2001, qui gère un site Web destiné à permettre la présentation, l’évaluation et le financement de projets à but non-lucratif. La première version de cette licence n’était pas compatible avec la GPL. La version 3 est en revanche compatible avec la version 3 de la GPL.

[Source Wikipédia]

Le décor est posé, la licence AGPL a été créée pour prendre en compte l’arrivée des services en ligne construit sur la base de logiciels open source. Autrement dit, une offre de could computing utilisant un logiciel sous licence AGPL doit rendre public les modifications effectuées sur le logiciel en question. Cette obligation n’existe pas sur la licence GPL par exemple, mais aussi sur d’autres licences. Un manque qui est souvent mis à profit par les grands du cloud computing.

Revenons-en à la question de Nico.P et voyons en quoi cette licence ne résoudrait pas tous les problèmes. Matthew Aslett, encore lui, a publié un billet dans lequel il évoquait au moins trois raisons :

1/ Si MySQL avait été publié sous licence AGPL, Google aurait simplement décidé de ne pas l’utiliser et aurait cherché une autre solution plutôt que de fournir son propre code. Il fait allusion au refus de Google de permettre cette licence pour les projets déposés sur Google Code.

2/ La licence AGPL n’empêche pas le déploiement des logiciels open source sur le réseau , elle implique juste le reversement des modifications. Dans le cas de Microsoft et de son support de MySQL et Tomcat dans son offre Azure, on peut se poser la question de l’intérêt des modifications apportées. Car si modification il y a, elle doivent être très spécifiques à Azur ou dans le cas d’Amazon à sa plateforme AWS. Si c’est le cas, les modifications ne seraient probablement d’aucun intérêt pour qui que ce soit. Cela ferait alors perdre son intérêt et son effet repoussoir à l’AGPL pour ces acteurs.

3/ La licence AGPL ne convient pas aux fournisseurs de services qui veulent encourager des tierces parties à la mise à disposition d’applications en ligne conjointement à la leur. En effet, l’adoption de l’AGPL pour un logiciel devant en intégrer d’autres peut potentiellement forcer le partenaire à publier son propre code sous cette licence.

Les objections 1/ et 2/ à l’intérêt de l’AGPL résident dans la part de modifications qui apportent une réelle plus-value au logiciel et celles qui relèvent simplement de l’adaptation technique à l’environnement d’hébergement. Dans le point 1/ les améliorations peuvent procurer un avantage au fournisseur de service. On se trouve donc face à des stratégies différentes.

Pour le cas 1/ le fournisseur a l’intention de fournir un service pour lequel il a besoin de logiciels open source pour les économies de licences et pour l’ouverture du code. Ce sont des avantages pratiques. La finalité est de délivrer un service le plus performant possible au moindre coût. Les modifications apportées ici relèvent bien de l’amélioration du logiciel. Mais ces améliorations doivent rester « secrètes » pour ne pas permettre à  un concurrent d’en profiter. La licence influera donc naturellement sur le choix du logiciel. Les logiciels sous licence AGPL ne seront par retenues.

A l’inverse dans le cas 2/, la finalité est juste de mettre à disposition le logiciel en l’état, car l’offre n’existe pas. Alors, la licence AGPL ne représente pas un obstacle. Mais les retours en terme de reversement de code resteront faibles. C’est le cas de tous ces services qui proposent d’héberger des applications open source. La plus-value est dans l’hébergement et ces conditions financières.

L’AGPL est censé protéger les éditeurs de logiciels open source contre les « cloudificateurs » d’application indélicats. Mais dans les faits il semblerait soit qu’elle représente un obstacle soit qu’elle ne protège en rien. Dans les deux cas, c’est une source de revenu potentiel qui disparaît. La démarche la plus certaines pour un éditeur souhaitant commercialiser une offre Saas pour son logiciel consiste à prendre le problème en main et à s’assurer par un partenariat efficace avec un spécialiste de l’hébergement d’application afin de s’assurer une part de revenue sur l’offre.

Comme souvent la vérité est sûrement à mi-chemin et des exemples concrets vous viendront peut-être à l’esprit. Pour l’instant je resterais sceptique sur l’apport de l’AGPL même si je ne remets pas en cause  ni l’intérêt ni la nécessite de son existence. Mais je ne suis pas sûr qu’elle contribue à changer le paysage des services en ligne.

Vous devriez peut-être lire ces articles sur le même sujet

1. Enomaly Elastic Computing Platform, solution open source de cloud computing
2. Xen Cloud Platform, la solution open source de cloud computing de Xen.org
3. 5 outils open source pour le cloud computing
4. Le cloud computing peut-il tuer l’open source ?

La liste des entrées complémentaires est établie par le module d’extension YARPP.

Article original écrit par Philippe Scoffoni le 03/12/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).