1. Historique de la licence

1.a La découverte de l’ « ASP Loophole »[1] de la GNU GPL

La version 2 de la GNU GPL, licence libre (encore) la plus utilisée, date de 1991. À cette époque, le logiciel était très fortement attaché à son support : la mise à disposition de l’un s’entendait donc par la distribution de l’autre, d’où l’idée d’attacher les effets de la GNU GPL à cette notion de distribution. Ainsi, le licencié disposait d’une sphère privée dans laquelle il est libre d’agir sans contrainte et dès lors qu’il distribuait le logiciel à un autre, il devait respecter l’ensemble des obligations imposées par la licence. Très attachée à cette sphère privée, on trouvait même une critique sur le site de la FSF à l’égard d’autres licences qui ne l’accordaient pas[2].

Mais, le développement d’Internet, la démocratisation des ordinateurs et des accès à Internet ont favorisé l’émergence et l’importance de l’utilisation de logiciels en tant que services. La réflexion et la compréhension entourant ces licences s’améliorant, la « faille » de la GNU GPL fut rapidement mise à nue et critiquée : tout licencié était en effet libre, en utilisant le logiciel en tant que service, de bénéficier pleinement des développements de ces pairs sans avoir lui-même à partager ses propres contributions puisqu’il ne « distribuait » pas le logiciel (d’où d’ailleurs une réapparition d’une logique de licence à l’utilisation). L’explication est simple :

  1. L’utilisateur accède via son navigateur au site du licencié ;
  2. À la demande de celui-ci, son logiciel client va envoyer une requête au licencié ;
  3. Celui-ci traitera cette requête en interne sur ces propres PC hébergeant le logiciel (et donc le service) ;
  4. Le licencié enverra la réponse sans jamais avoir distribué le logiciel (l’utilisateur bénéficiant uniquement de ses fonctionnalités – non soumises au droit d’auteur).

L’accès au logiciel est donc totalement opaque et la distribution matérielle inexistante, ce qui rend caduque le copyleft de la GNU GPL et justifie l’apparition de la licence Affero.

1.b L’ASP Loophole et les autres licences

Il est intéressant de relativiser l’apport de la licence. En effet, on s’aperçoit qu’elle ne vient pas s’intéresser à un sujet jusqu’ici négligé par d’autres, mais seulement par les licences GNU : bien d’autres licences, avec des mécanismes divers, appréhendaient, elles aussi, cette utilisation par le réseau. Ainsi, citons l’Honest Public licence 1.1, l’Open Software licence 3.0, la Reciprocal Public License 1.5 et la Common Public Attribution Licence 1.0.

L’Honest Public License

Fabrizio Capobianco est l’auteur de l’Honest Public License : une GNU GPL modifiée (unilatéralement, mais la FSF le permet dès lors que le préambule n’est pas repris) pour couvrir l’usage des logiciels par le réseau (voir les modifications).

Ainsi, une section 2 (d) est ajoutée à cette fin[3] ainsi que la notion de « communication de l’œuvre au public »[4]. « Dans l’objectif de déterminer le droit d’obtenir une copie du code source » (ainsi que le droit de modifier et distribuer ce code source et code objet), le terme distribution doit inclure la communication du Programme ou œuvre basée sur le Programme qui est conçu(e) pour interagir avec des utilisateurs tiers (on entend ainsi toute autre personne que vous, ainsi qu’une société, en tant qu’entité non individuelle), au travers d’un réseau d’ordinateurs et l’utilisateur doit avoir le droit d’obtenir le code source du Programme ou œuvre basée sur le Programme. Cette stipulation est une condition expresse pour le bénéfice de la licence qui suit et toutes ces communications doivent être considérées comme distribution selon les termes des Sections 1, 2 et 3[5].

L’Open Software License 3.0 :

Rédigée par Lawrence Rosen, l’OSL encadre depuis longtemps déjà cet usage par le réseau. Dans son article 5, l’OSL encadre l’usage des logiciels en tant que services en leur qualité de déploiement externe. Le terme « déploiement externe » signifie l’utilisation, la distribution ou la communication de l’œuvre originale ou des œuvres dérivées de quelque façon que l’œuvre originale ou les œuvres dérivées puissent être utilisées par toute autre personne que vous, même si ces œuvres sont distribuées ou communiquées à ces personnes ou rendues disponibles sous forme d’application conçue pour une utilisation par le réseau. Comme une condition expresse au bénéfice de la licence qui suit, Vous devez traiter tout déploiement externe par vous de l’œuvre originale ou d’une œuvre dérivée comme une distribution soumise à la section 1(c).[6]

La Reciprocal Public License 1.5

Assez critiquée, la RPL réduit considérablement la sphère privée concédée au licencié : seules la recherche ou l’utilisation personnelle du logiciel ne sont pas soumises à la redistribution du logiciel, de ses modifications et de ses sources. Pour faire simple, la licence traduit un désir de clore les failles des versions précédentes des licences open source, failles qui permettaient à des parties d’acquérir des logiciels libres et d’en tirer des bénéfices financiers sans avoir à communiquer leurs améliorations ou dérivés à la communauté qui leur permet d’exister. Ceci se confirme chaque foi qu’une entité ne distribue par son application à une partie tierce [7]

Article 1.2 : « Déployer » signifie utiliser, servir, sous-licencier ou distribuer le logiciel soumis à la licence autrement que pour Votre recherche interne et/ou votre Utilisation Personnelle, et incluse sans limitation, toute utilisation personnelle ou distribution du logiciel soumis à la licence au sein de votre société ou entreprise pour autre raison que la Recherche et/ou l’utilisation Personnelle, de la même façon que les sous-licenciements directs ou indirects du logiciel soumis à la licence par vous ou toute autre partie tierce de quelque façon que ce soit[8].

