Dear community members & customers,
The new version includes some updates. I’d also like to discuss the upcoming technical and licensing changes with you.
First of all, the minor update fixes a bug:
- Remote auth failing depending on password · Issue #23 · 0x101-Cyber-Security/NetLock-RMM
- The custom encryption has been completely replaced with a new one.
Upcoming license & techniques changes
It is incredibly important to me to serve the community as best as possible with a fully open-source RMM. Since the beginning, I have been reflecting on how to achieve this in the fairest and most effective way, gathering data and feedback from the community.
Currently, every user can generate the required packages through the members portal. The open-source version is limited to 50/100 devices and is not code-signed if they use the API. The initial idea behind this was to encourage users who don’t pay for it to support the project by starring it on GitHub.
The Problem?
I understand that the device limit can be frustrating. That’s why, in one of the upcoming updates, I will remove this limitation entirely. Additionally, the way not code signed, or code signed packages are delivered will change.
Instead of the current system, the members portal API will be directly integrated with the server and web console package. This will introduce advanced techniques to protect the licensing system while making it incredibly easy to use—eliminating the need for manual package compilation or complex setup.
But why am I making these changes, and what does this mean for you?
Let me explain.
The Hidden Challenges We Face
When you think of open source, you usually imagine a community-driven project where people freely contribute and collaborate. However, I’ve noticed that NetLock is too complex to easily attract contributors. While improving the developer documentation could help, the problem persists: the project is too large and intricate, and I don’t currently have the time to provide the support needed to foster contributions.
But what’s the deeper issue here? The truth is, to make the project grow, add features, and maintain it—things I truly enjoy—I need to dedicate myself full-time to it. Over time, I hope to hire employees to continue developing NetLock RMM while keeping it open-source for the sake of transparency. However, to make this a reality, I need proper funding.
But what happens when a larger company starts taking advantage of the project? This is a challenge many open-source projects face. Bigger companies often benefit from your work without giving back. Recently, I noticed a mid-sized company exploiting the members portal to generate packages regularly, white-labeling the web console, and offering it to their customers without any copyright acknowledgment, even after making small modifications to the code.
You might wonder, why is this a problem when NetLock is licensed under the AGPL-3.0? The license clearly states that any changes made to the code must be released back to the community. But the real issue is that these companies are not voluntarily contributing to the project—they’re abusing the license and profiting from the work without giving back.
So what will I do to prevent that? NetLock RMMs core remains open source, but everything that is related to the members portal api will be heavily protected. That means that I will actively fight and prevent the abusement of the members portal api and oss license abusement. If you want to whitelabel NetLock RMM without contributing to the project by either negoathing a solution with me, or simply contributing your changes to the community, you will have a very hard time in the future. The NetLock RMM ecosystem will grow, and for that, in the future I will introduce solutions to extend NetLock RMM in a easy way for everyone, for more and less experienced programmers to counter these limitations in a good way for everyone who would like to contribute.
What Do Obfuscation, Virtualization, and More Really Mean?
Obfuscation and virtualization are commonly used techniques to make it harder to analyze and tamper with applications. While these terms are well-known, their purposes can differ significantly. On one hand, threat actors use obfuscation techniques to bypass detection by security solutions. On the other hand, legitimate companies, like ours, implement these methods to protect specific parts of the software, ensuring both security and transparency.
Since we use C# as our primary language, incorporating these techniques is essential as a foundation for protection. Without them, anyone could easily bypass our upcoming security solutions, undermining the integrity of the application.
The following parts of the application will be affected and takes effect immediately:
- Web Console & Server
The agent WILL NOT be affected by this. This only affects the server & web console.
Your feedback is important to us.
If you have any questions regarding the changes or feel uncomfortable in any way, please don’t hesitate to contact us directly, or open a discussion on GitHub or Discord. We are deeply committed to growing the project alongside you while maintaining our integrity within the open-source community. As a small team tackling a big problem, we are constantly striving to find the right balance.
Update note
You can upgrade your instance based on your infrastructure by either pulling the Docker images again or, if Docker is not used, reissuing your package in the members portal and replacing the web console and server executables from your instance.
Note: The members portal will still show version 2.5.0.0, as this is tied to the server and agents update logic. Updating your agents is not required with this update. This will be changed later by providing a version number for each component with different update channels.
Thank you
Nico