The instinct is automatic by now. You hear about a tool, you go looking for the repository, you skim the readme and you spin up a container to see whether it is worth more of your time.
Then occasionally you hit a platform that is genuinely open source, licensed under the GPL, actively developed, and there is no public repository and no download link anywhere. The evaluation path you were about to follow simply does not exist.
This is not a bait and switch. It is a legitimate and fairly common commercial model built on top of copyleft licensing, and it catches a lot of engineers off guard the first time. Understanding how it works saves you a wasted afternoon and helps you evaluate these platforms properly.
Key Takeaways
- The GPL requires you to provide source code to people you distribute binaries to. It does not require you to publish anything publicly.
- Software as a service is not "distribution" under GPLv2 or GPLv3, which is the gap the AGPL was written to close.
- Totara is a well-known example, licensed under GPLv3 but distributed through subscribers and an approved partner network rather than a public download.
- Once you are a subscriber you get the source, and you can modify it, theme it and write plugins against it like any other open source codebase.
- The tradeoff is real. You gain commercial support and security assurance, and you lose the ability to evaluate the code before you commit.
Open source is a license, not a distribution promise
This trips people up because the two ideas usually travel together. Most open source you encounter is both freely licensed and freely downloadable, so it is easy to assume one implies the other.
The GPL is specific about this. If you give someone a compiled or running copy of the software, you must also make the corresponding source available to that person. Nothing in the license obliges you to publish it to the world.
There is a second wrinkle that matters even more. Running software on your own servers and letting customers access it over a network does not count as distribution under GPLv2 or GPLv3, so the source obligation never triggers at all.
That is not a loophole somebody discovered recently. It is why the Affero GPL exists, and it is the same mechanism that lets large cloud providers build enormous businesses on copyleft code without publishing their modifications.
A worked example worth understanding
Totara is one of the clearest cases in the wild. It started in January 2011 as a distribution of Moodle aimed at corporate training rather than education, built by Catalyst IT, Kineo and the Flexible Learning Network.
The additions were the things enterprises kept asking Moodle for and rarely got, including organizational hierarchies, audience management, learning plans and competency frameworks. In 2015 the project announced it would progressively fork from Moodle to move faster on its own roadmap.
Today it is licensed under GPL version 3.0 and ships as three products, with Totara Learn as the LMS, Totara Perform for performance management and Totara Engage as a learning experience layer. It is PHP, it runs on the stack you would expect and you can install plugins and write themes against it.
What you cannot do is go to a public repository and clone it.
So how do you actually get the code?
Access runs through a paid subscription, and subscriptions are sold through an approved partner network rather than directly by the vendor. Totara centralized code distribution years ago so that staff changes at a partner or customer would not cut an organization off from its own source.
In practice that means the partner is not an optional reseller you can route around. They are the delivery mechanism, and choosing a good one has more effect on the outcome than most technical decisions you will make on the project.
A Totara partner is vetted and tiered by the vendor, and handles licensing, implementation, hosting, custom development and version upgrades. The better ones maintain their own plugin libraries and theme frameworks on top of core, which is where a lot of the practical value sits.
That last point is worth dwelling on if you are the technical evaluator. Partners differ enormously in how aggressively they keep clients current, and being parked on a version several releases behind is a genuine and common failure mode. Ask directly about upgrade cadence before anything else.
Pricing is published in places, though it varies with users and modules. One UK partner lists core Totara starting around £12,500 per year, which gives you a rough order of magnitude rather than a quote.
What the subscription actually buys
It helps to separate the license from the service, because you are paying for the second one. The code is GPLv3 either way.
According to Totara, the annual subscription covers a monthly software update service, emergency security patches, error correction and independent security testing. For a platform holding employee records and compliance evidence, that last item is not decorative.
The honest comparison is not against downloading Totara for free, because that is not on the table. It is against self-maintaining a Moodle installation with heavy corporate customization, and then owning the patching, testing and upgrade burden yourself, forever.
Some teams should absolutely do that. Many discover two years in that nobody budgeted for it.
The tradeoffs, stated plainly
You cannot read the code before you buy. There is no public issue tracker to gauge how quickly bugs get fixed, no commit history to judge code quality and no way to run a proof of concept on your own infrastructure without engaging commercially first.
For engineers used to evaluating on evidence, that is a real cost and it is fair to say so. The mitigation is to lean on partner demos, reference customers in your sector and pointed questions about architecture and integration surfaces.
There is also a dependency question. Your ability to upgrade, patch and extend is mediated by a commercial relationship, and if that relationship goes badly your options are narrower than with a fully public project.
The counterweight is that you do get the source once you are in. You are not locked out of your own system, you can fork internally if you must, and your data and customizations remain inspectable. That is meaningfully different from a closed SaaS product.
The pattern is spreading
Totara is not an outlier anymore. Moodle Workplace uses a comparable approach, offered through partners rather than as a free public download, and open core models across the industry increasingly gate the enterprise-grade pieces behind a commercial tier.
This is worth keeping in mind when you compile a shortlist. Genuinely permissive projects and partner-gated GPL projects can look identical in a feature comparison and behave completely differently the moment you try to trial them.
If your requirement is full control with no commercial dependency, the honest answer is to filter for it early. Reviews of self-hosted alternatives that ship under permissive licenses with public Docker images will tell you far more in an afternoon than a vendor comparison chart will.
How to evaluate one of these properly
Ask what license the code is under and confirm you receive source as a subscriber. Get that in writing rather than inferring it from marketing copy.
Ask what happens to your instance and your customizations if you stop paying, and what the exit path looks like. A straight answer here separates serious vendors from the rest.
Then ask the engineering questions you would ask anyway. What are the integration surfaces, is there a documented API, how are plugins versioned against core releases and what does the upgrade process actually involve in practice.
Finally, ask the partner how many of their clients are on the current major version. The answer tells you more about your next three years than any feature list.
The bottom line
Open source is a licensing model, not a promise about how you get the software. Plenty of serious, well-engineered platforms sit behind a subscription and a partner network while remaining fully copyleft underneath.
Whether that is acceptable depends entirely on what you need. If you want to clone, patch and own the whole thing, filter these platforms out early and save yourself the time.
If what you actually want is enterprise capability with the source available and someone accountable for security patching, the model makes a lot more sense than it first appears.
Frequently Asked Questions
Is software still open source if you cannot download it publicly?
Yes, if the license qualifies. Open source describes the rights granted to whoever receives the software, mainly the freedom to run, study, modify and redistribute it. Public availability is a distribution choice, not a licensing requirement, so a GPL project distributed only to subscribers is still GPL.
Why does software as a service avoid GPL source obligations?
Because the GPLv2 and GPLv3 source requirement is triggered by distributing a copy of the software, and letting users access a hosted instance over a network is not distribution. The Affero GPL was written specifically to close that gap by treating network interaction as a trigger.
Is Totara a fork of Moodle?
It began in 2011 as a distribution of Moodle built for corporate training, then announced in 2015 that it would progressively fork to develop independently. The two codebases have diverged substantially since, though the shared lineage is still visible in the architecture.
Can you write your own plugins for a partner-distributed platform?
Generally yes. With Totara specifically, subscribers receive the GPLv3 source and can modify it, build custom themes and install plugins. The usual caution applies about keeping customizations upgrade-safe rather than patching core directly.
What is the main risk of the partner model?
Version drift. Because upgrades are typically delivered through the partner, an under-resourced or inattentive one can leave you several major versions behind, which compounds security exposure and makes eventual upgrades far more expensive.
How do you trial a platform with no public download?
Through the partner. Expect a guided demo environment rather than a self-serve sandbox, and use the time to test integration points and administrative workflows rather than just clicking through the learner interface.
