Skip to content

PATTERN Cited by 1 source

License-independent sandboxed plugins

Pattern

Structurally isolate plugins so they share no code (and no execution context) with the host platform. Plugins run in their own capability- based sandbox against a stable host API surface. Because there is no code-intertwining and no shared process, plugin authors are free to pick any license, distribute plugins through any channel, and ship closed-source / paid plugins — the host platform has no leverage over (and no need for leverage over) their distribution model.

Motivation

When plugins execute in the same process as the host platform and have direct access to the platform's data and APIs (e.g. WordPress-style PHP plugins), two structural consequences follow:

  1. The marketplace has to provide trust the platform can't. Because any plugin can do anything, users rely on marketplace-driven review + reputation to decide what's safe. The marketplace becomes the trust bottleneck. See concepts/plugin-marketplace-lock-in.
  2. Licensing gets coupled to the platform. When plugin code runs in the platform's execution context and is "so deeply intertwined with [platform] code, some argue they must carry forward [the platform's] GPL license." Plugin authors lose the ability to ship under their own license of choice.

This pattern addresses both consequences at once by making the runtime-level isolation the primary trust mechanism.

Preconditions

This pattern depends on two precursor primitives:

  • Capability-based sandbox at the runtime layer. Each plugin runs in a fresh sandbox with no ambient authority.
  • Capability manifest at the install interface. The plugin declares what capabilities it needs; the user inspects and approves at install time.

Without both, you can't credibly claim plugin trust is enforced by the runtime — and the marketplace will keep being the trust layer.

Two structural properties the pattern delivers

From the EmDash launch post:

"EmDash plugins have two important properties that mitigate this marketplace lock-in:

1. Plugins can have any license: they run independently of EmDash and share no code. It's the plugin author's choice.

2. Plugin code runs independently in a secure sandbox: a plugin can be provided to an EmDash site, and trusted, without the EmDash site ever seeing the code."

Property 1 — plugins can have any license — is a direct consequence of no-shared-code. The GPL inheritance argument only bites when the plugin is part of the platform's executable; in a sandbox with a stable host-API boundary, the plugin is a separate program. Authors ship MIT, proprietary, AGPL, or anything else.

Property 2 — plugin code can be trusted without being seen — is the more subtle one. Because the runtime enforces the manifest, the site administrator doesn't need to audit source to know what a plugin does. This enables:

  • Closed-source plugins. An author can ship a compiled binary, a minified bundle, or an obfuscated bytecode, and the installing site can still make an informed install decision.
  • Paid plugins without marketplace dependence. Authors can charge for plugins and distribute via their own channels (their own website, their own billing) without relying on a platform marketplace for trust signalling.
  • Multiple competing marketplaces. Because trust is runtime-enforced, not marketplace-provisioned, multiple marketplaces can coexist. Users aren't forced to accept any single curator's decisions.

Non-marketplace distribution channels that become viable

With this pattern, plugin distribution looks more like the npm / PyPI / Packagist model and less like the WordPress.org model:

  • NPM-style: a registry that hosts bundles; the consumer imports and uses what they want; the consumer decides what to trust based on their own criteria.
  • Direct distribution: an author's own website + download link. Installing is equivalent to installing from a registry because the runtime sandbox provides the trust.
  • Private distribution: enterprise customers can distribute internal plugins through their own channels without going through any public marketplace.

What this pattern does NOT eliminate

The pattern breaks the marketplace-as-trust-bottleneck coupling. It does not remove the marketplace's other useful functions:

  • Discovery — users still need to find plugins.
  • Reviews and ratings — users still value recommendation signal.
  • Updates and security bulletins — coordinated vulnerability disclosure, CVE tracking.
  • Billing infrastructure — some plugin authors will still prefer a marketplace handling billing.

A sandbox-based ecosystem can have marketplaces; they're just optional, non-exclusive, and no longer the trust layer.

Contrast — WordPress

WordPress's plugin architecture is the structural anti- example:

  • No isolation: plugins share process and data with the platform.
  • Trust via manual marketplace review: 800+ deep queue, ≥2 week wait.
  • License coupled to platform: GPL argument applies (disputed but influential).
  • Commercial freedom limited: plugin authors can charge for support / services but not for the code itself in a way that's straightforwardly compatible with GPL + the marketplace.

Canonical instance

EmDash's plugin architecture (v0.1.0, 2026-04-01) is the canonical wiki instance. Every plugin is a Dynamic Worker with a capability manifest; plugins can have any license; the EmDash site can run plugins without seeing their code. MIT-licensed EmDash core with any-license plugins is the explicit design goal.

Seen in

Last updated · 200 distilled / 1,178 read