In the sprawling ecosystem of open source, license violations are as common as bug reports. Most are ignored. A few escalate into lawsuits that drain both sides. But one maintainer turned an Apache 2.0 violation into a seven-figure consulting retainer—a deal that reshaped how he thinks about open source value.

The story begins with a library used for data serialization. It was released under the Apache License, Version 2.0, a permissive license that requires preserving copyright notices and disclaimers. A startup building a SaaS analytics platform copied the code, modified it, and deployed it as part of their proprietary backend—without the required attribution. The maintainer discovered the infringement not through a formal audit, but by browsing the GitHub fork network. A fork had been made from the startup's internal repository, and the license file was missing.

When the maintainer emailed the startup's CTO, the response was polite but dismissive. The CTO argued that since the library was “just a utility,” the license notice didn't matter. The maintainer explained that Apache 2.0 requires the notice to accompany all copies, modified or not. The startup had over 50 internal users relying on the modified library, and rewriting it would take months. The CTO offered to add a credit in the README. The maintainer declined.

This is where most stories end—either with a settlement for a few thousand dollars or with the maintainer giving up. But this maintainer saw an opportunity. He proposed a consulting retainer: $15,000 per month for a compliance audit, remediation of the violation, and ongoing maintenance of the library. The startup, facing a costly rewrite and potential legal exposure, accepted. Over five years, the retainer would total $900,000—a seven-figure sum when factoring in a revenue-sharing clause for future commercial licensing.

The License Violation That Built a Business

The violation itself was textbook. The startup had taken the maintainer's library, stripped the Apache 2.0 header, and integrated it into a proprietary microservice. The modified code was then deployed across dozens of containers. The maintainer spotted the fork because he monitored the GitHub network graph for his repositories—a practice few maintainers have time for.

When he reached out, the startup's legal team initially ignored him. It took a second email, cc'ing the company's outside counsel, to get a response. The startup's position: they believed the Apache license allowed them to remove notices if the code was substantially altered. This is a common misconception. The Apache 2.0 license explicitly requires that all copies retain the original copyright notice, even if modified. The only exception is for “reasonably conspicuous” attribution in documentation, not wholesale removal.

The maintainer didn't threaten a lawsuit. Instead, he offered a path to compliance: a full audit of their codebase, identification of all affected files, and a plan to add the missing notices. He priced this at a flat fee of $50,000. The startup balked. That's when he proposed the monthly retainer.

“I realized they had a long-term dependency on my library,” the maintainer later wrote in a blog post. “They couldn't just drop it without rearchitecting their core data pipeline. That gave me leverage.”

Why Most Violations End in Silence or Lawsuits

According to some estimates, roughly 90% of open source license violations go unresolved. Maintainers lack the time, money, or legal backing to pursue them. The few that do escalate often end in cease-and-desist letters or settlement demands for a few thousand dollars—hardly worth the effort.

Legal threats also destroy community goodwill. A maintainer who sues a user risks alienating other contributors. The Apache Software Foundation, for example, rarely litigates; it prefers to resolve violations through education. Only well-funded entities like the Software Freedom Conservancy or the Linux Foundation have the resources to sue—and even they do so sparingly.

For individual maintainers, the calculus is brutal. Hiring a lawyer costs $300–$500 per hour. A lawsuit can drag on for months. Even if you win, damages are often limited to actual harm, which is hard to prove when the code is free. Most maintainers conclude it's not worth it.

But this maintainer realized that the startup's dependency was a form of lock-in. They had built their data pipeline around his library's specific API. Rewriting it would take at least three months of engineering time—worth roughly $200,000 in salary costs. The retainer he proposed was less than that, and it came with ongoing support.

The Counteroffer That Changed Everything

The maintainer's counteroffer was simple: instead of a one-time payment, the startup would pay $15,000 per month for a “compliance and maintenance retainer.” This covered the audit, remediation, and all future updates to the library. The startup would also get priority support and a guarantee that the maintainer would not relicense the code in a way that broke their usage.

The startup's CTO was skeptical but saw the math. A rewrite would cost more than the retainer, and the retainer also gave them a direct line to the maintainer—someone who understood the code better than anyone else. They agreed to a six-month trial.

After the first audit, the maintainer identified 47 files missing license headers. He submitted patches to add them, along with a compliance guide for the startup's engineering team. The retainer also included monthly contributions to the upstream project: bug fixes, documentation improvements, and performance optimizations. Over time, the startup's developers began submitting their own patches, which the maintainer reviewed as part of the retainer.

The deal evolved. After two years, the startup asked to include a clause allowing them to sublicense the library under a different license for a specific product. The maintainer agreed, with a revenue split of 10% on any commercial sublicensing income. That clause alone added roughly $150,000 over the next three years.

“I never expected to make money from open source,” the maintainer said in a podcast interview. “But once I realized how much value my code was generating for that company, I felt justified in asking for a share.”

How the Deal Was Structured

The retainer agreement was built around four components. First, a monthly invoice for ongoing maintenance—bug fixes, security patches, and compatibility updates. Second, a compliance review service: every quarter, the maintainer would audit the startup's codebase for license compliance. Third, an escrow clause: if the maintainer stopped maintaining the library, the startup could relicense it under the standard Apache 2.0 terms, with all notices intact. Fourth, a non-disclosure agreement that protected the startup's proprietary modifications from being disclosed.

The revenue-sharing clause for future commercial licensing was a separate addendum. It applied only if the startup wanted to offer the library as part of a proprietary product under a different license. The split was 90/10 in the startup's favor, but the maintainer retained copyright ownership of the original code.

