Réponse globale aux violations de l’AGPLv3 par Bambu

 (sfconservancy.org)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Bambu Studio est une version modifiée de PrusaSlicer basée sur l’AGPLv3, mais ne fournissait ni l’intégralité du code source ni les informations d’installation de sa bibliothèque réseau propriétaire
  • Le Corresponding Source de l’AGPLv3 inclut le code nécessaire pour générer, installer, exécuter et modifier le logiciel, ainsi que le code source des bibliothèques liées dynamiquement et étroitement couplées
  • Bambu a exigé que Paweł Jarczak supprime un fork modifiant Orca Slicer pour l’interfacer avec des composants serveur de Bambu, ce qui entre en conflit avec l’interdiction d’imposer des restrictions supplémentaires
  • La SFC lance le projet baltobu pour faire de la rétro-ingénierie sur la bibliothèque réseau, maintenir Orca Slicer for Bambu et développer viscose, un fork alternatif à Bambu Studio
  • La SFC ouvre une collecte de 250 007 $US sur deux mois pour ses actions en faveur du droit à la réparation logicielle des imprimantes 3D, et prévoit de publier les détails d’un comité permanent en juin 2026

Violations confirmées de l’AGPLv3

  • Absence de publication du code source de libbambu_networking

    • L’enquête de conformité à l’AGPLv3 sur les logiciels et firmwares des imprimantes 3D de Bambu Lab a identifié deux violations
    • Bambu Studio est un slicer qui découpe des modèles de conception numérique comme des STL en couches 2D horizontales que l’imprimante peut produire
    • Depuis quatre ans, Bambu indique publiquement que Bambu Studio est une version modifiée de PrusaSlicer, un slicer concurrent sous licence AGPLv3
    • PrusaSlicer est lui-même une version modifiée de Slic3r, créé à l’origine par Alessandro Ranellucci
    • Une partie du code source de Bambu Studio est disponible sur le compte d’organisation GitHub de Bambu, mais Bambu a indiqué distribuer Bambu Studio aux utilisateurs via des invites interactives de l’interface, en le combinant avec une bibliothèque propriétaire
    • L’AGPLv3 prévoit que lorsqu’une œuvre couverte est transmise sous forme de code objet, son Corresponding Source lisible par machine doit aussi être fourni sous les mêmes conditions de licence
    • Le Corresponding Source inclut le code source et les scripts nécessaires pour générer, installer, exécuter et modifier le code objet
    • Il inclut aussi le code source des bibliothèques partagées et sous-programmes liés dynamiquement conçus pour être requis par l’œuvre via une communication de données étroite ou un flot de contrôle étroitement couplé
    • Le fait que Bambu ne fournisse pas le Corresponding Source Code complet ni les Installation Information de libbambu_networking.so, bambu_networking.dll et libbambu_networking.dylib est considéré comme une violation grave et continue de l’AGPLv3

  • Exigence de suppression du fork de Paweł Jarczak

    • Indépendamment du maintien propriétaire de la bibliothèque réseau par Bambu, les mesures prises contre le développeur et utilisateur de Bambu Lab Paweł Jarczak sont également présentées comme une violation de l’AGPLv3
    • Paweł Jarczak a publié une autre manière d’intégrer les composants côté serveur de Bambu Studio, sans remplacer ni modifier la bibliothèque liée dynamiquement
    • Après avoir examiné le code source incomplet de Bambu Studio, il a modifié un autre slicer sous AGPLv3, Orca Slicer
    • Cet Orca Slicer modifié permettait aux utilisateurs de remplacer Bambu Studio tout en se couplant, par une communication de données étroite, avec des parties exécutées sur les serveurs de Bambu Lab dont le code source n’est actuellement pas publié
    • Bambu a demandé à Paweł de supprimer de GitHub son fork d’OrcaSlicer contenant ces modifications
    • Bambu a affirmé que ses conditions d’utilisation primaient sur l’AGPLv3, mais l’AGPLv3§10¶3 précise qu’aucune restriction supplémentaire ne peut être imposée à l’exercice des droits accordés ou confirmés par la licence
    • Paweł a supprimé son fork d’Orca Slicer en signe de protestation

