An open-source license dispute is rarely about a license alone. Open-source software is meant to be free for anyone to use, change and share, and that promise built much of the modern web. It also holds a tension that surfaces every few years: what happens when a company makes serious money hosting free software that someone else mostly built and maintains?
The public clash between the company behind WordPress.com and the hosting provider WP Engine in autumn 2024 put this question in front of a wide audience. Without taking sides in the details, it is a good moment to explain how these conflicts typically start, because the pattern is not unique to WordPress.
Free to use does not mean free of rules
A license grants permissions. Permissive licenses such as MIT or Apache let almost anyone reuse the code, commercial products included, with few conditions. Copyleft licenses, such as the GPL family, let you use and modify the code but require that distributed versions stay open under similar terms. The Open Source Initiative maintains the best-known definition of what counts as open source.
Here is the detail that matters for hosting. Many copyleft duties are triggered by distribution, meaning you hand a copy of the software to someone else. A company that runs the software on its own servers and lets customers use it over the web may never distribute it at all. This is sometimes called the hosting loophole, and it is why some projects wrote licenses that treat network use as a trigger too.
So a host can build a thriving business on open-source software, follow the license to the letter, and still leave the project’s creators feeling taken advantage of. Both statements can be true at once, which is what makes every open-source license dispute so hard to settle.
Where the real friction comes from
An open-source license dispute rarely starts with a violation. They usually grow from one of four sources.
The first is money and contribution. In nearly every open-source license dispute, money sits underneath. A project is sustained by maintainers, many of them volunteers or employees of a few sponsors. If large commercial users take value without funding or contributing code, maintainers feel the imbalance. Hosts reply that they pay for infrastructure, employ support staff and bring users to the ecosystem.
The second, and often the loudest in an open-source license dispute, is trademarks. Code license and brand rights are separate. A project may let anyone copy the software yet keep strict rules on its name and logo. Hosting companies often use the name in marketing to describe what they offer, and the line between accurate description and implied endorsement can be thin.
The third is control of shared infrastructure. Plugin directories, update servers and package registries are run by someone, and whoever operates them holds power. A change to access rules can affect every host and customer at once.
The fourth is competition. Sometimes the project’s steward also runs a commercial service, which makes the steward both rule-setter and rival to other hosts. That naturally breeds mistrust.
Similar clashes have happened before. Several database and infrastructure projects moved to more restrictive licenses after cloud providers began selling them as paid services, and some of those changes prompted community forks under open licenses. The details differ, but the shape of each open-source license dispute repeats: a commercial host captures much of the revenue, the originators object, and the community splits over fairness versus freedom. Funding pressure of this kind is part of the story in our primer on how venture capital works.
What an open-source license dispute means for customers
If you run a site or product on open-source software through a host, an open-source license dispute between the host and the project can feel remote. It can still have practical effects. Updates and plugins may be blocked or delayed if access to a central repository is restricted. Branding and support language can change. Legal uncertainty can affect pricing or the host’s long-term plans. Forks may appear, forcing you to decide which version to follow.
Most of the time ordinary sites keep working. Still, it helps to know where your dependencies come from, and it helps to have a plan for outages, much like the one described in our guide to incident management tools for IT teams.
How to protect yourself
A little preparation goes a long way. Know your stack: list the software, plugins and themes your site uses and who maintains each one. Keep backups you control, stored outside your host, so you can move quickly. Avoid lock-in by preferring standard formats and portable setups, so that migrating is a weekend job and not a rebuild.
Read licenses before building a business on top of something. If you plan to resell or embed software, check what the license requires and whether trademarks limit your marketing. And support what you rely on. Sponsoring maintainers, paying for premium tools and contributing fixes all reduce the chance that a project burns out or turns defensive.
Hosts and vendors can lower friction by being clear and generous. Contribute upstream in proportion to the value you extract, and do it visibly. Read trademark policies carefully and ask permission when unsure. Describe your service accurately, without implying official status.
Project leaders have duties too. Clear governance, written trademark guidelines and predictable rules for directories and updates make an open-source license dispute less likely and less personal. When one organization controls a critical resource, it should use that control openly.
The practical takeaway: licenses decide what you may do with code, but trademarks, funding and control of shared infrastructure decide how relationships turn out. Know which of those your business depends on, and keep an exit route.
