The Counter-Stack: Building Profitable Enterprises on Open Source AI — and Making Values Valuable Again

A blueprint for OccupyAI.net, Vol. 1 of 3

Fair warning: this is not a post for the casual reader — it wades deep into the technical weeds of software licensing, trade secret law, and the Model Context Protocol, and just as deep into the political economics of monopoly, gatekeepers, and cooperative markets, so pour a coffee and settle in.

---

Two moments in that conversation matter enormously for what we’re building.

The first was Khan’s observation about DeepSeek. When an outsider shipped a model that rivaled the American giants at a fraction of the compute cost, it exposed a structural conflict of interest: the firms that dominate AI also sell the compute AI runs on. As Krugman put it, they have “no incentive to help the models use less compute — which in turn means using less electricity, means less environmental damage.” Inefficiency isn’t a bug in the incumbents’ business model. It is the business model.

The second was Khan’s reminder that “open source as a business model can also be enormously lucrative — because it can really catalyze innovation.” History backs her up: the breakthrough innovations — including the transformer architecture that made modern AI possible, which Google invented and then sat on until its authors left — come from outsiders and competitive markets, not from monopolies defending incremental turf.

Put those two ideas together and you get the OccupyAI thesis: the answer to concentrated, extractive, energy-gluttonous AI is not a petition. It’s a profitable alternative. Occupying AI means building the counter-stack — open models, community-owned compute, and connective software that keeps value circulating among people whose values align — and doing it as a business that sustains itself without a hyperscaler’s permission.

Here is how we intend to do it.

Part One: Profitable Enterprises on an Open Foundation

The economics of open source AI have crossed a threshold. Open-weight models now deliver a large share of the capability of frontier proprietary models at a tiny fraction of the cost, and they run on hardware you can own — including the kind of low-draw compute nodes (150–240 watts, roughly two bright light bulbs) that a rooftop of solar panels can power. That changes who gets to be an AI company.

The enterprises we’re building stack on top of each other:

Community AI infrastructure. Solar-powered, privacy-first AI compute nodes owned by the communities they serve — libraries, municipalities, cooperatives — rather than rented from a hyperscaler. Our CivicBoxAI pilot is the working prototype: local inference, zero tracking footprint, no data leaving the building. The revenue model is straightforward — hardware-plus-service contracts, maintenance subscriptions, and grant-funded deployments — and every efficiency gain flows to the community instead of a cloud vendor’s margin.

AI services on open models. Consulting, fine-tuning, retrieval systems, and workflow automation for mission-aligned organizations that want AI capability without surrendering their data. The open-weight ecosystem means our cost of goods is electricity and expertise, not per-token tribute to a gatekeeper.

Connective software. The layer this post is really about: WordPress plugins that act as MCP connectors, turning the world’s most widely deployed publishing platform into the nervous system of a values-aligned economy.

Notice what all three have in common: the software is open, and the money is in deployment, operation, curation, and trust — the things that can’t be copied by downloading a zip file. That’s the pattern Red Hat proved at billion-dollar scale, and it’s the pattern WordPress itself proved: the code is free; the enterprises around it are not.

Part Two: WordPress + MCP — The Door Is Wide Open Right Now

If you haven’t been watching WordPress lately, the ground just shifted. WordPress 6.9 introduced the Abilities API, a standard way for plugins, themes, and core to register their functionality as discoverable, typed, executable capabilities. WordPress 7.0 — released May 20, 2026, the biggest core update in eight years — extended it, and the official WordPress MCP Adapter now bridges those abilities directly to the Model Context Protocol (MCP), the open standard that lets AI agents like Claude discover and invoke tools on any server that speaks it.

Translate that from developer-speak: every one of the hundreds of millions of WordPress sites on the internet — over 40% of the web — can now become a node that AI agents can talk to, transact with, and act through. And the connector layer that makes it possible is brand new, officially supported, and almost entirely unbuilt-out.

This is the moment small players dream about. The incumbents are busy fighting over the model layer. The agentic plumbing layer — where an AI agent books a service from a local cooperative, checks inventory at a community solar installer, or files a request with a mutual-aid network — is greenfield, and WordPress is its natural substrate because it’s already where small organizations live.

Our plugin roadmap:

1. OccupyAI Connector (core plugin). Registers a site’s offerings — services, skills, availability, needs — as WordPress Abilities and exposes them via the MCP Adapter, so any MCP-capable agent can discover them.
2. Values Registry. Lets a site declare and cryptographically attest its values commitments (cooperative ownership, renewable power, privacy practices, living wages) in a machine-readable format agents can filter on.
3. Exchange Ledger. Records offers, matches, and completed exchanges between member sites — the bookkeeping layer of the marketplace described in Part Five.
4. Local Model Bridge. Points a site’s AI features at community-owned inference (a CivicBoxAI node or any local open-model endpoint) instead of a corporate API.

Each plugin is free and open. Each one also creates a paid surface: hosted setup, managed federation, verification services, and premium operational tooling. Which brings us to licensing.

