Every agency that has standardized on a theme for client work eventually gets burned by one of two scenarios, and it is rarely a bug. Either the free tier they built forty client sites on quietly turns into a $350-a-year bundle they did not ask for, or the plugin a client’s whole catalog depends on gets pulled from the repository with no warning because the original author stopped answering email two years ago. Neither scenario shows up in a feature comparison, and neither shows up in a changelog, until it already happened.

It shows up eighteen months into a maintenance contract, when a client calls asking why their site suddenly has a “license expired” banner, or why the developer quote to add one new section just tripled because the blocks that used to be free now require a Pro license across the agency’s whole site portfolio.

This is the question an experienced agency developer actually asks before standardizing on a theme, and it is almost never the question a sales page answers. “Is it fast” gets answered. “Does it support the block editor” gets answered. “What happens to the two hundred client sites I’ve built on this if the company behind it gets acquired, runs out of funding, or decides the free tier was a mistake” does not get answered, because there is no marketing page built to answer it honestly.

This post is an attempt to answer it honestly, for Brndle specifically and as a framework for any theme an agency is considering, using real precedent instead of hypotheticals: one acquisition that happened to a direct competitor in this same comparison series, and one takeover that happened to one of WordPress’s most widely used plugins fourteen months ago.

In this piece

Why “will this get abandoned or monetized on me” is underexamined

Theme and plugin selection in an agency context almost always gets evaluated on the wrong time horizon. A developer trials a theme for a week, builds a demo site, checks the Lighthouse score, reads the documentation, and ships a recommendation. That process answers “is this good today.” It does not answer “what does owning forty client sites on this look like in year three,” which is the actual commitment an agency is making when it picks a default theme for new builds.

A theme is not a one-time purchase decision the way a stock photo is. It is infrastructure. Every client site built on it inherits whatever happens to the vendor behind it, for as long as that site exists, and most agency relationships with a client outlive the original build by years.

The reason this gets underexamined is structural, not careless. Vendor risk is genuinely hard to evaluate in advance. A company’s funding situation, acquisition appetite, and roadmap commitment are not published anywhere a developer can check during a trial. The honest answer to “will this get bought out” is usually “nobody outside the company knows,” which makes it tempting to skip the question entirely and default to whichever theme felt nicest in the admin screen.

But skipping the question does not make the risk disappear, it just defers discovering it to the worst possible moment: a client site already in production, a support contract already signed, and a theme swap now costing real hours instead of being a five-minute decision made before the first line of code was written.

The question that actually matters is not “will this specific company change its mind”, nobody can promise that, including Wbcom Designs about Brndle. It is “if it does, what actually happens to the sites already built on it.” That is a licensing and architecture question, not a prediction, and it has a real answer you can verify today by reading a LICENSE file.

What GPL-2.0 actually guarantees, and what it doesn’t

Brndle ships under GPL-2.0-or-later, confirmed directly from the project’s own LICENSE file in its GitHub repository: the standard GNU General Public License, Version 2, June 1991, the same license WordPress core itself ships under. This is not a marketing claim layered on top of a different underlying license, the way some WordPress products quietly split their licensing between GPL code and a proprietarily-licensed design layer. The whole theme, all 20 native blocks, the Blade templates, the Acorn integration code, is GPL-2.0-or-later, full stop.

GPL-2.0 guaranteesGPL-2.0 does NOT guarantee
Full source code must stay available to anyone who receives the software, forever.That anyone will actually bother to fork an abandoned project. Forkability is a floor, not a promise of continuity.
Anyone can modify the code for their own use, including commercially.That a fork will be maintained to the same standard, speed, or polish as the original vendor’s work.
Anyone can redistribute it, including a modified fork, and sell support around it.That the original vendor won’t launch a separate paid product and shift focus away from the free GPL core.
A derivative work must stay GPL, a fork can’t be re-licensed proprietary, so it stays forkable too.Protection against a trademark or platform-governance dispute cutting off a specific distribution channel.