Plan de réponse de la SFC

  • Projet baltobu

    • La SFC a lancé le projet baltobu, qui héberge plusieurs dépôts pour répondre aux violations de l’AGPLv3 liées à Bambu et améliorer le droit à la réparation logicielle des imprimantes 3D
    • À la suite des actions de Bambu contre Paweł Jarczak, un travail multidimensionnel a démarré pour aider à court terme les consommateurs et utilisateurs, et améliorer à long terme le droit à la réparation logicielle des consommateurs d’imprimantes 3D
    • Comme Bambu était déjà connu de longue date comme un contrevenant important à l’AGPLv3, la priorité a été donnée à la rétro-ingénierie, jugée plus rapide que des démarches juridiques

  • reverse-networking

  • orca-slicer-for-bambu

    • Le dépôt orca-slicer-for-bambu de baltobu doit devenir le dépôt de référence pour maintenir et améliorer le fork d’Orca Slicer initialement publié par Paweł
    • La SFC recherche des bénévoles pour maintenir un fork d’OrcaStudio compatible avec les imprimantes 3D Bambu
    • Les bénévoles contribuant pour le compte de la SFC peuvent bénéficier d’un certain niveau de protection de responsabilité personnelle, et la SFC entend intervenir autant que possible si Bambu menace juridiquement des bénévoles

  • viscose

    • Le dépôt viscose de baltobu vise à maintenir un fork actif de Bambu Studio lui-même
    • À partir des résultats des deux premiers chantiers, le projet vise à créer un remplaçant à Bambu Studio qui fonctionne mieux pour les propriétaires d’imprimantes 3D Bambu

  • Surveillance d’autres violations

    • La SFC continuera de surveiller d’éventuelles violations supplémentaires de la part de Bambu Lab
    • En règle générale, elle ne recherche pas activement les violations, mais dans ce cas elle surveillera Bambu Lab de près et enquêtera régulièrement sur de possibles violations de licences copyleft

  • Comité permanent pour la communauté de l’impression 3D

    • La SFC prévoit de lancer un comité permanent consacré à la liberté logicielle et aux droits dans la communauté de l’impression 3D
    • Les détails du comité seront publiés en juin 2026
    • Le comité est envisagé comme une structure réunissant chaque mois des fabricants d’imprimantes 3D, des utilisateurs, des consommateurs, des experts des licences copyleft et des militants de la liberté logicielle
    • Son objectif est de partager les problèmes et préoccupations liés au droit à la réparation logicielle des imprimantes 3D et des logiciels associés, puis d’élaborer un plan d’action pour y répondre

Participation et soutien

  • Participation bénévole

    • La SFC appelle des bénévoles à rejoindre immédiatement ce travail
    • Paweł Jarczak a été le premier bénévole à s’y joindre, et son travail a joué un rôle important dans l’enquête sur plusieurs violations de l’AGPLv3 par Bambu
    • Si vous souhaitez aider au travail technique du projet baltobu, vous pouvez consulter la procédure pour demander un compte sur l’instance Forgejo de la SFC
    • Si vous êtes intéressé par d’autres initiatives, vous pouvez écrire à 3dprint@sfconservancy.org

  • Collecte de fonds pour le droit à la réparation

    • La SFC lance une collecte de 250 007 $US sur deux mois
    • Les nouvelles contributions Sustainer et les dons généraux à la SFC seront affectés aux actions pour le droit à la réparation logicielle
    • Si l’objectif est atteint, le recrutement commencera immédiatement afin d’embaucher du personnel supplémentaire pour piloter l’action sur le long terme
    • Cette personne coordonnera les bénévoles contributeurs, planifiera la stratégie d’amélioration du droit à la réparation logicielle des imprimantes 3D et préparera les étapes suivantes nécessaires si Bambu Lab ne se met pas en conformité avec l’AGPLv3
    • Si l’objectif n’est pas atteint, les fonds serviront au temps que le personnel existant consacrera à ce projet et à d’autres actions liées au droit à la réparation logicielle

