À la découverte de Sync-in, un projet libre et français de stockage et gestion de fichiers
Le souverain, c'est aussi à la maison
Cet été, un Français a lancé un projet sur lequel il travaillait en solitaire depuis longtemps : Sync-in. C’est un service open source d’hébergement et de gestion des fichiers, qui concurrence en partie NextCloud. Le projet jouit désormais d’une communauté grandissante. Johan Legrand, son concepteur, a également répondu à nos questions.
Le 24 octobre à 15h56
11 min
Logiciel
Logiciel
Comme nous l’explique l’auteur de Sync-in, le projet est né d’un constat : la grande majorité des services pour stocker ses fichiers sont possédés par de grandes entreprises américaines. Il souhaitait donc une solution d’hébergement et de stockage des fichiers. Les produits comme NextCloud et ownCloud existent bien, mais ils sont trop complets pour ce que l’ingénieur avait en tête.
Sync-in, c’est quoi ?
Il s’est donc lancé seul à l’aventure il y a dix ans, écrivant petit à petit sa propre solution, avant de valider ses choix techniques il y a deux ans et demi : TypeScript et Node.js, après une première version en Python. Précisons d'ailleurs que le projet ayant une décennie, plusieurs entreprises l’utilisent déjà, dont une moitié la version Python du projet.
Au sujet de cette version Python, l’auteur du projet, Johan Legrand, nous indique : « À mesure que le projet avançait, atteignant des centaines de milliers de lignes, j'ai commencé à constater la faiblesse de Python en termes de performance, d'asynchronisme, de typage. J'avais patché Python pour rendre le code asynchrone, mais le résultat n'était pas aussi bon que je l'espérais. Le frontend étant développé en TypeScript depuis le début, je me suis naturellement dirigé vers ce langage pour refondre le backend de Sync-in, ce qui m'a permis de mutualiser le code et de profiter des avantages de Node.js ».
La version finale a été publiée en juillet et la composante serveur a été mise à jour plusieurs fois depuis. Depuis la version 1.3 sortie en août, un paquet NPM est même disponible pour simplifier l’installation, en plus du conteneur Docker déjà fourni.
Sync-in est donc avant tout un logiciel serveur, qui nécessite d’avoir soit son propre serveur physique sur place, soit d’en louer un, par exemple à travers une offre VPS (Virtual Private Server). Une fois la partie serveur installée et configurée, on se sert d’un client web, d’une des applications desktop (Windows, macOS et Linux) ou mobile compatible WebDAV (il n’y a pour l’instant pas d’application mobile officielle Sync-in). L’ensemble est open source, visible dans un dépôt GitHub et s’accompagne d’un serveur Discord pour la communauté. Tout le code est sous licence AGPL 3.
« Rester maitre et propriétaire de ces fichiers »
L’ensemble est pensé comme une solution collaborative, l’inclusion d’OnlyOffice permettant l’édition à plusieurs des documents si besoin (une intégration de la suite Collabora est également prévue). En revanche, contrairement à des produits comme NextCloud, il n’est pas question d’e-mails, de contacts, d’agenda, de visioconférence ou autre. Sync-in est exclusivement tourné vers les fichiers.

« Sync-in, c’est beaucoup de choses, mais c’est avant tout une plateforme pour stocker ses fichiers, y avoir accès de partout, pouvoir les partager, pouvoir collaborer aussi en temps réel », nous explique Johan Legrand. « Cela permet à des particuliers, des organisations ou des entreprises d’avoir une vraie segmentation des données, de pouvoir rester maitres et propriétaires de ces fichiers. Le projet est conçu dans l’idée que nos données nous appartiennent. Même si on les partage, même si on autorise l’édition à d’autres, on reste maitre de nos fichiers ».
Comme nous l’indique le développeur, le projet a pris naissance sur la base d’un besoin simple : pouvoir accéder de partout à ses fichiers sans devoir passer par un GAFAM ou un outil n’offrant aucun ou peu de contrôle sur les données. Juste de quoi stocker, gérer, partager et protéger, le tout dans une interface voulue aussi simple que possible.