That table is the real content of “GPL means it can’t be abandoned the way a proprietary theme can.” It is not that abandonment becomes impossible, Wbcom Designs can absolutely stop working on Brndle, the same as any company can stop working on any product. What becomes impossible is permanent, unrecoverable abandonment, where the code disappears, locks up, or can only be continued by the original vendor’s say-so. A GPL-2.0 project that its original author walks away from is a project anyone else can pick up, exactly the way WordPress itself, bbPress, and dozens of other abandoned-then-revived GPL projects have been picked up by new maintainers over the platform’s history.

In short: GPL-2.0 is a real, structural, legally enforceable floor under the worst-case scenario. It is not a guarantee that the worst case never happens, and it is not a substitute for actually checking a project’s health before standardizing on it. Both of those things are true at once, and a theme that only tells you the first half is not being fully honest with the agency evaluating it.

Real precedent #1: Kadence’s 2026 move to a Liquid Web/StellarWP bundle

This is not a hypothetical dressed up as a case study. It is documented on this same site, checked on 29 October 2026, in our GeneratePress vs Kadence vs Brndle comparison: Kadence, one of the most widely adopted free WordPress themes with the Kadence Blocks plugin at 600,000+ active installs on its own, is now part of Liquid Web’s Nexcess software portfolio, sitting alongside StellarWP products like The Events Calendar, LearnDash, and Give. Kadence’s own pricing pages now redirect to liquidweb.com/software/kadence/, and as of that check, there was no standalone “just Kadence Blocks Pro” purchase available on that page at all.

The pricing that replaced it is a single bundle: $350/year for one site up to $999/year for 100 sites, and every tier includes Kadence plus The Events Calendar, LearnDash, and Give, whether a given client build needs event ticketing or course software or not. That is a materially different commitment than the simpler, single-product pricing Kadence used to run as an independent theme and plugin company. An agency that specced a client project around “Kadence Blocks Pro for $X/year” before this change is now looking at a bundle it may not want in order to keep the one thing it actually uses.

Three things about this case are worth being precise about, because overstating it would be exactly the kind of dishonesty this post is trying to avoid:

  • The free Kadence theme and the free Kadence Blocks plugin, with 20+ block types, are still free. Nothing was taken away from users who never paid. This is not a “bait and switch” in the sense of free users losing access to something they already had.
  • Existing Kadence Blocks Pro license holders were not immediately cut off. This is a go-forward pricing and packaging change, not a retroactive one, which is the normal and reasonable way a company restructures pricing after an acquisition.
  • The acquisition itself is not evidence of bad intent. Liquid Web and StellarWP are established companies with a track record in the WordPress space; this is a normal consolidation in a maturing market, not a predatory takeover. The point is not “Kadence did something wrong.” The point is that this is what a standalone product’s licensing model can turn into after an acquisition, regardless of anyone’s intentions, and it is the kind of change an agency has zero ability to veto or predict.

That last point is the one that matters for risk analysis. An agency that built its quoting and client contracts around Kadence Blocks Pro’s old standalone pricing had no say in this change and no advance warning beyond what any customer gets from a vendor’s own pricing page. The change is not catastrophic, existing functionality did not disappear, but it is exactly the category of risk this post is about: a theme or plugin’s commercial terms shifting underneath an agency’s existing client commitments, driven by a corporate decision the agency has no visibility into until it is already public.

Real precedent #2: the October 2024 ACF → Secure Custom Fields takeover

The second case is a sharper, more structurally relevant precedent, because it is specifically about control over a plugin changing hands against the original team’s wishes, and about GPL’s fork-ability being tested in real time rather than argued about in the abstract.

Advanced Custom Fields (ACF) is one of the most widely used plugins in the WordPress ecosystem, developed by WP Engine after WP Engine’s 2022 acquisition of Delicious Brains. In September 2024, a public dispute escalated between Automattic/WordPress.org and WP Engine over trademark use and contribution expectations.

On October 12, 2024, WordPress.org, under Matt Mullenweg’s direction, replaced the Advanced Custom Fields plugin listing in the official plugin directory with a forked version renamed Secure Custom Fields, citing a guideline that permits WordPress.org to make changes to a plugin without the developer’s consent “in the interest of public safety.” Because the fork used the same plugin identifier and update mechanism as the original, sites running ACF received Secure Custom Fields automatically on their next update, with no action taken by the site owner and, by most accounts, no advance warning.