This structure gave the startup certainty: they knew exactly what they were paying each month, and they had a fallback if the maintainer walked away. It also gave the maintainer a steady income stream—$180,000 per year, with minimal overhead. His only costs were his time and a few cloud instances for testing.

The deal was not without risks. The startup could have terminated the retainer after six months, leaving the maintainer with nothing but the audit fee. But by then, the maintainer had already built a relationship with their engineering team. The retainer was renewed annually for five years.

The Economics of a Single-Project Consulting Practice

With one client paying $15,000 per month, the maintainer's effective hourly rate was roughly $200–$250, assuming 60–80 hours of work per month. His margins were near 100%, since he had no employees, no office, and no marketing costs. The only expenses were a laptop, a cloud server, and health insurance.

Compare this to typical open source income. GitHub Sponsors pays a few hundred dollars per month to most maintainers. Patreon campaigns for open source projects often bring in $1,000–$5,000 per month. Even popular projects like Vue.js or React earn their maintainers far less than $180,000 per year from direct donations. The maintainer's single retainer dwarfed what most open source developers make from their projects.

But the economics come with trade-offs. The maintainer was now a de facto employee of the startup, even though he was an independent contractor. His roadmap was driven by their needs, not the broader community's. He spent less time on upstream contributions and more time on features that only one company wanted. Over five years, his open source contributions outside the retainer dropped by about 70%.

There was also single-client concentration risk. If the startup had been acquired or changed strategy, the retainer could have ended overnight. The maintainer mitigated this by saving aggressively and building a small buffer of consulting clients, but the retainer remained his primary income source.

What This Means for Open Source Sustainability

The story offers a template for maintainers of critical infrastructure libraries. License violations are not just legal problems—they are signals of dependency and value. A company that violates a license is often deeply reliant on the code. That reliance can be converted into a revenue stream.

Retainers like this are not available to every maintainer. They work best for libraries that are hard to replace, have a steep learning curve, or are embedded in complex systems. A simple utility like a string manipulation library would not command $15,000 per month. But a serialization library, a database driver, or a machine learning framework might.

The model also scales poorly. A maintainer can only handle a handful of retainer clients before becoming a bottleneck. And if the client decides to rewrite the dependency in-house, the retainer disappears. The maintainer in this case was lucky that the startup's CTO valued continuity over short-term cost savings.

Some argue that this approach commodifies open source and undermines the spirit of collaboration. If every maintainer starts charging for compliance, the ecosystem could fragment into a patchwork of paid relationships. Others counter that open source was never free—it was always subsidized by unpaid labor. Retainers simply make the economics explicit.

As one prominent open source lawyer put it: “The license is a contract. If you violate it, you owe the licensor something. That something can be money, or it can be work. The maintainer chose work, and it paid off.”

The Uncomfortable Takeaway for Maintainers

The lesson is not that every maintainer should sue or threaten their users. It's that many maintainers underestimate the leverage they have. A company that uses your code in a commercial product is generating value from it. If they violate the license, they are in a weak negotiating position. A polite conversation can lead to a deal that benefits both sides.

The maintainer in this case didn't start with a legal threat. He started with a question: “How can we resolve this so that you can keep using my code, and I can get paid for the work I've already done?” That framing made the negotiation collaborative rather than adversarial.

He also documented his compliance value proposition. He created a one-page PDF explaining what companies get from a retainer: audit reports, priority support, guaranteed response times, and a direct line to the person who wrote the code. That document was key to convincing the startup's CFO that the retainer was a good investment.

“I tell every maintainer I meet: build a service wrapper around your code,” he said. “Even if you never use it, knowing you could monetize your work changes how you think about your project.”

The deal is now in its sixth year. The startup has not rewritten the library. The maintainer has earned over a million dollars. He still contributes to open source, but now he does it on his own terms. And the library's license compliance is better than ever—because one company is paying to keep it that way.

Counterarguments and Limitations of the Retainer Model

This success story is inspiring, but it's important to examine the potential pitfalls and criticisms. One major concern is that the retainer model can create a conflict of interest. The maintainer is incentivized to keep the library stable but also to ensure the startup remains dependent on his expertise. If the library becomes too easy to replace, the retainer could be cancelled. Some might argue this creates a subtle disincentive to improve documentation or simplify the API.

Another criticism is that the model favors maintainers of already popular or entrenched libraries. A new library with a small user base has no leverage to demand a retainer. This could exacerbate the inequality in open source, where a handful of projects capture the majority of financial support. Smaller projects might struggle to attract any funding at all, while the maintainer of a key dependency earns a comfortable living.

There is also the risk of moral hazard. If companies know they can simply pay a retainer after violating a license, they might be less careful about compliance in the first place. The maintainer in this case did not publicize the violation, so the startup's reputation was not harmed. Other companies might see this as a cost of doing business, rather than an ethical obligation to respect licenses.

From the maintainer's perspective, the retainer can be a golden handcuff. He is tied to a single client's priorities, which may not align with the broader open source community. For example, if the startup wants a feature that is niche and unlikely to be used by others, the maintainer spends time on that instead of more widely beneficial improvements. Over time, the library's roadmap becomes skewed, potentially alienating other users.

Despite these concerns, the retainer model offers a pragmatic path for maintainers who want to sustain their work without relying on donations or venture capital. It is not a one-size-fits-all solution, but it demonstrates that open source value can be captured in ways that go beyond traditional licensing.

For a deeper look at how licensing negotiations can determine company outcomes, read the database license negotiation story. And for a contrasting take on build-time economics, see how one cloud provider profited from unfinished builds.