Que sait faire Sync-in ?
Les fonctions de Sync-in tournent toutes – sans surprise – autour de la gestion des fichiers, de leur synchronisation et des espaces collaboratifs. Ces derniers sont cloisonnés, chaque utilisateur accédant aux fichiers en fonction des autorisations préalablement définies. Bien sûr, rien ne vous empêche de créer votre propre instance où vous serez la seule personne.
Sync-in Server s’installe principalement via un conteneur Docker, mais pas seulement. Depuis cet été, on peut aussi passer par NPM, sous forme de paquet natif Node.js. Une fois en place, comme indiqué, on peut se servir d’une page web ou d’une application pour envoyer des données. Outre l’accès distant à travers une application mobile (compatible WebDAV) et l’aspect sauvegarde, on peut partager les fichiers avec les fonctions qu’on attend dans ce genre de cas : protection par mot de passe, date d’expiration et limitation du nombre d’accès. Les partages ont leur propre section dédiée dans l’interface de Sync-in, pour voir rapidement ce qui est partagé avec soi, avec d’autres, et la liste de tous les partages via des liens.


La consultation proprement dite des fichiers est très simple, avec une vue classique basée sur une arborescence. C’est la présentation par défaut, mais on peut basculer sur une vue en grille et modifier la taille des éléments. Dans cette vue, les images sont remplacées par des miniatures. On peut effectuer toutes les opérations habituelles de renommage, copie, déplacement, modification ou téléchargement depuis la barre d’outils en haut de l’interface, ou simplement via un clic droit. La sélection multiple est prise en charge, de même que le glisser/déposer.

Parmi les autres fonctions, citons aussi les clients desktop. Ces derniers ne fonctionnent pas comme des drives, mais bien comme des clients de synchronisation pour des fichiers et des dossiers que l’on peut lui pointer.
L’algorithme de synchronisation peut détecter les copies et déplacements. Il sait aussi reprendre les transferts après interruption. Signalons également les commentaires, qui permettent une autre forme de suivi des modifications, avec des instructions, remarques et autres. On peut d’ailleurs les assortir de notifications.
Une version démo du projet permet de tester l'essentiel de ses fonctions.


Une idée très précise du contrôle
La souveraineté est au centre de la démarche de Johan Legrand. Par « souveraineté », le développeur n’entend pas uniquement une démarche franco-française, mais l’idée générale d’un contrôle précis des données.
Ce principe s’illustre dans diverses fonctions offertes par Sync-in, surtout au niveau du partage. L’ancrage est un des points forts du projet : il permet de référencer l’un de ses fichiers dans un espace donné. Il apparait donc dans ce dernier, mais appartient toujours à son possesseur, qui en garde le contrôle. Les modifications sur le fichier sont ainsi répercutées partout où il a été ancré, une fonction pouvant s’avérer très pratique dans la gestion de projets.
Même les administrateurs des espaces ne peuvent changer les autorisations liées au fichier ancré : seul son propriétaire peut le faire. Dans le cas où un fichier est ancré dans plusieurs espaces, on peut définir des autorisations différentes pour chacun.