Commentators at the time, and WP Engine’s own subsequent legal filings, described the mechanism as functionally resembling a supply-chain attack, regardless of the stated public-safety justification. A preliminary injunction in December 2024 required Automattic to stop blocking WP Engine’s access to WordPress.org infrastructure, and the underlying dispute has continued through litigation since.

Two structural facts about this case matter more than the drama around it, and both are confirmed directly from the Secure Custom Fields plugin page on WordPress.org itself, which still documents its own origin:

“Installing this plugin will deactivate plugins with matching function names/functionality, specifically Advanced Custom Fields, Advanced Custom Fields Pro, and the legacy Secure Custom Fields plugins, to avoid code errors.”, Secure Custom Fields plugin description, wordpress.org, changelog entry for 12 October 2024: “Fork – Change name of plugin to Secure Custom Fields.”

  • This was exactly the kind of takeover the GPL fork-ability argument is supposed to answer, and it played out as the license predicts. ACF is GPL-licensed. WordPress.org’s action was legally possible specifically because GPL permits anyone, including a platform the original developer does not control, to fork and redistribute the code. The same openness that makes this kind of unilateral action legally possible is what also guaranteed WP Engine could not be stopped from continuing to distribute ACF directly through its own channels, outside the WordPress.org directory, which it did.
  • Control over a distribution channel is a separate risk from control over the code, and GPL only protects the second one. WP Engine never lost the right to the ACF codebase. What it lost, for a period, was default placement in front of the millions of users who get updates through the WordPress.org directory rather than a direct download. An agency relying on a plugin’s presence in the official directory as part of its update pipeline experienced a real, disruptive, unannounced change in what code their clients’ sites were running, even though nothing about the underlying GPL license was violated by either side.

This precedent is less clean than a simple “theme got bought, prices went up” story, and that is exactly why it is worth including rather than reaching for a tidier example. It shows that the risks an agency actually faces are not limited to a vendor deciding to charge more. A plugin or theme’s governance, trademark standing, and distribution channel can all shift independently of its license and independently of the original developer’s intent, and GPL’s fork-ability is real protection against losing the code, but it is not protection against every way a dependency can become unstable underneath a client site.

What “no license checks” protects against, specifically

Brndle’s homepage states plainly: “Agencies can use it on unlimited client sites without a license check or activation key.” It is worth being precise about what that specific property protects against, separate from the broader GPL fork-ability argument above, because it is a narrower and more mechanical guarantee.

A license-key system, common across the premium WordPress theme and plugin market, typically works like this: the product phones home to a vendor-controlled activation server, usually on a schedule, to confirm the site’s license is current. If that check fails, the product can respond in a few ways depending on how it was built: it might silently stop receiving updates, it might show an admin warning, or, in stricter implementations, it might disable premium features or the product’s own functionality outright until the check passes again.

None of these failure modes require the vendor to act maliciously. A license server going dark because a small company shut down, or because an acquisition consolidated infrastructure and someone forgot to migrate a legacy endpoint, produces the identical symptom from the client site’s perspective: something that worked yesterday stops working today, for a reason the agency did not cause and cannot fix without the vendor’s cooperation.

ScenarioTheme/plugin WITH a license keyBrndle (no license key)
Client misses a renewal invoiceUpdates stop, some products disable premium features until renewedNothing changes, there is no renewal to miss
Vendor’s activation server has an outageActivation checks can fail on affected sites until the server recoversNo activation server exists to go down
Agency clones a site to staging or a new client domainRe-activation or a new license slot may be requiredNo activation step, the code runs the same anywhere
Vendor is acquired and migrates licensing infrastructureLegacy license servers can be retired, sometimes with short noticeNot applicable, there is no license infrastructure to migrate
Vendor shuts down entirelyExisting activations may keep working, but no new activations are possible and the check can eventually failNot applicable, functionality was never gated on an external check

A theme or plugin with no license check has no such dependency, structurally, not as a matter of vendor goodwill. Brndle’s release zip, pulled directly from GitHub Releases, is the same code regardless of how many sites it is installed on, whether those sites are client-owned, agency-owned, or staging environments, and whether or not anyone paid anything for it, because there is nothing to pay.