La Common Public Attribution License Version 1.0 (CPAL)

La CPAL est assez classique en rajoutant un article 15 : « Terme additionnel : utililisation réseau ». Le terme « déploiement externe » signifie l’utilisation, distribution ou communication du Code Original ou des Modifications d’une façon telle que le Code Original ou des Modifications puissent être utilisés par toute autre personne que vous, que ces œuvres soient distribuées ou communiquées à ces personnes ou rendues disponibles comme une application destinée à une utilisation sur le réseau. Comme une condition expresse pour le bénéfice de la licence qui suit, Vous devez traiter tout Deploiement externe par Vous du Code Original ou des Modifications comme une distribution conforme à la Section 3.1 et rendre le Code Source disponible conformément à la section 3.2[9].

Le comportement de la CeCILL

Il convient de signaler sur ce point l’absence de prise en compte de ce phénomène par la licence CeCILL. De plus, malgré l’absence d’une clause expresse, spécifique à l’utilisation sur le réseau, ses auteurs affirment dans leur FAQ qu’« une mise à disposition via un site Web ou un serveur est donc bien une distribution même si l’utilisateur ne dispose pas d’un exemplaire du logiciel en propre, et l’obligation de fournir le code source du logiciel modifié s’applique ».

Or la distribution ainsi envisagée par la licence —article 5.3.2 de la licence Cecill— n’est en rien différente de la notion légale et il n’y a donc aucune raison d’étendre la notion de distribution à l’utilisation du logiciel sur réseau (la valeur juridique des FAQ n’étant bien sûr pas supérieure à celle des licences et seule celle-ci à valeur entre les parties).

Il y a aussi bien sûr l’Affero GPL.

1.c Un besoin manifesté par la Société Affero

L’écriture de la licence

