This isn’t strictly a ‘technical support’ topic. However, the news that Gl.iNet software is going closed source only seems to have been revealed informally, and implied via the state of the GitHub repos.
This is a very serious change of direction. The open source approach to the custom OpenWrt builds was a huge factor behind many people’s decision to buy and use Gl.iNet products.
Can we expect a formal statement to provide more clarity on the reasoning behind this and what we can expect for the future?
I never heard of this before. I also would like some clarification on this topic… What is being closed source? What part? If the GL.Inet OpenWRT fork was to become closed source, this would be a deal breaker for me, just saying!
We are writing to express our deep concern and seek clarification on the recent changes observed with two primary GitHub repositories that we regularly monitor. It has come to our notice that these repositories have been silently made private, as per the announcement on your Chinese forum. (Refer: Forum Link)
The automated translation of the announcement indicates that this decision was taken to mitigate business risks arising from unauthorized usage and resale of firmware packages developed through your open-source code. While we understand the need to protect intellectual property and maintain business integrity, we believe that an open dialogue regarding such significant changes is essential to maintain trust and transparency with your loyal customer base.
The open-source nature of GL products has been a significant factor in our choice to adopt them. This transparent approach not only fosters trust but also promotes collaborative development and innovation. Therefore, the recent shift in policy has raised several concerns amongst us, prompting speculation about the potential for unwanted backdoor access and other security vulnerabilities.
We sincerely hope that this decision is temporary and that steps will be taken to pursue legal actions against individuals engaging in copyright infringement, rather than restricting access for all users, many of whom have greatly valued the open-source ethos that GL has embraced till now.
The absence of a formal communication regarding this change has further intensified our worries. We kindly request an official statement detailing the reasons behind this change and the future course of action, which will allow us to make informed decisions as customers.
Thank you for your attention to this matter. We look forward to hearing from you soon, and hope to continue enjoying a fruitful and collaborative relationship with GL.
The open source thing does change. The source code is still in github.
Previously we have a builder to build the exactly firmware as the stock firmware but with user’s customizations. That is supposed to be used only by users for peronal use. But someone use that to build firmware, bypassing our restrictions e.g. country code, vpn etc for commerical use. That brings huge risk for our business and users. We removed that builder from github.
The source code, sdk, imagebuilders are still in github gl-inet · GitHub
as a long time happy user of ar-750s-ext and usb micro-router, i am now most confused about gl-inet and their future plans with opensource and openwrt.
fwiw, i was getting ready to purchase brume2, to replace my trusty ar750s-ext.
spent a lot of time reading specs, searching the forum, etc…
never once did i see any formal announcement about going closed source.
and now, seems to me, gl-inet is making false claims about using openwrt.
for the brume2, there is no clean version of openwrt?
am i correct that gl-inet does not use openwrt, but instead used a forked version? https://github.com/gl-inet/openwrt
“13743 commits behind openwrt:main”
yet the claim is made, that you run openwrt. GL-MT2500 / Brume 2 - GL.iNet
“Brume 2 runs on open-source OpenWrt firmware”
so please, really need to make a clear statement about your commitment to open-source and what is really going on with support for openwrt.
please understand, if you do not make it crystal clear what you are doing and recent changes, quickly going to lose support and respect of the open source community.
We submit patches to openwrt and it is openwrt developer’s decision to accept and merge. Before that we always provide our own repo first. Hope this is clear.
I am sorry but are you suggesting that while it is ok for GL.iNET to use open source (OpenWRT) as the very backbone of all of you devices for commercial gain that others should not be able to do the same??? The whole of your commercial success is built on the exact concept and benefits of open source. It has also allowed GL.iNET to have all their consumers to be their alpha and beta testers (whether they have liked it or not).
I believe it has to do with the fact that these devices in China may not have some of these feature we like them to have (mostly the VPN options). As Hong Kong GL-iNet based company I can imaging it will not go well if those Chinese versions will easily get features they should not have.
I can imaging this being a bit like the FCC some years ago requesting manufactures to prevent users from having any direct ability to change RF parameters, which caused some manufactures to also take measures.
But they have already been producing a different firmware for the Chinese market and they can also stop selling to that market if they feel it would jeopardise their business rather than completely destroy their worldwide operation by taking this suicidal step.
I don’t know specifically about Brume 2, but the GLi vs vanilla OpenWRT situation is complicated:
GLi’s firmware is in some cases a heavily modified OpenWRT which is often a major version or two behind latest vanilla OpenWRT.
In a few other cases, the firmware is based on a Qualcomm SDK (QSDK) which is itself a heavily modified version of OpenWRT which may be several major versions behind latest vanilla OpenWRT. This is true at least for devices with ‘IPQ’ CPUs.
All the various patches which GLi makes to make their hardware work well - patches to wifi drivers and the like - do not always later appear in vanilla OpenWRT, or if they do appear, it’s not on any timetable. So you cannot install vanilla OpenWRT on a GLi device and be 100% certain that the hardware will perform the same. This is especially true for newer devices.
Devices running the QSDK-based GLi firmware tend to have worse (or no) support in vanilla OpenWRT.
GLi is still calling their heavily modified OpenWRT, and also the QSDK-based firmwares, just “OpenWRT” on their product pages, with no qualifications.
FWIW, these are just the facts as I see them. I like the products, I wish the development was different in a few ways, but GLi hardware + software have changed my life. So I’m not trying to roast the company here. But the product pages really need to have an asterisk which explains EXACTLY what OS each one runs (as opposed to just “OpenWRT” which is misleading at best) and whether or not it is possible to install latest vanilla OpenWRT on it.
Everyone can benefit from open source. It is called licensing.
If you use open source code, you need to do it according to the license. You can check open source license thing in other website.
GL.iNet used open source and released source code as required. But for some programs we developed, we may or may not release source code. For example our api and UI are never open source. We released some tools so that users can build firmware easier. These are only for personal use and can not be used for commercial purpose without permission. To be more precise, you cannot make a firmware with the same UI as us and claim that it is your own firmware and sell it or claim it is our official firmware. It is a typical abuse of our tools.
Before few people would do that but recently became of country regulations, it is more and more a risk for us. This is not only related to vpn, but also adguard, WiFi channels , DFS etc.
i think if you give an imagebuilder with working openwrt compile toolchain and compileable kernel sources to change the kernel config (even if with binary modules for drivers), it’s most of what people want.
Normally, I can build something myself with the github repos, look at the hash, and compare the hash of a downloaded file and know that the file hasn’t been tampered with or code modified.
If I am using a closed-source software router and wireguard, how do I not know that the router isn’t sending packets through the wireguard protocol to another destination? I wouldn’t have any way of knowing unless I built a wireguard server and monitored the outgoing connections, and even then, closed-source software could be used to only send packets through wireguard for certain IP address associated with tor or known VPNs.
The packets could contain private information about what I do on the Internet.
I am not saying gl.inet would do this, they are a very good company. But in theory, a company could do this, right?
And previously we could confirm gl.inet didn’t do this and now we can’t, right?
I love gl.inet products and this seems like it would increase a user’s attack surface by a large amount.
The timing raises concerns. Recall that this shift was in response to preventing Chinese citizens from creating custom firmware with VPNs during a period when the PRC was targeting VPNs within its borders. Now, with Hong Kong fully under China’s jurisdiction, there’s potential for GL-Inet to be influenced or even weaponized by the government. It’s plausible that the government now has complete access to GL-Inet customer data, and potentially, to their routers in the near future.
Furthermore, trusting their GoodCloud becomes even more challenging without the client code being made publicly available. It would be prudent for GL-Inet to establish an overseas entity to cater to Western customers, re-evaluate their recent decisions, and place more emphasis on ensuring clean OpenWRT support for their latest devices. There seems to be some development in the realm of the latest OpenWRT for AX1800/AXT1800 (link), so it begs the question: Why isn’t GL-Inet exerting more effort in this direction? While I appreciate their customized firmware, blind trust is not something I can afford to give.