This is a narrower claim than “GPL protects you from abandonment,” and it is worth keeping the two separate. No license check protects against one specific, common, entirely mundane failure mode: a working feature breaking because of an external dependency unrelated to the code itself. It does not protect against the theme simply not being updated anymore, which is the abandonment scenario GPL’s fork-ability addresses instead. The two protections are complementary, not the same guarantee stated twice.

The honest flip side: free is not the same as risk-free

It would be dishonest to stop here, and it would specifically contradict the standard this site tries to hold itself to on posts like the recent color-scheme contrast audit, which published the failures in Brndle’s own code alongside the passes rather than only the parts that look good. The same rule applies here. A free theme with no Pro tier and no license checks removes two specific risks. It does not remove risk generally, and treating it as a magic exemption from everything this post has described would be its own kind of bait-and-switch.

Here is what GPL-2.0 and a no-license-check model specifically do not protect an agency from, stated as plainly as the protections above:

  • No guaranteed support SLA. A free, no-upsell project has no contractual obligation to respond to a support ticket in any timeframe, or at all. A premium theme’s paid support tier, whatever its other tradeoffs, at least comes with a stated response-time commitment an agency can put in a client contract. Brndle’s support currently runs through its GitHub issues and documentation; there is no paid escalation path to buy faster turnaround if a client emergency needs one.
  • No roadmap commitment. A paid product’s revenue gives its maintainers a direct, measurable incentive to keep shipping, because a stalled roadmap shows up in churn and renewal numbers the business tracks. A free project with no revenue tied to it has no equivalent feedback loop forcing continued investment.
  • Wbcom Designs could deprioritize Brndle. This needs to be stated without hedging: the company behind Brndle is a commercial business with other products, and nothing in this post, in GPL-2.0, or in Brndle’s current positioning makes Brndle immune to the same pressures that shifted Kadence’s roadmap after its acquisition, or that could lead any company to quietly slow investment in a free project in favor of something that generates revenue. The structural protection this post has described is real: if that happened, the code would not disappear, and it could be forked and continued by anyone, including by Wbcom Designs’ own competitors or by the agencies using it directly. But “the code survives” and “the project keeps actively improving at its current pace” are different claims, and only the first one is something GPL-2.0 actually guarantees.
  • A free project can still be abandoned in practice, even though it cannot be abandoned in the way a locked proprietary product can. A forkable-but-unmaintained project still requires someone, the agency itself, a community member, or a new commercial maintainer, to actually do the forking and the ongoing work. That is real effort an agency may end up bearing if the worst case happens, not a guarantee that someone else will always volunteer to bear it instead.
  • No Pro tier also means no dedicated resourcing for enterprise-specific needs. A paid tier, whatever its licensing downsides, often funds development of features a specific class of client needs: multisite license management, dedicated account support, custom SLAs. A project with no paid tier has no equivalent revenue stream earmarked for exactly those needs.

None of this is an argument against GPL or against no-license-check products generally. It is an argument against treating “it’s free and open source” as a complete answer to vendor risk, when it answers roughly half the question. The honest position, and the one this post is taking, is that GPL-2.0’s fork-ability and the absence of a license-check failure mode are real, verifiable, structural protections against two specific and common ways agencies get burned, standing on firmer ground than a vendor’s promise not to do those two things. They are not protection against every way a free, unfunded, single-vendor project can become a liability over a multi-year client relationship.

A framework for evaluating this risk on any theme