Part Three: Choosing Licenses — Open by Conviction, Protected by Design

First, the constraint that shapes everything: WordPress is licensed under the GPL, and plugin code that integrates with WordPress — calling its functions, using its hooks — is generally considered a derivative work. If you distribute a WordPress plugin, its PHP must carry a GPL-compatible license, and anything listed in the official WordPress.org plugin directory must be 100% GPL-compatible. This isn’t a burden for us; it’s an alignment. But it does mean the licensing strategy has to be deliberate. Here are the realistic options:

License	Type	What it requires	Best used for
GPLv2/GPLv3	Strong copyleft	Derivatives that are distributed must stay GPL; source must be offered	The WordPress plugins themselves — required for WP.org listing, keeps the commons open
AGPLv3	Strongest copyleft	Extends GPL obligations to software offered over a network — SaaS users must get source too	Server-side companion services you want to keep open and prevent cloud vendors from enclosing
LGPL	Weak copyleft	Modifications to the library stay open; linking from proprietary code is allowed	Shared libraries you want widely adopted, including by proprietary tools
MPL 2.0	File-level copyleft	Changed files stay open; can combine with proprietary files	Middle-ground components; GPL-compatible
Apache 2.0	Permissive	Attribution; includes an explicit patent grant	SDKs, protocol specs, and reference implementations you want everyone — even competitors — to adopt (GPLv3-compatible, not GPLv2)
MIT / BSD	Permissive	Attribution only	Small utilities, code samples, docs — maximum adoption, minimum friction
BSL / Fair Source / Elastic-style	Source-available (⚠️ not open source by OSI definition)	Source is visible but commercial use restricted, often converting to open after a delay	Generally not an option for WordPress plugin code, and off-brand for us — listed for completeness

The combination strategy — how you emphasize open source and protect the enterprise — is a layered one:

Layer 1 — GPL the plugins, fully and proudly. The connectors, the registry, the ledger: 100% GPL, listed on WordPress.org, forkable by anyone. This maximizes distribution, earns trust, and makes the protocol layer a genuine commons. Yes, anyone — including a competitor — can redistribute them. WordPress’s own economy proves this is survivable: people pay for updates, support, security, and a trusted source, not for the zip file.

Layer 2 — Split-license the premium tiers. GPL governs code that derives from WordPress; it does not automatically govern everything shipped alongside it. Premium plugin editions commonly use a “split license”: PHP under GPL, with original JavaScript applications, CSS frameworks, artwork, and documentation under a separate proprietary or restrictive license. Combined with trademark protection (more below), this is the standard freemium architecture of the WordPress economy.

Layer 3 — AGPL or keep private the network services. The hosted services our plugins talk to — the federation directory, the verification service, the matching engine — are not WordPress-derivative and can be licensed however we choose. AGPLv3 is the values-forward choice: it keeps the service code open while legally preventing a hyperscaler from taking it, improving it privately, and offering it as a competing closed service. Alternatively, some server components simply stay unpublished — which is Part Four.

Layer 4 — Trademark everything that carries reputation. GPL gives away the code, never the name. “OccupyAI,” “CivicBoxAI,” “Verdant Data” — registered trademarks mean a fork can copy our code but cannot wear our badge of trust. For a values-based network, the mark is the moat: certification marks can even formalize this, the way “Fair Trade Certified” does.

Layer 5 — Dual licensing where it pays. For components we author entirely (no WordPress derivation), we can offer the same code under GPL for the commons and under a paid commercial license for firms that want to embed it in proprietary products. MySQL and Qt built real businesses this way. It requires owning the copyright outright — so contributor license agreements matter from day one.

Part Four: The Coca-Cola Playbook — Protecting What Patents Can’t

In 1886, Coca-Cola faced a choice: patent the formula and disclose it to the world with an expiration date, or lock it in a vault and protect it through secrecy forever. The formula has now been a trade secret for 140 years — longer than any patent could ever have run. The lesson isn’t about syrup. It’s that the strongest protection for some assets is never publishing them at all.

Trade secret law — the federal Defend Trade Secrets Act and state Uniform Trade Secrets Act — protects information that (a) derives economic value from not being generally known and (b) is subject to reasonable measures to keep it secret. Unlike patents, there’s no application, no disclosure, no 20-year clock, and no examiner deciding whether an algorithm is “patentable subject matter” — a genuine problem for software, where courts have narrowed what qualifies. Unlike copyright, trade secrecy protects the ideas and data, not just the expression.

For an open source AI enterprise, this sounds like a contradiction. It isn’t. The discipline is knowing exactly where the vault sits. Our published GPL code is the bottling plant — visible, inspectable, copyable. The syrup stays server-side:

