Umfassende Reaktion auf Bambus Verstöße gegen die AGPLv3

 (sfconservancy.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bambu Studio ist eine modifizierte Version von PrusaSlicer auf AGPLv3-Basis, stellte jedoch weder den vollständigen Quellcode der proprietären Netzwerkbibliothek noch Installationsinformationen bereit
  • Zum Corresponding Source der AGPLv3 gehören der Code, der zum Erzeugen, Installieren, Ausführen und Ändern erforderlich ist, sowie die Quelltexte dynamisch gelinkter Bibliotheken, die eng damit gekoppelt sind
  • Bambu forderte Paweł Jarczak auf, seinen Fork zu löschen, der Orca Slicer so modifiziert, dass er mit den Server-Komponenten von Bambu zusammenarbeitet, was mit der Klausel zum Verbot zusätzlicher Einschränkungen kollidiert
  • Die SFC treibt mit dem Projekt baltobu das Reverse Engineering der Netzwerkbibliothek, die Pflege von Orca Slicer for Bambu und den Ersatz-Fork viscose für Bambu Studio voran
  • Die SFC startet eine zweimonatige Spendenkampagne über US$250,007 für Aktivitäten zum Recht auf Software-Reparatur bei 3D-Druckern und will im Juni 2026 Details zu einem ständigen Ausschuss veröffentlichen

Bestätigte AGPLv3-Verstöße

  • Fehlender Quellcode von libbambu_networking

    • Bei einer AGPLv3-Compliance-Untersuchung zu Software und Firmware für die 3D-Drucker von Bambu Lab wurden zwei Verstöße festgestellt
    • Bambu Studio ist ein Slicer, der digitale Designmodelle wie STL in horizontale 2D-Schichten aufteilt, die der Drucker ausgeben kann
    • Bambu hat seit vier Jahren offengelegt, dass Bambu Studio eine modifizierte Version von PrusaSlicer ist, einem Slicer eines Wettbewerbers unter AGPLv3-Lizenz
    • PrusaSlicer ist wiederum eine modifizierte Version von Slic3r, das ursprünglich von Alessandro Ranellucci entwickelt wurde
    • Ein Teil des Quellcodes von Bambu Studio liegt im Organisationskonto von Bambu auf GitHub, aber Bambu hat erklärt, Bambu Studio in Kombination mit proprietären Bibliotheken über interaktive UI-Aufforderungen an Nutzer zu verteilen
    • Die AGPLv3 schreibt vor, dass bei der Weitergabe eines betroffenen Werks in Objektcodeform auch der maschinenlesbare Corresponding Source unter denselben Lizenzbedingungen bereitgestellt werden muss
    • Zum Corresponding Source gehören der Quellcode und die Skripte, die zum Erzeugen, Installieren, Ausführen und Ändern des Objektcodes erforderlich sind
    • Ebenfalls dazu gehören die Quelltexte gemeinsam genutzter Bibliotheken und dynamisch gelinkter Unterprogramme, die so entworfen sind, dass das Werk sie über enge Datenkommunikation oder Kontrollflüsse benötigt
    • Dass Bambu weder den vollständigen Corresponding Source Code noch die Installation Information für libbambu_networking.so, bambu_networking.dll und libbambu_networking.dylib bereitstellt, wird als schwerwiegender und fortdauernder Verstoß gegen die AGPLv3 bewertet

  • Aufforderung zur Löschung von Paweł Jarczaks Fork

    • Unabhängig davon, dass Bambu die Netzwerkbibliothek proprietär gehalten hat, wird auch das Vorgehen gegen den Entwickler und Bambu-Lab-Nutzer Paweł Jarczak als AGPLv3-Verstoß dargestellt
    • Paweł Jarczak veröffentlichte einen anderen Ansatz zur Integration mit den serverseitigen Komponenten von Bambu Studio, ohne die dynamisch gelinkte Bibliothek auszutauschen oder zu verändern
    • Nachdem er den unvollständigen Quellcode von Bambu Studio geprüft hatte, modifizierte er den anderen AGPLv3-Slicer Orca Slicer
    • Der modifizierte Orca Slicer ermöglichte es Nutzern, Bambu Studio zu ersetzen und sich zugleich mit Teilen zu verbinden, die auf den Servern von Bambu Lab laufen, deren Quellcode derzeit aber nicht veröffentlicht ist und die über enge Datenkommunikation gekoppelt sind
    • Bambu forderte Paweł auf, den OrcaSlicer-Fork mit diesen Änderungen von GitHub zu löschen
    • Bambu behauptete, die eigenen Nutzungsbedingungen hätten Vorrang vor der AGPLv3, doch AGPLv3§10¶3 stellt klar, dass keine zusätzlichen Einschränkungen für die Ausübung von durch die Lizenz gewährten oder bestätigten Rechten auferlegt werden dürfen
    • Paweł löschte den Orca-Slicer-Fork unter Protest

Reaktionsplan der SFC

  • Projekt baltobu

    • Die SFC hat das Projekt baltobu gestartet und betreibt mehrere Repositories, um auf AGPLv3-Verstöße im Zusammenhang mit Bambu zu reagieren und das Recht auf Software-Reparatur bei 3D-Druckern zu verbessern
    • Ausgelöst durch Bambus Vorgehen gegen Paweł Jarczak begann eine vielschichtige Arbeit, die kurzfristig Verbrauchern und Nutzern helfen und langfristig das Recht auf Software-Reparatur für 3D-Drucker-Konsumenten verbessern soll
    • Da Bambu schon seit langer Zeit als schwerwiegender AGPLv3-Verletzer bekannt sei, werde zunächst Reverse Engineering vorangetrieben, weil es schneller Ergebnisse liefern könne als rechtliche Schritte

  • reverse-networking

  • orca-slicer-for-bambu

    • Das orca-slicer-for-bambu-Repository von baltobu soll auf Grundlage von Pawełs Arbeit zum Standard-Repository werden, das den von ihm zuerst veröffentlichten Orca-Slicer-Fork pflegt und verbessert
    • Die SFC sucht Freiwillige, die einen OrcaStudio-Fork pflegen, der mit 3D-Druckern von Bambu funktioniert
    • Freiwillige Beitragende, die im Namen der SFC arbeiten, können einen gewissen Schutz vor persönlicher Haftung erhalten, und die SFC will nach Möglichkeit eingreifen, falls Bambu Freiwillige rechtlich bedroht

  • viscose

    • Das viscose-Repository von baltobu ist ein Projekt zur Pflege eines aktiven Forks von Bambu Studio selbst
    • Aufbauend auf den Erkenntnissen aus den beiden vorherigen Arbeiten soll daraus ein Ersatz für Bambu Studio entstehen, der für Besitzer von Bambu-3D-Druckern besser funktioniert

  • Beobachtung weiterer Verstöße

    • Die SFC will weitere mögliche Verstöße von Bambu Lab weiterhin beobachten
    • Zwar suche sie im Allgemeinen nicht aktiv nach Verstößen, in diesem Fall werde Bambu Lab jedoch genau beobachtet und regelmäßig auf mögliche Verstöße gegen Copyleft-Lizenzen geprüft

  • Ständiger Ausschuss der 3D-Drucker-Community

    • Die SFC will einen ständigen Ausschuss starten, der Softwarefreiheit und Rechte in der 3D-Drucker-Community diskutiert
    • Details zu dem Ausschuss sollen im Juni 2026 veröffentlicht werden
    • Geplant ist eine Struktur, in der sich Hersteller von 3D-Druckern, Nutzer, Verbraucher, Fachleute für Copyleft-Lizenzen und Aktivisten für Softwarefreiheit monatlich treffen
    • Ziel ist es, Probleme und Bedenken rund um das Recht auf Software-Reparatur bei 3D-Druckern und zugehöriger Software zu teilen und Aktionspläne zu ihrer Lösung zu entwickeln

Beteiligung und Unterstützung

  • Freiwillige Mitarbeit

    • Die SFC sucht Freiwillige, die sich sofort an dieser Arbeit beteiligen
    • Paweł Jarczak ist bereits als erster Freiwilliger beigetreten, und seine Arbeit spielte eine wichtige Rolle bei der Untersuchung mehrerer AGPLv3-Verstöße von Bambu
    • Wer die technische Arbeit des baltobu-Projekts unterstützen möchte, kann nachsehen, wie man einen Account auf der Forgejo-Instanz der SFC beantragt
    • Wer an anderen Initiativen interessiert ist, kann eine E-Mail an 3dprint@sfconservancy.org senden

  • Spendenkampagne für Aktivitäten zum Recht auf Reparatur

    • Die SFC führt zwei Monate lang eine Spendenkampagne über US$250,007 durch
    • Neue Sustainer-Beiträge und allgemeine Spenden an die SFC werden den Aktivitäten zum Recht auf Software-Reparatur zugewiesen
    • Wird das Ziel erreicht, beginnt sofort die Suche nach zusätzlichem Personal, das die langfristige Arbeit leiten soll
    • Diese Person soll die Koordination freiwilliger Beitragender, die strategische Planung zur Verbesserung des Rechts auf Software-Reparatur bei 3D-Druckern und die Planung der nötigen nächsten Schritte übernehmen, falls Bambu Lab nicht zur AGPLv3-Compliance bewegt werden kann
    • Wird das Ziel nicht erreicht, werden die Spenden dafür verwendet, dass vorhandene Mitarbeitende Zeit auf dieses Projekt und auf verwandte Aktivitäten zum Recht auf Software-Reparatur konzentrieren

Personen, die bereits beigetragen haben

  • Paweł Jarczak machte die SFC auf die fortdauernden AGPLv3-Verstöße von Bambu Lab aufmerksam und änderte Quellcode in einer von der AGPLv3 erlaubten Weise, um die damit verbundene Arbeit voranzubringen
  • b3nsn0w untersuchte die Situation bei Bambu Lab weiter und hat sich seit mehr als einem Jahr für die AGPLv3 eingesetzt, insbesondere in Bezug auf Verstöße bei dynamisch gelinkten Bibliotheken
  • FULU machte auf dieses Problem aufmerksam und veröffentlichte eine Stellungnahme gegen Bambu Labs

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare
  • Ich weiß den Aufwand an sich zu schätzen. Ich bin langjähriger Open-Source-Nutzer und gelegentlicher Beiträger, nutze auch einen Bambu-Drucker, habe es aber nicht geschafft, Bambu Studio oder aus den Quellen gebautes OrcaSlicer auf einer etwas verbogenen Debian-Maschine ordentlich zum Laufen zu bringen
    Ich verfolge FLOSS-Lizenzen ebenfalls schon lange, und bei der AGPLv3 konnte ich die Motivation zwar immer nachvollziehen, sie fühlte sich für mich aber stets etwas unbehaglich an. Mir gefällt auch nicht, wie Bambu mit der Sache umgeht, und selbst wenn es rechtlich vielleicht nicht eindeutig ist, verletzt es meiner Ansicht nach zumindest klar den Geist von Open Source
    Was für mich hakt, ist die Frage, ob damit gemeint ist, dass AGPLv3-Software keine dlopen()-Aufrufe an unfreie Binärdateien machen darf, oder ob schon die Verbreitung einer .so-Datei, die mit AGPLv3-Software nur einige Funktionszeiger-Signaturen teilt, einen Lizenzverstoß darstellt. In diesem Fall kann ich die Ablehnung nachvollziehen, weil dieselbe Partei modifizierte AGPLv3-Software und unfreie Binärdateien gemeinsam ausliefert, aber verallgemeinert bekomme ich das gedanklich nicht gut zusammen
    Extrem betrachtet könnte das so wirken, als sei AGPLv3-Software, die Plugins in einem standardisierten Format laden kann, mit ihrer eigenen Lizenz nicht vereinbar. Wenn etwa AGPLv3-Audiosoftware VST (https://en.wikipedia.org/wiki/Virtual_Studio_Technology) laden kann, scheint es ziemlich kompliziert zu sein, die lizenzrechtlichen Folgen richtig zu verstehen
    • In diesem Thread sieht es so aus, als lasse Bambu bewusst sämtlichen Netzwerkverkehr über diese proprietäre Bibliothek laufen. Ohne sie ist die Software praktisch nutzlos, und es scheint sogar Anti-Debugging zu geben, das Abstürze verursacht, wenn man das Verhalten genauer untersuchen will
    • Die Auslegung „Heißt das, AGPLv3-Software darf keine dlopen()-Aufrufe an unfreie Binärdateien machen?“ ist nicht die Position der FSF. In ihrem FAQ-Eintrag zu Plugins erklärt die FSF, dass es davon abhängt, wie das Hauptprogramm das Plugin aufruft, ob beides als ein kombiniertes Programm gilt
      Wenn es nur per fork und exec gestartet wird und keine enge Kommunikation stattfindet, kann es ein separates Programm sein; bei dynamischem Linken und gegenseitigen Funktionsaufrufen sowie gemeinsam genutzten Datenstrukturen ist die Position jedoch, dass es als ein kombiniertes Programm zu betrachten ist. Auch der Austausch komplexer Datenstrukturen über Shared Memory wird als fast gleichbedeutend mit dynamischem Linken angesehen
      Soweit ich weiß, gilt das im Großen und Ganzen für alle GPL-Versionen. Vereinfacht gesagt schaut man darauf, ob das Plugin schon vor seiner Entwicklung für das GPL-Programm auch in anderer Software nutzbar gewesen wäre. Wenn es nur für genau dieses GPL-Programm sinnvoll ist, wird es faktisch eher als Teil dieses Programms angesehen
    • Die SFC hat die einschlägige Stelle aus dem Lizenztext zitiert. Dort heißt es, dass Corresponding Source auch den Quellcode für Shared Libraries und dynamisch verknüpfte Unterprogramme umfasst, die das Werk speziell benötigt
      Plugin-Unterstützung an sich ist also in Ordnung. Problematisch wird es, wenn für die allgemeinen Funktionen der Anwendung ein bestimmtes Plugin faktisch erforderlich ist. Die im SFC-Beitrag erwähnte .so scheint mit dem Netzwerk zu tun zu haben, und es erscheint plausibel, dass sich der Drucker ohne Netzwerkzugriff nur schwer komfortabel nutzen lässt
      Im weiteren Kontext heißt es, dass „Corresponding Source“ für ein Werk in Objektcodeform den gesamten Quellcode und alle Skripte umfasst, die nötig sind, um den Objektcode zu erzeugen, zu installieren, auszuführen und zu modifizieren; ausgenommen sind jedoch Systembibliotheken sowie allgemein verfügbare freie Programme oder universelle Werkzeuge, die unverändert verwendet werden
      Insbesondere ist es möglich, AGPL-Software unter OSX zu entwickeln, auch wenn sie von dem proprietären SDK abhängt, das Apple auf allen OSX-Rechnern bereitstellt. Dasselbe gilt für Windows-Anwendungen, die von Komponenten der Windows-Seite abhängen