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

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

agplv3-155x51Suite à 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.

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

5 réponses

  1. Fabien dit :

    Pour un complément d’information / un point de vue différent, il est possible de lire les interventions de Mben en provenance de VeniVidiLibri et notamment :

  2. Philippe dit :

    Merci Fabien pour ces compléments très intéressant.

  3. fredb219 dit :

    Je me trompe peut-être, mais j’ai l’impression que via ton billet est autant une critique de la AGPL que de la GPL.

    Si je réécris quelques paragraphes (comme me le permet la licence) en se considèrant dans le cas d’un éditeur logiciel classique :

    « 1/ Si BSD avait été publié sous licence GLP, Apple aurait simplement décidé de ne pas l’utiliser et aurait cherché une autre solution plutôt que de fournir son propre code. »
    « 2/ La licence GPL n’empêche pas la réutilisation des logiciels open source, elle implique entre autre le reversement des modifications. Dans le cas de MaSuperBoite et de son support de MonCodecMoisi dans son offre MonLecteurVideo, 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 à MonLecteurVideo à son périphérique vidéo que à 2 clients dans le monde. 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 à la GPL pour ces acteurs. »

    « Pour le cas 1/ le fournisseur a l’intention de fournir un logiciel 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 logiciel 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 GPL ne seront par retenues. »

    « La GPL est censé protéger les éditeurs de logiciels open source contre les « réutilisateur » 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. »

    Je considère que la licence GLP dans un contexte de site web ne vaut pas mieux qu’une licence BSD. L’utilisation d’un code GPL pour une service en ligne est équivalente selon moi à une utilisation propriétaire du code.

    Un logiciel libre est sensé présenter ses libertés :

    * Liberté 0 : La liberté d’exécuter le programme — pour tous les usages ;
    * Liberté 1 : La liberté d’étudier le fonctionnement du programme — ce qui suppose l’accès au code source ;
    * Liberté 2 : La liberté de redistribuer des copies — ce qui comprend la liberté de vendre des copies ;
    * Liberté 3 : La liberté d’améliorer le programme et de publier ses améliorations — ce qui suppose, là encore, l’accès au code source.

    Gmail est pour moi un programme. Le programme est constitué du client et du serveur puisque le client est inutile seul.

    * Liberté 0 : On peut dire que GMail respecte à peu prêt cette liberté dont je ne connais pas les subtilités.
    * Liberté 1 : elle n’est pas du tout respecté, et pourtant ça m’intéresserait. Le code source de la page web est tout ce que l’on a et il ne vaut pas beaucoup mieux qu’un code compilé.
    * Liberté 2 : Pas respectée.
    * Liberté 3 : Pas respectée.

    Le code de gmail, coté serveur est peut-être en GPL, utilisant des composant en GPL, mais si c’est les cas, moi utilisateur, je ne peux pas pas profiter des libertés promises.

    Je veux bien que l’on ne rendre pas tout disponible et je comprend que google ai un intérêt à de pas donner les 4 libertés à l’utilisateur (et encore), c’est un choix. Par contre, je ne trouve pas normal que des développeurs qui ont choisis la GPL pour leur logiciel comme garantis de perpétuité de la liberté du code, de la protection de l’utilisateur, et de l’esprit de partage mutuel voient leur code utilisé et pillé par des « applications propriétaires ».

    Bref, à mon avis la GPL à un bug, l’AGPL le corrige et donc résout autant les problèmes de l’opensource pour le cloud computing que la GPL pour les applications classique : elle est bien.

  4. Philippe dit :

    Jolie ré-écriture, j’apprécie 🙂 D’une certaine manière tu as raison, mon article revient alors bien à une critique la GPL aussi, mais ce n’était pas intentionnel.

    Cependant, force est de constater que les outils propriétaires n’utilisent jamais de code sous licence GPL (point 1/). Quand il le font (exemple de Microsoft pour le module de compatibilité Open Office pour Word), c’est quand il n’y a pas d’enjeu si ce n’est de couper à certaines critiques.Et à ce que je sache, Microsoft n’a jamais contribué au développement du format d’Ooo, au contraire il a fait normaliser un format concurrent par l’ISO. Un autre exemple plus d’actualité est le logiciel sous licence GPL accidentellement utilisé par Microsoft pour réaliser la version bootable de Windows 7.

    Mais soyons clair, l’objet de ce billet est surtout de faire un constat des pratiques à ce jour vis-à-vis des licences libres et des contournements ou des biais employés plus qu’une réelle critique de l’AGPL (cf le point d’interrogation 😉 ). Comme je l’indique en fin d’article, l’existence de la GPL et de l’AGPL sont bien sur indispensable. Plus il y aura de code sous ces licences plus le contournement sera difficile. Encore une fois l’exemple de Microsoft et de sa version bootable est excellent.

    Donc oui il faut utiliser la GPL et l’AGPL mais rester conscient aussi des limites. L’existence des licences libres n’empêchera personne de continuer à faire du propriétaire. Sauf que les avantages du libre finiront peut-être par être compris un jour par tous, rendant l’alternative inutile et peut-être nous dirons-nous alors : « Comment a-t-on pu fonctionner ainsi pendant aussi longtemps ? »

  1. 3 décembre 2009

    […] This post was mentioned on Twitter by Philippe and Planet-Libre, Azure Magic. Azure Magic said: La licence AGPL résout-elle tous les problèmes de l’open source et du cloud computing ?- Suite à … http://bit.ly/56IUMm […]