The point of this post is not “pick Brndle because of its license.” It is “ask this question about whatever theme you are evaluating, including Brndle, before you build forty client sites on it.” Here is the checklist, applicable to any theme or plugin an agency is standardizing on, not just the one this site happens to be written about:

  1. What license does the code actually ship under, confirmed from the LICENSE file, not the marketing page? GPL-2.0 or GPL-3.0 mean the fork-ability argument in this post applies. A split-licensed product, common in the ThemeForest and Envato marketplace model, where the PHP is GPL but the design, CSS, and bundled assets are proprietarily licensed, means only part of the product can legally be forked and continued if the vendor disappears.
  2. Does the product phone home to a vendor-controlled server for any function the site depends on at runtime? Not just for updates, those usually fail gracefully, but for feature gating, activation, or license validation that could, even in theory, disable something a client site actively uses if the check fails.
  3. Is the company behind the product a standalone business, or already part of a larger portfolio with its own acquisition history? A company that has already been acquired once, or that explicitly operates as a roll-up of multiple WordPress products under one umbrella, has a demonstrated pattern worth factoring in as a data point about how pricing and packaging might evolve again.
  4. What does the free tier actually include today, and is there a track record of features moving from free to paid over time? Check the product’s own changelog or release notes history, not just its current feature comparison table, for any precedent of a previously-free capability becoming a paid one.
  5. If the vendor disappeared tomorrow, who, specifically, could continue the project, and is there any sign that community or alternative maintenance already exists? A permissive license with zero community of contributors around it is a weaker practical safety net than the same license with an active contributor base already familiar with the codebase.
  6. What is actually written into the client contract about theme or plugin continuity? This is the step most agencies skip entirely. If a dependency failure is a risk worth analyzing at the vendor level, it is worth naming explicitly in the scope-of-work or maintenance agreement with the client, including who bears the cost of a theme migration if the underlying product becomes unviable.

Run that checklist against Brndle honestly: GPL-2.0-or-later confirmed from the actual LICENSE file, no runtime phone-home of any kind confirmed from the theme’s own source, Wbcom Designs is an independent, non-acquired company as of this writing, no precedent of a previously-free Brndle feature becoming paid because there has never been a paid tier to move features into, and an active public GitHub repository that any developer could clone and continue today without needing anyone’s permission. Run the same checklist against whatever else is on the shortlist. The answer that matters is not which theme wins in the abstract, it is which one an agency can defend, in writing, to a client who asks the uncomfortable question two years into the relationship.

Where Brndle sits today, stated plainly

Checked directly against the project’s own GitHub repository and homepage as of this post: Brndle is GPL-2.0-or-later, has no Pro tier, no license key or activation requirement of any kind, and is described on its own homepage as “a contribution to the WordPress commons,” with Wbcom Designs stating it sustains the project through its other commercial products rather than through Brndle itself.

That is the current, verifiable state of the project, not a promise about its state in three years. The structural protections this post describes, fork-ability under GPL-2.0 and the absence of any license-check failure mode, hold regardless of what happens to Wbcom Designs’ roadmap going forward, which is the entire point of calling them structural rather than promotional. An agency does not need to trust Wbcom Designs’ intentions to rely on those two specific guarantees; it needs to trust the license, which is independently verifiable and legally binding in a way a company’s stated intentions are not.

FAQ

If Brndle is GPL, can a competitor legally just copy it and sell a paid version?

Yes, with one important constraint: GPL-2.0’s copyleft clause means any redistributed version, modified or not, must also be released under GPL-2.0 or a compatible license. A competitor could legally take Brndle’s code, build a Pro version with extra features on top, and charge for the whole package, including support and the extra features. What they could not legally do is take Brndle’s existing free code, relicense that specific code as proprietary, and prevent others from continuing to use or fork the original free version.

Does “no license check” mean Brndle can never verify who’s using it?

Correct, by design. There is no mechanism in the theme that reports installation counts, site URLs, or usage back to Wbcom Designs, which is also what “no telemetry” on the homepage refers to. This is a tradeoff: it means the project has less first-party data about its actual install base than a product with phone-home telemetry would. An agency gets privacy and no failure mode in exchange for the project itself knowing less about its own adoption.

What specifically happened to Kadence that’s relevant here?

Kadence, previously an independent company selling its theme and the Kadence Blocks plugin directly, is now marketed and sold through Liquid Web’s Nexcess software portfolio, bundled with unrelated StellarWP products (The Events Calendar, LearnDash, Give) at $350 to $999 per year depending on site count, with no standalone purchase option as of the check documented in this site’s GeneratePress vs Kadence vs Brndle comparison. The free Kadence theme and free Kadence Blocks plugin are unaffected; the change is specifically to how the paid tier is packaged and priced.

Was the ACF takeover actually about licensing, or something else?