Le 1er mars 2002, la société Affero, assistée de la FSF, publie une licence nommée Affero GPL (notez l’absence du préfixe GNU puisque le projet n’était alors pas initié par la FSF[10]. Cette licence se veut très proche de la GNU GPL qu’elle adapte aux spécificités de l’utilisation par le réseau[11] et prévoit même la compatibilité expresse avec la GNU GPL v3 (précédant ainsi le processus de révision). Elle est alors pleinement soutenue par la FSF.

Je me souviens avoir étudié cette licence dans sa première version il y a quelques années. J’avais alors écrit ce qui suit :

La « technique » employée est assez novatrice : si le programme en question est destiné à interagir avec les utilisateurs par le réseau, et que la version reçue donnait la possibilitée à l’utilisateur de télécharger le code source, alors le licencié ne peut pas supprimer cette option. […] L’application de cette clause dépend de l’évolution du logiciel : tant que le logiciel fait l’objet d’une distribution « traditionnelle », les dispositions de la licence GNU GPL trouvent à s’appliquer, et dès lors que l’un des licenciés utilise sa version sur Internet en conférant la possibilité de télécharger le code source, alors les licenciés subséquents continueront de disposer du code source dans les mêmes conditions. Dans cette hypothèse, le licencié ne dispose plus d’un droit de distribuer, mais d’une obligation dès qu’il réutilise le logiciel sur Internet, rendant ainsi ses contributions disponibles. En effet, il y a bien ensuite une distribution au sens de la GNU (et donc Affero) GPL qui s’effectue lors du téléchargement du code source : le licencié se voit imposer d’y adjoindre la licence sur l’ensemble, logiciels et œuvres dérivées. Par ce subterfuge, la distribution du logiciel se retrouve liée à son utilisation sur Internet.

Bien évidemment, la licence était considérée comme libre par la FSF (une réponse que m’avait donnée Richard Stallman il y a quelques années à ce sujet : « Ces licences n’interdisent aucune modification dans les fonctionnalités du logiciel. C’est ce qui compte. »[12], mais était rejetée par la communauté Debian qui refuse par principe toute intangibilité dans le code (à l’instar des sections invariantes de la GFDL) ou simple limitation dans la liberté de modifier.

D’autres détails restaient problématiques[13], mais il suffisait de considérer que, comme toute première version, elle restait perfectible (je restais pour ma part résolument tourné vers l’Open Software License qui s’était améliorée en prenant en considération les commentaires de l’étude commandée par l’IDABC). Ces problèmes étaient d’autant moins gênants que la licence était originairement transitoire : la GNU GPL version 3 devant rectifier la faille qui justifiait l’Affero GPL.

Une intégration dans la GNU GPL v3 manquée

Tournée vers l’avenir, l’Affero GPL contenait une clause permettant de relicencier le logiciel sous GNU GPL v3[14], afin d’unifier rapidement tous les logiciels sous une licence unique répondant à cette problématique de l’usage par le réseau (considérée, tout comme la tivoïzation), comme une déviance qu’il conviendrait de corriger lors de la nouvelle version de la GNU GPL.

Au moins deux mécanismes auraient pu prévoir cette intégration :

  • Incorporer directement le mécanisme développé pour l’Affero GPL dans la nouvelle GNU GPL (« en dur ») ;
  • Ajouter ce mécanisme dans la liste des clauses qui pouvaient moduler la portée de la GNU GPL afin de rendre cette dernière compatible avec l’Affero GPL (par le mécanisme de l’article 7).

Contrairement à ce que la FSF avait laissé entendre, ce fut la dernière solution qui fut initialement retenue (encore prévue à l’article 7b.4 dans le second jet de la troisième version), mais un accueil mitigé — voire glacial — motiva sa suppression dans les propositions qui suivirent[15]. Dorénavant, la GNU GPL précise expressément qu’un tel usage n’est pas soumis à la licence et prévoit seulement une compatibilité[16].

Ce fut un tollé, certains n’hésitant pas à affirmer que la « GPL est la nouvelle BSD ». D’autres ont simplement regretté ce choix, peu réellement justifié par ailleurs — d’où l’appellation « SHING GPL » (« Sun HP IBM Nokia Google », principaux bénéficiaires/lobbyistes de cette clause).

La situation est d’autant plus précaire pour ceux qui avaient adopté la première version de l’Affero GPL puisqu’elle permettait la redistribution du logiciel sous GNU GPL v3 (pensant que cette utilisation par le réseau serait incorporée) : ils se retrouvent donc potentiellement avec une simple GNU GPL v3, n’encadrant plus l’usage qu’ils souhaitaient éviter de leur logiciel (et il n’est même pas certain que les logiciels sous Affero GPL puissent être licenciés sans autorisation des titulaires de droits sous GNU Affero puisque la compatibilité n’était assurée qu’à l’égard de la GNU GPL v3 et des versions ultérieures publiées par Affero…[17]) !

En parallèle, la FSF lança un nouveau chantier dans l’intention de faire de l’Affero GPL une licence autonome et périphérique à la GNU GPL : la GNU Affero GPL, qui viendrait côtoyer la GNU GPL à l’instar des autres licences libres (bénéficiant par ailleurs d’une dérogation spécifique dans l’article 13 de la GNU GPL[18]).

La publication d’une nouvelle version

Comme nous l’avions annoncée le jour de sa sortie, la nouvelle version de la GNU AGPL a été publiée le 19 novembre 2007 afin de compléter les offres de licences logicielles de la famille GNU : reprise en main par la FSF, la nouvelle version de la GNU Affero GPL paraît à grand bruit et avec de grandes ambitions.

De nombreux reproches à l’encontre du processus d’élaboration des licences de la FSF ont été émis, dont notamment celui d’un manque chronique de transparence. En effet, si la publicité de chaque version est incontestable, il ne l’est pas moins que les amendements et décisions prises d’une version à l’autre furent peu transparents[19], ce qui explique en partie les ressentis négatifs (des personnes s’étant investi sur les diverses versions, sans voir leurs travaux considérés — ou parfois modifiés avant publication, de sorte à correspondre aux modifications choisies). Je considère pour ma part que la consultation qui était faite auprès des milliers/millions de personnes n’étant pas tant pour intégrer leurs commentaires, mais seulement pour, éventuellement, s’en inspirer.

Ainsi, je ne porte aucune accusation contre le processus de révision des licences : la coordination nécessaire pour une telle révision dépassant à l’évidence les ressources d’une structure associative, serait-ce la FSF. Je regrette simplement dans ce type de situation la légitimité que l’on retire d’une situation qui n’est pas forcément conforme à l’image que l’on donne. À mon sens, la transparence nécessaire à une structure communautaire comme la FSF dépasse largement celle qui peut être demandée à l’encontre de toute entreprise et j’estime malheureusement trop souvent que cet objectif n’est pas atteint[20].

La labellisation par l’OSI

Conformément à la procédure indiquée en ce billet (la procédure de certification devant l’OSI passe nécessairement par toute une série d’étapes, initiée par une proposition de labellisation sur la liste review), la licence GNU Affero GPL fut proposée à labellisation. Ci-après un rapide résumé de la procédure :

Historique :

Rapide résumé de la procédure déroulée pour la labellisation de la licence.

  1. Le 30 janvier 2008, Stefano Maffulli (agissant à titre d’exception puisque la procédure est en principe réservée au rédacteur des licences) propose la certification de la licence GNU Affero GPL. Voici une proposition de traduction du courrier ayant initié la procédure :

    « Funambol a adopté la licence GNU Affero GPLv3 (« AGPLv3 ») et souhaite soumettre la licence AGPLv3 à l’OSI pour labellisation. La précédente Affero General Public License (« AGPLv1 ») n’a jamais été soumise à l’OSI pour labellisation, mais était réellement différente de la AGPLv1, son historique n’est donc pas opportun. La AGPLv3 est destinée à fermer la faille ASP (« ASP loophole ») en s’assurant que les modifications de tout programme qui est expressément destiné à accepter les requêtes des utilisateurs et à envoyer les réponses à travers le réseau, soient effectivement disponibles aux utilisateurs à travers le réseau. »

  2. Le 28 février 2008, Stefano Maffulli relance la discussion, car la licence n’était pas dans la liste des licences certifiées en janvier 2008 (License committee report for January 2008).
  3. Le 11 mars 2008, dans le “License committee report for March 2008”, Russ Nelson indique la labellisation de la licence :

    “I’m the chair of the license approval committee. This is my report for the current set of licenses under discussion. This finishes up the licenses submitted to license-discuss.
    Title: GNU Affero General Public License Submission:
    http://crynwr.com/cgi-bin/ezmlm-cgi?17:mss:59:apmcgapodhnnfmpgpnmb
    License: http://www.fsf.org/licensing/licenses/agpl-3.0.html
    Comments: Cowan, Moen approve, no one disapproves
    Recommend: approval”

L’affaire est dans la poche !

Après relecture, les échanges se sont bien limités à sept courts e-mails, sur deux jours, portant principalement sur des détails (dans quelle catégorie serait classée la licence : “Other/Miscellaneous licenses”, “Special purpose licenses.”, etc. – la proposition initiale étant évidement “Licenses that are popular and widely used or with strong communities”.). Un point de droit, plus trollogène, fut mis en avant (de la part d’un dénommé A. T., se basant sur l’article 17 U.S.C. 117 (a)(1) et une décision d’une cour américaine (Aymes v. Bonelli, 47 F.3d 23 (2d Cir. 1995)) pour suggérer que les restrictions imposées par l’AGPL au possesseur légitime d’une copie du logiciel dépassaient les prérogatives d’un titulaire de droits. Intéressantes, mais hors sujet[21], ses questions sont restées sans réponse.

Là-dessus, arrêt des échanges sur la liste, une exclusion d’A. T. (jugé trop bruyant), on apprend discrètement que la licence est labellisée « Open Source ». On apprend peu de temps après la nouvelle par une annonce plus « bruyante » sur le blog de Stefano Maffulli :

« Dorénavant, il ne reste plus qu’aux développeurs de comprendre qu’utiliser la GPL v3 à la place de la AGPL v3 est juste idiot. Votre logiciel va être utilisé comme un service, sinon aujourd’hui, ce sera dans quelques années. Oui, VOTRE logiciel. Tout est en train d’être utilisé comme service, même les traitements de texte… Ils peuvent prendre et ne rien reverser en échange à votre communauté. Wavemaker est intelligent et ils utilisent aujourd’hui l’AGPL. Bien d’autres suivront[22]. »

(voir l’article)

Quoi que l’on en dise, voilà une procédure bien surprenante pour une licence destinée à bouleverser le monde du logiciel libre.

2. Étude de la licence

Réfléchir sur la licence nous met rapidement face à un dilemme : l’importance de la sphère privée, dans laquelle chacun est roi et n’a pas à rendre de compte ; le déséquilibre d’une situation où une personne se sert des contributions offertes par d’autres sans lui-même redistribuer ses propres modifications[23]. C’est d’ailleurs ce que rappelle la FAQ de la GNU GPL[24].

Là-dessus, il faut reconnaître l’effort de la FSF pour mettre en place des outils juridiques qui collent aux objectifs que se donne la fondation. En effet, on a vu d’autres licences, comme les licences CeCILL, adopter une attitude autre en ajoutant au sein de la FAQ du site qu’un tel usage serait une distribution[25]. À l’inverse, la GNU GPL reconnaît sa faiblesse et renvoie à une licence sœur pour y remédier.

Pour comparaison, une licence à l’effet assez similaire, la « Reciprocal Public licence », était jugée non libre par la FSF au motif, notamment, qu’elle requerrait la publication des modifications mêmes privées (pour la RPL, tout acte ayant une finalité autre que la recherche interne ou une utilisation personnelle est considéré comme une diffusion). On ne peut ici nier une mutation au sein du paradigme de la FSF.

2.a Perception de la licence

À la lecture des différentes listes, on se rend rapidement compte que les avis divergent sensiblement : l’extension au SaaS est vue par certains comme une appréhension logique et nécessaire par la FSF ; d’autre, au contraire, y voyant un recul fort des libertés.

Quelques exemples tirés de la liste « Free Software for Business »[26]:

  • « Mon opinion est que l’existence d’une licence logicielle compatible avec la GPL et approuvée par la FSF qui comble la « faille des applis web » développera le secteur des modèles de business basés sur des familles de double licenciement pour les applications web hébergées interagissant avec les utilisateurs, particulièrement les cas où ce type d’applications participe d’une écologie qui a ses propres effets de réseau (par le partage ou la fédération de données, par exemple)[27]. », Michael R. Bernstein ;
  • « L’AGPL supprime la liberté de ne pas partager, qui est la même chose que la liberté de partager[28]. », Thomas Lord ;
  • « Je ne pense pas que Matt Asay va trop loin lorsqu’il dit que la “GPL est la nouvelle BSD” [29] », Luis Villa.

Et bien d’autres : notamment Michael R. Bernstein sur la combinaison interface/outil[30], João Miguel Neves sur le double licenciement[31], Michael R. Bernstein qui envisage la situation où front-end et back-end seraient entre les mains de personnes différentes[32] et Don Marti qui cite Tim O’Reilly — voir aussi cet autre article qui cite O’Reilly[33].

2.b Analyse de la licence

Je pensais initialement dresser un tableau des diverses analyses qui avaient pu paraître, mais le résultat manquait de netteté. Je vais donc procéder à ma propre analyse en renvoyant lorsque nécessaire aux commentaires qui ont pu être faits (principalement sur debian-legal).

L’article 13 et l’interaction par le réseau

Voici une traduction « maison » de la clause qui distingue la GNU Affero GPL de la GNU GPL :

Nonobstant toute autre provision de la Licence, si vous modifiez le Programme, votre version modifiée doit mettre en évidence l’offre pour tout les utilisateurs interagissant à distance via le réseau (si votre version supporte une telle interaction) une possibilité de recevoir les Sources Corresponsantes de votre version en fournissant un accès aux Sources Correspondantes par un serveur réseau sans frais supplémentaire, au travers de moyens standards ou habituels facilitant la copie du logiciel. Ces Sources Correspondantes doivent inclure les Sources Correspondantes pour toute œuvre logicielle couverte par la version 3 de la GNU General Public licence qui est inclue conformément au paragraphe suivant[34].

Une compatibilité expresse est décrite dans le second paragraphe :

Nonobstant toute autre provision de la Licence, vous avez la permission de lier ou combiner toute œuvre logicielle licenciée sous la version 3 de la GNU General Public licence en une simple œuvre combinée et de diffuser l’œuvre résultante. Les stipulations de cette licence continueront à s’appliquer à la partie couverte de l’œuvre, mais l’œuvre avec laquelle elle est combinée continuera d’être gouvernée par la version 3 de la GNU General Public License[35].

Je résume : dès lors que des utilisateurs peuvent interagir à distance avec le logiciel sous GNU Affero GPL (ou sous GNU GPL avec la section relative à l’utilisation interactive) qui a été modifié par X, alors X doit rendre disponible le code source correspondant au logiciel modifié. Je ne suis pas certain que la licence envisage expressément l’extension au logiciel global, mais on peut déduire celle-ci de la brique distribuée : si celle-ci est distribuée alors les autres stipulations « classiques » de la licence s’enclenchent et demandent la distribution du tout. Les « Sources Correspondantes » trouvent leur définition à l’article 1 de la GNU Affero GPL, dont la traduction qui figure ci-après est tirée d’une traduction non officielle de Philippe Verdy :

Le « Source Correspondant » d’un travail sous forme de code objet signifie l’ensemble des codes sources nécessaires pour générer, installer et (dans le cas d’un travail exécutable) exécuter le code objet et modifier le travail, y compris les scripts pour contrôler ces activités. Cependant, cela n’inclue pas les Bibliothèques Système du travail, ni les outils d’usage général ou les programmes libres généralement disponibles qui peuvent être utilisés sans modification pour achever ces activités mais ne font pas partie de ce travail. Par exemple le Source Correspondant inclut les fichiers de définition d’interfaces associés aux fichiers sources du travail, et le code source des bibliothèques partagées et des sous-routines liées dynamiquement, pour lesquelles le travail est spécifiquement conçu pour les requérir via, par exemple, des communications de données ou contrôles de flux internes entre ces sous-programmes et d’autres parties du travail.[36]

Bien évidement, l’étendue reste la même que celle d’une GPL classique, c’est-à-dire que non seulement les modifications doivent être distribuées, mais aussi le logiciel dans son entier (puisque l’on parle de version modifiée) : « le travail entier, comme un tout ».

Je trouve cette nouvelle clause particulièrement mal écrite :

  • À partir de quand y a-t-il modification ? Doit-on ici songer aux simples paramétrages, exclus de tout droit d’auteur — et alors la licence s’applique systématiquement dès installation.
  • Votre version : est-ce seulement la brique que l’on a modifiée ou la notion s’étend-elle (comme je le crains) au logiciel plus complexe dans lequel elle s’inscrit ? (voir notamment un témoignage de Sean Kellog, démontrant que dans sa situation l’interaction pouvait parfaitement s’entendre au serveur Apache[37]). Argument confirmé par John Halt [38] en prenant pour lecture la FAQ de la FSF qui précise quand est-ce que l’interaction est caractérisée (ce point sera étudié dans l’analyse). À ce sujet, Sean Kellog fit remarquer le flou qui entoure dorénavant le code qui doit être offert : c’était le code source correspondant au binaire distribué pour la GNU GPL, c’est maintenant beaucoup moins clair dans le cas de l’Affero GPL[39].
  • Qu’est-ce que des moyens standards ou habituels ? Et quand cessent-ils de l’être ou le deviennent-ils ?
  • Qu’est-ce qu’un utilisateur et une utilisation (on retrouve ces questions chez Fransesco Poli, au sein d’un commentaire assez virulent — mais pertinent — à l’encontre de la licence[40].
  • Lorsque le logiciel est sous GNU GPL et possède certaines de ses briques sous GNU Affero : la version modifiée s’entend d’une version incluant des fichiers sous GNU Affero GPL, ou toute partie ?
  • Plus généralement, ainsi que le suggère Fransesco Poli : “Where do we draw the line?” (« Où est la limite ? ») :

    « Si le programme est expressement conçu pour accepter les requêtes d’utilisateur et leur envoyer des réponses par le réseau, alors il remplit ces critères. Les exemples typiques de programmes qui ressortent de cette catégorie incluent les serveurs web et mails, les applications web interactive et les serveurs pour les jeux qui se jouent en ligne[41]. »

    « Si un logiciel n’est pas expressement destiné à interagir avec un utilisateur via le réseau, mais qu’il fonctionne dans un environnement qui lui confère cette interaction, alors il ne ressort pas de cette catégorie. Par exemple, une application ne nécessitera pas les sources simplement parce qu’elle est utilisée par tunnel SSH ou session distante.[42]. »

John Halton tempère cet argument par la notion (à mon sens malvenue, car trop imprécise) de “common sense” (on pourrait dire de « bon sens ») pour limiter la portée de la licence[43]. Il ajoute néanmoins une précision intéressante lorsqu’il indique que l’élément déclencheur de la GPL est la distribution, alors que celui de la GNU AGPL est la réunion d’une modification et de l’interaction avec les utilisateurs.[44]

L’interprétation extensive de la FSF

Comme on pouvait s’y attendre, la FSF s’engouffre dans l’interprétation qui peut être faite de sa licence afin de lui faire porter l’effet le plus large. Iain Nicol a pu préciser que la FSF cherchait à étendre aussi largement que possible l’étendue de la licence[45]. Je suis pour ma part très réservé quant à l’interprétation qui doit être faite de cet article 13, rejoignant sur ce point encore une fois Fransesco Poli lorsqu’il demande pourquoi la clause n’a pas été écrite de façon à couvrir uniquement les logiciels « destinés » à supporter une interaction si c’est ce qui est recherché[46].

Un autre problème se pose d’ailleurs lorsque le programme est modifié de façon à ne plus interagir, ou inversement : quelles sont les conséquences sur la clause [47] ?

3. Conclusion : faut-il et peut-on sans crainte utiliser la GNU Affero GPL ?

La première question consiste à se demander s’il faut, ou non, chercher à combler l’ASP loophole : je considère sans hésitation que cette faille rompt l’équilibre qui peut être recherché par l’utilisation de licences copyleft et donc la confiance qui permet à toute sorte de contributeurs de se retrouver autour d’un projet commun. Donc, oui — et peut-être même sans exception —, une telle utilisation par laquelle un licencié modifie et utilise un logiciel pour fournir un service (a minima lorsqu’il remplace la distribution physique pour l’utilisateur, mais de façon plus générale dès lors que le licencié bénéficie d’un travail réalisé par d’autres en amont) doit s’accompagner d’une mise à disposition des sources à la destination des éventuels contributeurs — la différence venant du fait que ceux-ci seront probablement des concurrents proposant le même service, mais c’est cette compétition/concurrence saine qui doit permettre un développement optimal et pérenne du logiciel.

Quant à l’utilisation d’une licence en particulier, la conclusion est difficile tant il est dur de faire sans/contre la FSF. Il me semble simplement important de réaliser que différentes licences appréhendent parfaitement, voire mieux, cette utilisation du logiciel en tant que service. Ainsi, de la même façon que les développeurs ont toujours eu le choix entre plusieurs licences, c’est à eux qu’il revient de déterminer la licence qui leur convient pour leur logiciel utilisé en SaaS.

J’ai pendant longtemps conseillé l’OSL, voire une double licence OSL/AGPL, mais j’avoue être de plus en plus souvent tenté/contraint de choisir une GNU Affero GPL. Ceci d’autant que la licence est aujourd’hui utilisable/utilisée, notamment en raison de ses qualités non négligeables :

  • Elle est construite sur les bases de la GNU GPL v3 (avec laquelle elle reste compatible), dispose d’un copyleft avec une étendue assez large ;
  • Son article 13 prend explicitement en considération les problématiques liées à l’usage par le réseau d’un logiciel, problématique de plus en plus récurrente ;
  • Elle reprend à l’identique la modularité intégrée dans l’article 7 de la GNU GPL : par un jeu de clauses additionnelles plus permissives, et de termes supplétifs (dont l’étendue est strictement cloisonnée), la licence propose un mécanisme contractuel souple qui favorise la compatibilité. Ainsi, l’étendue de la licence reste large, mais les contributions apportées au logiciel pourront l’être sous d’autres licences (potentiellement, présentes sur ces autres briques : par exemple sous licence Apache, CDDL, etc.) — tant que ces dernières concèdent un minimum de droits —, ce qui lui permet d’avoir une étendue d’autant plus large.

Néanmoins, renvoyant en ceci aux commentaires qui précèdent, je ne saurai que trop conseiller d’user largement de la faculté offerte par les interprétations.

3.a L’ajout d’une interprétation à la licence

Cette question est déjà abordée sur le wiki et mérite des développements bien plus poussés que ceux qui vont suivre, j’essaierai d’y revenir ultérieurement au sein d’un billet dédié…

Lors de l’ajout matériel de la licence (en-tête dans chaque fichier : renvoyant au besoin au texte de la licence, ou à un fichier qui définit plus précisément la licence), il est souvent intéressant d’ajouter une interprétation à la licence que l’on utilise. En effet, lorsque la portée de certains termes sujets à interprétation est contestée, il devient très incertain de défendre sa propre vision de la licence. À partir de là, il est opportun d’ajouter soi-même, lorsque l’on appose la licence, le sens que l’on entend donner à telle ou telle autre clause. Par ce moyen, les contributeurs subséquents seront liés par un contrat dont les termes ne seront plus ambigus, ce qui atténuera tout risque de contestation.

En l’espèce, concernant la licence GNU Affero GPL, plusieurs précisions semblent devoir être apportées :

  • Les utilisations et utilisateurs qui enclenchent l’article 13 de la licence concernée (l’hypothèse d’une simple page 404 ou “acces denied” par exemple) ;
  • Les modifications qui sont concernées (toutes modifications, seules celles donnant lieu à emprise du droit d’auteur) ;
  • L’étendue de la licence en application de l’article 13 (seul le logiciel X, seulement les modifications, les fichiers modifiés, tout l’Internet, etc.).

L’inclusion de cette interprétation dans les en-têtes, ou dans le fichier LICENSE.TXT distribué avec les sources, permet de la faire rentrer directement dans le champ contractuel (au côté de la licence). Elle permet à l’auteur de donner la portée exacte qu’il souhaite conférer à la licence, faisant alors disparaître toute incertitude.

Enfin, ce billet est ouvert à tout commentaire et évoluera grâce aux approfondissements qui pourront être faits, avec comme objectif final de rédiger une analyse plus complète sur la licence.

3.b Quelques projets qui utilisent dès à présent la GNU Affero GPL :

3.c Autres liens :

Notes

[1] ASP (application service provider) pour fournisseur d’applications hébergée et loophole pour faille : l’utilisation trouvée par les fournisseurs d’applications hébergées pour ne pas redistribuer le code modifié.

[2] Par exemple, un des reproches faits à la Reciprocal Public License est qu’elle requière la publication de toute version modifiée qu’une société utilise, même de manière privée : “It requires publication of any modified version that an organization uses, even privately”.

[3] “Section 2(d) has been added to cover use of software over a computer network.

[4] “communicate to the public

[5] “d) For the purposes of determining the right to obtain copies of the source code (as well as the right to modify and distribute such source code and object code), the term distribution shall include the communication of the Program or work based on the Program which is intended to interact with third party users (meaning anyone other than you or if you are an entity such as a corporation and not an individual, that corporation), through a computer network and the user shall have the right to obtain the source code of the Program or work based on the Program. This provision is an express condition for the grants of license hereunder and any such communication shall be considered a distribution under Section 1, 2 and 3.

[6] “External Deployment. The term “External Deployment” means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).

[7] “In short, this license grew out of a desire to close loopholes in previous open source licenses, loopholes that allowed parties to acquire open source software and derive financial benefit from it without having to release their improvements or derivatives to the community which enabled them. This occurred any time an entity did not release their application to a “third party”.

[8] ““Deploy” means to use, Serve, sublicense or distribute Licensed Software other than for Your internal Research and/or Personal Use, and includes without limitation, any and all internal use or distribution of Licensed Software within Your business or organization other than for Research and/or Personal Use, as well as direct or indirect sublicensing or distribution of Licensed Software by You to any third party in any form or manner.

[9] “ADDITIONAL TERM: NETWORK USE. The term “External Deployment” means the use, distribution, or communication of the Original Code or Modifications in any way such that the Original Code or Modifications may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Code or Modifications as a distribution under section 3.1 and make Source Code available under Section 3.2.”

[10] Remarque : il est parfaitement possible de réutiliser une licence de la FSF modifiée, mais à condition de ne pas réutiliser le nom et le préambule, sauf accord de la FSF. Voir à ce sujet la FAQ de la GPL : “You can use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble, and provided you modify the instructions-for-use at the end enough to make it clearly different in wording and not mention GNU (though the actual procedure you describe may be similar).

[11] Article 2, d) de la licence : “If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program’s complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work.

[12] “These licenses do not forbid any modification in the software’s useful functionality. That is what counts.

[13] À l’instar d’une limitation à un seul protocole pour la transmission du code source : le HTTP.

[14] “You may also choose to redistribute modified versions of this program under any version of the Free Software Foundation’s GNU General Public License version 3 or higher, so long as that version of the GNU GPL includes terms and conditions substantially equivalent to those of this licence.”

[15] Voir d’ailleurs la précision ajoutée dans la FAQ de la FSF : “Early drafts of GPLv3 allowed licensors to add an Affero-like requirement to publish source in section 7. However, some companies that develop and rely upon free software consider this requirement to be too burdensome. They want to avoid code with this requirement, and expressed concern about the administrative costs of checking code for this additional requirement. By publishing the GNU Affero GPLv3 as a separate license, with provisions in it and GPLv3 to allow code under these licenses to link to each other, we accomplish all of our original goals while making it easier to determine which code has the source publication requirement.

[16] Ce que l’on retrouve clairement dans la définition de “convey” : “To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying”.

[17] “Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by Affero, Inc. If the Program does not specify a version number of this License, you may choose any version ever published by Affero, Inc.

[18] “13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

[19] Pour être complet, il faut admettre qu’une justification accompagnait quasiment toute nouvelle sortie de brouillon. Mais, dans les faits, elle se limitait le plus souvent à paraphraser les choix effectivement pris dans la licence, sans donner la parole aux voix contestataires.

[20] La transparence adoptée par la Commission Européenne lors de la rédaction de la licence EUPL (comité d’expert, ouverture aux commentaires, mailing-lists debian et open source, etc.) est un exemple en la matière.

[21] Puisque l’on parlait simplement de la certification au regard de l’OSD.

[22] “Now we just need developers to understand that using GPL v3 instead of AGPL v3 is just dumb. Your software is going to be used as a service, if not today, in a few years. Yes, YOUR software. Everything is going to be used as a service, even word processors… They can take it and do not give any changes back to your community. Wavemaker is smart and they are now using AGPL. Many will follow.

[23] Le plus paradoxal dans cette situation, c’est que les brevets seraient ici mieux adaptés à protéger ces fonctionnalités.

[24] “The GPL permits anyone to make a modified version and use it without ever distributing it to others. What this company is doing is a special case of that. Therefore, the company does not have to release the modified sources.

[25] Ce qui est d’autant plus gênant que l’insertion d’une telle interprétation, dans un document postérieur à la licence, et extérieur à celle-ci, n’a aucune valeur vis-à-vis de l’engagement qui lie le concédant au licencié. C’est la raison pour laquelle nous conseillons, lorsque nécessaire, d’ajouter à l’usage de la licence une interprétation qui précise le sens et la portée donnés à cette notion de distribution — quitte à renvoyer à ladite FAQ pour plus de détails.

[26] fsb@crynwr.com

[27] “My opinion is that the existence of a GPL-compatible & FSF-endorsed software license that closes the ‘web-app loophole’ will expand the territory of the now-familiar dual-licensing business model to hosted user-facing web-applications, particularly where instances of such applications participate in a larger ecology that has it’s own network effects (by sharing and federating data, for example)”, michaelbernstein.com, 12.09.2007 20:29

[28] “AGPL takes away the freedom to not share, which is the same as taking away the freedom to share”, 12.09.2007 21:34

[29] “I don’t think Matt Asay is too far off when he said that ‘GPL is the new BSD”, 12.09.2007 21:24 

[30] “A more interesting twist is if the front-end is AGPL, and the back-end is GPL… The AGPL front-end would require the distribution of the version of the GPL-licensed back-end actually deployed behind the front-end, but there can be *other* GPL forks of the back-end in use that are not subject to that same requirement, and can have their own dual-licensing arrangements.”, 12.09.2007 22:18, Michael R. Bernstein, michaelbernstein.com

[31] “Dual-licensing is not a perfect model, but I like it. I call it the “free software tax model”: if you don’t want to share, you pay. That payment is then used to develop software that is available as Free Software.”, 12.09.2007 22:51, João Miguel Neves.

[32] “Specifically, in the scenario where you want to launch an under- (or non-) funded open source project for a user-facing web application. You can host the primary instance of the application at an eponymous domain, but others can set up their own instances elsewhere”, 13.09.2007 01:11, Michael R. Bernstein.

[33] <dmarti@zgp.org>, Tim O’Reilly said “I know about the AGPL, but how widely used is it? Not very. It would need to be the dominant licence for free software used in web construction for it to have an effect.” –but couldn’t one big application be “dominant” in its own developer community, the way Movable Type is?” 14.09.2007 16:14, Don Marti sur debian-legal.

[34] “Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

[35] “Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

[36] “The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

[37] “Not sure if I agree with your description of the LAMP stack :) As a user of a website running the stack I’m really interacting with two things… the browser which presents all this pretty buttons and links… and the apache server by means of HTTP requests. It’s the server which then goes and talks to the PHP/Perl/Python code to generate a bunch of HTML and is then sent back to the user via HTTP.” 20.11.2007 17:41, Sean Kellog sur debian-legal.