• Fine-tuned model weights and training recipes. The weights of models we specialize for community deployment, the curated datasets they’re trained on, and the data-cleaning pipelines that produced them never need to leave our infrastructure. Model weights are a textbook modern trade secret — most leading AI labs protect theirs exactly this way rather than through patents.
• The matching and reputation algorithms. How the marketplace scores values-alignment, ranks matches, and detects gaming — served as an API, never shipped as code. Server-side ranking logic that users never see is classic trade-secret territory.
• Prompt systems, evaluation harnesses, and orchestration logic. The accumulated operational know-how of making open models perform reliably in the field.
• Deployment know-how. Site-survey methods, solar/compute sizing calculators, thermal and power tuning for mini data centers — the craft knowledge from every installation.

Because MCP is an interface, this architecture is natural rather than forced: the GPL plugin on a member’s site calls a tool; the tool’s implementation lives behind our API. Users get full freedom over the code running on their machines — the open source commitment is real — while the crown jewels remain performances we deliver, not artifacts we hand over.

Secrecy only holds if the “reasonable measures” are actually taken, and courts check. That means: NDAs and confidentiality clauses for employees, contractors, and partners; access on a need-to-know basis with logging; marked and segregated confidential repositories; offboarding procedures; and never, ever committing the syrup to a public repo by accident. One caution worth stating plainly: a trade secret protects against misappropriation, not independent invention or reverse engineering of what you’ve shipped. That’s precisely why the strategy is don’t ship it — keep it behind the counter, like the formula in the vault in Atlanta.

(The usual caveat: this is strategy, not legal advice — an IP attorney should review the specific licensing and secrecy architecture before launch.)

Part Five: A Many-to-Many Marketplace — Making Values Valuable Again

Everything above is infrastructure. Here is what it’s for.

Khan told Krugman something publishers already know in their bones: when a gatekeeper sits between producers and the people they serve, the gatekeeper eventually keeps the value. Google went from being “a turnstile to the rest of the web” to an enclosure that summarizes everyone’s work and keeps the traffic. Every one-to-many platform tends the same way, because the platform’s incentive is extraction.

A many-to-many marketplace inverts the shape. No single company sits at the center taking a toll on every transaction. Instead, every participant is both producer and consumer — a web designer who needs solar consulting, a solar installer who needs bookkeeping, a bookkeeper who needs a website — and the marketplace is the protocol connecting them, not a landlord hosting them. Concretely:

Nodes, not accounts. Each member’s WordPress site, running the OccupyAI Connector, publishes what it offers and what it needs as MCP-discoverable abilities. Your storefront is your own site, on your own domain, under your own control. Leave the network and you lose nothing you built.

Values as a first-class filter. The Values Registry makes commitments machine-readable and verifiable — renewable-powered hosting, cooperative or worker ownership, privacy practices, community reinvestment. When your agent searches the network for “accessibility audit from a worker-owned shop within my bioregion,” alignment isn’t a vibe; it’s a query parameter. This is what “making values valuable again” means mechanically: values become discoverable, comparable, and rewardable attributes that steer real transactions — so the living-wage co-op stops being invisible next to the race-to-the-bottom bidder.

Reciprocity alongside currency. Members exchange services for money, but also through mutual credit — a ledger where providing services to any member earns credit spendable with any other member. This is the time-bank and mutual-credit tradition, proven for decades, given modern discovery tools. (No tokens, no speculation, no crypto — just accounting among parties who trust the federation.)

Agents as brokers. This is what MCP changes. Matching in a many-to-many network was always the hard part — too many pairings for humans to search. Now each member’s AI assistant, running on open models (ideally on community compute), can negotiate the graph: finding matches, checking values filters, proposing multi-party trades a human would never spot. A three-way exchange — design work for solar consulting for bookkeeping — becomes as easy as a purchase.

Cooperative governance. The marketplace itself should practice what it filters for: a platform cooperative, owned by its members, with the operating enterprise (ours) as service provider to the co-op rather than owner of the members. Revenue comes from membership dues, managed hosting of nodes, verification and certification services, premium tooling, and deployment of the community compute the network runs on — every stream tied to service delivered, none to enclosure.

That last point is the whole design philosophy in miniature. The moats of extractive platforms are lock-in and data hoarding. Ours are trust, verified values, operational excellence, and a few well-guarded trade secrets — moats that protect the enterprise without imprisoning the community.

The Invitation

The gatekeepers are betting that AI stays centralized, closed, and inefficient, because that’s what their margins require. We’re betting the other way — with Lina Khan’s history on our side: paradigm shifts come from outsiders, open systems catalyze innovation, and open source businesses can be enormously lucrative precisely because they grow the whole field.

The stack is ready. Open models are good and getting better. WordPress just handed 40% of the web an official bridge to AI agents. The licensing playbook lets us give the commons everything it needs while keeping the enterprise defensible. And the marketplace design turns shared values from a bumper sticker into a business advantage.

If you run a WordPress site, build plugins, install solar, keep books, write code, or simply believe your economic life should flow through institutions you’d be proud to co-own — the network needs your node.

Let’s make values valuable again.

---

OccupyAInet℠ is part of an ecosystem that includes the Broadband Institute Foundation, Verdant Data, and CivicBoxAI℠ from podCOINai℠ — building regenerative digital infrastructure: community-owned broadband, solar-powered mini data centers, and privacy-first AI.