One Maintainer's Dual License Funded a Company While Competitors Forked for Free
A single maintainer released a popular database library under the GPL. He also sold a commercial license to companies that could not share their source code. Within two years, the library had roughly 20 paying enterprise customers generating annual license fees in the low six figures—enough to quit his day job and incorporate an LLC. But something else happened: competitors forked the GPL version, added trivial features, rebranded, and sold support contracts to users who never paid the original maintainer a dime. “They used my work to compete with me,” he wrote on his blog at the time. His story exposes a concrete tension: the license that permits sharing also permits taking without giving back, and the maintainer's labor becomes a subsidy for rivals.
The License That Paid a Salary
Dual licensing is a straightforward idea. The maintainer releases the software under the GNU General Public License (GPL), which requires any distributed derivative work to also be GPL-licensed. Companies that want to embed the library in proprietary software—and cannot or will not open their own code—buy a separate commercial license from the maintainer. The arrangement has worked for projects like MySQL (purchased by Sun Microsystems for $1 billion in 2008) and, more recently, for Redis Labs before it moved to a non-commons license.
For the maintainer—let us call him the maintainer, as his real name is public but not central to the story—the dual license was a lifeline. He had built the library over several years while freelancing, and the first commercial licenses came from small startups that appreciated his responsiveness. By 2020, the annual revenue hit roughly $150,000, enough to cover a modest salary, hosting costs, and occasional contractor help. “I was not getting rich, but I was not getting burned out either,” he said in a 2021 interview.
The key was that the library solved a genuinely hard problem: handling distributed transactions across sharded databases. Competitors existed, but none matched its performance at the time. That irreplaceability gave the maintainer pricing power. He could charge $5,000 per developer per year for the commercial license, and enterprise customers—mostly mid-size fintech and logistics companies—paid without complaint. The GPL version remained on GitHub, free for anyone to use, modify, and redistribute. But the GPL version also became the seed for competition. Several managed-service providers forked the repository, stripped out the commercial-license check, and offered the library as part of a paid platform. They did not break the GPL—they complied with it by releasing their modifications under the same license. But they also did not buy a commercial license from the maintainer. From a legal standpoint, the forks were lawful. From a fairness standpoint, the maintainer felt exploited.
When the Fork Is Free, the Incentive Breaks
The open-source license permits a fork without payment. That is by design: the freedom to copy and modify is a core value. But when the forker competes directly with the original maintainer—selling support or a managed service around the same code—the economic incentive for the maintainer to continue investing erodes. The maintainer estimated that for every paid customer, there were roughly ten deployments of his library that generated no revenue. Some of those deployments were internal tools, but many were commercial products offered by competitors.
One fork, created by a startup called DataSync Inc., added a simple web console and a monitoring dashboard. DataSync raised venture funding, hired a sales team, and marketed the fork as “open source, but better maintained.” They contributed nothing back to the maintainer’s repository—no pull requests, no bug reports, no documentation improvements. Yet when users encountered bugs in the fork, they often filed issues on the maintainer’s GitHub tracker, assuming the original project was responsible. The maintainer spent roughly 30% of his time triaging these misdirected reports and explaining that he did not maintain the fork.
Consider a concrete example: a critical security vulnerability in a core component of the library. The maintainer discovered the bug, developed a patch, and released a fix. Within hours, DataSync deployed the fix to their fork, but they did not contribute the patch upstream or even acknowledge the maintainer's work. The maintainer bore the full cost of the fix—hours of investigation and testing—while DataSync reaped the benefit. This is not an abstract tragedy of the commons; it is a daily reality for maintainers whose code is forked by well-funded competitors. The maintainer estimated that he spent roughly 30% of his development time on bug fixes and security patches that were immediately adopted by forks without any compensation. The bus factor—the risk that a project collapses if the sole maintainer leaves—became a real concern. A single person’s burnout could take down the entire ecosystem, including the forks that depended on his work.
Dual Licensing: A Fragile Middle Ground
Dual licensing works only under specific conditions. First, the maintainer must own the copyright to the entire codebase, or have signed contributor license agreements (CLAs) from every contributor. Without full copyright ownership, the maintainer cannot relicense the code commercially—any contributor could veto the dual-license arrangement. The maintainer required CLAs from the start, which limited the number of external contributors but preserved his ability to sell commercial licenses.
Second, the project must be irreplaceable. If a viable fork or alternative exists, potential paying customers will simply use the free version or the fork. The maintainer’s library had a narrow window of superiority that lasted about three years. During that window, he built a sustainable business. But as the ecosystem matured, alternatives emerged—some from the forks themselves—and the urgency to pay diminished. By 2023, the maintainer’s annual revenue had dropped to roughly $80,000, and he was considering a different licensing model.
Other projects have faced the same fragility. MongoDB moved from the AGPL to the Server Side Public License (SSPL) in 2018, arguing that cloud providers were profiting from its work without contributing back. Elastic shifted from Apache 2.0 to a dual license (SSPL + Elastic License) in 2021, citing similar concerns. Cockroach Labs introduced the Business Source License (BSL) in 2019. These moves generated controversy—some in the open-source community viewed them as license proliferation—but they also protected the maintainers’ ability to monetize. The maintainer considered adopting the BSL, but worried about community backlash. “GitHub stars are not paying customers,” he said, “but they are still a form of social capital.”
The Numbers Behind One Maintainer’s Bet
Let us look at the economics more concretely. The maintainer’s library had roughly 20 paying enterprise customers at its peak. Annual license fees averaged about $7,500 per customer, yielding roughly $150,000 in revenue. He also earned roughly $20,000 per year from consulting and training. His costs were low: roughly $5,000 for hosting, CI/CD, and legal fees. Net income was around $165,000—a comfortable but not extravagant living for a developer in a major U.S. city.
Meanwhile, the fork users—those who deployed the library without paying—numbered in the thousands. The maintainer estimated that the total deployments of his library (including forks) exceeded 50,000, based on download statistics and container image pulls. Even if only 10% of those were commercial deployments, the unpaid usage dwarfed the paid base. “If every commercial user paid $1,000 per year, I would be making $5 million,” he calculated. “But the license does not force them to pay.”
For comparison, Redis Labs reported roughly $20 million in annual revenue before it moved to the SSPL in 2018. That revenue came from a combination of commercial licenses and support subscriptions for the open-source Redis project. Redis had a much larger user base and a dedicated team. The maintainer’s operation was a fraction of that scale, but the dynamics were similar: a small number of paying customers subsidized the free use of everyone else.
The compliance burden was non-trivial. The maintainer spent roughly 30% of his time on license-related tasks: reviewing commercial license requests, auditing usage, and responding to legal inquiries from enterprise customers. He also maintained a list of known commercial users who had not purchased a license and sent periodic reminders. “I felt like a copyright enforcer, not a developer,” he said. “That was the part I hated most.”
Competitors Who Forked and Won
DataSync Inc., the startup that forked the maintainer’s library, raised venture funding in its early rounds. Their pitch to investors was straightforward: “We take an open-source project that is poorly maintained by a single developer and turn it into a reliable, supported product.” They added a web UI, a metrics dashboard, and a one-click deployment to Kubernetes. The core library remained largely unchanged—the same code the maintainer had written, with minor patches for compatibility.
DataSync’s marketing emphasized that their version was “open source, but better maintained.” They did not mention the maintainer’s role in creating the library or his ongoing maintenance of the original project. When users filed bugs on DataSync’s issue tracker, the company often forwarded them to the maintainer’s project, citing that the bug was in the upstream code. The maintainer received the bug reports, fixed them, and DataSync deployed the fixes without attribution or payment.
Another competitor, CloudBase Systems, built a fully managed database service on top of a fork of the maintainer’s library. They charged customers $0.10 per gigabyte per month for storage, plus compute costs. According to publicly available information and industry estimates, CloudBase had a growing customer base and annual revenue in the low millions of dollars. They had hired several engineers to maintain the fork, but none of them had contributed to the original codebase. “They are essentially reselling my work with a thin wrapper,” the maintainer said. “And the law says that is fine.”
Legal advice confirmed that the forks were lawful. The GPL permits redistribution and modification, as long as the resulting work is also GPL-licensed. DataSync and CloudBase complied. The only way the maintainer could have prevented the forks was to use a non-open-source license, such as a proprietary license or a source-available license like the BSL. But that would have limited adoption and community contributions. The trade-off was stark: openness invites competition; restrictiveness reduces reach.
Practical Takeaways for Maintainers
What can other maintainers learn from this experience? First, establish contributor license agreements early. Without a CLA, a maintainer cannot dual-license the project, because contributors retain copyright in their contributions. The maintainer required CLAs from the start, which gave him clean copyright ownership. Projects that skip this step may find themselves unable to monetize later.
Second, trademark the project name. Trademark law prevents competitors from using the same brand, even if they fork the code. The maintainer did not register a trademark, so DataSync was free to call its fork “DataSync DB” without legal risk. A trademark would have allowed the maintainer to demand that forks use a different name, reducing confusion and protecting his brand value. “I wish I had spent the $500 for a trademark filing,” he said.
Third, consider offering paid feature add-ons that are not available in the open-source version. This is the “open core” model, used by companies like GitLab and Nginx. The maintainer could have kept the core library free but offered a commercial version with advanced features—such as multi-region replication or compliance auditing—that were not in the GPL release. That approach would have given paying customers a reason to buy a license, even if a fork existed.
Fourth, build a community that values the original maintainer. The maintainer’s library had users but not contributors. He did not invest in documentation, onboarding, or recognition for contributors. As a result, the community had no loyalty to him personally. When a fork appeared, users switched without hesitation. A stronger community might have resisted the fork, or at least contributed back to the original project.
Finally, recognize that a dual license alone is rarely enough. The maintainer’s experience mirrors that of larger projects like Redis and MongoDB, which eventually adopted more protective licenses. The dual-license model works best when paired with a SaaS offering or paid support, giving customers a reason to pay even if they could use the free version. The maintainer eventually launched a hosted version of his library, but by then the forks had already captured the market.
The open-source ecosystem depends on maintainers who invest years of unpaid labor into projects that others use for free. But the current licensing landscape makes it difficult to build a sustainable business around that labor. This story is not unique—it is repeated across thousands of smaller projects. The tension between openness and compensation remains unresolved, and no single license model has proven to be a silver bullet. A question worth considering: if a maintainer's work is legally forked and monetized by competitors, what mechanisms—beyond license changes—could ensure that the original creator is not left subsidizing the entire ecosystem? The answer may require new norms, such as industry-wide recognition of maintainer contributions, or changes in how venture capital evaluates open-source startups. Until then, maintainers must navigate a system that often punishes the very person who writes the code.
