I see that the GL-RM1 is described as open source in several places on the website.
Are there any pointers to exactly how this is open source? What is this based on?
Thank you.
Hello,
The RM1 OS is built on open-source project pikvm.
You can focus on this repo.
We will public the open source in the future, only open the part of the code which RM1 used open source projects.
Thank you.
2 Likes
Perfect, thanks for explaining this!
1 Like
device is being advertised as being open source so that's definitely not good enough.
1 Like
Relevant guidance documents and automated deployment scripts will be provided.
What about linux kernel source and u-boot source? I seem to only see userspace codes in that repo.
Those are GPL and are obligated to be made available, right?
One could take their own build of PiKVM and apply it to the comet maybe?
have you maybe read licence of that repo? Tivoization part of GPL v3 requires all all devices sold with any code that has this software to have user buildable firmware. I wont rest until i get to recreate every part of firmware/software that MY comet runs.
3 Likes
PIKVM is just an application software running on Linux system. Many application software following GPL license can also run on Windows. We cannot expect Windows to open all their source code.
The kernel and uboot parts should indeed follow the GPL agreement. I will further check with rockchip to see if it is possible to open the relevant code.
This is clearly stated in the GPL V3.0 agreement.
https://www.gnu.org/licenses/gpl-3.0.en.html#license-text
Note that while GPL requires releasing GPL-licensed source code as well as "Corresponding Source" and make the all those release together build-able to produce the final runnable binaries, it doesn't not mean you have to release the source code of the the non-GPL codes that GPL-licensed codes depend on.
Many companies separate of GPL and non-GPL codes, and would release GPL parts of the codes as source along with pre-built (and usually stripped) non-GPL codes in binary/object/ELF form. An example is how Qualcomm really like to release their NSS driver as binary/object to keep their trade secret as secretive as possible. To my knowledge, a large amount of commercial products follow similar way. For GPL-license the kernel and bootloader, they keep trade secrets in separate binary form. For userspace codes, if the particular binary is not based on GPL codes, they don't need to release them.
A side note, as a company whose majority of products are based on OpenWRT, GL-iNet should know better than most that OpenWRT came into existence and is named "WRT" because Cisco used GPL codes in their "WRT" product line, so they had to make it open source, hence there's the community fork of their WRT codes. (Albeit Cisco violated it at first but then they lost the law suit case)
1 Like
You're missing a few key points, like
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
but more importantly
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
(Section 1., Source Code., para. 2)
I believe the specific demand is for the Corresponding Source(s) of the Major Component(s) related to the Comet (Model No. GL-RM1) as designed, developed, manufactured by GL Intelligence, Inc. of 10400 Eaton Place, Suite 215, Fairfax, VA 22030, USA.
[ emphasis mine ]
Hi GL.iNet team,
I've been investigating the Comet (GL-RM1) and have some questions about GPL compliance. I see this was discussed back in March (thread #55955), but wanted to follow up with specific findings.
What I've Verified:
I extracted and analyzed the kernel from my device:
- Kernel version: Linux 4.19.111
- Build string: Linux version 4.19.111 (vscode@d9297806fa9b) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05)) #1 - SMP PREEMPT Thu Nov 27 07:36:07 UTC 2025
- Build environment: Docker container d9297806fa9b
- bcmdhd module vermagic: 4.19.111 SMP preempt mod_unload ARMv7 p2v8
This confirms GL.iNet built this kernel (not using pre-compiled Rockchip binaries).
Current Repository Status:
The GitHub repos (gl-inet/glkvm, gl-inet/glkvm-cloud) contain PiKVM userspace code, which is great! However, the kernel and bootloader sources are missing, and the userspace repositories don't appear to reflect the latest stable release (v1.7.2) currently running on customer devices.
Questions:
- Can you provide the complete kernel source code, including:
- Full Linux 4.19.111 source tree with any modifications
- The .config file used for compilation
- bcmdhd driver source (currently distributed as /rom/system/lib/modules/bcmdhd.ko)
- Build instructions to reproduce the kernel
- Can you provide the U-boot bootloader source code?
- The device uses U-boot to create the FIT image (built Fri Nov 28 10:31:46 2025)
- U-boot is GPL v2 and requires source distribution
-
Can you update the gl-inet/glkvm and gl-inet/glkvm-cloud repositories to include the source for version 1.7.2 (currently shipping as stable)?
-
Could you provide these sources or clarify the timeline for release?
GPL v2 Requirements:
Under GPL v2 Section 3, distributors must provide:
- Complete source code for all GPL components
- Scripts and instructions to build the binary
- This applies even if the source is unmodified from upstream (Rockchip)
GPL compliance allows users to:
- Verify security (no backdoors/vulnerabilities)
- Customize their devices
- Port to mainline Linux for long-term support
- Understand what's running on their hardware
Recent security issues with similar RV1126-based KVM devices (like the Sipeed NanoKVM's undocumented microphone and network security vulnerabilities) highlight why source code transparency is important for security-critical devices like KVMs.
@robotluo you seem to be the engineer behind this product. well done. I love it! Any update on this issue? It sounds like you are waiting on Rockchip since May 8? Under the GPL, they provided the source code to you (and you recieved the binaries). Similarly, with GL.iNET providing us the binaries (in the device), GL.iNET provides the source to us. That’s how I understand it. You shouldn’t have to check with Rockchip on this. You are simply following the license.
Qualcomm's SoCs heavily utilize the Linux kernel. Will they release it to the open-source community? Furthermore, the kernel and bootloader are provided by the SoC vendor, and we do not have the right to dispose of this code.
@robotluo Respectfully, that is not how the GPL works. Rockchip distributed the software to you, and when they did that, they were obligated by the GPL to give you the source code. They were also obligated by the GPL to give you the right to distribute any GPL-licensed software.
When GL.iNET distributed the software to me, or anyone else who bought a GL.iNET KVM, they were obligated to give us the source code under the GPL. If any of us were to modify the software and distribute it to anyone, we would have to give them the source code, and the right to distribute it, and they would also be obligated to the license terms.
This is why GL.iNET is in violation of the license right now, since they have not made the source code available. Most vendors comply with the GPL by hosting the code and build instructions on a github repository. Technically, you could also email each of us the source code and build instructions if we asked for them.
I am asking for them.
Thank you for your explanation. I have also consulted internally about some GPL requirements, and we will comply. Any changes to the open-source parts of the kernel and U-Boot will be uploaded to the public GitHub repository.
1 Like
@robotluo amazing to hear that. thank you!
1 Like