When revenue disappoints, open-source companies often reach for the license.
The reasoning is understandable: users receive valuable software without paying, so the free grant must be too generous. Tighten the license, restrict commercial use, or move critical capabilities into a proprietary tier, and some portion of that value should become revenue.
Sometimes a licensing change is necessary. But it is rarely a substitute for pricing and packaging. A license defines what people are legally permitted to do. Pricing gives them a practical reason to buy. Confusing those jobs produces a familiar outcome: more community anxiety, more sales friction, and roughly the same weak conversion.
Licenses create boundaries, not demand
An open-source license answers questions about permission, modification, distribution, and—depending on the license—reciprocity. It can influence which companies adopt the project and how competitors may incorporate it into their products.
It cannot make your commercial offer valuable.
A team that is content to run the free software may continue doing so after a license change. A company willing to comply with the AGPL, for example, does not become a customer merely because network use carries source-sharing obligations. Conversely, a buyer may happily pay for an Apache-licensed product when the commercial version eliminates enough operational risk.
This distinction matters because maintainers frequently diagnose a packaging problem as a licensing problem. They see thousands of deployments and too few contracts. Yet those deployments may belong to individual developers, small teams, consultancies, internal tools, experimental workloads, or companies with abundant infrastructure expertise. Legal leverage will not turn all of them into qualified buyers.
The commercial question is not, “How do we stop people from using this for free?” It is, “At what point does operating this independently become less attractive than buying from us?”
That point is usually created by organizational complexity, not source-code access.
Free use and commercial substitution are different problems
It helps to separate three groups that are often collapsed into one metric called “community adoption.”
The first group consists of genuine free users. They run small workloads, contribute fixes, teach others, or use the project where no meaningful budget exists. Most would not purchase the product if the free option disappeared. They would choose another project, build something smaller, or abandon the initiative.
The second group consists of future buyers. They can operate the software today, but their requirements are changing. They may soon need centralized policy, auditability, predictable upgrades, identity integration, regional deployment controls, or contractual accountability. Their willingness to pay grows with the cost of coordination.
The third group consists of commercial substitutes: organizations using your work to provide a competing product or service. Licensing may be highly relevant here. A permissive license can allow broad commercial reuse; a copyleft license can impose reciprocal obligations; a source-available license can restrict particular competitive activities. Those are consequential strategic choices.
But restricting the third group does not automatically monetize the first two. If the paid package remains vague, awkward, or disconnected from buyer pain, the company has protected an asset without creating an offer.
Before changing a license, determine which group is causing the actual problem. “A large company uses our software for free” is not sufficient evidence. Ask whether it is avoiding a paid capability, selling a substitute, or simply exercising rights you intentionally granted.
A restrictive license sends a commercial signal
License changes are not merely legal edits. They communicate how the company expects value to flow between maintainers, users, contributors, and downstream businesses.
That signal can be appropriate. If a well-capitalized vendor is packaging a project into a competing service while contributing little to its maintenance, a permissive arrangement may no longer support the project’s goals. Founders are allowed to protect the business required to fund development.
The mistake is pretending that nothing meaningful has changed.
Code under licenses such as the Business Source License or commercial-use restrictions may remain visible, modifiable, and eventually relicensed, depending on the terms. It should not automatically be described as open source while those restrictions apply. “Source available” is not an insult; it is a more accurate category. Clear language preserves more trust than strained attempts to retain an open-source label.
A change also creates practical costs. Some contributors will reconsider participation. Corporate adopters may trigger new legal reviews. Linux distributions and open-source ecosystems may treat the project differently. Prospects may worry about future changes even if the current terms are acceptable.
Those costs can be worth paying, but only for a specific strategic benefit. “We hoped conversion would improve” is not specific enough.
Package the work companies do not want to own
The strongest open-core offers charge for burdens that increase as software moves from useful tool to shared infrastructure.
A developer can configure one instance manually. A platform team managing 300 instances needs policy. A startup can inspect logs after an incident. A regulated enterprise needs durable audit records and evidence. A small team can coordinate upgrades in a chat channel. A global company needs staged rollouts, compatibility commitments, and recovery procedures.
These are not arbitrary tollbooths placed in front of popular features. They are products for organizational work.
Good paid packaging commonly addresses four kinds of burden:
- Coordination: role-based administration, delegated control, fleet management, and policy enforcement.
- Risk: tested upgrades, long-term maintenance, security response commitments, backup, and disaster recovery.
- Evidence: audit trails, compliance artifacts, reporting, and data-governance controls.
- Accountability: service levels, escalation paths, architecture guidance, and a vendor willing to sign a contract.
The free edition should remain genuinely useful. That is what sustains adoption, learning, and community credibility. The commercial edition should become attractive when the deployment crosses an operational boundary: more teams, more data, more jurisdictions, more criticality, or less tolerance for failure.
This framing also improves sales. Instead of arguing that a prospect has become “too big” to use the free version, you can show the costs and risks the paid product removes.
Price the avoided burden, not access to bits
Once the paid package solves a recognizable problem, its pricing metric should track the growth of that problem.
Seats may work for administrative and collaborative products, but they are often poor proxies for infrastructure value. Charging per node can discourage resilient architecture. Charging per CPU may feel disconnected from outcomes as hardware efficiency changes. A flat enterprise fee is simple, yet it can make small initial deployments difficult to approve and large ones unnecessarily cheap.
There is no universally correct metric. The useful test is whether a buyer can predict the bill and understand why it rises.
If value grows with managed data, a volume band may fit. If the product coordinates a fleet, managed instances or clusters may be defensible. If the commercial package primarily governs human access, active administrators or managed identities may make sense. Hybrid pricing can combine a predictable platform fee with a bounded usage component.
Avoid choosing a metric merely because the software can count it. Telemetry makes something measurable; it does not make it valuable.
You should also preserve an escape valve for community use. Reasonable free thresholds, noncommercial community programs, and clear self-hosting terms reduce fear without undermining the enterprise offer. The objective is not to extract payment from every successful deployment. It is to capture a fair portion of the value created where a real budget and a costly problem coexist.
Run a packaging test before a license change
Before rewriting the project’s terms, test whether the business can sell a better commercial package under the current license.
Interview recent buyers, lost opportunities, and sophisticated free users separately. Ask buyers what internal work disappeared after purchasing. Ask lost prospects which promised capability lacked urgency. Ask free users what would have to change before operating the project themselves became unacceptable.
Then write the paid offer without mentioning the license. Describe the buyer, the triggering event, the operational burden, the capabilities that remove it, and the pricing metric. If the offer cannot stand on its own, additional legal restrictions are unlikely to rescue it.
A licensing review may still reveal a separate competitive threat. Treat that as its own decision, with explicit goals such as preventing an unreciprocated hosted substitute, preserving contributor rights, or enabling dual licensing. Define in advance what success would look like and what ecosystem costs the company is prepared to accept.
This sequence is less emotionally satisfying than “close the loophole,” but it is more commercially honest. It forces the company to distinguish value capture from control.
The best open-source businesses are not built by making free software progressively harder to use. They are built by making independent operation possible while making commercial operation preferable. The license protects the rules of the ecosystem. The product, package, and price must still earn the purchase.
Leave a Reply