Licensing

Open runtime. Cloud-generated compliance.

The Fluxtion runtime is open source — it runs your processor. The hosted cloud service generates processors at design time and is the commercial product; the analyser behind that generation is source-available. You use the cloud to create or change a business process; you don't need it to run one that's already signed off.

That generation step is the patented flow — and its output is the deterministic, auditable artifact your compliance team reviews. The generator is needed to produce that artifact; once produced, it runs forever on the open runtime.

The architecture, end to end

From development to production

The cloud generates at design time; the open runtime carries it to production — embedded, standalone, edge/WASM, or hosted — with no cloud and no key past sign-off.

Fluxtion licensing architecture — development to productionAt design time the cloud service runs the patented analyser to generate your processor — the paid step. Its output is a deterministic, auditable artifact you sign off. At run time the open-source runtime executes that signed-off processor everywhere — embedded, standalone on the JVM or natively compiled or WebAssembly, or hosted in Mongoose — with no cloud and no key.FROM DEVELOPMENT TO PRODUCTIONDESIGN TIME — the cloud generates · needs a keyDefineauthor the graph — DSL · Spring · Javaopen · yoursGeneraterun by the cloud servicehosted · patented · paidAuditable artifactdeterministic source · graph · replayopen · yourssign off → runs forever, no cloudRUN TIME — the open runtime · no cloud, no keyfluxtion-runtimeopen source · runs your processordeterministic · replayable · auditableCompliance docssigned-off source · graph · replaywhat auditors reviewEmbeddeddrop into your processFlink · Lambda · your appopen source — no keyStandaloneself-contained appJVM · native binaryopen source — no keyEdge / WASMcompile to WebAssemblybrowser · node · edgeopen source — no keyMongooseindustrial servermulti-tenant · pluginsagent threads · admin
Design time vs run time

One generation flow, then open forever

The cloud touches your process exactly once per change — to generate it. Everything to the right of "Generate" is open and yours.

Author

Define the process

Your code · open

Describe the event logic in Java — the DSL, Spring XML, or imperative nodes. Plain source you own and version. Nothing leaves your machine yet.

Open · your code
Generate

Fluxtion cloud generates

Hosted · API key

The cloud service runs the patented graph-inference flow to generate your processor — the optimised, reflection-free dispatcher. This is the commercial product, and the only step that needs a key.

Cloud · patented · paid
Sign off

Auditable artifact

Yours to review

The output is deterministic generated source, the graph (GraphML), and replayable audit — human-readable and reproducible. This is the artifact your compliance team reviews and signs off.

Yours · the compliance artifact
Run

Run anywhere, no cloud

Open source

The open-source runtime executes the signed-off processor — JVM, native image, or WebAssembly — deterministically, emitting the same audit trail. No cloud, no key, no dependency on us.

Open source

The cloud service is used to generate or change a business process — not to run one that's already signed off. If the service were unavailable tomorrow, every signed-off processor keeps running, unchanged, on the open runtime.

What's open · what's paid

The component matrix

Everything you run and everything you ship is open or yours. The paid part is generation — creating or changing the processor artifact. The analyser is source-available; the one commercial piece is the hosted cloud service, used at design time.

No production lock-in: the generated processor source belongs to your project — inspect it, commit it, audit it, deploy it, and run it with no ongoing Fluxtion cloud access.

fluxtion-runtime

Run time

Executes your generated processor and emits the audit trail. One jar, no reflection on the hot path. Open source under AGPL today; a move to Apache 2.0 (for friction-free embedding) is under consideration.

Open · AGPL today

Fluxtion analyser

Design time

The graph-inference / generation engine — the patented flow. Source-available: inspect or self-host it, but offering it as a service means open-sourcing your serving stack.

Source-available

Fluxtion cloud service

Design time

The analyser hosted and run for you, reached with an API key. Telamin’s commercial offering — the paid product.

Commercial · hosted

Generated processor

The output

The deterministic, human-readable source the analyser produces — the artifact you audit, sign off, and ship. Yours.

Yours

fluxtion-wasm-bootstrap

Run time

Host glue that lets the generated processor run in the browser / on the edge as WebAssembly. Already shipped under Apache 2.0.

Open · Apache 2.0

IntelliJ plugin

Design time

Visual graph + audit step-through in the IDE. Licensing is being finalised ahead of public release.

Licensing TBD

The rest of the toolchain: the project starter and playground are free and keyless; cloud generation needs an API key. Mongoose and its plugins are a separately-licensed production-hosting and connector tier — Fluxtion processors run embedded without Mongoose, or hosted inside it for server management, agent threads, an admin UI, and enterprise connectors.

Open where you run

The runtime is open source — AGPL today, with a move to Apache 2.0 (for friction-free embedding in any application) under consideration. Either way, what you deploy and the generated source you sign off are yours, and run on the open runtime.

Source-available where it's generated

The analyser is source-available — inspect it, and where the licence permits, self-host it. The restriction is commercial resale as a competing hosted generation service. That protects the service that funds the project; it doesn't limit what you build with the processors it generates.

The analyser's specific source-available licence is under review (currently SSPL; a move to the Business Source License is being evaluated). The principle above — open to run, restricted from resale as a hosted generation service — holds either way. Generated processors and runtime use are not affected by this licence choice.

Why it holds up to audit

The generated output is the compliance artifact

Regulated processes are signed off on artifacts, not promises. And the generator emits more than code: alongside the deterministic, human-readable Java source it produces the supporting documents an audit relies on — a graph of how every event flows, a replayable audit trail, and the model behind both. A reviewer can read the logic, re-run a recorded event stream, and get the same result every time — the property an auditor actually needs.

And the outputs are customisable to your requirements: the set of generated documents — formats, fields, the audit and graph artifacts — can be shaped to match your organisation's compliance and sign-off process, rather than forcing you onto a fixed template.

Because the artifact is self-contained and the runtime is open, sign-off is durable: the processor you approved is the processor that runs in production, with no hidden runtime service deciding behaviour. You change it only by generating a new version — which goes through the same review.

Deterministic

Same input, same output — every run, on JVM, native, or WASM.

Replayable

Record an event stream, replay it through the same dispatcher, reproduce any decision.

Readable

Plain generated source + graph — no black box to take on trust.

One patented flow

Define → generate → auditable artifact is the patented graph-inference mechanism (US filing 2026): turning a declared graph into an optimised, reflection-free, deterministic dispatcher. The open-source runtime carries a patent grant for its use, and processors generated through the Fluxtion service are intended to run freely on it.

Go deeper

Try it without a key first

The browser playground generates and runs processors with no key and no install. When you're ready to ship, the project starter shows exactly when the cloud is needed — once, at build time.