Personnes ayant déjà contribué

  • Paweł Jarczak a permis à la SFC de prendre connaissance des violations continues de l’AGPLv3 par Bambu Lab, et a modifié le code source dans les limites autorisées par l’AGPLv3 pour faire avancer ce travail
  • b3nsn0w a mené des investigations supplémentaires sur la situation de Bambu Lab et défend l’AGPLv3 depuis plus d’un an concernant la violation liée aux bibliothèques dynamiquement liées
  • FULU a attiré l’attention sur ce problème et a pris position contre Bambu Labs

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Lobste.rs
  • J’apprécie l’effort en lui-même. Je suis utilisateur de longue date de l’open source et contributeur occasionnel, et j’utilise aussi une imprimante Bambu, mais je n’ai pas réussi à faire tourner correctement Bambu Studio ni OrcaSlicer compilé depuis les sources sur une machine Debian un peu bancale
    Je suis aussi les licences FLOSS depuis longtemps, et même si je comprends la motivation de l’AGPLv3, elle m’a toujours semblé légèrement inconfortable. Je n’aime pas non plus la manière dont Bambu gère cette affaire et, sans aller jusqu’à dire que c’est forcément illégal, j’estime qu’au minimum cela viole clairement l’esprit de l’open source
    Ce qui me bloque, c’est de savoir si l’on veut dire ici qu’un logiciel sous AGPLv3 ne peut pas appeler dlopen() sur un binaire non libre, ou bien que distribuer un fichier .so qui ne partage avec un logiciel AGPLv3 qu’une partie des signatures de pointeurs de fonction constitue déjà une violation de licence. Dans ce cas précis, on comprend le malaise puisque la même entité publie à la fois un logiciel AGPLv3 modifié et un binaire non libre, mais dès qu’on généralise, ça devient moins clair dans mon esprit
    Poussé à l’extrême, cela pourrait donner l’impression qu’un logiciel AGPLv3 capable de charger des plugins dans un format standardisé serait incompatible avec sa propre licence. Par exemple, dans le cas d’un logiciel audio AGPLv3 capable de charger des VST(https://en.wikipedia.org/wiki/Virtual_Studio_Technology), les implications en matière de licence semblent assez complexes à bien comprendre
    • En lisant ce fil, on dirait que Bambu force délibérément tout le trafic réseau à passer par cette bibliothèque propriétaire. Sans elle, le logiciel devient pratiquement inutilisable, et il semble même y avoir des fonctions anti-débogage qui le font planter si l’on essaie d’examiner son comportement
    • L’interprétation « un logiciel AGPLv3 ne peut pas appeler dlopen() sur un binaire non libre » n’est pas la position de la FSF. Dans cette entrée de FAQ sur les plugins, la FSF explique que le fait qu’il s’agisse ou non d’un programme combiné dépend de la manière dont le programme principal appelle le plugin
      S’il se contente de l’exécuter via fork et exec sans communication étroite, il peut s’agir d’un programme séparé, mais s’il y a liaison dynamique avec appels de fonctions mutuels et partage de structures de données, alors il faut le considérer comme un programme combiné. Ils estiment aussi qu’échanger des structures de données complexes via mémoire partagée revient pratiquement au même qu’une liaison dynamique
      À ma connaissance, cela vaut globalement pour toutes les versions de la GPL. En simplifiant, le critère est de savoir si ce plugin pouvait être utilisé par d’autres logiciels avant d’être écrit pour ce programme GPL. S’il n’est utile que pour ce programme GPL, il est en pratique considéré comme proche d’une partie de ce programme
    • La SFC a cité les passages pertinents du texte de la licence. Le Corresponding Source inclut le code source des bibliothèques partagées et des sous-programmes liés dynamiquement que l’œuvre est spécifiquement conçue pour nécessiter
      Donc, le support des plugins en soi ne pose pas de problème. Le problème apparaît quand un plugin particulier devient, de fait, nécessaire aux fonctions générales de l’application. Le .so mentionné dans le billet de la SFC semble lié au réseau, et il paraît plausible qu’il soit difficile d’utiliser confortablement l’imprimante sans accès réseau
      Dans un cadre plus large, le “Corresponding Source” d’une œuvre sous forme de code objet désigne tout le code source et les scripts nécessaires pour générer, installer, exécuter et modifier le code objet, mais exclut les bibliothèques système ainsi que les outils généraux ou programmes libres généralement disponibles utilisés sans modification
      En particulier, il est possible de développer sous OSX un logiciel AGPL qui dépend d’un SDK propriétaire fourni par Apple sur toutes les machines OSX. Il en va de même pour une application Windows qui dépend de composants côté Windows