I want to add to this thread because I am going through the exact same experience right now with the Creality Hi, and the responses I am getting are nearly identical to what @fake-name documented here over a year ago.
But first, some context on why this matters beyond just “open source principles.” This is about being able to actually use and maintain the printer I paid for…sorry for the length of this one, this has been a really long journey. My patience with this company is basically long gone.
My experience with Creality hardware over the past 12 months
I have invested heavily in this brand. Creality Hi Combo, Creality K1C, CFS-C filament system, a replacement mainboard for the Hi, a replacement CFS board, a replacement extruder, multiple limit switches, and countless hours troubleshooting. Despite all of that, I am still dealing with:
-
A replacement mainboard that arrived with a dead RS485 transceiver (CFS cannot sync)
-
A Y-axis motor board that shorted itself and has no replacement available anywhere
-
An RFID/RS485 board that also shorted
-
A filament cutter sensor cable with a non-standard connector (~0.8mm pitch) that cannot be sourced from any third-party supplier. Creality’s own store says “not available for delivery to your location” and the only alternative is $30+ international shipping for a cable that costs pennies to manufacture
-
A replacement extruder purchased from Amazon that does not even include the wiring needed to connect it to the nozzle_MCU board
I cannot buy replacement parts. I cannot find third-party equivalents. So I tried to do what Creality invited us to do: modify and customize.
The missing source code is a real, practical problem
I attempted to replace the stock toolhead with a BigTreeTech EBB42 and upgrade the extruder. This should be a straightforward modification on an “open source” Klipper printer. Instead, I ran into a wall.
The compiled .so modules are deeply integrated into the firmware. They handle motor control, serial communication, CFS filament management, and bed probing. When you try to replace hardware or modify configurations, you encounter errors and failures that trace back to these compiled files. You cannot read them, you cannot debug them, you cannot understand what they expect, and you cannot modify them to work with different hardware.
I also attempted to add basic functionality like CAN bus and USB serial support. The Tina Linux distribution running on the Hi is so stripped down that there is no package manager (opkg was removed), no standard development tools, and critical kernel modules are missing. I tried cross-compiling an FTDI kernel module from source on an NVIDIA Jetson Orin Nano. It compiled successfully, but segfaulted on insmod because Creality’s custom kernel does not match the vanilla 5.4.61 source and Module.symvers is not available on the printer. Even that path is a dead end.
The only USB serial driver built into the kernel is CH341. FTDI, CP210x, PL2303 are all absent. You cannot install them. You cannot compile them. The system is effectively locked.
This is why I started reverse engineering the CFS RS485 protocol ( GitHub - gitstonelabs/creality-cfs-klipper: This is my personal mission to reverse engineer how the Creality CFS Multi-Material system works in Klipper. The goal is to be able to use 3rd party hardware to run it on any printer running Klipper with the proper hardware to connect to the CFS. · GitHub ). Not because I wanted to, but because I had no other choice. The compiled serial_485_wrapper.so and box_wrapper.so make it impossible to understand how the CFS communicates, and with a dead onboard RS485 transceiver, I need to bypass the mainboard entirely with an external adapter just to get the CFS to function.
The GPL request timeline
I submitted a formal GPL-3.0 source code request to Creality on May 17, 2026 through four separate channels: email to kefu@creality.com, live chat (escalated with ticket number), a pull request on CrealityOfficial/Hi_Klipper (since Issues are disabled), and a comment on the official Reddit open source announcement post.
Here is how the responses have gone:
-
May 18: Support team says “We will report it to our technical and R&D teams.”
-
May 19: Technical team responds: “Creality Hi is not open source, but it can be rooted. The klipper portion is open source.” They link to CrealityTech/klipper, a generic upstream Klipper clone that contains none of the compiled modules.
-
May 20: I reply pointing out that my request IS about the Klipper portion, list the exact file paths, cite GPL-3.0 Section 6, and quote Creality’s own Reddit post about “Customize Freely.” Request escalated to senior engineers.
-
May 21: Senior engineers respond with the exact same answer: “The Hi is currently not open source, but it can be rooted.” They link to Creality · GitHub and tell me to look for what I need there.
-
May 22: I point out this is the fourth time I am making this request and that I have personally audited every repository under CrealityOfficial. The source does not exist in any of them. I request the matter be forwarded to legal/compliance.
I have personally reviewed every repository under CrealityOfficial. The source code for the following files does not exist in any of them:
/usr/share/klipper/klippy/extras/motor_control_wrapper.cpython-39.so
/usr/share/klipper/klippy/extras/box_wrapper.cpython-39.so
/usr/share/klipper/klippy/extras/serial_485_wrapper.cpython-39.so
/usr/share/klipper/klippy/extras/filament_rack_wrapper.cpython-39.so
/usr/share/klipper/klippy/extras/prtouch_v2_wrapper.cpython-39.so
/usr/share/klipper/klippy/extras/prtouch_v3_wrapper.cpython-39.so
These are the same files @fake-name identified back in February 2025. It is now May 2026. That is 15 months of documented non-compliance across multiple customers, multiple channels, and multiple printer models.
The pattern
It matches exactly what was described in this thread:
-
Step 1: “We will forward to our technical team”
-
Step 2: “It is open source, check GitHub” (links to repos that do not contain the files)
-
Step 3: Repeat Step 2 with a slightly different link
-
Step 4: Repeat Step 2 again
The bigger picture
This is not just an ideological issue about open source licensing. This is a practical problem affecting real customers who are trying to maintain and repair printers that are less than 12 months old.
When parts fail and cannot be replaced, the only option left is to modify the firmware to support alternative hardware. When the firmware is locked behind compiled binaries, that option is also closed. The customer is left with an expensive machine that cannot be repaired, cannot be modified, and cannot be maintained.
Creality publicly stated the purpose of open sourcing their firmware was to let makers and developers “Customize Freely.” I am a maker and developer. I am trying to customize. I am not able to do it freely, or at all, because of these files.
@fake-name, I saw your PR on K2_Series_Klipper (#4). It seems like PRs are the only public channel left since they disabled issue reporting. If you are still pursuing this, I would be happy to coordinate. At this point the documentation trail across both of our efforts is substantial enough to support a formal enforcement action.
To anyone else reading this: if you own a Creality Hi, K1, K1C, K2, or K2 Plus and are considering modifications, be aware that these compiled modules will block you. They control motor functions, serial communication, filament management, and bed probing. Without the source, you are limited to whatever Creality decides to support, and based on my parts experience, that support has significant gaps.