Nythral position: the license is not a footer detail. It decides what kind of trust a product can earn, what kind of competition it invites, and what kind of company can be built around it.
A common founder question sounds simple at first: should the code be open source, source-available, or closed with a free community edition?
The honest answer is that there is no magic license that gives every advantage at once. If a product wants the credibility of open source, it has to grant real open-source freedoms. If it wants to legally block commercial forks, it can do that, but it should stop calling itself open source. That distinction matters because sophisticated users, developers, and enterprise buyers notice when a company tries to borrow open-source language while withholding open-source rights.
Open Source Is Not Just Visible Code
The Open Source Definition is explicit: open source must allow free redistribution, derived works, and use in any field of endeavor. A license cannot say “you may use this, except for business,” and still be open source in the classical OSI sense.
That is the difference between “source is visible” and “software is open source.” A GitHub repository with a noncommercial restriction may be useful. It may even be generous. But it is source-available, not open source.
Working rule: if the license forbids commercial use, production use, SaaS hosting, resale, or competition, do not market it as open source. Call it source-available, community source, trial source, or noncommercial source.
The License Map
Every license below answers the same founder anxiety differently: how much freedom do users get, and how much commercial leverage does the original company keep?
| License or model | Type | What it allows | Commercial impact |
|---|---|---|---|
| MIT | Permissive open source | Use, modify, distribute, sublicense, and sell with minimal conditions. | Maximum adoption, weakest protection against closed commercial forks. |
| BSD | Permissive open source | Similar permissive rights; retain notices and disclaimers. | Friendly to vendors and embedded use, but easy to privatize downstream. |
| Apache 2.0 | Permissive open source | Broad commercial use plus explicit patent license and notice requirements. | Often the safest permissive choice for infrastructure and enterprise adoption. |
| MPL 2.0 | Weak copyleft open source | File-level copyleft: changes to MPL files stay open, larger combined apps can remain proprietary. | A middle path when you want some reciprocity without GPL-level reach. |
| LGPL | Weak copyleft open source | Common for libraries; apps can link under conditions, library modifications remain shareable. | Useful when adoption by commercial software matters but core improvements should stay open. |
| GPLv3 | Strong copyleft open source | Commercial use is allowed, but distributed modified versions must preserve GPL freedoms. | Blocks closed redistributed forks, but can make some enterprise legal teams cautious. |
| AGPLv3 | Network copyleft open source | Like GPL, with extra source-sharing obligations for modified network services. | Strongest open-source answer to hosted SaaS clones, but higher adoption friction. |
| Business Source License | Source-available with delayed open source | Source is visible, but production or competitive use is restricted until a later conversion date. | Good for commercial control, but not open source before conversion. |
| PolyForm Noncommercial | Source-available noncommercial | Use is allowed for noncommercial purposes, commercial use requires permission. | Clear commercial control, but it cannot be honestly positioned as open source. |
| Proprietary + free tier | Closed source | Users get product access, not source-code freedoms. | Maximum control, lowest community development and audit credibility. |
Why Ceph Could Sell for $175M
Ceph is a useful example because it breaks the naive idea that “open source means you cannot build a valuable company.” The Ceph repository's license file states that most of the code is under LGPL 2.1 or LGPL 3, with parts under BSD-style, Apache, Boost, public-domain, and other compatible licenses. That is real open source. It does not prohibit commercial use.
In 2014, Red Hat agreed to acquire Inktank, the company behind Ceph, for approximately $175 million in cash. Red Hat did not buy the exclusive right to stop everyone else from using Ceph. It bought the team, customer relationships, enterprise support motion, roadmap influence, brand trust, and the strategic position around distributed storage.
Known Products and Their Licensing Lessons
The best examples show that “open source” is not one business model. It is a set of rights that can support many business models.
| Project | License posture | Lesson |
|---|---|---|
| Linux kernel | GPLv2 | Strong copyleft can coexist with massive commercial ecosystems when the project becomes infrastructure. |
| Kubernetes | Apache 2.0 | Permissive licensing helped cloud vendors and enterprises adopt it widely, while brand and governance shaped trust. |
| PostgreSQL | PostgreSQL permissive license | A permissive database can still build an enormous ecosystem through quality, stability, and reputation. |
| WordPress | GPL | The core is open, while hosting, themes, plugins, services, and ecosystem trust create commercial value. |
| Blender | GPL | Open source can win creative tooling markets when community, foundation governance, and professional quality align. |
| Ceph | Mostly LGPL | Open source does not prevent acquisition value; it moves value into team, support, brand, and strategic ecosystem position. |
| MariaDB MaxScale-style BSL products | Business Source License | Source-available can protect commercialization for a time, but it is a different promise from open source. |
The Fork Fear Is Real
The fear sounds like this: if the code is open, a competitor can copy it, add better marketing, and sell the product faster.
That can happen. A license is not a substitute for product strategy. MIT and Apache make copying easy. GPL makes closed redistribution harder. AGPL makes modified hosted services harder to keep private. Source-available licenses can forbid commercial forks entirely, but at the cost of open-source legitimacy.
The question is not “how do we make copying impossible?” The question is “what advantage are we building that a fork cannot cheaply copy?”
Open-Core Is Usually the Practical Middle
For many product companies, the practical answer is not “everything open” or “everything closed.” It is open-core.
The core product is genuinely open source. The paid product adds operational features that businesses expect: hosted cloud, managed upgrades, SSO, role-based access control, audit logs, backups, high availability, compliance controls, security monitoring, signed builds, priority support, migration help, and team management.
This works when the paid layer is not a cynical crippleware wall. The open product must be useful enough to earn trust. The commercial product must be useful enough that serious teams prefer paying over operating everything themselves.
Related Nythral context: see our open-source projects for the public tools we maintain and the way we present official Nythral-backed software separately from ordinary code visibility.
So Which License Should A Founder Choose?
If the goal is maximum adoption and enterprise comfort, Apache 2.0 is often the cleanest default for infrastructure. It is permissive, familiar, and includes explicit patent language. The tradeoff is that commercial forks can close their changes.
If the goal is a real open-source project with stronger reciprocity, GPLv3 or AGPLv3 is the more defensive path. GPLv3 helps when modified software is redistributed. AGPLv3 is more relevant when the product is a server or hosted service, because modified network use triggers source-sharing obligations. The tradeoff is higher legal friction for some companies.
If the goal is to prevent commercial clones, choose source-available. Use something like BSL, PolyForm Noncommercial, or a custom commercial license. But say it plainly. Do not call it open source.
| Founder priority | Best fit | Tradeoff |
|---|---|---|
| Maximum adoption | Apache 2.0 or MIT | Competitors can build closed products from the code. |
| Infrastructure credibility | Apache 2.0 | Less defensive against hosted or proprietary forks. |
| Reciprocity on redistribution | GPLv3 | Some vendors and enterprise teams will hesitate. |
| Defense against SaaS clones | AGPLv3 | Still open source, but with more procurement and legal friction. |
| Commercial control over forks | BSL or PolyForm Noncommercial | Not open source before conversion or while noncommercial restrictions apply. |
| Premium product business | Open-core | Requires discipline: the free core must be real, and the paid layer must add operational value. |
The Clean Recommendation
For a developer-facing product that wants community respect and commercial upside, the strongest strategy is usually:
- make the core genuinely open source;
- choose Apache 2.0 for maximum adoption, or AGPLv3 if hosted clones are the central fear;
- protect the product name, logo, website, marketplace, official builds, and certification channel through trademarks;
- sell the best way to use the software: hosted cloud, official signed builds, support, enterprise controls, monitoring, upgrades, security, and integrations;
- never market source-available restrictions as open source.
The uncomfortable part is also the strategic clarity: open source means competitors may sell around your code. The way to win is not to pretend the code cannot be copied. The way to win is to become the project people trust, the release they install, the support team they call, and the roadmap they believe will still matter in five years.