Mythbusting AGPLv3 Misconceptions: You Really Can Keep Your Project Private
It’s time to set the record straight around the AGPLv3 open-source license: you CAN keep your codebase private. There’s a common misconception around AGPLv3 that discourages developers from using great open-source tools such as Spree. In reality, you can keep your project private—as long as you don’t commercially distribute your Spree-based product, for example, as a SaaS.
Private Use Is Allowed: No Need to Disclose Your Source Code
Let’s start with GitHub and its trusted licensing guide: choosealicense.com.
If you visit the AGPLv3 section, you’ll see a green light next to “Private use” with the note:
Private use permission: The licensed material may be used and modified in private.
Further, if you open any AGPLv3-licensed repository on GitHub, you’ll see the list of permissions:
- Commercial use
- Modification
- Distribution
- Patent use
- Private use
This is not an accident—AGPLv3 explicitly allows private use and private modification without any requirement to open-source your code. The obligation to share source code is only triggered if you convey or distribute the software, which includes running a SaaS where others interact with your modified version.
This principle applies just as clearly to GPLv3, from which AGPLv3 is derived. As confirmed by the GNU GPL FAQ:
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.
AGPLv3 Projects That Allow Private Use Without Disclosure
Several modern open-source projects have adopted AGPLv3—and they’ve gone out of their way to explain that private use is safe and allowed:
Lago
Lago is an open-source, usage-based billing platform. In their blog post “Open-source licensing and why Lago chose AGPLv3,” they explain:
You fork our code to build your own billing system at your company. It’s awesome and we would be grateful if you could take some time to share your code as well, as it could help other companies. This is strongly encouraged but not required, as we understand not all companies can afford to do this.
Vendure
Vendure is a headless commerce framework also licensed under GPLv3. Their blog post “Busting the Myth of GPL” addresses this head-on:
Myth: I’ll need to open-source all my code! This is the number one misconception about using GPL code in your project.
Grafana (Loki, Tempo)
Grafana Labs re-licensed some of its popular observability tools like Loki and Tempo under AGPLv3. In their licensing blog post, they state:
It’s important to note that this change does not prevent our users from using, modifying, or providing our open source software to others — provided, however, that under the AGPL license, users have to share source code if they are modifying it and making it available to others (either as a distribution or over a network).
These tools are available under (A)GPLv3 without the need to disclose or open-source your private modifications, unless you decide to distribute or sell your product to other users (developers or businesses that could be using your product), as a SaaS or as part of a larger product.
Where Do the AGPLv3 Misconceptions Come From?
The myths around AGPLv3 usually stem from one of four places:
1. Clear GPLv3 interpretations vs. misinterpreted AGPLv3 usage
While GPLv3 has well-documented and widely accepted interpretations — including in the GNU FAQ — which clearly states:
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them.
confusion around AGPLv3 often arises from how the “SaaS loophole” fix was added to GPL — specifically, the condition about making the software available to “users over a network” being a trigger of source-code disclosure.
As explained in Spree’s blog post, the term “users” in this context has a very specific meaning: developers or businesses interacting with your modified version as part of a service. It does not refer to customers shopping on your website, even though they technically “interact over a network.” They are not considered licensees and are (obviously) not entitled to your source code under AGPLv3.
2. Misinterpretations by AI and online summaries
Tools like ChatGPT, Gemini, or other AI often superficially interpret and summarize the AGPLv3 language. As a result, they sometimes issue overly cautious or even completely incorrect summaries of what AGPLv3 requires.
For example, if you ask an AI, “Does the AGPLv3 require that source code of modified versions be posted to the public?” the answer will likely be an unqualified “Yes” — even though in case of GPLv3 the answer to that question is “Yes, but only if…” even if the official FAQ says “No“.
Perhaps AI is generally eager to please and give positive answers when paraphrasing and summarizing. After all, it’s just a (biased, pre-configured) language model – not a lawyer.
3. Confused (or overreaching) open-source contributors
Some well-meaning—but mistaken—contributors and open-source businesses believe AGPLv3 requires full disclosure of modified source code even if used for internal or private projects. Such misinterpretations add to the confusion.
While the desire to promote openness among open-source contributors could be understood, it’s important to respect the actual legal boundaries of the license.
4. One-sided guidance from license FAQs and documentation
Many AGPLv3 license guides and FAQs focus heavily on scenarios where users must disclose their source code, because that serves the goals of the licensor—typically to ensure improvements are contributed back or a commercial license is purchased. It’s good for business.
These resources often do not highlight the equally important flip side, which is when users are not required to disclose—namely, when they use the software privately and do not distribute or convey it to other developers.
The key fact is this: If you are not distributing Spree or making it accessible to other developers or businesses (e.g., via SaaS), AGPLv3 does not require you to share your modified source-code.
Use AGPLv3 software & keep your code private
Don’t let AGPLv3 myths scare you away from using amazing open-source tools like Spree Commerce. If you’re building a private or internal project—even with custom modifications—you can use AGPLv3 software without disclosing your source code.
AGPLv3 is designed to prevent Big Tech exploitation of open-source projects, not to restrict independent developers and small businesses.
Happy coding!