Autre fonction forte du projet, les partages imbriqués. « En tant que propriétaire du fichier, vous pouvez voir tous les éléments qui ont été repartagés, si vous en avez donné le droit », nous explique Johan Legrand. « Vous pouvez gérer chaque sous-partage créé à partir de vos fichiers. Vous pouvez même modifier le partage comme si c’était le vôtre, en plus de la capacité à le supprimer. C’est une fonction phare de Sync-in, qui illustre la souveraineté des données jusqu’au bout ». En outre, si l’on supprime un utilisateur ou un groupe de ce partage, tous les sous-partages associés sont automatiquement supprimés.
Bien sûr, comme on peut s’y attendre, on peut inviter des personnes extérieures à rejoindre un groupe ou un espace. Pour chaque personne, on peut définir précisément les droits associés. Les personnes et les groupes peuvent être ajoutés séparément à des espaces, là aussi avec des droits spécifiques si besoin.
Notez que chaque espace doit avoir un responsable, à qui les membres extérieurs ou groupes seront liés et qui pourra paramétrer notamment les quotas alloués à chacun. S’ils peuvent supprimer des fichiers ancrés, les responsables ne peuvent pas en revanche modifier les droits associés, qui restent l’apanage exclusif de leurs propriétaires.
Cette précision dans la définition des droits est la force du projet, selon son auteur : « On veut pouvoir contrôler qui peut faire quoi, à tout moment et sur n’importe quelles données ».
L’évolution du projet
L’été et le début de l’automne ont été riches en annonces pour Sync-in. La version finale inaugurale a été lancée le 15 juillet sous forme d’une image Docker, suivie deux semaines plus tard d’une version 1.2 qui contenait déjà bon nombre de changements, ainsi qu’une première série de corrections pour des bugs divers. Pour Johan Legrand, c’était également l’occasion d’accueillir un autre développeur, Thibault Signor, dans la gestion du projet. Fin juillet, il remerciait également Alex Zalo pour son audit sur la sécurité, qui avait mené à plusieurs modifications.
Une dizaine de jours plus tard, la version 1.3 était lancée. Comme indiqué précédemment, c’était surtout l’occasion de proposer la disponibilité sur NPM et l’installation comme paquet natif Node.js (une demande de la communauté). La mouture introduisait au passage une interface CLI pour effectuer des opérations de gestion, comme la modification de la configuration et le démarrage ou l’arrêt du serveur.
La dernière grande évolution date du 27 septembre, avec la version 1.6, centrée sur la sécurité. On y trouvait le support de l’authentification à facteurs multiples (MFA) et son intégration dans les clients desktop, la possibilité de générer des mots de passe dédiés pour les applications et intégrations externes, ou encore une gestion plus simple des codes de récupération et mots de passe. La nouvelle mouture glissait au passage quelques autres nouveautés, dont le support des attributs LDAP spécifiques à Active Directory.
Et maintenant ?
Quelles sont les évolutions prévues pour Sync-in ? « On va continuer à parfaire les fonctionnalités de l'application Fichiers », nous répond Johan Legrand. « Par exemple, on va ajouter le versionning et les tags pour les documents. On veut aussi poursuivre l’intégration de plusieurs moyens d’authentification pour favoriser l’adoption. On est maintenant bien compatible avec Active Directory et on pense à OpenID Connect pour l’étape suivante ». Il ajoute qu’un système de plugins est également à l’étude « pour intégrer les fonctionnalités que la communauté réclame (contacts, calendrier, etc.) ».
Le projet a-t-il attiré l’attention ces derniers mois ? « Oui vraiment », nous répond le développeur. « Il y a un très fort engouement de la part des utilisateurs. On a eu notamment un article très sympa de la part de The New Stack, un média de San Francisco. Il a généré un engouement un peu plus international, en plus de selfh.st qui nous a référencés il y a quelques semaines et qui est une référence mondiale pour les logiciels auto-hébergés ».
S’agissant d'un projet open source et libre (sous licence AGPL 3.0), cet engouement s’est-il concrétisé en participation au code, au-delà de simples suggestions d'utilisateurs ? « Pas encore de contributeurs code, ce que je peux comprendre car c'est un projet avec une stack qui demande un peu d'apprentissage. La solution est mature puisque développée depuis plusieurs années déjà, donc peu de retours de bugs. Souvent ce sont plutôt des problèmes d'intégration liés à l'utilisateur et son environnement », indique Johan Legrand.
Pourrait-on envisager des partenariats avec des entreprises, par exemple pour des offres hébergées prêtes à l’emploi ? « On y travaille, mais rien d’officiel encore. J’ai régulièrement des administrateurs système à intégrer la solution, donc le projet plait. Des entreprises et collectivités se sont montrées très intéressées en tout cas, des partenariats se dessinent ».
À la découverte de Sync-in, un projet libre et français de stockage et gestion de fichiers
-
Sync-in, c’est quoi ?
-
« Rester maitre et propriétaire de ces fichiers »
-
Que sait faire Sync-in ?
-
Une idée très précise du contrôle
-
L’évolution du projet
-
Et maintenant ?
Commentaires (51)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 24/10/2025 à 16h32
Une alternative qui a l'air assez sérieuse en face de Nextcloud, surtout si on focus uniquement le partage de fichier.
Je trouvais que Nextcloud justement partait un peu dans tous les sens.
Je testerais cela :)
Merci pour la découverte :)
Le 24/10/2025 à 16h36
Le 24/10/2025 à 16h54
NodeJS consomme beaucoup de CPU de base. Et de RAM. Des projets comme
Par contre, le projet a l'air bien abouti, c'est du bon travail. L'intégration avec OnlyOffice est également clairement un avantage (ah, oui, je préfère Collabora sur mon NextCloud, les goûts et les couleurs).
Le 25/10/2025 à 08h41
Le 25/10/2025 à 11h24
Je ne connaissais pas non plus la solution, j'avais fais pas mal de recherche à l'époque en voulant quitter seafile.
Au final j'ai fini sur nextcloud. Ce n'est pas le plus performant, il y a trop de chose, mais je n'ai pas trouvé plus "sûr" niveau stabilité et facilité d'installation en repartant sur un produit européen.
Et justement quand on compare les perfs de seafile par rapport à next cloud, c'est là qu'on voit que le choix des technologies et du "je fais que serveur de fichier point" change la donne.
Je me fais aux performances et ne regrette pas mon choix, mais je ne peux que constater la grosse différence niveau charge cpu/mémoire côté serveur. (alors que mon usage reste basique, uniquement les fichiers point)
J'ai regardé sync, le point manquant de base je trouve c'est qu'il n'y a pas de versionning de fichier sauf erreur de ma part.
J'ai testé la démo ça semble réactif, et pour "juste du fichier" ça semble pas mal, mais sans versionning perso pour moi c'est mort.
Le 27/10/2025 à 08h24
Modifié le 27/10/2025 à 20h40
J'avais bien fais gaffe sur le site du projet dans les fonctionnalités actives mais pas vu que c'était prévu.
Edit: punaise la lecture sélective j'ai bien vu le passage sur les tag mais pas le versionning juste à côté....
Le 24/10/2025 à 17h36
Le 24/10/2025 à 18h35
Comme @Glandos, je suis pas hyper fan des technos utilisées, mais c'est pas rédhibitoire. En revanche, le facteur d'autobus est un peu faible, avec un seul contributeur régulier.
Pour remplacer mon NextCloud et gagner en performance, je mise sur OpenCloud (un fork d'OwnCloud Infinity Scale, le reboot en golang d'OwnCloud)
Le 24/10/2025 à 21h52
Modifié le 24/10/2025 à 21h55
- OwnCloud
- OwnCloud Infinity Scale ( connais pas, branche spécifique de OwnCloud pour l'héberger en tant que micro service ?)
- Nextcloud fork de OwnCloud suite à des divergence de point de vue entre la société OwnCloud et la communauté)
- OpenCloud (fork de OwnCloud pour passer sur du Go)
- ...
Ca commence à faire du monde, il y a encore des cousins/cousines que je ne connais pas ?
Un fork de Nextcloud en Rust peut être (
Le 25/10/2025 à 11h25
J'avoue que j'avais creusé pas mal OwnCloud Infinity Scale, qui est au final le futur de owncloud.
Mais ça semble quand même compliqué à installer/gérer, c'est vraiment pensé pour un usage cloud pas tellement pour une échelle particulier qui gère son truc.
Le 25/10/2025 à 19h58
Modifié le 28/10/2025 à 18h57
https://www.seafile.com
https://syncthing.net
Le 28/10/2025 à 14h10
Une fois installé et configuré, ça roule tout seul.
Le 24/10/2025 à 20h54
Le 24/10/2025 à 21h50
Je n'ai absolument pas le niveau pour discuter du choix du langage (je ne suis pas dev(ops)). Je suis cepandant un peu surpris par l'utilisation d'un seul langage pour le front et le back. Ca fonctionne ca ?
Mouai attention au système de plugin pour « intégrer les fonctionnalités que la communauté réclame ».
J'utilise Nextcloud pour pas mal de choses (fichiers (y compris de musique), contacts, favoris de navigateur, lecture de traces GPS ); c'est certes pratique que Nexcloud puisse faire tout ça mais est-ce vraiment son rôle ?
Est ce que ca complique pas inutilement le code ( et son maintien ) qui est en dessous ?
Est ce que finalement on aurait pas là le même problème qu'un célèbre système d'initialisation et de gestion des service ?
Le 24/10/2025 à 23h23
Mais AGPL ?!? Ça veut dire que, si on souhaite utiliser une future API pour gérer ses fichiers (scripting ou autre), il faudra que le logiciel utilisateur de l'API soit aussi AGPL ? Et je ne vois pas d'option d'achat pour réduire la licence à MIT, comme le font tous les éditeurs de librairies AGPL. En l'état, je ne vois pas comment cet outil peut être massivement adopté dans ces conditions par des profesionnels.
Modifié le 26/10/2025 à 14h27
Le 26/10/2025 à 19h08
Par contre, pour une API propre, non standardisée, il y a un certain flou vis-à-vis de la licence. L'AGPL est une variante de la GPL, pas de la LGPL. L'utilisation d'une API propre non standard, implémentée par un seul et unique service, pourrait donc être interprétée comme l'utilisation d'une librairie (chargement dynamique via HTTP) et donc nécessiter que le logiciel appelant soit distribuée sous une licence AGPL.
Tant que ce débat n'aura pas été tranché (et à ma connaissance, il ne l'a pas été), difficile d'apporter une réponse juste.
Le 26/10/2025 à 20h08
Cet article étant l'accès au code source aux utilisateurs au cas où ce code est sur un serveur et le logiciel est utilisé à travers le réseau. L'accès par un réseau équivaut donc à la distribution dans le cas de la GPL.
En fait, il y a une seconde différence qui permet de linker le logiciel avec du logiciel GPL v3, mais elle est sans objet dans la discussion.
Je ne vois pas pourquoi l'API réseau serait plus contaminante que dans le cas de la licence GPL v3.
Modifié le 26/10/2025 à 20h56
La FSF a été très prolifique sur ce qui est considérée comme une oeuvre dérivée ou non. En gros, si ton programme A dépend d'une librairie B (sous GPL) pour fonctionner, alors A doit être sous GPL. Qu'importe la manière dont tu utilises la librairie B (linkage statique, dynamique, à la volée, RPC, etc.).
Faire un linkage avec un .lib (ou .dll) ou utiliser une API REST, cela revient grosso modo au même. Si ton programme A dépend des services fournies par un webservice spécifique, c'est comme si il y avait une liaison dynamique, sauf qu'elle passe par le protocole HTTP. Bref, pas vraiment de différence avec du RPC. Donc je ne vois pas vraiment pourquoi il y aurait une différence à ce niveau là.
Mais à ma connaissance, cela n'a pas encore été traité. Ce n'est que mon interprétation.
[edit] Mais sinon oui, la seule différence de l'AGPL par rapport à la GPL, c'est sur qui est considéré comme utilisateur. La GPL était flou sur les usages via réseau. L'AGPL est venue combler ce flou.
Le 27/10/2025 à 01h48
Imagine deux minutes si c'était le cas, l'impact que cela aurait sur le développement de solutions libres interrogeant des API Rest propriétaires.
Modifié le 27/10/2025 à 08h09
L'usage d'une API peut relever d'un lien fort entre les programmes, faisant qu'ils deviennent liés. Ce n'est pas moi qui le dit, c'est la FSF :En bref, ce n'est pas parce que tu utilises une API REST que tu es protégé. C'est bien plus complexe que cela.
Non. Aucun problème, tant qu'il n'y a pas de souci à utiliser les API propriétaires, les API propréitaires n'étant alors pas un travail dérivé.
C'est dans l'autre sens que le problème se pose (solutions non GPL qui interrogent des API REST GPL).
Le 27/10/2025 à 08h42
M'enfin, cette discussion rappelle l'importance du choix d'un licence. Cette question serait intéressante à poser au développeur pour comprendre sa motivation derrière ce choix.
Le 27/10/2025 à 09h00
M'étant pas mal intéressé aux licences, j'en connais pas mal, mais je suis loin de tout connaitre (vraiment très loin), et on ne pense pas forcément aux conséquences que peut avoir tel ou tel choix de licence.
Le coup de l'API REST & (A)GPL par exemple, c'est en réfléchissant à la question posée par @bansan que j'en suis arrivé à cette conclusion ! Et je constate ne pas être trop éloigné de la vérité, puisqu'au final, j'ai la même interprétation que la FSF (ouf !!).
Sans parler pour l'auteur de Sync In, le choix de l'AGPL est généralement fait pour inclure les utilisateurs du service en tant qu'utilisateur couvert par la licence, ce que ne font pas la plupart des licences plus "classiques" et ne fait pas la GPL en particulier.
Maintenant, si l'API repose sur des standards, il n'y a pas vraiment de souci de contamination possible. Il faut vraiment que ce soit une API propre.
Et pour prendre un exemple de la complexité de la chose, une API peut être "propre" à un service à jour, et devenir un standard de fait le lendemain (exemple, S3).
Le 27/10/2025 à 09h55
Le 27/10/2025 à 10h07
Mon avis est appuyé par le texte même de la GPL et de la FAQ de la FSF. Mais il semblerait que cela ne soit pas suffisant pour toi...
Le 27/10/2025 à 09h28
Le texte que tu cite vient du point tentant de tracer la ligne entre agrégat et version modifiés. Le texte commence litéralement par
"Un « agrégat » est un ensemble de programmes séparés distribués sur le même CD-ROM ou autre média. La GPL vous permet de créer et de distribuer un agrégat, même si les licences des autres logiciels ne sont pas libres ou sont incompatibles avec la GPL. "
Les scripts développés pour contacter un API rest qui ne font pas partie d'un agrégat, ne sont pas non-plus distribués avec l'application, et tournent potentiellement sur des systèmes distincts ne sont pas concernés par ce texte .
Le 27/10/2025 à 10h04
Donc voici l'entrée complète de la FAQ en question :
A chacun de se faire un avis maintenant.
Ce que tu dis n'as pas de sens, car tu te trompes de sens. Le problème n'est pas de savoir si le logiciel A doit inclure ou non le service B, mais si le logiciel A doit est considéré comme une oeuvre dérivée du service B (et ça, cela dépend de la licence de B). La FAQ de la FSF répond justement sur ce point : ça dépend, et en dernier recours, c'est à un juge de trancher.
Le 27/10/2025 à 11h09
Assimiler un client passant par le réseau à une œuvre dérivée du service accédé est un amalgame dangereux, qui provoquerait un big bang dans l'industrie, et pas que pour le logiciel libre. Par exemple, un produit comme Samba deviendrait de-facto un produit dérivé de Windows Server avec tout ce que cela implique au niveau droits.
Enfin, d'un point de vue plus pragmatique: même avec de l'AGPL, dans la mesure où tes scripts sont indépendants du logiciel dont ils accèdent à l'API (=> ne contiennent donc pas du code venant du service sous AGPL), même s'ils étaient considérés comme une œuvre dérivée, il n'y a pas d'obligation de les publier dans la mesure où les utilisateurs de la solution n'exploitent pas directement ces scripts (maintenant, si ces scripts sont lancés par l'application AGPL3 sur demande des utilisateurs, il faudra les publier)
Le 27/10/2025 à 11h27
Fin de discussion.
Le 27/10/2025 à 12h40
Pour la considération "covered work", un client API rest développé sur base de la documentation de ladite API REST, ou sur base d'une ingénierie inverse du protocole, n'est pas un "covered work" pour reprendre le vocabulaire de la licence GPL3 car le client ne contient pas de code venant dudit "covered work".
Pour la considération "derivative work", le jour où légalement invoquer une API Rest transforme le client invoquant l'API en "derivative work" avec tout ce que ça implique, je vais chercher du popcorn pour être correctement équipé pour assister à la mort dans le feu et le sang de l'industrie informatique.
Le 27/10/2025 à 13h50
En attendant, ta seule considération, c'est "ça date d'une autre époque". C'est quand même faible comme argumentation.
Chouette, donc tu es en train de dire qu'on peut utiliser une bibliothèque GPL du moment que l'on utilise la documentation pour réaliser les interfaces nécessaires à son utilisation et que le projet ne contient pas de code de ladite bibliothèque ? Ben non, c'est pas comme ça que cela fonctionne. Une fois encore, tu n'as rien compris.
Rien qu'un exemple simple : les wrappers pour un usage dans un autre langage. Tu n'utilises pas le code du projet, mais tu utilises quand même la bibliothèque. Si la bibliothèque est en GPL, ton projet sera considéré comme un projet dérivé, et donc devra être sous GPL aussi. Et avant que tu me dises que c'est encore une interprétation de ma part, c'est dans la FAQ de la FSF.
Une licence, cela utilise des termes à la fois précis ET générique, pour couvrir le maximum de cas d'usage, présent, mais aussi à venir. Lorsqu'il y a un flou (car oui, cela arrive, l'avenir n'est pas connu), elle est mise à jour (cela a été le cas avec la GPLv3 pour lutter contre la Tivoïsation) ou la création d'une licence distincte (cas de l'AGPL pour préciser la notion d'utilisateur en cas d'usage réseau).
Le fait que la licence n'ait pas été mise à jour pour le cas d'usage qui nous occupe ne signifie pas que le cas d'usage n'est pas déjà couvert par la licence.
Et inversons les usages : donne moi une source faisant autorité qui dit EXPLICITEMENT que le cas que tu défends est autorisée.
Maintenant, cette discussion me fatigue sérieusement. Nos avis divergent. J'ai étayé le mien du mieux que possible. Je ne cherche pas à te convaincre en particulier, je cherche à être utile aux lecteurs en donnant des sources. Chacun se fera sa propre opinion.
Fin de discussion pour moi (et pour de bon cette fois-ci).
Modifié le 27/10/2025 à 14h40
Un service web n'est pas une librairie ou un module et il ne s'exécute pas dans le même contexte que le code du client.
Si j'écris des appels REST vers un service quelqu'il soit:
- je n'ai pas besoin de savoir sous quelle licence est le code source du service.
- par contre j'ai peut-être besoin d'un contrat d'utilisation de l'instance du service ( par exemple couvrant le nombre d'invocations, la fréquence d'invocation, et les responsabilités autour des données transférées par le service)
- je n'ai pas besoin d'avoir le code source du service que j'invoque
- je n'ai besoin que des spécifications API
- La seule chose pour laquelle l'AGPL a un impact sur mes activités, c'est que j'ai le droit d'exiger que l'entité qui fait tourner l'instance du service me fournisse ses modifications si elle altère le code du service en question.
Tout simplement, je suis l'UTILISATEUR du service et pas quelqu'un qui la propage ni au sens GPL3 ni au sens AGPL3.
Le 27/10/2025 à 14h58
La FAQ FSF (oui, toujours elle) a même un avis sur l'usage de conteneurs, qui ne change absolument rien au problème (pourtant, comme c'est du réseau, cela devrait être le cas selon ton interprétation).
Ta description d'un service REST est tout simplement incroyable. C'est une barrière infranchissable au niveau des licences pour toi. Ben non, ca va dépendre de la licence du service, que tu le veuilles ou non. Nul part il n'est écrit (dans une loi ou autre) que parce qu'il y a communication réseau, on se fiche de savoir ce qu'il y a derrière...
Le 27/10/2025 à 15h46
- 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?
Le 27/10/2025 à 16h01
La FSF le dit dans sa FAQ (que tu refuses) et que j'ai déjà citée plus haut. Si ton client utilise une API qui est propre à un serveur spécifique, et en dehors de tout standard et de toute alternative, alors oui, ton client peut être vu comme un travail dérivé du serveur.
Je sais, tu n'es pas d'accord avec cette vision. Mais c'est celle de la FSF, que cela te plaise ou non.
Je t'invite aussi à lire le témoignage de Jujens, qui te montreras que c'est loin d'être aussi simple que tu le prétends.
Si tu arrêtais 2min de déformer les propos, ce serait super. Cela ne rentre pas en ligne de compte, car le navigateur web repose sur un standard officiel (HTTP) qui, en plus, dispose de nombreuses implémentations côté serveur (Apache, Nginx, IIS, Kestrel, etc. désolé pour tout ceux que je n'ai pas cités).
Il n'existe donc pas de liens fort entre la partie cliente et la partie serveur.
Le 27/10/2025 à 16h13
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 à 22h51
Il me semblerait très étrange, et très dangereux pour l'écosystème libre, que l'implémentation de clients d'API réseau et de protocoles puisse être entravé par une licence qui ne cible à priori que le code du logiciel serveur spécifique... Ce serait un profond reniement de principes.
Le 27/10/2025 à 01h35
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" ... d'ailleurs les appels peuvent se produire depuis des systèmes complètement distincts et distants, ce qui réfute bien le côté lié: on est dans une logique client->serveur et non dans une logique binaire->librairie.
La question "standard/non standard" s'applique pour les librairies (par exemple pour garder une ouverture non contaminante pour les appels systèmes, les appels posix, ...).
Le 27/10/2025 à 08h02
Le 27/10/2025 à 14h33
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.
Le 27/10/2025 à 14h50
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 25/10/2025 à 14h37
Le 26/10/2025 à 14h24
Le 27/10/2025 à 14h01
Le 27/10/2025 à 14h08
Le 28/10/2025 à 09h25
Le 27/10/2025 à 15h09
Modifié le 27/10/2025 à 19h12
Il semble qu'ils ne testent que la version AppImage, considérée comme étant la version officielle pour Linux si j'en crois leur page de téléchargement.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?