- je ne fais pas tourner le webservice - je ne met pas le webservice à disposition - je ne modifie pas le webservice - je ne distribue pas le code du webservice - j'utilise le webservice dans la limite des interaction utilisateur offertes.
Il faut arrêter un peu le FUD pour faire peur aux gens avec un GPL qui deviendrait contaminant en relation client-serveur au mépris des principes d'interopérabilité défendus par la communauté du libre.
Tu vas me dire après ça que je n'ai pas le droit d'accéder à un site web utilisant un framework sous gpl si mon navigateur n'est pas lui-même sous GPL?
Je suis d’accord sur le fait qu’il y a beaucoup de FUD autour des licences GPL notamment des gros acteurs et que c’est dommageable. Je suis aussi obligé d’admettre qu’elles ne sont pas toujours simples à comprendre dès que des composants non libres sont impliqués. Et la longueur de la FAQ vs celle des licences Apache ou MPL me conforte dans cette opinion.
Dans le cas présent, après avoir relu la section de la FAQ, à part répondre "globalement une API restera suffisamment simple pour que ça ne s’applique pas", je ne vois pas quoi répondre de plus percutant pour réfuter ce point, point qui n’est pas abordé aussi frontalement dans les articles que j’ai pu consulté. Peut-être parce que comme les auteurs pensaient qu’il ne s’appliquait pas sans y avoir réfléchi. De ce que j’en comprends, dans certains cas, si l’API est assez complexe, je pense que ce point s’applique même en cas de communication via le réseau.
Le
27/10/2025 à
14h
50
Les débats autour de la GPL, on croirait du vim vs emacs ^^ Étant moi-même partisan de la AGPL et ayant fait plusieurs lectures sur le sujet, je me permets de donner mon humble avis avec j’espère un angle un peu différent.
Sur mes projets, quand j’ai choisi la AGPL c’était toujours pour être sûr que la partie serveur restait libre, même en cas de fork. Je n’ai jamais donné plus de considération que ça au client. J’ai refait quelques recherches dans le carde de ce post, et seul le serveur est abordé, pour le client c’est toujours "faite comme vous voulez". Mais je n’ai jamais vu non plus d’articles dans lequel ce point était explicitement abordé sous cet angle. J’admets avoir moi-même oublié cette "clause" alors que j’ai lu le texte de la licence et la FAQ. Cela vient sûrement du fait que j’étais d’abord intéressé par la partie serveur (et manifestement je ne suis pas le seul).
En y réfléchissant, je ne vois pas pourquoi ce point ne s’appliquerait pas dans le cadre d’un logiciel sous AGPL. Cette discussion sur le client d’un logiciel non AGPL ne semble pas s’appliquer : soit la licence est plus permissive et pas de viralité soit c’est privateur et on respecte les CGU.
Un point de flou concerne l’interprétation de complexe je pense. Si le client utilise une API qui permet de poster un fichier avec ses métadonnées (créateur, date, taille…) et de récupérer une liste de fichiers du serveur avec leurs métadonnées, je ne pense pas que l’API soit suffisamment complexe pour que la clause s’applique. Mais ça semble très situationnel et dépendre de l’interprétation de chacun : complexe pour quelqu’un sera simple pour quelqu’un d’autre.
Une solution pourrait être de mettre la définition de ces structures sous une licence plus permissive pour qu’on soit tous sûr que c’est bon. Mais ça complique un sujet déjà pas évident.
Ça me fait aussi penser à ce que faisait mongodb : le serveur était tous AGPL (avant de changer de licence) mais les drivers ont toujours étés sous ASLv2 pour pouvoir être utilisé dans du code propriétaire. De mémoire, la justification était (je n’ai plus la source) de rassurer les gens : pas de contamination possible de leur code avec la AGPL et peut-être une étrangeté juridique, mais porté exclusivement par l’entité fondée à agir donc pas de souci car elle ne se ferait pas de procès à elle-même. Donc même si c’est un peu étrange, tout va bien. De mémoire, mongo s’engageait aussi à ne pas poursuivre les auteurs de drivers tiers. Cela semble confirmer l’interprétation de @fdorin
Dans le cas présent, je ne pense pas que ça ait beaucoup d’impact sur l’adoption : je pense que la plupart des gens utiliseront le serveur et le client officiels sans aucune modification. Je pense que c’est ce qui est fait par ceux qui utilisent Nextcloud ou équivalent. Au passage, le serveur Nextcloud est sous AGPLv3 et le client sous GPLv2 (mais tout est détenu par Nextcloud, donc pas de risque de conflit) et c’est utilisé en entreprise.
Pour me répondre, je pense que la source c’était celle-là Archive.org (plus dispo sur le site de mongodb) Vu comment c’est tourné on peut supposer que c’est suffisamment flou pour qu’ils en parlent.
Et il y a aussi dans https://www.mongodb.com/legal/licensing/server-side-public-license/faq
Why did you base the SSPL on GPL v3 instead of AGPL?
[…]
There is some confusion in the marketplace about the trigger and scope of the Remote Network Interaction provision of AGPL.
Donc on ne doit pas être les seuls à débattre de ce point et d’à quel point ça s’applique via une API utilisée sur le réseau.
Le
27/10/2025 à
14h
33
Quand on interagis avec une API type REST, XMLRPC, SOAP, ... exposée, on est pas dans le cas d'un appel direct de librairie qui lui serait "contaminant"
Les débats autour de la GPL, on croirait du vim vs emacs ^^ Étant moi-même partisan de la AGPL et ayant fait plusieurs lectures sur le sujet, je me permets de donner mon humble avis avec j’espère un angle un peu différent.
Sur mes projets, quand j’ai choisi la AGPL c’était toujours pour être sûr que la partie serveur restait libre, même en cas de fork. Je n’ai jamais donné plus de considération que ça au client. J’ai refait quelques recherches dans le carde de ce post, et seul le serveur est abordé, pour le client c’est toujours "faite comme vous voulez". Mais je n’ai jamais vu non plus d’articles dans lequel ce point était explicitement abordé sous cet angle. J’admets avoir moi-même oublié cette "clause" alors que j’ai lu le texte de la licence et la FAQ. Cela vient sûrement du fait que j’étais d’abord intéressé par la partie serveur (et manifestement je ne suis pas le seul).
En y réfléchissant, je ne vois pas pourquoi ce point ne s’appliquerait pas dans le cadre d’un logiciel sous AGPL. Cette discussion sur le client d’un logiciel non AGPL ne semble pas s’appliquer : soit la licence est plus permissive et pas de viralité soit c’est privateur et on respecte les CGU.
Un point de flou concerne l’interprétation de complexe je pense. Si le client utilise une API qui permet de poster un fichier avec ses métadonnées (créateur, date, taille…) et de récupérer une liste de fichiers du serveur avec leurs métadonnées, je ne pense pas que l’API soit suffisamment complexe pour que la clause s’applique. Mais ça semble très situationnel et dépendre de l’interprétation de chacun : complexe pour quelqu’un sera simple pour quelqu’un d’autre.
Une solution pourrait être de mettre la définition de ces structures sous une licence plus permissive pour qu’on soit tous sûr que c’est bon. Mais ça complique un sujet déjà pas évident.
Ça me fait aussi penser à ce que faisait mongodb : le serveur était tous AGPL (avant de changer de licence) mais les drivers ont toujours étés sous ASLv2 pour pouvoir être utilisé dans du code propriétaire. De mémoire, la justification était (je n’ai plus la source) de rassurer les gens : pas de contamination possible de leur code avec la AGPL et peut-être une étrangeté juridique, mais porté exclusivement par l’entité fondée à agir donc pas de souci car elle ne se ferait pas de procès à elle-même. Donc même si c’est un peu étrange, tout va bien. De mémoire, mongo s’engageait aussi à ne pas poursuivre les auteurs de drivers tiers. Cela semble confirmer l’interprétation de @fdorin
Dans le cas présent, je ne pense pas que ça ait beaucoup d’impact sur l’adoption : je pense que la plupart des gens utiliseront le serveur et le client officiels sans aucune modification. Je pense que c’est ce qui est fait par ceux qui utilisent Nextcloud ou équivalent. Au passage, le serveur Nextcloud est sous AGPLv3 et le client sous GPLv2 (mais tout est détenu par Nextcloud, donc pas de risque de conflit) et c’est utilisé en entreprise.
A priori, c'est un peu incertain depuis quelques temps.
On a aussi une explication qui est donnée quant à la disparition du site, mais elle date de décembre 2022. Si le site n'est pas réapparu depuis, il y a peu de chance qu'il réapparaisse un jour...
Il y a eu un souci en 2022 oui. Mais le site était revenu en 2023 et 2024.
Le
09/01/2025 à
11h
56
Grammalecte est encore maintenu ? Il me semble que son auteur avait un peu perdu la motivation pour le maintenir...
Je pensais qu’il était encore un peu maintenu. J’ai vu des commits dessus il n’y pas si longtemps. Mais ça doit faire 2 ans qu’on n’a pas eu de nouvelle version.
Et quand j’ai voulu regarder en fin d’année pour vois s’il y avait une nouvelle version, j’ai vu que le site était inaccessible. Il n’est toujours pas revenu. Ce n’est pas bon signe.
“Open source technology is the backbone of many of Uber’s core services and as we continue to mature, these solutions will become ever more important,” d’après la source. Donc c’est une erreur de traduction.
8 commentaires
À la découverte de Sync-in, un projet libre et français de stockage et gestion de fichiers
24/10/2025
Le 27/10/2025 à 16h 13
Dans le cas présent, après avoir relu la section de la FAQ, à part répondre "globalement une API restera suffisamment simple pour que ça ne s’applique pas", je ne vois pas quoi répondre de plus percutant pour réfuter ce point, point qui n’est pas abordé aussi frontalement dans les articles que j’ai pu consulté. Peut-être parce que comme les auteurs pensaient qu’il ne s’appliquait pas sans y avoir réfléchi. De ce que j’en comprends, dans certains cas, si l’API est assez complexe, je pense que ce point s’applique même en cas de communication via le réseau.
Le 27/10/2025 à 14h 50
Et il y a aussi dans https://www.mongodb.com/legal/licensing/server-side-public-license/faq
Donc on ne doit pas être les seuls à débattre de ce point et d’à quel point ça s’applique via une API utilisée sur le réseau.
Le 27/10/2025 à 14h 33
Sur mes projets, quand j’ai choisi la AGPL c’était toujours pour être sûr que la partie serveur restait libre, même en cas de fork. Je n’ai jamais donné plus de considération que ça au client. J’ai refait quelques recherches dans le carde de ce post, et seul le serveur est abordé, pour le client c’est toujours "faite comme vous voulez". Mais je n’ai jamais vu non plus d’articles dans lequel ce point était explicitement abordé sous cet angle. J’admets avoir moi-même oublié cette "clause" alors que j’ai lu le texte de la licence et la FAQ. Cela vient sûrement du fait que j’étais d’abord intéressé par la partie serveur (et manifestement je ne suis pas le seul).
En y réfléchissant, je ne vois pas pourquoi ce point ne s’appliquerait pas dans le cadre d’un logiciel sous AGPL. Cette discussion sur le client d’un logiciel non AGPL ne semble pas s’appliquer : soit la licence est plus permissive et pas de viralité soit c’est privateur et on respecte les CGU.
Un point de flou concerne l’interprétation de complexe je pense. Si le client utilise une API qui permet de poster un fichier avec ses métadonnées (créateur, date, taille…) et de récupérer une liste de fichiers du serveur avec leurs métadonnées, je ne pense pas que l’API soit suffisamment complexe pour que la clause s’applique. Mais ça semble très situationnel et dépendre de l’interprétation de chacun : complexe pour quelqu’un sera simple pour quelqu’un d’autre.
Une solution pourrait être de mettre la définition de ces structures sous une licence plus permissive pour qu’on soit tous sûr que c’est bon. Mais ça complique un sujet déjà pas évident.
Ça me fait aussi penser à ce que faisait mongodb : le serveur était tous AGPL (avant de changer de licence) mais les drivers ont toujours étés sous ASLv2 pour pouvoir être utilisé dans du code propriétaire. De mémoire, la justification était (je n’ai plus la source) de rassurer les gens : pas de contamination possible de leur code avec la AGPL et peut-être une étrangeté juridique, mais porté exclusivement par l’entité fondée à agir donc pas de souci car elle ne se ferait pas de procès à elle-même. Donc même si c’est un peu étrange, tout va bien. De mémoire, mongo s’engageait aussi à ne pas poursuivre les auteurs de drivers tiers. Cela semble confirmer l’interprétation de @fdorin
Dans le cas présent, je ne pense pas que ça ait beaucoup d’impact sur l’adoption : je pense que la plupart des gens utiliseront le serveur et le client officiels sans aucune modification. Je pense que c’est ce qui est fait par ceux qui utilisent Nextcloud ou équivalent. Au passage, le serveur Nextcloud est sous AGPLv3 et le client sous GPLv2 (mais tout est détenu par Nextcloud, donc pas de risque de conflit) et c’est utilisé en entreprise.
Dernier point : si le client est interne à une entreprise, pas besoin de publier les sources, c’est un cas prévu par la licence.
Pas de compatibilité avec Windows 11 ? ESET recommande le passage à Linux
08/01/2025
Le 09/01/2025 à 12h 29
Le 09/01/2025 à 11h 56
Et quand j’ai voulu regarder en fin d’année pour vois s’il y avait une nouvelle version, j’ai vu que le site était inaccessible. Il n’est toujours pas revenu. Ce n’est pas bon signe.
Next INpact fête ses 16 ans !
06/05/2019
Le 06/05/2019 à 12h 43
Pertes colossales pour Uber, qui rejoint la Linux foundation
19/11/2018
Le 19/11/2018 à 13h 39
“Open source technology is the backbone of many of Uber’s core services and as we continue to mature, these solutions will become ever more important,” d’après la source. Donc c’est une erreur de traduction.
Jeuxvideo.com en mode « Damage control »
09/11/2017
Le 09/11/2017 à 13h 10
Et ça risque d’être contourné très vite façon p0rn Donc je doute que ça résolve quoi que ce soit.