[38] “I agree with what you say, and this seems consistent with the FSF guidance (where the priority is on “receiving and making requests”, see http://www.fsf.org/licensing/licenses/gpl-faq.html#AGPLv3InteractingRemotely). So the apache server *would* be software capable of supporting interaction over a network.” 20.11.2007 19:50, John Halt sur debian-legal.

[39] “The ultimate issue with the AGPL is that it separates authorship from distribution. Under the GPL what I am *required* to distribute as the original author is VERY clear… I only have to distribute what I distribute. Nothing more and nothing less. But, with the AGPL my distribution requirements are linked to some other event, and event which is very difficult to track down since it occurs in a virtual world without easily defined and discrete events.” 20.11.2007 04:26, Sean Kellog sur debian-legal.

[40] Notamment « Le terme « utilisateur » n’est pas clairement défini. Si mon navigateur affiche une page d’erreur ‘accès dénié’, suis-je un utilisateur de l’application web ? », ainsi que d’autres considérations : “The term “user” is not clearly defined. If I get an “access denied” error page through a browser, am I a user of the web application? When I visit a portal, am I a user of the browser? Of the portal application, as well? Of the server-side scripting engine, perhaps? Of the web server? Of the kernel the web server runs on top of? Of the router OS? And so forth… […] This ambiguity is really problematic, as it implies that there’s no clear way to tell whether a modified version supports remote interaction, and hence there’s no clear way to tell whether it is subject to the restriction specified by this section.” 19.11.2007 23:26 , Fransesco Poli sur debian-legal.

[41] “If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online.

[42] “If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session.

[43] “I’m inclined to say, “At common sense”, taking into account the intended functionality of the software. So someone getting an “access denied” message is not a “user” of the software (even though the software might need to be executed to generate that error). The highlighted wording is incorrect. Clause 13 only attaches *to the person who makes the modifications*. It does *not* apply to someone else who uses the software as so modified. To my mind this is a major loophole in the APGL - what you might call the “get a friend to modify it for you” loophole – but it’s not a “use restriction”.” 19.11.2007 23:26, John Halton sur debian-legal.

[44] “To clarify: the GPL, of course, only requires the source to be supplied once you *distribute* (or “convey”) the software, not merely if you modify it. Similarly, the AGPL “cost” only kicks in once you modify the software *and* put it on a network in a manner allowing for user interaction.” 20.11.2007 00:15, John Halton.

[45] “It looks like the FSF want this interpreted as broadly as possible. From the rationale of the second draft of the AGPLv3, at http://gplv3.fsf.org/agplv3-dd2-rationale.html.” 20.11.2007 15:01, Iain Nicol sur debian-legal. “One thing we did not change is the phrase “interacting with the software remotely through a computer network.” Many commenters expressed concern that this would include not only traditional GUIs that users manipulate for web-based applications, but also other kinds of network interaction, such as sending requests to an IMAP or HTTP server. In fact, we did intend such a broad reading. The GNU AGPL needs to cover all the various protocols and means for network interaction in order to fully achieve its purpose. […] bringing all kinds of network interaction under the license’s scope is the best way to ensure that the license will function as designed.

[46] “Hence it seems that the FSF interprets the “if your version supports such interaction” condition as “if your version is expressly designed to support such interaction”. I’m not sure that this interpretation naturally follows from the license text. And then I wonder: why didn’t they just write “if your version is expressly designed to support such interaction”, if they really meant that ?”, Fransesco Poli, sur debian-legal.

[47] “Now, the application’s “intended” functionality is an interesting concept. I wonder whose intentions matter here? If the author intends it have such interaction and provides source, and modifier downloads the source and turns it into something that doesn’t interact, does that change anything? And, if a third party gets modifier’s source by whatever means and changes it yet more and adds back network interactivity, now whose intentions matter? Perhaps we should ask the application what it itends… you never know these days, I’m sure some applications are smart enough to have an opinion.” et “Oy… this doesn’t seem like it’s going anywhere good. They should have just written a license that says “you must give back your changes, even if you don’t distribute” and just called it good… because that’s going to be the net effect of this license in any context that people consider using it. These extra legal contortions are just an attempt to mask a non-free clause as, well, free.” 20.11.2007 21:29, Sean Kellogg.