It was primarily a trademark and contribution dispute between WordPress.org’s leadership and WP Engine, not a licensing violation on either side. WordPress.org’s justification for replacing the plugin listing was a stated “public safety” guideline, and WP Engine’s legal response focused on the manner of the takeover and its effect on their business, not on a licensing breach. It is relevant to this post specifically because it demonstrates, in a real and recent event, how GPL’s fork-ability plays out when a plugin’s platform standing, not its code, comes under dispute.

Could something like the ACF situation happen to Brndle?

The ACF dispute was specific to WordPress.org’s plugin directory governance and a trademark conflict with a major hosting company; Brndle is a theme distributed via GitHub Releases rather than primarily through the WordPress.org theme directory, and Wbcom Designs has no comparable trademark dispute with WordPress.org. The precise mechanism of that takeover is unlikely to repeat identically, but the underlying lesson, that distribution-channel control is a separate risk from code ownership, applies to any project that relies on a third-party directory or marketplace for discovery and updates.

If Wbcom Designs stopped maintaining Brndle, would existing client sites break immediately?

No. A theme that stops receiving updates continues to function exactly as it did on the last released version; nothing about an unmaintained GPL theme causes it to stop working on its own. The risk in that scenario is accumulating, not immediate: no new WordPress core compatibility fixes, no new feature development, and gradually increasing exposure to any security issue discovered after maintenance stopped.

Does GPL-2.0 mean Brndle has no security accountability if a vulnerability is found?

GPL-2.0 does not create or remove any particular support obligation; that is governed by how actively a project is maintained, not by its license. A GPL-licensed project with an active maintainer, which Brndle currently is, has the same practical responsiveness to a disclosed vulnerability as any actively maintained product. The license’s relevance to security is specifically about the worst case: if active maintenance stopped, a GPL project’s vulnerability could still be patched by someone else, where a closed-source project’s could not be patched by anyone except the original vendor.

Is a “no Pro tier” model sustainable for a company, or is Brndle eventually going to need to monetize it?

That is a legitimate open question this post cannot answer with certainty, because it depends on decisions inside Wbcom Designs that have not been made yet. What can be answered today: nothing in Brndle’s current code, GitHub repository, or stated positioning suggests a Pro version is in development, and the structural point of this post stands regardless of the answer, because even if Wbcom Designs did introduce a future paid tier on top of Brndle, the GPL-2.0 code already released would remain free, forkable, and usable exactly as it is today.

How should an agency actually document this risk for a client, in practice?

Name the dependency explicitly in the project’s scope-of-work or maintenance agreement: which theme or major plugin the build relies on, its license, and what the agency’s plan is if that dependency becomes unmaintained or changes its commercial terms. Most agencies never write this down, which means the first time it gets discussed is during the crisis itself, with a client who is understandably frustrated that nobody raised it earlier.

Does choosing a GPL theme with no license check mean an agency gives up any commercial protection a paid theme would offer?

It gives up the specific protections a paid product’s support contract and SLA can offer, addressed honestly in the flip-side section above. It does not give up any legal protection the paid product’s license itself would have provided, because premium WordPress themes are, in the overwhelming majority of cases, also GPL-licensed for their PHP code under WordPress’s own theme and plugin directory requirements; the commercial layer on top (support, updates, activation) is what differs, not the base code’s legal status.

The bottom line

GPL-2.0 is a real, legally binding, independently verifiable structural protection against one of an agency’s worst-case theme scenarios: total, unrecoverable abandonment where the code itself becomes inaccessible. No license check removes a second, more mundane but genuinely common failure mode: a feature breaking because an external activation server went dark for reasons that have nothing to do with code quality.

Both of these are confirmed, as of this writing, directly from Brndle’s own LICENSE file and its homepage’s stated terms, not inferred from marketing language. Neither of them is a guarantee that Wbcom Designs will keep investing in Brndle at its current pace indefinitely, that support tickets will get answered quickly, or that the project is somehow exempt from the same commercial pressures that pushed Kadence into a bundled subscription after its acquisition, or that put ACF’s distribution channel in dispute in October 2024.

An agency evaluating any theme, Brndle included, should check the license file, check for runtime phone-home dependencies, and write the answer into the client contract, rather than taking either a vendor’s confidence or a license badge as the end of the analysis. The license is the floor. What a team builds, documents, and commits to on top of that floor is still the agency’s job, not the theme’s.