disclamer: I’d like to add more links, but it looks like the number is limited for freshly-registered users. I'll leave only the most important, to the SFC announcement and `License clarification` issue in the Klipper-go repository
This topic is meant as a concrete case study supplementing @Sineos’ overview in /t/20467, in particular the part that asks:
Are the changes known, documented and public or might they even violate the Klipper licence?
I would like to document what I have observed on a stock Anycubic Kobra 3, because it appears to be exactly the pattern that the topic warns about, and it is currently causing reproducible issues for customers who want to use third-party slicers.
I am posting this for follwing reasons:
- To put the technical details on the record, so future Kobra 3 / Kobra 3 V2 / Kobra S1 users searching the forum find them.
- To check with the Klipper maintainers and the wider community whether this matches the “license concern” pattern described in topic 20467 - and, if so, what the recommended next steps are.
- To complement the action SFC announced on 2026-05-18 regarding Bambu Lab’s AGPLv3 violations (SFC announcement). The situation around Anycubic’s firmware is structurally similar, but on the firmware side and against Klipper’s GPL-3.0 rather than PrusaSlicer’s AGPLv3.
- For the cross-reference to the issue created in ANYCUBIC-3D/Klipper-go#16 repository, which is a direct request for the publication of the source corresponding to the modifications in the shipped firmware.
Background
Anycubic publishes ANYCUBIC-3D/Klipper-go on GitHub under GPL-3.0. The README describes it as:
Klipper-go is a Golang porting of klippy (python code of Klipper firmware), dedicated by Anycubic to the community.
and also states:
Please note that, due to IP and R&D considerations, certain of Anycubic’s proprietary features are not open source and have been encapsulated.
So Anycubic publicly acknowledges both (a) that Klipper-go is derived from upstream Klipper and (b) that a portion of the shipped firmware is intentionally kept closed.
What observed
Starting with OrcaSlicer 2.3.2, the G-code config block contains a comment line of the form
; filament_colour_type = 1;1;1;1
(or 1, depending on configuration). This is a valid G-code comment and is produced by other PrusaSlicer/OrcaSlicer/Bambu Studio-derived slicers as well.
On stock Kobra 3 firmware, gklib panics while parsing this line:
project/Webhooks.go:873 panic:13 runtime error: slice bounds out of range [:3] with length 1goroutine 13 [running]:
runtime/debug.Stack()
/home/liuxiaobo/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.11.linux-386/src/runtime/debug/stack.go:26 +0x78
k3c/project.(*GCodeHelper)._handle_script.func1()
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Webhooks.go:872 +0xa0
panic({0x6be1f0, 0xfc8d60})
/home/liuxiaobo/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.11.linux-386/src/runtime/panic.go:791 +0xfc
k3c/project.(*VirtualSD).getCodeInfo(0xd56008, {0xebeb40, 0x46})
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/extras_virtual_sdcard.go:2513 +0x3cf8
k3c/project.(*VirtualSD).Cmd_SDCARD_PRINT_FILE(0xd56008, {0x6ce598, 0xdedda0})
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/extras_virtual_sdcard.go:1120 +0x244
k3c/project.(*GCodeDispatch).Register_command.func1({0x6ce598, 0xdedda0})
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/gcode.go:541 +0x1ec
k3c/project.(*GCodeDispatch).Process_commands(0xc80150, {0xf87de8, 0x1, 0x1}, 0x0)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/gcode.go:691 +0x550
k3c/project.(*GCodeDispatch).Run_script(0xc80150, {0xcb42a0, 0x63})
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/gcode.go:727 +0x124
k3c/project.(*GCodeHelper)._handle_script(0xcb0040, 0xf1b8f0)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Webhooks.go:883 +0x108
k3c/project.(*ClientConnection)._process_request1(0xc92240, 0xc2a360, 0xf1b8f0)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Webhooks.go:555 +0x5c
k3c/project.(*ClientConnection)._process_request(0xc92240, 0xf1b8f0)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Webhooks.go:540 +0x58
k3c/project.(*ClientConnection)._process_received.func1({0x66e3c8, 0x1058fd0})
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Webhooks.go:487 +0x24
k3c/project.(*ReactorCallback).invoke1(0x1096648, 0x40e6c6661bece6da)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Reactor.go:144 +0x7c
k3c/project.(*ReactorCallback).invoke(0x1096648, 0x40e6c6661bece6da)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Reactor.go:138 +0x44
k3c/project.(*EPollReactor)._check_timers(0xcbb2c8, 0x40e6c6661bece6da, 0x1)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Reactor.go:879 +0x120
k3c/project.(*EPollReactor)._dispatch_loop(0xcbb2c8, {0x66e3c8, 0xd94ca8})
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/Reactor.go:788 +0xc4
k3c/project/greenlet.(*ReactorGreenlet).goGreenlet(0xc79ea0)
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/greenlet/greenlet.go:63 +0xf0
created by k3c/project/greenlet.(*ReactorGreenlet).SwitchTo in goroutine 12
/data/liuxiaobo/k3_sys_cartesian/1.0/k3c/project/greenlet/greenlet.go:98 +0x1e4
The print is then stuck in parsing state until the printer is restarted. Reproduced by multiple users - see OrcaSlicer#12444 and Klipper-go#13.
The mismatch with the public repository
The crash references project/extras_virtual_sdcard.go at line 2513, but the same file in the public repository is 561 lines long (see current main). The function getCodeInfo() does not appear in the public source at all.
In other words, the shipped firmware contains substantial modifications to files that are published here under GPL-3.0, but the corresponding source for those modifications is not present in the public repository.
Vendor response
I reported the panic to Anycubic support (ticket 1125994). After a few months, the suggested resolution was to switch from OrcaSlicer to Anycubic’s proprietary Anycubic Slicer Next, because that slicer does not emit the field that triggers the crash. After pushing back, Anycubic confirmed a firmware fix is planned for next month, but did not address the license question.
The proposed workaround is unfortunately not a fix: filament_colour_type is an upstream OrcaSlicer field, so any third-party slicer in that lineage will keep triggering the crash until the parser is patched. From a user perspective, the message is effectively “use the proprietary slicer or your printer is broken.”
Why I think this matches topic 20467
Using @Sineos’ framing:
- “These modifications can result in unexpected printer performance that deviates from what users might expect based on standard Klipper documentation” - confirmed; the crash is in code that does not exist upstream.
- “Incompatibility with Community Resources” - confirmed; the community cannot diagnose the crash from a public source.
- “Dependency on OEM for Updates” - confirmed; the only path to a fix is Anycubic’s release schedule.
- “Are the changes known, documented and public or might they even violate the Klipper licence?” - that is the question I would like the community’s view on. The README explicitly states that the modifications are not public.
Question to the community and maintainers
- Does this match the licensing concern described in topic 20467 as the Klipper project sees it?
- Is there interest from the Klipper maintainers in being notified of this case, given that Klipper is the upstream and the copyright holders are ultimately the only parties who can enforce the license?
- Are there other Kobra 3 / Kobra 3 V2 / Kobra S1 users on this forum who have observed similar gaps between the shipped binary and the published source? Pooling specific examples would help.
- Ask if the maintainers would like to write a message to
3dprint@sfconservancy.org, since the case is slightly similar to Bambu Lab’s AGPLv3 violation and SFC’s response to it. SFC is currently asking for information about similar cases in the 3D printer community, and the more data points they have, the better. The time looks perfect.